LogonUser returns true for a disabled account

Question

I call LogonUser to try to verify the credential set:

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

And it returns true even if the account is disabled:

---

I also tried using SSPI directly to verify credentials , which includes a call:

• AcquireCredentialsHandle(..., "Negotiate", SECPKG_CRED_OUTBOUND, ..., ["forest", "stapler", "avatopia.com"], ...)
• InitializeSecurityContext(...)
• AcquireCredentialsHandle(..., "Negotiate", SECPKG_CRED_INBOUND, ...)
• AcceptSecurityContext(...)
• InitializeSecurityContext(...)
• AcceptSecurityContext(...)

On most machines, the AcquireCredentialsHandle initial AcquireCredentialsHandle not made if the user account is disabled. But on this particular machine, I’m testing completes the whole cycle and works.

---

If I try with an invalid password, then LogonUser (correctly) fails :

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

returns false , and GetLastError returns 1326 (login failure: unknown username or password)

Trying SSPI with the wrong password also (correctly) does not work:

• AcquireCredentialsHandle(..., "Negotiate", SECPKG_CRED_OUTBOUND, ..., ["forest", "adf342sdf3", "avatopia.com"], ...)
• InitializeSecurityContext(...)
• AcquireCredentialsHandle(..., "Negotiate", SECPKG_CRED_INBOUND, ...)
• AcceptSecurityContext(...) failed with 8009030C (login attempt failed)

Which means that this behavior only happens on machine one .

Why LogonUser and the entire security support provider interface indicate that credentails of a disconnected account on a specific computer connected to a domain are valid?

• domain connected to the computer where LogonUser (incorrectly): Windows XP SP2
• the domain is connected to the machine where LogonUser (correctly) crashes: Windows XP SP2

---

Update:

There is no local user named Forest :

and there is no local user named Forest :

which doesn't matter because I'm asking avatopia.com\Forest , not speeder\Forest .

oi vay People get their panties in a bundle only because a user with limited rights was allowed to access something that they should not have access to.

Answer 1

I agree with Luke that it is very likely that he is using cached credentials. Able to ping domain controllers does not mean that he is able to speak with him correctly.

One test you can try is to log in to this computer using this gump account. Yes, you may need to provide him with an interactive login to do this, but only for troubleshooting purposes.

Another thing you can do to prove this is related to the problem of credential caching - it is capturing 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 communicate with KDC. If this fails, he should talk to the NetLogon server using NTLM.

If credential caching is a real issue, I suspect you can just fix it by using kerberos instead of reconcile in the AcquireCredentialsHandle call.

Answer 2

What happens if you use LOGON32_LOGON_INTERACTIVE instead? Just looking at the documents and the NETWORK option provide you with a different type of token, so I could imagine the behavior you see.