Вход в личный кабинет Введение
Сразу отмечу, что в качестве Веб-интерфейса я использую 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), а через файлы конфигураций.
Далее опишу настройку конфигурационных файлов.
Ldap авторизация на сайте | vhod-v-lichnyj-kabinet.ru
Drupal можно с легкостью назвать универсальным инструментом для реализации различных задач, также и определенной сложности enterprise решения.
Так получилось, что в основном Drupal я использую на предприятии, внутри Интранет сети, которая имеет Active Directory. И для того чтобы полноценно
использовать инфраструктура нашей сети, программой минимум это является Active Directory авторизация на сайтах и сервисах, и тут проблем у Drupal-а
нет, благодаря модулю Lightweight Directory Access Protocol (LDAP).
В данном материале я хочу рассказать, как он настроен в моём окружении, и может кому то статья пригодится.
Итак, сразу забегая скажу, что с помощью данного модуля вы сможете предоставить:
1. LDAP авторизацию в вашей сети (в моём случае используется Active Directory от Microsoft)
2. Настроить сквозную авторизацию (когда пользователь автоматически входит под учётной записью операционной системы)
3. Ограничивать доступ, тем кто может входить на сайт и кому нельзя.
4. Синхронизация атрибутов учетной записи Active Directory с полями профиля пользователя на сайте, так и наоборот.
5. Актуализация учетной записи на сайте после смены логина учетной записи Active Directory (обычно происходит после смены фамилии сотрудника – меняется аналогично логин)
6. Присваивание роли пользователю на сайте в зависимости от его нахождения в определенной группе Active Directory
Итак для работы авторизации нам понадобятся 2 модуля:
- Lightweight Directory Access Protocol (LDAP)
- LDAP Single Sign On
Т.к. я пока являюсь активным пользователем Drupal 7, то все инструкции буду приводить на его примере, но опять же когда я интереса ради запускал Drupal 8,
то понял что модуль практически идентичен 7ой версии Drupal.
Скопируем к себе данные модуля, а также их зависимости Ctools и Entity API. На странице модулей активируем следующие модули:
- LDAP Authentication
- LDAP Authorization (модуль опционально, если вам требуется ограничение на доступ к сайта, либо ролям сайта по признаку нахождения пользователя в группах Active Directory)
- LDAP Authorization – Drupal Roles (дополнение к выше описанному модулю)
- LDAP Servers
- LDAP SSO (модуль опционально, если вам не требуется сквозная авторизация, либо пока веб-сервер не настроен под это, можно не устанавливать)
- LDAP User Module
Стоит отметить, что модуль не установится, если в ваших настройках PHP не установлен модуль php_ldap. Потому заранее установите, и настройте под характеристики вашего окружения.
После успешной установки модуля, перейдем в его настройки которые расположены здесь admin/config/people/ldap
Настройки модуля поделены на 4 вкладки: Settings, Servers, User, Authentication, Authorization
В первой вкладке настраивается метод шифрования паролей учетной записи Active Directory внутри Drupal-а.
На своей практике я это не использую, потому сразу перехожу во вторую вкладку Servers. И здесь мы остановимся по подробней.
Во вкладке отображены все созданные сервера LDAP авторизации, которые будут использованы на сайте, по умолчанию этот список пуст и нам с помощью кнопки Add LDAP Server Configuration можно создать новый сервер.
Страница создания сервера поделена на несколько блоков, рассмотрим каждый из них:
Connection settings
Machine name for this server configuration. – собственно машинное имя создаваемого сервера. Обычно называю active_directory
Name **- ещё какое то имя сервера, также называю active_directory
**Enabled – ставлю галочку, таким образом включаю создаваемую конфигурацию сервера
LDAP Server Type – в моём случае выбираю Active Directory
LDAP server – доменное имя либо IP адрес по которому находится сервер Active directory, в моём случае ad.zv
LDAP port – отставляю по умолчанию 389, у нас он такой же
Use Start-TLS – галочку не ставлю, т.к. не используем шифрование
Follow LDAP Referrals – также не ставлю, хотя так до конца и не разбирался для чего нужна данная настройка
Bingind method
Binding Method for Searches (such as finding user object or their group memberships)
Другими словами спрашивается каким образом, от чьего имени будет происходить подключение к сервере Active directory для поиска пользователя на факт существования, чтения его аттрибутов и т.д.
Также как и в описании к значения использую первый вариант Service Account Bind как best practice.
А именно подключение к серверу будет происходить от специальной заранее созданной учетной записи в Active directory которая имеет право на чтение каталогов и структуры Active Directory
Выбирая данный вариант ниже необходимо указать логин и пароль сервисной учетной записи в полях DN for non-anonymous search и Password for non-anonymous search
Clear existing password from database. Check this when switching away from Service Account Binding – пункт не применим к нашему методу описанному выше, потому галочку не ставим.
LDAP user to Drupal user relationship
Base DNs for LDAP users, groups, and other entries – базовый DN где находятся все пользователи в Active Directory, в моём случае ставлю DC=ad,DC=zv. В данной настройке лучше проконсультироваться с системными администраторами вашего сервера Active Directory
AuthName attribute и AccountName attribute – атрибут в котором хранится логин пользователя и аккаунт имя, обычно они должны быть одинаковы, и в большинстве случаев указывается samaccountname , т.к. по умолчанию логин находится там в Active Directory
Email attribute – атрибут в котором находится почтовый ящик пользователя, в моём случае mail. Стоит отметить что для Drupal-а это поле обязательно, т.к. Drupal не может иметь пользователя без почтового ящика, потому если в вашем окружении есть вероятность того что существует пользователи без почтового ящика, то вам необходимо воспользоваться полем ниже для заполнения почтового ящика по шаблону, либо позже в другой вкладке мы вернёмся к данной настройке с другой стороны.
Email template – шаблон почтового ящик, применяется тогда, когда ваши почтовые ящики например идентичны логину, либо состоят из нескольких атрибутов пользователя в Active Directory. Потому вы может просто составить его из токенов аттрибутов.
Thumbnail attribute – атрибут в котором находится изображение пользователя (в binary) для последующей загрузки в изображения профиль пользователя в Drupal-е, в моём случае thumbnailPhoto
Persistent and Unique User ID Attribute – уникальный атрибут, который никогда не изменится у пользователя Active Directrory. Применяется в тех случаях когда например логин у вас представляет собой фамилию и инициалы пользователя, и если вдруг пользователь сменил фамилию, и следом ему изменили логин, то для следующего входа им на сайт для Drupal-а он будет по умолчанию как новый пользователь, и Drupal будет создавать новую учётную запись (конечно при условии, что почтовый ящик ему тоже сменили, т.к. если он останется прежним, то Drupal сообщит о конфликте почтового ящика, и не создаст новую запись). Именно поэтому данное поле служит уникальным ключом на которое в первую очередь будет смотреться при входе пользователя на сайт, даже если он сменил логин, Drupal сначала найдёт его по данному атрибуты, и тогда по нему построит связь с пользователем Active Directory и как следствие обновит ему логин на сайте Drupal. В моем случае это objectsid
Does the Persistent and Unique User ID Attribute hold a binary value? – галочку ставлю, т.к. objectsid хранится в binary.
Аутентификация в общем случае
Как показано в статьях, аутентификация производится по следующей схеме:
Альтернативным вариантом может являться использование компилируемого модуля для nginx, но я данный вариант здесь не рассматриваю с силу некоторых проблем с данным модулем и меньшей его гибкости.
Доработанный образ для OpenLDAP сервера есть здесь.
Аутентификация контейнеров
В рамках NAS, сервисы работают в контейнерах, поэтому есть желание сделать так, чтобы возможно было переключать режимы аутентификации, просто установив переменные внутри контейнера.
Такой механизм уже есть в используемом образе ngingx-proxy и реализован он через шаблоны, которые обрабатывает docker-gen.
Он подставляет в шаблон метаданные, которые содержат описание запущенных в данный момент контейнеров Docker.
Таким образом, всё что надо сделать — это доработать шаблон конфигурации обратного прокси так, чтобы при наличии условной переменной в контейнере, было включено перенаправление на сервис сквозной аутентификации, который также работает в контейнере.
Затем, внести соответствующие коррективы в конфигурацию docker-compose.
Важные детали
1 Должна быть создана учётка helpdesk на AD2. Открывать Otrs надо по символическому а не по IP адресу3. На KDC должен быть сгенерирован keytab файл и скопирован на веб-сервер4. wbinfo -u должен выдавать список юзеров, веб-сервер должен быть в домене
Иерархия ролей.
Самое важное, и при этом самое запутанное для понимания — это иерархия элементов в RBAC. От того насколько правильно она продуманна зависит то, как гибко вы сможете управлять ролями в системе, и как часто вам придется изменять код контроллеров.
Рассмотрим подробнее каждый элемент авторизации:
На диаграмме выше указана типовая иерархия, где контроллеры проверяют операции, а к пользователям привязываются роли. Однако YII не запрещает вам проверять в контроллере что либо другое, например, роль пользователя. Но вы должны помнить, что это НЕПРАВИЛЬНО и приводит к тому, что вы лишаетесь преимуществ централизованного управления.
Рассмотрим пример: У нас есть Новости, к управлению которыми мы хотим разграничить доступ. Первое, что мы должны сделать при проектировании RBAC это продумать возможные ОПЕРАЦИИ (а не роли пользователей, как кажется на первый взгляд).
Обычно новости можно удалять, создавать, читать и редактировать. Преобразуем эти действия в операции: deleteNews, createNews, readNews, updateNews.
В коде вы можете проверять любую из этих операций:
Использование сервисом
Сквозная аутентификация по умолчанию выключена.Для её включения достаточно установить в окружении нужного контейнера переменные:
Модификация конфигурации docker-compose
В docker-compose.yml были добавлены:
Модификация шаблона конфигурации nginx-proxy
В первую очередь добавляется новый upstream, который позволяет обращаться к сервису аутентификации в конфиге:
Настройка proftpd сервера
На сервере нужно установить LDAP -client libnss-LDAP командой apt-get install libnss-LDAP
Вводим ip-адресOpenLDAP сервера:
Имя базы, в которой будет осуществлён поиск:
ВерсиюLDAP надо выбрать 3:
Далее система предложит согласиться на ввод админских данныхLDAP сервера, соглашаемся:
Настройка авторизации пользователей в active directory
Как правило, в компаниях существует сервер (контроллер домена) в котором хранится база всех пользователей, и желательно сделать так, чтобы наши родные пользователи смогли проходить аутентификацию со своим AD-аккаунтом в OTRS. Это можно сделать так.
Требования к аккаунтамУ пользователей в AD должно быть заполнено поля с информацией об имени (Имя. Фамилия, Отчество (инициал) и email). Без этого они не пройдёт аутентификацию.
Спасибо!
Если вам помогла статья, или вы хотите поддержать мои исследования и блог – вот лучший способ сделать это:
Способы проверки прав в контроллерах
Всего имеется 2 способа проверки прав.
Первый способ мы уже рассмотрели. Это метод
checkAccess()
компонента
Ссылки
OTRS Appliance (iso)OTRS Installation manualУстановка OTRS на Ubuntu ServerНастройка OTRSИнтеграция с Active DirectoryOTRS:ITSMСтавим OTRS на Ubuntu по-быстромуУстановка OTRS и интеграция с Active DirectoryKerberos в Active DirectoryКодировка имён пользователей
Тормозит otrs
У меня возникла такая проблема. После прописывания сервера для исходящей почты OTRS стал дико тормозить (я про веб-интерфейс). Как оказалась проблема была в том, что он каждый раз при работе с почтой проверял действительность email адреса. Лечится это просто, я поставил эту настройку в «нет», и тормоза исчезли.
Администрирование -> Конфигурирование системы -> Framework:Core -> CheckMXRecord = НетВключает проверку MX record почтовых адресов клиента до отправки почты или приема почтовой или телефонной заявки.
Требования
Для начала определимся с требованиями. Допустим у нас уже есть центральный сервер, с развернутой на нём службой каталогов (Active Directory). Необходимо сделать так, чтобы пользователи могли авторизовываться в системе, создавать заявки, а технические специалисты отвечать на них и собственно выполнять. Для этих целей поставим виртуальную машину и развернём на ней OTRS.
Установка задания cron
Делаем по официальному руководству. См. раздел «Настрой планировщика задач (cron jobs) для OTRS» на github.
Заключение
Механизм ролей в Yii является по настоящему гибким, если его правильно использовать.
В планах на будущее есть создание или адаптация какого либо GUI решения по управлению ролями, т.к. даже с небольшим количеством действий система становится запутанной, а количество писанины неоправданным.
Призываю всех пользователей к обсуждению: как они реализовывали систему управления правами в Yii проектах, и какие советы из личного опыта могут быть полезны остальным?