Tags: authentication, ive, machine, mechanism, net, occurs, security, server, staging, unknown

AD - The authentication mechanism is unknown

On .Net » .Net Security

7,754 words with 11 Comments; publish: Sun, 06 Jan 2008 08:04:00 GMT; (10046.88, « »)


I've a problem using AD but it only occurs in the server. In my machine and in staging it works fine.

The problem is"The authentication mechanism is unknown".

My code is

DirectoryEntry rootEntry =new DirectoryEntry(ConfigurationSettings.AppSettings["ActiveDirectoryPath"], ConfigurationSettings.AppSettings["ADUser"], ConfigurationSettings.AppSettings["ADPassword"]);DirectorySearcher search =new DirectorySearcher(rootEntry);search.PropertiesToLoad.Add("numColaborador");search.Filter ="(|(cn=" + tokens[1] +")(sAMAccountName=" + tokens[1] +"))";SearchResult result = search.FindOne();collaboratorNum = search.FindOne().GetDirectoryEntry().Properties["numColaborador"].Valueas string;

I read in other forum how i can resolve this. I've to change the attribute userName from system to machine in the tag processModel at the file machine.config.

The problem with this, is it will apply the changes to all sites, and i don't know how they will work after that.

All Comments

Leave a comment...

    • What's the value of ADUser? If it is a valid user account in the domain then you shouldn't have to switch process model and stuff.

      Do you have different web configs for prod and test?

      Can you pinpoint the line on which the error occurs? Given that your settings for path, username and password is correct, then my best guess is that the call to GetDirectoryEntry won't connect with explicit credentials, but instead use those of the current thread.

      Try to fetch the result's DirectoryEntry with explicit credentials like this:

      DirectoryEntry resEntry =new DirectoryEntry(search.FindOne().Path, ConfigurationSettings.AppSettings["ADUser"], ConfigurationSettings.AppSettings["ADPassword"]);collaboratorNum = resEntry.Properties["numColaborador"].Valueas string;
      #1; Sun, 06 Jan 2008 08:06:00 GMT
    • Thaks for the quick response.

      The ADUser is valid and the difference beteween test and prod web.config file are the keys connecionString and ActiveDirectotyPath for the different ambients.

      I put your suggest in my code, so now it is:

      DirectoryEntry rootEntry = new DirectoryEntry(ConfigurationSettings.AppSettings["ActiveDirectoryPath"], ConfigurationSettings.AppSettings["ADUser"], ConfigurationSettings.AppSettings["ADPassword"]);

      DirectorySearcher search = new DirectorySearcher(rootEntry);


      search.Filter = "(|(cn=" + tokens[1] + ")(sAMAccountName=" + tokens[1] + "))";

      SearchResult result = search.FindOne();

      DirectoryEntry resEntry = new DirectoryEntry(search.FindOne().Path, ConfigurationSettings.AppSettings["ADUser"], ConfigurationSettings.AppSettings["ADPassword"]);

      collaboratorNum = resEntry.Properties["numColaborador"].Value as string;

      The error occurs when is calledsearch.FindOne();

      #2; Sun, 06 Jan 2008 08:07:00 GMT
    • Why do you call FindOne twice? If you break it down in more lines it will be easier for you to spot the error. But to start with, try modifying the code like this:

      SearchResult result = search.FindOne();DirectoryEntry resEntry =new DirectoryEntry(result.Path, ConfigurationSettings.AppSettings["ADUser"], ConfigurationSettings.AppSettings["ADPassword"]);collaboratorNum = resEntry.Properties["numColaborador"].Valueas string;

      Now, put a breakpoint in the FindOne line and do one step. Make sure you get a valid object in result (i.e. that the query actually returns). You can for instance put a watch on result.Path to make sure it is LDAP://servername/distinguishedname

      #3; Sun, 06 Jan 2008 08:08:00 GMT
    • The two called to FindOne() method it's a error, when i modify the code.

      I modify the code again like your suggestion.

      In my machine i see it fails if i use DirectoryEntry resEntry =new DirectoryEntry(...), and works ok if use DirectoryEntry resEntry = result.GetDirectoryEntry().

      Then, i'm using the second option, first doesn't have resEntry.Properties["numColaborador"].

      Now, i'm waiting for other guy put this on production, to see the the results, and where it really fails on production.

      When i've news, i tell you.

      #4; Sun, 06 Jan 2008 08:09:00 GMT
    • Strange. A DirectoryEntry should contain all properties of the object it is pointing to, unless you access it from the global catalog.

      Can it be that the entry you find does not have this property (numColaborador) set?

      #5; Sun, 06 Jan 2008 08:10:00 GMT
    • "unless you access it from the global catalog."

      Can you explain it?

      "Can it be that the entry you find does not have this property (numColaborador) set?"

      The propety can be null, but this is not the problem. It fails before of read that, and it fails too with a user with a valid value in this field.

      #6; Sun, 06 Jan 2008 08:10:00 GMT
    • Is everything working when you are using GetDirectoryEntry? Or do you still get the authentication mechanism is unknown?

      I did a little test and it showed that GetDirectoryEntry is perfectly valid to do in this context. It will inherit the credentials given to the DirectorySearcher, from the search root (initial DirectoryEntry). So that's just fine.

      You are probably not using the global catalog if you don't know what it is. To do this, use the prefix GC:// instead of LDAP://. Using the global catalog could improve read performance, but you can only access the standard attributes of each class.

      #7; Sun, 06 Jan 2008 08:12:00 GMT
    • I was comparing my application with other from a friend that uses the same AD and same user.

      The DirectoryEntry rootEntry = new DirectoryEntry(...) at the begin, gives different values.

      In my project the property 'SchemaEntry' doesn't have some values.

      The difference i found isthe user used to create a DirectoryEntry doesn't have domain before the username.

      The user i send at filter of the search is in lowercase.

      I change this two things and now in localhost and staging i have correct values. I'm waiting to see it on production.

      #8; Sun, 06 Jan 2008 08:13:00 GMT
    • casing on username is not important (but on password of course). However, you always need to prefix your username with domainName\

      Like: "fabrikam\admin"

      If you had asked me this from the start I could have told you

      #9; Sun, 06 Jan 2008 08:14:00 GMT
    • Ok, it's confirmed. The problem i wasn't using the prefix domain.

      Now i've other problem, getting the value of NumColaborador, but doesn't fail at authentication.

      I think the problem is know the domain of the user logged in.

      Thanks for the help.

      #10; Sun, 06 Jan 2008 08:15:00 GMT
    • The logged in user has nothing to do with accessing DirectoryServices when you specify explicit credentials. You can even access an entirely different domain if you also specify server address in the LDAP query.

      I would advise your to downloadSofterra LDAP Browser, with which you can connect to your AD and inspect all available attributes LDAP way. Then you can make sure that the object your are trying to fetch really have that attribute your are requesting.

      #11; Sun, 06 Jan 2008 08:16:00 GMT