InitializeSecurityContext () throws SEC_E_WRONG_PRINCIPLE.
henin
henin at newsgroup.nospam
Mon Mar 20 07:24:16 EST 2006
This is a multi-part message in MIME format.
--------------050800050306080509090000
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hello Todd,
Thank you very much for your reply.
3) What SPN are you providing to InitializeSecurityContext()? What is the
output of setspn -L <machine name>?
Both in working and non-working case setspn -L gives the below 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:
All the poniters state that there can be two possible reasons for this issue
1)SPN is not properly configured for the service we are interrested in.
2)The DNS is not configured properly.
1)SPN is not properly configured for the service we are interrested in.
But I note that both the client and the server lie in the same realm
( i.e in the same domain ) and the SPN's in our network are for hostname's
and not per services.Going by this we do not have same machine names in a domain.
Does the output stated above by setspn give some wrong value?.
2)The DNS in configured properly as it gives a FQDN, if I do a ping -a ( ipaddress).
I am still worried how does this all work in one machine and not on other
when both the machines are in the same domain.
So can please let me know where we are going wrong here.
Regards,
Henin.
Todd Stecher wrote:
>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
>>
>>
>
>________________________________________________
>Kerberos mailing list Kerberos at mit.edu
>https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
>
--------------050800050306080509090000
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
Hello Todd,<br>
Thank you very much for your reply.<br>
<pre wrap="">3) What SPN are you providing to InitializeSecurityContext()? What is the
output of setspn -L <machine name>?
Both in working and non-working case <b>setspn -L</b> gives the below 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:
All the poniters state that there can be two possible reasons for this issue
1)SPN is not properly configured for the service we are interrested in.
2)The DNS is not configured properly.
1)SPN is not properly configured for the service we are interrested in.
But I note that both the client and the server lie in the same realm
( i.e in the same domain ) and the SPN's in our network are for hostname's
and not per services.Going by this we do not have same machine names in a domain.
Does the output stated above by setspn give some wrong value?.
2)The DNS in configured properly as it gives a FQDN, if I do a ping -a ( ipaddress).
I am still worried how does this all work in one machine and not on other
when both the machines are in the same domain.
So can please let me know where we are going wrong here.
Regards,
Henin.
</pre>
<br>
<br>
<br>
Todd Stecher wrote:<br>
<blockquote type="cite"
cite="mid200603200424.k2K4ODaV010560 at pacific-carrier-annex.mit.edu">
<pre wrap="">See below.
Todd Stecher
Emergent Security Corp
425 205 1180
<a class="moz-txt-link-abbreviated" href="mailto:tstecher at qwest.net">tstecher at qwest.net</a>
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:kerberos-bounces at MIT.EDU">kerberos-bounces at MIT.EDU</a> [<a class="moz-txt-link-freetext" href="mailto:kerberos-bounces at MIT.EDU">mailto:kerberos-bounces at MIT.EDU</a>] On Behalf
Of henin
Sent: Thursday, March 16, 2006 1:16 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:kerberos at MIT.EDU">kerberos at MIT.EDU</a>
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.
</pre>
</blockquote>
<pre wrap=""><!---->
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>?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
<a class="moz-txt-link-freetext" href="http://www.microsoft.com/kerberos">http://www.microsoft.com/kerberos</a> (see KRB_AP_ERR_MODIFIED). You can also
search for an explanation by looking for emails from me on the
Samba-technical archives.
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-abbreviated" href="mailto:Kerberos at mit.edu">Kerberos at mit.edu</a>
<a class="moz-txt-link-freetext" href="https://mailman.mit.edu/mailman/listinfo/kerberos">https://mailman.mit.edu/mailman/listinfo/kerberos</a>
</pre>
</blockquote>
<pre wrap=""><!---->
________________________________________________
Kerberos mailing list <a class="moz-txt-link-abbreviated" href="mailto:Kerberos at mit.edu">Kerberos at mit.edu</a>
<a class="moz-txt-link-freetext" href="https://mailman.mit.edu/mailman/listinfo/kerberos">https://mailman.mit.edu/mailman/listinfo/kerberos</a>
</pre>
</blockquote>
</body>
</html>
--------------050800050306080509090000--
More information about the Kerberos
mailing list