It seems that the issue might happen for just this attribute or for all
attributes, but it's not consistent. I'm not sure that we can say it's for
a particular user id, but it has occurred with a few different users. Also,
the management web app is using a JSON service registry for storage.
Additionally, after turning up some of the logging in CAS to debug, I
noticed the following, which may be causing the issue, though I'm not 100%
sure if this is the cause.
- org.springframework.ldap.PartialResultException:nested exception is
javax.naming.PartialResultException [Root exception is
javax.naming.CommunicationException: simple bind failed: adserver:636 [Root
exception is javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: timestamp check failed]].
Further down the stacktrace are the following entries it finally gets to
this:
- Caused by: java.security.cert.CertificateExpiredException: NotAfter:
timestamp
Additional output then shows:
- DEBUG [org.jasig.cas.authentication.AuthenticationManagerImpl] -
Attribute map for username: {}
So what seems to be happening is the user is able to authenticate but then
that CertificateExpiredException maybe is preventing it getting the
attributes?
The odd thing is that I looked at the certs in the truststore for the AD
server and although one cert was expired, the timestamp was different from
the value in the Java exception.
I also checked the cert for the CAS server itself, but this is valid still.
After comparing to a development build I'm working on for CAS 4, I don't
think I need that particular certificate because the CAS 4 instance is
using a certificate that is higher in the general certificate chain and
seems to be working successfully so far for authentication and attribute
release.
So then I tried removing that certificate on the CAS 3 server and just
using the higher level cert, but the issue seems to persist.
For example, I tested with my account with a simple webapp that lists the
attribute and another user also tested, both of us successfully.
Then I had a third user test, but this one ran into the issue. I'm going
to have this user try clearing their cache and see if it happens again to
try to narrow it down further.
Matt
On Wednesday, March 2, 2016 at 1:20:38 PM UTC-5, Misagh Moayyed wrote:
>
> Guessing here: You are and have been running the same exact code for a
> number of years. So my bet would be that something else changed external to
> CAS, or is acting up somehow, recently. I’d look into your LDAP/CAS logs
> for the times the attribute is not being released and trace the activity.
> Also you should narrow down the scope. Is that the only attribute that is
> not received? Do all fail to be released? Does it fail for a particular
> user id? What values are there for the failing case? What does
> your management app use for storage? Etc. The fewer variables, the better.
>
> --
> Misagh
>
> From: Matt S. <[email protected]> <javascript:>
> Reply: Matt S. <[email protected]> <javascript:>
> Date: March 2, 2016 at 6:10:46 PM
> To: CAS Community <[email protected]> <javascript:>
> CC: [email protected] <javascript:> <[email protected]> <javascript:>
> Subject: [cas-user] CAS 3.5.3 Intermittent Attribute Issues
>
> Hi,
>
> We originally set up CAS server 3.5.3 as a development server before 4 was
> released and we have been running version 3.x for 1-2 years without any
> issue.
>
> However, recently this server started to have an issue with one of the
> attributes that is released.
>
> Here are some specifications:
>
> - We are reading the employeeId attribute and using LDAP for
> authentication.
> - The service authorization has been setup to release one or more
> attributes to all of the web apps that are developed in a particular
> location on a development server.
> - CAS and web app servers are using Tomcat 6
>
> The attribute mentioned above recently began to not show up sometimes in
> the CAS response, even though the user account does have the attribute set
> in AD.
>
> Some things we have tried to resolve this each time it happens include:
>
> - Update the service definition in the CAS Service Management web app
> to not release the attribute and then update it again to release it.
> -
> - This seems to work sometimes, but not always.
> - Clear the browser cache and then access the web app again
> -
> - This also does not work every time.
>
>
> Any suggestions would be extremely appreciated!
>
> Thanks,
> Matt
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected] <javascript:>.
> Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/
> .
>
>
--
You received this message because you are subscribed to the Google Groups "CAS
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
