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

Введение

Сразу отмечу, что в качестве Веб-интерфейса я использую OpenSearch-Dashboards. И в основном именно для OpenSearch-Dashboards мне нужна доменная авторизация.

Для того, чтобы настроить аутентификацию и авторизацию доменных пользователей Active Directory в OpenSearch по протоколу LDAP необходимо сконфигурировать файл «/plugins/opensearch-security/securityconfig/config.yml» (в моем случае полный путь к этому файлу такой «/opt/opensearch/plugins/opensearch-security/securityconfig/config.yml»).

Почему двухфакторная аутентификация в домене по токену с pin-кодом безопаснее обычной парольной схемы?

PIN-код привязан к определенному устройству, в нашем случае к токену. Знание PIN-кода само по себе ничего не дает.

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

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

Токен является уникальным некопируемым физическим объектом. Им обладает легитимный пользователь. Двухфакторную аутентификацию по токену можно обойти только тогда, когда администратор намеренно или по недосмотру оставил для этого «лазейки» в системе.

Предисловие

Эта статья является продолжением статьи

. Однако, тема этой статьи достаточно узкая и практически не зависит от основной настройки всего стека OpenSearch (материала первой статьи). Поэтому эту статью можно считать самостоятельной.

. Послесловие

На этом всё. Всем спасибо за внимание к статье, надеюсь она окажется для кого-то полезной.

Коротко об объектах настройки конфиденциальности в OpenSearch

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

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

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

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

А вот «Backend» роль сущность несколько абстрактная. «Обычная» роль может иметь «Backend» роль или даже несколько «Backend» ролей. Пользователь тоже может иметь «Backend» роль или даже несколько «Backend» ролей. Если «Backend» роль есть у пользователя, и эта же «Backend» роль есть у «обычной» роли, то такой пользователь становится обладателем этой «обычной» роли.

«Backend» роли становятся актуальными для использования при доменной авторизации. Потому как доменные пользователи не доступны для настройки прав или «обычных» ролей, они могут получить только «Backend» роль автоматически, в зависимости от настроенной конфигурации.

Настройка LDAP

Для наглядности я сразу приведу уже сконфигурированный файл «config.yml» целиком (в моем случае это файл «/opt/opensearch/plugins/opensearch-security/securityconfig/config.yml»).

---
# This is the main OpenSearch Security configuration file where authentication
# and authorization is defined.

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    # Set filtered_alias_mode to 'disallow' to forbid more than 2 filtered aliases per index
    # Set filtered_alias_mode to 'warn' to allow more than 2 filtered aliases per index but warns about it (default)
    # Set filtered_alias_mode to 'nowarn' to allow more than 2 filtered aliases per index silently
    #filtered_alias_mode: warn
    #do_not_fail_on_forbidden: false
    #kibana:
    # Kibana multitenancy
    #multitenancy_enabled: true
    #server_username: kibanaserver
    #index: '.kibana'
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: '192.168.0.10|192.168.0.11' # regex pattern
        #internalProxies: '.*' # trust all internal proxies, regex pattern
        #remoteIpHeader:  'x-forwarded-for'
        ###### see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help
        ###### more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For
        ###### and here https://tools.ietf.org/html/rfc7239
        ###### and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve
    authc:
      kerberos_auth_domain:
        http_enabled: false
        transport_enabled: false
        order: 6
        http_authenticator:
          type: kerberos
          challenge: true
          config:
            # If true a lot of kerberos/security related debugging output will be logged to standard out
            krb_debug: false
            # If true then the realm will be stripped from the user name
            strip_realm_from_principal: true
        authentication_backend:
          type: noop
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 4
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      proxy_auth_domain:
        description: "Authenticate via proxy"
        http_enabled: false
        transport_enabled: false
        order: 3
        http_authenticator:
          type: proxy
          challenge: false
          config:
            user_header: "x-proxy-user"
            roles_header: "x-proxy-roles"
        authentication_backend:
          type: noop
      jwt_auth_domain:
        description: "Authenticate via Json Web Token"
        http_enabled: false
        transport_enabled: false
        order: 0
        http_authenticator:
          type: jwt
          challenge: false
          config:
            signing_key: "base64 encoded HMAC key or public RSA/ECDSA pem key"
            jwt_header: "Authorization"
            jwt_url_parameter: null
            roles_key: null
            subject_key: null
        authentication_backend:
          type: noop
      clientcert_auth_domain:
        description: "Authenticate via SSL client certificates"
        http_enabled: false
        transport_enabled: false
        order: 2
        http_authenticator:
          type: clientcert
          config:
            username_attribute: cn #optional, if omitted DN becomes username
          challenge: false
        authentication_backend:
          type: noop
      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: false
        order: 5
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          # LDAP authentication backend (authenticate users against a LDAP or Active Directory)
          type: ldap
          config:
            # enable ldaps
            enable_ssl: false
            # enable start tls, enable_ssl should be false
            enable_start_tls: false
            # send client certificate
            enable_ssl_client_auth: false
            # verify ldap hostname
            verify_hostnames: true
            hosts:
            - server-ad.my.big.domain:389
            bind_dn: 'cn=user_for_LDAP,ou=Service Accounts,ou=Moscow,dc=MY,dc=BIG,dc=DOMAIN'
            password: 'Au5dUJ9q!54S'
            users:
              1-userbase:
                base: 'CN=Пушкин Александр Сергеевич (PushkinAS),OU=Users,OU=Saint_Petersburg,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
              2-userbase:
                base: 'CN=Горький Максим (GorkiiM),OU=Users,OU=Nizhny_Novgorod,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
              3-userbase:
                base: 'CN=Толстой Лев Николаевич (TolstoiLN),OU=Users,OU=Yasnaya_Polyana,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
            username_attribute: 'cn'
    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: false
        authorization_backend:
          # LDAP authorization backend (gather roles from a LDAP or Active Directory, you have to configure the above LDAP authentication backend settings too)
          type: ldap
          config:
            # enable ldaps
            enable_ssl: false
            # enable start tls, enable_ssl should be false
            enable_start_tls: false
            # send client certificate
            enable_ssl_client_auth: false
            # verify ldap hostname
            verify_hostnames: true
            hosts:
              - server-ad.my.big.domain:389
            bind_dn: 'cn=user_for_LDAP,ou=Service Accounts,ou=Moscow,dc=MY,dc=BIG,dc=DOMAIN'
            password: 'Au5dUJ9q!54S'
            users:
              1-userbase:
                base: 'CN=Пушкин Александр Сергеевич (PushkinAS),OU=Users,OU=Saint_Petersburg,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
              2-userbase:
                base: 'CN=Горький Максим (GorkiiM),OU=Users,OU=Nizhny_Novgorod,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
              3-userbase:
                base: 'CN=Толстой Лев Николаевич (TolstoiLN),OU=Users,OU=Yasnaya_Polyana,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
            username_attribute: 'cn'
            roles:
              1-rolebase:
                base: 'CN=Department05-Developers,OU=Groups,OU=Moscow,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(member={0})'
              2-rolebase:
                base: 'CN=Department05-Admins,OU=Groups,OU=Moscow,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(member={0})'
              3-rolebase:
                base: 'CN=Department05-Analysts,OU=Groups,OU=Moscow,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(member={0})'
            userroleattribute: null
            userrolename: memberOf, SamAccountName
            rolename: "cn"
            resolve_nested_roles: false
      roles_from_another_ldap:
        description: "Authorize via another Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          type: ldap

Описание всех параметров вы можете посмотреть на официальном сайте OpenSearch (

Получаем полный путь к объектам в AD

Полный путь к группе в AD через PowerShell можно получить так:

$group = ([adsisearcher]“(&(objectcategory=group)(cn=name_of_group))”).Findall()
$group

Вместо «name_of_group» подставьте название нужной вам группы.

Полный путь к пользователю в AD через PowerShell можно получить так:

Проблема применения настроек

Выполнение команды для применения настроек удаляет все изменения, сделанные в OpenSearch-Dashboards в разделе «Security», то есть все настройки пользователей и ролей. И это является проблемой, так как в конфигурацию со временем будет необходимо добавлять новых пользователей и удалять старых пользователей.

Видимо разработчики OpenSearch всё же подразумевают, что все пользователи в AD лежат в одном каталоге и «лишних» пользователей там нет. Либо всё-таки подразумевается использование проксирующего LDAP сервера. Другого объяснения я не нашел.

Для того чтобы обойти эту проблему можно вносить изменения не в Web-интерфейсе (OpenSearch-Dashboards), а через файлы конфигураций.

Далее опишу настройку конфигурационных файлов.

Двухфакторная аутентификация

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

Особенно часто это происходит, когда пароль сложный (содержащий более 6 знаков и состоящий из букв разного регистра, цифр и специальных символов) и его трудно запомнить. А ведь такие политики администраторами задаются не просто так. Это необходимо для защиты учетной записи пользователя от простого перебора паролей по словарю.

Давайте вспомним, что такое аутентификация. В нашем случае это процесс подтверждения подлинности субъекта или объекта. Аутентификация пользователя — это процесс подтверждения подлинности пользователя.

А двухфакторная аутентификация — это такая аутентификация, в которой необходимо использовать не менее двух различных способов для подтверждения своей личности.

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

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

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

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

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

Опишу вкратце что и как взаимодействует, вся инфраструктура доменная (кроме 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. На картинке ниже роли, которые нужно поднять:

Я это все делаю с помощью 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:inetpubwwwroot, например rt.yourdomain.com, ну что б было все красиво и понятно тому, кто придет на этот сервер после нас или с нами. Добавляем новый веб-сайт (это, я думаю, понятно как) и заполняем:

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

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

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

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

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

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

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

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

Setspn /s HTTP/rt yourdomainiis_service
Setspn /s HTTP/rt.yourdomain.com yourdomainiis_service

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

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

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

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

Недостатки, куда же без них

Токены или смарт-карты не бесплатные (решается бюджетом).

Их нужно учитывать, администрировать и обслуживать (решается системами управления токенами и смарт-картами).

Некоторые информационные системы могут «из коробки» не поддерживать аутентификацию по токенам (решается системами типа Single Sign-On — предназначенными для организации возможности использования единой учетной записи для доступа к любым ресурсам области).

Преимущества входа в домен по токену

PIN-код от токена проще запомнить, так как он может быть намного проще пароля. Каждый наверняка хоть раз в жизни видел, как «опытный» пользователь мучительно не может с нескольких попыток аутентифицироваться в системе, вспоминая и вводя свой «безопасный» пароль.

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

При использовании токена для пользователя вход в систему выглядит следующим образом: после загрузки компьютера, он просто подключает токен к USB-порту компьютера, вводит 4-6 цифр и нажимает кнопку Enter. Скорость ввода цифр у обычных людей выше, чем скорость ввода букв. Поэтому PIN-код вводится быстрее.

Токены позволяют решить проблему «брошенного рабочего места» — когда пользователь уходит со своего рабочего места и забывает выйти из своей учетной записи.

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

Токен и смарт-карта

Наверно, самым надежным и простым в реализации способом двухфакторной аутентификации является использование криптографического токена или смарт-карты. Токен — это USB-устройство, которое является и считывателем, и смарт-картой одновременно. Первым фактором в таком случае является факт владения устройством, а вторым — знание его PIN-кода.

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

На фотографии изображена типичная смарт-карта и считыватель.

Однако вернемся к корпоративной безопасности.

А начнем мы с домена Windows, ведь в большинстве компаний в России корпоративная сеть построена именно вокруг него.

Как известно, политики Windows-домена, настройки пользователей, настройки групп в Active Directory предоставляют и разграничивают доступ к огромному количеству приложений и сетевых сервисов.

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