Windows authentication iis как включить
Перейти к содержимому

Windows authentication iis как включить

  • автор:

Настройка аутентификации 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

date

08.06.2022

user

itpro

directory

Windows Server 2012 R2

comments

комментариев 26

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

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

IIS - Windows Authentication

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

Провайдеры включаем Windows Authentication

Следующий этап – регистрация 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 пустой).

Пустой атрибут 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

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

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

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

setspn /l iis_service

setspn /l iis_service

Совет. Kerberos не будет работать корректно при наличии дублирующих SPN у разных записей домена. С помощью следующей команды, убедитесь, что дубликатов SPN в домене нет: setspn –x

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

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

DefaultAppPool

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

Расширенные настройки пула IIS

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

identity

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

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

useAppPoolCredentials

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

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

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

iisreset

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

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

Примечание. В моем примере, на IE11 сразу авторизоваться не получилось. Пришлось добавить адрес в доверенные и в настройках Trusted Zones Sites выставить значение параметра User Authentication -> Logon на Automatic logon with current user name and password

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

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

Authorization Header (Negotiate) appears to contain a Kerberos ticket

Предыдущая статьяПредыдущая статья Следующая статья Следующая статья

Аутентификация Windows

Аутентификации Windows (NTLM) и LDAP могут работать независимо друг от друга. Аутентификация Windows требует ввода учетных данных пользователя в окне авторизации браузера. А аутентификация LDAP использует проверку пароля пользователя на сервере Active Directory. Аутентификации Windows (NTLM) и LDAP работают вместе, когда пользователь нажимает ссылку “Войти под доменным пользователем”, и его аккаунт синхронизирован с LDAP.

На заметку. Аутентификация Windows доступна только для on-site приложений в связи с особенностями cloud-архитектуры.

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

  1. Выполняется проверка авторизации пользователя в домене.
  2. Имя и пароль текущего доменного пользователя считываются из cookie-файла, если эти данные записаны в cookie. В противном случае отображается браузерное окно ввода учетных данных. Дальнейшие шаги зависят от того, синхронизирован ли пользователь с каталогом LDAP.

На заметку. Проверка подлинности выполняется как среди пользователей основного приложения, так и среди пользователей портала самообслуживания. Порядок проверки настраивается в файле Web.config приложения-загрузчика. Подробнее: Настроить файл Web.config приложения-загрузчика.

Для использования функциональности аутентификации Windows по протоколу NTLM необходимо зарегистрировать пользователей в системе вручную или импортировать из LDAP и предоставить им лицензии. Также необходимо, чтобы у пользователей в настройках браузера была разрешена запись локальных данных в cookie-файлы.

Настройка выполняется на сервере, где развернуто приложение, и включает в себя:

  • Настройку сервера IIS, которая активирует аутентификацию по протоколу NTLM. Подробнее: Настроить аутентификацию Windows в IIS.
  • Настройку файла Web.config приложения-загрузчика, которая определяет провайдеров аутентификации и порядок проверки наличия пользователей среди зарегистрированных в Creatio. Подробнее: Настроить файл Web.config приложения-загрузчика.

Настроить аутентификацию Windows в IIS

Для приложения-загрузчика и веб-приложения включите анонимную аутентификацию и аутентификацию форм (Рис. 1).

Рис. 1 — Настройки для приложения-загрузчика в настройках IIS

chapter_ldap_synchronization_ntlm_auth.png

На заметку. Обратите внимание, что необходимо выключить настройку “Windows Authentication”, которая в IIS включена по умолчанию.

Для директории Login внутри приложения-загрузчика отключите аутентификацию форм и включите анонимную аутентификацию и аутентификацию Windows (Рис. 2).

Рис. 2 — Настройки для директории Login

chapter_ldap_synchronization_ntlm_login_auth.png

Обратите внимание, что анонимная аутентификация приложения-загрузчика и рабочих приложений должна выполняться под пользователем Application Pool Identity. Для этого перейдите в окно редактирования данных входа настроек Authentication по кнопке Edit в боковом меню Actions менеджера IIS, и выберите пользователя “Application Pool Identity” (Рис. 3).

Рис. 3 — Указание пользователя для анонимной аутентификации в настройках IIS

chapter_ldap_synchronization_ntlm_auth_anonymous.png

На заметку. Подробнее о настройке аутентификации Windows читайте в справочной документации Microsoft .

Настроить файл Web.config приложения-загрузчика

InternalUserPassword — провайдер, указанный в файле Web.config по умолчанию. Если вы хотите предоставить возможность аутентификации по NTLM-протоколу только пользователям, которые не синхронизированы с LDAP, не указывайте для параметра providerNames дополнительные значения.

Ldap — добавьте к значениям параметра providerNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям приложения, которые синхронизированы с LDAP.

SSPLdapProvider — добавьте к значениям параметра providerNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям портала самообслуживания, которые синхронизированы с LDAP.

NtlmUser — добавьте к значениям параметра autoLoginProviderNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям приложения, независимо от того, синхронизированы ли они с LDAP и какой тип аутентификации установлен для данных пользователей в Creatio.

SSPNtlmUser — добавьте к значениям параметра autoLoginProviderNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям портала самообслуживания, независимо от того, синхронизированы ли они с LDAP и какой тип аутентификации установлен для данных пользователей в Creatio.

Порядок записи провайдеров параметра autoLoginProviderNames определяет, в каком порядке выполняется проверка наличия пользователя системы среди пользователей приложения (NtlmUser) или среди пользователей портала (SSPNtlmUser). Например, чтобы проверка осуществлялась в первую очередь среди пользователей основного приложения, укажите провайдер NtlmUser первым в списке значений параметра autoLoginProviderNames .

Важно. Вы можете указать в качестве значения параметра autoLoginProviderNames провайдер SSPNtlmUser , только если указан дополнительно провайдер NtlmUser . Существует возможность использовать отдельно только провайдер NtlmUser .

Для отображения страницы входа в систему с доступной ссылкой Войти под доменным пользователем укажите значение “false” для параметра UsePathThroughAuthentication . При этом сквозная аутентификация будет выполняться лишь при переходе на главную страницу приложения. Чтобы отобразить страницу входа, добавьте запись /Login/NuiLogin.aspx к адресу сайта.

Если после выполнения описанных действий при первой попытке входа в систему отображается окно доменной авторизации, то необходимо дополнительно настроить свойства обозревателя Windows.

Чтобы в дальнейшем окно доменной авторизации не отображалось:
В меню “Start” → “Settings” → “Control Panel” → “Network and Internet” выберите пункт “Internet options” (Рис. 4).

Рис. 4 — Настройка свойств обозревателя

chapter_ldap_synchronization_ie_internet_options.png

  1. Откройте для редактирования файл Web.config приложения-загрузчика.
  2. Укажите в файле провайдеры аутентификации Windows:
auth providerNames="InternalUserPassword,SSPLdapProvider,Ldap" autoLoginProviderNames="NtlmUser,SSPNtlmUser"

Использование встроенной аутентификации Windows

Вы можете обеспечить безопасный доступ к вашей организации при помощи встроенной аутентификации Windows (IWA). Когда вы используете IWA, управление учетными записями происходит с помощью Microsoft Windows Active Directory. Выполняя вход в организацию, пользователи тем самым открывают веб-сайт, используя те же учетные записи, которые они использовали для входа в Windows .

Для использования интегрированной аутентификации Windows необходим ArcGIS Web Adaptor (IIS) , развернутый на веб-сервере Microsoft IIS . Вы не можете использовать ArcGIS Web Adaptor (Java Platform) для выполнения встроенной аутентификации Windows . Если этого еще не сделано, установите и настройте ArcGIS Web Adaptor (IIS) для работы с порталом.

Настройка организации на использование Windows Active Directory

По умолчанию, ArcGIS Enterprise активирует HTTPS для всех подключений. Если вы ранее меняли эту опцию, чтобы активировать подключения как по HTTP, так и по HTTPS, вам понадобится перенастроить портал для использования подключения только по HTTPS, выполнив описанные ниже шаги.

Примечание:

При помощи хранилища удостоверений Active Directory ArcGIS Enterprise поддерживает аутентификацию из нескольких доменов в одном лесу, но не предоставляет аутентификацию между несколькими лесами. Для поддержки пользователей, относящихся к конкретной организации, из нескольких лесов требуется провайдер аутентификации SAML.

Настройка организации для работы с HTTPS-коммуникацией

Выполните следующие шаги для настройки организации для работы с HTTPS:

  1. Войдите на веб-сайт организации в качестве администратора.

URL-адрес имеет вид https://webadaptorhost.domain.com/webadaptorname/home .

Обновление хранилища аутентификаций портала

Затем обновите хранилище аутентификаций вашего портала, чтобы использовались учетные записи и группы Windows Active Directory.

  1. Войдите в Portal Administrator Directory в качестве администратора вашей организации.

URL-адрес имеет формат https://webadaptorhost.domain.com/webadaptorname/portaladmin .

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

В большинстве случаев вам будет необходимо изменить только значения для параметров userPassword и user . Хотя вы вводите пароль в виде обычного текста, он будет зашифрован, когда вы щелкнете Обновить конфигурацию (ниже). Для учетной записи, которую вы задали для параметров пользователя, необходимы права доступа только для просмотра адреса электронной почты и полного имени учетных записей Windows в сети. Если возможно, задайте для учетной записи пароль, срок действия которого не истекает. В тех редких случаях, когда Windows Active Directory чувствительна к регистру, установите для параметра caseSensitive значение true .

Либо добавьте в следующий пример информацию о группах вашей организации.

В большинстве случаев вам будет необходимо изменить только значения для параметров userPassword и user . Хотя вы вводите пароль в виде обычного текста, он будет зашифрован, когда вы щелкнете Обновить конфигурацию (ниже). Для учетной записи, которую вы задали для параметров пользователя, необходимы права доступа только для просмотра имен групп Windows в сети. Если возможно, задайте для учетной записи пароль, срок действия которого не истекает.

Настройка дополнительных параметров хранилища аутентификаций

При необходимости вы можете изменить дополнительные параметры конфигурации хранилища аутентификаций с помощью Portal Administrator Directory. Эти параметры включают ограничение на автоматическое обновление групп при входе в организацию пользователя, относящегося к конкретной организации, установку интервала обновления участия, а также опцию, которая определяет, будет ли производиться проверка форматов разных имен пользователей. Более подробно см. в разделе Обновление хранилища аутентификаций.

Добавление учетных записей конкретной организации

По умолчанию пользователи конкретной организации могут работать с веб-сайтом организации ArcGIS Enterprise . Однако они могут лишь просматривать элементы, открытые для всех пользователей организации. Это связано с тем, что учетные записи конкретной организации не были добавлены, и им не были выданы права доступа.

Добавьте учетные записи в свою организацию, используя один из следующих способов:

  • По отдельности или пакетно (однократно, в пакетном режиме с использованием файла .csv или из существующих групп Active Directory)
  • Утилита командной строки
  • Автоматически

Рекомендуется назначить хотя бы одну корпоративную учетную запись в качестве администратора портала. Это можно сделать, выбрав роль Администратор при добавлении учетной записи. Теперь, когда у вас появилась дополнительная учетная запись администратора портала, вы можете назначить учетной записи главного администратора роль Пользователя или удалить ее. Более подробно см. в разделе О учетной записи главного администратора.

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

Настройка ArcGIS Web Adaptor для работы с IWA

Чтобы настроить ArcGIS Web Adaptor на использование IWA, выполните следующие действия:

  1. Откройте Internet Information Server (IIS) Manager.
  2. На панели Подключения найдите и разверните вебсайт, на котором размещен ArcGIS Web Adaptor .
  3. Щелкните на имени ArcGIS Web Adaptor .

По умолчанию – arcgis .

Проверка доступности портала с помощью IWA

Чтобы проверить, используя IWA, есть ли доступ к порталу, выполните следующие действия:

  1. Откройте портал.

URL-адрес имеет формат https://organization.example.com//home .

Запрет создания собственных учетных записей пользователями

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *