Настройка доменной авторизации 1с

Обновлено: 08.07.2024

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

Данный кейс с реальной практики, проект начался в начале 2019 и все "n" баз были переведены в течении полугода на доменную авторизацию (надеюсь все понимают, что это значит), но мне больше нравится SSO.

Значит что имеем:

Windows Server 2016 + AD (не рассматриваем как настраивать)

CentOS 7 + Haproxy + Comodo SSL Wildcard

Windows Server 2016 + IIS + 1C

Примерная схема работы

Примерная схема работы

Вроде все понятно, конечно если об этом вы слышите в первый раз, то нужно будет почитать дополнительные материалы как настраивается каждый сервис.

Двигаемся дальше и приступаем к настройке наших сервисов

Можно так же использовать сертификаты Let's Encrypt но у меня есть подписанный ЦС, а еще может быть что клиент 1С на разных ОС будет ругаться на Let's Encrypt. Если у вас кластер 1С тогда нужно добавить еще один сервер rt_db_srv02 в backend rt_db_server

Настройка IIS, тут уже будет больше картинок.

После инстала IIS, включаем только 80й порт остальные нам не нужны так как ssl будет занимается haproxy. На картинке ниже роли, которые нужно поднять:

компоненты IIS

компоненты IIS

Я это все делаю с помощью Ansible, поэтому готовых команд PS под рукой нет. Идем дальше и не к настройке IIS, а к установке 1С:

Ставим все кроме хранилища, ковертора и проверки целосности

Ставим все кроме хранилища, ковертора и проверки целосности

По стандарту заходим в консоль администрирования 1С подключаем базу и тд. В клиенте 1С на сервере на котором бы будем делать публикацию прописываем имя сервера (у нас же AD и DNS внутренний) можно без порта, но естественно если порт у вас отличный от стандартного (например, подняли еще одну службу на 1640), то его писать тоже нужно типа server1С1:1641, но если у вас кластер тогда пишем так server1С1;server1С2 (server1С1:1641;server1С2:1641) и нормальные имена нужно прописывать обязательно, так как это пойдет в конфиг IIS. Чуть не забыл, после инсталляции 1С службу, которую она создаст, необходимо запустить от имени доменного пользователя, на сервер 1С его нужно будет сделать админом, а в домене может быть обычным пользователем. главное что б мог читать пользователей с AD. Например

запуск службы от доменного пользователя

запуск службы от доменного пользователя

Публикуем базу как обычно, все по дефолту, с необходимыми галочками в hs/ws

Настройки веб-сайт

Настройки веб-сайт

Веб сайт есть, а далее вместе с ним создается и пул приложений. который нам больше всего и нужно, так как в нем мы задаем кто будет авторизовать креды пользователей в 1С и расшифровывать karberos. Для этого нам нужен еще один доменный пользователь желательно отдельный, например iis_service (создаём помним пароль)))

Так он выглядит стандартно:


Приводим его в нужный вид, редактируя удостоверение:


Тюним, Режим управления выставляем Классический и нужно что б это удостоверение использовалось для этого делаем в редакторе конфигурации сервер (путь system.webServer/security/authentication/windowsAuthentication).



делаем так

делаем так


С этим все готово. Для корректной работы, необходимо в AD прописать spn запись, это просто заходим на домен контроллер и запускаем команды, в которых пишем нашу публикацию и нашего пользователя, который расшифровывает kerberos:

В 1С пользователю вставляем авторизацию как на картинке:


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

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

В следующей статье напишу про то, как мы сделали веб страничку с сеансами пользователей и возможностью их удаления.

В данной статье мы рассмотрим настройку сервера «1С:Предприятие» для использования Microsoft AD в качестве системы авторизации клиентов 1С. Статья представляет собой описание успешно внедрённого решения, за основу брались различные статьи из открытых источников, в частности официальная документация разработчика 1С.


Преамбула.
У нас имеется работающий на ОС Linux (CentOS7) сервер «1С:Предприятие». Сервер работает на хосте srv-app01, входящем в домен local.domain.name.

1. Настройка кластера сервера 1С:Предприятие

Настройка и управление кластером сервера «1С:Предприятие» происходит с компьютера с ОС Windows, так что для управления сервером нужно использовать традиционную оснастку mmc для Windows «Администрирование серверов 1С:Предприятие», которую следует установить из дистрибутива технологической платформы для Windows (ссылка).

Обязательно нужно настроить «Параметры рабочего сервера», как показано ниже:


Свойства кластера 'Критический объем памяти процессов', 'Режим распределения нагрузки' или свойства рабочего сервера 'Критический объем памяти процессов', 'Временно допустимый объем памяти процессов', 'Интервал превышения допустимого объема памяти процессов', 'Безопасный расход памяти за один вызов', 'Количество ИБ на процесс' содержат значения, отличные от значений по умолчанию.

Использование этих функций возможно только для лицензий на платформу уровня КОРП.

Это связано с тем, что «..начиная с версий платформы «1С:Предприятие» 8.3.12.1852, 8.3.13.1791 и 8.3.14.1592, вводятся ограничения на техническом уровне, не позволяющие использовать функциональность КОРП». Подробнее можно посмотреть здесь.

2. Настройка Kerberos-аутентификации

Для решения поставленной задачи настроим Kerberos-аутентификацию сервера «1С:Предприятие».

а) Настройка контроллера домена

Имя сервера srv-app01 обязательно должно разрешаться DNS-сервером (если его ввели в домен, то соответствующая запись в DNS-сервере есть).

Создать в домене учетную запись пользователя, с которой будут ассоциироваться запросы авторизации к серверу 1С:Предприятие. Имя может быть произвольное. В нашем случае это будет пользователь usr1cv8x с паролем XxXxXx. В свойствах этой уч`тной записи на вкладке «Учётная запись» в секции «Параметры учётной записи:» следует сбросить флажок «Use DES encryption types with this account»:

Для пользователя usr1cv8x следует сгенерировать файл с секретным ключом на компьютере с ОС Windows. Для этого используется утилита ktpass, входящая в состав в пакета Windows Support Tools (его можно найти в подкаталоге SUPPORT установочного диска Windows).

В командной строке запустим утилиту ktpass, которая «свяжет» доменного пользователя с пользователем, от имени которого работает сервер «1С:Предприятие»:

usr1cv8x, указываемое в параметре mapuser, — это имя доменного пользователя, которого мы создали.

В параметре pass передаётся пароль доменной учётной записи usr1cv8x.

В параметре out указывается имя файла с ключом. В нашем случае это usr1cv8.keytab.

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

Убедимся, что все в порядке:

Как видно, мы получили от KDC (Key Distribution Center — центр распределения ключей, эту функцию выполняет контроллер домена) так называемый ticket-granting ticket. После этого следует с помощью команды kdestroy очистить локальный кэш тикетов, чтобы вернуться в исходное состояние.

Далее любым способом следует передать файл с секретным ключом usr1cv8.keytab, полученный во время настройки контроллера домена, на центральный сервер кластера «1С:Предприятия». Этот файл следует скопировать в директорию, где установлен сервер «1С:Предприятие» (по умолчанию это /opt/1C/v8.3/x86_64), и установить права и владельца файла как показано ниже:

При желании файл можно разместить в любом другом месте, нужно только изменить переменную SRV1CV8_KEYTAB в конфигурационном файле (/etc/sysconfig/srv1cv83), чтобы она указывала на новое местоположение файла с секретным ключом.

После этого с помощью команды klist проверяем, всё ли мы сделали правильно. Для этого выполним команду:

Мы видим, что файл с секретным ключом содержит именно то, что нам нужно — в колонке Principal указано то самое имя службы, которое мы задавали при создании файла с секретным ключом, и правильный алгоритм шифрования (arcfour-hmac для RC4-HMAC).

Теперь посмотрим на результаты работы с помощью команды klist. В случае успеха мы увидим примерно следующее:

Если что-то настроено не так, то эта команда выведет следующее:

Если проверка работоспособности прошла успешно, это значит, что с данного момента сервер кластера «1С:Предприятия» способен обрабатывать запросы на аутентификацию. При этом перезапуск сервера не требуется, кроме того случая, когда в конфигурационном файле было изменено место расположения файла с секретным ключом.

в) Настройка пользователей в информационных БД «1С:Предприятие»

Для настройки аутентификации пользователей в информационной БД «1С:Предприятие» с помощью доменной учетной записи нужно запустить БД под Администратором.

Перейти в «Администрирование», слева в списке выбрать «Пользователи».


В появившемся окне «Пользователи» выбрать нужного пользователя.

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

В списке «Пользователи» выбрать нужного пользователя и нажать на кнопку «Выбрать». Должно получиться как на скриншоте:


Эти действия нужно повторить для всех пользователей БД.

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

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

Конечно, данная тема также подымается и на курсе: Администратор 1С!

Тогда мы просто разобрали аутентификацию через операционную систему без Active Directory.

В качестве дополнения думаю будет не лишним расписать и аутентификацию через AD.

В первую очередь это позволит, пользователям не запоминать еще и пароли от 1С, будет достаточно знать учетку на вход в Windows, чтоб начать работу в 1С, выполнить вход.

Autentifickacia_cherez_Active_Directory_v_1S

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

Что ж приступим к работе!

Предполагается, что Active Directory у Вас уже «поднята» и можно приступать к переходу на аутентификацию в 1С через AD.

Сервер или ПК, (где Ваши пользователи работают в 1С Предприятии) должен быть присоединен к домену.

Итак, запускаем 1С Предприятие в режиме «Конфигуратор» под учетной записью администратора.

Autentifickacia_cherez_Active_Directory_v_1S_2

Затем на вкладке «Основные» выполним такие манипуляции:

Сперва уберем птичку возле «Аутентификация 1С Предприятия».

Вместо этого ставим птичку возле «Аутентификация операционной системы».

Autentifickacia_cherez_Active_Directory_v_1S_3

Затем следует выбрать пользователя, которого мы собственно «свяжем» с учеткой пользователя в 1С. Именно этот пользователь, созданный предварительно в Active Directory будет запускать 1С Предприятие.

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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 (для тестирования).

Читайте также: