Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm troubleshooting a linux-based hardware firewall for a client. This hardware firewall connects to ActiveDirectory for Single SignOn authentication.

ActiveDirectory is largley just a perverted version of LDAP to the best of my knowledge, and uses the same BindDN syntax -- correct me if I'm wrong.

The client has configured this as their BindDN -- actual strings have been replaced for privacy reasons but special characters and whitespace remain. "somerandomplace\fubar fubaz"

This does not seem to be valid BindDN syntax to me and I've worked with LDAP before, but when we hit the Test button to test this BindDN, the test succeeds. When I change just one of the characters in the BindDN and run the test again, the test fails.

I'm trying to figure out what the problem is here:

A) That I don't completely understand the nuances of BindND and associated syntax


B) That the appliance fails to properly verify inputs and is falsely identifying the test as a success

share|improve this question

LDAP is just a protocol. And like Greg said, Microsoft's implementation of it in Active Directory is compliant to the various RFCs that define it. (+1 to him)

Doug's answer is partially correct in that he gives one example of a valid Bind DN. But Active Directory specifically allows for the Bind DN value to be sent as other forms as well. The best form to use in my opinion is the UserPrincipalName (UPN) which is usually in the following form unless it has been explicitly changed.

  • <sAMAccountName>@<domain FQDN> (e.g.

The benefit of this over a normal DN value is that the user account can be moved within AD and the application using the credential doesn't have to update it's config.

It can also be in the legacy NetBIOS form which looks like this and appears to be what your client is using.

  • <Domain NetBIOS Name>\<sAMAccountName> (e.g. CONTOSO\user1)

This has the same benefit as the UPN value, but again is considered legacy. NetBIOS names should have died a long time ago, but that's a rant for another thread.

share|improve this answer
Thank you! This comment about the 3 forms of DN is the puzzle piece I was missing. – mehaase Jul 16 '14 at 13:54
Had no idea you could use UPN as an LDAP DN. Sweet. – Jonathon Reinhart Oct 30 '15 at 16:42
I'm amazed at how many application vendors who only support external auth against AD (via LDAP) don't know this either. – Ryan Bolger Oct 30 '15 at 17:28

The bind DN would be CN=username,CN=Users,DC=yourdomain,DC=com for a user located in the Users container.

It might work if you just put in the username as well since it probably searches for sAMAccountname property if its Active Directory aware. Just don't preface the username with the domain.

share|improve this answer

Microsoft's LDAP implementation is compliant. Any character is valid in a DN. If there are special characters, they must be escaped. Whitespace does not need to be escaped unless it is leading or trailing. A character can be escaped with either a backslash or the \nn hex equivalent.

Distinguished Names

space or # character at the beginning of a string    0x20
space character at the end of a string    0x20
,    comma    0x2C
+    plus sign    0x2B
"    double quote    0x22
\    backslash    0x5C
<    left angle bracket    0x3C
>    right angle bracket    0x3E
;    semicolon    0x3B
LF   line feed    0x0A
CR   carriage return    0x0D
=    equals sign    0x3D
/    forwards slash    0x2F 
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.