Does System.DirectoryServices.DirectoryEntry contain a constructor that actually uses "domain\username" with Ldap?

Microsoft has a general purpose KB article (Q316748) describing how to authenticate against Active Directory using the DirectoryEntry object. In their example they produce a username value by concatenating the domain name and username into the standard NetBIOS format("domain\username") and passing that as a parameter to the directory entry constructor:

string domainAndUsername = domain + @"\" + username;
DirectoryEntry entry = new DirectoryEntry(_path, domainAndUsername, pwd);

It recently came to our attention that the domain part of the username was being completely ignored and in multiple environments I've confirmed this behavior. The username and password are in fact being used, as authentication fails when they're invalid, but any arbitrary value can be supplied for the domain name and authentication passes. At a glance I'd theorize this format works for WinNT based directory access but the domain part is ignored for LDAP.

A check on google shows many LDAP examples passing a "domain\username" value to the DirectoryEntry object so I've either messed something up in my configuration or there's a lot of people confused by the KB article. Can anyone confirm this is the expected behavior or开发者_如何学Python recommend a way to accept "domain\username" values and authenticate against Active Directory with them?

Thanks,

---

The short answer: When the path parameter of the DirectoryEntry constructor contains an invalid domain name the DirectoryEntry object will (after an unsuccessful search for the invalid domain in the forrest) attempt a fall back by dropping the domain part of the username parameter and attempt connection using the plain username (sAMAccountName).

The long answer: If the domain name specified in the username parameter is invalid but the user exists in the domain specified in the path parameter the user will be authenticated (through the use of the fallback). However, if the user exists in another domain in the forrest than the one specified in the path parameter authentication will only succeed when the domain part of the username parameter is included and correct.

There are four different ways of specifying the username parameter when dealing with DirectoryEntry-objects:

• Distinguished Name (CN=Username,CN=Users,DC=domain,DC=local)
• NT Account Name (DOMAIN\Username)
• Plain Account Name/sAMAccountname (username)
• User Principal Name (generally username@domain.local)

Let me illustrate with an example:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using System.DirectoryServices;

namespace DirectoryTest
{
  class Program
  {

    private static Int32 counter = 1;

    static void Main(string[] args)
    {
      TestConnection();
    }

    private static void TestConnection()
    {
      String domainOne = "LDAP://DC=domain,DC=one";
      String domainOneName = "DOMAINONE";
      String domainOneUser = "onetest";
      String domainOnePass = "testingONE!";

      String domainTwo = "LDAP://DC=domain,DC=two";
      String domainTwoName = "DOMAINTWO";
      String domainTwoUser = "twotest";
      String domainTwoPass = "testingTWO!";

      String invalidDomain = "INVALIDDOMAIN";

      // 1) This works because it's the correct NT Account Name in the same domain:
      Connect(domainOne, domainOneName + "\\" + domainOneUser, domainOnePass);

      // 2) This works because username can be supplied without the domain part
      // (plain username = sAMAccountName):
      Connect(domainOne, domainOneUser, domainOnePass);

      // 3) This works because there's a fall back in DirectoryEntry to drop the domain part
      // and attempt connection using the plain username (sAMAccountName) in (in this case)
      // the forrest root domain:
      Connect(domainOne, invalidDomain + "\\" + domainOneUser, domainOnePass);

      // 4) This works because the forrest is searched for a domain matching domainTwoName:
      Connect(domainOne, domainTwoName + "\\" + domainTwoUser, domainTwoPass);

      // 5) This fails because domainTwoUser is not in the forrest root (domainOne)
      // and because no domain was specified other domains are not searched:
      Connect(domainOne, domainTwoUser, domainTwoPass);

      // 6) This fails as well because the fallback of dropping the domain name and using
      // the plain username fails (there's no domainTwoUser in domainOne):
      Connect(domainOne, invalidDomain + "\\" + domainTwoUser, domainTwoPass);

      // 7) This fails because there's no domainTwoUser in domainOneName:
      Connect(domainOne, domainOneName + "\\" + domainTwoUser, domainTwoPass);

      // 8) This works because there's a domainTwoUser in domainTwoName:
      Connect(domainTwo, domainTwoName + "\\" + domainTwoUser, domainTwoPass);

      // 9) This works because of the fallback to using plain username when connecting
      // to domainTwo with an invalid domain name but using domainTwoUser/Pass:
      Connect(domainTwo, invalidDomain + "\\" + domainTwoUser, domainTwoPass);
    }

    private static void Connect(String path, String username, String password)
    {
      Console.WriteLine(
        "{0}) Path: {1} User: {2} Pass: {3}",
        counter, path, username, password);
      DirectoryEntry de = new DirectoryEntry(path, username, password);
      try
      {
        de.RefreshCache();
        Console.WriteLine("{0} = {1}", username, "Autenticated");
      }
      catch (Exception ex)
      {
        Console.WriteLine("{0} ({1})", ex.Message, username);
      }
      Console.WriteLine();
      counter++;
    }
  }
}

In the example above domain.one is the forrest root domain and domain.two is in the same forrest as domain.one (but a different tree naturally).

So to answer your question: Authentication will always fail if the user in not in the domain that we're connecting to and no or an invalid domain name is specified in the username parameter.

---

I have two applications which uses DirectoryEntry(_path, domainAndUsername, pwd); constructor and I don't have any authentication problem. Each application is installed on a different customer, both with very (very) large domain structures.