Вход в личный кабинет Аутентификация в web-приложениях на примере internet explorer – портал технической поддержки
В данной статье рассмотрим способы аутентификации пользователей на различных web-ресурсах предприятия.
Скриншоты в статье будут c IE11 и IIS 8 (русскоязычные) и IE8/IIS7(англоязычные)
Вход по логину и паролю
Самый простой и очевидный способ. Прежде, чем дать доступ, сервер просит пользователя подтвердить себя:
Вводите логин и пароль пользователя, имеющего права доступа к приложению и выполняется вход в приложение.
Каждый раз вводить пароль (логин можно запомнить, поставив соответствующую галочку) не очень удобно. Следующий способ позволяет не вводить и пароль.
Вход без ввода логина и пароля
Если пароль вводить лень, значит нужно сделать так, чтобы он вводился сам. Вот как это делается:
В настройках IE открыть Свойства обозревателя -> Безопасность (Internet Options -> Secutiry). Выбираете зону, к которой принадлежит используемый сайт. Обычно это зона Интернета, но можно добавить сайт и в зону местной интрасети (Local intranet) или Надежных сайтов (Ttusted sites).
Все в той же вкладке Безопасность выбираем уровень безопасности для указанной зоны: Другой… (Custom Level…). В окне параметров безопасности в разделе Проверка подлинности пользователя (User Authentication) ставимАвтоматический вход в сеть с текущим именем пользователя и паролем (Automatic logon with current user name and password):
Сохраняем изменения. Теперь при входе на сайт запрос учетных данных появляться не будет.
Вход с использованием сертификата пользователя
Раз уж Indeed CM позволяет управлять устройствами аутентификации (смарт-картами, usb-ключами) и записывать на них сертификаты, то почему бы не аутентифицироваться по смарт-карте?
Для этого необходим настроенный SSL в IIS, где расположен сайт. Для аутентификации по смарт-карте необходимо в IIS выставить следующие настройки для приложений:
Сертификаты клиента: Принимать(Accept) или Требовать(Require).
Если используется Принимать, значит аутентификация может осуществляться как по вводу логина/пароля, так и по сертификату, если он предоставлен пользователем.
Если используется Требовать, значит вход на сайт возможен только по сертификату пользователя и никак иначе:
Теперь необходимо настроить браузер для аутнетификации по карте. Добавьте сайт в зону местной интрасети, а в параметрах безопасности зоны укажите Автоматический вход в сеть только в зоне интрасети (Automatic logon only in Intranet zone)
Теперь, при входе на сайт, появится предложение использовать данные смарт-карты:
Настройка kerberos авторизации на сайте iis | windows для системных администраторов
Пошаговая инструкция по настройке на веб-сайте IIS на Windows Server 2022 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 contosoiis_serviceSetspn /s HTTP/webportal.contoso.loc contosoiis_service
Таким образом, мы разрешим этой учетной записи расшифровывать тикеты Kerberos при обращении пользователей к данным адресам и аутентифицировать сессии.
Проверить настройки SPN у учетной записи можно так:
setspn /l iis_service
Совет. Kerberos не будет работать корректно при наличии дублирующих SPN у разных записей домена. С помощью следующей команды, убедитесь, что дубликатов SPN в домене нет:
setspn –x
Следующий этап – настройка в IIS Application Pool для запуска из-под созданной сервисной учетной записи.
Выберите Application Pool сайта (в нашем примере это DefaultAppPool).
Откройте раздел настроек Advanced Settings и перейдите к параметру Identity.
Измените его с ApplicationPoolIdentity на contosoiis_service.
Затем в консоли IIS Manager перейдите на свой сайт и выберите секцию Configuration Editor.
В выпадающем меню перейдите в раздел system.webServer > security > authentication > windowsAuthentication
Измените useAppPoolCredentials на True.
Тем самым мы разрешим IIS использовать доменную учетку для расшифровки билетов Kerberos от клиентов.
Перезапустим IIS командой:
iisreset
Аналогичную настройку нужно выполнить на всех серверах веб-фермы.
Протестируем работу Kerberos авторизации, открыв в браузере клиента (браузер нужно предварительно настроить для использования Kerberos) адрес _http://webportal.contoso.loc
Убедится, что для авторизации на сайте используется Kerberos можно с помощью инспектирования HTTP трафика утилитой Fiddler.
Запускаем Fiddler, в браузере открываем целевой сайт. В левом окне находим строку обращения к сайте. Справа переходим на вкладку Inspectors. Строка Authorization Header (Negotiate) appears to contain a Kerberos ticket, говорит о том, что для авторизации на IIS сайте использовался протокол Kerberos.
Выводы:
- При аутентификации Negotiate:
сначала используется протокол Kerberos
используется протокол NTLM, если Kerberos возвращает ошибку
проваливается аутентификация при недоступности контроллера домена. - При аутентификации Kerberos:
аутентификационные данные между веб сервером и клиентом не передаются
требуется подключение клиента и веб сервера к контроллеру домена
требуется наличие корректного SPN у учетной записи, под которой работает веб сервер
SPN не требует включения порта для веб сервера
SPN может требовать включение порта для других сервисов. - При аутентификации NTLM:
аутентификационные данные передаются от клиента к веб серверу
не требуется подключение клиента к контроллеру домена. - Если клиент не в домене, то используется NTLM аутентификация.
- При использовании NTLM протокола учетные данные в зашифрованном виде передаются напрямую между сервером и клиентом. Поскольку NTLM хранит хешированные пароли на сервере, то завладев хешем пароля, можно аутентифицироваться на других серверах не зная самого пароля:
- Если используется локальная учетная запись, то хеш пароля храниться на локальной машине.
- Если используется доменная учетная запись, то хеш пароля храниться на контроллере домена. Однако, если зайти на клиент под доменной учетной записью, ее аутентифицированные данные закешируются. Этот кеш используется для механизма Single Sign-On (для доступа к другим доменным ресурсам без запроса пароля) и для входа на рабочую станцию при недоступном контроллере домена. Если у атакующего получится расшифровать кеш учетной записи, то он получит ее хеш пароля. Существует групповая политика, чтобы указать, сколько последних зашедших пользователей кешировать. Сам кеш не имеет срока истечения и остается рабочим до того момента, пока рабочая станция не соединиться с контроллером домена.
Источник 1Источник 2Источник 3Источник 4Источник 5Источник 6Источник 7Источник 8Источник 9Источник 10Источник 11Источник 12Источник 13
Поддержать блог