Вопрос или проблема
Я разработчик для малого бизнеса. Одно из приложений — это веб-приложение ASP.NET, размещенное на внутреннем сервере IIS. Приложение использует Windows-аутентификацию и имперсонацию для доступа к внутреннему SQL-серверу. Все пользователи работают на Windows-машинах и входят в систему с использованием учетных записей Active Directory в одном и том же домене.
Приложение работало нормально до нескольких недель назад, когда один пользователь сообщил, что получает следующее сообщение об ошибке:
Не удалось войти в систему для пользователя ‘NT AUTHORITY\ANONYMOUS LOGON’
Все остальные пользователи могут без проблем получить доступ к приложению. Вход в систему с проблемной учетной записью AD на другом компьютере проходит без ошибок. Вход в систему на проблемном компьютере с использованием другой рабочей учетной записи AD приводит к ошибке.
Доступ к странице WhoAmI.aspx показывает NEGOTIATE (KERBEROS) как AUTH_TYPE и показывает учетную запись пользователя AD, так что фактически передача Windows-учетных данных происходит (по крайней мере, на первом этапе).
Проблема явно ограничивается этим одним компьютером, а не учетной записью AD или каким-либо из серверов.
Компьютер недавно обновился до Windows 11 24H2. Мне неизвестно о каких-либо изменениях в коде, AD или любых Групповых Политик для этого пользователя.
Ранее у меня были проблемы с Windows Credential Guard, вызывающим проблемы с двойными переходами; я проверил и Credential Guard НЕ включен на проблемном компьютере.
Это, похоже, проблема двойного перехода, но я разработчик, так что это не в моей области экспертизы. Я не уверен, что может вызывать проблему или что исследовать дальше. Буду очень благодарен за любую помощь.
Ответ или решение
Теория
Проблема, описанная вами, известна как "двойной прыжок" (Double Hop), которая часто встречается в средах, где используется аутентификация Kerberos. Проблема заключается в следующем: при использовании Kerberos, когда пользователь пытается получить доступ к ресурсу на одном сервере (например, веб-приложению на IIS), а затем это приложение пытается получить доступ к другому ресурсу (например, к базе данных на SQL Server), передача учетных данных для второго "прыжка" может не происходить. Вместо этого передается учетная запись ‘NT AUTHORITY\ANONYMOUS LOGON’, что вызывает ошибку доступа.
IIS поддерживает Windows-аутентификацию, которая в принципе должна позволять передавать учетные данные AD между серверами. Однако здесь есть подводные камни, связанные с безопасностью и настройками среды.
Пример
Рассматриваем ситуацию, когда у нас есть приложение А на сервере S1, которое обращается к базе данных Б на сервере S2. Пользователь U1 из Active Directory пытается получить доступ к приложению А, а затем приложение А пытается получить доступ к Б, чтобы получить или сохранить данные. Если Kerberos неправильно настроен или если существуют проблемы на уровне клиентской машины (например, политики безопасности, особенности обновления ОС и т.д.), то учетные данные U1 не передаются от A к B.
Ваша конкретная проблема интересна тем, что она проявляется лишь на одном клиентском компьютере, что говорит о проблемах на уровне конфигурации этого компьютера, а не серверов или учетных записей AD.
Применение
На основе вашего описания, вероятнее всего, что проблема связана с клиентским компьютером, который недавно обновили до Windows 11 24H2. Поскольку другие машины работают корректно, попробуем предложить несколько шагов для диагностики и устранения проблемы:
-
Проверка SPN (Service Principal Names):
- Убедитесь, что SPN корректно зарегистрированы в Active Directory для аккаунтов, используемых веб-сервером и SQL Server.
- Используйте команду
setspnдля проверки записей.
-
Настройки безопасности и политики:
- Проверьте, не изменились ли после обновления политики безопасности на машине.
- Обратите внимание на политики, связанные с аутентификацией (Local Security Policy -> Local Policies -> Security Options).
-
Проверка Kerberos:
- Убедитесь, что для проблемы нет проблем с разрешением имен, поскольку Kerberos требует точного соответствия имен домена.
- Проверьте кэш Kerberos, удостоверившись, что он обновлён, и что в кэше нет старых или поврежденных билетов, с помощью утилит
klist purge.
-
Выключить временно все анти-вирусные программы и фаерволы:
- Иногда они могут блокировать передачу необходимых пакетов.
- Протестируйте работу приложения без них для исключения помех с их стороны.
-
Обновление драйверов и прошивок:
- Windows 11 может иметь специфические требования к драйверам сетевых адаптеров.
- Проверьте, что все системные драйвера обновлены до самых последних версий, совместимых с Windows 11.
-
Проверка GPO:
- Проверьте групповую политику для данного компьютера и аккаунта на предмет её обновлений после перехода на новую ОС.
-
Трассировка сети:
- Используйте утилиты анализа сетевого трафика, такие как Wireshark, для диагностики, чтобы увидеть, какие пакеты теряются или проходят не так, как ожидалось.
Эти рекомендации должны позволить вам более детально понять, где именно происходит сбой и какое решение можно предложить. Если проблема остаётся нерешенной, может иметь смысл обратиться за поддержкой к специалистам, специализирующимся на сетях и безопасности Windows, так как это требует углубленного анализа и возможной конфигурации серверной части.