В настоящее время я занимаюсь расширением своей среды разработки, которая до сих пор использовала только серверы Linux, путем добавления машин под управлением Windows Server 2016. Процесс аутентификации обрабатывается MIT Kerberos. Для новых компьютеров с Windows я планирую использовать Active Directory. Поскольку я не хочу управлять пользователями в двух системах, я устанавливаю межсферное доверие между Windows AD и уже существующей установкой MIT Kerberos.
Для этого я следовал этому руководству: https://bluedata.zendesk.com/hc/en-us/articles/115007484067-How-To-Establish-Cross-Realm-Trust-from-MIT-KDC-to-AD.
Теперь я заметил, что могу получить билет из Windows AD для пользователя из AD на Linux-машине: Запуск kinit Administrator@AD.DOMAIN.LOCAL завершается без ошибок и выдает мне билет, как и ожидалось.
С другой стороны, я не могу войти ни на одну из машин Windows, используя учетную запись из настройки MIT Kerberos. Попытка войти в систему с использованием моей тестовой учетной записи (test@DOMAIN.LOCAL из области MIT DOMAIN.LOCAL) выдает следующую ошибку:
«База данных безопасности на сервере не имеет учетной записи компьютера для доверительных отношений этой рабочей станции».
Еще я замечаю, что когда я пытаюсь проверить доверительные отношения с помощью команды netdom trust DOMAIN.LOCAL /Domain:AD.DOMAIN.LOCAL /Kerberos /verbose /verify, Я получаю следующее сообщение об ошибке:
«Невозможно связаться с доменом DOMAIN.LOCAL. Команда не выполнена успешно».
Похоже, что Windows AD не может взаимодействовать с установкой MIT Kerberos, что кажется странным, потому что, по-видимому, все работает наоборот. Я уже дважды проверил, что все записи DNS (domain.local, ad.domain.local и FQDN для KDC) соответствуют правильным IP-адресам. Исследуя проблему, я наткнулся на этот пост https://stackoverflow.com/questions/45236577/using-mit-kerberos-as-account-domain-for-windows-ad-domain, который сначала казался многообещающим, но не помог мне решить мою проблему. Любая помощь приветствуется!
Честное предупреждение, мои знания в этой области на данный момент сильно устарели. Как и в начале 2000-х, Active Directory эпохи Windows 2003. Так что теперь все может работать по-другому.
Основная проблема заключается в том, что Windows не знает, как найти KDC для вашей области MIT по умолчанию (по иронии судьбы, она не будет просто использовать DNS для поиска, как это делается для AD). Есть утилита под названием ksetup.exe это позволит вам сопоставить имя области с одним или несколькими серверами KDC. В конечном итоге эта утилита просто устанавливает некоторые значения реестра. Так что при необходимости вы можете автоматизировать это с помощью групповой политики.
Обновление: @grawity упомянул, что Windows может фактически найти KDC через DNS, если существуют соответствующие записи SRV и ksetup используется, по крайней мере, для определения области.
У нас также были «теневые» учетные записи в AD, соответствующие пользователям, определенным в области MIT. Пароли от этих учетных записей не имели значения, они просто должны были существовать. Возможно, мы также установили некоторые дополнительные атрибуты, такие как UPN или SPN, которые каким-то образом связаны с областью MIT. Хотя память туманна.
Еще одна вещь, о которой следует знать, - это поддерживаемые типы шифрования между AD и вашей областью MIT. Если оба они появились совсем недавно, вероятно, все будет в порядке. Но когда мы это делали, наша область MIT была старой, и нам пришлось добавить групповую политику в AD, чтобы добавить некоторые устаревшие типы шифрования, которые поддерживала область MIT.
Надеюсь, это поможет вам двигаться в правильном направлении.