CAS 5.2 and AD - Auth fail for just one OU

[Matthew Uribe]

Hi everyone,

I'm only just beginning to use AD with my CAS 5.2 deployment, and with the information in many previous posts here, I've been successful in authenticating users in CAS with their AD accounts. There is one exception, however, and that is the Active Students OU. Accounts in that OU fail to authenticate. If I move one of the accounts out of Active Students and into an OU where accounts are able to authenticate, they still can't authenticate. Likewise, accounts from any other OU, if moved into Active Students, do successfully authenticate. This leads me to believe that it must be something specific to those accounts, but I don't know what it would be.

I initially used the following settings for AD in the cas.properties:

cas.authn.ldap[1].order:                1

cas.authn.ldap[1].name:                 Test Empl Active Directory

cas.authn.ldap[1].type:                 AD

cas.authn.ldap[1].ldapUrl:              ldaps://testaimsdc1.test.aims.edu

cas.authn.ldap[1].validatePeriod:       270

cas.authn.ldap[1].poolPassivator:       NONE

cas.authn.ldap[1].userFilter:           sAMAccountName={user}

cas.authn.ldap[1].baseDn:               dc=test,dc=aims,dc=edu

cas.authn.ldap[1].dnFormat:             %s...@test.aims.edu

This worked, as I said, for all accounts but those contained in Active Students.

I've also tried configuring a connection for each OU, but the results are the same. I've tried different LDAP types, such as AUTHENTICATED, which also works, except for the Active Students accounts.

The accounts in the Active Students OU are able to sign in to domain joined workstations with no problem, which has the AD team pointing to CAS as the issue, so I finally set the ldaptive log level to debug and found the following: When an affected user tries to sign in to CAS, these are some of the first lines to appear in the log:

2019-03-25 15:00:34,499 DEBUG [org.ldaptive.auth.PooledSearchDnResolver] - <resolve user=[org.ldaptive.auth.User@1399833348::identifier=aault, context=null]>

2019-03-25 15:00:34,499 DEBUG [org.ldaptive.auth.PooledSearchDnResolver] - <searching for DN using userFilter>

2019-03-25 15:00:34,502 DEBUG [org.ldaptive.SearchOperation] - <execute request=[org.ldaptive.SearchRequest@-1061412749::baseDn=, searchFilter=[org.ldaptive.SearchFilter@1642584434::filter=(objectClass=*), parameters={}], returnAttributes=[1.1], searchScope=OBJECT, timeLimit=PT0S, sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null, sortBehavior=UNORDERED, searchEntryHandlers=null, searchReferenceHandlers=[org.ldaptive.referral.SearchReferralHandler$SearchReferenceHandler@42336fb8], controls=null, referralHandler=org.ldaptive.referral.SearchReferralHandler@1b0ccd3c, intermediateResponseHandlers=null] with connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1455399867::config=[org.ldaptive.ConnectionConfig@904794016::ldapUrl=ldaps://testaimsdc1.test.aims.edu, connectTimeout=PT5S, responseTimeout=PT5S, sslConfig=[org.ldaptive.ssl.SslConfig@866800436::credentialConfig=null, trustManagers=null, hostnameVerifier=null, hostnameVerifierConfig=null, enabledCipherSuites=null, enabledProtocols=null, handshakeCompletedListeners=null], useSSL=true, useStartTLS=false, connectionInitializer=[org.ldaptive.BindConnectionInitializer@792450504::bindDn=cn=svc-ri-ad,ou=Service,ou=Users,ou=Enterprise Support,dc=test,dc=aims,dc=edu, bindSaslConfig=null, bindControls=null], connectionStrategy=org.ldaptive.DefaultConnectionStrategy@5542e5a6], providerConnectionFactory=[org.ldaptive.provider.jndi.JndiConnectionFactory@1596835154::metadata=[ldapUrl=ldaps://testaimsdc1.test.aims.edu, count=1], environment={java.naming.ldap.factory.socket=org.ldaptive.ssl.ThreadLocalTLSSocketFactory, com.sun.jndi.ldap.connect.timeout=5000, java.naming.ldap.version=3, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.security.protocol=ssl, com.sun.jndi.ldap.read.timeout=5000}, classLoader=null, providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig@792845762::operationExceptionResultCodes=[PROTOCOL_ERROR, SERVER_DOWN], properties={}, controlProcessor=org.ldaptive.provider.ControlProcessor@21226762, environment=null, tracePackets=null, removeDnUrls=true, searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED, PARTIAL_RESULTS], classLoader=null, sslSocketFactory=null, hostnameVerifier=null]], providerConnection=org.ldaptive.provider.jndi.JndiConnection@1b1dc06c]>

.

.

.

2019-03-25 15:00:34,545 INFO [org.ldaptive.auth.PooledSearchDnResolver] - <search for user=[org.ldaptive.auth.User@2145716895::identifier=aault, context=null] failed using filter=[org.ldaptive.SearchFilter@81898

0213::filter=cn={user}, parameters={context=null, user=aault}]>

2019-03-25 15:00:34,545 DEBUG [org.ldaptive.auth.PooledSearchDnResolver] - <resolved dn=null for user=[org.ldaptive.auth.User@2145716895::identifier=aault, context=null]>

2019-03-25 15:00:34,545 DEBUG [org.ldaptive.auth.Authenticator] - <authenticate dn=null with request=[org.ldaptive.auth.AuthenticationRequest@1343668647::user=[org.ldaptive.auth.User@2145716895::identifier=aault

, context=null], returnAttributes=[], controls=null]>

2019-03-25 15:00:34,545 WARN [org.apereo.cas.authentication.LdapAuthenticationHandler] - <DN resolution failed. [DN cannot be null]>

Why would the DN be null, only for a specific set of users?

Thanks for any insight anyone may have.

Matt Uribe

[David Curry]

Just a quick off the cuff thought, but could there be a syntax error in the properties file somewhere before the dn setting that's causing that line to be misread?

David A. Curry,  CISSP
Director of Information Security
The New School - Information Technology
71 Fifth Ave., 9th Fl. ~ New York, NY 10003
+1 212 229-5300 x4728 ~ david...@newschool.edu
Sent from my phone; please excuse typos and inane auto-corrections.
   

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/a9bcbfaa-762b-4243-b033-9d9b7d7546ab%40apereo.org.

[Matthew Uribe]

We found the following error in the DC logs: "The user has not been granted the requested logon type (aka logon right) at this machine".

Is there any chance that this has anything to do with CAS, or is this more likely a problem with AD? It's still baffling that these same accounts are able to sign in to domain joined workstations.