05-05-2017 08:25 AM
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
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
Solved! Go to Solution.
05-09-2017 02:18 PM
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.
05-09-2017 02:18 PM
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.
05-24-2017 08:03 AM
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?
05-25-2017 09:45 AM
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
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide