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