CAS allows multiple LDAP directories to be queried when authenticating users. Because our Active Directory does not include all our users, we also need to authenticate against the LDAP server included with Ellucian’s Luminis user portal.
Add the following settings to etc/cas/config/cas.properties
, below the Active Directory settings added in the previous section, to authenticate against Luminis LDAP:
cas.authn.ldap[1].order: 1
cas.authn.ldap[1].name: Luminis LDAP
cas.authn.ldap[1].type: AUTHENTICATED
cas.authn.ldap[1].ldapUrl: ldaps://janus.newschool.edu
cas.authn.ldap[1].validatePeriod: 270
cas.authn.ldap[1].userFilter: uid={user}
cas.authn.ldap[1].baseDn: ou=People,o=cp
cas.authn.ldap[1].bindDn: uid=ldap_ssotest,ou=People,o=cp
cas.authn.ldap[1].bindCredential: xxxxxxxxxxxx
The [1]
in the property names indicates that this is the second LDAP source to be configured (Active Directory was [0]
).
The properties used above are:
order |
When multiple authentication sources are configured, the CAS server looks for the user in one source after another until the user is found, and then the authentication is performed against that source (where it either succeeds or fails). This property influences the order in which the source is evaluated (if not specified, sources are evaluated in the order they are defined). |
name |
The name of the source. This is used when writing log file messages. |
type |
The type of authenticator to use. This should be AUTHENTICATED to specify the traditional “bind account” method of authentication. |
ldapUrl |
The URL of the LDAP server. In our case, we use the URL of the virtual host on the F5 load balancer, which has multiple LDAP servers behind it. |
validatePeriod |
The LDAP module periodically validates the connections in its connection pool. But the default setting for how often to do this (600 seconds) is longer than the idle timeout on the F5 load balancer that fronts the LDAP servers (300 seconds), which results in lots of warning messages being written to the CAS log file (one per connection every ten minutes). Reducing the validation period to something shorter than the load balancer idle timeout eliminates these messages. |
userFilter |
The LDAP filter to select the user from the directory. Luminis LDAP searches on the uid attribute, which is actually the user’s username. The {user} pattern will be replaced with the username string entered by the user. |
baseDn |
The base DN to search against when retrieving attributes. |
bindDN |
The DN of the account to bind to the directory with. This account must have search privileges on the directory. |
bindCredential |
The password to the bind account. |
Install and test on the master build server
Adding the Luminis LDAP server only required changing cas.properties
, so there is no need to rebuild or reinstall the server. Instead, just copy the new file into place on the master build server (casdev-master) and restart Tomcat by running the commands
casdev-master# cd /opt/workspace/cas-overlay-template
casdev-master# cp etc/cas/config/cas.properties /etc/cas/config/cas.properties
casdev-master# systemctl restart tomcat
Review the contents of the log files (/var/log/tomcat/catalina.yyyy-mm-dd.out
and /var/log/cas/cas.log
) for errors.
Once everything has started, open up a web browser and enter the URL of the CAS application on the master build server (https://casdev-master.newschool.edu:8443/cas/login
), and try to log in using a Luminis LDAP username and password (one that isn’t also in Active Directory). The “Log In Successful” page should appear. If it doesn’t, consult /var/log/cas/cas.log
for errors. Then try logging in with an Active Directory username and password to confirm that the addition of LDAP didn’t break anything.
It may help to enable debugging on the LDAP module by changing the org.ldaptive
logging level to debug
around line 95 in /etc/cas/config/log4j2.xml
:
<AsyncLogger name="org.ldaptive" level="debug" />
and restarting Tomcat.
Install and test on the CAS servers
Once everything is running correctly on the master build server, it can be copied to the CAS servers:
casdev-master# for host in srv01 srv02 srv03
> do
> scp etc/cas/config/cas.properties casdev-${host}:/etc/cas/config/cas.properties
> ssh casdev-${host} systemctl restart tomcat
> done
casdev-master#
and tested using the URL of the load balancer’s virtual interface (https://casdev.newschool.edu/cas/login
).
Commit changes to Git
Before moving on to the next phase of configuration, commit the changes made to pom.xml
and cas.properties
to Git:
casdev-master# cd /opt/workspace/cas-overlay-template
casdev-master# git add etc/cas/config/cas.properties
casdev-master# git commit -m "Added Luminis LDAP authentication"
[newschool-casdev 912da34] Added Luminis LDAP authentication
1 file changed, 15 insertions(+)
casdev-master#