Windows GSSAPI ssh connection via cross-realm authentication problems

[Jason Mogavero]

Ok, I found part one of my problem, in that on the non-windows KDC I had not
specified an encryption type and whatever is the default was not working
with the windows DC.  I've fixed that and I can now get issued tickets by
the non-windows KDC.  Here is the kdc.log entry for my ticket generation:

Aug 21 13:59:47 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
{23 3 1 24 -135}) 172.16.102.28: ISSUE: authtime 1156189823, etypes {rep=3
tkt=16 ses=1}, jason.mogavero at KDCTEST.COM for
host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
Aug 21 13:59:47 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
{23 3 1 24 -135}) 172.16.102.28: ISSUE: authtime 1156189823, etypes {rep=3
tkt=16 ses=1}, jason.mogavero at KDCTEST.COM for
host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM

However, GSSAPI is still failing.  The logging in PuTTY shows a general SSPI
failure, but nothing specific other than the ssh server is kicking back a
reject.  (note that GSSAPI works on a Linux system that connects via openssh
and is authenticated the the non-windows KDC)

I ran sshd in debug mode, and compared the output from a rejected GSSAPI
session and an accepted one.  Here is the accepted:

Aug 21 14:21:30 kdcvps1 sshd[19893]: debug1: Received some client
credentials
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_send entering: type
41
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive entering
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: monitor_read: checking request
44
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_send entering: type
45
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive entering
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: monitor_read: checking request
42
Aug 21 14:21:30 kdcvps1 sshd[19893]: Authorized to kdcadmin, krb5 principal
kdcadmin at DMZ.KDCTEST.COM (krb5_kuserok)
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_answer_gss_userok: sending
result 1
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_send entering: type
43
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive_expect
entering: type 47
Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive entering
Aug 21 14:21:31 kdcvps1 sshd[19893]: debug3: PAM: do_pam_account
pam_acct_mgmt = 0
Aug 21 14:21:31 kdcvps1 sshd[19893]: debug3: mm_request_send entering: type
48
Aug 21 14:21:31 kdcvps1 sshd[19893]: Accepted gssapi-with-mic for kdcadmin
from 172.16.102.112 port 32957 ssh2

And here is the failed one:

Aug 21 14:01:35 kdcvps1 sshd[19853]: debug1: Received some client
credentials
Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_send entering: type
41
Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_receive entering
Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: monitor_read: checking request
44
Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_send entering: type
45
Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_receive entering
Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: monitor_read: checking request
42
Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_answer_gss_userok: sending
result 0
Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_send entering: type
43
Aug 21 14:01:35 kdcvps1 sshd[19853]: Failed gssapi-with-mic for
jason.mogavero from 172.16.102.28 port 4292 ssh2

So it seems that even though I am getting a tgt from the non-Windows KDC, I
am not being authorized by this "checking request 42" which I imagine checks
against the non-Win KDC.  I don't need to have every user in the Windows AD
in the non-Windows KDC user database as well, do I?  I thought the point of
the one-way trust was to allow users authenticated in one realm to have
access to resources in another.  Is this an ACL issue?  I have an entry in
the kadm5.acl file on the non-windows KDC that says:

*@KDCTEST.COM *

Is not not correct syntax?

On 8/18/06, Douglas E. Engert <deengert at anl.gov> wrote:
>
>
>
> Jason Mogavero wrote:
>
> > Hello all,
> >
> >    I am implementing a Kerberos/GSSAPI solution in a test environment
> and I
> > am experiencing some issues with allowed windows ssh clients to be
> granted
> > acess to the ssh server.
> >
> > The background:
> >
> > Windows AD is primary kdc with realm name KDCTEST.COM and hostname
> > adauth.kdctest.com
> > MIT kdc (on CentOS 4.3, installed from rpms) is DMZ.KDCTEST.COM
> >
> > ssh server is hostname kdcvps1.kdctest.com
> > ssh client (linux) is kdcvps2.kdctest.com
> > windows ssh client is kdctest01.kdctest.com
> >
> > I am able to passwordlessly log into the ssh server from the Linux ssh
> > client via gssapi.  When I connect from PuTTY or SecureCRT in GSSAPI
> mode,
> > it fails.  PuTTY prompts me for a password and SecureCRT errors out with
> > "All available GSSAPI mechanisms failed"  Here is the kdc.log entry I
> get:
>
> Sounds like the cross realm keys are not setup correctly, i.e. the kvno
> key or enc types are different in AD and krb KDC for the
> krbtgt/KDCTEST.COM at DMZ.KDCTEST.COM principal on both sides. You can use
> mmc
> and ADSIEdit to look at AD at the acocunt you created for the trust to see
> the key version number on 2003.
>
> You could use ethereal (wireshark) on Windows to watch the client contact
> the
> AD to get a cross realm ticket, then try and use it with the krb KDC to
> get
> the service ticket. It would show the kvno and enctypes being used.
>
> It could also be the keys don't match, because of the way they where
> generated from passwords on each side. I assume you used the 2003 ktpass
> Getting a keytab with the out option could help identify problems too.
>
> ---snip--
> --
>
>   Douglas E. Engert  <DEEngert at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>