Я ни в коем случае не эксперт по IIS или Active Directory, поэтому я хочу представить здесь сценарий и посмотреть, возможно ли то, что мы хотим достичь.
У нас есть приложение, размещенное на Windows Server 2008 R2, с рядом веб-служб, представленных в виде API через IIS. Эти службы будут вызываться несколькими внешними системами интеграции. Если мы настроим службы IIS для использования обычной проверки подлинности, будет ли IIS проверять передаваемые им учетные данные в Active Directory по умолчанию, это особый параметр конфигурации или это невозможно? Мы хотели бы, чтобы эти учетные данные были проверены в AD, чтобы мы получили токен / принципала взамен, который можно было бы отправить в базовое приложение на этом сервере.
Заранее спасибо. Любая помощь приветствуется.
Обычная проверка подлинности отлично подойдет для проверки подлинности в AD - она проверяет подлинность локальной базы данных учетных записей сервера IIS; для члена домена, который включает домены Active Directory в лесу, к которому он присоединен.
Вы не получите взамен ни одного билета kerberos - базовая аутентификация просто включает пароль в заголовок запросов, отправленных на сервер, и сервер делает с ним то, что он будет - возвращая запрошенный ресурс или 401 ошибка .. но если вы ищете идентификацию пользователя в веб-приложении в IIS, тогда эта информация (какой пользователь / домен они аутентифицированы как) должна быть доступна коду.
Браузеры будут хранить введенный пароль в памяти в течение всего сеанса, поэтому вы будете защищены от последующих запросов к этому серверу, но не от доступа к другим системам или службам.
Там есть информация о настройке базовой аутентификации, включая настройку домена по умолчанию и приглашения, которое получают пользователи, Вот.
Если в IIS есть учетные данные пользователя, их можно использовать для создания основного токена для этого пользователя. IIS может использовать этот токен и выдавать себя за этого пользователя для доступа к ресурсам и приложениям на других серверах.
Идентификатор компьютера IIS и пула приложений (учетная запись службы) необходимо настроить для соответствующего уровня олицетворения или делегирования, чтобы действовать от имени пользователя с его токеном, но этот сценарий на самом деле довольно распространен в IIS / ASP. Чистый мир.
Если бы вы должны были выполнить ограниченное делегирование - упомянутый Тристаном - на самом деле можно создать токен полного уровня делегирования для пользователей для доступа к определенным службам на определенных машинах (это ограниченная часть), и вам фактически не нужен их пароль. Это более безопасно, если у вас есть внешний механизм аутентификации (например, смарт-карта), и в веб-приложение передается только их личность. Это избавляет от необходимости передавать пароли за пределы безопасности.
Итак, ответ принят, но в целом я скажу:
Не используйте Basic.
Если есть вопрос, для которого Basic-with-domain-credentials кажется правильным ответом, почти всегда это не так.
Используйте встроенную аутентификацию.
Базовый позволяет злонамеренному веб-разработчику узнать учетные данные пользователя в AD, и на этом игра окончена.
Интегрированный позволяет пользователю подтвердить, что он является тем, кем он является, и позволяет использовать ограниченное делегирование для ограничения того, что веб-разработчик может делать с токеном. Он не подвергает напрямую имя пользователя и пароль перехвату (если SSL настроен неправильно (то есть не-), что происходит постоянно), и не позволяет кому-либо с доступом на запись к общему ресурсу веб-сервера писать простые веб-приложения, которые перехватывают учетные данные.
Если вы хотите использовать AD для аутентификации веб-пользователей, вам необходимо использовать встроенную аутентификацию.
Базовая аутентификация HTTP небезопасна, не защищена и тривиально нарушается для всех, кто имеет доступ к сетевому трафику.
Для Windows было бы крайне небезопасно разрешать людям использовать учетные данные AD для базовой аутентификации - это автоматически сделало бы эти учетные данные ненадежными.