如果帐户是“ AD保护的用户”组的成员，如何验证用户凭据？

Question

In my C# application I need to check/validate user name and password in an Active Directory environment. There is a Domain Controller on Windows Server 2012 R2 or higher.

Some users are added to AD Protected Users group. API that is currently used does not work for such users.

For now, the only thing that seems to work is LogonUser function. But it requires P/invoke.

Is there a trick, a workaround or other API that I can use to validate user name and password for user account that is a member of the AD Protected Users group?

I tried the following APIs with different options:

• DirectoryEntry.NativeObject.
• PrincipalContext.ValidateCredentials with different ContextOptions.

var de = new DirectoryEntry("LDAP://DomainController.lab", "test-user",
    "Test-user-password", AuthenticationTypes.Secure);
var bo = de.NativeObject;

var context = new PrincipalContext(ContextType.Domain, "domain");
var res = context.ValidateCredentials("test-user", "test-user-password",
     ContextOptions.Negotiate);

DirectoryEntry.NativeObject throws DirectoryServicesCOMException (0x8007052E) "The user name or password is incorrect".

PrincipalContext.ValidateCredentials simply returns FALSE.

Answer 1

You didn't say what kind of application this is. If it's a web application, you're better off using Windows Authentication and let Windows handle all of this.

If it's not a web app, then it'll be more tricky. The important part of the documentation for Protected Users is this:

Accounts that are members of the Protected Users group that authenticate to a Windows Server 2012 R2 domain are unable to:

• Authenticate with NTLM authentication.

• Use DES or RC4 encryption types in Kerberos pre-authentication.

The documentation for AuthenticationTypes.Secure says:

Active Directory Domain Services uses Kerberos, and possibly NTLM, to authenticate the client.

That "possibly NTLM" is a problem. It will attempt Kerberos first, and fail back to NTLM. But NTLM is guaranteed not to work.

I think you will have to troubleshoot Kerberos, which unfortunately gets complicated fast.

The easiest first step is to confirm that Kerberos is indeed failing by enabling Kerberos event logging (on the machine that you're running this code) by going to the registry key HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Kerberos\\Parameters and adding a LogLevel DWORD value with a value of 1 . All Kerberos errors will now be logged to the System log in Event Viewer. See if you see errors there. (set it to 0 to disable it later)

If so, there are several articles out there that walk you through some form of Kerberos troubleshooting, if you search for them: https://www.google.com/search?q=troubleshoot+kerberos