Great to hear, Mike. A piece of advice for returning attributes: not sure if it is better documented now than when I was stumbling around with it, but make sure you call the p3 endpoint on service validation (.../cas/p3/serviceValidate?...). This invokes the CAS 3.0 protocol, and works very, very well for returning attributes.
John RedZone Software On 7/1/2015 8:46 AM, Mike Seiler wrote: > Thank you all for your suggestions and help. I touch CAS maybe once a > year when changes are needed, so I'm not very savvy. > > By setting the log values to TRACE I was able to determine that CAS > was never initiating the ldap search (as Daniel pointed out) and > figure out what was causing that. > > The authentication /*succeeded*/ after the following: > 1) Using the 2nd option (LDAP Requiring Authenticated Search), and > fixing differences in the sample code and my cas.properties file (e.g. > ldap.managerDn vs ldap.authn.managerDn) > 2) changing the the managerDN to the [email protected] > <mailto:[email protected]> -- in the 3.5.2 installation, I > used the full CN=CASADMIN, etc... > 3) setting useStartTLS=false > 4) setting searchFilter to (sAMAccountName={user}) -- anything else > seems to fail > > The response from the server (in catalina.out) contains all the > attributes I'm hoping to get (and then some), so it seems that the > attribute mapping is working as well. I'll find out more when I > modify the authorization plugins for our external apps to pull the CAS > attributes list. > > *SSL* > It seems that disabling/enabling the sslConfig bean makes no > difference in my config; the certs are stored in the default keystore > as well, so both methods build and authenticate. > > In the interest of helping fellow Google searchers down the road, I've > attached my LDAP properties section of the cas.properties file below: > > #======================================== > # General properties > #======================================== > ldap.url=ldaps://id.fuller.edu <http://id.fuller.edu> > # LDAP connection timeout in milliseconds > ldap.connectTimeout=3000 > # Whether to use StartTLS (probably needed if not SSL connection) > ldap.useStartTLS=false > #======================================== > # LDAP connection pool configuration > #======================================== > ldap.pool.minSize=3 > ldap.pool.maxSize=10 > ldap.pool.validateOnCheckout=false > ldap.pool.validatePeriodically=true > ldap.pool.blockWaitTime=3000 > ldap.pool.validatePeriod=300 > ldap.pool.prunePeriod=300 > ldap.pool.idleTime=600 > #======================================== > # Authentication > #======================================== > # Base DN of users to be authenticated > ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu > # Manager DN for authenticated searches > [email protected] > <mailto:[email protected]> > # Manager password for authenticated searches > ldap.authn.managerPassword=admin_password > # Search filter used for configurations that require searching for DNs > ldap.authn.searchFilter=(sAMAccountName={user}) > # Domain Setting > ldap.domain=fuller.edu <http://fuller.edu> > ldap.trustedCert=file:/etc/cas/id_app.pem > > and am attaching my current deployerConfigContext.xml file to this email. > > Thanks again, > > Mike > > > On Tue, Jun 30, 2015 at 3:27 PM, Mike Seiler <[email protected] > <mailto:[email protected]>> wrote: > > Thank you Mihai and John. > > I will try those things first thing in the morning and get back to > you with all the additional logs and details. > > Mike > > On Tue, Jun 30, 2015 at 3:22 PM, John Ryan <[email protected] > <mailto:[email protected]>> wrote: > > Mike, > > I think Daniel is on to something: we see no indication > whatsoever in your log output that LDAP authentication is even > being attempted. In your log4j.xml please dial way back > everything (most especially org.springframework) to WARN > except//org.jasig and org.ldaptive (set both to TRACE). After > you attempt to hit a CAS-ified application, we should then see > a rich set of detail about CAS placing a service in FlowScope, > generating a login ticket, etc. > > If everything is OK up to that point, we'll see an "Attempting > LDAP authentication" message from > org.jasig.cas.authentication.LdapAuthenticationHandler, > followed by rich detail from org.ldaptive components as they > interact with AD. > > FYI we're using CAS 4.0 with AD and it is working fine. The > only differences that jump out to me from our configuration is > that we don't use any of the ldap.authn properties at all, as > we want to use the user's sAMAccountName. > > Also, one departure from the deployerConfigContext.xml at > > http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication > is that we do not use an sslConfig bean. We use ldaps, the > cert for our AD server is in the JVM's keystore, and things > seem to work just fine without the sslConfig bean. > > But again, we see no indication an attempt at LDAP > authentication is even being attempted. Updating log4j.xml > with the suggested changes should at least make that clear. > > On 6/29/2015 9:26 PM, Daniel Fisher wrote: >> On Mon, Jun 29, 2015 at 1:28 PM, Mike Seiler >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> Any further suggestions on what might be causing the >> system to fail to authenticate users? >> >> Bind with manager password works. Certificates validate. >> sAMAccountName is set as the search filter. >> >> Any suggestions would be appreciated. >> >> >> I didn't see the LDAP authentication component being >> exercised. Your LDAP pools initialize correctly, but the >> authentication handler does not appear to use them. I don't >> know enough about the v4 config to say what's wrong, but I >> would look for something fundamental in the authentication >> wiring, not in the LDAP config. >> >> --Daniel Fisher >> >> -- >> You are currently subscribed [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 > > -- > John Ryan / Senior Software Engineer / RedZone Software > [email protected] <mailto:[email protected]> / www.redzone.co > <http://www.redzone.co> > > -- > You are currently subscribed [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, > seehttp://www.ja-sig.org/wiki/display/JSG/cas-user > > > This transmission contains confidential information intended > solely for the party identified above. If you receive this > message in error, you must not use it or convey it to others. > Please destroy it immediately and contact the sender at (303) > 386-3955 <tel:%28303%29%20386-3955> or by return e-mail to the > sender. > > > > > -- > *Michael Seiler* > -------------------------------------------------- > Systems Integration Engineer > Fuller Theological Seminary > Phone: (970) 306-6105 <tel:%28970%29%20306-6105> > [email protected] <mailto:[email protected]> > > *Fuller Summer Hours:* Please note that all Fuller offices will be > closed on Fridays from 7/3-8/28 > *Mike's Vacation Notice:* From 7/3-8/28 I will also be taking > Mondays off, and will be out of the office for vacation 7/31 - 8/31 > > *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 > <tel:%28626.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. > > > > > -- > *Michael Seiler* > -------------------------------------------------- > Systems Integration Engineer > Fuller Theological Seminary > Phone: (970) 306-6105 > [email protected] <mailto:[email protected]> > > *Fuller Summer Hours:* Please note that all Fuller offices will be > closed on Fridays from 7/3-8/28 > *Mike's Vacation Notice:* From 7/3-8/28 I will also be taking Mondays > off, and will be out of the office for vacation 7/31 - 8/31 > > *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 -- This transmission contains confidential information intended solely for the party identified above. If you receive this message in error, you must not use it or convey it to others. Please destroy it immediately and contact the sender at (303) 386-3955 or by return e-mail to the sender. -- 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
