☰

Настройки GPO для аутентификации Kerberos

tag-icon • tag-icon windows active-directory kerberos ntlm
Настройки GPO для аутентификации Kerberos

Моему клиенту требуется SSO в домене Windows для моего веб-сервера/сервера приложений на базе Linux. На сервере установлен собственный keytab, и все работает нормально. В домене Windows (EXAMPLE.ORG) есть учетная запись пользователя службы с SPN HTTP/server.example.org. Мой сервер приложений (WildFly) требует аутентификации Kerberos и запрещает аутентификацию NTLM.

У меня есть тестовый домен (на основе 2016 года), который был создан с настройками по умолчанию. Я пытаюсь повторить эту настройку в тестовом домене и не могу заставить работать Kerberos. Я вижу запрос на согласование от сервера, но клиент всегда возвращает билет NTLM.

WWW-Authenticate: Negotiate                 (request)
Authorization: Negotiate TlRMTVNTU.....     (reply)

В инфраструктуре клиента я вижу то же самое с билетом Kerberos.

WWW-Authenticate: Negotiate                 (request)
Authorization: Negotiate YIIHmAYGKw....     (reply)

Единственное отличие (помимо GPO), которое я вижу, это то, что мой SPN не находится внутри того же домена DNS. Мой домен AD — tdm.sample.org, а сервер — server.sample.org, не знаю, имеет ли это значение.

Некоторое время назад у меня была такая же проблема и в домене. И клиент IE, и Windows Server 2016 с IIS, присоединенные к одному домену, тоже использовали NTLM.

Я полагаю, что существует несколько настроек GPO, регулирующих, как клиент может или не может авторизовать, но ни один из прочитанных мной документов не помог.

Есть ли четкое описание ограничений, которые накладывает аутентификация клиента Kerberos, или какие-либо подсказки или стратегии отладки, которые можно применить?

решение1

Существует ряд ограничений, когда Windows даже не пытается выполнить авторизацию Kerberos.

1. SPN указывает на PTR, а не на веб-псевдоним

Если ваш не-домен-член веб-сервера имеет псевдоним, вам не нужно назначать SPN для этого псевдонима. Он будет проверен на основе реальной записи DNS этого сервера.

Допустим, у вас есть это:

A record server.example.org -> 10.0.0.1
PTR record 10.0.0.1 -> server.example.org
CNAME record webapp.example.org -> server.example.org

Доступwebapp.example.orgвам не нужен SPNHTTP/webapp.example.org, вы должны назначитьHTTP/сервер.example.orgТОЛЬКО в запись службы. Я считаю, что это должен быть IP-адрес, если нет записи PTR.

2. Члены домена НЕ должны называться никакими другими именами.

У меня есть сервер-член домена с включенными IIS и встроенной аутентификацией Windows. Из-за моей сетевой настройки у него есть настройка DNS как в недоменной, так и в доменной сети:

srv.example.org -> 10.0.0.1
10.0.0.1 -> srv.example.org

И он также зарегистрирован в домене:

srv.tdm.example.org -> 10.0.0.1

Этот сервер не разрешит Kerberos, если доступ к нему осуществляется как srv.example.org, Kerberos будет работать только если к нему осуществляется доступ как srv.tdm.example.org. Он даже не будет работать, если к нему осуществляется доступ по IP-адресу.

Я предполагаю, что природа этого факта обусловлена ​​разрешением имен Windows в домене, которое обычно происходит до DNS.

Я продолжу поиск и обновлю этот ответ.

Связанный контент