AlexXYZ
@AlexXYZ
O Keep Clear O

[Решено, Solved] Если linux-комп не в Active Directory, то он не считается компьютером домена?

Всем привет.
Если вопрос слишком краткий, то ситуация такая: есть windows домен с Active Directory. Есть Linux комп с суффиксом как у домена. Настраиваю на linux kerberos-аутентификацию web-сервера apache/php/*.keytab. Apache ни в какую не хочет узнавать пользователей домена. Есть оооочень веские подозрения, что windows-клиент не считает linux-комп за компьютер домена, не смотря на то, что суффиксы одинаковые (если вам что-то скажет ASN.1, то именно по нему узнал, что комп не признаётся за доменный). Когда-то давно "слышал", что в настройках политик Active Directory можно указать, что "считать" компьютерами домена (может быть только те, что есть в AD). Не подскажите, что это может быть за настройка?

P.S.
Есть отдельный тестовый домен (чистый), так там таких проблем с аутентификацией по kerberos нет. Суффиксы совпадают? - значит доменный!
P.P.S.
Настройки зон безопасности IE выполнены на доменный суффикс.

UPDATE:
Решение читайте в моём ответе ниже.
  • Вопрос задан
  • 1567 просмотров
Решения вопроса 1
AlexXYZ
@AlexXYZ Автор вопроса
O Keep Clear O
Проблема решена.
Вот небольшое расследование.

Есть два сервера. test-0001/apache,php/Centos 7.2 (нормально аутентифицирует по kerberos) и test-0002/apache,php/OracleLinux 7.2 (сбой аутентификации kerberos).

Анализ протокола обмена HTTP показал, что «почему-то» web-клиент (IE, FF, Chrome) как один отличают компьютер test-0002 от test-0001. Отличие состоит в том, что ключ аутентификации, которые web-клиент отправляет в качестве авторизации пользователя ооочень сильно отличается «размером»:
Запрос к test-0002 (сбой аутентификации по Kerberos):
96706c13d8894210bfe4d0fd2b2516e2.png080ede7e64b0434b9229c520d07af319.png

Запрос к test-0001 (аутентификация Kerberos выполняется нормально):
5825189ce16741359c1148fee30b70dd.pngb710650b34bf482d88f77adca35000ff.png

Давайте всё-таки выясним, почему ключ от test-0002 короче test-0001 ??? Начну с того, что формат ключа - ASN.1 (если интересно, то гляньте https://ru.wikipedia.org/wiki/ASN.1 ). В инете есть просмотрщик этого формата:
https://lapo.it/asn1js
Анализ ключа в запросе от test-0002:
1ceee5434ef44a08b17cee123e5ba515.png
1. NEGOEX – насколько я понял именно этот формат обеспечивает «объединение» нескольких аутентификаторов одного и того же пользователя в разных протоколах. В данном ключе вложен только протокол NTLM
2. Данные для протокола NTLM (который не поддерживается компонентом apache mod_auth_gssapi).

Анализ ключа в запросе к test-0001:
573bbcfea2e64351a1a27e4db461d303.png
Как видим во втором ключе уже присутствует протокол Kerberos!!! Занятно! Т.е. проблема для test-0002 не на стороне сервера, раз клиент сразу не отдаёт ему ключ правильного формата!

Хм. А давайте-ка посмотрим в журнал windows?
c7d2f48555b348cdb239d1b40e36af8b.png

0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
0x19 KDC_ERR_PREAUTH_REQUIRED

Опаньки! Это что такое??? Какая-то проблема с принципалом? И почему только с test-0002? (Записей, указывающих на другой компьютер, например, test-0001 не найдено). Получается, что браузер до ответа на запрос серверу уже что-то «подозревает», раз не отдаёт ему нужный ключ (ОЧЕНЬ БОЛЬШАЯ ПРОСЬБА: ЕСЛИ КТО-ТО ПОНИМАЕТ ПРОЦЕСС, КАК БРАУЗЕР ПРИНИМАЕТ РЕШЕНИЕ КАК СОЗДАТЬ КЛЮЧ ДЛЯ АУТЕНТИФИКАЦИИ - РАССКАЖИТЕ МНЕ НЕМНОГО ОБ ЭТОМ!!!).
Если порыться в интернете, то вопросов по этой ошибке много (https://www.google.ru/search?q=KDC_ERR_S_PRINCIPAL...), но в основном они без ответа. Тупик? Ничего подобного! Давайте глянем в документацию Microsoft по поводу SPN: https://msdn.microsoft.com/en-us/library/ms677949%...
b5334963f38a4f9ca87c087db77ed639.png
Т.е. spn моего сервиса должен быть зарегистрирован только в одном аккаунте. ЗАПОМНИМ ЭТО!!! И вот ещё один интересный момент: https://msdn.microsoft.com/en-us/library/ms677601%...
6545dfe4a1ad44b6acc6577a3163eeb3.png
Тут написано, что SPN должен быть уникальным. Если он не уникален, то аутентификация даст сбой.

А вот давайте проверим, а действительно ли SPN для сервера test-0002 уникален? На просторах интернета нашёлся простой скрипт powershell, который после небольшой модификации показывает интересующие нас SPN-ы: social.technet.microsoft.com/wiki/contents/article...
#Set Search
cls
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]“”)
$search.filter = “(servicePrincipalName=HTTP/test-*)”
$results = $search.Findall()

#list results
foreach($result in $results)
{
       $userEntry = $result.GetDirectoryEntry()
       Write-host "Object Name = " $userEntry.name -backgroundcolor "yellow" -foregroundcolor "black"
       Write-host "DN      =      "  $userEntry.distinguishedName
       Write-host "Object Cat. = "  $userEntry.objectCategory
       Write-host "servicePrincipalNames"
       $i=1
       foreach($SPN in $userEntry.servicePrincipalName)
       {
           Write-host "SPN(" $i ")   =      " $SPN       $i+=1
       }
       Write-host ""
}


Результат:
3e67af20a3d041779246cdaeb21598b9.pngWTF???

ПОЧЕМУ В ДВУХ РАЗНЫХ АККАУНТАХ ОДИН И ТОТ ЖЕ SPN??? (Помните, чуть выше я просил запомнить правило, что spn должен быть уникален и присвоен только одному аккаунту?) Или может быть я что-то неправильно понял? Пойдём дальше и давайте посмотрим атрибуты для учёток test-0002 и test-0001, но не через оснастку AD, а через оснастку ADSI:
2f16d1f71fcf40779ff6ac36b4824c2f.png
test-0002 – OK.
А вот для test-0001 нас ждёт СЮРПРИЗ (удивительно, что сюрприз связан с аккаунтом сервера на котором ВСЁ РАБОТАЕТ!!!):
a04ac318d20c4844b68b1f7127f8a934.png
Так, так!!! Оказывается, что spn для сервера test-0002 имеется в AD в двух экземплярах – в учётке test-0002_httpd и в учётке test-0001_httpd ! Чего по документации быть не должно! Вот это и был корень проблемы! Дубликат SPN.
После удаления дубликата всё заработало!!!

Всем спасибо за внимание.)))

P.S.
Рекомендация для заведения SPN. Нужно использовать команду setspn -S, а не servspn -A, т.к. setspn -S проверяет наличие дубликатов. Очень рекомендую к прочтению статью https://social.technet.microsoft.com/wiki/contents....
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
scarab
@scarab
Не считается. Чтобы считался, его надо ввести в домен - т.е. создать учётную запись компьютера в домене, назначить пароль и залогинить керберос туда (команда kinit, если мне память не изменяет).

В противном случае любой посторонний, включившийся в сеть и выставивший себе соответствующий domain name, мог бы получить доступ к инфраструктуре домена AD.
Ответ написан
CityCat4
@CityCat4
Внимание! Изменился адрес почты!
"Доменный" компьютер - это тот, который имеет учетку в домене. Учетка в домене нужна чтобы как минимум проходила аутентификация через керберос, без ввода пароля. Именно этот факт - без ввода пароля и есть признак - "доменный" или "чужой".
"Чужой" тоже может получить список пользователей и даже аутентифицировать юзеров, но для этого ему самому сначала надо в домене аутентифицироваться. Обычно это делается созданием фейкового юзера, не имеющего никаких прав и имеющего простой текстовый пароль. Пароль этого юзера указывается в конфиге в открытом виде. Так работает аутентификация через апач (AuthBasicProvider ldap), так работает PAM-модуль pam_ldap.so и NSS-модуль nss_ldap.so, так может работать аутентификатор squid. Так работает любой скрипт на Perl/PHP, которому нужно аутентифицировать юзеров в AD - redmine, horde, любой велосипед, использующий Net::LDAP.
Конечно, это неудобно и небезопасно. Поэтому и создают учетки компам в AD, настраивают керберос через ktpass и полученный keytab сбрасывают на линух - так например делают для squid.
Аутентифицироваться в домене можно и не заводя учетку. Но логин и пароль хоть какого-нибудь юзера из домена комп, который аутентифицируется, должен знать.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы