Авторизация и роли в IIS 8

IIS 8 позволяет управлять правилами доступа к собственному модулю авторизации для веб-сайтов непосредственно в консоли управления. Вдобавок прямо из этой консоли можно также управлять ролями, находящимися в хранилище данных сконфигурированного поставщика Roles API. Ранее уже было показано, как следует настраивать хранилище данных поставщика Roles API, используя для этого консоль управления IIS 8, где конфигурировались некоторые правила аутентификации для включения аутентификации с помощью форм для приложений ASP.NET и приложений, отличных от ASP.NET.

На рисунке ниже показано средство конфигурирования авторизации консоли управления IIS 8. В этом разделе мы углубимся в некоторые детали механизмов конфигурирования IIS 8.

Средство URL-авторизации IIS 8 работает совершенно независимо от ASP.NET, оно реализовано в отдельном встроенном HTTP-модуле, поставляемом с IIS 8. Как упоминалось ранее, он конфигурируется в отдельном разделе внутри файла web.config. Любое правило авторизации, которое настраивается через консоль управления IIS 8, добавляется в раздел внутри раздела файла web.config. Типичная конфигурация авторизации IIS 8 в файле web.config выглядит подобно приведенной ниже и концептуально работает точно так же, как правила авторизации ASP.NET:

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

Почему важно понимать разницу? Прежде всего, UrlAuthorizationModule.dll можно использовать из IIS 8 независимо от ASP.NET. Когда веб-сервер IIS 8 установлен на машине, a ASP.NET — нет, URL-авторизацию по-прежнему можно использовать через встроенный модуль.

Однако вторая причина намного важнее для разработчика ASP.NET. Встроенный модуль URL-авторизации, поставляемый в составе IIS 8, способен корректно идентифицировать зарегистрированных пользователей, аутентифицированных всеми возможными модулями аутентификации, включая базовую аутентификацию, Windows-аутентификацию и даже аутентификацию с помощью форм. Это связано с тем, что модуль разработан таким образом, что он понимает билет аутентификации с помощью форм (закодированный либо в cookie-наборе, либо в строке запроса). Но, к сожалению, он не был реализован с учетом ролей ASP.NET.

Какова причина этого? Роли извлекаются инфраструктурой ASP.NET из хранилища на определенной стадии внутри жизненного цикла приложения (например, из базы данных, сконфигурированной для поставщика ролей). Информация о ролях затем инкапсулируется в управляемых объектах, реализующих интерфейс IPrincipal, и потому хранится в чистых управляемых объектах .NET, которые не доступны встроенным модулям IIS 8. Поэтому такие встроенные модули IIS 8, как UrlAuthorizationModule, не могут использовать эту информацию.

Как упоминалось ранее, в случае имен пользователей можно полностью полагаться на управление авторизацией IIS 8. Причина в том, что встроенный модуль реализован так, что он распознает пользователей, аутентифицированных встроенными модулями, и пользователей, аутентифицированных управляемыми модулями, такими как FormsAuthenticationModule. Чтобы использовать модуль FormsAuthenticationModule в сочетании с встроенным UrlAuthorizationModule, модуль FormsAuthentication должен быть разрешен для встроенной очереди обработки.

И, наконец, это означает, что авторизация на основе ролей является одним из нескольких исключений, где конфигурация IIS и ASP.NET все еще должна учитываться раздельно.

Авторизация с помощью ролей ASP.NET в IIS 8

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

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

защитить ресурсы ASP.NET;

использовать средства безопасности ASP.NET для любого веб-приложения, даже написанного не на ASP.NET.

Обе цели достигаются одинаковым способом — нужно просто разрешить управляемому модулю UrlAuthorization из ASP.NET работать в конвейере вместе с другими модулями IIS 8 (и модулями ASP.NET).

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

Настройка аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах

Описание проблемы

Не работает аутентификация операционной системы (windows) через IIS при использовании тонкого клиента или веб-клиента.

С точки зрения пользователей, будет видно окно с запросом логина и пароля.

Проблема может заключаться в том, что методы операционной системы в силу различных причин возвращают описание текущего пользователя сеанса в таком представлении, которое не совпадает ни с одним пользователем в списке пользователей информационной базы 1С

Решение проблемы

На сервере 1С включить технологический журнал, используя следующую настройку:

Воспроизвести ситуацию с неудачной аутентификацией операционной системы. Авторизоваться под пользователем операционной системы, указанным в свойствах пользователя 1С.

Открыть технологический журнал рабочего процесса и найти событие EXCP со следующим описанием: «Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя»

Обратите внимание на предшествующее ему событие CONN и значение свойства DstUserName2 — именно в таком виде пользователь должен быть указан в свойствах пользователя информационной базы.

04:45.940011-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: SrcUserName1: svc-1c@DOMAIN701.COM
04:45.940012-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: DstUserName1: testuser2@DOMAIN701.COM(DOMAIN701.COM\testuser2)
04:45.971001-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: DstUserName2: DOMAIN701\testuser2(DOMAIN701\testuser2)
04:46.205021-0,EXCP,2,process=rphost,p:processName=trade,t:clientID=60,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=19,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

Заменить значение свойства «Пользователь» пользователя информационной базы согласно следующему формату «\\» + [Имя пользователя из свойства DstUserName2 без скобок].

Проверить работоспособность аутентификации средствами операционной системы, войдя в информационную базу, используя веб-клиент.

Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах

В некоторых случаях, несмотря на корректно указанного пользователя операционной системы в пользователе информационной базы, при попытке входа в опубликованную базу через браузер аутентификация операционной системы не проходит. Такая ситуация может возникать, если веб-сервер IIS и сервер 1с находятся на разных машинах. В таком случае в технологическом журнале рабочего процесса можно наблюдать следующую картину:

56:39.487001-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: SrcUserName1: winserver1c$@DOMAIN701.COM
56:39.487002-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName1: testuser2@DOMAIN701.COM(DOMAIN701.COM\testuser2)
56:39.596004-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName2: NT AUTHORITY\ANONYMOUS LOGON(NT AUTHORITY\ANONYMOUS LOGON )
56:39.659003-0,EXCP,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

При возникновении такой ситуации необходимо проверить следующие настройки:

1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.

2) Убедиться, что веб-сервер IIS настроен корректно.

В публикации информационной базы найти настройки аутентификации

В настройках аутентификации отключить анонимную аутентификацию и включить Windows-аутентификацию. В Windows-аутентификации упорядочить доступных провайдеров так, чтобы на первом месте был Negotiate.

Пул приложений публикации не нуждается в настройках, в нем можно оставить все по умолчанию.

После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.

3) Убедиться, что в контроллере домена в свойствах компьютера, на котором запущен веб-сервер, на вкладке делегирование установлено «Доверять компьютеру делегирование любых служб (только Kerberos)»

Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение «Доверять компьютеру делегирование любых служб (только Kerberos)» и нажать применить.

4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.

После выполнения всех действий необходимо перезагрузить клиентский компьютер (рабочие серверы перезагрузки не требуют) и убедиться, что аутентификация операционной системы успешно выполняется.

Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования).

Настройка 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.