Wrong principal in request error on gss_accept_sec_context()

Xie, Hugh hugh.xie at bankofamerica.com
Fri Dec 19 13:33:11 EST 2014


We are using the same account on both hosts the Principal in the keytab is "myacct at COMMON.BANKOFAMERICA.COM"

Klist return service principals are the same "krbtgt/COMMON.BANKOFAMERICA.COM at COMMON.BANKOFAMERICA.COM" on both host


-----Original Message-----
From: Greg Hudson [mailto:ghudson at mit.edu] 
Sent: Friday, December 19, 2014 12:11 PM
To: Xie, Hugh; <kerberos at mit.edu>
Subject: Re: Wrong principal in request error on gss_accept_sec_context()

When you try to connect to the non-working server on the client, what service ticket appears in the cache as reported by klist?  How does this compare to the entries in the keytab on the non-working server?

On 12/19/2014 11:50 AM, Xie, Hugh wrote:
> 
> * What do "hostname" and "hostname -f" say on each host?
> The working on are using "host1.bankofamerica.com" the non working one has "host2.site123.baml.com". "hostname" and "hostname -f" returns same string on both hosts.
> 
> In the KRB5_CONFIG of both hosts, default_realm is set to 
> COMMON.BANKOFAMERICA.COM And the domain_realm is config from above 
> host_name = COMMON.BANKOFAMERICA.COM
> 
> * What OS are these hosts running?
> The working host is running EL5, the non working host is running EL6
> 
> * What server application are you getting the error from?  If it's a custom application, what name was imported to create the verifier_cred_handle argument of gss_accept_sec_context?
> The application is custom app running under python. If you meant acceptor_cred_handle, it is generated with the following with the following code:
> maj_stat = gss_acquire_cred(&min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE,
>                                     GSS_C_NO_OID_SET, GSS_C_BOTH, 
> &state->server_creds, NULL, NULL);
> 
> * Did you recently re-key one of the hosts without retaining the old 
> keytab?  (If so, run kinit again on the client to flush any old 
> service
> tickets.)
> I did this multiple times already.
> 
> -----Original Message-----
> From: Greg Hudson [mailto:ghudson at mit.edu]
> Sent: Friday, December 19, 2014 11:24 AM
> To: Xie, Hugh; <kerberos at mit.edu>
> Subject: Re: Wrong principal in request error on 
> gss_accept_sec_context()
> 
> On 12/18/2014 02:02 PM, Xie, Hugh wrote:
>> I am getting "Wrong principal in request" error on
>> gss_accept_sec_context() on one host but does not on another. I 
>> verified /etc/hosts, both host conform to this format
>>
>> # Default /etc/hosts file
>> 127.0.0.1       localhost.localdomain localhost
>> 123.150.123.123  myhost.bankdomain.com myhost
>>
>> Are there any other causes for this error?
>> I am using krb5 1.11.5
> 
> Unfortunately several things can cause this error in 1.11.  (In 1.13 we try harder to disambiguate.)  Information which might help:
> 
> * What do "hostname" and "hostname -f" say on each host?
> 
> * What OS are these hosts running?
> 
> * What server application are you getting the error from?  If it's a custom application, what name was imported to create the verifier_cred_handle argument of gss_accept_sec_context?
> 
> * Did you recently re-key one of the hosts without retaining the old 
> keytab?  (If so, run kinit again on the client to flush any old 
> service
> tickets.)
> 
> ----------------------------------------------------------------------
> This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.
> 

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.


More information about the Kerberos mailing list