Bug in SSPI AcceptSecurityContext?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

We have been trying to gain a detailed understanding of what SSPI does when
authentication fails.

Take the scenario where the client initializes a context for a service with
the SPN of "userA@xxxxxxxxxx". However the service is actually running as
"userB@xxxxxxxxxx".

On the first call to AcceptSecurityContext, when the client's first blob is
passed in, SSPI returns SEC_I_CONTINUE_NEEDED. Shouldn't it return a failure
code since the ticket embedded in the security blob (token) is not encrypted
with a key it can understand?

We've also noticed the behaviour differs between an initial logon and once
the workstation has been locked and unlocked.

On an initial login:
AcquireCredentialsHandle (client side) - SEC_E_OK
AcquireCredentialsHandle (server side) - SEC_E_OK
InitializeSecurityContext - SEC_I_CONTINUE_NEEDED -> Send token to server
AcceptSecurityContext - SEC_I_CONTINUE_NEEDED -> Send token to client
InitializeSecurityContext - SEC_I_CONTINUE_NEEDED -> Send token to server
AcceptSecurityContext - SEC_I_CONTINUE_NEEDED -> Send token to client
InitializeSecurityContext - SEC_E_WRONG_PRINCIPAL

After locking/unlocking the workstation:
AcquireCredentialsHandle (client side) - SEC_E_OK
AcquireCredentialsHandle (server side) - SEC_E_OK
InitializeSecurityContext - SEC_I_CONTINUE_NEEDED -> Send token to server
AcceptSecurityContext - SEC_I_CONTINUE_NEEDED -> Send token to client
InitializeSecurityContext - SEC_E_LOGON_DENIED

Where is the behaviour different after the lock/unlock and why the extra
roundtrip in the initial logon case?

Any enlightment would be greatly appreciated given the black-box nature of
SSPI :)
.

Relevant Pages

  • Re: Using NTLM/SSPI with custom username/password scheme
    ... tickets, complex key management, and a trusted ticket-granting server. ... you can easily do an simplistic NTLM-style authentication. ... The server creates a challenge for the client and sends it back (random ... If you still want to use SSPI, you're going to have to create an unmanaged ...
    (microsoft.public.dotnet.security)
  • New Bug in AcceptSecurityContext in Kerberos SSPI?
    ... passed in, SSPI returns SEC_I_CONTINUE_NEEDED. ... AcquireCredentialsHandle (client side) - SEC_E_OK ... InitializeSecurityContext - SEC_E_WRONG_PRINCIPAL ...
    (microsoft.public.platformsdk.security)
  • Using SSPI in a client/server environment
    ... I'm having some problems wrapping my brain around SSPI. ... The server is a C++ MFC Windows application that monitors a port ... The client is a C++ MFC application that sends packets and waits ... The current security model ...
    (microsoft.public.platformsdk.security)
  • SSPI Server: How to retrieve the username of incoming authentication request
    ... the server for mutual authentication, will the server able to deduce the ... I am using the SSPI Workbench sample. ... In the client side, I ... server and I don't see the username being sent. ...
    (microsoft.public.platformsdk.security)
  • Re: AcquireCredentialsHandle returns with SEC_E_INTERNAL_ERROR
    ... But I don't see any explicitly conneciton with AcquireCredentialsHandle ... server application, so could you post a simple repro code (including server and client) so that I can reproduce the prolem ... In addition, if you have installed Platform SDK, there is client and server samples under \Microsoft Platform SDK\Samples ...
    (microsoft.public.platformsdk.security)