cross realm trusts ..

[Simo Sorce]

On Thu, 2013-11-28 at 15:09 +1000, Matt Bryant wrote:
> All,
> 
> Having an issue creating a cross realm trust between freeipa and a 
> legacy krb5 realm. Have added the relevant one way trust principles to 
> both KDCs and configured up and can see request being made to KDC but 
> when trying to access a host from the new freeipa realm to kerberos 
> realm .. its not working .. putting the sshd into debug am seeing
> 
> the server i am coming from .....
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug3: Wrote 96 bytes for a total of 1205
> debug1: Delegating credentials
> debug3: Wrote 1328 bytes for a total of 2533
> debug1: Delegating credentials
> debug1: Unspecified GSS failure.  Minor code may provide more information
> Generic error (see e-text)
> 
> debug1: Authentications that can continue: 
> publickey,gssapi-with-mic,password
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug3: Wrote 96 bytes for a total of 2629
> debug1: Authentications that can continue: 
> publickey,gssapi-with-mic,password
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug3: Wrote 96 bytes for a total of 2725
> debug1: Authentications that can continue: 
> publickey,gssapi-with-mic,password
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug3: Wrote 96 bytes for a total of 2821
> debug1: Authentications that can continue: 
> publickey,gssapi-with-mic,password
> debug2: we did not send a packet, disable method
> debug3: authmethod_lookup publickey
> debug3: remaining preferred: keyboard-interactive,password
> 
> the server i am going to ...
> 
> debug3: mm_request_send entering: type 38
> debug3: mm_request_receive entering
> Postponed gssapi-with-mic for root from 203.147.190.30 port 42965 ssh2
> debug3: mm_request_send entering: type 39
> debug3: mm_request_receive_expect entering: type 40
> debug3: mm_request_receive entering
> debug3: monitor_read: checking request 39
> debug1: Miscellaneous failure
> ASN.1 identifier doesn't match expected value
> 
> debug1: Got no client credentials
> debug3: mm_request_send entering: type 40
> debug3: mm_request_receive entering
> Failed gssapi-with-mic for root from 203.147.190.30 port 42965 ssh2
> debug1: userauth-request for user root service ssh-connection method 
> gssapi-with-mic
> debug1: attempt 2 failures 2
> debug2: input_userauth_request: try method gssapi-with-mic
> Failed gssapi-with-mic for root from 203.147.190.30 port 42965 ssh2
> debug1: userauth-request for user root service ssh-connection method 
> gssapi-with-mic
> debug1: attempt 3 failures 3
> debug2: input_userauth_request: try method gssapi-with-mic
> Failed gssapi-with-mic for root from 203.147.190.30 port 42965 ssh2
> debug1: userauth-request for user root service ssh-connection method 
> gssapi-with-mic
> debug1: attempt 4 failures 4
> debug2: input_userauth_request: try method gssapi-with-mic
> Failed gssapi-with-mic for root from 203.147.190.30 port 42965 ssh2
> Connection closed by 203.147.190.30
> 
> 
> How can i tell whats causing this ASN.1 error ????

Before trying to check what obscure errors are, maybe you wan to check
that you can properly get a ticket for the target server.

So if you do:
$ kinit myuser at MY.REALM
$ kvno host/server.dest.domain at DEST.REALM
$ klist

Do you see a tgt for your own realm, a cross realm tgt and a ticket for
the target server ?

If not you have problems in resolving names or realms or domain->realm

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York