Bug in Kerberos SSP within SSPI??

Bug in Kerberos SSP within SSPI??

Secure Home | Search | About

Microsoft Applications Security - Microsoft's general security discussions and announcements 

Bookmark this page:  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
Bug in Kerberos SSP within SSPI?? the_marshman 07-28-2005
Posted by =?Utf-8?B?dGhlX21hcnNobWFu?= on July 28, 2005, 4:46 am
If you were  Registered and logged in, you could reply and use other advanced thread options
We have been trying to gain a detailed understanding of what SSPI does when
authentication fails. Unfortunately while much documentation exists for how
ti works when it all works, the documentation on what happens when things go
wrong is almost non-existent!

For example, take the scenario where the client initializes a context for a
service with the SPN of "userA@domain.com". However the service is actually
running as
"userB@domain.com".

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 :)

We are running a W2K3 with SP1 running in W2K+ mode for the Domain
controller and WinXP with SP2 for the workstations.


Similar ThreadsPosted
SSPI Kerberos for delegation December 18, 2008, 11:17 am
SSPI: VerifySignature(Digest) October 17, 2005, 4:52 pm
Weird problem with SSPI May 1, 2009, 1:42 pm
Using SPNEGO/SSPI in SMB (Extended Security) August 18, 2005, 5:56 pm
SSPI to verify machine identity January 12, 2006, 8:59 am
SSPI client to ldap Server - Error at last stage of n-way authentication check December 24, 2005, 1:14 am
SSPI client to ldap Server - Error at last stage of n-way authentication check December 24, 2005, 1:15 am
Kerberos UDP vs TCP November 14, 2006, 4:18 am
Kerberos Delegation July 6, 2005, 2:06 pm
Kerberos problem April 22, 2008, 1:02 pm

The site map in XML format XML site map

Contact Us | Privacy Policy