Перекрестное доверие между Active Directory и MIT Kerberos
В настоящее время я занимаюсь расширением своей среды разработки, которая до сих пор использовалась только для серверов 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, который на первый взгляд казался многообещающим, но не мог не поможет мне решить мою проблему. Любая помощь с благодарностью!
1 ответ
Честное предупреждение, мои знания в этой области чрезвычайно устарели на данный момент. Как и в начале 2000-х годов, Windows 2003 эпохи Active Directory. Так что теперь все может работать по-другому.
Основная проблема заключается в том, что Windows не знает, как найти KDC для вашей области MIT по умолчанию (по иронии судьбы, она не просто использует DNS для поиска, как это делает для AD). Там есть утилита под названием ksetup.exe это позволит вам сопоставить имя области с одним или несколькими серверами KDC. В конечном счете, эта утилита просто устанавливает некоторые параметры реестра. Таким образом, вы можете автоматизировать это с помощью групповой политики, если это необходимо.
Обновление: @grawity упомянул, что Windows может действительно находить KDC через DNS, если существуют надлежащие записи SRV и ksetup используется, по крайней мере, для определения области.
У нас также были, по сути, "теневые" учетные записи в AD, которые соответствовали пользователям, определенным в области MIT. Пароли этих учетных записей не имели значения, они просто должны были существовать. Возможно, мы также установили некоторые дополнительные атрибуты, такие как UPN или SPN, которые каким-то образом были связаны с областью MIT. Память хоть и туманная.
Следует также помнить о поддерживаемых типах шифрования между AD и вашей областью MIT. Если оба довольно недавно, вы, вероятно, будете в порядке. Но когда мы делали это, наша область MIT была старой, и нам пришлось добавить групповую политику в AD, чтобы добавить некоторые устаревшие типы шифрования, поддерживаемые областью MIT.
Надеюсь, это поможет вам двигаться в правильном направлении.