5

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 [email protected]
Password for [email protected]: 
root@clienttest2:~# kvno [email protected]
[email protected]: kvno = 1

But, the opposite does not, and gives me an error message: KDC has no support for encryption type while getting credentials for [email protected]

# kinit [email protected]
Password for [email protected]: 
root@clienttest2:~# kvno [email protected]
kvno: KDC has no support for encryption type while getting credentials for [email protected]

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
    }

2 Answers 2

3

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/[email protected]
addprinc -e rc4-hmac krbtgt/[email protected]

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.

0

I solved this by checking the error in the journal. The error stated:
-- Logs begin at Tue 2018-05-22 13:03:55 UTC, end at Mon 2018-06-18 10:41:01 UTC. --
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Resolving: _ldap._tcp.local.domain
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Performing LDAP DSE lookup on: 10.x.x.1
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Performing LDAP DSE lookup on: 10.x.x.30
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Performing LDAP DSE lookup on: 10.x.x.60
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Successfully discovered: local.domain
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Assuming packages are installed
Jun 18 10:41:00 nlxxp1 realmd[1609]: * LANG=C /usr/sbin/adcli join --verbose --domain local.domain --domain-realm LOCAL.DOMAIN --domain-controller 10.x.x.1 --login-type user --login-user localuser --stdin-password
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Using domain name: local.domain
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Calculated computer account name from fqdn: NLXXP1
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Using domain realm: local.domain
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Sending netlogon pings to domain controller: cldap://10.x.x.1
Jun 18 10:41:01 nlxxp1 realmd[1609]: * Received NetLogon info from: dc.local.domain
Jun 18 10:41:01 nlxxp1 realmd[1609]: * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-QudocS/krb5.d/adcli-krb5-conf-8Gyp0B
Jun 18 10:41:01 nlxxp1 realmd[1609]: ! Couldn't authenticate as: [email protected]: KDC has no support for encryption type
Jun 18 10:41:01 nlxxp1 realmd[1609]: adcli: couldn't connect to local.domain domain: Couldn't authenticate as: [email protected]: KDC has no support for encryption type
Jun 18 10:41:01 nlxxp1 realmd[1609]: ! Failed to join the domain

My domain is a mixed domain with a 2003 DC.
After I went into DNS and changed the _ldap._tcp.local.domain record of the 2003 DC (I gave it a heavier weight 400) It picked up a newer (2012R2 DC) which was able to join the server to the domain.

I guess the encryption type used was not supported by the 2003 DC.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .