[36681] in Kerberos
Re: Wrong principal in request error on gss_accept_sec_context()
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Dec 19 12:11:24 2014
Message-ID: <54945C2F.2050200@mit.edu>
Date: Fri, 19 Dec 2014 12:11:11 -0500
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: "Xie, Hugh" <hugh.xie@bankofamerica.com>,
"<kerberos@mit.edu>" <Kerberos@mit.edu>
In-Reply-To: <7E270C3427928E499F189C5636C52CDC45C6DC00@smtp_mail.bankofamerica.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@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.
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
