Re: Cross Realm MIT <-> Windows Close But No Cigar

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

Markus

"Michael B Allen" <mba2000@xxxxxxxxxx> wrote in message
news:20070502221332.f84f2b59.mba2000@xxxxxxxxxxxxx
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@xxxxxxx
Entry for principal test@xxxxxxx 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@xxxxxxx 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@xxxxxxxxxx
...
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@xxxxx

Valid starting Expires Service principal
05/02/07 21:35:40 05/03/07 07:36:11 krbtgt/W.NET@xxxxx
renew until 05/03/07 21:35:40
05/02/07 21:36:23 05/03/07 07:36:11 krbtgt/S.W.NET@xxxxx
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@xxxxxxx
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@xxxxxxx

Valid starting Expires Service principal
05/02/07 21:27:56 05/03/07 21:27:56 krbtgt/S.W.NET@xxxxxxx
05/02/07 21:33:35 05/03/07 21:27:56 krbtgt/W.NET@xxxxxxx
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@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/kerberos




________________________________________________
Kerberos mailing list Kerberos@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/kerberos

.

Relevant Pages

  • Cross Realm MIT <-> Windows Close But No Cigar
    ... Info about the two domains and ssh / smbclient test results follows. ... I created some principals and it confirmed the enctype was archfour-hmac: ... debug2: we sent a gssapi-with-mic packet, ...
    (comp.protocols.kerberos)
  • Re: ssh: without password/passphrase prompt
    ... Changing the permissions as indicated below still doesn't work. ... the permissions on root's home and .ssh. ... > debug2: we sent a publickey packet, ...
    (comp.security.ssh)
  • Re: OT: Security....
    ... you can't really spoof IP addresses on SSH sessions. ... You send a SYN packet, ... Normally since you would not get the SYN ACK ... This would work to the spoofers benefit since the machines ...
    (Fedora)
  • Re: PuTTY internals
    ... > command line sessions and found that PuTTY appears to be sending each ... PuTTY can certainly be expected to send two SSH messages per ... the next character before sending a packet. ...
    (comp.security.ssh)
  • Re: OT: Security....
    ... >> what I can tell it appears that when you initiate an ssh attempt the ... Normally since you would not get the SYN ACK ... >> packet the connection would not be completed. ... >> SYN packet I think you would have a good chance of completing the ...
    (Fedora)