Mombu the Microsoft Forum sponsored links

Go Back   Mombu the Microsoft Forum > Microsoft > Windows 2003 Server (TECHNET) > ADSimple bind - Why user DN fails but UPN-format works
User Name
Password
REGISTER NOW! Mark Forums Read

sponsored links


Reply
 
1 13th July 09:45
ohaya
External User
 
Posts: 1
Default ADSimple bind - Why user DN fails but UPN-format works


Hi,

We have one AD instance where we ran into a strange problem.

We attempted doing simple binds using both ldifde and ldp. Originally,
we used user DN for the simple bind (e.g., -a
"cn=username,cn=users,dc=domain,dc=com", and the simple bind failed with
"Invalid Credentials".

Just by accident, we did the simple bind using a UPN-formatted user name
(e.g., username@domain.com), and the simple bind succeeded?

We have another AD instance, and we can use a simple bind with the user
DN, and don't need to use the UPN format.

Can anyone tell me what this might be?

Thanks,
Jim
  Reply With Quote


  sponsored links


2 13th July 09:47
joe kaplan mvp - adsi
External User
 
Posts: 1
Default ADSimple bind - Why user DN fails but UPN-format works


With AD, simple bind support UPN, NT name (domain\user) and DN as the
username. That's why UPN works.

If I had to guess, I'd say that your DN is wrong. Did you verify that you
definitely have the right DN for the user being passed in (as returned by
ldp.exe or similar search tool)?

Joe K.
  Reply With Quote
3 13th July 09:51
ohaya
External User
 
Posts: 1
Default ADSimple bind - Why user DN fails but UPN-format works


Joe,

Sorry to keep bothering you all with these "odd" AD questions ...

Yes, we tried the DN and the bind using both ldifde and ldp.exe, and I
have two other colleagues "eyeballing" the typing.

I also reviewed the output from an ldifde that worked, to verify the DN
was correct. FYI, I ran the ldp.exe both on the AD machine itself and
from another Windows machine that was not part of the Windows domain.
In both cases, I had to use the UPN-formatted username in order to do a
successful simple bind.

The strange thing was that we can successfully bind with another AD
instance that we have, that was *supposedly* setup with the same
baseline installation.

Jim
  Reply With Quote
4 13th July 09:54
joe kaplan mvp - adsi
External User
 
Posts: 1
Default ADSimple bind - Why user DN fails but UPN-format works


Ok, that's pretty weird. I can't reproduce that behavior and have no idea
what the problem is. You might try auditing logon events on the DC and see
if you can see something in the security log that tells you more.

The only other thing I can possibly think of is that you have an object with
another naming attribute that takes arbitrary text (like displayName) with
the same value. That seems like an odd case, who knows? Another thing to
look out for might be escape sequences in the DN (in case your CN has commas
or other DN separator characters).

If you figure it out, please let me know. I'm very curious.

Maybe Dmitri knows and is reading this...

Joe K.
  Reply With Quote
5 13th July 09:55
ohaya
External User
 
Posts: 1
Default ADSimple bind - Why user DN fails but UPN-format works


Joe,

I know it's weird ...

I can't duplicate the problem on a different test AD/2003 I have at home
either. I've even tried some odd stuff like changing the
userPrincipalName in the AD so that the first part is be different than
the CN, I could still do a simple bind using either the full user DN or
the UPN.

When you say "try auditing logon events on the DC", is there something I
need to enable this? If so, can you describe?

As I mentioned, I did a ldifde to export, and I couldn't see anything
strange in there.

I definitely will post back if I find anything.

Thanks for your help.

Jim
  Reply With Quote
6 13th July 10:01
joe kaplan mvp - adsi
External User
 
Posts: 1
Default ADSimple bind - Why user DN fails but UPN-format works


In the local security policy, go to the auditing section and enable both
success and failure audits of logon events. This will populate the security
event log with lots of gory details about what's going on with your
authentications. This is also something I would consider a best practice
for most Windows server deployments.

Joe K.
  Reply With Quote
7 13th July 10:06
ohaya
External User
 
Posts: 1
Default ADSimple bind - Why user DN fails but UPN-format works


Hi,

I'm starting to wonder if it might be something OUTSIDE of the
configuration of AD itself might be causing this behavior?

Specifically, I'm wondering whether maybe something like the AD-to-DNS
server relationship is different between the two different AD instance
configurations?

For example, if one configuration were using an integrated DNS server
vs. the other using a separate DNS server, or maybe the DNS
configuration (Network->Advanced->DNS tab) settings is different between
the two AD machines?

For reference, the test AD instance that I have here at home, which
doesn't exhibit this "UPN format only" problem, was built with an
integrated DNS server configuration (i.e., I installed MS DNS server
when I did the DCPROMO to turn the machine into an AD) with the default
network/DNS settings from the Win2K3 installation.

I've asked the guys at work to check on this next week, but I was
wondering if anyone here might have an idea if something like this might
be causing the difference? Would something in the DNS configuration
cause AD not to be able to accept userDN for simple binds, whereas UPNs
would work?

I know that this is a 'long shot', but I'm kind of running out of ideas
!!

Thanks,
Jim
  Reply With Quote
8 13th July 10:07
joe richards mvp
External User
 
Posts: 1
Default ADSimple bind - Why user DN fails but UPN-format works


I agree with JoeK that this absolutely should be working, it would indicate to
me that there is something odd with the DN, a space a comma, who knows,
something that is not being handled properly. You can also test with adfind as
it will do simple binds as well. It would look something like

{all one line}

adfind -default -s base -dn -simple -u CN=someuser,OU=TestOU,DC=joe,DC=com -up
somepassword


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
http://www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
  Reply With Quote
9 13th July 10:20
ohaya
External User
 
Posts: 1
Default For Joe K and Dmitri Gavrilov was


Hi,

I've been continuing to search for an answer for my original question,
and I ran across the following thread:

http://groups.google.com/group/microsoft.public.windows.server.active_directory/browse_thread/thread/ed48cf78b43fde15/9d0a7b03889d2658?lnk=st&q=simple+bind+upn+fails&rnum=3#9d0a7b03889d2658

"ADAM authentication failure" original post on 2/17/06.

In a post dated 2/19/06:

http://groups.google.com/group/microsoft.public.windows.server.active_directory/msg/bf223f372530e11e

Dmitri said:

"If you have two users whose displayName is Dmitri, then you won't be
able to
bind. Same for UPN."

This *SEEMS* to come *CLOSE* to the problem that I am seeing, where I
cannot do a simple bind, but in my case using a DN, but I *CAN* do a
simple bind, using a UPN, i.e., it seems just the opposite?

So, I'm wondering if there might be a case where a simple bind would not
work, using a DN, since this is AD and not ADAM, and according to the
quoted part of that last post, the order of formats is different between
AD and ADAM?

Jim
  Reply With Quote
10 13th July 10:31
ohaya
External User
 
Posts: 1
Default Solved was ]


Hi,

Inspiration struck tonight, and it turns out that this whole
problem/question was because of a stupid thing that I forgot .

It turns out that the "CN=" part of the user's DN was NOT what I thought
it was .

As mentioned earlier, we were able to do the simple bind using a UPN,
e.g., smithj@mydomain.com. Earlier, when we were trying to do the
simple bind using a DN, we had been trying
"CN=smithj,CN=Users,DC=mydomain,DC=com".

Well, it turns out that that user's DN is actually "CN=John
Smith,CN=Users,DC=mydomain,DC=com" !!!

Sorry for all the posts about this. This was really a stupid error on
my part, not checking what the ACTUAL DN was in AD!

Thanks for all of the suggestions,
Jim
  Reply With Quote
Reply


Thread Tools
Display Modes




Copyright 2006 SmartyDevil.com - Dies Mies Jeschet Boenedoesef Douvema Enitemaus -
666