cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5385
Views
2
Helpful
3
Replies

Help understanding LDAP strings

AmishBill
Level 1
Level 1

I have picked up some of the LDAP string syntax, but I can’t find anything that explains what’s needed for specific instances.

In the context of a Duo Search DN, How would I specify this AD OU and why?

mydomain.local

  • MyCo
    • MyUsers

I think it should be:
search_dn=OU=MyUsers,OU=MyCo,DC=mydomain,DC=local

But the Barracuda folks tell me that their box is getting a “Failed to communicate with any Active Directory server” error

1 Accepted Solution

Accepted Solutions

DuoKristina
Cisco Employee
Cisco Employee

Hello again AmishBill!

Given your sample OU hierarchy the search DN you’ve constructed is correct.

The “Failed to communicate with any Active Directory server” usually indicates that either the Authentication Proxy literally can’t contact the domain controller specified in the [ad_client] section of authproxy.cfg, or that the LDAP account username or password configured in that file that’s used to connect to the AD domain controller is incorrect.

Make sure that the Authentication Proxy is able to communicate with the domain controller over port 389 (636 if using LDAPS, or whichever port you specified if you’re using a custom one), that the service_account_username and service_account_password are correct (as is the DN for the account in bind_dn if you’re using that parameter), and that the account you’re using has the rights to bind to AD and look up information about users in that domain.

With respect to the search_dn, make sure it’s not set too low in the hierarchy. You want it at a level above any users (and the OUs or containers that hold them) who will log in with Duo, AND above the service account used in ad_client, AND above any level that contain groups if you’re doing any filtering or restrictions by group.

By way of example, if you have search_dn=OU=MyUsers,OU=MyCo,DC=mydomain,DC=local but the service_account_username user is in an different subtree (like say OU=ServiceAccounts,OU=MyCo,DC=mydomain,DC=local) the Authentication Proxy may not locate it in an LDAP search.

Duo, not DUO.

View solution in original post

3 Replies 3

DuoKristina
Cisco Employee
Cisco Employee

Hello again AmishBill!

Given your sample OU hierarchy the search DN you’ve constructed is correct.

The “Failed to communicate with any Active Directory server” usually indicates that either the Authentication Proxy literally can’t contact the domain controller specified in the [ad_client] section of authproxy.cfg, or that the LDAP account username or password configured in that file that’s used to connect to the AD domain controller is incorrect.

Make sure that the Authentication Proxy is able to communicate with the domain controller over port 389 (636 if using LDAPS, or whichever port you specified if you’re using a custom one), that the service_account_username and service_account_password are correct (as is the DN for the account in bind_dn if you’re using that parameter), and that the account you’re using has the rights to bind to AD and look up information about users in that domain.

With respect to the search_dn, make sure it’s not set too low in the hierarchy. You want it at a level above any users (and the OUs or containers that hold them) who will log in with Duo, AND above the service account used in ad_client, AND above any level that contain groups if you’re doing any filtering or restrictions by group.

By way of example, if you have search_dn=OU=MyUsers,OU=MyCo,DC=mydomain,DC=local but the service_account_username user is in an different subtree (like say OU=ServiceAccounts,OU=MyCo,DC=mydomain,DC=local) the Authentication Proxy may not locate it in an LDAP search.

Duo, not DUO.

Thanks for the help.
I’m using this as my current string in the ad_client section
search_dn=OU=CompName,DC=MyDomain,DC=local
All our group and user OUs live under CompName, so that should be high enough.

Where does CN enter into these strings, and what exactly is it?

The “CN” typically refers to the “Common Name” of an Active Directory object.

So, if your AD hierarchy for a given user was:

mydomain.local

  • MyCo
    • MyUsers
    • -John Doe

The common name for that user would be “CN=John Doe” and the user’s full distinguished name (DN) would be “CN=John Doe,OU=MyUsers,OU=MyCo,DC=mydomain,DC=local”.

Microsoft also decided to confuse people by reusing “CN” for Containers, which are hierarchy objects similar to OUs but they apply policies differently than OUs. The built-in organizational folders in your domain like “Users” are actually containers, so the DN for a user inside the Users container would be “CN=Bob Soandso,CN=Users,DC=mydomain,DC=local” (note that “CN” is used twice, but with different meaning).

If you’re still experiencing connectivity issues from your Authentication Proxy to your Active Directory domain controller even after checking my other troubleshooting suggestions, I suggest you contact Duo Support. One of our TSEs can review the debug log output with you to try to pinpoint the issue.

Duo, not DUO.
Quick Links