See below. Todd Stecher
Emergent Security Corp 425 205 1180 [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of henin > Sent: Thursday, March 16, 2006 1:16 AM > To: [email protected] > 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 [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
