Re: Windows GSSAPI ssh connection via cross-realm authentication problems
- From: deengert@xxxxxxx ("Douglas E. Engert")
- Date: Fri, 18 Aug 2006 09:24:39 -0500
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@xxxxxxxxxxxxxxx principal on both sides. You can use mmc
and ADSIEdit to look at AD at the aco*** 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@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxx, 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@kdcdmz ~]# ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: l
slot KVNO Principal
---- ----
---------------------------------------------------------------------
1 3 host/kdcdmz.kdctest.com@xxxxxxxxxxxxxxx
2 3 host/kdcdmz.kdctest.com@xxxxxxxxxxxxxxx
3 4 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
4 4 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
5 3 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
6 3 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
7 3 host/kdcdmz.kdctest.com@xxxxxxxxxxxxxxx
8 3 host/kdcdmz.kdctest.com@xxxxxxxxxxxxxxx
9 4 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
10 4 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
11 5 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
12 5 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
13 3 host/kdcdmz.kdctest.com@xxxxxxxxxxxxxxx
14 3 host/kdcdmz.kdctest.com@xxxxxxxxxxxxxxx
15 3 host/kdcdmz.kdctest.com@xxxxxxxxxxxxxxx
16 3 host/kdcdmz.kdctest.com@xxxxxxxxxxxxxxx
17 4 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
18 4 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
19 5 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
20 5 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
The keytab from the ssh server:
[root@kdcvps1 pam-krb5-2.0]# ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: l
slot KVNO Principal
---- ----
---------------------------------------------------------------------
1 6 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
2 6 host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
Listing the keytabs in kadmin shows matching encryption types. Here's my
/etc/krb5.conf file from the kdc:
[root@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@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@xxxxxxxxxxxxxxx
admin/admin@xxxxxxxxxxxxxxx
host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
host/kdcvps1@xxxxxxxxxxxxxxx
jason.mogavero@xxxxxxxxxxxxxxx
kadmin/admin@xxxxxxxxxxxxxxx
kadmin/changepw@xxxxxxxxxxxxxxx
kadmin/history@xxxxxxxxxxxxxxx
kdcadmin/admin@xxxxxxxxxxxxxxx
kdcadmin@xxxxxxxxxxxxxxx
krbtgt/DMZ.KDCTEST.COM@xxxxxxxxxxxxxxx
krbtgt/DMZ.KDCTEST.COM@xxxxxxxxxxx
krbtgt/KDCTEST.COM@xxxxxxxxxxxxxxx
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@xxxxxxxxxxx)
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@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/kerberos
--
Douglas E. Engert <DEEngert@xxxxxxx>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list Kerberos@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/kerberos
.
- Follow-Ups:
- Re: Windows GSSAPI ssh connection via cross-realm authentication problems
- From: "Jason Mogavero"
- Re: Windows GSSAPI ssh connection via cross-realm authentication problems
- References:
- Windows GSSAPI ssh connection via cross-realm authentication problems
- From: "Jason Mogavero"
- Windows GSSAPI ssh connection via cross-realm authentication problems
- Prev by Date: Re: AW: AW: Validation with Kerberos 5, SAP Linux, SNC for SSO
- Next by Date: Re: kpasswd: Failed decrypting request
- Previous by thread: Re: Windows GSSAPI ssh connection via cross-realm authentication problems
- Next by thread: Re: Windows GSSAPI ssh connection via cross-realm authentication problems
- Index(es):