Пример настройки Kerberos-аутентификации для Linux-версии сервера 1С:Предприятия 8
Статья предназначена для версий 1С:Предприятия, начиная с 8.1.12 и 8.2.8 .
В данном примере описывается настройка Kerberos-аутентификации сервера 1С:Предприятия 8.1 для некоторой базовой системы, состоящей из трех компьютеров: контроллера домена, центрального сервера кластера 1С:Предприятия и рабочей станции.
Настройка сервера 1С:Предприятия версии 8.2 выполняется аналогично с учетом следующего:
- Вместо usr1cv81 следует использовать usr1cv82
- Вместо grp1cv81 — grp1cv82
- Вместо /opt/1C/v8.1 — /opt/1C/v8.2
Описание базовой системы
В базовой системе присутствуют следующие компьютеры:
Настройка контроллера домена
В нашем примере мы полагаем, что контроллер домена Active Directory настроен и работает. Исходя из этого, для настройки Kerberos-аутентификации нужно выполнить следующие шаги:
В DNS-сервере следует «вручную» зарегистрировать все Linux-компьютеры. Регистрация Windows-компьютеров происходит автоматически при включении их в домен. В нашем случае, «вручную» необходимо зарегистрировать центральный сервер кластера 1С:Предприятия (т.к. на нем исполняется Linux-версия сервера), а рабочую станцию включить в домен (зарегистрирована она будет автоматически).
После этого следует создать учетную запись пользователя, с которой будут ассоциироваться запросы авторизации к серверу 1С:Предприятия . В нашем примере это будет пользователь usr1cv8 с паролем pass1cv8 . В свойствах этой учетной записи следует сбросить флажок «Use DES encryption types with this account» . Если ваша реализация Kerberos не поддерживает алгоритм шифрования RC4-HMAC, то флажок обязательно нужно выставить.
Затем для пользователя usr1cv8 следует сгенерировать файл с секретным ключом. Для этого используется утилита ktpass , входящая в состав в пакет Windows Support Tools (Его можно найти в подкаталоге SUPPORT установочного диска Windows).
В командной строке запустим утилиту ktpass . В нашем примере командная строка должна выглядеть следующим образом:
Копировать в буфер обмена
C:\>ktpass -princ usr1cv81/srv1c.krb.local@KRB.LOCAL -mapuser usr1cv8 -pass pass1cv8 -out usr1cv81.keytab C:\>
Если алгоритм RC4-HMAC не поддерживается, командная строка должна выглядеть так:
Копировать в буфер обмена
C:\>ktpass -crypto DES-CBC-CRC -princ usr1cv81/srv1c.krb.local@KRB.LOCAL -mapuser usr1cv8 -pass pass1cv8 -out usr1cv81.keytab C:\>
В результате будет создан файл usr1cv81.keytab в текущей директории (в нашем случае — это корень диска C:), а c пользователем usr1cv8 будет ассоциировано имя участника службы usr1cv81/srv1c.krb.local .
Обратите внимание на различие между именем usr1cv81 и usr1cv8 . В нашем примере usr1cv81/srv1c.krb.local@KRB.LOCAL — это стандартное имя службы. Оно включает в себя имя локального пользователя, от имени которого на центральном сервере кластера запускается сервер 1С:Предприятия ( usr1cv81 ). А usr1cv8 , указываемое в параметре mapuser, — это имя доменного пользователя, которое мы создали в пункте 2.
В параметре pass передается пароль учетной записи usr1cv8 — pass1cv8 .
В параметре out указывается имя файла с ключом. В нашем случае это usr1cv81.keytab .
Настройка центрального сервера кластера 1С:Предприятия
В нашем примере мы полагаем, что кластер серверов 1С:Предприятия уже установлен и работает на центральном сервере кластера.
Прежде всего следует указать DNS-сервер для центрального сервера кластера. Это должен быть DNS контроллер домена. Процесс настройки зависит от конкретного дистрибутива Linux, в нашем случае отредактируем «вручную» файл /etc/resolv.conf, указав в нем IP адрес контроллера домена. В результате файл должен содержать следующие строки:
srv1c:~# cat /etc/resolv.conf nameserver 192.168.29.150 search krb.local srv1c:~#
Теперь проверим работу DNS. Для этого выполним команду ping :
srv1c:~# ping main -c 1 PING main.krb.local (192.168.29.150) 56(84) bytes of data. 64 bytes from 192.168.29.150: icmp_seq=1 ttl=128 time=0.177 ms --- main.krb.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.177/0.177/0.177/0.000 ms srv1c:~#
Для компьютеров, участвующих в процессе аутентификации, не допускается большого расхождения системных часов, так как аутентификационные пакеты (тикеты) имеют ограниченное время действия. Соответственно, нужно синхронизировать время центрального сервера кластера с контроллером домена. Используем для этого команду ntpdate:
srv1c:~# ntpdate main 4 Jun 11:51:53 ntpdate[2527]: step time server 192.168.29.150 offset -56.766439 sec srv1c:~#
Теперь настроим Kerberos. Для этого отредактируем файл /etc/krb5.conf . При этом, нам понадобится NETBIOS-имя контроллера домена. Оно, как правило, представляет собой имя домена в верхнем регистре. Поэтому в нашем случае NETBIOS-имя будет KRB.LOCAL .
В результате файл /etc/krb5.conf должен выглядеть следующим образом:
srv1c:~# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = KRB.LOCAL dns_lookup_realm = false dns_lookup_kdc = false default_tkt_enctypes = rc4-hmac default_tgs_enctypes = rc4-hmac [realms] KRB.LOCAL = < kdc = main.krb.local:88 default_domain = krb.local >[domain_realm] krb.local = KRB.LOCAL .krb.local = KRB.LOCAL KRB.LOCAL = KRB.LOCAL .KRB.LOCAL = KRB.LOCAL [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = < debug = true ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = false krb4_convert = false >srv1c:~#
Если алгоритм RC4-HMAC не поддерживается, то значения параметров default_tkt_enctypes и default_tgs_enctypes должны быть следующими:
. . . default_tkt_enctypes = des-cbc-crc des-cbc-md5 default_tgs_enctypes = des-cbc-crc des-cbc-md5 . . .
Теперь проверим работу системы аутентификации. Для этого выполним команду kinit , где имя — это имя произвольного пользователя, зарегистрированного в домене krb.local. В следующем примере это имя user. Далее введем пароль этого пользователя и нажмем Enter. Если после этого программа не выдаст никаких сообщений — значит все хорошо.
Убедиться в этом можно с помощью команды klist . Как видно на рисунке, мы получили от KDC (Key Distribution Center — центр распределения ключей. Эту функцию выполняет контроллер домена) так называемый ticket-granting ticket . После этого следует с помощью команды kdestroy очистить локальный кэш тикетов, чтобы вернуться в исходное состояние.
srv1c:~# kinit user Password for user@KRB.LOCAL: srv1c:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user@KRB.LOCAL Valid starting Expires Service principal 06/04/08 11:29:21 06/04/08 21:28:28 krbtgt/KRB.LOCAL@KRB.LOCAL renew until 06/05/08 11:29:21 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached srv1c:~# kdestroy srv1c:~#
Далее, любым способом следует передать файл с секретным ключом usr1cv81.keytab , полученный во время настройки контроллера домена, на центральный сервер кластера 1С:Предприятия. Этот файл следует скопировать в директорию, где установлен сервер 1С:Предприятия (по умолчанию это /opt/1C/v8.1/i386), и установить права и владельца файла, как показано ниже:
srv1c:~# cd /opt/1C/v8.1/i386 srv1c:i386# chown usr1cv81:grp1cv81 usr1cv81.keytab srv1c:i386# chmod 600 usr1cv81.keytab srv1c:i386#
При желании файл можно разместить в любом другом месте, нужно только изменить переменную SRV1CV8_KEYTAB в конфигурационном файле, чтобы она указывала на новое местоположение файла с секретным ключом.
После этого, с помощью команды klist проверяем, все ли мы сделали правильно. Для этого выполним команду:
srv1c:~# klist -e -k -t /opt/1C/v8.1/i386/usr1cv81.keytab
В нашем случае результат выполнения команды должен выглядеть следующим образом:
Keytab name: FILE:/opt/1C/v8.1/i386/usr1cv81.keytab KVNO Principal ---- --------------------------------------------------------------------- 13 usr1cv81/srv1c.krb.local@KRB.LOCAL (ArcFour with HMAC/md5)
Если алгоритм RC4-HMAC не поддерживается, результат выполнения команды будет выглядеть следующим образом:
Keytab name: FILE:/opt/1C/v8.1/i386/usr1cv81.keytab KVNO Principal ---- --------------------------------------------------------------------- 13 usr1cv81/srv1c.krb.local@KRB.LOCAL (DES cbc mode with RSA-MD5)
Мы видим, что файл с секретным ключом содержит именно то, что нам нужно (в колонке Principal указано то самое имя службы, которое мы задавали при создании файла с секретным ключом (п. 3), и правильный алгоритм шифрования ( ArcFour with HMAC/md5 для RC4-HMAC или DES cbc mode with RSA-MD5 для DES).
Далее проверим возможность работы Kerberos без пароля с использованием секретного ключа. С помощью команды kinit укажем, что надо использовать аутентификационную информацию из файла (в нашем случае /opt/1C/v8.1/i386/usr1cv81.keytab ) и прочитать оттуда ключ для сервиса usr1cv81/srv1c.krb.local@KRB.LOCAL . В результате программа kinit должна отработать без каких-либо сообщений, не спрашивать никаких паролей и вернуть управление обратно в командную строку:
srv1c:~# kinit -k -t /opt/1C/v8.1/i386/usr1cv81.keytab usr1cv81/srv1c.krb.local@KRB.LOCAL srv1c:~#
Теперь посмотрим на результаты работы с помощью команды klist . В случае успеха мы увидим примерно следующее:
srv1c:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: usr1cv81/srv1c.krb.local@KRB.LOCAL Valid starting Expires Service principal 06/04/08 11:44:54 06/04/08 21:43:58 krbtgt/KRB.LOCAL@KRB.LOCAL renew until 06/05/08 11:44:54 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached srv1c:~#
Если что-то настроено не так, то эта команда выведет следующее:
srv1c:~# klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000) Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached srv1c:~#
Если проверка работоспособности прошла успешно, это значит, что с данного момента сервер кластера 1С:Предприятия способен обрабатывать запросы на аутентификацию. При этом перезапуск сервера не требуется, кроме того случая, когда в конфигурационном файле было изменено место расположения файла с секретным ключом.
Сервер «1С: Предприятие» на Linux: настройка доменной авторизации из различных доменов
Похожая статья уже была на Хабре, но у меня появилась задача авторизировать пользователей из разных и ничем не связанных доменов.
В статье будем использовать: Microsoft AD, 1c Сервер, Debian 11.
В связи с событиями в мире, появилась идея перевода всех серверов на linux, и как говорится из названия, авторизации множества пользователей из разных доменов, скажу сразу, домены находятся не в лесу и на разных площадках.
srv-1cserver — целевой сервер 1с предприятия.
domain.loc — 1 домен.
master.loc — 2 домен.
office.loc — 3 домен.
На данном этапе будем считать что у нас уже функционирует сервер на нашем Debian и там есть пара баз.
На каждом сервере необходимо создать пользователя с которым будут ассоциироваться запросы к 1с серверу.
Для простоты будем использовать пользователя в Windows usr1cv8 , в Debian usr1cv8 .
При создании пользователя, обязательно снять галочку в пункте «Use DES encryption types with this account».
Сделаем для этого пользователя секрутный ключ .keytab c помощью утилиты ktpass.
C:\>ktpass -princ usr1cv8/srv-1cserver.domain.ru@domain.loc -mapuser usr1cv8 -pass XxXxXx -out usr1cv8.keytabПосле этого в корне диска С:\ у нас будет файл usr1cv8.keytab и теперь с пользователем usr1cv8 ассоциируется служба usr1cv8/srv-1cserver.domain.ru@domain.loc.
Проделаем эту процедуру на всех Windows серверах и сформированные файлы поместим в удобные папки на Debian для нас.
Дальнейшие действия тоже довольно простые, запустим уже на Debian утилиту ktutil.
root@srv-1cserver:~# ktutil ktutil: list slot KVNO Principal ---- ---- --------------------------------------------------------------------- Читаем кейтаб ktutil: rkt /opt/1cv8/x86_64/8.3.21.1393/keytab_domain.loc/usr1cv8.keytab смотрим ktutil: list slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 1 HTTP/srv-1cserver.domain.ru@DOMAIN.LOC читаем второй кейтаб ktutil: rkt /opt/1cv8/x86_64/8.3.21.1393/keytab_master.loc/usr1cv8.keytab смотрим ktutil: list slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 1 HTTP/srv-1cserver.domain.ru@DOMAIN.LOC 2 1 HTTP/srv-1cserver.domain.ru@MASTER.LOC читаем третий кейтаб ktutil: rkt /opt/1cv8/x86_64/8.3.21.1393/keytab_office.loc/usr1cv8.keytab смотрим ktutil: list slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 1 HTTP/srv-1cserver.domain.ru@DOMAIN.LOC 2 1 HTTP/srv-1cserver.domain.ru@MASTER.LOC 3 1 HTTP/srv-1cserver.domain.ru@OFFICE.LOC Добавилось, т.е. успешно объединили три keytab Записываем ktutil: wkt /etc/krb5.keytabПосле этого перезапустим 1с сервер и можно заходить в тонкий клиент и прописать настройки пользователю.
Для этого переходим в «Администрирование», слева в списке выбрать «Пользователи».
В свойствах пользователя выбрать «Аутентификация операционной системы» и в поле «Пользователь» прописать \\MASTER.LOC\e.ivanov
В 1с домен прописать обязательно большими буквами.
Данное действие проделаем на нужных серверах, и на данном этапе авторизация с различных серверов будет работать.