Iis настройка аутентификации windows

Стандартные возможности аутентификации Internet Information Server (IIS), анонимный доступ, методы аутентификации, учетная запись IUSR_

Большая часть серверов IIS работает без требований к пользователю аутентифицироваться — то есть в режиме анонимного доступа. На самом деле такие анонимные пользователи работают от имени специальной учетной записи IUSR _имя_компьютера. Конечно же, настоятельно не рекомендуется использовать эту учетную запись для каких-то других целей, добавлять ее в другие группы (кроме группы Guests ), в которой эта учетная запись находится по умолчанию и т.п.

Однако в некоторых ситуациях анонимным доступом не обойтись. Обычно аутентификация требуется в двух случаях:

1) когда на Web -сервере находятся ресурсы, доступ к которым нужен не всем пользователям (проще говоря, чтобы задействовать систему разрешений);

2) для целей дополнительного протоколирования — чтобы можно было записывать информацию о том, какие именно пользователи обращались к ресурсам Web -сайта (во многих ситуациях, например в локальной сети, в этом случае можно обойтись без аутентификации — поскольку текущее имя пользователя автоматически записывается в логи Web -сервера).

Аутентификация в IIS , к сожалению, полностью основывается на системе безопасности Windows . Фактически мы можем предоставить доступ только тем пользователям, для которых у нас создана локальная учетная запись (или доменная учетная запись, если компьютер с IIS входит в домен). Конечно, по этой причине доступ на IIS со стандартными средствами можно предоставлять только пользователям локальной сети (или, например, очень ограниченному числу внешних партнеров). Рассчитывать на организацию системы аутентификации для пользователей из Интернета стандартными средствами не приходится (поскольку для каждого пользователя учетную запись Windows не создашь). Обычно для таких целей используются или самостоятельно созданные Web -приложения, или специальные надстройки на IIS , которые обеспечивают отдельную, независимую от Windows систему аутентификации. Ниже будет рассмотрены стандартные возможности аутентификации, а затем — дополнительные средства других производителей.

Настройку аутентификации стандартными методами предписывается производить из консоли Internet Information Services Manager -> свойства Web -сайта -> вкладка Directory Security -> кнопка Edit в группе Authentification and Access Control . При нажатии на эту кнопку открывается окно Authentification Method , в котором и производятся настройки параметров аутентификации. В этом окне вы можете:

• разрешить или запретить анонимный доступ на Web -сайт и выбрать учетную запись, которая будет использована для этой цели;
• выбрать методы аутентификации, которые могут быть использованы для доступа на Web -сервер.

О методах аутентификации необходимо рассказать подробнее:

• IntegratedWindowsAuthentification — единственный метод (кроме анонимного доступа), доступный по умолчанию. При использовании этого метода используются те же хэши NTLM (или Kerberos — negotiate для Windows 2000/ XP /2003), что и при обычной аутентификации в Windows (например, при обращении к файлам на файл-сервере). Конечно, ни один броузер, кроме Internet Explorer , такой аутентификации не поддерживает. Необходимо отметить, что, если прав учетной записи IUSR недостаточно (или анонимный доступ вообще отключен) следующее, что делает Internet Explorer — отсылает NTLM -хэш (его версия зависит от версии операционной системы) текущей учетной записи на сервер IIS . Если аутентификация не прошла (или прошла, но у учетной записи не оказалось прав на Web -ресурс), то открывается всплывающее окно аутентификации, в котором пользователь имеет возможность ввести данные другой учетной записи;
• DigestAuthentification — сравнительно новая технология (появилась только в Windows 2000/ IIS 5.0), основанная на открытых Интернет-стандартах (алгоритм хэширования MD 5 и RFC 2617). При использовании этого метода аутентификации сервер посылает специальную случайную последовательность символов — nonce — клиенту (для каждого сеанса она будет сгенерирована заново). Клиент принимает эту последовательность, на основе ее и своего пароля генерирует хэш по алгоритму MD 5 и пересылает ее серверу. Сервер, который производит такую же операцию и сравнивает полученные значения. Главной проблемой применения этого метода аутентификации является то, что IIS должен получить доступ к открытым паролям пользователей, которых по умолчанию нет и на контроллерах домена. Таким образом, чтобы этот метод аутентификации заработал, необходимо для учетных записей пользователей установить параметр » Store password using reversible encryption «, что обычно в защищенных сетях недопустимо.
• BasicAuthentification — самый простой тип аутентификации, который поддерживается практически всеми броузерами. При этом имя пользователя и пароль посылаются почти открытым текстом (на самом деле они кодируются, во избежание попадания служебных символов, по алгоритму Base 64). Те менее, конечно, расшифровать эти данные не составит никакого труда — например, при помощи утилиты Base 64 Decoder (она умеет декодировать и некоторые другие форматы) из каталога прочее на компакт-диске. Поскольку передаются таким образом на самом деле имя и пароль учетной записи Windows , то последствия могут оказаться очень серьезными (если в сети запущен сниффер). Безопасно пользоваться этим методом аутентификации можно только при использовании SSL .
• .NETPassportauthentification — возможность использовать для аутентификации централизованную систему . NET Passport от Microsoft . Не совсем понятно, зачем эта возможность помещена на графический интерфейс IIS Manager — использовать эту возможность могут только участники программы . NET Passport , фактически — очень ограниченный круг крупных Web -коммерсантов. Существует и множество других ограничений при использовании .NET Passport .

Есть и другие методы аутентификации, например, при помощи клиентских сертификатов (этот метод сертификации настраивается при помощи Edit в разделе Secure Certifications и о нем будет рассказано ниже), при помощи серверов RADIUS и смарт-карт, но обычно последние два способа используются в составе комплексных решений для очень защищенных Web -сайтов.

Еще несколько слов об служебных учетных записях и группах, имеющих отношение к IIS :

• IUSR _имя_компьютера — об этой учетной записи уже говорилось, она предназначена для обеспечения анонимного доступа на сервер IIS и никаких дополнительных прав ей предоставлять не рекомендуется;
• IWAM_имя_компьютера — еще одна гостевая учетная запись, которой не нужно давать лишние права. От имени этой учетной записи запускаются внешние процессы, порождаемые процессом INETINFO (то есть процессом Web -сервера). Иногда для работы Web 0-приложения этой учетной записи необходимо предоставить дополнительные права, например, на запись в каталог.
• IIS _WPG — эта группа предназначена для предоставления прав в операционной системе приложениям CGI и ASP . NET , работающим на Web -сервере. Если у вас таких приложений нет, выдавать какие-либо разрешения этой группе не нужно.
• ASPNET — как понятно из названия, эта учетная запись используется приложениями ASP . NET , работающими на сервере IIS . Если у вас не используется ASP . NET (не установлена как компонент IIS ), то этой учетной записи не будет. Этой учетной записи нужно предоставлять права, например, если приложению ASP . NET необходимо подключаться к SQL Server .

При помощи группы переключателей IP address and domain name restrictions можно также ограничить доступ к сайту по IP -адресам, целым IP -сетям или именам доменов DNS . Обычно такие возможности используются только в Интранет Web -серверах.

Настройка аутентификации в IIS 8

IIS 8 поддерживает интегрированный режим ASP.NET, который помимо прочего объединяет конвейер обработки ASP.NET HTTP с конвейером обработки IIS HTTP. Это предоставляет в распоряжение богатейший набор новых возможностей, которые можно использовать в сочетании с имеющимися знаниями ASP.NET. Например, одна из них — это возможность применения аутентификации с помощью форм ASP.NET для других веб-приложений, сконфигурированных в IIS 8, которые не обязательно должны быть построены на ASP.NET.

Более того, IIS 8 использует файл web.config для хранения многих частей конфигурации веб-приложений внутри веб-сервера. Это означает возможность настройки многих параметров приложения с использованием либо консоли управления IIS 8, либо за счет непосредственной модификации файла web.config. Благодаря тесной интеграции средств конфигурирования ASP.NET и IIS 8, любые изменения, внесенные непосредственно в файл web.config, немедленно отражаются в консоли управления, и наоборот.

Давайте сначала рассмотрим возможности конфигурирования аутентификации с помощью форм из среды консоли управления IIS 8. Конфигурировать аутентификацию с помощью форм можно с использованием средства настройки аутентификации консоли управления IIS 8, как показано на рисунке ниже:

После разрешения аутентификации с помощью форм подобным образом также понадобится сконфигурировать необходимые правила авторизации. Наиболее важно добавить правило deny для анонимных пользователей с помощью средства конфигурирования авторизации в консоли управления IIS 8:

Обе конфигурационные настройки затрагивают файл web.config и веб-сервер берет эту информацию из web.config для определения собственного поведения, что видно в следующем фрагменте кода:

Вы заметите, что аутентификация с помощью форм, сконфигурированная IIS, как и следовало ожидать, находится в разделе . Но по умолчанию (и если вы ранее не добавили этого вручную), никаких правил авторизации там не будет. Как упоминалось ранее, не все опции конфигурации по умолчанию помещаются непосредственно в файл web.config. Авторизация URL — одна из таких опций конфигурации.

В любом случае унифицированная консоль управления очень хорошо продумана, так что настраивать безопасность IIS и ASP.NET посредством других инструментов нет необходимости. Многие опции по умолчанию сохраняются непосредственно в файле web.config. Как известно можно даже сконфигурировать IIS так, чтобы почти все опции помещались непосредственно в web.config. Однако, как упоминалось ранее, интеграция ASP.NET предоставляет множество возможностей при запуске IIS 8 в интегрированном с ASP NET режиме.

При запуске IIS 8 в интегрированном режиме (выбираемом по умолчанию) IIS использует канал обработки HTTP для обработки как основанных на ASP.NET HTTP-модулей, так и встроенных HTTP-модулей IIS 8.

Поскольку аутентификация с помощью форм реализована в виде HTTP-модуля ASP.NET, ее можно использовать для любого веб-приложения и виртуального каталога, сконфигурированного в IIS, который функционирует в интегрированном режиме. Это значит, что аутентификацию с помощью форм можно применять вместе с приложениями других типов, такими как статические HTML-сайты, классические приложения ASP или даже приложения PHP. Все, что потребуется сделать — это настроить веб-приложение как виртуальный каталог и затем сконфигурировать аутентификацию с помощью форм через консоль управления IIS 8. Это автоматически добавит к приложению конфигурацию web.config.

Поскольку нужно позаботиться об одной дополнительной детали, давайте в этом разделе кратко рассмотрим настройку аутентификации с помощью форм для приложения, отличного от ASP.NET. Предположим, что имеется следующая страница PHP, работающая на веб-сервере:

Теперь просто откройте доступ к папке, где расположен PHP-файл (например, test.php), как к виртуальному каталогу или веб-приложению внутри IIS. После этого можно сконфигурировать аутентификацию с помощью форм и настройки авторизации, как было описано ранее.

Поскольку IIS 8 органично поддерживает аутентификацию с помощью форм, полагаясь на HTTP-модуль аутентификации с помощью форм, поставляемый в ASP.NET, она работает точно также, как работала бы с приложением ASP.NET. Все что нужно — это удостовериться в наличии необходимой страницы входа, которая сама по себе является страницей ASP.NET. Также должны быть доступны части, необходимые для страницы ASP.NET, внутри веб-приложения (или в другом виртуальном каталоге, если применяются cookie-наборы аутентификации между приложениями).

На рисунке ниже показана страница PHP вместе со страницей входа ASP.NET в виртуальном каталоге. Аутентификация с помощью форм просто конфигурируется через управляющую консоль IIS 8, как было описано ранее:

Однако просто поместить содержимое PHP вместе с основанными на ASP.NET страницами входа и сконфигурировать аутентификацию с помощью форм еще недостаточно. Когда вы попытаетесь выполнить переход на страницу PHP, аутентификация с помощью форм пока работать не будет. В зависимости от аутентификации и правил авторизации, вы либо получите ответ «unauthorized» («неавторизовано»), либо сможете переходить к странице PHP без приглашения на вход.

Причина в том, что по умолчанию управляемые HTTP-модули, в том числе и модуль аутентификации с помощью форм, настроены так, что выполняются только по запросу кода, основанного на ASP.NET. Поэтому чтобы заставить работать аутентификацию с помощью форм, потребуется изменить это поведение, вызвав средство конфигурации HTTP Modules в консоли управления IIS 8 когда ваше веб-приложение выбрано. Затем нужно отобразить детальную информацию для модуля FormsAuthentication, сконфигурированного в списке модулей, как показано на рисунке ниже:

Открыв средство конфигурации HTTP Modules, найдите FormsAuthentication и дважды щелкните на нем или выберите ссылку Edit (Правка) в панели задач справа. В открывшемся диалоговом окне снимите отметку с флажка Invoke Only for Requests to ASP.NET Applications or Managed Handlers (Вызывать только для запросов к приложениям ASP.NET или управляемым обработчикам), как показано на рисунке ниже:

После завершения этой настройки при обращении к странице PHP в каталоге веб-приложения запрос будет аутентифицирован посредством аутентификации с помощью форм ASP.NET. Конфигурационный файл web.config для веб-приложения будет выглядеть следующим образом:

Конфигурация FormsAuthenticationModule важна. Флажок в неотмеченном состоянии задает preCondition=»», которое по умолчанию установлено в managedHandler.

Настройка Kerberos авторизации на сайте IIS

Пошаговая инструкция по настройке на веб-сайте IIS на Windows Server 2012 R2 прозрачной авторизации доменных пользователей в режиме SSO (Single Sign-On) по протоколу Kerberos.

На веб сервере запустите консоль IIS Manager, выберите нужный сайт и откройте раздел Authentication. Как вы видите, по умолчанию разрешена только анонимная аутентификация (Anonymous Authentication). Отключаем ее и включаем Windows Authentication (IIS всегда сначала пытается выполнить анонимную аутентификацию).

Открываем список провайдеров, доступных для Windows аутентификации (Providers). По умолчанию доступны два провайдера: Negotiate и NTLM. Negotiate – это контейнер, который в качестве первого метода проверки подлинности использует Kerberos, если эта аутентификация не удается, используется NTLM. Необходимо, чтобы в списке провайдеров метод Negotiate стоял первым.

Следующий этап – регистрация Service Principal Name (SPN) записей для имени сайта, к которому будут обращаться пользователи. В том случае, если сайт IIS должен быть доступен только по имени сервера, на котором он расположен (http://server-name или http://server-name.contoso.com), создавать дополнительные SPN записи не нужно (SPN записи уже имеются в учетной записи сервера в AD). При использовании адреса сайта, отличного от имени хоста, или при построении веб-фермы с балансировкой, придется привязывать дополнительные записи SPN к учётной записи сервера или пользователя.

Предположим, у нас имеется ферма IIS серверов. В этом случае оптимально создать отдельную учетную запись в AD и привязать SPN записи к ней. Из-под этой же учетной записи будут запускать целевой Application Pool нашего сайта.

Создадим доменную учетную запись iis_service. Убедимся, что SPN записи для этого объекта не назначены (атрибут servicePrincipalName пустой).

Предположим, что сайт должен отвечать по адресам _http://webportal and _http://webportal.contoso.loc. Мы должны прописать эти адреса в SPN атрибут служебной учетной записи

Setspn /s HTTP/webportal contoso\iis_service
Setspn /s HTTP/webportal.contoso.loc contoso\iis_service

Таким образом, мы разрешим этой учетной записи расшифровывать тикеты Kerberos при обращении пользователей к данным адресам и аутентифицировать сессии.

Проверить настройки SPN у учетной записи можно так:

setspn /l iis_service

Следующий этап – настройка в IIS Application Pool для запуска из-под созданной сервисной учетной записи.

Выберите Application Pool сайта (в нашем примере это DefaultAppPool).

Откройте раздел настроек Advanced Settings и перейдите к параметру Identity.

Измените его с ApplicationPoolIdentity на contoso\iis_service.

Затем в консоли IIS Manager перейдите на свой сайт и выберите секцию Configuration Editor.

В выпадающем меню перейдите в раздел system.webServer > security > authentication > windowsAuthentication

Измените useAppPoolCredentials на True.

Тем самым мы разрешим IIS использовать доменную учетку для расшифровки билетов Kerberos от клиентов.

Перезапустим IIS командой:

Аналогичную настройку нужно выполнить на всех серверах веб-фермы.

Протестируем работу Kerberos авторизации, открыв в браузере клиента (браузер нужно предварительно настроить для использования Kerberos) адрес _http://webportal.contoso.loc

Убедится, что для авторизации на сайте используется Kerberos можно с помощью инспектирования HTTP трафика утилитой Fiddler (ранее мы уже упоминали эту утилиту).

Запускаем Fiddler, в браузере открываем целевой сайт. В левом окне находим строку обращения к сайте. Справа переходим на вкладку Inspectors. Строка Authorization Header (Negotiate) appears to contain a Kerberos ticket, говорит о том, что для авторизации на IIS сайте использовался протокол Kerberos.