You are viewing the development documentation for the Apereo CAS server. The
functionality presented
here is not officially released yet.
This is a work in progress and will be continually updated as development moves forward. To view
the documentation for a specific Apereo CAS server release, please choose an appropriate version.
The release schedule is also available here.
LDAP Authentication
LDAP integration is enabled by including the following dependency in the Maven WAR overlay:
LdapAuthenticationHandler authenticates a username/password against an LDAP directory such as Active Directory
or OpenLDAP. There are numerous directory architectures and we provide configuration for these common cases:
You also need to make sure component scanning is turned on when you configure LDAP authentication. Be sure to include the following in the same configuration file that houses the LDAP configuration for CAS:
Ldap Authentication Principal Attributes
The LdapAuthenticationHandler is capable of resolving and retrieving principal attributes independently without the need for extra principal resolver machinery.
The above configuration defines a map of attribtues. Keys are LDAP attribute names and values are CAS attribute names which allow you to optionally, retrieve a given attribute and release it under a virtual name. (i.e. Retrieve mail from LDAP and remap/rename it to email to be released later). If you have no need for this virtual mapping mechanism, you could directly specify the attributes as a list, in which case the above configuration would become:
Active Directory Authentication
The following configuration authenticates users by sAMAccountName without performing a search,
which requires manager/administrator credentials in most cases. It is therefore the most performant and secure
solution for the typical Active Directory deployment. Note that the resolved principal ID, which becomes the NetID
passed to CAS client applications, is the sAMAccountName in the following example.
Simply copy the configuration to deployerConfigContext.xml and provide values for property placeholders.
LDAP Requiring Authenticated Search
The following configuration snippet provides a template for LDAP authentication performed with manager credentials
followed by a bind. Copy the configuration to deployerConfigContext.xml and provide values for property placeholders.
LDAP Supporting Anonymous Search
The following configuration snippet provides a template for LDAP authentication performed with an anonymous search
followed by a bind. Copy the configuration to deployerConfigContext.xml and provide values for property placeholders.
LDAP Supporting Direct Bind
The following configuration snippet provides a template for LDAP authentication where no search is required to
compute the DN needed for a bind operation. There are two requirements for this use case:
All users are under a single branch in the directory, e.g. ou=Users,dc=example,dc=org.
The username provided on the CAS login form is part of the DN, e.g. uid=%s,ou=Users,dc=exmaple,dc=org.
Copy the configuration to deployerConfigContext.xml and provide values for property placeholders.
LDAP Provider Configuration
In certain cases, it may be desirable to use a specific provider implementation when
attempting to establish connections to LDAP. In order to do this, the connectionFactory
configuration must be modified to include a reference to the selected provider.
Here’s an example for configuring an UnboundID provider for a given connection factory:
Note that additional dependencies must be available to CAS at runtime, so it’s able to locate
the provider implementation and supply that to connections.
LDAP Properties Starter
The following LDAP configuration properties provide a reasonable starting point for configuring the LDAP
authentication handler. The ldap.url property must be changed at a minumum. LDAP properties may be added to the
cas.properties configuration file; alternatively they may be isolated in an ldap.properties file and loaded
into the Spring application context by modifying the propertyFileConfigurer.xml configuration file.
#========================================
# General properties
#========================================
ldap.url=ldap://directory.ldaptive.org
# LDAP connection timeout in milliseconds
ldap.connectTimeout=3000
# Whether to use StartTLS (probably needed if not SSL connection)
ldap.useStartTLS=false
#========================================
# LDAP connection pool configuration
#========================================
ldap.pool.minSize=3
ldap.pool.maxSize=10
ldap.pool.validateOnCheckout=false
ldap.pool.validatePeriodically=true
# Amount of time in milliseconds to block on pool exhausted condition
# before giving up.
ldap.pool.blockWaitTime=3000
# Frequency of connection validation in seconds
# Only applies if validatePeriodically=true
ldap.pool.validatePeriod=300
# Attempt to prune connections every N seconds
ldap.pool.prunePeriod=300
# Maximum amount of time an idle connection is allowed to be in
# pool before it is liable to be removed/destroyed
ldap.pool.idleTime=600
#========================================
# Authentication
#========================================
# Base DN of users to be authenticated
ldap.authn.baseDn=ou=Users,dc=example,dc=org
# Manager DN for authenticated searches
ldap.authn.managerDN=uid=manager,ou=Users,dc=example,dc=org
# Manager password for authenticated searches
ldap.authn.managerPassword=nonsense
# Search filter used for configurations that require searching for DNs
#ldap.authn.searchFilter=(&(uid={user})(accountState=active))
ldap.authn.searchFilter=(uid={user})
# Search filter used for configurations that require searching for DNs
#ldap.authn.format=uid=%s,ou=Users,dc=example,dc=org
ldap.authn.format=%s@example.com
# A path to trusted X.509 certificate for StartTLS
ldap.trustedCert=/path/to/cert.cer
LDAP Password Policy Enforcement
The purpose of the LPPE is twofold:
Detect a number of scenarios that would otherwise prevent user authentication, specifically using an Ldap instance as the primary source of user accounts.
Warn users whose account status is near a configurable expiration date and redirect the flow to an external identity management system.
Reflecting LDAP Account Status
The below scenarios are by default considered errors preventing authentication in a generic manner through the normal CAS login flow. LPPE intercepts the authentication flow, detecting the above standard error codes. Error codes are then translated into proper messages in the CAS login flow and would allow the user to take proper action, fully explaining the nature of the problem.
ACCOUNT_LOCKED
ACCOUNT_DISABLED
INVALID_LOGON_HOURS
INVALID_WORKSTATION
PASSWORD_MUST_CHANGE
PASSWORD_EXPIRED
The translation of LDAP errors into CAS workflow is all handled by ldaptive.
Account Expiration Notification
LPPE is also able to warn the user when the account is about to expire. The expiration policy is determined through pre-configured Ldap attributes with default values in place.
No Password Management!
LPPE is not about password management. If you are looking for that sort of capability integrating with CAS, you might be interested in:
LPPE is by default turned off. To enable the functionally, navigate to src/main/webapp/WEB-INF/unused-spring-configuration and move the lppe-configuration.xml xml file over to the spring-configuration directory.
Next, in your ldapAuthenticationHandler bean, configure the password policy configuration above:
Next, you have to explicitly define an LDAP-specific response handler in your Authenticator.
Generic
Also, you have to handle the PasswordPolicy controls in the BindAuthenticationHandler:
Active Directory
Components
DefaultAccountStateHandler
The default account state handler, that calculates the password expiration warning period, maps LDAP errors to the CAS workflow.
OptionalWarningAccountStateHandler
Supports both opt-in and opt-out warnings on a per-user basis.
The first two parameters define an attribute on the user entry to match on, and the third parameter determines
whether password expiration warnings should be displayed on match.
Note: Deployers MUST configure LDAP components to provide warningAttributeName in the set of attributes returned from the LDAP query for user details.
Troubleshooting
To enable additional logging, modify the log4j configuration file to add the following: