Thanks Carl, That was actually a leftover from testing. I had tried every option of connection setting, even the ones that don't make sense (like ldaps://host:389 and ldap://host:636); neither of those two worked, of course. However, even with ldaps://id.fuller.edu or ldaps:// id.fuller.edu:636 I still get "Invalid Credentials."
I've added DEBUG levels to most everything that pertains to LDAP, and I'm still not seeing any errors listed that seem to shed light. Just as additional info, I noticed that the cas.log in the production server shows the following: ============================================================= WHO: [username: michaelseiler] WHAT: supplied credentials: [username: michaelseiler] ACTION: AUTHENTICATION_SUCCESS APPLICATION: CAS WHEN: Tue Jun 23 22:19:05 PDT 2015 CLIENT IP ADDRESS: 65.129.164.219 SERVER IP ADDRESS: 192.168.72.137 ============================================================= and the test server seems to be missing the username in the "WHO" section: ============================================================= WHO: audit:unknown WHAT: supplied credentials: [michaelseiler+password] ACTION: AUTHENTICATION_FAILED APPLICATION: CAS WHEN: Tue Jun 23 21:09:15 PDT 2015 CLIENT IP ADDRESS: 192.168.72.69 SERVER IP ADDRESS: 192.168.72.160 ============================================================= Not sure if that is an expected difference in CAS 4.0. or not. Thanks, Mike On Tue, Jun 23, 2015 at 4:09 PM, Carl Waldbieser <[email protected]> wrote: > If you are running on port 636, that typically is ldaps. The initial tcp > connection is encrypted using SSL/TLS and you would use STARTTLS=false and > USETLS=true. > > The url scheme is "ldaps://host:port/basedn" for many ldap libraries (not > sure about this one). > > Carl Waldbieser > On Jun 23, 2015 6:33 PM, "Mike Seiler" <[email protected]> wrote: > >> Daniel, >> >> Thanks. I turned on the debug for Ldaptive, and got multiple lines of >> DEBUG, but none seems to indicate a full error that I can see. >> >> In catalina.out there are a few lines about ldaptive that show the >> following: >> useSSL=false, useStartTLS=false,... etc. >> >> If I set the ldap.useStartTLS=true in my cas.properties, the application >> fails to load and tells me that "TLS or SSL already in effect" and then >> there's a cascading set of errors concerning initializing authentication >> handlers. >> >> If I set ldap.useStartTLS=false, then the application loads fine, but >> catalina.out shows that useSSL=false as well. >> >> If I manually set useSSL to true (in deployerConfigContext), the >> application initializes fine and cas.log still shows "authentication >> failed" but there are no other errors to indicate that something is wrong >> either in catalina.out or cas.log. >> >> The following is from catalina.out which tells me SSL is loading properly: >> ------------------------------------------------------- >> 2015-06-23 15:12:46,290 DEBUG [org.ldaptive.ssl.AggregateTrustManager] - >> <checkServerTrusted for sun.security.ssl.X509TrustManagerImpl@23802df5 >> succeeded> >> 2015-06-23 15:12:46,290 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier] >> - <verifying hostname=id.fuller.edu against cert=> >> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier] >> - <verifyDNS using subjectAltNames=[id-dc2.id.fuller.edu, id.fuller.edu, >> ID]> >> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier] >> - <verifyDNS found hostname match: id.fuller.edu> >> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] - >> <checkServerTrusted for >> org.ldaptive.ssl.HostnameVerifyingTrustManager@126d0169 succeeded> >> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] - >> <invoking getAcceptedIssuers invoked for >> sun.security.ssl.X509TrustManagerImpl@23802df5> >> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] - >> <invoking getAcceptedIssuers invoked for >> org.ldaptive.ssl.HostnameVerifyingTrustManager@126d0169> >> >> The lines containing the useSSL and useStartTLS: >> ----------------------------------------------- >> 2015-06-23 15:12:46,814 DEBUG [org.ldaptive.pool.BlockingConnectionPool] >> - <initialized available queue: >> [org.ldaptive.pool.Queue@458045035::queueType=LIFO, >> queue=[org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@6a3096d4, >> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@630eaf38, >> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@2021f8cc >> ]]> >> 2015-06-23 15:12:46,820 DEBUG [org.ldaptive.pool.BlockingConnectionPool] >> - <prune pool task scheduled for >> [org.ldaptive.pool.BlockingConnectionPool@1188516673::name=null, >> poolConfig=[org.ldaptive.pool.PoolConfig@1654322364::minPoolSize=3, >> maxPoolSize=10, validateOnCheckIn=false, validateOnCheckOut=false, >> validatePeriodically=true, validatePeriod=300], activator=null, >> passivator=null, validator=[org.ldaptive.pool.SearchValidator@725194039 >> ::searchRequest=[org.ldaptive.SearchRequest@88681342::*baseDn=, >> searchFilter=*[org.ldaptive.SearchFilter@1642584434::filter=(objectClass=*), >> parameters={}], returnAttributes=[1.1], searchScope=OBJECT, timeLimit=0, >> sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null, >> sortBehavior=UNORDERED, searchEntryHandlers=null, >> searchReferenceHandlers=null, controls=null, followReferrals=false, >> intermediateResponseHandlers=null]] >> pruneStrategy=[org.ldaptive.pool.IdlePruneStrategy@397920599::prunePeriod=300, >> idleTime=600], connectOnCreate=true, >> connectionFactory=[org.ldaptive.DefaultConnectionFactory@587430635 >> ::provider=org.ldaptive.provider.jndi.JndiProvider@397aec42, >> config=[org.ldaptive.ConnectionConfig@892141193::ldapUrl=ldap:// >> id.fuller.edu:636, connectTimeout=3000, responseTimeout=-1, >> sslConfig=[org.ldaptive.ssl.SslConfig@486207397 >> ::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@1427787790::trustCertificates=file:/etc/cas/id_app.pem, >> authenticationCertificate=null, authenticationKey=null], >> trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, >> handshakeCompletedListeners=null], *useSSL=true, useStartTLS=false*, >> connectionInitializer=null]], initialized=false, availableCount=3, >> activeCount=0]> >> >> I notice that the baseDN is empty, though I have that set in my >> cas.properties file as per the file sample on the Active Directory >> Installation page. >> >> Just to verify my credentials, I logged in on our current CAS 3.5.2 >> server using the same credentials I am trying on the new 4.0 server - both >> CAS servers access the same Active Directory. >> >> Thanks, >> >> Mike >> >> On Tue, Jun 23, 2015 at 12:33 PM, Daniel Fisher <[email protected]> wrote: >> >>> On Tue, Jun 23, 2015 at 12:01 PM, Mike Seiler <[email protected]> >>> wrote: >>> >>>> Hello all, >>>> >>>> I'm running into problems authenticating with Active Directory in CAS >>>> 4.0. What I've done so far: >>>> 1) set up the CAS server using this documentation: >>>> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication >>>> 2) Installed secure certificates in Tomcat for both SSL (on 8443) and >>>> the AD certificate >>>> 3) Installed the certs in the default Java Keystore as well - when >>>> things didn't work with only Tomcat certs >>>> 4) Updated my cas.properties file with the appropriate credentials and >>>> attributes. >>>> >>>> *The Problem:* >>>> CAS loads, but returns with "Invalid Credentials" for every attempt to >>>> log in (even though I can query the AD from the command line): >>>> >>> >>> Put the org.ldaptive package in debug. That may shed some light on the >>> problem. >>> >>> --Daniel Fisher >>> >>> -- >>> 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 >>> >>> >> >> >> -- >> *Michael Seiler* >> -------------------------------------------------- >> Systems Integration Engineer >> Fuller Theological Seminary >> Phone: (970) 306-6105 >> [email protected] >> >> *Please NOTE:* >> I respond to email at 8 AM, 1PM, and at 4:30PM. If you need more >> immediate help, please contact TSS (626.584.5675) and they can route the >> issue to the appropriate person. If this is a business process life or >> death emergency, you may call me at the above number. >> >> >> -- >> 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 >> >> -- > 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 > > -- *Michael Seiler* -------------------------------------------------- Systems Integration Engineer Fuller Theological Seminary Phone: (970) 306-6105 [email protected] *Please NOTE:* I respond to email at 8 AM, 1PM, and at 4:30PM. If you need more immediate help, please contact TSS (626.584.5675) and they can route the issue to the appropriate person. If this is a business process life or death emergency, you may call me at the above number. -- 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
