Re: HELP! Really strange problem w/AD and LDAP/LDIFDE
- From: ohaya <ohaya@xxxxxxx>
- Date: Mon, 22 Jan 2007 21:25:24 -0500
Hi,
On the 2nd part of my post, re. my "original" problem, I *think* that the problem may be that we were calling the LDAPJDK authenticate() method using a (admin) username of the form user@xxxxxxxxxxxxx I think that the admin username in the authenticate() should be a "full DN" style username. I'm trying to get someone who's onsite to test this theory tomorrow.
Assuming that that (full DN style username) solves that original problem, I was wondering: Would some specific version of Win2K3/AD not accept authenticate() (i.e., simple LDAP binds) using usernames of the form user@xxxxxxxxxxxx, but accept "cn=user,cn=users,dc=whatever,dc=com"?
Re. the 1st part of my post, it looks like what is happening is that I can authenticate with two DIFFERENT passwords, which happen to be the current password, and the password that was changed. In other words, if the password was "Foobar123", and my password reset webapp changes the password to "Foobar456", I can bind using ldifde using either of those two passwords, even after rebooting the AD machine!!
However, I can only login INTO WINDOWS using the current password.
Seems like the "LDAP subsystem" (if there is such a thing) in AD may be caching passwords persistently?
Jim
ohaya wrote:
Hi,.
I've written a web application for resetting passwords in Win2K3/AD using LDAP. This web app uses an LDAP 'modify' to change the user's 'unicodePwd' attribute, and it seems to work.
I was doing some testing today, testing with ldifde and doing simple binds, and I've run across a really strange problem: At least in one case, I have a test user named 'test1' (cn=test1,cn=users,dc=test,dc=com) where I can successfully do a simple bind using ldifde:
XXXXXXXXX1
XXXXXXXXX2
The ldifde command line is:
ldifde -f foo -t localhost -t 389 -d "dc=test,dc=com"
-a "cn=test1,cn=users,dc=test,dc=com" "XXXXXXXXXy"
where: y = 1 or 2
This behavior is repeatable, i.e., I can do it over and over, including even after rebooting the AD machine :(!!
However, when I try to login to the AD machine as "test1", I can only login using the "correct" password, as set by my password web app.
Has anyone run across something like this, or does anyone know what might be going on?
BTW, a little off-topic from this post (but more important to me :)), the reason that I was doing this testing with ldifde was because we have deployed this web app successfully in 3 different environments, but then we ran into a problem with it in a 4th environment today, so maybe this might be related:
In order to do the password modification, this web app connects to AD (using an SSL connection), then it uses an admin username/password to do an 'authenticate()'. After a successful authenticate(), it then does the password modification.
The original problem that I ran into today was that in this one environment (and only this one, so far), the authenticate() using the admin username/password is failing with an "invalid_credential" error, even though we KNOW that the admin username and password are valid.
I was doing the ldifde testing described at the beginning of this post because I was trying to determine why the admin usernamd/password authenticate() might be failing.
So, if ANYONE has any ideas about what this latter problem might be, I'd really appreciate if you could post. At this point, I'm really running out of ideas :(!!
Thanks in advance,
Jim
- Follow-Ups:
- Re: HELP! Really strange problem w/AD and LDAP/LDIFDE
- From: Joe Kaplan
- Re: HELP! Really strange problem w/AD and LDAP/LDIFDE
- References:
- Prev by Date: Re: Association Between Local Profile and Domain Login?
- Next by Date: Re: Trust relationship between this workstation and the primary do
- Previous by thread: HELP! Really strange problem w/AD and LDAP/LDIFDE
- Next by thread: Re: HELP! Really strange problem w/AD and LDAP/LDIFDE
- Index(es):
Relevant Pages
|
