Назад | Перейти на главную страницу

«KDC не поддерживает тип шифрования» при настройке межсферного доверия между MIT Kerberos и Active Directory.

В настоящее время я настраиваю среду, в которой у меня есть набор машин Solaris и Linux, с использованием выделенной области Krberos 5 (MIT, на Solaris 11, krb5-config --version возвращает: Solaris Kerberos (based on MIT Kerberos 5 release 1.6.3)). У нас также есть сервер Active Directory (Windows 2003) для отдельной области.

Моя цель состоит в том, чтобы все пользователи на сервере AD, а также участники host / nnn, nfs / nnn и cifs / nnn находились в области MIT. Я пытаюсь установить междоменное доверие между этими двумя сферами.

Предположим следующее:

Область Unix: ПРИМЕР.COM
Область AD: AD.EXAMPLE.COM

Я установил межсферное доверие AD в соответствии с Документация Microsoft, с двусторонним доверием.

Что происходит, так это то, что межсферная аутентификация работает только в одном направлении. Из AD в Unix работает:

# kinit adtest@AD.EXAMPLE.COM
Password for adtest@AD.EXAMPLE.COM: 
root@clienttest2:~# kvno ltest@EXAMPLE.COM
ltest@EXAMPLE.COM: kvno = 1

Но обратного нет и выдает сообщение об ошибке: KDC не поддерживает тип шифрования при получении учетных данных для 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

Заметьте, что я пробовал много разных вещей. Некоторые из них:

Настроил межсферные ключи на стороне Unix для использования rc4-hmac только с тем эффектом, что вызов kvno даже не сможет найти KDC на стороне Microsoft.
Добавлено default_tkt_enctypes и default_tgs_enctypes записи для принудительного использования rc4-hmac. Это было необходимо только для того, чтобы аутентификация для входа в AD работала.

Что могло быть причиной этого и как я могу понять, что происходит на самом деле? В частности, было бы очень полезно знать, какой именно тип шифрования он пытается использовать, который KDC не поддерживает. Также было бы полезно знать, какой KDC отправил ошибку.

Для полноты, вот содержание krb5.conf файл:

[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
    }

Я решил проблему. Я отправляю здесь ответ на случай, если кто-то еще столкнется с той же проблемой.

Решение было очень простым. Мне нужно было убедиться, что участники межсферной аутентификации были созданы с одним типом кодировки типа rc4-hmac:

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

Насколько я могу судить, происходит то, что MIT KDC использует наиболее безопасный тип кодирования при отправке билета на сервер AD. Сервер AD не может обработать эту кодировку и, таким образом, ответил с ошибкой о том, что тип шифрования не поддерживается. Имея только один тип кодировки для принципалов, сервер MIT будет использовать этот тип при разговоре с сервером AD.

Я решил это, проверив ошибку в журнале. В сообщении об ошибке указано:
- Журналы начинаются во вторник 2018-05-22 13:03:55 UTC, заканчиваются в понедельник 2018-06-18 10:41:01 UTC. -
18 июня, 10:40:55 nlxxp1 realmd [1609]: * Разрешение: _ldap._tcp.local.domain
18 июня, 10:40:55 nlxxp1 realmd [1609]: * Выполнение поиска LDAP DSE на: 10.x.x.1
18 июня, 10:40:55 nlxxp1 realmd [1609]: * Выполнение поиска LDAP DSE на: 10.x.x.30
18 июня 10:40:55 nlxxp1 realmd [1609]: * Выполнение поиска LDAP DSE на: 10.x.x.60
18 июня, 10:40:55 nlxxp1 realmd [1609]: * Успешно обнаружено: local.domain
18 июня, 10:41:00 nlxxp1 realmd [1609]: * Предполагается, что пакеты установлены
18 июня, 10:41:00 nlxxp1 realmd [1609]: * LANG = C / usr / sbin / adcli join --verbose --domain local.domain --domain-realm LOCAL.DOMAIN --domain-controller 10.xx1 --login-type user --login-user localuser --stdin-password
18 июня, 10:41:00 nlxxp1 realmd [1609]: * Использование имени домена: local.domain
18 июня, 10:41:00 nlxxp1 realmd [1609]: * Расчетное имя учетной записи компьютера из fqdn: NLXXP1
18 июня, 10:41:00 nlxxp1 realmd [1609]: * Использование области домена: local.domain
18 июня, 10:41:00 nlxxp1 realmd [1609]: * Отправка эхо-запросов netlogon на контроллер домена: cldap: //10.x.x.1
18 июня, 10:41:01 nlxxp1 realmd [1609]: * Получена информация NetLogon от: dc.local.domain
18 июня, 10:41:01 nlxxp1 realmd [1609]: * Записал фрагмент krb5.conf в /var/cache/realmd/adcli-krb5-QudocS/krb5.d/adcli-krb5-conf-8Gyp0B
18 июня 10:41:01 nlxxp1 realmd [1609]:! Не удалось пройти аутентификацию как: localuserc@LOCAL.DOMAIN: KDC не поддерживает тип шифрования
18 июня, 10:41:01 nlxxp1 realmd [1609]: adcli: не удалось подключиться к домену local.domain: не удалось пройти аутентификацию как: localuser@LOCAL.DOMAIN: KDC не поддерживает тип шифрования
18 июня, 10:41:01 nlxxp1 realmd [1609]:! Не удалось присоединиться к домену

Мой домен - это смешанный домен с контроллером домена 2003 года.
После того, как я вошел в DNS и изменил запись _ldap._tcp.local.domain DC 2003 (я присвоил ей более тяжелый вес 400), он взял более новую (2012R2 DC), которая могла присоединить сервер к домену.

Я предполагаю, что используемый тип шифрования не поддерживался DC 2003 года.