Cross Realm MIT <-> Windows Close But No Cigar
Michael B Allen
mba2000 at ioplex.com
Thu May 3 20:33:11 EDT 2007
On Thu, 3 May 2007 23:33:29 +0100
"Markus Moeller" <huaraz at moeller.plus.com> wrote:
> What does sshd -ddde show when you connect ? Do you use a .k5login or
> auth_to_local ?
Hi Markus,
I'm not familiar with .k5login or auth_to_local. The only thing I changed
in sshd_config was I turned of UsePAM.
I actually think the trust is valid. I've been trying it with my HTTP
SSO code and the GSS calls are definitely succeeding. It's something
that happends after the auth (e.g. RC4 salting or session key problem).
Thanks,
Mike
debug1: userauth-request for user ioplex service ssh-connection method gssapi-with-mic
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method gssapi-with-mic
debug3: mm_request_send entering: type 38
debug3: monitor_read: checking request 38
debug3: mm_request_receive_expect entering: type 39
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 39
debug3: mm_request_receive entering
Postponed gssapi-with-mic for ioplex from ::ffff:192.168.2.16 port 48735 ssh2
debug3: mm_request_send entering: type 40
debug3: monitor_read: checking request 40
debug3: mm_request_receive_expect entering: type 41
debug3: mm_request_receive entering
debug1: Got no client credentials
debug3: mm_request_send entering: type 41
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 44
debug3: mm_request_receive_expect entering: type 45
debug3: mm_request_receive entering
debug3: monitor_read: checking request 44
debug3: mm_request_send entering: type 45
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 42
debug3: mm_request_receive_expect entering: type 43
debug3: mm_request_receive entering
debug3: monitor_read: checking request 42
debug3: mm_answer_gss_userok: sending result 0
debug3: mm_request_send entering: type 43
Failed gssapi-with-mic for ioplex from ::ffff:192.168.2.16 port 48735 ssh2
debug3: mm_request_receive entering
debug3: mm_ssh_gssapi_userok: user not authenticated
Failed gssapi-with-mic for ioplex from ::ffff:192.168.2.16 port 48735 ssh2
debug1: userauth-request for user ioplex 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 ioplex from ::ffff:192.168.2.16 port 48735 ssh2
debug1: userauth-request for user ioplex 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 ioplex from ::ffff:192.168.2.16 port 48735 ssh2
debug1: userauth-request for user ioplex service ssh-connection method publickey
debug1: attempt 4 failures 4
> "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
> >
>
>
>
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
--
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/
More information about the Kerberos
mailing list