topic Re: How to avoid User Homes in Alfresco Archive

How to avoid User Homes

alarocca — Mon, 30 Apr 2007 18:49:25 GMT

Hi,is there any configuration or even workaround to avoid User Homes creation, allowing users to play only with common spaces?Thank you,Alessandro

Re: How to avoid User Homes

andy — Wed, 09 May 2007 10:44:05 GMT

Hi

What version are you using?

At what point do you want to control user home creation?
User creation? LDAP import?

See the example for home folder providers on the Wiki.

Andy

Re: How to avoid User Homes

alarocca — Wed, 09 May 2007 10:56:21 GMT

Hi Andy,

version is 2.0 and I use NTLM. With provider userHomesHomeFolderProvider, first time user login, its home space is created within User Homes. Is it mandatory that a user has to be owner of a space? I would like to avoid users to have their home space. They should just use some shared spaces according roles assigned to them.

Hi

What version are you using?

At what point do you want to control user home creation?
User creation? LDAP import?

See the example for home folder providers on the Wiki.

Andy

Re: How to avoid User Homes

pparkinson — Wed, 09 May 2007 16:32:01 GMT

Hi,

Us too, we do not want user home spaces created. We're using ALF 2.0.1, LDAP sync authenticator type passthru.

We've changed the homeFolderProvider to companyHomeFolderProvider which helps for what the users default home is however, each account that is imported an automatic home folder space is still created.

Is there a way to disable this user homespace creation?

Re: How to avoid User Homes

andy — Thu, 10 May 2007 10:21:40 GMT

Hi

Please rasie this as a bug and describe your set up as fully as possible.

If the company home folder provider is used a user specific home space
should not be made.

Can you post your LDAP config and any changes made to authentication-services-context.xml and home folder providers

Cheers

Andy

Re: How to avoid User Homes

pparkinson — Thu, 10 May 2007 18:04:29 GMT

Hi Andy,

RH4 E
ALF 2.0.1 E
MySQL 4

So before I post a bug perhaps I'm missing something. We've tested that with a fresh database and empty datafolders. On startup when ldap syncs the existing users come over and no home folders are created. However, now running, if we add a new user to ldap and the scheduled ldap sync runs on the hour a new home folder will be created for the newly added user not existing users.

We have made no changes to the authentication-services-context.xml and home providers. Enclosed is our ldap-authentication-context.xml file.

ldap-authentication-context.xml
*************************************************************
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>

<beans>

    <!– DAO that rejects changes - LDAP is read only at the moment. It does allow users to be deleted with out warnings from the UI. –>

    <bean name="authenticationDao" class="org.alfresco.repo.security.authentication.DefaultMutableAuthenticationDao" >
        <property name="allowDeleteUser">
            <value>true</value>
        </property>
    </bean>


    <!– LDAP authentication configuration –>

    <!–

    You can also use JAAS authentication for Kerberos against Active Directory or NTLM if you also require single sign on from the
    web browser. You do not have to use LDAP authentication to synchronise groups and users from an LDAP store if it supports other
    authentication routes, like Active Directory.

    –>

    <bean id="authenticationComponent" class="org.alfresco.repo.security.authentication.ldap.LDAPAuthenticationComponentImpl">
        <property name="LDAPInitialDirContextFactory">
            <ref bean="ldapInitialDirContextFactory"/>
        </property>
        <property name="userNameFormat">
            <!–

            This maps between what the user types in and what is passed through to the underlying LDAP authentication.

            "%s" - the user id is passed through without modification.
            Used for LDAP authentication such as DIGEST-MD5, anything that is not "simple".

            "cn=%s,ou=London,dc=company,dc=com" - If the user types in "Joe Bloggs" the authentricate as "cn=Joe Bloggs,ou=London,dc=company,dc=com"
            Usually for simple authentication.

            –>
            <value>uid=%s,ou=users,dc=bc,dc=com</value>
        </property>
    </bean>

    <!–

    This bean is used to support general LDAP authentication. It is also used to provide read only access to users and groups
    to pull them out of the LDAP reopsitory

    –>

    <bean id="ldapInitialDirContextFactory" class="org.alfresco.repo.security.authentication.ldap.LDAPInitialDirContextFactoryImpl">
        <property name="initialDirContextEnvironment">
            <map>
                <!– The LDAP provider –>
                <entry key="java.naming.factory.initial">
                    <value>com.sun.jndi.ldap.LdapCtxFactory</value>
                </entry>

                <!– The url to the LDAP server –>
                <!– Note you can use space separated urls - they will be tried in turn until one works –>
                <!– This could be used to authenticate against one or more ldap servers (you will not know which one ….) –>
                <entry key="java.naming.provider.url">
                    <value>ldap://sampleldap.bc.com:9888</value>
                </entry>

                <!– The authentication mechanism to use      –>
                <!– Some sasl authentication mechanisms may require a realm to be set –>
                <!–                java.naming.security.sasl.realm –>
                <!– The available options will depend on your LDAP provider –>
                <entry key="java.naming.security.authentication">
                    <value>simple</value>
                </entry>

                <!– The id of a user who can read group and user information –>
                <!– This does not go through the pattern substitution defined above and is used "as is" –>
                <entry key="java.naming.security.principal">
                    <value>uid=account,ou=users,dc=bc,dc=com</value>
                </entry>

                <!– The password for the user defined above –>
                <entry key="java.naming.security.credentials">
                    <value>password</value>
                </entry>
            </map>
        </property>
    </bean>

    <!– Ldap Syncronisation support –>

    <!–

    There can be more than one stack of beans that import users or groups. For example, it may be easier
    to have a version of ldapPeopleExportSource, and associated beans, for each sub-tree of your ldap directory
    from which you want to import users. You could then limit users to be imported from two or more sub tress and ignore
    users found else where. The same applies to the import of groups.

    The defaults shown below are for OpenLDAP.

    –>


    <!– Extract user information from LDAP and transform this to XML –>

    <bean id="ldapPeopleExportSource" class="org.alfresco.repo.security.authentication.ldap.LDAPPersonExportSource">
        <!–
        The query to select objects that represent the users to import.

        For Open LDAP, using a basic schema, the following is probably what you want:
        (objectclass=inetOrgPerson)

        For Active Directory:
        (objectclass=user)
        –>
        <property name="personQuery">
            <value><![CDATA[(&(objectclass=inetOrgPerson)(adMemberOf=CN=HQBO200Alfresco,OU=CSC Security Groups,OU=CSC,DC=bc,DC=com))]]></value>
        </property>

        <!–
        The seach base restricts the LDAP query to a sub section of tree on the LDAP server.
        –>
        <property name="searchBase">
            <value>ou=users,dc=bc,dc=com</value>
        </property>

        <!–
        The unique identifier for the user.

        THIS MUST MATCH WHAT THE USER TYPES IN AT THE LOGIN PROMPT

        For simple LDAP authentication this is likely to be "cn" or, less friendly, "distinguishedName"

        In OpenLDAP, using other authentication mechanisms "uid", but this depends on how you map
        from the id in the LDAP authentication request to search for the inetOrgPerson against which
        to authenticate.

        In Active Directory this is most likely to be "sAMAccountName"

        This property is mandatory and must appear on all users found by the query defined above.

        –>
        <property name="userIdAttributeName">
            <value>uid</value>
        </property>

        <!– Services –>
        <property name="LDAPInitialDirContextFactory">
            <ref bean="ldapInitialDirContextFactory"/>
        </property>
        <property name="personService">
            <ref bean="personService"></ref>
        </property>
        <property name="namespaceService">
            <ref bean="namespaceService"/>
        </property>

        <!–
        This property defines a mapping between attributes held on LDAP user objects and
        the properties of user objects held in the repository. The key is the QName of an attribute in
        the repository, the value is the attribute name from the user/inetOrgPerson/.. object in the
        LDAP repository.
        –>
        <property name="attributeMapping">
            <map>
                <entry key="cm:userName">
                    <!– Must match the same attribute as userIdAttributeName –>
                    <value>uid</value>
                </entry>
                <entry key="cm:firstName">
                    <!– OpenLDAP: "givenName" –>
                    <!– Active Directory: "givenName" –>
                    <value>givenName</value>
                </entry>
                <entry key="cm:lastName">
                    <!– OpenLDAP: "sn" –>
                    <!– Active Directory: "sn" –>
                    <value>sn</value>
                </entry>
                <entry key="cm:email">
                    <!– OpenLDAP: "mail" –>
                    <!– Active Directory: "???" –>
                    <value>mail</value>
                </entry>
                <entry key="cmrganizationId">
                    <!– OpenLDAP: "o" –>
                    <!– Active Directory: "???" –>
                    <value>employeeId</value>
                </entry>
                <!– Always use the default –>
                <entry key="cm:homeFolderProvider">
                    <null/>
                </entry>
            </map>
        </property>
        <!– Set a default home folder provider –>
        <!– Defaults only apply for values above –>
        <property name="attributeDefaults">
            <map>
                <entry key="cm:homeFolderProvider">
                    <value>companyHomeFolderProvider</value>
                </entry>
            </map>
        </property>
    </bean>

    <!– Extract group information from LDAP and transform this to XML –>

    <bean id="ldapGroupExportSource" class="org.alfresco.repo.security.authentication.ldap.LDAPGroupExportSource">
        <!–
        The query to select objects that represent the groups to import.

        For Open LDAP, using a basic schema, the following is probably what you want:
        (objectclass=groupOfNames)

        For Active Directory:
        (objectclass=group)
        –>
        <property name="groupQuery">
            <value>(objectclass=groupOfUniqueNames)</value>
        </property>

        <!–
        The seach base restricts the LDAP query to a sub section of tree on the LDAP server.
        –>
        <property name="searchBase">
            <value>ou=Alfresco,ou=AppData,dc=bc,dc=com</value>
        </property>

        <!–
        The unique identifier for the user. This must match the userIdAttributeName on the ldapPeopleExportSource bean above.
        –>
        <property name="userIdAttributeName">
            <value>uid</value>
        </property>

        <!–
        An attribute that is a unique identifier for each group found.
        This is also the name of the group with the current group implementation.
        This is mandatory for any groups found.

        OpenLDAP: "cn" as it is mandatory on groupOfNames
        Active Directory: "cn"

        –>
        <property name="groupIdAttributeName">
            <value>cn</value>
        </property>

        <!–
        The objectClass attribute for group members.
        For each member of a group, the distinguished name is given.
        The object is looked up by its DN. If the object is of this class it is treated as a group.
        –>
        <property name="groupType">
            <value>groupOfUniqueNames</value>
        </property>

        <!–
        The objectClass attribute for person members.
        For each member of a group, the distinguished name is given.
        The object is looked up by its DN. If the object is of this class it is treated as a person.
        –>
        <property name="personType">
            <value>inetOrgPerson</value>
        </property>
        <property name="LDAPInitialDirContextFactory">
            <ref bean="ldapInitialDirContextFactory"/>
        </property>
        <property name="namespaceService">
            <ref bean="namespaceService"/>
        </property>

        <!–
        The repeating attribute on group objects (found by query or as sub groups)
        used to define membership of the group. This is assumed to hold distinguished names of
        other groups or users/people; the above types are used to determine this.

        OpenLDAP: "member" as it is mandatory on groupOfNames
        Active Directory: "member"

        –>
        <property name="memberAttribute">
            <value>uniquemember</value>
        </property>

        <property name="authorityDAO">
            <ref bean="authorityDAO"/>
        </property>
    </bean>

    <!– Job definitions to import LDAP people and groups –>
    <!– The triggers register themselves with the scheduler –>
    <!– You may comment in the default scheduler to enable these triggers –>
    <!– If a cron base trigger is what you want seee scheduled-jobs-context.xml for examples. –>

    <!– Trigger to load poeple –>
    <!– Note you can have more than one initial (context, trigger, import job and export source) set –>
    <!– This would allow you to load people from more than one ldap store –>

    <bean id="ldapPeopleTrigger" class="org.alfresco.util.TriggerBean">
        <property name="jobDetail">
            <bean id="ldapPeopleJobDetail" class="org.springframework.scheduling.quartz.JobDetailBean">
                <property name="jobClass">
                    <value>org.alfresco.repo.importer.ImporterJob</value>
                </property>
                <property name="jobDataAsMap">
                    <map>
                        <entry key="bean">
                            <ref bean="ldapPeopleImport"/>
                        </entry>
                    </map>
                </property>
            </bean>
        </property>
        <!– Start after 5 minutes of starting the repository –>
        <property name="startDelay">
            <value>300000</value>
        </property>
        <!– Repeat every hour –>
        <property name="repeatInterval">
            <value>3600000</value>
        </property>
        <!– Commented out to disable –>
        <property name="scheduler">
            <ref bean="schedulerFactory" />
        </property>
    </bean>

    <bean id="ldapGroupTrigger" class="org.alfresco.util.TriggerBean">
        <property name="jobDetail">
            <bean id="ldapGroupJobDetail" class="org.springframework.scheduling.quartz.JobDetailBean">
                <property name="jobClass">
                    <value>org.alfresco.repo.importer.ImporterJob</value>
                </property>
                <property name="jobDataAsMap">
                    <map>
                        <entry key="bean">
                            <ref bean="ldapGroupImport"/>
                        </entry>
                    </map>
                </property>
            </bean>
        </property>
        <!– Start after 5 minutes of starting the repository –>
        <property name="startDelay">
            <value>300000</value>
        </property>
        <!– Repeat every hour –>
        <property name="repeatInterval">
            <value>3600000</value>
        </property>
        <!– Commented out to disable–>
        <property name="scheduler">
            <ref bean="schedulerFactory" />
        </property>
    </bean>

    <!– The bean that imports xml describing people –>

    <bean id="ldapPeopleImport" class="org.alfresco.repo.importer.ExportSourceImporter">
        <property name="importerService">
            <ref bean="importerComponentWithBehaviour"/>
        </property>
        <property name="transactionService">
            <ref bean="transactionComponent"/>
        </property>
        <property name="authenticationComponent">
            <ref bean="authenticationComponent"/>
        </property>
        <property name="exportSource">
            <ref bean="ldapPeopleExportSource"/>
        </property>

        <!– The store that contains people - this should not be changed –>
        <property name="storeRef">
            <value>${spaces.store}</value>
        </property>

        <!– The location of people nodes within the store defined above - this should not be changed –>
        <property name="path">
            <value>/${system.system_container.childname}/${system.people_container.childname}</value>
        </property>

        <!– If true, clear all existing people before import, if false update/add people from the xml –>
        <property name="clearAllChildren">
            <value>true</value>
        </property>
        <property name="nodeService">
            <ref bean="nodeService"/>
        </property>
        <property name="searchService">
            <ref bean="searchService"/>
        </property>
        <property name="namespacePrefixResolver">
            <ref bean="namespaceService"/>
        </property>


        <property name="caches">
            <set>
                <ref bean="permissionsAccessCache"/>
            </set>
        </property>
    </bean>

    <!– The bean that imports xml descibing groups –>

    <bean id="ldapGroupImport" class="org.alfresco.repo.importer.ExportSourceImporter">
        <property name="importerService">
            <ref bean="importerComponentWithBehaviour"/>
        </property>
        <property name="transactionService">
            <ref bean="transactionComponent"/>
        </property>
        <property name="authenticationComponent">
            <ref bean="authenticationComponent"/>
        </property>
        <property name="exportSource">
            <ref bean="ldapGroupExportSource"/>
        </property>
        <!– The store that contains group information - this should not be changed –>
        <property name="storeRef">
            <value>${alfresco_user_store.store}</value>
        </property>

        <!– The location of group information in the store above - this should not be changed –>
        <property name="path">
            <value>/${alfresco_user_store.system_container.childname}/${alfresco_user_store.authorities_container.childname}</value>
        </property>

        <!– If true, clear all existing groups before import, if false update/add groups from the xml –>
        <property name="clearAllChildren">
            <value>true</value>
        </property>
        <property name="nodeService">
            <ref bean="nodeService"/>
        </property>
        <property name="searchService">
            <ref bean="searchService"/>
        </property>
        <property name="namespacePrefixResolver">
            <ref bean="namespaceService"/>
        </property>

        <!– caches to clear on import of groups –>
        <property name="caches">
            <set>
                <ref bean="userToAuthorityCache"/>
                <ref bean="permissionsAccessCache"/>
            </set>
        </property>

        <!– userToAuthorityCache –>
    </bean>

</beans>
*************************************************************

Thanks,
Preston

Re: How to avoid User Homes

andy — Mon, 14 May 2007 10:38:10 GMT

Hi

It may be you are auto creating people before the ldap import comes along.
(If they log in before the LDAP import)
This will create user homes according to the default provider and not the one defined in the LDAP config. See authentication-services-context.xml.

Cheers

Andy

Re: How to avoid User Homes

chrisb — Thu, 31 May 2007 14:33:11 GMT

I am running into what I think may be the same issue, although I am just creating users via the Javascript API. After this is done I then want to set their home space via code to an existing space (i.e. not the default homespace that seems to get created).

I am using the latest Alfresco community build of 2.1.0, running on CentOS 5 and using PostgreSQL.

Currently I am trying to create a cmerson node using a call to:


var myPersonNode = companyhome.createNode("usernamexyz", "cm:person");
‍‍‍

As the cm:homeFolder property is mandatory within cmerson I then set the cm:homeFolder property to an existing folder Node, as well as setting several of the other cmerson properties.

However when I execute the script I see the following error in the web client:


Failed to run Actions due to error: Failed to execute script 'workspace://SpacesStore/666132ed-0f6d-11dc-a310-75e4e46f179e': Failed to execute script 'workspace://SpacesStore/666132ed-0f6d-11dc-a310-75e4e46f179e': Wrapped org.alfresco.repo.security.person.PersonException: Can not create a home space when the uid is null or empty (AlfrescoScript#46)
‍‍‍

which I think relates to the fact that the action of creating the cmerson is triggering the default homespace creation behaviour mentioned in the posts above?

Should I override the personalHomeFolderProvider bean definition in the authentication-services-context.xml? Or alternatively is there a bootstrap config where I should setup an alternative personalHomeFolderProvider definition?

The other option I will try is using the companyHomeFolderProvider option and then changing the newly created users home folder within my code….

All I am really after is the ability to create cmerson objects and set their home folders to a location other than the default.

Any help/suggestions greatly appreciated.

Thanks.

Re: How to avoid User Homes

chrisb — Fri, 01 Jun 2007 10:26:44 GMT

OK - in case it is of interest to anyone I have made some progress on this, but come into another issue for which I will start a new thread.

Changing the HomeFolderProvider to use either the guest or company providers seems to work for me (i.e. it stops the default behaviour of creating a new user homespace).

Using the latest (i.e. v2.1.0) People Javascript API methods, (in particular the createNode(nodeName, QName type, properties), I can create a new cmerson.

The key part seems to be setting up the associative array of default / mandatory properties before the call to creatNode(). Having said that the code to do this seems to run with no errors, but I can't find the person created in the user admin…. but I'll start another thread for that one :wink:

Thanks