On the client side two ticket shows up for either when connects for either 
hosts the krbtgt/COMMON.BANKOFAMERICA.COM @ COMMON.BANKOFAMERICA.COM
The service ticket on the clients has the principal of:
HTTP/host1.bankofamerica.com @ COMMON.BANKOFAMERICA.COM
HTTP/host2.site123.baml.com @ COMMON.BANKOFAMERICA.COM


-----Original Message-----
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
Xie, Hugh
Sent: Friday, December 19, 2014 1:33 PM
To: Greg Hudson; <kerberos@mit.edu>
Subject: RE: Wrong principal in request error on gss_accept_sec_context()

We are using the same account on both hosts the Principal in the keytab is 
"mya...@common.bankofamerica.com"

Klist return service principals are the same 
"krbtgt/common.bankofamerica....@common.bankofamerica.com" on both host


-----Original Message-----
From: Greg Hudson [mailto:ghud...@mit.edu]
Sent: Friday, December 19, 2014 12:11 PM
To: Xie, Hugh; <kerberos@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:ghud...@mit.edu]
> Sent: Friday, December 19, 2014 11:24 AM
> To: Xie, Hugh; <kerberos@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.
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

----------------------------------------------------------------------
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.
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to