Cross Realm MIT <-> Windows Close But No Cigar

Markus Moeller huaraz at moeller.plus.com
Thu May 3 18:33:29 EDT 2007


What does sshd -ddde show when you connect ?  Do you use a .k5login or 
auth_to_local ?

Markus

"Michael B Allen" <mba2000 at ioplex.com> wrote in message 
news:20070502221332.f84f2b59.mba2000 at ioplex.com...
> Hello,
>
> I struggling with cross realm auth and I'd appreciate it if someone can
> give me pointers.
>
> The problem seems to be with enctypes. So I just asserted RC4 everywhere
> and now I'm getting all the right tickets but ssh and smbclient still
> aren't quite satisfied.
>
> Info about the two domains and ssh / smbclient test results follows.
>
> ---- S.W.NET ----
>
> MIT 1.3.4-46 on CentOS 4.4
>
> I created KDC as usual but before creating the db I put the following
> in my kdc.conf:
>
> supported_enctypes = arcfour-hmac:normal
>
> I created some principals and it confirmed the enctype was archfour-hmac:
>
> kadmin.local:  ktadd test at S.W.NET
> Entry for principal test at S.W.NET with kvno 3, encryption type ArcFour
> with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab.
>
> krb5.conf is standard except I added W.NET to the [realms] and
> [domain_realm] sections (not sure if that's necessary).
>
> I created a host/ls1.s.w.net at S.W.NET principal and exported it to the
> /etc/krb5.keytab (for ssh).
>
> ---- W.NET ----
>
> W2K3 standard
> ktsetup /addkdc S.W.NET ls1.s.w.net
> ktpass /MitRealmName S.W.NET /TrustEncryp RC4
> Created two-way trust with AD Domains and Trusts.
> Rebooted.
>
> So with everything setup like above I tried ssh and smbclient.
>
> -- Testing with SSH with W.NET TGT --
>
> Ssh doesn't tell me much:
>
> $ ssh -vvv ioplex at ls1.s.w.ne
> ...
> debug1: Next authentication method: gssapi-with-mic
> debug3: Trying to reverse map address 192.168.2.20.
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug1: Authentications that can continue: 
> publickey,gssapi-with-mic,password
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug1: Authentications that can continue: 
> publickey,gssapi-with-mic,password
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug1: Authentications that can continue: 
> publickey,gssapi-with-mic,password
> debug2: we did not send a packet, disable method
>
> but I can see I have the right tickets:
>
> $ klist
> Ticket cache: FILE:/tmp/krb5cc_500
> Default principal: ioplex at W.NET
>
> Valid starting     Expires            Service principal
> 05/02/07 21:35:40  05/03/07 07:36:11  krbtgt/W.NET at W.NET
>        renew until 05/03/07 21:35:40
> 05/02/07 21:36:23  05/03/07 07:36:11  krbtgt/S.W.NET at W.NET
>        renew until 05/03/07 21:35:40
> 05/02/07 21:36:04  05/03/07 07:36:11  host/ls1.s.w.net at S.W.NET
>        renew until 05/02/07 21:36:04
>
> Ssh with an S.W.NET TGT to ls1.s.w.net works fine (no password).
>
> -- Testing with smbclient with S.W.NET TGT --
>
> $ smbclient -k //dc1.w.net/tmp
> signing_good: BAD SIG: seq 1
> SMB Signature verification failed on incoming packet!
> session setup failed: Server packet had invalid SMB signature!
>
> again I have the right tickets:
>
> $ klist
> Ticket cache: FILE:/tmp/krb5cc_500
> Default principal: ioplex at S.W.NET
>
> Valid starting     Expires            Service principal
> 05/02/07 21:27:56  05/03/07 21:27:56  krbtgt/S.W.NET at S.W.NET
> 05/02/07 21:33:35  05/03/07 21:27:56  krbtgt/W.NET at S.W.NET
> 05/02/07 21:33:55  05/03/07 07:33:55  dc1$@W.NET
>
> The signature in the SMB response packet is identical to the one
> in the request packet (i.e. it was echo'd).
>
> Any ideas?
>
> Do I need to do anything special with DNS?
>
> Mike
>
> -- 
> Michael B Allen
> PHP Active Directory Kerberos SSO
> http://www.ioplex.com/
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 






More information about the Kerberos mailing list