InitializeSecurityContext () throws SEC_E_WRONG_PRINCIPLE.

[Todd Stecher]

See below.

Todd Stecher

Emergent Security Corp
425 205 1180

tstecher at qwest.net
> -----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
> SEC_E_WRONG_PRINCIPLE error.

MS Kerb *could* fail right away - in this case, the server returns a
KRB_ERROR with the KRB_AP_ERR_MODIFIED / WRONG_PRINCIPAL, and the client
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
http://www.microsoft.com/kerberos (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 mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos