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

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

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

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

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

Если этого не сделать, то после входа N-го количества пользователей в 1С, будут появляться сообщения об ошибке:

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

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

Это связано с тем, что «..начиная с версий платформы «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С:Предприятие»:

C:\>ktpass -princ usr1cv8/srv-app01.local.domain.ru@local.domain.ru -mapuser usr1cv8x -pass XxXxXx -out usr1cv8.keytab
C:\>

В результате будет создан файл usr1cv8.keytab в текущей директории (в нашем случае это корень диска C:), а c пользователем usr1cv8x будет ассоциировано имя участника службы usr1cv8/srv-app01.local.domain.ru.

• usr1cv8/srv-app01.local.domain.ru — это стандартное имя службы. Оно включает в себя имя локального пользователя, от имени которого на центральном сервере кластера запускается сервер «1С:Предприятие» (usr1cv8).

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

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

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

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

На сервере srv-app01 проверим работу системы аутентификации. Для этого выполним команду kinit <имя>, где имя — это имя произвольного пользователя, зарегистрированного в домене. Далее введём пароль этого пользователя и нажмём «Enter». Если после этого программа не выдаст никаких сообщений, значит, всё хорошо.

[root@srv-app01]# kinit mailquery
Password for mailquery@local.domain.ru:
[root@srv-app01]#

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

[root@srv-app01]# klist
Ticket cache: KEYRING:persistent:20001:krb_ccache_532ruYi
Default principal: mailquery@local.domain.ru
 
Valid starting   	Expires          	Service principal
14.12.2018 15:48:12  15.12.2018 01:48:12  krbtgt/local.domain.ru@local.domain.ru renew until 21.12.2018 15:48:09
[root@srv-app01]#
[root@srv-app01]# kdestroy
[root@srv-app01]#

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

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

[root@srv-app01]# cd /opt/1C/v8.3/x86_64
[root@srv-app01]# chown usr1cv8:grp1cv8 usr1cv8.keytab
[root@srv-app01]# chmod 600 usr1cv8.keytab
[root@srv-app01]#

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

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

[root@srv-app01]# klist -e -k -t /opt/1C/v8.3/x86_64/usr1cv8.keytab
Keytab name: FILE:/opt/1C/v8.3/x86_64/usr1cv8.keytab
KVNO Timestamp       	Principal
---- ------------------- ------------------------------------------------------
   1 01.01.1970 07:00:00 usr1cv8/srv-app01.local.domain.ru@local.domain.ru (arcfour-hmac)
[root@srv-app01]#

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

Далее проверим возможность работы Kerberos без пароля с использованием секретного ключа. С помощью команды kinit укажем, что надо использовать аутентификационную информацию из файла (в нашем случае /opt/1C/v8.3/x86_64/usr1cv8.keytab) и прочитать оттуда ключ для сервиса usr1cv8/srv-app01.local.domain.ru@local.domain.ru. В результате программа kinit должна отработать без каких-либо сообщений, не спрашивать никаких паролей и вернуть управление обратно в командную строку:

[root@srv-app01]# kinit -k -t /opt/1C/v8.3/x86_64/usr1cv8.keytab usr1cv8/srv-app01.local.domain.ru@local.domain.ru
[root@srv-app01]#

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

[root@srv-app01]# klist
Ticket cache: KEYRING:persistent:20001:krb_ccache_d9U38xU
Default principal: usr1cv8/srv-app01.local.domain.ru@local.domain.ru
 
Valid starting   	Expires          	Service principal
14.12.2018 16:22:32  15.12.2018 02:22:32  krbtgt/local.domain.ru@local.domain.ru renew until 21.12.2018 16:22:32
[root@srv-app01]#

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

[root@srv-app01]# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000)
Kerberos 4 ticket cache: /tmp/tkt1000
 
klist: You have no tickets cached
[root@srv-app01]#

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

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

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

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

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

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

В окне «Выбор пользователя операционной системы» в списке «Домены» выбрать домен «local.domain.ru». 

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

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

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