I have adjusted the log level in ad a bit and I am getting this error:
Internal event: The LDAP server returned an error.
Additional Data
Error value:
0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best
match of:
'CN=Dfs-Configuration,CN=System,DC=ExampleOrganization,DC=local'
Regards
Mike Jones
Identity Management Systems Administrator
IT Systems
University of Hull
Tel: 01482 465549
Email: [email protected]
-----Original Message-----
From: Michael A Jones [mailto:[email protected]]
Sent: 26 May 2009 16:12
To: [email protected]
Subject: RE: [cas-user] Problem authenticating with CAS to Active
Directory
Thanks for getting back. I'm not sure that is a bad password, as I don't
specifically get the bad username and password message as part of the
52e error. I think it's a general credentials issue somewhere with both
the username and password being invalid. I have so far used cn=%u and
sAMAccountname=%u, making sure these attributes are populated in AD, but
still no luck. I haven't tried the standard uid, as the CAS setup
doesn't suggest using this for AD.
I'm at a bit of a loss to be honest. Is there any way of finding out
what credentials it is expecting? I have tried to bind to AD using the
LDP viewer and it gives the same error. Therefore it's something I think
to do with the LDAP query being sent by CAS. The DN somewhere must be
wrong in my config, but I'm not sure what it wants to correct his?
Regards
Mike Jones
Identity Management Systems Administrator IT Systems University of Hull
Tel: 01482 465549
Email: [email protected]
-----Original Message-----
From: Michael J. Barton [mailto:[email protected]]
Sent: 26 May 2009 14:29
To: [email protected]
Subject: RE: [cas-user] Problem authenticating with CAS to Active
Directory
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
--
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
*****************************************************************************************
To view the terms under which this email is distributed, please go to
http://www.hull.ac.uk/legal/email_disclaimer.html
*****************************************************************************************
