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

Веб-клиент, windows авторизация

(0) >из внешней сети как можно зайти, используя данные нашей локальной сети

Никак. Протокол win-аутентификации (NTLM) работает только внутри локальной сети.

(1) >А еще хочется, чтобы доменная аутентификация опционально для пользователя была бы «неавтоматической», то есть с вводом логина, пароля и домена

Это штатная функция. В настройках запуска базы нужно выбрать «Запрашивать имя и пароль».

(3) >Доменные — не умеет.
Имхо, и правильно делает. Для юзеров самое то, чтобы работали в базах под своими учетками.
А для админа есть 1с-ные логин/пароль.

>Сквид же умеет так делать.
Дык, 1с же не только через веб-сервер умеет работать.

(12) и проблема то в чем?

заходишь на сервак в конторе по RDP/VPN под учеткой домена

заходишь с сервера в 1с.

> а стандарт де-факто при организации выхода в интернет из локальной сети.

лучше бы в 1с аудит сделали. блокировку после N-той попытки зайти

(23) Да, неявно. В этом режиме 1С ничего не знает про логины, пароли, домены и т.д., а пользуется стандартным интерфейсом безопасности ОС.

При явной аутентификации необходимо реализовывать защищенный ввод логина/пароля, процедуры аутентификации в домене и на локальном компьютере, обрабатывать ошибки, выполнять дополнительные действия вроде «Менять пароль при входе в систему» и т.п.

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

Вот зачем 1С становиться «слабым звеном»?

>Вот зачем 1С становиться «слабым звеном»?

некуй накручивать на систему еще и «варку кофе с минетом».

Настройка подключения к опубликованному web-сервису «Клеверенс» на web-сервере IIS с включенной авторизацией учетных записей OС Windows

Если обмен между Mobile SMARTS и «1С: Предприятием» происходит через веб-сервис «Клеверенса», то для выполнения внешних требований безопасности необходимо подключаться к веб-серверу с авторизацией по пользователю 1С. Но в некоторых организациях для авторизации в IIS можно использовать только данные пользователя Windows. Чтобы не лишать таких пользователей Mobile SMARTS возможности работать c 1С через веб-сервер, мы добавили возможность подключаться к нему от имени пользователя Windows.

Если у вас используется доменная авторизация пользователя Windows, то авторизация при входе в «1С: Предприятие» и подключении к веб-серверу будет происходить без дополнительного запроса имени пользователя и пароля.

Настройка использования доменной авторизации Windows при подключении к веб-серверу производится в несколько этапов.

Настройка проверки подлинности веб-службы IIS в Windows

Рассмотрено на примере ОС Windows 10, для других версий Windows могут быть небольшие отличия.

Открыть панель управления Windows и выбрать пункт «Программы».

Далее выбрать «Включение или отключение компонентов Windows».

В открывшемся списке найти пункт «Службы IIS», затем открыть «Службы Интернета» → «Безопасность» и поставить флаг в пункте «Проверка подлинности Windows».

После этого необходимо произвести проверку работы опубликованного web-сервиса. Для этого вводим в браузере его адрес (например, http://VM-VIN10-USR-3/ut114demo/ws/CleverenceWebExtension.1cws), и если все настройки были указаны правильно, окно ввода имя пользователя и пароля не появится, а откроется следующая xml-страница.

Настройка авторизации пользователя в базе «1С:Предприятие 8»

В конфигураторе 1С в настройках пользователя («Администрирование» → «Пользователи» → выбрать нужного пользователя) поставьте флаг в пункте «Аутентификация операционной системы».

В настройках публикации на веб-сервере поставьте флаг на «Использовать аутентификацию операционной системы» и нажмите «Опубликовать».

Изменение настроек коннектора Mobile SMARTS к базе «1С:Предприятия»

Коннектор 1С используется только в случае работы сервера Mobile SMARTS и «1С: Предприятие» в режиме онлайн.

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

Откройте вкладку «Свойства» для коннектора «1С: Предприятия».

В строке «Сервер» укажите адрес ранее опубликованного веб-сервера.

Далее во вкладке «Прочее» укажите следующие параметры:

• Домен — имя домена или имя текущей OС Windows (например «cleverence.local» или VM-VIN10-USR-3).
• Пароль — пароль пользователя домена или текущей ОС, который вы будете использовать при подключении к опубликованному веб-сервису 1С.
• Пользователь — пользователь, от имени которого вы будете подключаться к веб-сервису и 1С.
• Тип авторизации — укажите значение «Win» (Windows).
• Тип подключения — WebConnector.

После того как был выбран тип авторизации Win, перевведите пароль для получения токена Windows!

Сохраните все изменения.

Запустите коннектор к 1С. Если запуск прошел успешно, значит все настройки были произведены правильно.

Если попытка запуска завершится неудачей, то необходимо перепроверить все указанные настройки, или воспользоватьс функцией «Диагностика и исправление проблем».