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

A user of our product came out with a problem which was caused by the DN of Configuration object in AD. We had a rather static lookup method to find Configuration object, thus it failed.

Let's say the domain name of AD is Therefore, the expected DN of configuration should be CN=Configuration,DC=foo,DC=bar,DC=example,DC=com, right?

But somehow, this user's DN of configuration has one value missing: CN=Configuration,DC=bar,DC=example,DC=com.

Do you know how can we reproduce this issue (or is it commonly implemented?)?

share|improve this question

migrated from Nov 11 '11 at 16:47

This question came from our site for professional and enthusiast programmers.

up vote 1 down vote accepted

It seems that the root configuration is associated with the domain and foo is just a subdomain. To be sure you can get the configuration distinguished name programatically:

// you may need to specify username/password here as well with another 
// constructor overload.  Try any of the following:
// DirectoryEntry root = new DirectoryEntry("LDAP://RootDSE", user, pwd); 
// DirectoryEntry root = new DirectoryEntry("LDAP://ADServer/RootDSE"); 
// DirectoryEntry root = new DirectoryEntry("LDAP://ADServer/RootDSE", user, pwd); 
DirectoryEntry root = new DirectoryEntry("LDAP://RootDSE"); 

string configDN = root.Properties["configurationNamingContext"].Value.ToString();
share|improve this answer

Your Answer


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