See inline comments ... 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 4:54 PM, Waldbieser, Carl <[email protected]> wrote: > 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? > > YES, noted in RED below 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: > I control which LDAP server is being used by properties in the cas.properties file. I have not changed servers for either the primary or secondary between CAS versions. > > 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. > See LOG in blue below. It does not indicate it is trying to resolve a principal and can not so it moves on to constructing a SimplePrincipal. > > 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 > -- 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
