Пример настройки 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-аутентификации нужно выполнить следующие шаги:

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

Если алгоритм RC4-HMAC не поддерживается, командная строка должна выглядеть так:

В результате будет создан файл 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 адрес контроллера домена. В результате файл должен содержать следующие строки:

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

Для компьютеров, участвующих в процессе аутентификации, не допускается большого расхождения системных часов, так как аутентификационные пакеты (тикеты) имеют ограниченное время действия. Соответственно, нужно синхронизировать время центрального сервера кластера с контроллером домена. Используем для этого команду ntpdate:

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

В результате файл /etc/krb5.conf должен выглядеть следующим образом:

Если алгоритм RC4-HMAC не поддерживается, то значения параметров default_tkt_enctypes и default_tgs_enctypes должны быть следующими:

Теперь проверим работу системы аутентификации. Для этого выполним команду kinit , где имя — это имя произвольного пользователя, зарегистрированного в домене krb.local. В следующем примере это имя user. Далее введем пароль этого пользователя и нажмем Enter. Если после этого программа не выдаст никаких сообщений — значит все хорошо.

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

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

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

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

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

Если алгоритм RC4-HMAC не поддерживается, результат выполнения команды будет выглядеть следующим образом:

Мы видим, что файл с секретным ключом содержит именно то, что нам нужно (в колонке 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 должна отработать без каких-либо сообщений, не спрашивать никаких паролей и вернуть управление обратно в командную строку:

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

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

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

Источник

Авторизация Active Directory на Linux сервере 1С

Авторизация Active Directory на Linux сервере 1С

В 1С у пользователей есть возможность авторизоваться не только с помощью пароля, но и пользователем операционной системы. Это повышает управляемость и доступность системы, так как пользователь, авторизовавшись в операционной системе, может просто открыть 1С и база откроется от его имени без ввода дополнительных паролей. Это также повышает общую безопасность системы, так как не остается учетных записей, для которых не установлен пароль или установлен не надежный. В организации роль глобального каталога пользователей, как правило, выполняет контроллер домена. Как правило, применяются доменные службы Active Directory под управлением Windows. Для работы с пользователями в такой среде с Linux сервером 1С необходимо выполнить ряд манипуляций, чтобы к пользователям баз 1с, размещенным на нем, могла применяться сквозная авторизация (Single-Sign-On).

Для работы сервера в такой среде потребуется сделать всего несколько дел, при этом вводить сервер в домен не обязательно, нужно только вручную добавить статическую запись DNS в доменной зоне, чтобы сервер мог правильно пинговаться. Также следует заранее позаботиться о синхронности времени на сервере 1С и контроллере домена. Далее необходимо настроить домен поиска и сервера имен в файле resolv.conf:

Далее необходимо выполнить ряд действий на контроллере домена. Необходимо создать на контроллере домена учетную запись, имя которой совпадает с именем учетной записи сервера 1С. Как правило, это usr1cv8. Затем на контроллере домена необходимо создать файл с секретным ключом:

В результате создастся файл usr1cv8.keytab в текущей директории, а c пользователем usr1cv8 будет ассоциировано имя участника службы usr1cv81/ИМЯ_СЕРВЕРА.example.com@EXAMPLE.COM. Его необходимо разместить на сервере 1С в каталоге /opt/1C/v8.3/x86_64/ и задать соответствующие права:

На сервере 1С необходимо установить и настроить Kerberos для авторизации в домене. Установка выполняется командой apt install krb5-user (apt или не apt зависит от используемой операционной системы). Далее его необходимо сконфигурировать. В общем случае конфиг выглядит следующим образом:

Теперь можно проверить правильность сделанных настроек и попробовать авторизовать пользователя.

Результат

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

Команда должна выполниться без какого либо вывода и запросов. После этого команда klist дляжна отобразить полученный тикет пользователя:

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

Источник

1С, авторизация через AD

Задача: Настроить 1С сервер установленный на Linux таким образом, чтобы авторизация пользователей осуществлялась через контроллер домена, то есть доменный пользователь входя в 1С не должен ввводить пароль.

Имя домена: domainname.ru

NetBIOS имя домена: DNAM

IP контроллеров домена, они же DNS сервера: 172.16.1.16, 172.16.1.19

Сетевое имя одного из контроллеров домена: server-dc1

Сетевое имя сервера 1С: SERVER-1S

ОС сервера 1С: Debian GNU/Linux 7 (wheezy)

Версия сервера 1C: 8.3.5.1248

Все нижеследующее работает на «Debian GNU/Linux 8 (jessie)» + 1С версии 8.3.9.1850

1. Настраиваем DNS на сервере 1С:

в моем случае содержание resolv.conf следующее:

Имя сервера 1С должно быть вручную зарегистрировано на DNS сервере.

Ping должен выглядеть следующим образом:

2. Синхронизируем время на сервере 1С с контроллером домена.

3. Выясняем имя учетной записи от которой работает сервер 1С

4. На контроллере домена создаем учетную запись с паролем «1cv8password» и запрещаем смену пароля пользователем.

5. На контроллере домена выполняем следующую комманду

usr1cv8 — учетная запись от имени которой работает сервер 1С, а так-же учетная запись в AD

server-1s — сетевое имя узла, на котором запущен сервер 1С, можно выяснить командой hostname

1cv8password — пароль доменного пользователя usr1cv8

В результате должен сформироваться файл usr1cv8.keytab.

6. Полученный в предыдущем пункте файл, копируем в на сервер 1С в директорию /opt/1C/v8.3/x86_64/ и устанавливаем на него необходимые права:

7. На сервере 1С Устанавливаем базовый набор утилит для работы Kerberos аутентификацией

8. Настраиваем Kerberos.

В моем случае содержание файла следующее:

9. На сервере 1С выполняем:

результат должен быть следующим:

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

10. В 1С настраиваем параметры пользователя как на картинке (используем полное имя домена):

Источник

Как мы переходили на доменную авторизацию AD в 1С (двигаем SSO в компании)

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

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

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

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

CentOS 7 + Haproxy + Comodo SSL Wildcard

Windows Server 2016 + IIS + 1C

Опишу вкратце что и как взаимодействует, вся инфраструктура доменная (кроме unix подобных), сервер с 1С-на нем поднята только 1С, сама БД на SQL-ных серверах они нам не нужны сейчас. Все публикации работают по https. конечно есть и подключение сервер база (их мы тоже не будем рассматривать так как доменная авторизация в таком режиме работает сразу и без проблем. Значит клиент с доменным устройством Windows 10 вошел в систему с доменной учеткой запускает 1С в которой прописана ссылка на базу например https://1cbase.yourdomain.com, обращается в к haproxy, тот в свою очередь согласно правилам адресует его на нужный сервер с этой базой, далее IIS принимает соединение, подхватывает доменные учетные данные и передает их в 1С. Ниже схемка:

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

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

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

Haproxy, просто ставим с репозитория и корректируем конфиг, в моем случае сервис обслуживает не только 1С а и другие WEBы, по этому у меня настройка с 80 редиректор в 443, но для 1С в клиенте нужно писать сразу https так как клиент 1С не воспринимает редирект и прописав http вы просто никуда не попадете. Плюс который для меня важен в такой схеме что на моем маршрутизаторе открыт только 80 и 443 порты и на этом все, я не делаю для каждой БД другой порт и т.д., просто устанавливаешь в своей команде стандарт названия баз и передаешь в ТП что б они знали и могли прописать базу. хотя и это автоматизировано и у каждого сотрудника согласно должности свой список баз. Так вот ссылка всегда будет иметь нормальный для меня вид. например https://rt.yourdomain.com или https://ut.yourdomain.com или https://erp.yourdomain.com. Подняли haproxy (у меня HA-Proxy version 2.0.13) и добавляем конфиг

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

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

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

компоненты 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

И тут возвращаемся к IIS, тут уже будет публикация в 1С в сайте по умолчанию, но мы ее не трогаем пока что. это как эталон конфига. Делаем паку в C:\inetpub\wwwroot\, например rt.yourdomain.com, ну что б было все красиво и понятно тому, кто придет на этот сервер после нас или с нами. Добавляем новый веб-сайт (это, я думаю, понятно как) и заполняем:

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

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

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

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

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

IIS настроен, переходим к нашей новой публикации rt.yourdomain.com, для начала выставляем проверку подлинности:

Копируем конфиг публикации, то есть с наше стандартной публикации берем два файла default.vrd и web.config копируем в папку C:\inetpub\wwwroot\rt.yourdomain.com, отлично. Чуть поправим конфиг, буквально удалим в одно строчке символы, что б наши ссылки были короче и красивей. В файле default.vrd удаляем как на картинке и именно так. даже если что-то было после / мы это удаляем:

делаем так

Ну и по классике что б не было кракозябликов в 1С то правим настройку страницы ошибок для нашей публикации rt.yourdomain.com:

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

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

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

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

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

Источник