Michael, For what it is worth, the link below suggests that 52e is a "bad password" error.
http://wiki.caballe.cat/index.php/Active_Directory_LDAP_Errors We have been using Active Directory (via LDAP) as our CAS authentication source for a couple of years now. Recently we had a user that was unable to authenticate. It was determined (by trial and error) that she had a crosshatch "#" in her password. Once she eliminated the "#" from her password she was able to login via CAS. The "#" should not be an issue with AD passwords, but I haven't had time to determine whether the "#" was really the issue or was simply coincidental. I looked over the snippet of your deployerContextConfig.xml and it looks similar to ours, with the exceptions that we use SSL when talking to our domain controllers and since we populate the uid attribute we use uid=%u as our filter. -Michael -----Original Message----- From: Michael A Jones [mailto:[email protected]] Sent: Tuesday, May 26, 2009 8:23 AM To: [email protected] Subject: RE: [cas-user] Problem authenticating with CAS to Active Directory Hi there, Thanks for the advice. I have set my filter to cn=%u abd turned on logging. The error being thrown up is: Internal event: The LDAP server returned an error. Additional Data Error value: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece This apparently suggests invalid credentials being passed to AD. Not sure where to go from here. I have been using my cn value as the login username in CAS. Regards Mike Jones Identity Management Systems Administrator IT Systems University of Hull Tel: 01482 465549 Email: [email protected] -----Original Message----- From: Marvin Addison [mailto:[email protected]] Sent: 22 May 2009 14:56 To: [email protected] Subject: Re: [cas-user] Problem authenticating with CAS to Active Directory I don't think I've ever looked at an AD LDIF, so sAMAccountName may be obfuscated, but it's clearly not what you're using for the test principal: > [email protected] ... > cn: [email protected] > sAMAccountName: $Z21000-CA6B2SF9KI You might try a filter of cn=%u just for kicks, since the cn clearly has the correct value of the principal you're testing with. As with any sort of authentication problem, the most helpful place to look for clues is in the authentication provider logs, AD in this case. I won't even attempt a suggestion for how to turn up logging or where to look, but I'm sure you can figure that out. If you can get some good log output showing the failed auth attempt, post that here. Once you get this working, I would strongly recommend creating a low-privileged user that is used for the bind attempt used to search for the DN of the authenticating user. (Recall BindLdapAuthenticationHandler uses a 2-step authentication process; initial bind and search for DN, then bind as DN using supplied password credential.) You can avoid disclosing any passwords in the clear by using FastBindLdapAuthenticationHandler if all your users live immediately under one branch, e.g. ou=Identities. Hope that helps, M -- 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
smime.p7s
Description: S/MIME cryptographic signature
