InitializeSecurityContext () throws SEC_E_WRONG_PRINCIPLE.

Todd Stecher tstecher at
Sun Mar 19 23:23:37 EST 2006

See below.

Todd Stecher

Emergent Security Corp
425 205 1180

tstecher at
> -----Original Message-----
> From: kerberos-bounces at MIT.EDU [mailto:kerberos-bounces at MIT.EDU] On Behalf
> Of henin
> Sent: Thursday, March 16, 2006 1:16 AM
> To: kerberos at MIT.EDU
> Subject: InitializeSecurityContext () throws SEC_E_WRONG_PRINCIPLE.
> Hello All,
> We are facing very strange issues on some of our installations.
> InitializeSecurityContext () throws SEC_E_WRONG_PRINCIPLE error.

This (almost) always means the service ticket cannot be decrypted by the
service.  I'd verify that:

1) The caller of AcceptSecurityContext() is indeed running as local system,
and not under an impersonated token.

2) The credential handle pass to ASC() is *not* using explicit credentials
(e.g. you've provided a SEC_WINNT_AUTH_IDENTITY_* structure to
AcquireCredentialsHandle() with a username or password).

3) What SPN are you providing to InitializeSecurityContext()?  What is the
output of setspn -L <machine name>?


> Setup consists of a client and a server, server is running as a
> service (LocalSystem)
> Both client and server are running on the same machine.
> The setup is as below
> 1)Platform : Windows 2000 with sp4.
> 2)Server is running as a service with log-on user as LocalSystem.
> 3)Kerberos is used for authenticating the client with the server.
> In non-working case on both sides( client and server ) we are getting
> SEC_I_CONTINUE_NEEDED during the 3rd leg phase of authetication
> and later on the client side( InitializeSecurityContext() ) we get

MS Kerb *could* fail right away - in this case, the server returns a
purges it tickets (in case it has a stale ticket encrypted with an "old"
password), and retries the authentication.  It gives up after the SSPI
transaction fails again.

> I have verified that the targetname that is being passed to
> InitializeSecurityContext() is domain\hostname.One more point here is
> the hostname is not a fqdn.

A properly formed SPN would be of the form host/machinename.  Also, if the
machinename is NOT a FQDN, you have some chance of name collisions, as
described in the "troubleshooting Kerberos" whitepaper at (see KRB_AP_ERR_MODIFIED).  You can also
search for an explanation by looking for emails from me on the
Samba-technical archives.

> I have verified that ping hostname and later ping -a ipaddress
> gives me the fqdn of the machine on which both the client/server
> are running.
> The same installation on a different machine ( Say m/c B) works fine.
> We get SEC_E_OK on the first call to AcceptSecurityContext().
> Both these machines are in the same domain and have same os configuration.
> Running "Setspn -l (hostname)" gives the following output:
> C:\Program Files\Resource Kit>Setspn.exe -l COMPUTERNAME
> Registered ServicePrincipalNames for CN=COMPUTERNAME
> ,CN=Computers,DC=DOMAIN-NAME,DC=us
> ,DC=ORG-NAME,DC=com:
> Any pointers here.
> Regards,
> Henin.
> ________________________________________________
> Kerberos mailing list           Kerberos at

More information about the Kerberos mailing list