Вопрос или проблема
Существует ответ на запрос AD с аутентификацией по паролю, который работает нормально локально. А как насчет аутентификации Kerberos? Запуск ldapsearch с аутентификацией GSSAPI выдает следующую ошибку:
$ ldapsearch -ZZ -Y GSSAPI -H ldap://ad.server.fqdn/ -b "CN=Caleb,CN=Users,DC=samdom,DC=example,DC=com" cn
Аутентификация SASL/GSSAPI начата
ldap_sasl_interactive_bind: местная ошибка (-2)
дополнительная информация: SASL(-1): общая ошибка: GSSAPI Ошибка: Непредвиденная ошибка GSS. Небольшой код может предоставить больше информации (Сервер не найден в базе данных Kerberos)
$
В журнале Samba AD DC это отображается следующим образом:
...
Kerberos: TGS-REQ [email protected] с ipv4:<IP-адрес клиента>:48092 для ldap/<IP сервера>@SAMDOM.EXAMPLE.COM [канонизация, возобновляемый]
...
Запрос билета осуществляется для IP DC, а не для FQDN сервера, что очевидно неверно; FQDN сервера показывается в записях SPN, как и должно быть. Но как мне это исправить?
Я вижу эту проблему даже с минимальным krb5.conf
[libdefaults]
default_realm = SAMDOM.EXAMPLE.COM
Вы не сможете получить билеты Kerberos для общего псевдонима ad.server.fqdn – известны только отдельные FQDN DC, и они не взаимозаменяемы (каждый имеет свои собственные ключи Kerberos). Поэтому обычно вам потребуется двухэтапный процесс: сначала получить имена DC через записи DNS SRV, затем указать ldapsearch запрашивать конкретный DC по его имени.
Например:
dig +short -t srv _ldap._tcp.ad.example.comldapsearch -H ldaps://dc01.ad.example.com -N -Y GSS-SPNEGO
(…признаю, что точно не помню, создает ли Active Directory записи SRV _ldap._tcp по умолчанию – хотя у меня они есть с Samba – или вам нужно смотреть на _kerberos._udp.)
Использование общего псевдонима может иногда сработать из-за того, что Unix Kerberos выполняет канонизацию через обратный DNS, но на это не стоит полагаться – когда за псевдонимом стоит более одного DC, может часто случиться, что libldap подключается к серверу A, но запрашивает билеты для сервера B. (Когда это происходит, вы получаете таинственные ошибки “KRB_AP_ERR_MODIFIED”, что на самом деле означает “несоответствие ключа” в этом случае.)
[Правка: Добавлена опция -N, чтобы отключить принудительную канонизацию rDNS в ldapsearch.]
Кроме того, Windows вообще не выполняет канонизацию на основе обратного DNS, а дистрибутивы Linux начали отключать ее также (хотя libldap принудительно повторно включает ее…), и TGS-REQ на основе IP в ваших журналах указывает на то, что у вас в любом случае нет работающего rDNS.
Обратите внимание, что в большинстве дистрибутивов системная библиотека Kerberos предоставляется MIT Kerberos, в то время как инструменты Samba, такие как ‘ldbsearch’, построены против [ее вендорной копии] Heimdal Kerberos, поэтому два инструмента могут иметь несколько различное поведение в отношении канонизации имен.
Для полноты, агрегирую решения здесь. Спасибо Роуланду Пенни и пользователю1686 за их помощь!
- Используйте
ldbsearch. Пример вызова:
ldbsearch -H dap://ad.server.fqdn/ -b "CN=Caleb,CN=Users,DC=samdom,DC=example,DC=com" cn
- Исправьте обратный DNS-запрос (в моем случае IPv6 rDNS) и продолжайте использовать
ldapsearch. Не требуйте TLS, иначе SASL будет жаловаться:
ldapsearch -Y GSSAPI -H ldap://ad.server.fqdn/ -b "CN=Caleb,CN=Users,DC=samdom,DC=example,DC=com" cn
Ответ или решение
Для выполнения запроса атрибутов пользователей из Samba AD DC в Linux с использованием Kerberos-авторизации, вы можете столкнуться с проблемами, связанными с получением билетов Kerberos, если у вас неверно настроены параметры. Я постараюсь описать полное решение данной ситуации.
Основные шаги
-
Получение DC с помощью DNS SRV-записей:
Одной из причин ошибки является то, что Kerberos не может получить билет для общего имени сервера, поскольку у каждого контроллера домена (DC) есть свои ключи Kerberos. Вам необходимо сначала определить имя конкретного DC с помощью DNS SRV-записей.Выполните команду:
dig +short -t srv _ldap._tcp.ad.example.comЭто позволит вам получить список доступных контроллеров домена.
-
Использование конкретного DC в запросе ldapsearch:
Получив имя доступного DC, выполните запрос с использованием ldapsearch, указав конкретный DC. Например:ldapsearch -H ldaps://dc01.ad.example.com -N -Y GSS-SPNEGO -b "CN=Caleb,CN=Users,DC=samdom,DC=example,DC=com" cnОбратите внимание на флаг
-N, который отключает принудительное использование обратной DNS-канонизации. -
Корректировка конфигурации Kerberos:
Убедитесь, что ваш файлkrb5.confнастроен правильно. Минимальный пример:[libdefaults] default_realm = SAMDOM.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true -
Использование ldbsearch как альтернативы:
Если вы хотите избегать некоторых проблем с ldapsearch, рассмотрите возможность использования инструментаldbsearch, предоставляемого Samba:ldbsearch -H dap://dc01.ad.example.com/ -b "CN=Caleb,CN=Users,DC=samdom,DC=example,DC=com" cn -
Исправление проблемы с обратным DNS:
Если вы хотите продолжить использовать ldapsearch, убедитесь, что у вас настроен правильный обратный DNS. Эта настройка может быть важна, если вы полагаетесь на Canonicalization.
Заключение
Таким образом, основной проблемой является неправильное разрешение имени при запросах Kerberos. Использование конкретных имен контроллеров домена и правильная настройка Kerberos и DNS являются ключевыми аспектами для успешного выполнения запросов AT пользователям AD. Если у вас возникнут дополнительные вопросы, не стесняйтесь обращаться за помощью!