Cодержание

 

• 1 Введение
• 2 Как к этому пришли?
• 3 Полная инструкция по настройке доменной аутентификации 1C веб-сервера Apache на ОС Debian
  • 3.1 Подготовка окружения
  • 3.2 Настройка сервисной УЗ веба в Active Directory
  • 3.3 Установка 1C и Веб-сервера Apache
  • 3.4 Публикация базы на веб-клиент с поддержкой веб-сервисов на Apache с ОС Debian через webinst
  • 3.5 Настройка Веб-сервера Apache для поддержки аутентификации ОС
• 4 Заключение
• 5 Вопросы и ответы
• 6 Ссылки

 

Введение

Всем большой привет, Инфостарт!

В Magnit Tech в отделе Центра экспертизы 1C мы осуществляем проект по переводу информационных систем 1C с ОС Windows на ОС LInux. Так как для каждого дистрибутива Linux своя инструкция по настройке 1C веб-сервера Apache с поддержкой доменной аутентификации ОС, то мы решили, что будет правильно поделиться этими знаниями по многочисленным вопросам от участников прошлых конференций.

В нашем кейсе схема веб публикации базы: один веб-сервер - одна платформа. То есть через веб-клиент с 8.3.24 мы можем зайти только на базу с 8.3.24. Темы установки и настройки СП 1C, на котором будет опубликована база, мы не касались, поскольку подобных инструкций много, а инструкций по настройке доменной аутентификации на Веб-сервере с ОС Debian почти что и нет.

Наша цель: настроить доменную аутентификацию через SSO на Веб-сервере Apache 2.4 с ОС Debian 12, при 1C Платформе 8.3 с компонентой адаптера веб-клиента ws.

Краткое описание задачи: интеграция аутентификации ОС (Active Directory) в веб-клиент 1С через веб-сервер Apache 2.4 на ОС Debian 12.

Для чего это нужно: единый вход (SSO), повышение безопасности, удобство пользователей.

Основные технологии:

• Контроллер домена: Windows Active Directory

• Веб-сервер: 

  • ОС Debian 12
  • 1С:Предприятие (адаптер веб-клиента ws) 8.3.24.1624
  • Веб-сервер Apache 2.4.62
  • Модуль доменной аутентификации apache2: mod_auth_gssapi 1.6.4-3
• Сервер приложений 1C:
  • ОС Debian 11/12
  • 1C:Предприятие (СП) 8.3.24.1624

 

 

 

Как к этому пришли?

Мы долго бились с проблемой не рабочей доменной аутентификации ОС на веб-сервере Apache 2.4 Debian 11, так как инструкция с ИТС (2.8.1.3. Аутентификация операционной системы при использовании веб-сервера Apache - https://its.1c.ru/db/v8322doc/bookmark/adm/TI000000063) не давала результата.

Изначально, наш стэк технологий был:

• Контроллер домена: Windows Active Directory

• Веб-сервер:

  • ОС Debian 11
  • 1С:Предприятие (адаптер веб-клиента ws) 8.3.22.1851
  • Веб-сервер Apache 2.4.62
  • Модуль доменной аутентификации apache2: mod_auth_gssapi 1.6.3
• Сервер приложений 1C:
  • ОС Debian 11
  • 1C:Предприятие (СП) 8.3.22.1851

В ходе переписки с представителями 1C мы узнали, что есть доп подводные камни, например:

• Полной официальной документации для настройки Apache для аутентификации ОС при входе в 1С с использованием gssapi нет.
• Была найдена ранее зарегистрированная и уже исправленная ошибка '60008315' препятствующая аутентификации на платформе до 8.3.22.2208.
• Для браузера клиента требуется выполнять настройку согласно инструкции (Глава 9. Настройка веб-браузеров для работы в веб-клиенте (1c.ru))
• Для изучения логов требуется собирать ТЖ при входе веб-клиентом (из браузера), тонким клиентом через веб-публикацию и тонким клиентом при прямом подключении.

Эти рекомендации тоже не давали результата.
При изучении логов мы упирались в сообщения об постоянном подключении без результата. 

В какой-то момент наш коллега из отдела cопровождения 1С решил, что надо самому поиграться с настройкой, и тут мы наконец получили результат!

Проблема была в версии ОС Debian 11 для веб-сервера, а именно пакет модуля доменной аутентификации apache2 mod_auth_gssapi 1.6.3 не давал работать аутентификации ОС согласно инструкции (ИТС). Только версия модуля 1.6.4-3 решила проблему. Тем самым решением было обновление ОС веб-сервера до Debian 12, чтобы доменная аутентификация начала работать.

В итоге мы пришли к тому стеку технологий, который указан в самом начале.

 

Полная инструкция по настройке доменной аутентификации 1C веб-сервера Apache на ОС Debian

Подготовка окружения

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

• Требования для Веб-сервера:
  • ОС Debian 12.
  • Доступ к контроллеру домена Active Directory.
• Требования для СП:
  • Заведена служебная УЗ СП в Active Directory.
  • ОС Debian 11 - 12.
  • Установленная 1C Платформа 8.3.24.1624 с компонентами server, server_admin, additional_admin_functions.
  • Выпущенный для него Keytab файл.
  • Доступ к контроллеру домена Active Directory.

 

Настройка сервисной УЗ веба в Active Directory

Настройка привязанных SPN

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

 

 

Помимо этого требуется еще и настройка доступа к веб-серверу (обратитесь к своим коллегам предоставляющим ВМ).

 

Установка 1C и Веб-сервера Apache

1.  Устанавливаем 1C Платформу только с компонентой адаптера веб-клиента

Качаем с официального сайта программу установщик 1C Платформы 8.3.24.1624,

Ссылка на программу установщик: https://releases.1c.ru/project/Platform83.

8.3.24.1624 → Linux (x64) → Технологическая платформа 1С:Предприятия (64-bit) для Linux → Скачать дистрибутив

Далее распаковываем и перекидываем файл setup-full-8.3.24.1624-x86_64.run на веб-сервер

Запускаем установку:

./setup-full-8.3.24.1624-x86_64.run --mode unattended --disable-components client_full --enable-components ws

Примечание 1:

Как видно из программы установщика мы используем версию 1C платформы 8.3.24.1624, архитектура сервера x86-64, устанавливаем только нужную нам компоненту адаптера веб-клиента - ws, строго указывая, что нам не требуется полный клиент - client_full.

Примечание 2:

В качестве инструкции ИТС предлагает краткий обзор вариантов установки 1C Платформы под ОС Linux с обзором компонентов.
Чтобы стало возможным сделать публикацию веб-клиента надо установить компоненту ws. В качестве способа установки предлагается 2 варианта - через программу установщик или через Deb-пакеты. Выбор способа установки далее повлияет на способ удаления платформы, поэтому мы рекомендуем вариант с программой установщиком, где достаточно указать необходимые флаги с аргументами.

Главная::Инструкции по разработке на::1С Платформа::1С:Предприятие. Документация::Платформа 1С:Предприятие 8.3.24::Клиент-серверный вариант. Руководство администратора::Глава 3. Установка компонентов системы::3.1.3. Установка в ОС Linux -  https://its.1c.ru/db/v8324doc/bookmark/cs/TI000000292

ws - адаптер для публикации веб-клиента и Интернет-сервисов «1С:Предприятия» на веб-сервере Apache HTTP Server (поддерживаемых версий)

 

2. Устанавливаем веб-сервер apache версии 2.4.62 или выше

sudo apt install apache2

3. Устанавливаем модуль аутентификации apache2: libapache2-mod-auth-gssapi

sudo apt install libapache2-mod-auth-gssapi

4. Добавляем поддержку SSL-сертификатов

Включаем модули для работы с SSL

sudo a2enmod ssl sudo a2enmod headers sudo a2enmod rewrite

Полученный файл сертификата для сервера и приватный ключ помещаем в созданный нами в каталог Apache:

sudo mkdir /etc/apache2/ssl && chmod 755 /etc/apache2/ssl sudo cp ~/<ДОМЕННОЕ ИМЯ ВЕБ-СЕРВЕРА>.cer /etc/apache2/ssl/<ДОМЕННОЕ ИМЯ ВЕБ-СЕРВЕРА>.cer && sudo cp ~/private.key /etc/apache2/ssl/private.key && sudo chmod 755 /etc/apache2/ssl/*

Прописываем пути в конфигурационном файле:

sudo nano /etc/apache2/sites-enabled/default.conf

SSLCertificateFile    /etc/apache2/ssl/<ДОМЕННОЕ ИМЯ ВЕБ-СЕРВЕРА>.cer SSLCertificateKeyFile /etc/apache2/ssl/private.key

 

 

5. Перезапустить службу, чтобы настройки веб-сервера вступили в силу

sudo systemctl restart apache2

В итоге получили подобный вывод при заходе на веб-сервер через браузер по ссылке https://<ДОМЕННОЕ ИМЯ ВЕБ-СЕРВЕРА>.your.corp.ru/:

 

 

Ура у нас есть Веб-сервер apache2 с поддержкой SSL-сертификатов и 1C платформой с адаптером для публикации веб-клиента!

Далее остается дело за малым:

1) Сделать веб-публикацию базы с поддержкой веб-сервисов

2) Настроить доменную аутентификацию на веб-сервере Apache с ОС Debian 12

 

Публикация базы на веб-клиент с поддержкой веб-сервисов на Apache с ОС Debian через webinst

Для создания веб-публикаций от 1С предоставляется утилита webinst. Она позволяет публиковать базу под apache, но без поддержки веб-сервисов. Чтобы она выполняла публикацию с поддержкой веб-сервисов потребуется применять вместе с ней файл-шаблон (apache-template.vrd), который создается через 1C Конфигуратор.

1. Создаем файл-шаблон (apache-tamplate.vrd) публикации через 1C Конфигуратор

Заходим в 1C Конфигуратор сервера СП и выбираем вкладку "Администрирование" → "Публикация на веб-сервере"

 

 

Указываем флаг "Публиковать Web-сервисы" и выбираем параметры публикуемых Web-сервисов
Нажимаем кнопку сохранить и указываем имя файла "apache-template".

 

 

Таким образом, мы получили файл-шаблон apache-template.vrd, который позволит нам добавить поддержку Web-сервисов к веб-клиенту на Apache.
 

Примечание 1:

По поводу публикации базы для веб-клиента с поддержкой веб-сервисов есть много инструкций на ИТС для Apache, поскольку он кроссплатформенный (Windows и Linux), структура и конфигурация в основном схожа.
Вот полезные ссылки c ИТС по публикации базы на веб-клиент с поддержкой веб-сервисов для платформы 8.3.24:

• Главная::Инструкции по разработке на 1С Платформа::1С:Предприятие. Документация::Платформа 1С:Предприятие 8.3.24::Руководство администратора::8.5 Настройка поддержки Web-сервисов::8.5.2 Для ОС Linux::8.5.2.4 Apache версии 2.4::8.5.2.4.2. Утилита webinst - https://its.1c.ru/db/v8324doc/bookmark/adm/TI00000063
• Главная::Инструкции по разработке на 1С Платформа::1С:Предприятие. Документация::Платформа 1С:Предприятие 8.3.24::Руководство администратора::8.3.1. Общая схема публикации - https://its.1c.ru/db/v8324doc/bookmark/adm/TI000000525

Для публикации базы на веб-клиент с поддержкой веб-сервисов требуется использовать утилиту webinst (стандартная и входит в каждую платформу с веб-компонентой)

Сам по себе webinst для Apache позволяет создать default.vrd файл публикации только для веб-клиента без поддержки веб-сервисов.
Чтобы была включена поддержка веб-сервисов необходимо вручную создать файл-шаблон apache-template.vrd через конфигуратор 1C.

Для выполнения публикации из конфигуратора - создания файла-шаблона, необходимо воспользоваться диалогом публикации (Администрирование -> Публикация на веб-сервере…) (ссылка).

Далее можно его использовать для публикации/удаления баз:

Пример:

webinst -publish -apache24 -wsdir demo-ws -dir /var/www/demo-ws -connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-template.vrd

 

2. Теперь создаем публикацию базы через утилиту webinst на веб-сервере

Примечание 1:

Публикация базы с поддержкой веб-сервисов:

/opt/1cv8/x86_64/8.3.24.1624/webinst -publish -apache24 -wsdir base_wc -dir /var/www/1C/base -connstr "Srvr=v00serv1c01lnx;Ref=base" -descriptor <path>/apache-template.vrd -confpath /etc/apache2/apache2.conf

(Альтернатива)

Публикация базы без поддержки веб-сервисов, то есть без файла-шаблона:

/opt/1cv8/x86_64/8.3.24.1624/webinst -publish -apache24 -wsdir base_wc -dir /var/www/1C/base -connstr "Srvr=v00serv1c01lnx;Ref=base" -confpath /etc/apache2/apache2.conf

(Если потребуется)
Удаление публикации:

/opt/1cv8/x86_64/8.3.24.1624/webinst -delete -apache24 -wsdir base_wc -dir /var/www/1C/base -connstr "Srvr=v00serv1c01lnx;Ref=base" -confpath /etc/apache2/apache2.conf

-publish - флаг публикации по-умолчанию
-delete - флаг удаления публикации
-apache24 - версия веб-сервера (apache2, apache22 или iis)
-dir - имя физического каталога, куда будет отображен виртуальный каталог веб-сервера. Каталог должен существовать.
-descriptor - позволяет выполнить публикацию по шаблону, заданному существующим файлом, который задается в данном параметре (включая путь к файлу). Имя файла-шаблона не обязательно должно быть default.vrd. При выполнении публикации существующий файл default.vrd полностью замещается файлом-шаблоном. Если одновременно с данным параметром указаны параметры -wsdir или -connstr, то значения этих    параметров замещают собой значения атрибутов base и ib (соответственно) элемента point.

-wsdir - alias в описании виртуального хоста в конфиге веб-сервера apache2, например, в apache2.conf в строке 'Alias "/base_wc" "/base"' и значение параметра 'base=' в новом vrd файле '/var/www/base/default.vrd', например, в default.vrd будет следующая подстрока 'base="/base_wc"'
-connstr - основная информация для подключения базы в default.vrd, например, "Srvr=v00serv1c01lnx;Ref=base", где 'Srvr=' указывает на СП 1C (можно и по IP), 'Ref=' указывает на базу
-confpath - файл в котором будет произведено добавление публикации после тэга </Directory> или на следующую строку/удаление публикации с идентичным именем физического и виртуального каталога базы
Флаг включающий аутентификацию через ОС -osauth работает только для IIS веб-сервера

Примечание 2:

• После удаления публикации не удаляются vrd файлы и физические каталоги, например, /var/www/1C/base, куда должен быть отражен виртуальный каталог веб-сервера. Поэтому чистка каталогов тоже выполняется в ручную. Например, полное удаление будет включать rm -rf /var/www/1C/base
• Хорошим тоном будет заведение отдельного пути для физических каталогов публикаций баз, например /var/www/1C/*
• Если имя базы содержит пробелы, то заключаем в бинарные кавычки дополнительно (""), если содержит сам символ ", то вместо "" для выделения текста можно использовать ординарные кавычки (').

 

Выполнение публикации на веб-сервер с поддержкой веб-сервисов:

 

 

После того как выполнили публикацию базы с поддержкой Web-сервисов получили следующие папки и конфиги:

В /etc/apache2/apache2.conf добавился блок с публикацией базы:

 

 

Появился физический каталог /var/www/1C/ad_test_2_wc и файл default.vrd:

 

 

 

В результате имеем следующий вариант работы веб-клиента с поддержкой веб-сервисов без работы аутентификации ОС:

Проверка работы веб-клиента https://<ДОМЕННОЕ ИМЯ ВЕБ-СЕРВЕРА>/<ВИРТУАЛЬНЫЙ КАТАЛОГ>

 

 

 

Проверка работы Web-сервиса Exchange через браузер по ссылке типа https://<ДОМЕННОЕ ИМЯ ВЕБ-СЕРВЕРА>/<ВИРТУАЛЬНЫЙ КАТАЛОГ>/ws/Exchange?wsdl

 

 

Гип-гип ура! Публикация прошла успешно! Веб-клиент работает и поддерживает веб-сервисы.

А теперь самое интересное.

 

Настройка Веб-сервера Apache для поддержки аутентификации ОС

Вот именно тут многие отпадают)

Чтобы мы имели доступ к СП, нам требуется иметь:

• Заведенную сервисную УЗ веба с привязанными к ней ее SPN.

• Установленный Apache 2.4.62

• 1С Платформа 8.3.24.1624 только с компонентой адаптера веб-клиента ws.

Чтобы иметь доменную аутентификацию ОС на веб-сервере Apache 2.4.62 на ОС Debian 12 нам дополнительно требуется:

1. Настроенное делегирование указанных служб СП у сервисной УЗ веба в Active Directory
2. (Опционально) Включенная поддержка 256-разрядного типа шифрования у сервисной УЗ в Active Directory
3. Выпущенный Keytab файл для сервисной УЗ веба, где будет указан его принципал
4. Настроенный конфиг /etc/krb5
5. Установленная библиотека libapache2-mod-auth-gssapi 1.6.4-3
6. Виртуальный каталог публикации базы в конфиге /etc/apache2/apache2.conf с добавленными директивами модуля libapache2-mod-auth-gssapi 

Примечание 1:

• Во первых требуется установить apache2, библиотеку для доменной аутентификации, чтобы работать с протоколом Kerberos
• В файле /etc/krb5 должен быть указан REALM компании, который будет указывать на контроллер домена, например, YOUR.CORP.RU

Поехали по пунктам!

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

При настройке доменной сервисной учетной записи веб-клиента нам требуется в настройках Делегирование → Поставить флаг Доверять этому пользователю делегирование указанных служб → Поставить флаг только Kerberos → Добавить принципал сервера СП по имени службы СП, например, по имени svc_sp1clnx, к базе которого необходимо иметь доступ.

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

 

 

Пример работы без настройки делегирования:

 

 

 

 

2. (ОПЦИОНАЛЬНО) Настройка поддерживаемых типов шифрования

Keytab файл будет содержать принципалы с паролем от УЗ веба, поэтому, стоит подумать и об защите с помощью шифрования.

В зависимости от ваших требований ИБ потребуется, чтобы Windows администратор указал для УЗ поддержку вашего типа шифрования, например, поставил флаг на поддержку 256-разрядного типа.

Зайти в свойства УЗ <ИМЯ УЗ ВЕБА> -> Учетная запись -> Параметры учетной записи Включить опцию:

Данная учетная запись поддерживает 256-разрядное.

 

 

3. Создание Keytab файла и его размещение

Keytab файл хранит таблицу ключей и principal.

От того, какой тип шифрования и какой пароль от доменной сервисной УЗ мы укажем, зависит работа доменной аутентификации (работоспособность Keytab).

Keytab стоит размещать в тот путь, где к нему будет иметь доступ пользователь, от имени которого работает веб-сервер www-data в путь /etc/apache2/HTTP.keytab. Также требуется выдать все права (чтение, запись) для пользователя владельца www-data и убрать все права для остальных пользователей.

Примечание 1:

• В случае смены пароля от УЗ потребуется менять Keytab тоже. Так что согласуйте создание Keytab
• Для записи с ktutil не так важен KVNO (Key Version Number), тем не менее лучше его ставить таким как на сервере
• Лучше сделать защищенные типы шифрования для principal, например, AES-256
• От типа шифрования который указан в для principal в Keytab и списка поддерживаемых типов шифрования для УЗ в Active Directory зависит будет ли Keytab рабочим.

Есть два способа выпустить Keytab файл:

Создание Keytab через ktpass (Windows)/ Создание Keytab через ktutil (Linux)

 

Создание Keytab через ktpass (Windows):

Создать файл можно, попросив вашего Windows админа прописать команды в контроллере домена:

На каком контроллере домена выписываем keytab – тот и будет KDC

1) Для начала зададим атрибут servicePrincipalName. Действие необязательное, так как далее утилита KTPASS сама это сделает, но рекомендуемое

SETSPN -S HTTP/<ДОМЕННОЕ ИМЯ СЕРВЕРА 1>your.corp.ru@YOUR.CORP.RU <ИМЯ УЗ ВЕБА> SETSPN -S HTTP/<ДОМЕННОЕ ИМЯ СЕРВЕРА 2>your.corp.ru@YOUR.CORP.RU <ИМЯ УЗ ВЕБА>

Данный SPN указывает, что под учетной записью <ИМЯ УЗ ВЕБА> может быть запущен веб-сервер HTTP на машинах с FQDN <ДОМЕННОЕ ИМЯ СЕРВЕРА 1>your..corp.ru, <ДОМЕННОЕ ИМЯ СЕРВЕРА 2>your.corp.ru

2)  Формируем keytab файл

KTPASS -princ HTTP/<ДОМЕННОЕ ИМЯ СЕРВЕРА 1>your.corp.ru@YOUR.CORP.RU -mapuser <ИМЯ УЗ ВЕБА>@YOUR.CORP.RU -pass !!!!PASSWORD!!!! -setpass -ptype KRB5_NT_PRINCIPAL -out C:\<ИМЯ KEYTAB 1>.keytab

   -mapuser - указывается имя учётной записи, к которой будет привязываться принципал сервиса.

   -princ - указывается имя принципала сервиса, который мы собираемся привязывать, и для которого будет сформирована keytab-запись.

   -ptype - указывается тип принципала.

   -pass - задаётся пароль сразу и для учётной записи, и для формирования ключа в keytab-записи с использованием нужного алгоритма шифрования.

   -out - указан keytab-файл

   -setpass - не переназначаем пароль для УЗ (чтобы не повышать KVNO)

3) Если нужно выписать keytab для двух и более принципалов сервиса

KTPASS -princ HTTP/<ДОМЕННОЕ ИМЯ СЕРВЕРА 1>your.corp.ru@YOUR.CORP.RU -mapuser <ИМЯ УЗ ВЕБА>@YOUR.CORP.RU -pass !!!!PASSWORD!!!! -setpass /kvno 3 -ptype KRB5_NT_PRINCIPAL -in C:\<ИМЯ KEYTAB 1>.keytab -out C:\<ИМЯ KEYTAB 2>.keytab -setupn

   -mapuser - указывается имя учётной записи, к которой будет привязываться принципал сервиса.

   -princ - указывается имя принципала сервиса, который мы собираемся привязывать, и для которого будет сформирована keytab-запись.

   -ptype - указывается тип принципала.

   -pass - задаётся пароль сразу и для учётной записи, и для формирования ключа в keytab-записи с использованием нужного алгоритма шифрования.

   -setpass - не переназначаем пароль для УЗ (чтобы не повышать KVNO - это важно). Если KVNO изменится - все кейтабы с отличными значениями KVNO будут недействительны. Таким образом, пароль из аргумента -pass будет использован только для создания keytab-записи

   -kvno - явно указываем номер KVNO. Должен быть такой же, как на предыдущем шаге. Его значение можно посмотреть в выводе команды на предыдущем шаге.

   -in - указывается файл, из которого необходимо импортировать уже имеющиеся keytab-записи (keytab-файл, созданный на предыдущем шаге)

   -out - указан итоговый keytab-файл

      -setupn - указывается, что переназначать имя принципала пользователя учётной записи не требуется

Помещаем Keytab на веб-сервер cp ~/bmc1.keytab /etc/apache2/HTTP.keytab

 

Создание Keytab через ktutil (Linux)

Альтернативный вариант создать Keytab лично на сервере Linux, но есть нюанс так как для создания потребуется пароль от сервисной УЗ веб-клиента, поэтому проконсультируйтесь заранее с вашим сотрудником ИБ и с владельцем.

После зайдите на веб-сервер, который привязан к доменной УЗ веба, например, <ИМЯ УЗ ВЕБА>, и вводите команды по очереди:

ktutil addent -password -p HTTP/<ДОМЕННОЕ ИМЯ ВЕБ-СЕРВЕРА>your.corp.ru@YOUR.CORP.RU -k 3 -e aes256-cts-hmac-sha1-96 -f <вводим пароль от сервисной УЗ веба> wkt /etc/apache2/HTTP.keytab quit

Примечание 1:

• -p указывает на SPN привязанный к доменной УЗ
• -k указывает на номер версии ключа KVNO (Key Version Number)
  -e указывает на тип шифрования. Требуется знать какой тип поддерживает доменная УЗ. Если 256 или 128 разрядный, то требуется запросить у вашего Windows админа информацию по поддерживаемым типам шифрования доменной УЗ

• -f - обязательный флаг

• wkt <путь к keytab> - создать keytab файл

Произвести проверку Keytab

• посмотреть список principals в keytab с KVNO и типом шифрования: klist -e -k -t /etc/apache2/HTTP.keytab
• получить билеты с помощью keytab по principal: kinit -Vk -t /etc/apache2/HTTP.keytab HTTP/<ДОМЕННОЕ ИМЯ ВЕБ-СЕРВЕРА>your.corp.ru@YOUR.CORP.RU
• просмотреть список полученных билетов: klist -e
• удалить полученные билеты: kdestroy

Примечание 2:

• Надо, чтобы в ней предварительно был заведен пользователь с корпоративным доменом.
• Окончательной проверкой является попытка входа через веб-клиент в базу.

 

На выпушенный Keytab выдаем права

sudo chown www-data:www-data /etc/apache2/HTTP.keytab sudo chmod 600 /etc/apache2/HTTP.keytab

4. Настройка Kerberos (для Active Directory)

Конфигурация /etc/krb5.conf должна содержать следующие строки:

[libdefaults]     default_realm = YOUR.CORP.RU     default_keytab_name =  /etc/apache2/HTTP.keytab     default_client_keytab_name = /etc/apache2/HTTP.keytab     dns_lookup_kdc = true     dns_lookup_realm = true     forwardable = true     ticket_lifetime = 24h     renew_lifetime = 7d   [domain_realm]     .your.corp.ru = YOUR.CORP.RU     your.corp.ru = YOUR.CORP.RU     .YOUR.CORP.RU = YOUR.CORP.RU     YOUR.CORP.RU = YOUR.CORP.RU

5. Установка модуля доменной аутентификации Kerberos для apache2: libapache2-mod-auth-gssapi 1.6.4-3
Выполнили еще в самом начале установки веб-сервера)

6. Добавляем в виртуальный каталог публикации базы в /etc/apache2/apache2.conf необходимые директивы модуля для поддержки работы аутентификации ОС

Примечание 1:

• Начиная с версии ОС Debain 11 пакет mod_auth_kerb больше не доступен в репозитории, но именно его демонстрируют в инструкции с ИТС (тут), а в качестве замены для Apache предлагается любой схожий модуль, например, libapache2-mod-auth-gssapi.
• Чтобы выполнить настройку виртуального окружения на свой вкус вот ссылка на официальный README.md из GitHub репозитория проекта libapache2-mod-auth-gssapi.
• Описание стандартных директив Apache можно прочитать здесь - https://httpd.apache.org/docs/2.4/mod/quickreference.html

Как было:

 

Как должно стать:

 

Примечание 2:

Настройка виртуального окружения для копирования:

# 1c publication Alias "/base_wc" "/var/www/1C/base/" <Directory "/var/www/1C/base/">    AuthType GSSAPI    AuthName "Kerberos Login"    Require valid-user      GssapiCredStore keytab:/etc/apache2/HTTP.keytab    GssapiCredStore client_keytab:/etc/apache2/HTTP.keytab    GssapiCredStore ccache:FILE:/var/krb/ktk123    GssapiUseS4U2Proxy On    GssapiImpersonate On    GssapiLocalName On    GssapiDelegCcacheDir /var/cred/      AllowOverride All    Options SymLinksIfOwnerMatch    Require valid-user    SetHandler 1c-application      ManagedApplicationDescriptor "/var/www/1C/base/default.vrd" </Directory>

 

Выполняем перезапуск apache2, чтобы настройки вступили в силу

systemctl restart apache2

Проверяем, что доменная аутентификация ОС работает:

 

 

Наконец-то! Теперь наши пользователи могут использовать как тонкий клиент, так и веб-клиент, так и вариант через тонкий клиент по веб-публикации с аутентификацией ОС.

Поздравляю! Теперь мы можем использовать стандартные механизмы 1C для этой настройки без использования сторонних решений типа KeyCloak.

Самое главное, что мы поняли основные причины проблем при настройке аутентификации ОС на веб-сервере Aapache:

• неправильная настройка УЗ веба в Active Directory, то есть делегирование служб СП
• неправильно выпущенный Keytab файл
• нерабочая версия модуля аутентификации через протокол Kerberos под ОС Debian - libapache2-mod-auth-gssapi < 1.6.4-3
• неверно подключенные директивы модуля аутентификации в конфиге apache2
• неверно выполненная публикация на Apache через webinst без поддержки Web-сервисов

 

Заключение

Итого: нам удалось сделать интеграцию аутентификации ОС (Active Directory) в веб-клиент 1С через веб-сервер Apache 2.4.62 на ОС Debian 12.

Что мы из этого получили?

Теперь можно предлагать пользователям информационных систем 1C использовать веб-клиент в браузере, если будут проблемы по запуску приложения Платформы, например, при использовании в качестве клиента ОС MacOS.

Через строку публикации мы можем получать доступ к Web-сервисам, что несомненно потребуется при интеграции 1C с другими системами.

Также аутентификация ОС позволяет нам усилить защиту, чтобы не светить логином и паролем при каждом входе. Пользователи также скажут спасибо за то, что нет лишних вводов данных: один вход (Single Sing On) через ОС и все.

Надеемся, что данная инструкция сэкономит вам и вашей компании драгоценное время)

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

В конце стандартная глава вопросы и ответы, где можно найти ответ на популярный вопрос.

 

Вопросы и ответы

 

Вопрос: А можно ли развернуть несколько публикаций баз с разными версиями 1C Платформы?

Ответ:

В общем, поискав в интернете, узнал, почему же в Apache я не могу подключить несколько модулей _1сws_module для одного сервера apache2

Дело в том, что модули хранятся в .so файлах (C динамические библиотеки). В них указывается структура, имя которой и есть имя модуля - _1cws_module. И знаете в чем весь прикол? Директива ManagedApplicationDescriptor одна на все модули, то есть даже при разных именах модулей мы бы не смогли использовать на одном apache сервере несколько модулей из разных платформ. Было бы круто-если бы в других версиях это учли и добавили бы разные имена директив и модулей под apache, а так только несколько служб apache2 под разными портами под каждую платформу. Как вариант: хоть через Docker контейнеры, хоть рассматривать внедрение nginx для изменения портов.

Вопрос: Работают ли схемы, где СП с ОС Windows, а веб-сервер с ОС Linux?

Ответ:

Да, наш главный специалист сопровождения 1C проверял. Эта схема тоже работает.

Вопрос: Где мне узнать что делает каждая директива модуля mod-auth-gssapi для настройки?

Ответ:

Очень просто - через официальный репозиторий проекта libapache2-mod-auth-gssapi в их README.md файле: https://github.com/gssapi/mod_auth_gssapi?tab=readme-ov-file. Описание полностью на английском языке.

Вопрос: Можно ли как-то автоматизировать процесс публикации с поддержкой Web-сервисов и с поддержкой аутентификации ОС?

Ответ:

Да, это можно легко реализовать с помощью Ansible. Так как webinst входит в поставку, то будет достаточно делать его вызов для публикации базы, а после подставлять директивы в виртуальный каталог публикации в /etc/apache2/apache2.conf через регулярное выражение. Проверкой того что это именно та публикация в конфиге будут выступать строки Alias .. и <Directory ..>, </Directory>. Сам webinst будет удалять публикацию именно по этим строкам в конфигурации apache2. Чтобы не плодить лишние папки и vrd можно также при удалении добавить вызов удаления физического каталога после вызова webinst -delete.

Вопрос: Если я запущу утилиту публикации webinst другой версии, то будут проблемы?

Ответ:

Да, так как webinst добавит в конфигурацию apache2 директиву загрузки модуля адаптера веб-клиента LoadModule _1cws_module определенной версии 1C Платформы из-за чего будет конфликт версий, при попытке войти в базу.
 

Ссылки

1C ИТС 8.3.24 "..3.1.3. Установка в ОС Linux" -  https://its.1c.ru/db/v8324doc/bookmark/cs/TI000000292

1С ИТС 8.3.24 "..2.8.1.3. Аутентификация операционной системы при использовании веб-сервера Apache" -  https://its.1c.ru/db/v8324doc/bookmark/adm/TI000000063

1C ИТС 8.3.24 "..8.5. Настройка поддержки Web-сервисов::8.5.2. Для ОС Linux::8.5.2.4. Apache версии 2.4" - https://its.1c.ru/db/v8324doc/bookmark/adm/TI000000635

1C ИТС 8.3.24 "..8.3.1. Общая схема публикации" - https://its.1c.ru/db/v8324doc/bookmark/adm/TI000000525

1C ИТС 8.3.24 "..8.5 Настройка поддержки Web-сервисов::8.5.2 Для ОС Linux::8.5.2.4 Apache версии 2.4::8.5.2.4.2. Утилита webinst" - https://its.1c.ru/db/v8324doc/bookmark/adm/TI000000637

GitHub репозиторий модуля libapache2-mod-auth-gssapi - https://github.com/gssapi/mod_auth_gssapi?tab=readme-ov-file

APACHE "Directive Quick Reference" - https://httpd.apache.org/docs/2.4/mod/quickreference.html

1C ИТС 8.3.24 "..Глава 9. Настройка веб-браузеров для работы в веб-клиенте" - https://its.1c.ru/db/v8324doc/bookmark/adm/TI000000250