Re: [cas-user] CAS 5.2 and AD - Auth fail for just one OU

2019-03-26 Thread Matthew Uribe
Thanks David.

After getting someone from the AD side to sit down and look at it with me, 
we were able to find in the logs on the DC the following error for the 
affected users: "The user has not been granted the requested logon type 
(aka logon right) at this machine"

It looks like the issue really is on the AD side, so I'll let them work it 
out.

Thanks again.
Matt


On Monday, March 25, 2019 at 3:21:27 PM UTC-6, David Curry wrote:
>
> 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.
> 
>
> On Mon, Mar 25, 2019, 17:08 Matthew Uribe  > wrote:
>
>> 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] 
>> - > context=null]>
>> 2019-03-25 15:00:34,499 DEBUG [org.ldaptive.auth.PooledSearchDnResolver] 
>> - 
>> 2019-03-25 15:00:34,502 DEBUG [org.ldaptive.SearchOperation] - > 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, 
>> 

Re: [cas-user] CAS 5.2 and AD - Auth fail for just one OU

2019-03-25 Thread 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.cu...@newschool.edu
Sent from my phone; please excuse typos and inane auto-corrections.


On Mon, Mar 25, 2019, 17:08 Matthew Uribe  wrote:

> 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] -
>  context=null]>
> 2019-03-25 15:00:34,499 DEBUG [org.ldaptive.auth.PooledSearchDnResolver] -
> 
> 2019-03-25 15:00:34,502 DEBUG [org.ldaptive.SearchOperation] -  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]>
> .
> .
> .
>