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
