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 authentication properties
javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=alfness,dc=com'
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.
com.sun.jndi.ldap.LdapReferralException: Continuation Reference; remaining name 'dc=alfness,dc=com'
For more information, see Referrals in the JNDI [9].
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.
%s@domain
cn=%s,ou=xyz,dc=domain
uid=%s,ou=People,dc=company,dc=com
%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.
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.
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
openssl s_client -connect ldap.foxpass.com:636 > my-ldap.crt
keytool -importcert -alias LDAP.HOST.FQDN -file my-ldap.crt -keystore my-keystore-filename -storepass my-pass -storetype JCEKS
The type of the truststore, as specified when generating with keytool or another keystore manager. Must be a standard Java Cryptography Keystore.
You can check which Simple Authentication and Security Layer (SASL) authentication mechanisms are supported.
ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedSASLMechanisms dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: NTLM supportedSASLMechanisms: CRAM-MD5
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.
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 |
authentication.chain=ldap1:ldap-ad
synchronization.externalUserControlSubsystemName=ldap1
ldap.synchronization.userAccountStatusProperty=pwdAccountLockedTime ldap.synchronization.disabledAccountPropertyValue=000001010000Z
ldap.synchronization.userAccountStatusProperty=ds-pwp-account-disabled ldap.synchronization.disabledAccountPropertyValue=true
ldap.synchronization.userAccountStatusProperty=nsAccountLock ldap.synchronization.disabledAccountPropertyValue=true
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 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.
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: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.
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.
Notice that attributes such as email address were populated automatically from Active Directory.
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).
authentication.chain=alfinst:alfrescoNtlm,ad1:ldap-ad,ad2:ldap-ad ntlm.authentication.sso.enabled=false
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
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.
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 ad2.
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
Links:
[1] https://docs.alfresco.com/auth-ldap-openldaptips.html
[2] https://docs.alfresco.com/../concepts/auth-ldap-props.html
[3] https://docs.alfresco.com/../tasks/auth-ldap-sasl.html
[4] https://docs.alfresco.com/../concepts/ldap-sync-user.html
[5] https://docs.alfresco.com/../tasks/auth-example-oneldap-ad.html
[6] https://docs.alfresco.com/../tasks/auth-example-twoldap-ad.html
[7] https://docs.alfresco.com/../concepts/auth-config-examples.html
[8] https://docs.alfresco.com/auth-ldap-ADtips.html
[9] http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html
[10] http://java.sun.com/javase/6/docs/technotes/guides/jndi/spec/jndi/properties.html#pgfId=999247
[11] http://java.sun.com/javase/6/docs/technotes/guides/jndi/jndi-ldap.html#SASL
[12] ftp://ftp.isi.edu/in-notes/rfc2831.txt
[13] https://docs.alfresco.com/../concepts/auth-ldap-intro.html
[14] https://support.microsoft.com/en-gb/kb/305144
[15] http://www.openldap.org/doc/admin24/overlays.html
[16] https://docs.alfresco.com/../tasks/auth-example-ldap-addemo.html