Logon sessions, SSPI and access tokens

Name the object being inspected

“The user’s authentication” can mean several different pieces of state:

SSPI gives applications a common interface to security packages. It does not itself collect a password or establish a Windows interactive logon. The distinction matters when a service uses default credentials, explicit credentials or a client’s impersonation context. Microsoft’s SSPI model describes the interface boundary.

An application can establish one of these objects and still fail at the next step. A ticket in an administrator’s terminal tells you nothing about the credentials available to a separate service process.

Follow the application exchange

The usual SSPI sequence is:

1. Each endpoint obtains an appropriate credential handle through AcquireCredentialsHandle.
2. The client calls InitializeSecurityContext, supplying the intended target name.
3. The application transports the returned opaque authentication bytes to the server, which calls AcceptSecurityContext.
4. Both sides exchange any further output until the protocol completes, then inspect the resulting context.

Obtaining the credential handle doesn’t mean a remote server has accepted anything yet. The credential-handle API separates acquiring credentials from logging on to the network.

SEC_I_CONTINUE_NEEDED means another protocol exchange is required. It is not a completed authentication or an ordinary failure. Even a final SEC_E_OK can accompany output bytes that must reach the peer. An application or proxy dropping that last message can break the exchange after one side appears successful. These requirements are documented for client initialization and server acceptance.

When tracing the application, record the requested package, target SPN, input/output lengths, return status and completion state. Keep the error codes, but leave passwords and session-key material out of the trace.

Requested security is different from negotiated security

Requesting Negotiate doesn’t tell you whether Kerberos was selected. After completion, application instrumentation can query SECPKG_ATTR_NEGOTIATION_INFO to record the selected package and negotiation state. SECPKG_ATTR_NAMES identifies the context principal; SECPKG_ATTR_FLAGS reports negotiated attributes. See QueryContextAttributes for Negotiate and the negotiation-information structure.

Check the returned integrity, confidentiality and mutual-authentication properties after the final successful call. A request flag says what the application asked for. The returned properties tell you what it got. Also check how the application uses the context and its message-protection functions to protect subsequent messages.

If the target name differs between a working direct connection and a failing alias, compare the actual SPN before changing account credentials. See SPN ownership.

A process identity and a thread identity can differ

Every process has a primary access token. A server thread may additionally impersonate a client. For ordinary local object access, an impersonating thread can therefore be checked as the client while another thread in the same process acts as the service account. Inspect the thread involved in the failed operation, not just the executable’s configured account. Microsoft’s access-token description defines both token types.

Impersonation also has a level:

These are token impersonation levels, not an instruction to enable unconstrained delegation. Kerberos constrained delegation has its own ticket and policy workflow; diagnose it through the second-hop guide.

A service logging “authenticated Alice” may still deliberately perform file or database work under its service identity. Check whether the application supports impersonation, whether it attempted it successfully, and whether the thread was still impersonating at the access check.

The logon type changes the available credentials

Two tokens bearing the same account name need not provide the same outbound behavior. The LogonUser API distinguishes these cases:

For NewCredentials, local whoami output can describe the original local identity while a remote resource receives a different identity. Starting the local process successfully doesn’t test that next remote authentication. Don’t switch to a credential-retaining logon type just to make a second hop work. Check which authentication model the application supports.

Match tickets to the failing logon session

These are local inspection examples:

whoami /all
klist sessions
klist tickets

The first and third describe the caller’s context unless another session is selected. With appropriate local privileges, select the affected service’s LUID. Replace this example LUID with the one you’re investigating:

klist -lh 0x0 -li 0x123456 tickets

klist documents hexadecimal LUID selection. Sysinternals LogonSessions -p, if already approved and available, associates active logon sessions with processes. A desktop/RDP session number and an authentication LUID are different identifiers.

Keep the host, process, LUID, account, logon type, ticket target and collection time together so you can compare the working and failing processes in the right context. Purging an administrator’s tickets won’t refresh an unrelated service’s credentials or replace an existing access token. Changing directory membership doesn’t update that token either. See groups and tokens.