Active directory authentication

Tue, 09/12/2006 - 11:36

#2

Andy

Alfresco Employee

Stats

Posts: 1442
Achievements: 6
Member for: 7 years 11 months
From: London

Hi

The first thing is to find out what authentication mechanisms are supported by your AD instance.

You may be able to use digest-md5 authentciation and enter the sAMAccountName (simple requires the DN)

In this case the usernameFormat should be just %s.

Regards

Andy

—

Andy Hind
Alfresco Development

Tue, 02/20/2007 - 13:30

#3

ajaychd

Stats

Posts: 3
Achievements: 0
Member for: 6 years 3 months

Hi

I also have same problem, working fine with simple authentication & using cn(full name), but not able to login through samaccountname.

i'm using Active Directory on windows 2003, it supports MD5 authentication, but still i'm not able to login if i go for MD5.

I have also configured the CIFS server for Kerberos/Active Directory integration.

here is a piece of code from ldap-authentication-context.xml

  <bean id="authenticationComponentImpl" class="org.alfresco.repo.security.authentication.ldap.LDAPAuthenticationComponentImpl">
        <property name="LDAPInitialDirContextFactory">
            <ref bean="ldapInitialDirContextFactory"/>
        </property>
        <property name="userNameFormat">
                      <value>%s</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://10.1.53.53:389</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>DIGEST-MD5</value> 
				  <!--   <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>ajay.mundra</value>
				<!--	<value>cn=ajay mundra,cn=Users,dc=secfportal,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 -->
 
 
    <!-- 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>(objectclass=inetOrgPerson)</value>-->
		    <value>(objectclass=user)</value>
        </property>
 
        <!--
        The seach base restricts the LDAP query to a sub section of tree on the LDAP server.
        -->
        <property name="searchBase">
            <value>dc=secfportal,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>-->
			<value>samaccountname</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>-->
					<value>samaccountname</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="cm:organizationId">
                    <!-- OpenLDAP: "o" -->
                    <!-- Active Directory: "???" -->
                    <value>company</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>personalHomeFolderProvider</value>
                </entry>
            </map>
        </property>
    </bean>

Please Help!

Tue, 02/20/2007 - 19:29

#4

Andy

Alfresco Employee

Stats

Posts: 1442
Achievements: 6
Member for: 7 years 11 months
From: London

Hi

Can you connect using digest-md5 hash with any other LDAP client?
It may be you have to configure AD.

You can fall back to Jass/Kerberos which will use the sAMAccountName.

Regards

Andy

—

Andy Hind
Alfresco Development

Fri, 03/09/2007 - 16:58

#5

rhofkens

Alfresco Partner

Stats

Posts: 34
Achievements: 2
Member for: 6 years 8 months

Hello,

I've managed to get authentication with AD sAMAccountName and DIGEST-MD5 up and running.

1) Make sure your AD stores user's passwords in reversible encryption. You can do this in the user --> properties --> Account tab, under Account Options. Note: you will have to reset the user's password after doing this, otherwise it won't have an effect. This is a major pain since AD is not configured out of the box for reversible encryption.

2) Make sure you use the right ldap URL. The value you enter here has to be listed in the serverPrincipalName attribute of your domain controller. Things like localhost will most likely not work.

                <!-- 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://alfresco-demo.wps-alfresco.com:389</value>
                </entry>

3) Enter the right credentials. Digest authentication doesn't work with distinguished names.

                <!-- 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">
                    <!-- DOESN'T WORK: <value>cn=administrator,cn=Users,dc=wps-alfresco,dc=com</value>-->
                    <value>administrator</value>
                </entry>

4) same for the username format:

        <property name="userNameFormat">
 
            <value>%s</value>
        </property>

Best regards,

—

Roeland Hofkens
Chief ECM Consultant
Westernacher Products & Services
http://www.westernacher.com

Mon, 03/12/2007 - 15:25

#6

Andy

Alfresco Employee

Stats

Posts: 1442
Achievements: 6
Member for: 7 years 11 months
From: London

Hi

Many thanks for your contribution. That is very helpful.

Do you know which versions of AD can be used?

Cheers

Andy

—

Andy Hind
Alfresco Development

Mon, 03/12/2007 - 16:58

#7

rhofkens

Alfresco Partner

Stats

Posts: 34
Achievements: 2
Member for: 6 years 8 months

I'm running my test environment on a Win2k3 Release 2.

The AD controller "Forest functional level" however, is set to "Windows 2000 mixed". This means that the configuration should work on all AD's starting from windows 2000 server.

Microsoft indicates that, when you raise the forest functional level to "Windows 2003 native" (easy to do via the Admin console, but only available on w2k3 of course), you should be able to authenticate with MD5 even when you're not using reversible encryption in your accounts. I'll give that a try as well. See http://technet2.microsoft.com/WindowsServer/f/?en/library/ad3c14d4-7495-441c-81f0-7cf1e368c56e1033.mspx.

Quote:

Digest Hashes

Digest Authentication verifies passwords by computing a hash of the account name, realm property, and password. The specific format is H(username:realm:password) where H() is the MD5 hash operation. As this form shows, the plaintext password is required to compute the MD5 hash. To use Digest Authentication in previous versions of Windows Server, reversible encryption has to be set on an account. This setting allows the security provider to compute the digest hash when it is authenticating a server request by using Digest Authentication. In Windows Server 2003, a new digest hash is created and stored in Active Directory when a password is modified on an account. This digest hash contains several pre-computed versions of the H(username:realm:password) hash and permits these hashes to be authenticated without requiring reversible encryption to be enabled on an account.

Cheers,

—

Roeland Hofkens
Chief ECM Consultant
Westernacher Products & Services
http://www.westernacher.com

Thu, 03/15/2007 - 14:41

#8

Andy

Alfresco Employee

Stats

Posts: 1442
Achievements: 6
Member for: 7 years 11 months
From: London

Hi

Thanks once again.

Cheers

Andy

—

Andy Hind
Alfresco Development

Tue, 11/27/2007 - 14:38

#9

tinaagrawal

Stats

Posts: 4
Achievements: 0
Member for: 5 years 7 months

I am able to successfully login using LDAP Authentication but the ldap properties are not getting mapped to repository properies.
Any Ideas?

<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="cm:organizationId">

                    <!-- OpenLDAP: "o" -->

                    <!-- Active Directory: "???" -->

                    <value>o</value>

                </entry>

                <!-- Always use the default -->

                <entry key="cm:homeFolderProvider">

                    <null/>

                </entry>

            </map>

</property>

I have pasted I portion of the xml file used for the mapping.

Thu, 01/10/2008 - 08:07

#10

Rubi

Stats

Posts: 10
Achievements: 1
Member for: 5 years 9 months

Hi,

Same problem here. Don't get the email adress over to the repository!

.
.

sAMAccountName

givenName

sn

mail

company

LDAP works fine and we are pretty happy with these synk, but...
From AD via LDAP only the Username har posted in repository and we should really have the email account exportet over.....

Tue, 02/12/2008 - 07:14

#11

Rubi

Stats

Posts: 10
Achievements: 1
Member for: 5 years 9 months

OK. solved this one.
To restrict personQuery: userAccountControl=512)

Tue, 10/18/2011 - 17:55

#12

Daddy87

Stats

Posts: 4
Achievements: 0
Member for: 1 year 8 months

Re: Active directory authentication

I have a problem with builtin admin account when integrating with AD.

All AD accounts properlly authenticate in Domain Controller however there is also a builtin account called ADMIN in Alfresco.
This account periodically tries to authenticate in AD (why ?).

Of course authentication fails for this account (it doesn't exist in AD). There are tons of "logon failures" in Security Log of Domain Controller.
I must avoid those failures.

Could you help me solve this issue ?

Thu, 10/20/2011 - 18:23

#13

roshan

Stats

Posts: 16
Achievements: 1
Member for: 2 years 3 months

Re: Active directory authentication

Everything works for me, the only thing that is lacking is NTLM passthru doesn't work on VPN. So if I am on the network and authenciated via AD, I am ok it takes me right in, if i am on VPN (since I haven't authenticated), it won't pass NTLM, any help?

Fri, 02/10/2012 - 11:09

#14

adanbarter

Stats

Posts: 1
Achievements: 0
Member for: 1 year 3 months

Re: Active directory authentication

Your thread is really fantastic about the active directory authentication. Actually I am looking online for Open Directory Ads. Actually I want to know that how Open Directory Ads can help in increasing site's traffic?

==========================
http://opendirectoryads.com/

Active directory authentication

You are here

Stats

Stats

Stats

Stats

Stats

Stats

Stats

Stats

Stats

Stats

Stats

Stats

Stats

Stats