Windows GSSAPI ssh connection via cross-realm authentication problems

Jason Mogavero chemhead at gmail.com
Thu Aug 17 18:08:09 EDT 2006


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:

Aug 17 15:18:09 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
{23 3 1 24 -135}) 172.16.102.28: PROCESS_TGS: authtime 0,  <unknown client>
for host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM, Key table entry not found
Aug 17 15:18:09 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
{23 3 1 24 -135}) 172.16.102.28: PROCESS_TGS: authtime 0,  <unknown client>
for host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM, Key table entry not found

Here's the ktutil output from the kdc showing that I have keytabs for the
ssh server.  Note that I have no idea why it has so many entries.

[root at kdcdmz ~]# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  l
slot KVNO Principal
---- ----
---------------------------------------------------------------------
   1    3  host/kdcdmz.kdctest.com at DMZ.KDCTEST.COM
   2    3  host/kdcdmz.kdctest.com at DMZ.KDCTEST.COM
   3    4 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
   4    4 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
   5    3 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
   6    3 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
   7    3  host/kdcdmz.kdctest.com at DMZ.KDCTEST.COM
   8    3  host/kdcdmz.kdctest.com at DMZ.KDCTEST.COM
   9    4 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
  10    4 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
  11    5 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
  12    5 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
  13    3  host/kdcdmz.kdctest.com at DMZ.KDCTEST.COM
  14    3  host/kdcdmz.kdctest.com at DMZ.KDCTEST.COM
  15    3  host/kdcdmz.kdctest.com at DMZ.KDCTEST.COM
  16    3  host/kdcdmz.kdctest.com at DMZ.KDCTEST.COM
  17    4 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
  18    4 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
  19    5 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
  20    5 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM

The keytab from the ssh server:

[root at kdcvps1 pam-krb5-2.0]# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  l
slot KVNO Principal
---- ----
---------------------------------------------------------------------
   1    6 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
   2    6 host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM

Listing the keytabs in kadmin shows matching encryption types.  Here's my
/etc/krb5.conf file from the kdc:

[root at kdcdmz ~]# more /etc/krb5.conf
[logging]
 kdc = FILE:/var/kerberos/krb5kdc/kdc.log
 admin_server = FILE:/var/kerberos/krb5kdc/kadmin.log

[libdefaults]
 default_realm = DMZ.KDCTEST.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false

[kdc]
 profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
 pam = {
[root at kdcdmz ~]# cat /etc/krb5.conf
[logging]
 kdc = FILE:/var/kerberos/krb5kdc/kdc.log
 admin_server = FILE:/var/kerberos/krb5kdc/kadmin.log

[libdefaults]
 default_realm = DMZ.KDCTEST.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false

[kdc]
 profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

[realms]
        DMZ.KDCTEST.COM = {
                kdc = kdcdmz.kdctest.com:88
                admin_server = kdcdmz.kdctest.com:749
        }

        KDCTEST.COM = {
                kdc = adauth.kdctest.com:88

        }

[domain_realm]
        kdctest01.kdctest.com = KDCTEST.COM
        .kdctest.com = DMZ.KDCTEST.COM
        kdctest.com = DMZ.KDCTEST.COM


I am thinking that this is some problem with the cross realm
auththentication, but I've created the principals in the Linux kdc for the
cross-realm trust and configured it on the Windows2003 side via a one-way
domain trust.  (tickets issued in the AD are trusted in the linux kdc)  I'm
using NetIDMgr to manage the windows tickets.

Here's the list of principals on the linux side:
kadmin:  listprincs
K/M at DMZ.KDCTEST.COM
admin/admin at DMZ.KDCTEST.COM
host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
host/kdcvps1 at DMZ.KDCTEST.COM
jason.mogavero at DMZ.KDCTEST.COM
kadmin/admin at DMZ.KDCTEST.COM
kadmin/changepw at DMZ.KDCTEST.COM
kadmin/history at DMZ.KDCTEST.COM
kdcadmin/admin at DMZ.KDCTEST.COM
kdcadmin at DMZ.KDCTEST.COM
krbtgt/DMZ.KDCTEST.COM at DMZ.KDCTEST.COM
krbtgt/DMZ.KDCTEST.COM at KDCTEST.COM
krbtgt/KDCTEST.COM at DMZ.KDCTEST.COM

On the windows side, I've used ksetup.exe to configure both realms.  Here's
the output:

C:\Documents and Settings\Administrator.ADAUTH>ksetup
default realm = kdctest.com (NT Domain)
DMZ.KDCTEST.COM:
        kdc = kdcdmz.kdctest.com
        Realm Flags = 0x0 none
KDCTEST.COM:
        kdc = adauth.kdctest.com
        Realm Flags = 0x6 TcpSupported Delegate
Mapping all users (*) to a local account by the same name (*).

I've checked "allow des encryption"  and "account is trusted for delegation"
in the AD user manager for the user I am connecting as.  I've also allowed
the windows ssh client computer to be trusted for delegation.  I'm pretty
sure the cross-realm part is working because, in Windows, I am issued a tgt
for the linux kdc.  (krbtgt/DMZ.KDCTEST.COM at KDCTEST.COM)

So tell me, what am I missing?  The windows username is not being
propagated, linux kdc reads it as <unknown client> and it is reporting that
the ssh server has no keytab, which is does.  (because it works on a linux
ssh connection)  Any point in the right direction would be great.



More information about the Kerberos mailing list