Listing an LDAP Address from an NT Domain Name

Given the NT account name (DOMAIN \ username), is it possible to specify which LDAP address for this domain is used to search for user information?

My scenario: I have an asp.net application running on IIS that accepts both anonymous users and domain users. Anonymous users must be logged in, but domain users I check the server headers for the domain user name provided by IIS. I need to find some information from the active directory, such as email address, etc. It works for me if I specify the LDAP address in config, but I do not want it to support this additional configuration value, if I can avoid it.

+4
source share
1 answer

If all domains are part of the same forest, you should be able to perform a global directory lookup (GC: // instead of LDAP: //). You only get the partial attribute, but you can get the distinguished name and then the standard LDAP search: //.

If you are in a situation where you have different domains that are in different forests, then one simple way would be to create a NetBIOS domain name lookup table. For each forest, you search for the subtree CN = Partitions, CN = Configuration, DC = YourDomain, DC = com with the filter (netBIOSname = *), and you will return a list of domains in this forest. The dnsRoot attribute will provide you with the DNS domain name, and you can simply use this to bind or search for DNS in it and use the first address that you are contacting. Or you can use dnsRoot to create a System.DirectoryServices.ActiveDirectory.DirectoryContext using DirectoryContextType DirectoryServer to get a link to a domain controller. Or you can use nCName (gives you the name of the domain context).

Perhaps I can help more if you can provide more detailed information or if any of this is unclear.

Additionally:

  • You can get a DirectoryEntry by doing "serverless binding" by simply providing the display name of the object in the directory. For instance. "LDAP: // CN = User1, CN = Users, DC = domain_name, DC = com." This will automatically detect the appropriate domain controller and bind it to get the object.
  • If you perform a search using DirectorySearcher and you do not provide a SearchRoot object, it will automatically bind to the root of the current domain. You can provide SearchRoot to narrow your search, but you don't need to.
  • If you absolutely need to get the name of the current domain, you can associate it with the RootDSE object ("LDAP: // RootDSE") and get the value of the defaultNamingContext attribute. This will return the DC = yourdomain, DC = com bit.

Honestly, a more general code is probably not worth the pain if you are not sure that you will need it, because it will depend on the structure of your domains and forests. For instance. if you have two forests, there is trust between them: you will not know this until you have two forests, and the decision will depend on it. There is an insightful little maxim in agile development that eludes me, but it goes along the lines, do not code what you do not need now.

Here is a console program that will perform such a search:

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.DirectoryServices; namespace SearchDirectory { class Program { static void Main(string[] args) { string user = @"YOURDOMAIN\yourid"; using (DirectorySearcher ds = new DirectorySearcher()) { ds.SearchScope = SearchScope.Subtree; ds.Filter = String.Format("(&(objectClass=user)(objectCategory=person)(sAMAccountName={0}))", user.Split('\\')[1]); ds.PageSize = 1000; using (SearchResultCollection src = ds.FindAll()) { foreach (SearchResult sr in src) Console.WriteLine(sr.Properties["distinguishedName"][0].ToString()); } } Console.WriteLine("\r\nPress a key to continue..."); Console.ReadKey(true); } } } 

I cropped a few corners, but you need to start. My advice is to make it work in a console program, and then move the class to an ASP.NET project. There are many odd System.DirectoryServices errors that can throw you around, and using S.DS inside ASP.NET can be very funny, so it's best to know how your code works before you wrap it in all this ASP.NET appeal.

+4
source

All Articles