“KDC has no support for encryption type” when setting up cross-realm trust between MIT Kerberos and Active Directory

Question

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 to kvno won't even be able to find the KDC on the Microsoft side.
• Added default_tkt_enctypes and default_tgs_enctypes entries to force the use of rc4-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
    }

Answer 1

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:

addprinc -e rc4-hmac krbtgt/AD.EXAMPLE.COM@EXAMPLE.COM
addprinc -e rc4-hmac krbtgt/EXAMPLE.COM@AD.EXAMPLE.COM

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.