Вопрос или проблема
Извините, если этот вопрос не соответствует теме; я пытаюсь разобраться с проблемой, выходящей за пределы моей компетенции.
Я недавно перенес веб-приложение для внутреннего использования на IIS. Я также включил аутентификацию Windows (IWA), которую ранее не использовал. Проблема, с которой я сталкиваюсь, заключается в том, что моя учетная запись пользователя (и, как видно, только моя учетная запись пользователя) иногда (не везде) неправильно идентифицируется процессом аутентификации.
Вот подробности настройки аутентификации IIS для моего сайта:
- У меня включена аутентификация Windows, а все остальное (включая анонимную аутентификацию) отключено.
- Аутентификация Windows использует аутентификацию в режиме ядра и провайдер
Negotiate.
Что касается неправильной идентификации, на которую я намекнул:
- У меня есть две учетные записи пользователей в одном и том же домене AD. Назовем их
acct1иacct2. Обычно я вхожу в систему какacct1, переключаясь наacct2, когда мне нужны расширенные привилегии. - Я вошел в виртуальную машину, на которой работает IIS, как
acct2, чтобы настроить сайт. - Когда я возвращаюсь на свой локальный ПК для доступа к сайту, сайт идентифицирует меня как
acct2, хотя я вошел в систему на своем ПК какacct1. - Все остальные, кто получал доступ к сайту, были правильно идентифицированы, даже те, у кого, как и у меня, есть более одной учетной записи.
- Если я получаю доступ к сайту с другого ПК, будучи в системе как
acct1, я правильно идентифицируюсь сайтом какacct1. - Парадоксально, но если я получаю доступ к сайту с самого серверного компьютера, где я вошел как
acct2, он идентифицирует меня какacct1. - Для справки,
acct2имеет административные привилегии на моем локальном ПК, но не на другом ПК, с которого я получал доступ к сайту. - Это продолжается уже более недели и сохраняется даже после перезагрузки моего локального ПК. Это также происходит в разных браузерах.
Если я переключу провайдер IWA с Negotiate на NTLM, то вот что я вижу:
- Я правильно идентифицируюсь как
acct1, когда получаю доступ к сайту с моего локального ПК. - Я получаю запрос на ввод учетных данных, когда получаю доступ к сайту с серверной машины. Однако он не принимает учетные данные ни для
acct1, ни дляacct2.
Меня не слишком беспокоит доступ к сайту с сервера, но мне нужно правильно идентифицироваться при доступе с моего ПК. Я бы предпочел использовать Negotiate вместо NTLM.
Я разработчик, а не системный администратор, но я пытаюсь найти какие-либо следы, которые могли бы помочь мне сузить круг того, что происходит, и, возможно, направить нашу команду инфраструктуры в правильном направлении. Похоже ли это на проблему с конфигурацией Active Directory или Kerberos?
Сайт представляет собой приложение Python Flask, работающее как приложение FastCGI в IIS через библиотеку Python wfastcgi. Сайт считывает значение переменной запроса REMOTE_USER, чтобы получить результат процесса аутентификации IWA.
- Это чаще тема Stack Overflow о том, как правильно использовать фреймворки приложений, такие как Flask. Администраторы серверов здесь могут быть не так хорошо знакомы с программированием.
- FastCGI через wfastcgi больше не является надежным подходом, так как никто не поддерживает этот пакет.
- HttpPlatformHandler предоставляет информацию о пользователе через специальный HTTP-заголовок (
X-IIS-WindowsAuthToken), и вам нужно декодировать это на стороне Python/Flask. Более подробная информация в этом блоге.
Классический ASP/ASP.NET 2.x/4.x/ASP.NET Core обрабатываются Microsoft по-другому, поэтому сравнение вашего с любым из них не имеет смысла.
Благодаря подсказке от @massimo, которую расширил @grawity, я нашел ответ. Оказалось, что это было простое дело, связанное с сохранением учетных данных в Менеджере учетных данных Windows.
Я предполагал, что процесс аутентификации Kerberos всегда будет использовать учетные данные из моего активного входа в Windows, где я вхожу как acct1. Однако учетные данные, связанные с компьютером, где размещен мой сайт, были сохранены в Менеджере учетных данных (в разделе учетных данных Windows, а не веб-учетных данных, к вашему сведению), и, похоже, система использовала их после того, как каким-то образом определила, что сайт размещен на этом компьютере. (Мое понимание здесь все еще не четкое.) Сохраненные учетные данные использовали acct2.
В любом случае, после удаления сохраненных учетных данных и перезагрузки моего ПК, сайт идентифицировал меня как acct1, как я и ожидал.
.
Ответ или решение
Причина, по которой IIS неправильно идентифицировал вашу учетную запись при использовании Windows Authentication (IWA) с провайдером Negotiate, связана с особенностями Kerberos-аутентификации в связке с Credential Manager в операционной системе Windows. Позвольте объяснить это детальнее, используя подход TEA (Теория, Пример, Применение).
Теория
Kerberos — это протокол аутентификации, который часто используется в корпоративных сетях для обеспечения безопасности доступа к ресурсам. Он обеспечивает безопасную передачу учетных данных и отвечает за идентификацию пользователей в сети. Основное преимущество Kerberos заключается в его способности аутентифицировать пользователей без необходимости повторного ввода учетных данных для каждого ресурса, к которому они пытаются получить доступ.
Когда вы используете аутентификацию Windows в IIS с включенным режимом Negotiate, IIS пытается использовать Kerberos по умолчанию для аутентификации пользователей. Однако в случае, если Kerberos не может быть использован из-за каких-либо ограничений или ошибок, он переключается на NTLM. Это может привести к ситуациям, когда аутентификация проходит не так, как ожидалось. Одним из таких случаев может быть наличие сохраненных учетных данных в Credential Manager вашего компьютера.
Credential Manager в Windows — это инструмент, который хранит ваши учетные данные (логины и пароли) для доступа к удаленным ресурсам. Это удобный механизм для упрощения процесса входа на сайты и сервисы. Тем не менее, если в Credential Manager сохранены учетные данные для конкретного сервера или пользователя, они могут быть использованы вместо текущих учетных данных пользователя.
Пример
В вашем случае, как вы выявили, в Credential Manager на вашем локальном компьютере были сохранены учетные данные для учетной записи acct2. Эти данные использовались IIS каждый раз, когда вы пытались зайти на ваш сайт с вашего ПК, что и вызывало неправильную идентификацию. Несоответствие в том, почему для других пользователей такая ошибка не встречалась, может объясняться тем, что у них не было сохраненных учетных данных в Credential Manager для данной машины.
Применение
Лучшим решением в данной ситуации, как вы уже выяснили, является удаление сохраненных учетных данных в Credential Manager. После удаления этих данных и перезагрузки компьютера, при следующей попытке доступа к сайту будут использоваться текущие локальные учетные данные пользователя acct1, и IIS сможет правильно вас идентифицировать.
Однако стоит учитывать и другие контекстные особенности. Например:
-
Проверка конфигурации IIS: Убедитесь, что все параметры аутентификации настроены корректно, особенно в той части, где происходит взаимодействие с Active Directory. Это поможет убедиться, что аутентификация работает должным образом во всех сценариях.
-
Логирование и мониторинг: Включите подробное логирование в IIS, чтобы отслеживать процесс аутентификации и быстро выявлять причину возможных сбоев.
-
Ограничения на использовании NTLM: Если вы стремитесь использовать Negotiate, учтите, что NTLM имеет свои ограничения и меньшее количество опций безопасности по сравнению с Kerberos. Повторная настройка может потребоваться в случае, если отдельные элементы вашей сети не поддерживают Kerberos.
-
Обновление инфраструктуры: Как вы отметили, FastCGI через wfastcgi больше не поддерживается. Рассмотрите возможность обновления инфраструктуры, чтобы использовать подерживаемые и более современные решения.
Таким образом, понимание того, как взаимодействуют различные компоненты вашей сети, в сочетании с правильной настройкой IIS и системой управления учетными данными Windows, позволяет избежать подобных ситуаций в будущем. Рассмотрите также возможность налогать политик использования Credential Manager в своей сети, чтобы минимизировать риск некорректной аутентификации.