Вопрос или проблема
Мы имеем веб-сайт на нашем корпоративном интранете. Он имеет два https-связи на одном и том же сайте/сервере/порту:
https://mysite1.mycorp.ads – Внутренний сертификат, выданный нашим внутренним удостоверяющим центром
https://mysite2.subdomain.mycorp.com – Внешний сертификат, выданный публичным удостоверяющим центром
Когда пользователь (с повышенной или без повышенной учетной записью) пытается открыть #1, все работает как ожидалось – они автоматически аутентифицируются с помощью своей учетной записи Windows.
Когда пользователь без повышенной учетной записи пытается открыть #2, все работает как ожидалось.
Однако, когда пользователь с повышенной учетной записью пытается открыть #2, они автоматически входят с помощью своей повышенной учетной записи. Они могут успешно открыть окно инкогнито и войти с правильной (не повышенной) учетной записью, но автоматический вход всегда происходит с повышенной учетной записью.
Обратите внимание, что и mycorp.ads, и mycorp.com включены в доверенные узлы в параметрах интернета. На веб-сервере настройка по умолчанию установлена на обсуждение, затем NTLM (не уверен, является ли это проблемой)?
Есть ли какие-либо мысли о том, что может вызывать это, и/или предложения о том, как изменить учетную запись, используемую по умолчанию?
Ответ или решение
Ваша ситуация требует детального анализа для понимания причины автоматического входа с использованием неверного аккаунта на внутреннем сайте с внешним сертификатом. Для начала проведем теоретический анализ проблемы, потом рассмотрим возможные причины и решения на основе примеров, а в завершение предложим практические шаги для решения проблемы.
Теоретический анализ
Основная проблема заключается в том, как Windows и веб-браузер обрабатывают автоматической аутентификацией пользователей, особенно когда речь идет о доступе к ресурсам с различными сертификатами. В данном случае, аутентификация NTLM (NT LAN Manager) используется в системе Windows для учетных записей. Когда пользователь пытается зайти на сайт, Windows сначала пытается аутентифицировать его с уже имеющимися учетными данными, которые могут быть "спрятаны" в текущей сессии. Ваша система настроена на "negotiation" (переговоры), затем NTLM, что указывает, что сперва определяется доступный протокол (Kerberos или NTLM), и в отсутствие Kerberos используется NTLM.
Примеры и разбор возможных причин
Особенности учетных записей
-
Учетная запись с повышенными правами: Ваша система, как описание показывает, склонна использовать для автоматической аутентификации учетную запись с повышенными правами при доступе к URL с внешним сертификатом. Это может быть связано с тем, что эти учетные данные “запомнены” в текущей Windows-сессии и могут быть определены как более подходящие для доступа к ресурсу.
-
Автоматическая аутентификация: Windows старается минимизировать количество раз, когда пользователю требуется вводить свои учетные данные, используя для этого механизм SSPI (Security Support Provider Interface). Когда браузер осуществляет запрос аутентификации, система использует учетные данные, находящиеся в памяти безопасности Windows.
Особенности SSL/TLS и доверенности
-
Разные сертификаты: URL-адреса используют разные сертификаты — внутренний и внешний. Часто это влияет на способ, которым Windows обрабатывает аутентификацию. Внутренние сайты могут обрабатывать аутентификацию более прозрачно, чем внешние, в зависимости от политики безопасности системы.
-
Интернет-интергативность и политика: Поскольку вы упоминаете, что оба домена добавлены в доверенные сайты, следовательно, политика безопасности интернет-обозревателя должна позволять автоматическую аутентификацию. Возможно, различие заключается в том, каким образом обрабатываются доверительные сертификаты организма (например, различия в зональных конфигурациях для mycorp.ads и mycorp.com).
Применение: практически ма шаги
-
Проверка SSPI: Вам следует рассмотреть настройку SSPI, чтобы убедиться, что нет различий в политике безопасности для различных типов сертификатов. Перейдите по пути консольного редактора групповых политик (gpedit.msc) в раздел Конфигурации компьютера -> Политики безопасности и проверьте настройки аутентификации.
-
Ручной вход: Поскольку вход в инкогнито позволяет использовать е нужный аккаунт, возможно временно использовать этот подход, когда это необходимо, но это не оптимальное решение для производственной среды.
-
Изменение сразу используемого протокола: Рассмотрите возможность изменения порядка протоколов аутентификации на уровень выше на стороне сервера, установив Kerberos как основную метод аутентификации для урегулирования ситуации.
-
Изучение конфигураций Advanced Security: Используйте IIS Manager для изучения настроек безопасности «Расширенная аутентификация» на сервере, чтобы убедиться, что конфигурации позволяют правильный вход. Убедитесь, что в конфигурациях IIS не происходит «перекрытие» стратегий учетных записей.
-
Журналы и мониторинг: Проверьте журналы событий на ошибках или предупреждениях, связанных с аутентификацией. Порой может быть полезно включить отслеживание запросов для дальнейшего анализа поведения сервиса.
Заключение
Ваша проблема имеет вероятность быть вызванной конфигурационными особенностями Windows и IIS, а также политиками применения учетных даннных, связанными с обработкой сертификатов. Решение потребует тщательного анализа текущих настройка и возможно корректировок сетевых политик для обеспечения того, чтобы объекты, задействующие такие учетные данные, могли действовать эффективно и точно.