Configuring LDAP

An LDAP subsystem supports two main functions:

user authentication - checking a user's ID and password using an LDAP bind operation
user registry export - exposing information about users and groups to the synchronization subsystem

Either of these functions can be used in isolation or in combination. When LDAP authentication is used without user registry export, default Alfresco person objects are created automatically for all those users who successfully log in. However, they will not be populated with attributes without user registry export enabled. LDAP user registry export is most likely to be used without LDAP authentication when chained with other authentication subsystems. For example, Kerberos against Active Directory, pass-through against ActiveDirectory, and possibly Samba on top of OpenLDAP.

The user registry export function assumes that groups are stored in LDAP as an object that has a repeating attribute, which defines the distinguished names of other groups, or users. This is supported in the standard LDAP schema using the groupOfNames type. See the example LDIF file in OpenLDAP tips [1].

LDAP configuration properties

Both the ldap and ldap-ad subsystem types support the following configurable properties.

Note: The defaults for ldap are typical for OpenLDAP and Oracle Directory Server, and the defaults for ldap-ad are typical for Active Directory.

LDAP authentication properties

ldap.authentication.active

This Boolean flag, when true enables use of this LDAP subsystem for authentication. It might be that this subsystem should only be used for user registry export, in which case this flag should be set to false and you would have to chain an additional subsystem such as passthru or kerberos to provide authentication functions.

ldap.authentication.java.naming.referral

This property specifies how the referrals sent by AD in the search results are handled by Alfresco. The recommended values are:

ignore

If ldap.authentication.java.naming.referral=ignore, the following exception will be thrown when a referral is encountered:

javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=alfness,dc=com'

follow

If ldap.authentication.java.naming.referral=follow, Alfresco will automatically follow the referral. To be successful, make sure Alfresco can access the referred server. If this property has not been set, then the default is to follow the referrals.

throw

If ldap.authentication.java.naming.referral=throw, the following exception will be thrown:

com.sun.jndi.ldap.LdapReferralException: Continuation Reference; remaining name 'dc=alfness,dc=com'

For more information, see Referrals in the JNDI [9].

ldap.authentication.java.naming.security.authentication

The mechanism to use to authenticate with the LDAP server. This should be set to one of the standard values listed here or one of the values supported by the LDAP provider. Oracle's LDAP provider supports the following SASL mechanisms. The recommended values are:

simple: The basic LDAP authentication mechanism requiring the user name and password to be passed over the wire unencrypted. You might be able to add SSL for secure access, otherwise this should only be used for testing.
DIGEST-MD5: More secure RFC 2831 Digest Authentication. Note that with Active Directory, this requires your user accounts to be set up with reversible encryption, not the default setting.

ldap.authentication.java.naming.read.timeout

Specifies the read timeout in milliseconds for LDAP operations. If Alfresco cannot get a LDAP response within that period, it aborts the read attempt. The integer should be greater than zero. If the integer is less than or equal to zero, no read timeout is specified, which is equivalent to waiting for the response infinitely until it is received.

ldap.authentication.userNameFormat

Specifies how to map the user identifier entered by the user to that passed through to LDAP.

If set to an empty string (the default for the ldap subsystem), an LDAP query involving ldap.synchronization.personQuery and ldap.synchronization.userIdAttributeName will be performed to resolve the DN from the user ID dynamically. This allows directories to be structured and does not require the user ID to appear in the DN.

If set to a non-empty value, the substring %s in this value will be replaced with the entered user ID to produce the ID passed to LDAP. This restricts LDAP user names to a fixed format. The recommended format of this value depends on your LDAP server.

Active Directory

There are two alternatives:

User Principal Name (UPN)

These are generally in the format of <sAMAccountName>@<UPN Suffix>. If you are unsure of the correct suffix to use, use an LDAP browser, such as Softerra, to browse to a user account and find its userPrincipalName attribute. For example:

%s@domain

DN

This requires the user to authenticate with part of their DN, so might require use of their common name (CN) rather than their login ID. It also might not work with structured directory layouts containing multiple organization units (OUs). For example:

cn=%s,ou=xyz,dc=domain

OpenLDAP

The format used depends on the value chosen for ldap.authentication.java.naming.security.authentication.

simple

This must be a DN and would be something like the following:

uid=%s,ou=People,dc=company,dc=com

DIGEST-MD5

Use this value to pass through the entered value as-is:

%s

When authenticating against LDAP, users are not always in the same subtree of LDAP. In this situation, it is necessary to support authentication against multiple branches of LDAP. For example, some users who can authenticate using cn=%s,ou=myCity,ou=myState,o=myCompany but others can authenticate using cn=%s,ou=ANOTHERCity,ou=myState,o=myCompany. Set ldap.authentication.userNameFormat to be empty (the default), and then it will derive a query from your personQuery to look up a user by UID. This ensures that you can support users in any branch structure.

ldap.authentication.allowGuestLogin

Identifies whether to allow unauthenticated users to log in to Alfresco as the 'guest' user.

ldap.authentication.java.naming.factory.initial

The LDAP context factory to use. There is no need to change this unless you do not want to use the default Oracle LDAP context factory.

ldap.authentication.java.naming.provider.url

The URL to connect to the LDAP server, containing its name and port. The standard ports for LDAP are 389 (and 636 for SSL). For example: ldap://openldap.domain.com:389

ldap.authentication.escapeCommasInBind

Escape commas in the entered user ID when authenticating with the LDAP server? Useful when using simple authentication and the CN is part of the DN and contains commas.

ldap.authentication.escapeCommasInUid

Escape commas in the entered user ID when deriving an Alfresco internal user ID? Useful when using simple authentication and the CN is part of the DN and contains commas, and the escaped \, is pulled in as part of a synchronize operation. If this option is set to true it will break the default home folder provider as space names cannot contain \ (backslash character).

ldap.authentication.defaultAdministratorUserNames

A comma separated list of user names to be considered administrators by default. If you are using LDAP for all your users, this maps an LDAP user to be an administrator user. This administrator user can then configure the other admin users or groups by add users and/or groups to the ALFRESCO_ADMINISTRATORS group using the Share Admin Tools.

If you already have a group of administrators in LDAP, you can add the required LDAP group(s)to the ALFRESCO_ADMINISTRATORS group. This can be set without a server restart.

ldap.synchronization.active

This flag enables use of the LDAP subsystem for user registry export functions and decides whether the subsystem will contribute data to the synchronization subsystem. It might be that this subsystem should only be used for authentication, in which case this flag should be set to false.

ldap.synchronization.java.naming.security.authentication

The authentication mechanism used to connect to the LDAP server when performing user registry exports. In versions earlier than 3.4 versions, this property was the same as ldap.authentication.java.naming.security.authentication. The property should use one of the standard values covered in the Oracle documentation http://java.sun.com/javase/6/docs/technotes/guides/jndi/spec/jndi/properties.html#pgfId=999247 [10] or one of the values supported by the LDAP provider. Oracle's LDAP provider supports the SASL mechanisms documented in http://java.sun.com/javase/6/docs/technotes/guides/jndi/jndi-ldap.html#SASL [11]. Recommended values are:

none: Use this option if your LDAP server supports connection without a password. Set to none to allow synchronization by using anonymous bind (note that you will not also need to set the following two properties).
simple: This option is the basic LDAP authentication mechanism requiring the user name and password to be passed over the wire unencrypted. You might be able to add SSL for secure access; otherwise, use this option for testing only.
DIGEST-MD5: This option provides a more secure (RFC 2831 [12]) digest authentication. With Active Directory, this requires your user accounts to be set up with reversible encryption, not the default setting.

ldap.synchronization.java.naming.security.principal

The LDAP user to connect as for the export operation, if one is required by the ldap.synchronization.java.naming.security.authentication authentication mechanism. This should be in the same format as ldap.authentication.userNameFormat but with a real user ID instead of %s.

This is the default principal to use (only used for LDAP sync when ldap.synchronization.java.naming.security.authentication=simple): ldap.synchronization.java.naming.security.principal=cn\=Manager,dc\=company,dc\=com

ldap.synchronization.java.naming.security.credentials

The password for this user, if required. The password for the default principal (only used for LDAP sync when ldap.synchronization.java.naming.security.authentication=simple) ldap.synchronization.java.naming.security.credentials=secret

ldap.synchronization.queryBatchSize

If set to a positive integer, this property indicates that RFC 2696 paged results should be used to split query results into batches of the specified size. This overcomes any size limits imposed by the LDAP server. The default value of 1000 matches the default result limitation imposed by Active Directory. If set to zero or less, paged results will not be used.

ldap.synchronization.groupQuery

The query to select all objects that represent the groups to export. This query is used in full synchronization mode, which by default is scheduled every 24 hours.

ldap.synchronization.groupDifferentialQuery

The query to select objects that represent the groups to export that have changed since a certain time. Should use the placeholder {0} in place of a timestamp in the format specified by ldap.synchronization.timestampFormat. The timestamp substituted will be the maximum value of the attribute named by ldap.synchronization.modifyTimestampAttributeName the last time groups were queried. This query is used in differential synchronization mode, which by default is triggered whenever a user is successfully authenticated that does not yet exist in Alfresco.

ldap.synchronization.personQuery

The query to select all objects that represent the users to export. This query is used in full synchronization mode, which by default is scheduled every 24 hours.

ldap.synchronization.personDifferentialQuery

The query to select objects that represent the users to export that have changed since a certain time. Should use the placeholder {0} in place of a timestamp in the format specified by ldap.synchronization.timestampFormat. The timestamp substituted will be the maximum value of the attribute named by ldap.synchronization.modifyTimestampAttributeName the last time users were queried. This query is used in differential synchronization mode, which by default is triggered whenever a user is successfully authenticated that does not yet exist in Alfresco.

ldap.synchronization.groupSearchBase

The DN below which to run the group queries.

ldap.synchronization.userSearchBase

The DN below which to run the user queries.

ldap.synchronization.modifyTimestampAttributeName

The name of the operational attribute recording the last update time for a group or user.

ldap.synchronization.timestampFormat

The timestamp format. This varies between directory servers.

Active Directory: yyyyMMddHHmmss'.0Z'
OpenLDAP: yyyyMMddHHmmss'Z'

ldap.synchronization.userIdAttributeName

The attribute name on people objects found in LDAP to use as the uid in Alfresco.

ldap.synchronization.userFirstNameAttributeName

The attribute on person objects in LDAP to map to the first name property in Alfresco.

ldap.synchronization.userLastNameAttributeName

The attribute on person objects in LDAP to map to the last name property in Alfresco.

ldap.synchronization.userEmailAttributeName

The attribute on person objects in LDAP to map to the email property in Alfresco.

ldap.synchronization.userOrganizationalIdAttributeName

The attribute on person objects in LDAP to map to the organizational ID property in Alfresco.

ldap.synchronization.defaultHomeFolderProvider

The default home folder provider to use for people created using LDAP import.

ldap.synchronization.groupIdAttributeName

The attribute on LDAP group objects to map to the group name in Alfresco.

ldap.synchronization.groupType

The group type in LDAP. The default value is groupOfNames.

ldap.synchronization.personType

The person type in LDAP. The default value is inetOrgPerson. This value only need changing if the objectclass for mapping groups and users differs from the default provided by Alfresco. Check the documentation of the LDAP server being accessed.

ldap.synchronization.groupMemberAttributeName

The attribute in LDAP on group objects that defines the DN for its members.

ldap.authentication.java.naming.security.protocol

This sets the security protocol to use for connecting with the LDAP server. This property has a single value of ssl. Set this property to ssl if the configuration of truststore is required. Leave this property unused if the truststore configuration is not required (the connection is not secured).

Note: In order to enable SSL, import the SSL certificate from the LDAP provider into a Java truststore and the truststore.path, truststore.passphrase, and truststore.typeproperties. To download the certificate, use the following command:

openssl s_client -connect ldap.foxpass.com:636 > my-ldap.crt

To import the certificate into a new keystore, use the following command:

keytool -importcert -alias LDAP.HOST.FQDN -file my-ldap.crt -keystore my-keystore-filename -storepass my-pass -storetype JCEKS

ldap.authentication.truststore.path

The path to the truststore file on the file system.

ldap.authentication.truststore.passphrase

The password for the truststore.

ldap.authentication.truststore.type

The type of the truststore, as specified when generating with keytool or another keystore manager. Must be a standard Java Cryptography Keystore.

LDAP connection pooling configuration properties

ldap.synchronization.com.sun.jndi.ldap.connect.pool: Use this property to enable or disable connection pooling for synchronization.
ldap.pooling.com.sun.jndi.ldap.connect.pool.authentication: A list of space-separated authentication types of connections that may be pooled. Valid types are none, simple, and DIGEST-MD5.
ldap.pooling.com.sun.jndi.ldap.connect.pool.debug: A string that indicates the level of debug output to produce. Valid values are fine (trace connection creation and removal) and all (all debugging information).
ldap.pooling.com.sun.jndi.ldap.connect.pool.initsize: The string representation of an integer that represents the number of connections per connection identity to create when initially creating a connection for the identity.
ldap.pooling.com.sun.jndi.ldap.connect.pool.maxsize: The string representation of an integer that represents the maximum number of connections per connection identity that can be maintained concurrently. An empty value means no maximum size.
ldap.pooling.com.sun.jndi.ldap.connect.pool.prefsize: The string representation of an integer that represents the preferred number of connections per connection identity that should be maintained concurrently. An empty value means no preferred size.
ldap.pooling.com.sun.jndi.ldap.connect.pool.protocol: A list of space-separated protocol types of connections that may be pooled. Valid types are plain and ssl.
ldap.pooling.com.sun.jndi.ldap.connect.pool.timeout: The string representation of an integer that represents the number of milliseconds that an idle connection may remain in the pool without being closed and removed from the pool. # Empty value means no timeout, connection stays in pool forever. Bad connections are automatically detected and removed from the pool by the LDAP provider
ldap.pooling.com.sun.jndi.ldap.connect.timeout: The string representation of an integer that represents the number of milliseconds to specify how long to wait for a pooled connection. An empty value means the application will wait indefinitely.

Checking the supported SASL authentication mechanisms

You can check which Simple Authentication and Security Layer (SASL) authentication mechanisms are supported.

Using an LDAP browser, such as the one from Softerra, check the values of the supportedSASLMechanisms attributes on the root node of your LDAP server.

Note: The simple authentication method will not be reported because it is not a SASL mechanism.

If you use OpenLDAP, you can also query using ldapsearch. For example:

ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5

Synchronizing user account status

Use this information to synchronize the enabled or disabled user status property LDAP with Alfresco after an LDAP sync.

Different LDAP directories store data in different formats. For example, Active Directory has an attribute called userAccountControl where the second bit (0x2) is an ACCOUNTDISABLE flag [14], Oracle Directory Server has an attribute called pwdAccountLockedTime, and LDAP systems derived from Netscape Directory Server (NDS) have a nsAccountLock attribute.

The values of these attributes need to be mapped onto a boolean property on the cm:person node. To do this, configure the attributes as follows:

Open the <classpathRoot>/alfresco-global.properties file.

For all directory servers, add the following properties:

synchronization.externalUserControl=true
synchronization.externalUserControlSubsystemName=

Property Name	Description	Example
synchronization.externalUserControl	Specifies if the users can be enabled. It set to `true`, the enables or disabled user status can be synchronized from an LDAP directory. If set to `false` (default setting), the users have to be explicitly disabled in Alfresco.	`false`
synchronization.externalUserControlSubsystemName	Specifies the authentication subsystem that will handle the external user status.	`ldap1`

For all directory servers, the value of the synchronization.externalUserControlSubsystemName property must match the value from the authentication chain. For example, if your authentication chain looks like:

authentication.chain=ldap1:ldap-ad

then you need to set the synchronization.externalUserControlSubsystemName property as:

synchronization.externalUserControlSubsystemName=ldap1

For other LDAP implementations, you need to set two additional properties: ldap.synchronization.userAccountStatusProperty and ldap.synchronization.disabledAccountPropertyValue. To determine the name and the value of these properties see the specific LDAP implementation documentation.
For example:
- For OpenLDAP, add the following properties to the alfresco-global.properties file:
```
ldap.synchronization.userAccountStatusProperty=pwdAccountLockedTime
ldap.synchronization.disabledAccountPropertyValue=000001010000Z
```
  Note: Make sure you activate and configure the password policy (ppolicy) overlay. For more information, see Password Policies [15].
- For Oracle, add the following properties to the alfresco-global.properties file:
```
ldap.synchronization.userAccountStatusProperty=ds-pwp-account-disabled
ldap.synchronization.disabledAccountPropertyValue=true
```
- In addition to the above properties, for Netscape Directory Server systems (Oracle, Red Had, 389 DS), add the following properties to the alfresco-global.properties file:
```
ldap.synchronization.userAccountStatusProperty=nsAccountLock
ldap.synchronization.disabledAccountPropertyValue=true
```
  Note: The nsAccountLock attribute is an operational attribute and may require some additional configuration depending on the directory server used.

Example: authentication and synchronization with one ldap-ad subsystem

This example addresses the more advanced goal of delegating authentication responsibility to a centralized directory server. Most organizations maintain their user database in a directory server supporting the LDAP protocol, such as Active Directory or OpenLDAP.

When integrated with an LDAP server, Alfresco can delegate both the password checking and account setup to the LDAP server, thus opening up Alfresco to your entire enterprise. This avoids the need for an administrator to manually set up user accounts or to store passwords outside of the directory server.

To integrate Alfresco with a directory server, you simply need to include an instance of the ldap or ldap-ad subsystem types in the authentication chain. Both subsystem types offer exactly the same capabilities and should work with virtually any directory server supporting the LDAP protocol. Their only differences are the default values configured for their attributes. The ldap type is preconfigured with defaults appropriate for OpenLDAP, whereas ldap-ad is preconfigured with defaults appropriate for Active Directory.

There are two choices in this scenario: replace or add to the authentication chain.

Replace the authentication chain
You could remove alfinst from the previous example and instead add an instance of ldap-ad. This would hand over all authentication responsibility to Active Directory and would mean that the built-in accounts, such as admin and guest, could not be used.
In this scenario, it would be important to configure at least one user who exists in Active Directory as an administrator and enable the guest account in Active Directory, if guest access were required. Furthermore, because ldap-ad cannot support CIFS authentication (as it requires an MD5 password hash exchange), it would rule out use of the CIFS server for all users and the CIFS server would be disabled.
Add to the authentication chain
You could instead supplement the existing capabilities of alfinst by inserting an ldap-ad instance before or after alfinst in the chain. This means that you could use the built-in accounts alongside those accounts in the directory server. Furthermore, the built-in accounts could access Alfresco through the CIFS server, since alfrescoNtlm is able to drive CIFS authentication.
In this scenario, where you chose to position your ldap-ad instance in the chain determines how overlaps or collisions between user accounts are resolved. If an admin account existed in both Alfresco and Active Directory, then admin would be Alfresco if alfinst came first, or Active Directory if the ldap-ad instance came first.

This example uses an Active Directory server and configures an instance of the ldap-ad subsystem.

This example uses the second option to append an instance of ldap-ad to the authentication chain. This instance name is ldap1 and is declared by changing the authentication.chain property in the alfresco-global.properties file. In addition to the authentication.chain property, you need to add the ntlm.authentication.sso.enabled property to the alfresco-global.properties file.
Undo any previous modifications to alfinst and disable NTLM-based SSO.
This is done because the ldap-ad and ldap subsystem types cannot participate in the NTLM handshake, so leaving SSO enabled would prevent any of the Active Directory users from logging in.
Disable SSO by opening the alfresco-global.properties file in a text editor and editing the ntlm.authentication.sso. enabled property as follows:
```
authentication.chain=alfinst:alfrescoNtlm,ldap1:ldap-ad

ntlm.authentication.sso.enabled=false

ldap.authentication.allowGuestLogin=false
ldap.authentication.userNameFormat=%s@domain.com
ldap.authentication.java.naming.provider.url=ldap://domaincontroller.domain.com:389
ldap.authentication.defaultAdministratorUserNames=Administrator,alfresco
ldap.synchronization.java.naming.security.principal=alfresco@domain.com
ldap.synchronization.java.naming.security.credentials=secret
ldap.synchronization.groupSearchBase=ou=Security Groups,ou=Alfresco\
,dc=domain,dc=com

ldap.synchronization.userSearchBase=ou=User Accounts,ou=Alfresco,dc=domain,dc=com
```
There are a large number of configurable properties for ldap-ad, which demonstrates the flexibility of Alfresco’s LDAP infrastructure. Luckily, because ldap-ad already has sensible defaults configured for a typical Active Directory set up, there are only a few edits you must make to tailor the subsystem instance to your needs.
The following list is a summary of the settings that have been changed:
- ldap.authentication.allowGuestLogin — Enables / disables unauthenticated access to Alfresco
- ldap.authentication.userNameFormat — A template that defines how Alfresco user IDs are expanded into Active Directory User Principal Names (UPNs) containing a placeholder %s, which stands for the unexpanded user ID. A UPN generally consists of the user’s account ID followed by an @ sign and then the domain’s UPN suffix. You can check the appropriate UPN suffix for your domain by connecting to the directory with an LDAP browser, browsing to a user account, and looking at the value of the userPrincipalName attribute.
- ldap.authentication.java.naming.provider.url — An LDAP URL containing the host name and LDAP port number (usually 389) of your Active Directory server
- ldap.authentication.defaultAdministratorUserNames — A list of user IDs who should be given Alfresco administrator privileges by default. Another administrator can include more users as administrators by adding those users to the ALFRESCO_ADMINISTRATORS group.
- ldap.synchronization.java.naming.security.principal — The UPN for an account with privileges to see all users and groups. This account is used by Alfresco to retrieve the details of all users and groups in the directory so that it can synchronize its internal user and authority database. Passwords are never compromised and remain in the directory server.
- ldap.synchronization.java.naming.security.credentials — The password for the previous account
- ldap.synchronization.groupSearchBase — The Distinguished Name (DN) of the Organizational Unit (OU) below which security groups can be found. You can determine the appropriate DN by browsing to security groups in an LDAP browser.
- ldap.synchronization.userSearchBase — The distinguished name (DN) of the Organizational Unit (OU) below which user accounts can be found. You can determine the appropriate DN by browsing to user accounts in an LDAP browser.

Applying the ldap-ad example

This example demonstrates how you can further delegate authentication responsibility to Active Directory, without the automatic sign-on and CIFS browsing capabilities that are available to internal Alfresco users.

Restart the Alfresco server.

If you watch the output from Tomcat in the alfresco.log in the installation directory, you will eventually see lines similar to the following:

13:01:31,225 INFO  
[org.alfresco.repo.management.subsystems.ChildApplicationContextFactory] 
Starting 'Synchronization' subsystem, ID: [Synchronization, default]

…

13:01:49,084 INFO  
[org.alfresco.repo.security.sync.ChainingUserRegistrySynchronizer] 
Finished synchronizing users and groups with user registry 'ldap1'

13:01:49,084 INFO  
[org.alfresco.repo.security.sync.ChainingUserRegistrySynchronizer] 
177 user(s) and 19 group(s) processed

13:01:49,131 INFO  
[org.alfresco.repo.management.subsystems.ChildApplicationContextFactory] 
Startup of 'Synchronization' subsystem, ID: [Synchronization, default] complete

This is output is from the Synchronization subsystem, the Alfresco subsystem responsible for synchronizing the Alfresco internal user and authority database with all user registries in the authentication chain. Since the authentication chain now provides a user registry, the Synchronization subsystem has some work to do when Alfresco starts up.

From the example logs, notice that the Synchronization subsystem automatically created 177 users and 19 groups using attributes, such as email address and group memberships, retrieved from Active Directory through an LDAP query. This reduces the workload of the administrator user.

Note: The Synchronization subsystem uses an incremental timestamp-based synchronization strategy, meaning that it only queries for changes since the last synchronization run. So after the first start up, further synchronization runs can be almost instantaneous. Because synchronization runs are also triggered by a scheduled nightly job and whenever an unknown user successfully authenticates, you should find that Alfresco always stays synchronized with hardly any effort.
Now, if you enter the Alfresco URL: http://localhost:8080/share/ into your browser, you can log in using the ID and password of any of the Active Directory users.

Important: Passwords are validated through an LDAP bind operation on Active Directory in real time. Passwords for Active Directory users are not stored locally.
Navigate to a user profile.
Notice that attributes such as email address were populated automatically from Active Directory.

Example: authentication and synchronization with two ldap-ad subsystems

This example uses one Active Directory server and shows authentication as well as user registry export (synchronization) from two ldap-ad subsystems.

The two ldap-ad subsystems used are ad1 and ad2. Both these subsystems use the same Active Directory server but different locations within it (search bases).

Add the following properties to the alfresco-global.properties file.

authentication.chain=alfinst:alfrescoNtlm,ad1:ldap-ad,ad2:ldap-ad
ntlm.authentication.sso.enabled=false

Create the properties files to configure ad1:

mkdir <installLocation>\tomcat\shared\classes\alfresco\extension\subsystems\
Authentication\ldap-ad\ad1

cd /d <installLocation>\tomcat\shared\classes\alfresco\extension\subsystems\
Authentication\ldap-ad\ad1

copy <installLocation>\tomcat\webapps\alfresco\WEB-INF\classes\alfresco\subsystems\
Authentication\ldap-ad\*.properties

A single file called ldap-ad-authentication.properties now appears in the ad1 directory. You can edit this file to define your LDAP set up.

The following lines show the set of properties you will typically need to edit and how you might set them for a domain controller for a fictitious domain called domain.com for ldap-ad subsystem ad1.

ldap.authentication.allowGuestLogin=false
ldap.authentication.userNameFormat=%s@domain.com
ldap.authentication.java.naming.provider.url=ldap://domaincontroller.domain.com:389
ldap.authentication.defaultAdministratorUserNames=Administrator,alfresco
ldap.synchronization.java.naming.security.principal=alfresco@domain.com
ldap.synchronization.java.naming.security.credentials=secret
ldap.synchronization.groupSearchBase=ou=ad1,ou=Alfresco\
,dc=domain,dc=com
ldap.synchronization.userSearchBase=ou=ad1,ou=Alfresco,dc=domain,dc=com

Create the properties files to configure ad2:

mkdir <installLocation>\tomcat\shared\classes\alfresco\extension\subsystems\
Authentication\ldap-ad\ad2

cd /d <installLocation>\tomcat\shared\classes\alfresco\extension\subsystems\
Authentication\ldap-ad\ad2

copy <installLocation>\tomcat\webapps\alfresco\WEB-INF\classes\alfresco\subsystems\
Authentication\ldap-ad\*.properties

A single file called ldap-ad-authentication.properties now appears in your ad2 directory. You can edit this file to define your LDAP set up.

ldap.authentication.allowGuestLogin=false
ldap.authentication.userNameFormat=%s@domain.com
ldap.authentication.java.naming.provider.url=ldap://domaincontroller.domain.com:389
ldap.authentication.defaultAdministratorUserNames=Administrator,alfresco
ldap.synchronization.java.naming.security.principal=alfresco@domain.com
ldap.synchronization.java.naming.security.credentials=secret
ldap.synchronization.groupSearchBase=ou=ad2,ou=Alfresco\
,dc=domain,dc=com
ldap.synchronization.userSearchBase=ou=ad2,ou=Alfresco,dc=domain,dc=com