I am currently setting up an environment where I have a set of Solaris and Linux machines, using a dedicated Krberos 5 realm (MIT, on Solaris 11, krb5-config --version
returns: Solaris Kerberos (based on MIT Kerberos 5 release 1.6.3)
). We also have an Active Directory (Windows 2003) server for a separate realm.
My goal is to have all users in the AD server, and the host/nnn, nfs/nnn and cifs/nnn principals in the MIT-based realm. I'm trying to set up cross-domain trust between these two realms.
Assume the following:
- Unix realm: EXAMPLE.COM
- AD realm: AD.EXAMPLE.COM
I've set up the AD cross-realm trust according to the Microsoft documentation, with two-way trust.
What happens is that cross-realm authentication only works in one direction. From AD to Unix works:
# kinit adtest@AD.EXAMPLE.COM
Password for adtest@AD.EXAMPLE.COM:
root@clienttest2:~# kvno ltest@EXAMPLE.COM
ltest@EXAMPLE.COM: kvno = 1
But, the opposite does not, and gives me an error message: KDC has no support for encryption type while getting credentials for adtest@AD.EXAMPLE.COM
# kinit ltest@EXAMPLE.COM
Password for ltest@EXAMPLE.COM:
root@clienttest2:~# kvno adtest@AD.EXAMPLE.COM
kvno: KDC has no support for encryption type while getting credentials for adtest@AD.EXAMPLE.COM
Note that I have tried all sorts of different things. Some of those being:
- Configured the cross-realm keys on the Unix side to use
rc4-hmac
only, with the effect that the call tokvno
won't even be able to find the KDC on the Microsoft side. - Added
default_tkt_enctypes
anddefault_tgs_enctypes
entries to force the use ofrc4-hmac
. This was necessary to just get login authentication against AD to work.
What could be the cause of this, and how can I figure out what is actually going on? In particular, it would be very helpful to know exactly what encryption type it's trying to use which the KDC has no support for. It would also be useful to know which KDC that sent the error.
For completeness, here is the content of the krb5.conf
file:
[libdefaults]
default_realm = EXAMPLE.COM
allow_weak_crypto = true
verify_ap_req_nofail = false
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
[realms]
EXAMPLE.COM = {
kdc = unix-server.example.com
admin_server = unix-server.example.com
}
AD.EXAMPLE.COM = {
kdc = ad-server.ad.example.com
admin_server = ad-server.ad.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
.ad.example.com = AD.EXAMPLE.COM
[capaths]
EXAMPLE.COM = {
AD.EXAMPLE.COM = .
}
AD.EXAMPLE.COM = {
EXAMPLE.COM = .
}
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable = true
}
Best Answer
I have solved the problem. I'm posting a reply here in case someone else faces the same issue.
The solution was very simple. I needed to make sure that the cross-realm authentication principals were created with a single encoding type, of type
rc4-hmac
:As far as I can tell, what happens is that the MIT KDC uses the most secure encoding type when sending the ticket to the AD server. The AD server is unable to handle that encoding and thus replied with the error that the encryption type is not supported. By only having a single encoding type for the principals, the MIT server will use that type when talking to the AD server.