LDAP attribute problems after upgrade to 5.0.3.x

[Baron Fujimoto]

We recently upgraded from 5.0.2 to 5.0.3.1, but had to roll it back due
to strange LDAP attribute problems that appeared afterwards. A couple of
hours after the upgrade (strange right there that the problems didn't
manifest right away after the upgrade), we began receiving problem reports
that were traced back to applications not receiving expected attributes
from CAS upon successful authentication.

Previously we'd get attributes from our LDAP (389DS) like:

INFO [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - <Authenticated principal [user1] and attributes {cn=Firstname Lastname, eduPersonAffiliation=student, eduPersonOrgDN=uhm, eduPersonPrincipalName=us...@hawaii.edu, givenName=Firstname, LdapAuthenticationHandler.dn=uhEntry=*****,ou=People,dc=hawaii,dc=edu, mail=us...@hawaii.edu, sn=Lastname, attrFoo=Foo, attrBar=Bar, attrBaz=Baz} with credentials [user1].>

But once the problems began, we'd only receive:

INFO [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - <Authenticated principal [user1] and attributes {LdapAuthenticationHandler.dn=uhEntry=*****,ou=People,dc=hawaii,dc=edu} with credentials [user1].>

On the LDAP side of things, it looks like the exact same query. Only for
the first successful example, we get one result (n=1), and for the second,
no results (n=0, and no errors). Rolling back CAS to 5.0.2 fixes the
problem. We can see from our CAS logs that we'd occasionally see the n=0
results with 5.0.2 a few times a day, but it wasn't a permanent condition.
With 5.0.3 once we get the n=0 result, it will permanently return n=0. We
did not touch our LDAP service or our CAS configs for LDAP as part of the
upgrade.

Furthermore, before we rolled back the upgrade, our developers observed
that they were able to work around the problem by clearing cookies in
their browsers. We're still trying to wrap our heads around how this could
affect the LDAP queries/results as seen on the LDAP host.

Unfortunately, we have thus far been unable to replicate these problems
in our test environments. Nor have we been able to yet identify any other
significant differences between these environments.

Has anyone seen anything similar, or have any ideas what might be involved
here?

Aloha,
-baron
--
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

[Baron Fujimoto]

In the interest of due diligence, is anyone else out there using
5.0.3.1 with 389DS LDAP for authentication credentials and attributes
that we could compare config/notes with?

[Jérôme Nenert]

We've experienced the same issue. Take a look at this post
https://groups.google.com/a/apereo.org/d/topic/cas-user/PyGTeFXU_-U/discussion

Baron Fujimoto <ba...@hawaii.edu> a écrit :

> --
> - CAS gitter chatroom: https://gitter.im/apereo/cas
> - CAS mailing list guidelines:
> https://apereo.github.io/cas/Mailing-Lists.html
> - CAS documentation website: https://apereo.github.io/cas
> - CAS project website: https://github.com/apereo/cas
> ---
> 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 cas-user+u...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/20170307204517.572gx4eirobziq3h%40praenomen.mgt.hawaii.edu.

[Baron Fujimoto]

Yup, thanks. I'm the one that filed the CAS PR referenced in that thread.
FWIW, we are currently working around the issue in 5.0.3.1 via a special
interim LDAP ACI that exempts us from the problem.

-baron