Now, for the final segment in my AD/LDAP adventure… As I mentioned in the previous posting, I stopped trying to get the instructions for Active Directory (https://jasig.github.io/cas/4.0.0/installation/LDAP-Authentication.html#active_directory_authentication) to work because I found that they relied on the UniversalPrincipalName which in our environment could be one of multiple values.
Instead, I used ‘Authenticated Search’ (https://jasig.github.io/cas/4.0.0/installation/LDAP-Authentication.html#ldap_requiring_authenticated_search) instructions with one tweak. By default the PooledSearchDnResolver only does a single-level search in the directory. I had to configure the subtreeSearch property. See below… <bean id="dnResolver" class="org.ldaptive.auth.PooledSearchDnResolver" p:baseDn="${ldap.baseDn}" p:allowMultipleDns="false" p:subtreeSearch="true" <-- Added this per the ldaptive docs. p:connectionFactory-ref="searchPooledLdapConnectionFactory" p:userFilter="${ldap.authn.searchFilter}" /> I realize that this is sub-optimal as now I have to use a separate bind account whose credentials are now in the configuration files, but I don’t see how to make the other method work short of reworking the UpnSearchEntityResolver into a CnSearchEntityResolver. I just don’t have time for that at the moment. The only other wrinkle I ran into was that there are two entries in the cas.properties section of the LDAP documentation that share the same description. So, I had to try both to see which would work. For my environment, the former was the correct one. # 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=%[email protected] I hope that this helps someone else down the line and I appreciate all the help I received from other members. Thanks, Geoff From: Whittaker, Geoffrey [mailto:[email protected]] Sent: Wednesday, October 29, 2014 3:27 PM To: [email protected] Subject: RE: [cas-user] AD Auth Handler Success, but failed to authenticate? Okay, I have figured out the problem and it should have been obvious, but it wasn’t to me… ☺ I used Wireshark to watch the LDAP traffic and noticed that it seems to be doing the search with the filter (userPrincipleName=<username>@xxx.xxx.edu.) We have Office365 for the students in our environment. That necessitated a change to the UPN field for those users to something other than our standard. When I changed the ldap.domain field to match the UPN of the account I was using, it started working like a champ. Of course, that leaves our other users out in the cold. Back in the 3.x days we matched users on the CN field. The AD configuration in 4.x uses the UpnSearchEntityResolver. Now looking back, that name should have been a clue. However, I missed it thinking that the filter in the cas.properties example (that I modified) was the filter used. I lost a good portion of a day troubleshooting this instead of temporarily disabling SSL and watching it… Bummer. Anyway, I’m currently trying to get the “LDAP Requiring Authenticated Search” configurations to work. If that fixes it, I’ll just have to go forward with it. If it won’t work, I guess I’ll have to declare separate authentication handlers for the two types of UPNs. I’ll post back with my results in case this can help someone else later. If anyone has any thoughts on how to get the regular AD instructions to work, I’m all ears. Geoff From: Whittaker, Geoffrey [mailto:[email protected]] Sent: Wednesday, October 29, 2014 1:59 PM To: [email protected]<mailto:[email protected]> Subject: RE: [cas-user] AD Auth Handler Success, but failed to authenticate? In our environment sAMAccountName and CN are the same value. I had changed it from the default to cn for testing because it’s what I’d used in the past for other projects. I tested with sAMAccountName again and I still get the AUTHENTICATION_HANDLER_SUCCESS, but “authentication handler failed authenticating”. When I changed the dnResolver’s format to just %s, the logs showed that authentication completely failed. Any other thoughts? Geoff From: Jay [mailto:[email protected]] Sent: Wednesday, October 29, 2014 12:23 PM To: [email protected]<mailto:[email protected]> Subject: Re: [cas-user] AD Auth Handler Success, but failed to authenticate? I use p:principalIdAttribute="sAMAccountName" And I just pass username when login without @xxx.xxx Seems you are trying with cn. <bean id="ldapAuthenticationHandler" class="org.jasig.cas.authentication.LdapAuthenticationHandler" p:principalIdAttribute="sAMAccountName" c:authenticator-ref="authenticator"> https://jasig.github.io/cas/4.0.0/installation/LDAP-Authentication.html Cheers - Jay On Wed, Oct 29, 2014 at 4:10 PM, Whittaker, Geoffrey <[email protected]<mailto:[email protected]>> wrote: I’m trying to configure our AD authentication handler still and when I test it, I see the following in the cas.log. 2014-10-29 11:52:07,025 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Attempting LDAP authentication for <username>+password 2014-10-29 11:52:07,025 DEBUG [org.jasig.cas.authentication.support.UpnSearchEntryResolver] - resolve criteria=[org.ldaptive.auth.AuthenticationCriteria@175296763::dn=<username>@sub.root.edu<http://sub.root.edu>, authenticationRequest=[org.ldaptive.auth.AuthenticationRequest@1982840750::user=<username>, retAttrs=[]]] 2014-10-29 11:52:07,025 DEBUG [org.jasig.cas.authentication.support.UpnSearchEntryResolver] - resolved result=[[]] for criteria=[org.ldaptive.auth.AuthenticationCriteria@175296763::dn=<username>@sub.root.edu<http://sub.root.edu>, authenticationRequest=[org.ldaptive.auth.AuthenticationRequest@1982840750::user=<username>, retAttrs=[]]] 2014-10-29 11:52:07,025 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - LDAP response: [org.ldaptive.auth.AuthenticationResponse@100882638::authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS, ldapEntry=[dn=<username>@sub.root.edu<http://sub.root.edu>[]], accountState=null, result=true, resultCode=SUCCESS, message=null, controls=null] 2014-10-29 11:52:07,025 INFO [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - LdapAuthenticationHandler failed authenticating <username>+password 2014-10-29 11:52:07,025 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN ============================================================= WHO: audit:unknown WHAT: supplied credentials: [<username>+password] ACTION: AUTHENTICATION_FAILED APPLICATION: CAS WHEN: Wed Oct 29 11:52:07 EDT 2014 CLIENT IP ADDRESS: myIP SERVER IP ADDRESS: ServerIP I have included my ldap properties and my deployer config. I’m quite certain that I’m missing something simple. Can anyone point it out? Geoff -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
