cross realm trusts ..

[Matt Bryant]

Simo,

Have done that and yes can see all of those tickets .... mine, the TGT 
for cross realm auth and the host ticket in the other realm .. Now at 
this point got to say the old realm/kdc is on el4 and of course th eipa 
is on el6
is there any reason the version disparity 1.3 v 1.10 is causing issues 
.. I have to upgrade the el4 instance anyhow am hoping can just copy the 
kerberos db ... or is there a way to export/inport that kind of thing.

rgds

Matt B.

On 29/11/13 06:02, Simo Sorce wrote:
> 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.
>