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

I don't suppose your web server LDAP stack can do Windows secure binds, can
it? Like I said, I'm really unsure as to what is going on, but I can't
remember seeing this issue when Windows auth is used in LDAP (GSS-SPNEGO
SASL). As a .NET guy, I'm generally always using the MS LDAP APIs on a
Windows OS machine to do my LDAP, so I generally don't run into these
problems. I only use simple bind for ADAM, but I don't remember seeing
issues with invalid passwords being accepted there either.

It may also be worth it to you to open a real PSS ticket and see if someone
there can provide a more satisfactory answer.

Sorry I was less helpful this time, but perhaps that username syntax stuff
will be useful. :)

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@xxxxxxx> wrote in message
news:uV6SSBqPHHA.140@xxxxxxxxxxxxxxxxxxxxxxx
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 :(,
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 :)...

Thanks,
Jim



Joe Kaplan wrote:
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@xxxxxxxxxx) 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. :) 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.



.

Relevant Pages

  • Re: HELP! Really strange problem w/AD and LDAP/LDIFDE
    ... UPN username and perhaps that is behaving weirdly in this environment due to ... receives the simple bind. ... What we're thinking is that if THAT is the case, and if the DNS ... like when the simple LDAP bind is ...
    (microsoft.public.windows.server.active_directory)
  • Re: HELP! Really strange problem w/AD and LDAP/LDIFDE
    ... One of the things that we were theorizing about was that AD might be doing different processing, depending on the format of the username, when it receives the simple bind. ... This 2nd standalone AD is the one that my web app is accessing using LDAP, and I *think* that the domain name for this 2nd AD is the same as the original domain, i.e., also "foo.foo1". ...
    (microsoft.public.windows.server.active_directory)
  • Re: What is DirectoryServices.AuthenticationTypes.None
    ... It is supposed to mean to use LDAP simple bind. ... If you supply username and password, ...
    (microsoft.public.dotnet.security)
  • Re: Query AD from DMZ via LDAP?
    ... You don't really need ADAM for this unless you need LDAP simple bind, ... authentication to apps on the public internet, ...
    (microsoft.public.windows.server.active_directory)
  • Re: HELP! Really strange problem w/AD and LDAP/LDIFDE
    ... Windows secure bind: ... any LDAP client doing a bind can use those username formats with AD ... admin username in the authenticate() should be a "full DN" style username. ... I was doing some testing today, testing with ldifde and doing simple ...
    (microsoft.public.windows.server.active_directory)
Loading