Назад | Перейти на главную страницу

Встроенная проверка подлинности Windows не работает на ПК, подключенном к сети AD

Задний план:

  1. Веб-сервер со стеком LAMP
  2. Веб-сервер имеет VPN-туннель к сети AD в штаб-квартире
  3. Несколько сетей AD по всему миру с туннелями VPN и доверительными отношениями с сетью HQ
  4. Проверка подлинности Kerberos настроена на веб-сервере и работает для всех сетей с использованием файлов ключей.
  5. Я веб-администратор, но не имею доступа ни к одной из конфигураций сети AD.

У нас есть проблема с одной сетью AD, которая проявляется только в IE или Chrome, когда компьютер, используемый для доступа к нашему веб-серверу, привязан к рассматриваемому AD. Маркер не передается, и в журналах сервера нет записей, связанных с согласованием маркера. Если мы используем Firefox и включаем параметры network.negotiate-auth, тогда пользователь может войти в систему без проблем, однако при использовании IE он получает сообщение об ошибке авторизации. Веб-сайт находится в зоне интрасети, и IWA проверяется (это контролируется GPO)

Если пользователи попытаются получить доступ к сайту с помощью IE или Chrome из-за пределов своего AD, они получат ожидаемое приглашение входа в систему аутентификации, а затем токен будет отправлен правильно.

Я разговаривал с администраторами сети, и они уверены, что для AD не требуется специальной конфигурации для обеспечения работы аутентификации Kerberos, но я не могу понять, почему аутентификация работает для шести других сетей AD и не работает в этой 1, если это не до Сама конфигурация AD.

Я что-то упускаю? Чем можно объяснить отказ от переговоров по токену?

[Примечание - это не срочно, и, поскольку я выхожу из офиса, отвечу на любые запросы для получения более подробной информации в понедельник]

Проблема заключалась в том, что токен отправлялся и автоматически предпринималась попытка согласования внутри сети AD, но это всегда приводило к сбою из-за шифрования, используемого при создании keytab.

Первоначально мы использовали -crypto DES-CBC-CRC но как только мы перешли на использование -crypto RC4-HMAC-NT проблема ушла.

Не эксперт в этом, но я склонен думать, что, если токены переговоров не обмениваются, проблема может заключаться в том, что приложение не имеет зарегистрированного SPN с именем пользователя, связанным с keytab.

Если это так, следующая команда, запущенная на сервере AD, может исправить это:

setspn –a HTTP / (yourhostname) (keytabusername)

например setspn -a HTTP / intranetappsrv.mycompany.com jbossaccount