Thanks John, I'll keep that in mind about the p3 endpoint when I get to the next step of this project.
Mike On Wed, Jul 1, 2015 at 8:52 AM, John Ryan <[email protected]> wrote: > 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]> > [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 > # 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] > # 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 > 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]> > 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]> >> [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> >>> 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]>[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 to [email protected] as: >>> [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] / www.redzone.co >>> >>> -- >>> 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 <%28303%29%20386-3955> or by >>> return e-mail to the sender. >> >> >> >> >> -- >> *Michael Seiler* >> -------------------------------------------------- >> Systems Integration Engineer >> Fuller Theological Seminary >> Phone: (970) 306-6105 <%28970%29%20306-6105> >> [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. >> > > > > -- > *Michael Seiler* > -------------------------------------------------- > Systems Integration Engineer > Fuller Theological Seminary > Phone: (970) 306-6105 > [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 > > > -- > 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. > -- *Michael Seiler* -------------------------------------------------- Systems Integration Engineer Fuller Theological Seminary Phone: (970) 306-6105 [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
