Вход в личный кабинет Введение
Сразу отмечу, что в качестве Веб-интерфейса я использую OpenSearch-Dashboards. И в основном именно для OpenSearch-Dashboards мне нужна доменная авторизация.
Для того, чтобы настроить аутентификацию и авторизацию доменных пользователей Active Directory в OpenSearch по протоколу LDAP необходимо сконфигурировать файл «/plugins/opensearch-security/securityconfig/config.yml» (в моем случае полный путь к этому файлу такой «/opt/opensearch/plugins/opensearch-security/securityconfig/config.yml»).
Предисловие
Эта статья является продолжением статьи
. Однако, тема этой статьи достаточно узкая и практически не зависит от основной настройки всего стека 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), а через файлы конфигураций.
Далее опишу настройку конфигурационных файлов.
Конфигурация — кто-то использует tls, кто-то — нет
В данном случае выдвигается требование, что некоторые пользователи будут использовать TLS, а другие — нет. Например, политика может быть следующей:
Настройка sasl tls/ssl в openldap
В руководстве администратора OpenLDAP утверждается, что при использовании TLS с механизмом EXTERNAL SASL и клиенту, и серверу необходимо иметь действительный сертификат X.509. Если это правда, то мы получаем излишне сложную конфигурацию, а уровень безопасности повышается незначительно, и потому в большинстве случаев её использование представляется сомнительным (но есть заметные исключения, такие как репликация). В настоящее время подробно обсуждать это мы не будем.
Настройка sasl в openldap
Мы закончим этот раздел уже совсем скоро (one day real soon now ™)
Настройка сервера tls
LDAP-серверу требуется принимать только защищённые TLS-соединения от клиентов с проверкой подлинности LDAP. Поддерживается единственное пользовательское DIT с включённой службой репликации — то есть данный сервер использует наложение syncprov, кроме того, требуется доступ к сервисам cn=monitor и cn=config.
Настройка смешанного доступа tls/ssl в openldap
Если Вы сразу перешли к этому разделу, минуя описание нормальной конфигурации TLS, пожалуйста, найдите время ознакомиться как минимум с вводными замечаниями, а желательно и со всем разделом, поскольку в противном случае Вы можете очень быстро прийти в замешательство (хотя после прочтения Вы можете прийти в замешательство еще быстрее). Надеемся, однако, что некоторое просветление настанет.
Обзор
TLS (Transport Level Security) — это просто название стандартизированной IETF версии Secure Sockets Layer (SSL) от Netscape. Практически нет никаких различий между SSL(v3) и TLS(v1), и в этой документации данные термины считаются синонимами. TLS/SSL поддерживается OpenLDAP начиная с версии 2.1.
Обычно для работы TLS/SSL требуется сертификат X.509 (более известный как сертификат SSL), который можно приобрести в коммерческом центре сертификации или удостоверяющем центре (Certificate Authority, CA), либо это может быть самоподписанный сертификат.
Сессия TLS/SSL начинается с переговоров о выборе набора шифров, включающего в себя шифр обмена ключами, шифр для шифрования данных и алгоритм MAC (Message Authentication Code, представляет собой хэш). Шифр для шифрования данных или массового шифрования (который всегда является симметричным шифром, использующим вычисленный ключ сессии)
и MAC используются при передаче данных и потребляют значительно меньше ресурсов CPU, чем шифр обмена ключами (асимметричный шифр, например RSA или DSA/DSS), применение которого ограничивается посылкой ключа pre-master (на основании которого вычисляется ключ сессии) в начале обмена.
При использовании с контекстом TLS термин аутентификация указывает только на аутентификацию сервера (с помощью сертификата X.509), его не следует путать с аутентификацией LDAP, используемой для контроля доступа к DIT. При защите сессии с помощью TLS/SSL аутентификация LDAP с использованием простого (simple) механизма подсоединения становится полностью безопасной, поскольку, не смотря на то, что пароли отправляются открытым текстом, они инкапсулируются в шифрованный поток данных, таким образом, при пересылке как по доверенным, так и по недоверенным сетям, перехват (прослушивание) данных становится невозможным.
Приводимые ниже конфигурации не дают исчерпывающего описания всех возможностей использования TLS с LDAP. Скорее, они представляют собой те варианты конфигурации, которые охватывают наиболее часто встречающиеся ситуации, и, надеемся, поддаются относительно простому внедрению даже со скромным уровнем знаний в области TLS/SSL и сертификатов X.509.
Однако, если пользовательские требования выдвигают какие-то специфические условия, могут понадобиться более глубокие знания. Тогда Вам может быть полезно это руководство по выживанию, дающее жуткие подробности протокола TLS/SSL, форматов сертификатов X.509 и генерации самоподписанных сертификатов для использования в различных условиях.
Процесс инициации сессии TLS может происходить одним из двух способов:
Автоматически: Если клиент использует LDAP URL в форме ldaps://hostname/, то диалог TLS инициируется автоматически (обе стороны ожидают элементов протокола TLS/SSL) на порту по умолчанию для ldaps 636. Порт по умолчанию для ldaps может быть изменён на альтернативный путём использования URL в форме ldaps://hostname:port/, при этом сервер должен быть настроен на приём соединений на этом альтернативном порту (с помощью параметра -h при запуске slapd). Чтобы окончательно всех запутать, можно даже указать в качестве альтернативного ldaps порта 389-й (то есть нормальный порт ldap), при этом даже не придётся перенастраивать фаервол. Даже в этом случае диалог TLS будет по-прежнему инициироваться автоматически благодаря использованию схемы ldaps в URL.
Согласно определению: LDAP также может быть настроен на приём соединений TLS/SSL на стандартном порту LDAP при использовании URL ldap://hostname (порт по умолчанию — 389, но это можно изменить). В этом случае клиент должен быть явно запрограммирован (или ему должно быть указано) использовать последовательность StartTLS (сообщение с запросом расширенной операции с OID элемента управления StartTLS 1.3.6.1.4.1.1466.20037). Например, при использовании syncrepl с TLS и URL в форме ldap://hostname/ ДОЛЖЕН быть задан параметр starttls=yes или starttls=critical (если же используется URL в форме ldaps://hostname/, задавать его не обязательно).
Хотя OpenLDAP, в соответствии со своей обычной философией, позволяет производить множество разнообразных вариантов настройки, все описанные ниже конфигурации TLS схожи по характеристикам и используют лишь некоторый набор из доступных опций настройки.
Обзор безопасности ldap
У LDAP, и особенно у OpenLDAP, есть ряд возможностей обеспечения безопасности, которые на первый (да и на второй и третий) взгляд могут показаться немного сложными. Рисунок 15-1 показывает общую картину проблемы, перед тем как углубиться в детали. Далее демонстрируются различные методы доступа и интерфейсы к LDAP-системе, а затем описываются проблемные вопросы безопасности и доступные методы управления рисками. Цель данного упражнения — либо определиться с набором политик безопасности, либо выделить приоритеты реализации.
Рисунок 15-1. Общая картина вопросов обеспечения безопасности
Все номера, встречающиеся в описании ниже, ссылаются на рисунок 15-1.