Wrong principal in request error on gss_accept_sec_context()

[Greg Hudson]

On 01/05/2015 09:36 PM, Xie, Hugh wrote:
> 1. /efs/dist/kerberos/mit/1.11.5/exec/bin/klist -k -t $KRB5_KTNAME
> Keytab name: FILE: /tmp/myacct.keytab
> KVNO Timestamp           Principal
> ---- ------------------- ------------------------------------------------------
>    2 12/17/2014 15:30:08 myacct at COMMON.BANKOFAMERICA.COM

[In the klist output:]
> #1>     Client: winlogin @ COMMON.BANKOFAMERICA.COM
>         Server: HTTP/host2.site123.baml.com @ COMMON.BANKOFAMERICA.COM

If the client is authenticating to HTTP/host2.site123.baml.com then the
server needs that key in its keytab, though it doesn't have to be listed
under that name.

>From the information given so far, I cannot tell whether the myacct key
ought to be the same as the HTTP/host2.site123.baml.com key through some
kind of principal aliasing.  I am particularly confused by these two
statements:

On 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"

On: Sat Dec 20 21:28:33 EST 2014
> No it is different computer accounts.