Windows GSSAPI ssh connection via cross-realm authentication problems
Douglas E. Engert
deengert at anl.gov
Fri Aug 18 10:24:39 EDT 2006
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.
>
> 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.
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the Kerberos
mailing list