Как стать автором
Обновить

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

Время на прочтение4 мин
Количество просмотров33K

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

Данный кейс с реальной практики, проект начался в начале 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) и добавляем конфиг

frontend http
        bind :80
        default_backend redirect-backend
        
frontend https
        mode http
        option tcplog
        bind *:443 ssl crt /etc/ssl/certs/yourcomodossl.pem                                                                                                                                                            /md-group.kz.pem no-tls-tickets
        acl rt hdr_beg(host) rt.yourdomain.com
backend redirect-backend
        redirect scheme https
backend rt_db_server
        balance roundrobin
        server rt_db_srv01 192.168.1.46:80 check inter 4000 weight 10

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

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

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

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

Setspn /s HTTP/rt yourdomain\iis_service
Setspn /s HTTP/rt.yourdomain.com yourdomain\iis_service

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

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

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

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

Теги:
Хабы:
Всего голосов 5: ↑3 и ↓2+3
Комментарии18

Публикации

Истории

Работа

Консультант 1С
100 вакансий
DevOps инженер
33 вакансии
Программист 1С
72 вакансии
Аналитик 1С
5 вакансий

Ближайшие события