HELP! Really strange problem w/AD and LDAP/LDIFDE

ohaya · Guest

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 frown

!!

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 smile

),
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 frown

!!

Thanks in advance,
Jim

ohaya · Guest

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@whatever.com. 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@whatever.com, 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:

Joe Kaplan · Guest

I'm not at all sure what's going on with the passwords. I can tell you what
the rules are for usernames doing different types of binds in AD is though.
:)

Simple bind: full DN (as per LDAP spec), userPrincipalName (user@domain.com)
and NT name (domain\user)
Windows secure bind (GSS-SPNEGO): userPrincipalName, NT name, plain user
name (user)

I generally use UPN all the time, as it works with both binding syntaxes and
DNs are a pain to type. smile

Since this is supported directly by the server
itself, any LDAP client doing a bind can use those username formats with AD
for simple bind.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"ohaya" <ohaya@cox.net> wrote in message
news:%23B7y3WpPHHA.320@TK2MSFTNGP06.phx.gbl...

ohaya · Guest

Joe K.,

As mentioned in my earlier posts, I'm having someone try the full DN
username tomorrow (my app uses a config file, so they just have to
change the username there, not in code) to see if that works at this one
site where using the UPN-formatted username gave us the
INVALID_CREDENTIALS exception (BTW, we tried using the NT-formatted name
today, and that threw an exception also), and will post back the results.

If the full DN doesn't work, then I'm kind of out of ideas on this one
frown

, because as I also mentioned, we've had this same exact web app
running in several other environments (also with Win2K3/AD).

The other problem, with the two different passwords working, with
ldifde, is less of a priority for me, although it actually seems the
stranger (and scarier) of the two problems, to me smile

...

Thanks,
Jim

Joe Kaplan wrote: