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

I think you may be on to something here, as there may be some additional
involvement with DNS and/or the GC in order to service the simple bind with
UPN username and perhaps that is behaving weirdly in this environment due to
something in its "checkered" past. :)

However, I'm clueless on this level of detail, so I'd want someone from MS
(or a more useful MVP type :)) to step in and hopefully elaborate on what's
going on under the hood.

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:OqFhvt1PHHA.2340@xxxxxxxxxxxxxxxxxxxxxxx
Hi,

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.

In particular, we were thinking that if the username was in the UPN format
(e.g., user@xxxxxxxxxxxx), that maybe AD does something extra, like do a
DNS lookup on the "domain" part of the username (e.g., "whatever.com").

What we're thinking is that if THAT is the case, and if the DNS
configuration at this one site is either different or just plain messed
up, that that might be why I was getting the exception when I tried the
simple bind using the UPN-formatted username.


The other possibility is that this particular site was set up sort of
strangely...

There was originally an AD/Windows domain already setup there. This
original, "real" Windows domain is something like "foo.foo1".

For this testing, my group needed to have an AD instance for my web app to
access, but the site manager did not want to have my web app accessing the
original, "real" domain controller.

So, they setup a 2nd, standalone AD, with it's own associated DNS server
(on the same physical machine). 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".
This machine is setup to point to its own IP address as the only DNS
server, and there was no DNS forwarding that I could see.

The usernames I was using to bind were in the "foo.foo1" domain, i.e.,
"theuser@xxxxxxxx" or "cn=theuser,cn=users,dc=foo,dc=foo1".

The test client/workstations are joined to the 1st, original AD/domain.
DNS settings on the client/workstations only point to the DNS server on
the 1st AD.

I *think* that the above was the configuration... I guess it's all kind
of "fuzzy", because I was *SO* happy to just get my web app working :).

Anyway, assuming that my memory is at least somewhat accurate, and that
the above is what the configuration looks like, I'm thinking that maybe
something weird might be happening, like when the simple LDAP bind is
received by the 2nd AD, and the username happens to be UPN-formatted, the
2nd AD might think that it needs to authenticate the user against the 1st
AD, instead of authenticating to itself. Conversely, if the username in
the simple BIND is in the full DN format, maybe the 2nd AD then does the
authentication "locally".


Is anyone aware of any mechanism like this in AD?

Thanks,
Jim



ohaya wrote:
Joe (et al),

I ended having to go onsite, because our other guys were at different
sites, and I tested, changing the admin username format in the LDAP
(simple) bind from the UPN format to the full DN format, and guess what?

The bind *WORKED*!!

We checked the AD at this one site, and it looks to be exactly the same
Windows version, Windows 2003 Enterprise SP1, as the other FIVE sites
that I've installed this same software, so we are REALLY puzzled about
this.

I guess that I'm happy that it's working, but am still really befuddled
as to why we had to use the full DN username format for the admin bind.

So to summarize:

- Six different environments, all using Win2K3 Enterprise SP1 with AD

- First five sites, my web app is configured with a UPN-formatted admin
username to do the simple LDAP bind (myadmin@xxxxxxxxxxxx)

- This last site, when I configured my web app to use a UPN-formatted
admin username (myadmin@whatever,com), the simple LDAP bind fails with
INVALID_CREDENTIALS. When I change the admin username to full DN format
(cn=myadmin,cn=users,dc=whatever,dc=com), the simple LDAP bind succeeds.

- Reminder: Using both UPN-formatted or full DN-formatted admin usernames
with ldifde works in all six environments.

Question/Puzzle: What is it about that sixth site that allows the simple
LDAP binds with the admin username to only work if the username is using
full DN format?

Jim




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


.

Relevant Pages

  • Re: HELP! Really strange problem w/AD and LDAP/LDIFDE
    ... I don't suppose your web server LDAP stack can do Windows secure binds, ... I only use simple bind for ADAM, ... Sorry I was less helpful this time, but perhaps that username syntax stuff ...
    (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)
  • [NEWS] BIND 9 DNS Cache Poisoning
    ... BIND 9 DNS Cache Poisoning ... source UDP port and DNS transaction ID can be effectively predicted. ... address of the target name server), and the destination UDP port (53 the ...
    (Securiteam)
  • [UNIX] Multiple Remote Vulnerabilities in BIND4 and BIND8
    ... ISS X-Force has discovered several serious vulnerabilities in the Berkeley ... Internet Name Domain Server (BIND). ... majority of DNS servers on the Internet. ... deployed recursive DNS servers on the Internet. ...
    (Securiteam)