LogonUser returns true for a disabled account

Question

i am calling LogonUser to try to validate a set of credentials:

LogonUser("forest", "avatopia.com" "stapler", 
         LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_WINNT50, out token);

And it returns true, even though the account is disabled:

enter image description here

i also tried using SSPI directly to validate credentials, which involves calling:

AcquireCredentialsHandle(..., "Negotiate", SECPKG_CRED_OUTBOUND, ..., ["forest", "stapler", "avatopia.com"], ...)

InitializeSecurityContext(...)

AcquireCredentialsHandle(..., "Negotiate", SECPKG_CRED_INBOUND, ...)

AcceptSecurityContext(...)

InitializeSecurityContext(...)

AcceptSecurityContext(...)

On most machines the initial call to AcquireCredentialsHandle fails if the user account is disabled. But on this particular machine i'm testing it completes the entire cycle and works.

If i try with invalid password then LogonUser does (correctly) fail:

LogonUser("forest", "avatopia.com" "adf342sdf3", 
         LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_WINNT50, out token);

returns false, and GetLastError returns 1326 (Logon failure: unknown user name or password)

Trying SSPI with an invalid password also (correctly) fails:

AcquireCredentialsHandle(..., "Negotiate", SECPKG_CRED_OUTBOUND, ..., ["forest", "adf342sdf3", "avatopia.com"], ...)

InitializeSecurityContext(...)

AcquireCredentialsHandle(..., "Negotiate", SECPKG_CRED_INBOUND, ...)

AcceptSecurityContext(...) fails with 8009030C (The logon attempt failed)

What is aggrevating is that this behavior is only happening on one machine.

Why would LogonUser, and the entire Security Support Provider Interface, indicate that credentails of a disabled account on a particular domain-joined machine: are valid?

domain joined machine where LogonUser (incorrectly) succeeds: Windows XP SP2
domain joined machine where LogonUser (correctly) fails: Windows XP SP2

Update:

There is no local user called Forest:

nor is there any local user called Forest:

which is irrelevant because i'm asking for avatopia.com\Forest, and not speeder\Forest.

oi vay People get their panties in a bunch just because a disabled user was allowed to access something they should have not have been allowed to access.

Maybe there's a local user with the same name which is disabled while the Domain user is active? To me it looks like you're viewing the users in the local management snap-in. Does this show disabled domain users, too? — Thorsten Dittmar
@ThorstenDittmar i checked that; i'll add screenshot to question. — Ian Boyd
Maybe a dumb question, but can you reach the domain controller from that machine when this is happening? Perhaps cached credentials are being used. — Luke
@Luke i can ping both of the two domain controllers in the network forest (han and solo) — Ian Boyd

Harvey Kwok Harvey Kwok · Accepted Answer · 2012-03-22T00:30:08

I agree with Luke that very likely, it's using cached credentials. Able to ping domain controllers doesn't mean it's able to talk to it correctly.

One test that you can try is to logon that computer using that forest gump account. Yes, you might need to grant him interactive logon right to do this but just for troubleshooting purpose.

Another thing that you can do to prove this is due to the credentials caching issue is to capture the network traffic between your domain controller and your machine. See if there is any NTLM or Kerberos traffic. By default, it should use Kerberos to talk to the KDC. If that fails, it should talk to the NetLogon server using NTLM.

If credentials caching is the real issue, I am suspecting that you can simply fix it by using "kerberos" instead of "negotiate" in the call of AcquireCredentialsHandle.

LogonUser returns true for a disabled account

2 Answers