Linda, In your CAS logs, prior to a successful BIND while using CAS 3.4.2.1, is there any indication CAS tried to BIND to the primary directory? I am guessing in the failed attempt to BIND to the primary using CAS there were no further log entries suggesting CAS might have tried to BIND to the secondary directory?
Also, I am not sure how much logging information you can get out of your directories, but can you confirm from the LDAP side of things what directories are being consulted by each version of CAS? I.e., can you fill in the following table based on LDAP logs, using an account that is *supposed* to fail over to the secondary: CAS VERSION Attempt BIND Primary? Attempt BIND Secondary? =========== ===================== ======================= 3.4.2.1 3.5.2.1 The deployerConfig.xml is what I would expect-- the authentication handlers look like they should be tried one after another until one succeeds or they all fail. What is not clear without seeing more logs (either CAS or LDAP) is whether CAS fails in the newer version because it is not attempting to BIND to the secondary, or whether it attempts to BIND to the secondary and fails. Thanks, Carl ----- Original Message ----- From: "Linda Toth" <[email protected]> To: [email protected] Sent: Monday, February 2, 2015 7:22:44 PM Subject: Re: [cas-user] 3.4.2.1 to 3.5.2.1 in deployerConfigContext.xml Carl I was able to roll out 3.5.2.1 a little earlier than I expected and you asked if I had evidence in the logs of successful roll over to secondary primary, etc. ... Here is the log for an unexpired user in 3.4.2.1, followed by the log in 3.5.2.1. Users that are authenticated through the primary LDAP show the successful filter of: Successful filter via primary LDAP 2015-02-02 11:42:05,885 DEBUG [org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver] - LDAP search with filter "(|(sAMAccountName=rred)(&(uaIdentifier=rred )(employeeNumber=*)))" Successful filter via secondary LDAP on 3.4.2.1 2015-02-02 14:59:28,720 DEBUG [org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler] - Performing LDAP bind with credential: CN=eofelt,OU=userAccounts,DC=ua,DC=adt,DC=alaska,DC=edu 2015-02-02 14:59:29,307 DEBUG [org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler] - Performing LDAP bind with credential: CN=eofelt,OU=userAccounts,DC=ua,DC=adt,DC=alaska,DC=edu 2015-02-02 14:59:29,582 DEBUG [org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver] - Attempting to resolve a principal... 2015-02-02 14:59:29,582 DEBUG [org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver] - Attempting to resolve a principal... 2015-02-02 14:59:29,582 DEBUG [org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver] - Creating SimplePrincipal for [eofelt] 2015-02-02 14:59:29,582 DEBUG [org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver] - Resolved eofelt. Trying LDAP resolve now... 2015-02-02 14:59:29,582 DEBUG [org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver] - LDAP search with filter "(|(&(employeeNumber=*)(uaIdentifier=eofelt))(cn=eofelt))" 2015-02-02 14:59:29,582 DEBUG [org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver] - returning searchcontrols: scope=2; search base=dc=ua,dc=adt,dc=alaska,dc=edu; attributes=[cn]; timeout=1000 2015-02-02 14:59:29,920 DEBUG [org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver] - Resolved eofelt to eofelt 2015-02-02 14:59:29,920 DEBUG [org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver] - Creating SimplePrincipal for [eofelt] 2015-02-02 14:59:29,920 DEBUG [org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao] - Created seed map='{username=[eofelt]}' for uid='eofelt' 2015-02-02 14:59:29,920 DEBUG [org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao] - Adding attribute 'sAMAccountName' with value '[eofelt]' to query builder 'null' 2015-02-02 14:59:29,920 DEBUG [org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao] - Generated query builder '(sAMAccountName=eofelt)' from query Map {username=[eofelt]}. 2015-02-02 14:59:30,128 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - Added ticket [ TGT-4-jKce9e7jidyzM1CvMPXgyQN1RsahpPIKBotxtGWJsYaxMLVsch-cas-test.alaska.edu] to registry. 2015-02-02 14:59:30,130 DEBUG [org.jasig.cas.web.support.CookieRetrievingCookieGenerator] - Removed cookie with name [CASPRIVACY] 2015-02-02 14:59:30,130 DEBUG [org.jasig.cas.web.support.CookieRetrievingCookieGenerator] - Added cookie with name [CASTGC] and value [ TGT-4-jKce9e7jidyzM1CvMPXgyQN1RsahpPIKBotxtGWJsYaxMLVsch-cas-test.alaska.edu ] 2015-02-02 14:59:30,132 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - Attempting to retrieve ticket [TGT-4-jKce9e7jidyzM1CvMPXgyQN1RsahpPIKBotxt GWJsYaxMLVsch-cas-test.alaska.edu] 2015-02-02 14:59:30,132 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - Ticket [ TGT-4-jKce9e7jidyzM1CvMPXgyQN1RsahpPIKBotxtGWJsYaxMLVsch-cas-test.alaska.edu] found in registry. 2015-02-02 14:59:30,133 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - Added ticket [ ST-5-qakFITk0TLvGSSfCeOzF-cas-test.alaska.edu] to registry. 2015-02-02 14:59:30,133 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service ticket [ ST-5-qakFITk0TLvGSSfCeOzF-cas-test.alaska.edu] for service [ https://beistest.alaska.edu:443/ssomanager/c/SSB] for user [eofelt] Failed via primary LDAP on 3.5.2.1 2015-02-02 14:48:51,265 DEBUG [org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler] - Performing LDAP bind with credential: CN=eofelt ,OU=userAccounts,DC=ua,DC=adt,DC=alaska,DC=edu 2015-02-02 14:48:51,541 INFO [org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler] - Failed to authenticate user eofelt with error [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 701, v1db1^@]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 701, v1db1^@] 2015-02-02 14:48:51,541 DEBUG [org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler] - No error definitions are defined. Throwing error [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 701, v1db1^@]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 701, v1db1^@] 2015-02-02 14:48:51,542 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler failed authenticating [username: eofelt] 2015-02-02 14:48:51,547 DEBUG [org.jasig.cas.web.flow.AuthenticationViaFormAction] - An authentication error has occurred. Returning the event id error Linda Toth University of Alaska - Office of Information Technology (OIT) - Identity and Access Management 910 Yukon Drive, Suite 103 Fairbanks, Alaska 99775 Tel: 907-450-8320 Fax: 907-450-8381 [email protected] | www.alaska.edu/oit/ On Mon, Feb 2, 2015 at 1:46 PM, Linda Toth <[email protected]> wrote: > Carl, > > Yesterday I had a clear distinction between the 3.4.2.1 successful login > and the 3.5.2.1 failure. I did not it make the attempt for 3.4.2.1 and did > not see it in 3.5.2.1. It simply came back with the expired notice. > > I am in the process of rebuilding TEST to 3.4.2.1 (including tables for > registry). I won't be able to diagnose more of these issues on DEV until > that is complete - at which time I can provide better details. > > Thanks for taking time to respond. I greatly appreciate it. > > Linda > > Linda Toth > University of Alaska - Office of Information Technology (OIT) - Identity > and Access Management > 910 Yukon Drive, Suite 103 > Fairbanks, Alaska 99775 > Tel: 907-450-8320 > Fax: 907-450-8381 > [email protected] | www.alaska.edu/oit/ > > > On Mon, Feb 2, 2015 at 9:33 AM, Waldbieser, Carl <[email protected]> > wrote: > >> Linda, >> >> Is there any indication (e.g. from proxy logs) that the accounts that are >> failing over are actually making requests against the proxy? In other >> words, do you have any indication whether the issue is that the fail over >> requests are never being made or that the requests are being made but >> failing to authenticate? >> >> Thanks, >> Carl Waldbieser >> ITS Systems Programmer >> Lafayette College >> >> ----- Original Message ----- >> From: "Linda Toth" <[email protected]> >> To: [email protected] >> Sent: Monday, February 2, 2015 1:04:40 PM >> Subject: [cas-user] 3.4.2.1 to 3.5.2.1 in deployerConfigContext.xml >> >> Good morning, >> >> FYI - I am aware I need to promote to 3.5.3, but first things first. >> >> I forwarded this question to our support organizations for CAS and they >> have not come up with any explanation yet. I am hoping someone here has >> some insight. >> >> I have not changed the deployerConfigContext.xml file from 3.4.2.1 to >> 3.5.2.1. I looked over the distribution, but opted to try it as is. Our >> deployerConfigContext.xml file contains a component that allows expired >> and >> new users to fall through to an active directory proxy when they fail to >> be >> authenticated via straight AD LDAP. Our policies at UA expire students >> very quickly on some campuses so that they can not use the PC work >> stations. This causes issues when they come back to register for the next >> semester. >> >> In 3.4.2.1, I developed a nice configuration that will allow >> authentication >> through one or the other. 3.5.2.1, it only authenticates users that are >> not expired, i.e., it is not failing over. >> >> I have extracted the pertinent sections and placed them in a file, >> attached. It is a simple text file. One thing I did not do that may >> cause >> problems is that I did not denote a separate attributeRepository bean. >> They are identical for both straight AD and the proxy. Perhaps I should >> replicate them with a different name. >> >> If anyone can pinpoint a modification I should make to accommodate 3.5.2.1 >> quickly, I would greatly appreciate it. I very much want to move toward >> two-factor authentication and Casifying Shib, but need 3.5.2.1 to do that. >> >> >> Linda Toth >> University of Alaska - Office of Information Technology (OIT) - Identity >> and Access Management >> 910 Yukon Drive, Suite 103 >> Fairbanks, Alaska 99775 >> Tel: 907-450-8320 >> Fax: 907-450-8381 >> [email protected] | www.alaska.edu/oit/ >> >> -- >> 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 >> > > -- 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
