Приклад налаштування 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
  • ім'я комп'ютера (hostname) — main
  • IP-адреса — 192.168.29.150
  • ім'я домену — krb.local
• Центральний сервер кластера 1С:Підприємства
  • Операційна система Fedora 6
  • Ім'я комп'ютера (hostname) — srv1c
  • IP-адреса — 192.168.29.151
  • Установлено реалізацію Kerberos від MIT, що підтримує алгоритм RC4-HMAC (пакет krb5-workstation).
• Робоча станція

Налаштування контролера домену

У нашому прикладі ми припускаємо, що контролер домену Active Directory налаштований і працює. Виходячи з цього, для налаштування Kerberos-автентифікації потрібно виконати такі кроки:

1. У DNS-сервері слід "вручну" зареєструвати всі Linux-комп'ютери. Реєстрація Windows-комп'ютерів відбувається автоматично під час включення їх до домену. У нашому випадку "вручну" необхідно зареєструвати центральний сервер кластера 1С:Підприємства (оскільки на ньому виконується Linux-версія сервера), а робочу станцію включити до домену (вона буде зареєстрована автоматично).
2. Після цього слід створити обліковий запис користувача, з яким асоціюватимуться запити авторизації до сервера 1С:Підприємства . У нашому прикладі це буде користувач usr1cv8 з паролем pass1cv8. У властивостях цього облікового запису слід зняти прапорець "Use DES encryption types with this account". Якщо ваша реалізація Kerberos не підтримує алгоритм шифрування RC4-HMAC, то прапорець обов'язково потрібно встановити.
3. Потім для користувача usr1cv8 слід згенерувати файл із секретним ключем. Для цього використовується утиліта ktpass, що входить до складу пакета Windows Support Tools (Його можна знайти в підкаталозі SUPPORT інсталяційного диска Windows).

У командному рядку запустимо утиліту ktpass. У нашому прикладі командний рядок має виглядати так:

C:>ktpass -princ usr1cv81/srv1c.krb.local@KRB.LOCAL -mapuser usr1cv8 -pass pass1cv8 -out usr1cv81.keytabC:>

Якщо алгоритм RC4-HMAC не підтримується, командний рядок має виглядати так:

C:>ktpass -crypto DES-CBC-CRC -princ usr1cv81/srv1c.krb.local@KRB.LOCAL    -mapuser usr1cv8 -pass pass1cv8 -out usr1cv81.keytabC:>

У результаті буде створено файл usr1cv81.keytab у поточній директорії (у нашому випадку — це корінь диска 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.confnameserver 192.168.29.150search krb.localsrv1c:~#

Тепер перевіримо роботу DNS. Для цього виконаємо команду ping:

srv1c:~# ping main -c 1PING 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 0msrtt min/avg/max/mdev = 0.177/0.177/0.177/0.000 mssrv1c:~#

Для комп'ютерів, що беруть участь у процесі автентифікації, не допускається великого розходження системного часу, оскільки автентифікаційні пакети (тікети) мають обмежений час дії. Відповідно, потрібно синхронізувати час центрального сервера кластера з контролером домену. Використаємо для цього команду ntpdate:

srv1c:~# ntpdate main4 Jun 11:51:53 ntpdate[2527]: step time server 192.168.29.150 offset -56.766439 secsrv1c:~#

Тепер налаштуємо Kerberos. Для цього відредагуємо файл /etc/krb5.conf. При цьому нам знадобиться NETBIOS-ім'я контролера домену. Воно, як правило, є ім'ям домену у верхньому регістрі. Тому в нашому випадку NETBIOS-ім'ям буде KRB.LOCAL.

У результаті файл /etc/krb5.conf має виглядати так:

srv1c:~# cat /etc/krb5.conf[logging]default = FILE:/var/log/krb5libs.logkdc = FILE:/var/log/krb5kdc.logadmin_server = FILE:/var/log/kadmind.log[libdefaults]default_realm = KRB.LOCALdns_lookup_realm = falsedns_lookup_kdc = falsedefault_tkt_enctypes = rc4-hmacdefault_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.LOCALKRB.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-md5default_tgs_enctypes = des-cbc-crc des-cbc-md5. . .

Тепер перевіримо роботу системи автентифікації. Для цього виконаємо команду kinit <ім'я>, де ім'я — це ім'я довільного користувача, зареєстрованого в домені krb.local. У наступному прикладі це ім'я user. Далі введемо пароль цього користувача та натиснемо Enter. Якщо після цього програма не видасть жодних повідомлень — отже, все добре.

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

srv1c:~# kinit userPassword for user@KRB.LOCAL:srv1c:~# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: user@KRB.LOCALValid starting     Expires            Service principal06/04/08 11:29:21  06/04/08 21:28:28  krbtgt/KRB.LOCAL@KRB.LOCAL        renew until 06/05/08 11:29:21Kerberos 4 ticket cache: /tmp/tkt0klist: You have no tickets cachedsrv1c:~# kdestroysrv1c:~#

Далі будь-яким способом слід передати файл із секретним ключем usr1cv81.keytab, отриманий під час налаштування контролера домену, на центральний сервер кластера 1С:Підприємства. Цей файл слід скопіювати до директорії, де встановлено сервер 1С:Підприємства (за замовчуванням це /opt/1C/v8.1/i386), і встановити права та власника файлу, як показано нижче:

srv1c:~# cd /opt/1C/v8.1/i386srv1c:i386# chown usr1cv81:grp1cv81 usr1cv81.keytabsrv1c:i386# chmod 600 usr1cv81.keytabsrv1c: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.keytabKVNO Principal---- ---------------------------------------------------------------------  13 usr1cv81/srv1c.krb.local@KRB.LOCAL (ArcFour with HMAC/md5)

Якщо алгоритм RC4-HMAC не підтримується, результат виконання команди матиме такий вигляд:

Keytab name: FILE:/opt/1C/v8.1/i386/usr1cv81.keytabKVNO 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.LOCALsrv1c:~# 

Тепер подивимося на результати роботи за допомогою команди klist. У разі успіху ми побачимо приблизно таке:

srv1c:~# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: usr1cv81/srv1c.krb.local@KRB.LOCALValid starting     Expires            Service principal06/04/08 11:44:54  06/04/08 21:43:58  krbtgt/KRB.LOCAL@KRB.LOCAL        renew until 06/05/08 11:44:54Kerberos 4 ticket cache: /tmp/tkt0klist: You have no tickets cachedsrv1c:~# 

Якщо щось налаштовано не так, то ця команда виведе таке:

srv1c:~# klistklist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000)Kerberos 4 ticket cache: /tmp/tkt1000klist: You have no tickets cachedsrv1c:~# 

Якщо перевірка працездатності пройшла успішно, це означає, що від цього моменту сервер кластера 1С:Підприємства здатний обробляти запити на автентифікацію. При цьому перезапуск сервера не потрібний, окрім того випадку, коли в конфігураційному файлі було змінено місце розташування файлу із секретним ключем.