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

Инструкция подойдет как для одиночного сервера 1С, так и для кластера. Мы имеем 3 сервера:

DC01 – Windows Server с Active Directory
SQL01 – Debian 12 с Postgres и 1С сервером
TS01 – терминальный сервер 1С на Windows

Установка и настройка Kerberos на Linux

Первым делом установим Kerberos на Linux:

apt install krb5-k5tls krb5-user

И сразу же перейдем к его настройке:

nano /etc/krb5.conf

Стираем всё и вставляем готовый конфиг, в котором нужно лишь подправить ваш домен. test.local здесь меняем на ваш домен, оставляя исходный реестр:

[libdefaults]
    default_realm = TEST.LOCAL
    dns_lookup_realm = false
    dns_lookup_kdc = false
    default_tgs_enctypes = rc4-hmac des3-hmac-sha1 arcfour-hmac des-hmac-sha1 des-cbc-md5 des-cbc-crc aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tkt_enctypes = rc4-hmac des3-hmac-sha1 arcfour-hmac des-hmac-sha1 des-cbc-md5 des-cbc-crc aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes = rc4-hmac des3-hmac-sha1 arcfour-hmac des-hmac-sha1 des-cbc-md5 des-cbc-crc aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    udp_preference_limit = 0

[realms]
    TEST.LOCAL = {
        kdc = DC.test.local:88
        default_domain = test.local
    }

[domain_realm]
    .test.local = TEST.LOCAL
    test.local = TEST.LOCAL

[kdc]
    profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
    pam = {
        debug = true
        ticket_lifetime = 36000
        renew_lifetime = 36000
        forwardable = false
        krb4_convert = false
    }

Настройка доменной авторизации Windows в 1С на Linux сервере - EFSOL

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

Настройка файла hosts для SQL01

Не уходя от сервера, сразу же настроим файл /etc/hosts . Это также может играть важную роль для того, чтобы избежать ошибки. FQDN записи обязательно должны быть вверху.

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.15.82.2      SQL01.TEST.LOCAL

Настройка файла resolv.conf

Также мы настроим /etc/resolv.conf на наш домен, а именно допишем строку:

search test.local

Настройка Active Directory

Теперь можем переходить на Windows сервер с Active Directory. Там также нужно провести настройки. Для начала, стоит добавить компьютер в AD, а также создать учетную запись для 1С сервера, которая будет нашим связующим звеном. Также обязательно проверяем, что у нас имеется запись в DNS о нашем сервере. Если нет, то необходимо добавить вручную.

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

Настройки делегирования в AD

Теперь можно перейти в свойства пользователя. Никаких DES шифрований включать не нужно. Выбираем в Делегировании «Доверять этому пользователю делегирование служб (только Kerberos)». Возможно, этот параметр также не является обязательным, но для избежания ошибок выставим его.

Генерация ключа для 1С

Теперь нам необходимо сгенерировать ключ. Для этого я явно объявляю ptype , kvno и методы шифрования (использую все доступные). Обычно в статьях с 1C 8.2 это не указывают, но в новых версиях AD многие криптоалгоритмы устарели, бывают предупреждения о ptype и проблемы с kvno на Windows, Linux, поэтому лучше указать их явно:

ktpass -princ usr1cv8/sql01.test.local@TEST.LOCAL -mapuser usr1cv8 -pass password -out usr1cv8.keytab -ptype KRB5_NT_PRINCIPAL /kvno 1 /crypto ALL

Небольшой разбор параметров:

-princ usr1cv8/sql01.test.local@TEST.LOCAL — указан пользователь Linux – usr1cv8 , от которого работает служба 1С и сам сервер 1С. Несмотря на то, что hostname прописан в верхнем реестре на сервере, здесь я его прописываю в нижнем. Когда я пробовал делать в верхнем, то в ТЖ можно увидеть ошибку:

GSS-API error gss_acquire_cred: No key table entry found matching usr1cv8/sql01.test.local@ В самой ошибке пишется нижний реестр, и именно с ним она пропала.

-mapuser и -pass — это данные от нашего пользователя AD.

Проверить привязку можно командой в cmd:

setspn -L usr1cv8

В «Имя входа пользователя» все поменялось, теперь там прописан полный сервер и домен.

Перенос и настройка ключа на Linux сервере

Теперь можем переходить на сервер Linux. Переносим туда ключ (обычно путь /opt/1cv8/x86_64/8.3.24.1691/usr1cv8.keytab ), выдаем права на файл пользователю 1С:

chown usr1cv8:grp1cv8 /opt/1cv8/x86_64/8.3.24.1691/usr1cv8.keytab

chmod 600 /opt/1cv8/x86_64/8.3.24.1691/usr1cv8.keytab

и можем пробовать инициализировать его:

kinit -k -t /opt/1cv8/x86_64/8.3.24.1691/usr1cv8.keytab usr1cv8/rk-sql01.test.local@TEST.LOCAL

/opt/1cv8/x86_64/8.3.24.1691/usr1cv8.keytab — это стандартный путь ключа, но он может меняться. Лучше смотреть файл systemd и поменять его, если требуется.

Проверка и инициализация ключа

Также можно посмотреть полную информацию по ключу, это делается командой:

klist -e -k -t /opt/1cv8/x86_64/8.3.24.1691/usr1cv8.keytab

Если timestamp 1970 года, то в этом нет ничего страшного. Ключ все также будет работать. Теперь если мы пропишем klist , то у нас должна появиться информация о подключенном ключе и тикетах.

Проверка авторизации в 1С

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

Если после перезахода не получается войти в 1С и продолжает требовать ввести пароль, то идем в ТЖ и смотрим ошибки. Для кластера лучше делать две учетные записи, 1 запись — 1 привязка. Если привязывать к одной учетной записи, то после регистрации других серверов может не проходить авторизация по ключу из-за того, что имя входа пользователя заменяется на последнюю регистрацию.