Alfresco Authentication Subsystems

From AlfrescoWiki

Jump to: navigation, search


Contents

[edit] Introduction

This page describes how to configure authentication in Alfresco versions 3.2 and greater. In version 3.2, this area underwent a major reorganization with the goals of:

  • simplifying the configuration of the most common types of authentication
  • allowing you to easily 'mix and match' different types of authentication
  • clearly separating configuration from product
  • consistently using a single simple configuration mechanism

What emerged were the Authentication Subsystems described on this page.

This page now replaces the following pages. Refer to these pages only if you are configuring authentication in Alfresco versions prior to 3.2:

[edit] What is an Authentication Subsystem?

An authentication subsystem is a coordinated stack of compatible components responsible for providing authentication-related functionality to Alfresco. Alfresco offers multiple alternative implementations of authentication subsystem, each engineered to work with one of the different types of back-end authentication server that you may have available in your enterprise.

Authentication is just one of the many Alfresco subsystems introduced in version 3.2. The subsystem pattern lends itself particularly well to the world of authentication. In contrast with earlier releases:

  • Subsystems for all supported authentication types are pre-wired and there is no need to edit template configuration.
  • There is no danger of compatibility issues between sub-components, as these have all been pre-selected for you. For example, your CIFS authenticator and authentication filter is compatible with your authentication component.
  • Common parameters are shared and specified in a single place. There is no need to specify the same parameters to different components in multiple configuration files.
  • There is no need to edit web.xml. web.xml now uses generic filters that call into the authentication subsystem. The alfresco.war file is now a more portable unit of deployment.
  • You can easily swap from one type of authentication to another by activating a different authentication subsystem.
  • Your authentication configuration remains standard and will be a 'known quantity' for Alfresco support and other Alfresco experts.
  • Authentication subsystems are easily chained.

[edit] What are the Authentication Subsystems?

The following table lists the Authentication subsystem types supplied with Alfresco and the optional features they support. Note that if you configure a single authentication subsystem of a type that doesn't support CIFS authentication (such as ldap), the CIFS server will automatically be disabled. If you want CIFS and LDAP, you add more than one subsystem to the authentication chain. Refer to The Alfresco Authentication Chain for more detail. For further information on each of these subsystem types and the configuration options they support, refer to the corresponding section in the Authentication Subsystem Reference.

Type Description Single Sign-On (SSO) ? CIFS Authentication? User Registry Export?
alfrescoNtlm Native Alfresco authentication Yes, NTLM Yes No
ldap Authentication and user registry export via the LDAP protocol (e.g. OpenLDAP) No No Yes
ldap-ad Authentication and user registry export from Active Directoy via the LDAP protocol No No Yes
passthru Authentication via a Windows domain server Yes, NTLM (v1 only) Yes No
kerberos Authentication via a Kerberos Realm Yes, SPNEGO Yes No
external Authentication via an external SSO mechanism Yes No No

[edit] What's in an Authentication Subsystem?

The main components of an authentication subsystem are:

An authentication component
Handles the specifics of talking to the back-end authentication system.
An authentication Data Access Object (DAO)
Decides what user management functions are allowed, if any (such as the ability to create a user).
An authentication service
Wraps the authentication component and DAO with higher-level functions. Refer to The Authentication Service for more detail.
A user registry export service (optional)
Exposes information about users and groups to the Synchronization Subsystem
Authentication Filters
Provide form or SSO-based login functions for
  • Web Client
  • Web DAV
  • Web Scripts
  • SharePoint Protocol
File server authenticators
Provide authentication functions for
  • CIFS protocol (optional)
  • FTP protocol

[edit] The Alfresco Authentication Chain

It's very likely that at least one of the authentication subsystem types would allow you to integrate Alfresco with one of the authentication servers in use in your enterprise. However, integrating Alfresco with just one of these systems may not be enough; for various reasons you might want to 'mix and match' multiple authentication protocols against a collection of servers.

For this reason, Alfresco has a built-in authentication chain. In simple terms, this is a priority-ordered list of authentication subsystem instances. Alfresco composes together the functions of the subsystems in this list into a more powerful conglomerate.

[edit] Authentication Functions

The functions of the chain are composed in two different ways.

[edit] Chained Functions

Chained functions combine functions of more than one subsystem in the chain together.

For example, when a user logs in, Alfresco tries the user's credentials against each of the subsystems in the chain in the order specified.

  • If a chain member accepts the credentials, the login succeeds.
  • If no chain member accepts, the login fails.

User registry export is also chained. During a synchronize operation, users and groups are exported from each member of the chain supporting user registry export (such as those of type ldap or ldap-ad) and imported into Alfresco. Ordering in the chain is used to resolve 'collisions' between users and groups existing in the same directory. Refer to The Synchronization Subsystem for more detail.

[edit] Passthru functions

These functions cannot be chained and instead pass through to a single member of the chain, which handles them directly.

Examples of passthru functions are:

  • NTLM / SPNEGO - based Single Sign-On (SSO)
  • CIFS Authentication

Such passthu functions are handled by the first member of the chain that supports that function and has it enabled. This means that only a subset of your user base may be able to use SSO and CIFS.

[edit] The Default Authentication Chain

The default product configuration has a simple chain with one member. This is an instance of the alfrescoNtlm subsystem type with ID alfrescoNtlm1.

This is expressed in the built-in defaults (in repository.properties) as: 

authentication.chain=alfrescoNtlm1:alfrescoNtlm

To configure the properties of alfrescoNtlm1, you can use one of the methods described in Configuring Subsystems.

This subsystem instance does not have SSO enabled by default.

To switch from password-based login to NTLM-based SSO, set the following property (in alfresco-global.properties or using JMX). 

ntlm.authentication.sso.enabled=true

Note: You do not need to change web.xml, unlike previous versions of Alfresco.

This basic use of NTLM requires Alfresco to store its own copies of your MD4 password hash, which means your user ID and password must be the same in both Alfresco and your Windows domain. For direct authentication with a Windows domain server without the need to synchronize accounts in Alfresco and the domain, see the passthru subsystem type.

[edit] Configuring the Authentication Chain

You can easily add to or completely replace the default authentication chain.

The chain is controlled by the special authentication.chain global property.

This is a comma separated list of the form: 

instance_name1:type1,...,instance_namen:typen

So, for example, if you set this property to the following value, by navigating to the Alfresco:Type=Configuration,Category=Authentication,id1=manager MBean in JConsole for the Enterprise version, or using one of the methods described in Global Property Overrides 

alfrescoNtlm1:alfrescoNtlm,ldap1:ldap

then a new authentication subsystem instance called ldap1 is created and added to the end of the authentication chain.

You can then configure values for the various properties of alfrescoNtlm1 and ldap1 as in Configuring Subsystems.

[edit] Example 1: Advanced AD Chain

If you want to integrate Alfresco with Active Directory with the following requirements:

  • Built-in Alfresco users and Windows users should be able to log in, with Alfresco taking precedence
  • The Windows domain server should handle CIFS authentication directly
  • LDAP should be used to synchronize user and group details

Configure the following authentication chain: 

alfrescoNtlm1:alfrescoNtlm,passthru1:passthru,ldap1:ldap-ad

You then deactivate SSO in order to activate chained password-based login, target CIFS at passthru1 and target synchronization (but not authentication) at ldap1. Set the properties using JMX as follows:

alfrescoNtlm1
ntlm.authentication.sso.enabled=false
alfresco.authentication.authenticateCIFS=false
passthru1
ntlm.authentication.sso.enabled=false
passthru.authentication.authenticateCIFS=true
ldap1
ldap.authentication.active=false
ldap.synchronization.active=true

Note 1: Although it is easy to chain authentication subsystems, not all protocols can be chained. For instance, in the requirement of the example, you authenticated CIFS against the AD server. Having a failover mechanism that tries first Alfresco database and then asks the AD server if that fails does not work. This is because CIFS authentication using NTLM protocol, which is a challenge-response protocol, and the client won't do two authentication attempts in a chain. In other words, you cannot have the following at the same time: 

alfresco.authentication.authenticateCIFS=true

and 

passthru.authentication.authenticateCIFS=true

Only one of the two can be set to 'true'.

Note 2:: One can turn on SSO on one of the auth components for instance passthru, to get the following set of parameters values:

alfrescoNtlm1
ntlm.authentication.sso.enabled=false
alfresco.authentication.authenticateCIFS=false
passthru1
ntlm.authentication.sso.enabled=true
passthru.authentication.authenticateCIFS=true
ldap1
ldap.authentication.active=false
ldap.synchronization.active=true

That way, SSO is given to AD users. Local (AlfrescoNtlm) users will still be able to login, but they will need to login using a (backdoor) URL: http://localhost:8080/alfresco/faces/jsp/login.jsp where the login form is displayed, even when when SSO is turned on.

[edit] Example 2: Advanced LDAP Chain

You want to integrate Alfresco with two LDAP directories with the following requirements:

  • User passwords should be validated directly against the LDAP servers for web, Sharepoint and FTP login
  • The CIFS server should be deactivated, since neither server can handle CIFS-style authentication
  • LDAP should be used to synchronize user and group details from both directories
  • Users in the first directory, ldap1, should take precedence over those in the second directory, ldap2
  • We want to use file-based configuration methods rather than JMX

For this, use the mechanism described in Alfresco Subsystems to configure different property sets for the two LDAP subsystem instances. (Note this currently requires a recent Alfresco Community nightly build or the Enterprise Edition.)

Include the following in alfresco-global.properties: 

authentication.chain=ldap1:ldap,ldap2:ldap

Then copy $TOMCAT_HOME/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/Authentication/ldap/ldap-authentication.properties to 

$TOMCAT_HOME/shared/classes/alfresco/extension/subsystems/Authentication/ldap/ldap1/ldap-authentication.properties

and 

$TOMCAT_HOME/shared/classes/alfresco/extension/subsystems/Authentication/ldap/ldap2/ldap-authentication.properties

You can then edit the properties for ldap1 and ldap2 as required to complete the configuration. Use the LDAP Configuration section as a reference for each of the properties.

[edit] Authentication Subsystem Reference

The following sections provide a detailed reference guide to configuring and using each of the authentication subsystems. Thanks to the many people who have contributed and continue to contribute to the body of wisdom in these sections.

[edit] AlfrescoNtlm

alfrescoNtlm is the subsystem configured by default in the Alfresco Authentication Chain. It performs authentication based on user and password information stored in the Alfresco repository. It is capable of supporting both form-based login and NTLM-based Single Sign-On (SSO) as well as providing authentication for the CIFS server.

Note that by default the NTLM SSO functions are disabled by default, thus not making any assumptions about the availability of a Windows Domain. However, activating SSO only requires the editing of a single property (see Configuration) and no longer requires any changes to web.xml or futher file server configuration as in earlier Alfresco versions.

Note that this subsystem has nothing to do with Active Directory or LDAP! A better way to think of it is simply as the Alfresco native authentication subsystem that happens to support CIFS (via NTLM).

[edit] NTLM

The alfrescoNtlm subsystem supports optional NTLM Single Sign-On (SSO) functions for WebDav and the Alfresco Explorer client. Note that since Alfresco 3.0, NTLM v2 is supported which is more secure that the NTLM v1 previously supported. NTLMv2 will automatically downgrade to NTLMv1 if the client does not support it.

By using NTLM authentication to access Alfresco Explorer and Alfresco WebDAV sites the web browser can automatically log in.

Internet Explorer will use your Windows logon credentials when requested by the web server when SSO is enabled. Firefox and Mozilla also support the use of NTLM but you need to add the URI to the Alfresco site that you want to access to network.automatic-ntlm-auth.trusted-uris option (available through writing about:config in the URL field) to allow the browser to use your current credentials for login purposes.

The Opera web browser does not currently support NTLM authentication, the browser is detected and will be sent to the usual Alfresco logon page.

Note in this configuration, Alfresco must still store its own copy of your MD4 password hash. In order to remove this need and authenticate directly with a Windows domain controller, consider the Passthru subsystem.

[edit] Configuration

The alfrescoNtlm subsystem supports the following properties. See Configuring Subsystems for how to configure these.

ntlm.authentication.sso.enabled
A Boolean that when true enables NTLM based Single Sign On (SSO) functionality in the Web clients. When false and no other members of the authentication chain support SSO, password-based login will be used.
ntlm.authentication.mapUnknownUserToGuest
Should unknown users automatically be logged on as the Alfresco guest user during Single Sign-On (SSO)?
ntlm.authentication.browser.ticketLogons (new in v3.3 SP3)
Can a ticket parameter in the request URL be used to authenticate with the Alfresco Explorer application? Default is true. Note that WebDAV URLs always accept ticket parameters.
alfresco.authentication.authenticateCIFS
A Boolean that when true enables Alfresco-internal authentication for the CIFS server. When false and no other members of the authentication chain support CIFS authentication, the CIFS server will be disabled.
alfresco.authentication.allowGuestLogin
Should we allow guest access to Alfresco?

[edit] Alfresco Share SSO using NTLM

The Alfresco Share application exists as an entirely separate web application to the main Alfresco Repository/Explorer WAR file. It can run in the same app-server instance on the same machine to the main Alfresco web application or can run on a completely separate app-server instance on a completely different machine altogether. The Share application uses HTTP(S) to communicate with the configured Alfresco Repository. Therefore, to use NTLM with Share, you must first enable SSO for the alfrescoNtlm or passthru subsystem, then edit the Share application web.xml file in the WEB-INF folder and change the servlet filter that is used. Enable the following servlet filter: 

  <filter>
     <filter-name>Authentication Filter</filter-name>
     <filter-class>org.alfresco.web.site.servlet.NTLMAuthenticationFilter</filter-class>
     <init-param>
        <param-name>endpoint</param-name>
        <param-value>alfresco</param-value>
     </init-param>
  </filter>

Then add the following filter mappings: 

  <filter-mapping>
     <filter-name>Authentication Filter</filter-name>
     <url-pattern>/page/*</url-pattern>
  </filter-mapping>
  
  <filter-mapping>
     <filter-name>Authentication Filter</filter-name>
     <url-pattern>/p/*</url-pattern>
  </filter-mapping>
  
  <filter-mapping>
     <filter-name>Authentication Filter</filter-name>
     <url-pattern>/s/*</url-pattern>
  </filter-mapping>

Note: The NTLM settings should already be in the web.xml file in a commented out section. Use the settings that are present in your web.xml as they may differ slightly from those above depending on the Alfresco version you have installed.

Finally, you need to make a configuration change to the Share application. The Share web application supports overriding of application config files in a very similar way to the Alfresco Explorer web client. To use NTLM with Share, find the .sample configuration override file for your version:

for 3.2 

\tomcat\shared\classes\alfresco\web-extension\webscript-framework-config-custom.xml.sample

for 3.3 

\tomcat\shared\classes\alfresco\web-extension\share-config-custom.xml.sample

Copy and rename the file to:

for 3.2 

\tomcat\shared\classes\alfresco\web-extension\webscript-framework-config-custom.xml

for 3.3 

\tomcat\shared\classes\alfresco\web-extension\share-config-custom.xml

Then edit the file and uncomment this section as appropriate for your version:

for 3.2 

	<!-- Overriding endpoints to reference an Alfresco server with NTLM filter enabled -->
	<!-- NOTE: the NTLM Authentication Filter must be enabled for both repository and web-tier web.xml -->
	<!-- NOTE: if utilising a load balancer between web-tier and repository cluster, the "sticky -->
	<!--       sessions" feature of your load balancer must be used when NTLM filter is active -->
	<config evaluator="string-compare" condition="Remote">
		<remote>
         
			<connector>
				<id>alfrescoCookie</id>
				<name>Alfresco Connector</name>
				<description>Connects to an Alfresco instance using cookie-based authentication</description>
				<class>org.alfresco.connector.AlfrescoConnector</class>
			</connector>

			<endpoint>
				<id>alfresco</id>
				<name>Alfresco - user access</name>
				<description>Access to Alfresco Repository WebScripts that require user authentication</description>
				<connector-id>alfrescoCookie</connector-id>
				<endpoint-url>http://localhost:8080/alfresco/wcs</endpoint-url>
				<identity>user</identity>
				<external-auth>true</external-auth>
			</endpoint>
			
		</remote>
	</config>

for 3.3 

   <!-- 
        NTLM authentication config for Share
        NOTE: you will also need to enable the NTLM authentication filter in Share web.xml
              change localhost:8080 below to appropriate alfresco server location if required
   -->
   <config evaluator="string-compare" condition="Remote">
      <remote>
         <connector>
            <id>alfrescoCookie</id>
            <name>Alfresco Connector</name>
            <description>Connects to an Alfresco instance using cookie-based authentication</description>
            <class>org.springframework.extensions.webscripts.connector.AlfrescoConnector</class>
         </connector>
         
         <endpoint>
            <id>alfresco</id>
            <name>Alfresco - user access</name>
            <description>Access to Alfresco Repository WebScripts that require user authentication</description>
            <connector-id>alfrescoCookie</connector-id>
            <endpoint-url>http://localhost:8080/alfresco/wcs</endpoint-url>
            <identity>user</identity>
            <external-auth>true</external-auth>
         </endpoint>
      </remote>
   </config>

Note: Change the endpoint-url value to point to your Alfresco Server location.

Now restart the Share web application. If you have configured alfrescoNtlm or passthru in your Alfresco authentication chain and enabled SSO, NTLM will now be the active authentication mechanism.

[edit] 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

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, passthru against Active Directory 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.

[edit] Configuration

Both the ldap and ldap-ad subsystem types support the following configurable properties. See Configuring Subsystems for how to configure these. Defaults for ldap are typical for Open LDAP and defaults for ldap-ad are typical for Active Directory.

ldap.authentication.active
This Boolean flag, when true, enables use of this LDAP subsystem for authentication. It may be that this subsytem 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.security.authentication
The mechanism used to validate passwords with the LDAP server. Should be one of the standard values documented here or one of the values supported by the LDAP provider. Sun's LDAP provider supports the SASL mechanisms documented here. Recommended values are:
simple
the basic LDAP authentication mechanism requiring the username and password to be passed over the wire unencrypted. You may be able to add SSL for secure access; otherwise, only use this 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.userNameFormat
How to map the user id entered by the user to that passed through to LDAP. The substring %s in this value will be replaced with the entered user ID to produce the ID passed to LDAP. The recommended value of this setting depends on your LDAP server.
Active Directory
You have two alternatives:
User Principal Name (UPN)
These are generally in the format of <sAMAccountName>@<UPN Suffix>. Official documentation can be found here. 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 may require use of their common name (CN) rather than their login ID. It also may not work with structured directory layouts containing multipe 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 above.
simple
This must be a DN and would be something like
uid=%s,ou=People,dc=company,dc=com
DIGEST-MD5
Use this value to pass through the entered value as-is:
%s
ldap.authentication.allowGuestLogin
Should we allow unauthenticated users to log in to Alfresco as 'guest'?
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 Sun 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 \.
ldap.authentication.defaultAdministratorUserNames
A comma separated list of user names who should be considered administrators by default
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 may 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. Note this property is new in v3.4 and in previous versions it was the same as ldap.authentication.java.naming.security.authentication. Should be one of the standard values documented here or one of the values supported by the LDAP provider. Sun's LDAP provider supports the SASL mechanisms documented here. Recommended values are:
none
your LDAP server may support connection without a password. This is known as anonymous bind.
simple
the basic LDAP authentication mechanism requiring the username and password to be passed over the wire unencrypted. You may be able to add SSL for secure access; otherwise, only use this 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.synchronization.java.naming.security.principal
The LDAP user to connect as to do the export operation, if one is required by the above authentication mechanism.
ldap.synchronization.java.naming.security.credentials
The password for this user, if required.
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.attributeBatchSize
If set to a positive integer, this property indicates that range retrieval should be used to fetch multi-valued attributes (such as member) in batches of the specified size. Overcomes any size limits imposed by Active Directory.
ldap.synchronization.groupQuery
The query to select all objects that represent the groups to export. This query is used in 'full sync mode', which by default is scheduled every 24 hours. See The Synchronization Subsystem.
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 sync mode', which by default is triggered whenever a user is successfully authenticated that does not yet exist in Alfresco. See The Synchronization Subsystem.
ldap.synchronization.personQuery
The query to select all objects that represent the users to export. This query is used in 'full sync mode', which by default is scheduled every 24 hours. See The Synchronization Subsystem.
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 sync mode', which by default is triggered whenever a user is successfully authenticated that does not yet exist in Alfresco. See The Synchronization Subsystem.
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. Unfortunately, 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 email property in Alfresco.
ldap.synchronization.defaultHomeFolderProvider
The default home folder provider to use for people created via LDAP import. See Security_and_Authentication#Creating_home_spaces_-_from_1.4_onwards.
ldap.synchronization.groupIdAttributeName
The attribute on LDAP group objects to map to the authority name in Alfresco.
ldap.synchronization.groupDisplayNameAttributeName
The attribute on LDAP group objects to map to the authority display name property in Alfresco (v3.3+)
ldap.synchronization.groupType
The group type in LDAP.
ldap.synchronization.personType
The person type in LDAP
ldap.synchronization.groupMemberAttributeName
The name of the multi-valued attribute on an LDAP group object that lists its members. If the value of this attribute parses as a Distinguished Name (DN) then the exporter will resolve the member name and type by looking up that DN, determining its object class (user or group) and getting the appropriate name attribute. This strategy will work with the groupOfNames class, for example. Otherwise, the attribute value is assumed to contain a user ID. This strategy will work with the posixGroup class, for example.

[edit] How do I find out what Simple Authentication and Security Layer (SASL) authentication mechanisms my LDAP server supports?

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 as it is not a SASL mechanism.

If you use OpenLDAP, you can also query using ldapsearch: 

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

[edit] OpenLDAP Tips

[edit] Sample Configuration

Here is a sample configuration file.

There are a number of things to note:

  • The maximum number of results returned has been increased from the default of 500 that even applies to paged results. See the OpenLDAP documentation on limits. If you have more than 500 users or groups this would be an issue.
  • Digest authentication has been configured to map from a user ID to the corresponding distinguished name. See the example data.
  • Passwords are in clear text (so that any authentication mechanism can be used). It is possible they can be in the correct hashed form for the MD5 digest to work. 
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include		/usr/local/etc/openldap/schema/core.schema
include		/usr/local/etc/openldap/schema/cosine.schema
include		/usr/local/etc/openldap/schema/inetorgperson.schema


# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral	ldap://root.openldap.org

pidfile		/usr/local/var/run/slapd.pid
argsfile	/usr/local/var/run/slapd.args

# Load dynamic backend modules:
# modulepath	/usr/local/libexec/openldap
# moduleload	back_bdb.la
# moduleload	back_ldap.la
# moduleload	back_ldbm.la
# moduleload	back_passwd.la
# moduleload	back_shell.la

# Sample security restrictions
#	Require integrity protection (prevent hijacking)
#	Require 112-bit (3DES or better) encryption for updates
#	Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#	Root DSE: allow anyone to read it
#	Subschema (sub)entry DSE: allow anyone to read it
#	Other DSEs:
#		Allow self write access
#		Allow authenticated users read access
#		Allow anonymous users to authenticate
#	Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#	by self write
#	by users read
#	by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# BDB database definitions
#######################################################################

database	bdb
suffix		"dc=company,dc=com"
rootdn		"cn=Manager,dc=company,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# This is secret ....
rootpw          {SSHA}u9AUUYOSVX6idlXcwyYOAG6G84oHFpvG
# The database directory MUST exist prior to running slapd AND 
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory	/usr/local/var/openldap-data
# Indices to maintain
index	objectClass	eq

# Clear text to allow hashing 
password-hash	{CLEARTEXT}


# SASL mappings for md5 digest authentication
# Extract the user id and use as the search key

authz-regexp
   uid=([^,]*),cn=digest-md5,cn=auth
   ldap:///dc=company,dc=com??one?(uid=$1)

authz-regexp
   uid=([^,]*),cn=company.com,cn=digest-md5,cn=auth
   ldap:///dc=company,dc=com??one?(uid=$1)

# Tweaks to increase the result set size and max query time

sizelimit 50000
timelimit 3600
[edit] Sample Data

Here is a very simple example LDIF file that defines People and Groups Organizational units and some example users and groups. 


# Initial directory contents
dn: dc=company,dc=com
dc: company
objectClass: top
objectClass: domain

dn: ou=People,dc=company,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Groups,dc=company,dc=com
ou: Groups
objectClass: top
objectClass: organizationalUnit

dn: uid=fullname,ou=People,dc=company,dc=com
objectclass: inetOrgPerson
sn: Name
cn: Full Name
userPassword: inClearText
telephoneNumber: 1234567890
uid: fullname
givenName: Full
mail: full.name@company.com
o: Company Software Inc.

dn: uid=walrus,ou=People,dc=company,dc=com
objectclass: inetOrgPerson
sn: Rus
cn: Wal Rus
userPassword: inClearText
telephoneNumber: 1234567890
uid: walrus
givenName: Wal
mail: wal.rus@company.com
o: Company Software Inc.

dn: cn=Group One,ou=Groups,dc=company,dc=com
objectclass: groupOfNames
cn: Group One
member: uid=fullname,ou=People,dc=company,dc=com 

dn: cn=Group Two,ou=Groups,dc=company,dc=com
objectclass: groupOfNames
cn: Group Two
member: cn=Group One,ou=Groups,dc=company,dc=com 
member: uid=walrus,ou=People,dc=company,dc=com


[edit] Active Directory Tips

  • You may need to give special permissions in the Active Directory to the account that you are using to do the LDAP bind (as configured in ldap.synchronization.java.naming.security.principal). To do this, open Active Directory Users and Computers, right click on the domain, and select "Delegate Control..." Click "Next", then select the user that you are using for the LDAP bind and click "Next". The permission that they will need is on the next screen "Read all inetOrgPerson information."
  • The example URL in ldap.authentication.java.naming.provider.url does not use SSL. SSL is recommended for production systems. You'll need to switch the port from 389 (below, non-SSL) to 636 for SSL.
  • It is often helpful to screen out non-user accounts and disabled accounts. The default user queries in the ldap-ad subsystem type do this by checking bit fields on the userAccountControl attribute. For example: 
userAccountControl:1.2.840.113556.1.4.803:=512

[edit] Passthru

[edit] Introduction

The passthru subsystem can be used to replace the standard Alfresco user database with a Windows server/domain controller, or list of servers, to authenticate users accessing Alfresco. This saves having to create user accounts within Alfresco. The subsystem also supports optional NTLM Single Sign-On (SSO) functions for WebDav and the Alfresco Explorer and Share clients and direct CIFS authentication for the CIFS server. This method of authentication is much more secure than simple LDAP-based authentication or form-based authentication.

Note that only NTLM v1 is supported in this configuration. As NTLMv2 has been designed to avoid "man-in-the-middle" attacks, it would be impossible to use in this 'pass through' style.

[edit] Configuration

The passthru subsystem supports the following properties. See Configuring Subsystems for how to configure these. Also relevant are the configuration steps described in Alfresco Share SSO using NTLM if you want to enable NTLM-based Single Sign-On (SSO) for the Alfresco Share client.

[edit] Domain level properties

The following properties control the set of domain controllers used for authentication. The three properties are mutually exclusive. For example, to set the passthru.authentication.servers property, set passthru.authentication.domain to be empty and passthru.authentication.useLocalServer to be false.

passthru.authentication.useLocalServer
A Boolean that when true inidicates that the local server should be used for passthru authentication by using loopback connections into the server.
passthru.authentication.domain
Sets the domain to use for passthru authentication. This will attempt to find the domain controllers using a network broadcast. Make sure that you use the Windows NetBIOS domain name, not the forest name. The network broadcast does not work in all network configurations. In this case use the passthru.authentication.servers property to specify the domain controller list by name or address.
passthru.authentication.servers
A comma delimited list of server names or addresses that are used for authentication. The passthru authenticator will load balance amongst the available servers, and can monitor server online/offline status.
  • Each server name/address may be prefixed with a domain name using the format <domain>\<server>. If specifying this in alfresco-global.properties, remember that the backslash character must be escaped. For example
passthru.authentication.servers=DOMAIN1\\host1.com,DOMAIN2\\host2.com,host1.com
  • If the client specifies a domain name in its logon request then the appropriate server will be used for the authentication. Domain mappings may also be specified to route authentication requests to the appropriate server (see below).
  • If a server handles authentication for multiple domains then multiple entries can be added in the server list prefixed with each domain name.
  • There should be at least one entry in the server list that does not have a domain prefix, this is the catch all entry that will be used if the client domain cannot be determined from the NTLM request or via domain mapping.
[edit] Other properties
ntlm.authentication.sso.enabled
A Boolean that when true enables NTLM based Single Sign On (SSO) functionality in the Web clients. When false and no other members of the authentication chain support SSO, password-based login will be used.
ntlm.authentication.mapUnknownUserToGuest
Should unknown users automatically be logged on as the Alfresco guest user during Single Sign-On (SSO)?
ntlm.authentication.browser.ticketLogons (new in v3.3 SP3)
Can a ticket parameter in the request URL be used to authenticate with the Alfresco Explorer application? Default is true. Note that WebDAV URLs always accept ticket parameters.
passthru.authentication.authenticateCIFS
A Boolean that when true enables pass-through authentication for the CIFS server. When false and no other members of the authentication chain support CIFS authentication, the CIFS server will be disabled.
passthru.authentication.authenticateFTP
A Boolean that when true enables pass-through authentication for the FTP server. The provided password is hashed and checked directly against the domain server securely using NTLM. When false and no other members of the authentication chain support FTP authentication, standard chained authentication will be used.
passthru.authentication.guestAccess
Should we allow guest access to Alfresco if the authenticating server indicates the logon was allowed guest access?
passthru.authentication.defaultAdministratorUserNames
A comma separated list of user names who should be considered administrators by default. It's often useful to add the administrator user to this list.
passthru.authentication.connectTimeout
The timeout value when opening a session to an authentication server, in milliseconds. The default is 5000.
passthru.authentication.offlineCheckInterval
Specifies how often passthru servers that are marked as offline are checked to see if they are now online. The default check interval is 5 minutes. The check interval is specified in seconds.
passthru.authentication.protocolOrder
Specifies the type of protocols and the order of connection for passthru authentication sessions. The default is to use NetBIOS, if that fails then try to connect using native SMB/port 445. Specify either a single protocol type or a comma delimited list with a primary and secondary protocol type. The available protocol types are NetBIOS for NetBIOS over TCP and TCPIP for native SMB.
[edit] Domain Mappings

Domain mappings are used to determine the domain a client is a member of when the client does not specify its domain in the logon request. If the client uses a numeric IP address to access the web server it will not send the domain in the NTLM request as the browser assumes it is an Internet address.

To specify the domain mapping rules that are used when the client does not supply its domain in the NTLM request you can use the filesystem.domainMappings composite property of the File Server Subsystem. There are two ways of defining a domain mapping, either by specifiying an IP subnet and mask, or by specifying a range of IP addresses. The example below, when included in alfresco-global.properties defines mappings for two domains, ALFRESCO and OTHERDOM. For more information on setting composite properties see Setting composite properties. 

filesystem.domainMappings=ALFRESCO,OTHERDOM
filesystem.domainMappings.value.ALFRESCO.subnet=192.168.1.0
filesystem.domainMappings.value.ALFRESCO.mask=192.168.1.255
filesystem.domainMappings.value.OTHERDOM.rangeFrom=192.168.1.0
filesystem.domainMappings.value.OTHERDOM.rangeTo=192.168.1.100

The passthru subsystem can use the domain prefixed server name format of the passthru.authentication.servers property along with the domain mappings to route authentication requests to the appropriate server.

A sample NTLM authentication component server list: 

passthru.authentication.servers=ALFRESCO\\ADSERVER,OTHERDOM\\OTHERSRV

[edit] Kerberos

[edit] Introduction

The Java Authentication and Authorization Service (JAAS) is used within the Kerberos subsystem to support Kerberos authentication of user names and passwords. You may choose to use Kerberos against an Active Directory server in preference to LDAP or NTLM as it provides strong encryption without using SSL. It would still be possible to export user registry information via a chained LDAP subsystem.

The disadvantages of using LDAP authentication against Active Directory compared with JAAS/Kerberos are:

  • the simplest approach is to use the SIMPLE LDAP authentication protocol, which should be used with SSL;
  • AD requires special set up to use digest MD5 authentication (reversible encryption for passwords), which may be difficult retrospectively;
  • LDAP can use GSSAPI + Kerberos which would be equivalent but this is more difficult to configure and has not been tested.

For some pointers and background information on JAAS, the Java Authentication and Authorization Service, please see:

[edit] Alfresco Configuration

To enable full Kerberos support in Alfresco requires that the CIFS server and the SSO authentication filters each have a Kerberos service ticket. See Configuring against Active Directory for how this is set up on Active Directory.

The Kerberos subsystem supports the following properties. See Configuring Subsystems for how to configure these.

kerberos.authentication.realm
The Kerberos realm to authenticate with. The realm should be the domain upper cased; example if the domain is alfresco.org then the realm should be ALFRESCO.ORG
kerberos.authentication.sso.enabled
A Boolean that when true enables SPNEGO/Kerberos based Single Sign On (SSO) functionality in the Web client. When false and no other members of the authentication chain support SSO, password-based login will be used.
kerberos.authentication.authenticateCIFS
A Boolean that when true enables Kerberos authentication in the CIFS server. When false and no other members of the authentication chain support CIFS authentication, the CIFS server will be disabled.
kerberos.authentication.user.configEntryName
The name of the entry in the JAAS configuration file that should be used for password-based authentication. The default value Alfresco is a good choice here.
kerberos.authentication.cifs.configEntryName
The name of the entry in the JAAS configuration file that should be used for CIFS authentication. The default value AlfrescoCIFS is a good choice here.
kerberos.authentication.http.configEntryName
The name of the entry in the JAAS configuration file that should be used for web-based single-sign on (SSO). The default value AlfrescoHTTP is a good choice here.
kerberos.authentication.cifs.password
The password for the CIFS Kerberos principal
kerberos.authentication.http.password
The password for the HTTP Kerberos principal
kerberos.authentication.defaultAdministratorUserNames
A comma separated list of user names who should be considered administrators by default
kerberos.authentication.browser.ticketLogons (new in v3.3 SP3)
Can a ticket parameter in the request URL be used to authenticate with the Alfresco Explorer application? Default is true. Note that WebDAV URLs always accept ticket parameters.

[edit] Making sure Kerberos is set up

Here it is assumed you have a simple configuration and are setting up a machine just to connect to existing Kerberos support, such as Active Directory.


MIT Docs

Kerberos: The Network Authentication Protocol http://web.mit.edu/kerberos


Microsoft docs

Kerberos Authentication in Windows Server 2003 http://technet2.microsoft.com/windowsserver/en/technologies/featured/kerberos/default.mspx

Kerberos Authentication in Windows 2000 Server http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/security/kerberos/default.mspx

Troubleshooting Kerberos http://technet2.microsoft.com/WindowsServer/en/library/26ce2e7f-52d6-4425-88cc-1573bc5e646d1033.mspx


Setting the kerberos configuration can be done from the java command line, using system variables, or using a kerberos config file. This section describes using a config file.

The default locations for the config file are:

  • /etc/krb5/krb5.conf [Solaris]
  • c:\winnt\krb5.ini [Windows] or
  • c:\WINDOWS\krb5.ini [Windows]
  • /etc/krb5.conf [Linux]

[edit] Configuring against Active Directory

The following instructions detail how to set up accounts under Active Directory for use by Alfresco running on Java 6.

1. Create a user account for the Alfresco CIFS server using the Active Directory Users and Computers application. Use the Action->New->User menu, then enter the full name as 'Alfresco CIFS' and the user logon name as 'alfrescocifs'. Click Next, enter a password, enable 'Password never expires' and disable 'User must change password at next logon'. Click Finish. Right click the new user account name, select Properties, go to the Account tab and enable the Do not require Kerberos preauthentication option in the Account Options section.

2. Create a user account for the Alfresco SSO authentication filters as in step 1 using the full name 'Alfresco HTTP' and user logon name as 'alfrescohttp'.

3. Use the ktpass utility to generate key tables for the Alfresco CIFS and web server. The ktpass utility is a free download from the Microsoft site, and is also part of the Windows Server 2003 Support Tools download. The ktpass command can only be run from the Active Directory server. 

ktpass -princ cifs/<cifs-server-name>.<domain>@<realm> -pass <password> -mapuser <domainnetbios>\alfrescocifs
-crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:\temp\alfrescocifs.keytab

ktpass -princ HTTP/<web-server-name>.<domain>@<realm> -pass <password> -mapuser <domainnetbios>\alfrescohttp
-crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:\temp\alfrescohttp.keytab

The principal should be specified using the server name and domain in lowercase with the realm in uppercase. The service types should match cifs and HTTP. E.g. cifs/server.alfresco.org@ALFRESCO.ORG.

The realm should be the domain upper cased; example if the domain is alfresco.org then the realm should be ALFRESCO.ORG

<web-server-name> is the host name that is running the Alfresco server.

<cifs-server-name> is the NetBIOS name of the Alfresco CIFS server when running on an Active Directory client or the host name for a client that is not an Active Directory client, ie. not logged onto the domain.

<domain> is the DNS domain, example alfresco.org

<domainnetbios> is the netbios name, example alfresco

Note: Some versions of the ktpass command can generate invalid keytab files, download the latest version of the support tools from the Microsoft site to avoid any problems.

4. Create the Service Principal Names (SPN) for the Alfresco CIFS and web server using the setspn utility. The setspn utility is a free download from the Microsoft site, and is also part of the Windows Server 2003 Support Tools download. 

setspn -a cifs/<cifs-server-name> alfrescocifs
setspn -a cifs/<cifs-server-name>.<domain> alfrescocifs

setspn -a HTTP/<web-server-name> alfrescohttp
setspn -a HTTP/<web-server-name>.<domain> alfrescohttp

Some versions of the ktpass command will add the SPN for the principal so you may only need to add the NetBIOS/short name versions of the SPNs. Use the setspn -l <account-name> command to check if the ktpass' command set the SPN.

You can list the SPNs for a server using :- 

setspn -l <account-name>

That is: 

setspn -l alfrescocifs
setspn -l alfrescohttp


5. Copy the key table files created in step 3 to the server where Alfresco will run. Copy the files to a protected area such as C:\etc\ or /etc.

6. Set up the Kerberos ini file, the default location is C:\WINNT\krb5.ini or /etc/krb5.conf. 

[libdefaults]
 default_realm = ALFRESCO.ORG
 default_tkt_enctypes = rc4-hmac
 default_tgs_enctypes = rc4-hmac 


[realms]
 ALFRESCO.ORG = {
  kdc = adsrv.alfresco.org
  admin_server = adsrv.alfresco.org
 }


[domain_realm]
 adsrv.alfresco.org = ALFRESCO.ORG
 .adsrv.alfresco.org = ALFRESCO.ORG

Note: The realm should be specified in uppercase.

7. Set up the Java login configuration file.

For JBoss 5, this is done in $JBOSS_HOME/server/default/conf/login-config.xml. Add the following entries inside the <policy> tag. 

 <application-policy name="Alfresco">
   <authentication>
     <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="sufficient"/>
   </authentication>
 </application-policy> 

 <application-policy name="AlfrescoCIFS">
   <authentication>
     <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
       <module-option name="debug">true</module-option>
       <module-option name="storeKey">true</module-option>
       <module-option name="useKeyTab">true</module-option>
       <module-option name="keyTab">C:/etc/alfrescocifs.keytab</module-option>
       <module-option name="principal">cifs/<cifs-server-name>.domain</module-option>
     </login-module>
   </authentication>
 </application-policy> 

 <application-policy name="AlfrescoHTTP">
   <authentication>
     <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
       <module-option name="debug">true</module-option>
       <module-option name="storeKey">true</module-option>
       <module-option name="useKeyTab">true</module-option>
       <module-option name="keyTab">C:/etc/alfrescohttp.keytab</module-option>
       <module-option name="principal">HTTP/<web-server-name>.<domain></module-option>
     </login-module>
   </authentication>
 </application-policy>

For other environments, this would usually be configured in the JRE\lib\security folder (e.g: /usr/local/jdk1.6.0_03/jre/lib/security).

Create a file named java.login.config with the following entries :- 

Alfresco {
   com.sun.security.auth.module.Krb5LoginModule sufficient;
};

AlfrescoCIFS {
   com.sun.security.auth.module.Krb5LoginModule required
   storeKey=true
   useKeyTab=true
   keyTab="C:/etc/alfrescocifs.keytab"
   principal="cifs/<cifs-server-name>.<domain>";
};

AlfrescoHTTP {
   com.sun.security.auth.module.Krb5LoginModule required
   storeKey=true
   useKeyTab=true
   keyTab="C:/etc/alfrescohttp.keytab"
   principal="HTTP/<web-server-name>.<domain>";
};

com.sun.net.ssl.client {
   com.sun.security.auth.module.Krb5LoginModule sufficient;
};

other {
   com.sun.security.auth.module.Krb5LoginModule sufficient;
};

Enable the login config file in the main Java security configuration file, usually at JRE\lib\security\java.security. Add the following line :- 

login.config.url.1=file:${java.home}/lib/security/java.login.config

[edit] Kerberos Client Configuration

In order to get Internet Explorer to negotiate Kerberos authentication rather than NTLM, make sure:

  • The alfresco web server is in the Local Intranet security zone. Check Tools > Internet Options > Security > Local Intranet and make sure that a pattern matching the protocol and domain name is included, e.g. http://server.com or http://*.company.com (the IP does not work)
  • Automatic logon is enabled. Check Tools > Internet Options > Security > Custom Level and make sure Automatic logon with current username and password is selected.

When using firefox on Windows as client, you will need to add your alfresco server name to the network.negotiate-auth.trusted-uris variable You can access the variable going to the special URL: about:config

When using firefox under Linux, you will need to add your alfresco server name to network.negotiate-auth.trusted-uris as above but you will need in addition to get a kerberos ticket using the kinit command. Note that the ticket can correspond to a different user than your linux username 

 kinit user1

where user1 is an active directory user. Notes:

  • if the client and the server are on the same machine, you will need to go to the external interface. The loopback interface won't be able to authenticate.
  • when using HTTP Kerberos SSO, you will need to enter the hostname in the URL, not the IP.
  • You can view your tickets using klist.

[edit] Debugging

You can debug kerberos issues using the log4j properties below: 

log4j.logger.org.alfresco.web.app.servlet.KerberosAuthenticationFilter=debug
log4j.logger.org.alfresco.repo.webdav.auth.KerberosAuthenticationFilter=debug

A sample login output follows: 

18:46:27,915 DEBUG [app.servlet.KerberosAuthenticationFilter] New Kerberos auth request from 192.168.4.95 (192.168.4.95:38750)
18:46:28,063 DEBUG [app.servlet.KerberosAuthenticationFilter] User user1 logged on via Kerberos


the servicePrincipalName (SPN) attribute is a multivalued, nonlinked attribute within the Active Directory directory. It can thus also be shown with standard LDAP clients. For instance the commands below show how to use the "ldapsearch" tool to check the servicePrincipalName and userPrincipalName of the created users. The example below assumes the AD server is at IP 10.69.69.99, the domain is 'example.foo', and the alfresco server name is 'madona'. 

ldapsearch -h 10.69.69.99 -x -D "CN=Administrator,CN=Users,DC=example,DC=foo" \
-W -b 'DC=example,DC=foo' '(servicePrincipalName=cifs*)'

will show 

# Alfresco CIFS, example.foo
dn: CN=Alfresco CIFS,DC=example,DC=foo
...
userPrincipalName: cifs/madona.example.foo@EXAMPLE.FOO
servicePrincipalName: cifs/madona
servicePrincipalName: cifs/madona.example.foo
...

and 

ldapsearch -h 10.69.69.99 -x -D "CN=Administrator,CN=Users,DC=example,DC=foo" \
-W -b 'DC=example,DC=foo' '(servicePrincipalName=HTTP*)'

will show 

# Alfresco HTTP, example.foo
dn: CN=Alfresco HTTP,DC=example,DC=foo
...
userPrincipalName: HTTP/madona.example.foo@EXAMPLE.FOO
servicePrincipalName: HTTP/madona
servicePrincipalName: HTTP/madona.example.foo
...

Finally, network dumpers (tcpdump, snoop, wireshark, Microsoft Network Monitor, etc...) are the ultimate tools to understand why a kerberos login fails.

To create the network dump files, you need to record all the packets going to/from port 88 of the Active Directory server, eg: 

tcpdump -s0 -w kerberos_dump1.pcap port 88

The example below shows a kerberos login failure with a KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN error; this error occurs because the host name sent (apache.foo) does not correspond to the host the server expects (madona.example.foo). Entering the correct URL and having a DNS setup with no error should solve this kind of issues.

Image:Kerberos_error1.png

The example below shows a logon failure with a KRB5KDC_ERR_ETYPE_NOSUPP which occurs when the kerberos client uses a encoding type which is not supported by the server. Having the same encoding in the /etc/krb5.conf file i.e lines: 

default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac

and in the command used to generate the keytabs, i.e. option 

-crypto RC4-HMAC-NT

of the ktpass command, should solve this issue.

Image:Kerberos_error2.png

[edit] External

[edit] Introduction

The external authentication subsystem can be used to integrate Alfresco with any external authentication system that can be integrated with your application server in such a way that the identity of the logged-in user is passed to servlets via the HttpServletRequest.getRemoteUser() method. As this is the standard way for application servers to propagate user identities to servlets, it should be compatible with a number of SSO solutions, including CAS. The subsystem also allows a 'proxy' user to be configured, such that requests made through this proxy user are made in the name of an alternative user whose name is carried in a configured HTTP request header. This allows, for example the Share application and other Alfresco Surf applications to act as a client to an SSO-protected Alfresco application and assert the user name in a secure manner.

See Alfresco With mod_auth_cas for a step-by-step example of configuring the Alfresco Explorer and Share applications behind a CAS server.

[edit] Configuration

The external subsystem supports the following properties. See Configuring Subsystems for how to configure these.

external.authentication.enabled
A Boolean property that when true indicates that this subsystem is active and will trust remote user names asserted to it by the application server.
external.authentication.defaultAdministratorUserNames
A comma separated list of user names who should be considered administrators by default.
external.authentication.proxyUserName
The name of the remote user that should be considered the 'proxy user'. The default is alfresco-system. Requests made by this user will be made under the identity of the user named in the HTTP Header indicated by the external.authentication.proxyHeader property. If not set, then the HTTP Header indicated by the external.authentication.proxyHeader property is always assumed to carry the user name (but please note that this would not be secure unless this application is not directly accessible by other clients).
external.authentication.proxyHeader
The name of the HTTP header that carries the name of a proxied user. The default is X-Alfresco-Remote-User, as used by the Share application.
external.authentication.userIdPattern
An optional regular expression to be used to extract a user ID from the HTTP header. The portion of the header matched by the first bracketed group in the regular expression will become the user name. If not set (the default), then the entire header contents are assumed to be the proxied user name.
Retrieved from "http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems"