Возможность

Подключение LDAP/AD

Ваш корпоративный каталог уже есть; TR7 AAM не копирует пользователя, а подключается к LDAP/AD и превращает членство в группах в политику доступа.

TR7 LDAP / AD Bind делает существующую инфраструктуру каталога организации нативной частью управления доступом. Проверка пользователей, членство в группах, условный доступ, MFA и поток аудита объединяются на одной платформе; потребность управлять LDAP-подключением каждого приложения по отдельности снижается. TR7 AAM предлагает два разных метода bind. В режиме direct-bind имя пользователя преобразуется напрямую в операцию LDAP bind через UPN, NetBIOS, UID, CN или пользовательский шаблон. В режиме search-bind сначала пользователь ищется через сервисную учётную запись, затем найденный DN используется для проверки собственного пароля пользователя. Запрос членства в группах переносится в сессию AAM и может использоваться в политиках условного доступа. Решения вроде «какая группа к какому приложению имеет доступ», «какому пользователю требуется MFA», «какой backend открывается только членам определённого OU или группы» питаются из информации каталога. Результат: TR7 AAM выводит интеграцию LDAP/AD из состояния распределённой по приложениям конфигурации и переносит её на корпоративный слой доступа с безопасным транспортом, failover на несколько серверов, политикой на основе групп и централизованным аудитом.

Поддерживаемых шаблонов LDAP bind: UPN, NetBIOS, UID, CN, пользовательский

Метода балансировки нагрузки: roundrobin, weighted, failover

Компонента автоматического фильтра search-bind: userPrincipalName, sAMAccountName, cn

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

Большинство организаций управляют идентичностью пользователей в LDAP- или AD-каталоге. Когда вводится новое приложение, снова встаёт тот же вопрос: как это приложение подключится к каталогу, как проверит пользователя, какую информацию о группах прочитает и где примет решение о доступе? Если это подключение делается в каждом приложении по отдельности, архитектура идентичности быстро рассыпается.

LDAP-интеграция на каждое приложение порождает операционный долг. Каждое приложение несёт собственную сервисную учётную запись, адрес подключения, фильтр поиска, значение тайм-аута и настройку проверки сертификата. Когда меняется схема каталога, переносится структура OU, проводится ротация пароля сервисной учётной записи или выполняется миграция домена, это изменение распространяется на множество приложений.

Со стороны безопасности риск тоже растёт. Использование незашифрованного LDAP может привести к незащищённой передаче паролей по сети. Пароли сервисных учётных записей хранятся в конфигурациях приложений. Авторизация на основе групп при этом распределена по собственному коду приложений; аутентификация и политика доступа применяются в разных системах по разным правилам.

Аудит и наблюдаемость тоже фрагментируются. Информация о том, какое приложение через какую сервисную учётную запись подключилось к каталогу, какой пользователь был проверен, какая группа была запрошена, какой доступ был отклонён, чаще всего остаётся погребённой в логах приложений. Командам SOC и аудита приходится сводить разрозненные логи вместо единого централизованного потока идентичности.

TR7 LDAP / AD Bind решает эту проблему на платформе доступа: методы direct-bind и search-bind, безопасный транспорт LDAPS, запрос членства в группах, фильтр ограничения bind, failover на несколько серверов и политика условного доступа AAM объединяются в одной архитектуре.

Наш подход

TR7 AAM рассматривает подключение LDAP/AD не только как проверку пароля; а как поток поиска пользователей, запроса групп, безопасного транспорта и формирования политики доступа.

Direct-bind и search-bind предлагают две разные модели проверки

Direct-bind преобразует имя пользователя в значение bind principal через UPN, NetBIOS, UID, CN или пользовательский шаблон. Search-bind же ищет информацию о DN пользователя через сервисную учётную запись, затем выполняет проверку bind с собственным паролем пользователя.

Запрос членства в группах превращается в решение условного доступа

В режиме search-bind можно включить поиск групп, и членство пользователя в группах добавляется в сессию AAM. Эта информация о группах может использоваться в решениях о доступе к приложениям, обязательности MFA или авторизации на основе backend.

Подключение к каталогу защищается безопасным транспортом LDAPS

TR7 может устанавливать защищённое TLS подключение через LDAPS. Уровень безопасности подключения к каталогу определяется в соответствии с корпоративным стандартом путём настройки проверки сертификата и политики self-signed сертификатов.

Failover и распределение на несколько LDAP-серверов

Несколько серверов LDAP/AD могут быть определены в одной конфигурации. Подключения распределяются методами roundrobin, weighted или failover; когда первичный сервер каталога недоступен, может быть задействован альтернативный сервер.

Возможности

LDAP / AD Bind подключает проверку корпоративного каталога к потоку AAM через шаблоны bind, фильтры поиска, членство в группах, безопасный транспорт и управление несколькими серверами.

Direct-bind с пятью шаблонами principal адаптируется к разным структурам каталога

В режиме direct-bind имя пользователя преобразуется в значение bind principal одним из шаблонов UPN, NetBIOS, UID, CN или custom. В средах AD распространены форматы UPN и NetBIOS; в каталогах OpenLDAP или POSIX более уместными могут быть шаблоны UID и CN. С помощью custom-шаблона можно построить специфичную для организации структуру вроде uid={{username}},ou=people,dc=company,dc=com. Эта гибкость упрощает подключение разных схем каталога к единому потоку проверки AAM.

Search-bind сначала ищет пользователя, затем проверяет его паролем пользователя

В режиме search-bind TR7 сначала подключается к каталогу через сервисную учётную запись и ищет информацию о DN пользователя. Когда пользователь найден, на втором шаге выполняется операция bind с собственным DN и паролем пользователя. Эта модель полезна в средах, где пользователи находятся в разных OU, где DN не может быть выведен напрямую из имени пользователя или где требуется более контролируемый фильтр поиска. Информация о сервисной учётной записи и base DN поиска управляется централизованно.

Автоматический или пользовательский search filter делает поиск пользователей гибче

Фильтр search-bind в автоматическом режиме может совместно оценивать поля userPrincipalName, sAMAccountName и cn. В custom-режиме оператор задаёт собственный LDAP-фильтр; например, можно выполнить более узкий поиск вроде (sAMAccountName={{username}}). Этот подход адаптируется к разным схемам каталога и форматам имён пользователей. Для снижения ошибочных совпадений пользователей фильтр следует определять как можно точнее.

Bind restriction filter сужает доступ после успешного bind

Даже если пароль пользователя верен, может быть нежелательно, чтобы каждый пользователь каталога имел доступ к каждому приложению. С помощью bind restriction filter обеспечивается, что поток проверки проходят только пользователи, удовлетворяющие условию определённого OU, группы или атрибута. Например, к определённому backend могут допускаться только пользователи группы VPN Users. Этот фильтр оценивает аутентификацию вместе с областью доступа.

Поиск членства в группах добавляет в сессию AAM сигнал для политики

Когда активен ldapEnableGroupSearch, TR7 может запросить членство в группах, используя значение DN пользователя. С помощью ldapGroupSearchBase и ldapGroupFilter определяется, в какой области каталога и каким фильтром искать группы. Возвращённый список групп добавляется в сессию AAM. Потоки условного доступа могут на основе этой информации о группах принимать разные решения о приложении, MFA, разрешении или отказе.

Подключение LDAPS делает проверку пароля безопасной через TLS

При использовании LDAPS LDAP-подключение защищается TLS и обычно работает через порт 636. Поведение проверки сертификата сервера может быть настроено параметрами вроде sslValidateCertificate и sslAllowSelfSigned. В продакшн-среде незашифрованный LDAP использовать не следует. Безопасность подключения к каталогу является базовым требованием для защиты конфиденциальных данных, таких как пароль пользователя и сервисная учётная запись.

Значения тайм-аута подключения контролируют медленные ответы каталога

Значения тайм-аута подключения и операции LDAP настраиваемы. Если подключение не удаётся установить или сервер каталога отвечает медленно, поток AAM не ждёт бесконечно. Поведение медленного domain controller в часы пик или задержка сетевого сегмента может быть взята под контроль этими значениями. Настройки тайм-аута следует планировать вместе с пользовательским опытом и поведением failover.

Синхронизация списка пользователей LDAP переносит поля профиля в AAM

TR7 может, выбирая пользователей под определённым search base, переносить значения атрибутов вроде mail и телефона в локальный профиль пользователя AAM. Поля вроде queryMailField и queryPhoneField могут настраиваться в соответствии со схемой организации. Эта функция помогает в управлении списком пользователей и контактной информацией. В кластерной среде выборка списка пользователей ограничивается так, чтобы работать только на primary node.

Несколько серверов и failover делают доступ к каталогу устойчивым

В массиве hosts может быть определено несколько серверов LDAP/AD. lbMethod может быть выбран как roundrobin, weighted или failover. В режиме failover при недоступности первичного сервера выполняется переход на альтернативный. Подход с пулом подключений и circuit breaker снижает влияние постоянно сбоящих серверов на поток.

Выбор namespace обеспечивает доступ к каталогам в отдельном сетевом сегменте

Можно настроить, через какой сетевой namespace идти к LDAP-серверу. Это важно для domain controller в отдельном сегменте или специфичных для тенанта структур каталога. Трафик управления доступом переносится по правильной таблице маршрутизации и через сетевую изоляцию. В мультитенантных или сегментированных архитектурах ЦОД это обеспечивает более чёткий сетевой контроль.

Операционная глубина

LDAP / AD Bind эксплуатируется вместе с жизненным циклом подключения, безопасностью фильтров, очисткой подключений, поведением search-bind, кластерным ограничением и выбором атрибутов.

Жизненный цикл LdapManager

Когда настройки LDAP обновляются, информация о подключении переподготавливается, и поток проверки работает с новыми настройками. Информация о подключении формируется из параметров protocol, host, port, TLS и timeout. Применение изменений настроек в рамках централизованного жизненного цикла обеспечивает согласованность конфигурации.

Экранирование LDAP-фильтра

Перед подстановкой пользовательского ввода в LDAP-фильтр специальные символы экранируются. Значения вроде обратной косой черты, звёздочки, скобок и null-символа экранируются для снижения риска LDAP injection. Это поведение особенно критично в структурах, использующих custom filter.

Очистка подключения

После использования LDAP-подключения клиент очищается, а слушатели удаляются. Этот подход снижает зомби-подключения и излишнее использование памяти. Длительное keep-alive поведение должно использоваться только в специальных режимах, таких как выборка списка пользователей.

Выбор фильтра search-bind

Автоматический фильтр search-bind может совместно оценивать поля userPrincipalName, sAMAccountName и cn. В режиме custom-фильтра оператор задаёт собственный LDAP-фильтр. Custom-фильтр мощен; однако его следует проектировать осторожно, поскольку слишком широкие фильтры могут привести к неожиданным совпадениям пользователей.

Пул подключений

Структура пула backend нового поколения для LDAP может управлять клиентскими LDAP-подключениями по логике пула. При выборе LDAPS опции TLS добавляются к установке подключения. Специальное время DNS lookup и значения тайм-аута подключения приобретают значение в медленных или сегментированных сетях.

Ограничение primary в кластере

Выборка списка пользователей в кластерной среде ограничивается так, чтобы работать только на primary node. Это поведение предотвращает одновременную выборку одного и того же списка пользователей несколькими узлами и порождение излишней нагрузки. Поток bind аутентификации же продолжает работать согласно определённой модели подключения.

Выбор атрибутов

Массивом ldapAttributes определяется, какие поля будут возвращаться из каталога. Поля по умолчанию могут охватывать значения вроде dn, cn, userPrincipalName, displayName, mail и телефона. Дополнительные поля, такие как department, employeeID или пользовательский атрибут, могут быть добавлены в список согласно потребности организации.

В каких сценариях используется

Доступ AAM с AD-идентичностью по всей организации

В крупной организации сотрудники получают доступ к приложениям через AAM с существующими именем пользователя и паролем AD. Членство в группах переносится в политику AAM; группы финансов, HR и IT могут направляться в разные приложения или потоки MFA. При изменении политики паролей AD приложения не обновляются по одному.

Географический failover с несколькими domain controller

В структуре с двумя domain controller в двух ЦОД TR7 может устанавливать подключение методом failover. Когда первичный сервер каталога недоступен, происходит переход на альтернативный сервер. Поток проверки пользователей не зависит от отказа одного DC.

Ограничение доступа только для группы VPN-пользователей

Определённый backend может открываться только пользователям группы VPN Users. Даже если bind успешен, пользователь, не прошедший условие bindRestrictionFilter, отклоняется. Так проверка пароля и право доступа к приложению не считаются одним и тем же.

Использование UID bind с каталогом OpenLDAP и POSIX

Организации, использующие OpenLDAP вместо AD, могут выполнять проверку пользователей с шаблонами bind UID или CN. В каталогах на основе posixAccount сопоставление mail, телефона и пользовательских атрибутов может переноситься в профиль AAM. С установкой безопасного подключения через LDAPS классические LDAP-каталоги включаются в современный поток доступа.

Часто задаваемые вопросы

В чём основное различие между direct-bind и search-bind?

Direct-bind преобразует имя пользователя напрямую в значение LDAP bind principal через UPN, NetBIOS, UID, CN или пользовательский шаблон; дополнительный шаг поиска не требуется. Search-bind же сначала подключается к каталогу через сервисную учётную запись и ищет информацию о DN пользователя, затем выполняет второй bind с найденным DN и паролем пользователя. Для сред, где пользователи находятся в разных OU или где DN не может быть выведен напрямую из имени пользователя, search-bind более уместен.

Как информация о членстве в группах используется в политике доступа?

Когда включён ldapEnableGroupSearch, TR7 запрашивает из каталога членство в группах пользователя, успешно прошедшего аутентификацию. Возвращённый список групп добавляется в сессию AAM. Потоки условного доступа, используя эту информацию, могут определять, к какому приложению предоставить доступ, будет ли MFA обязательной и будет ли вход к определённому backend одобрен или отклонён.

Для чего служит bind restriction filter?

Bind restriction filter привязывает доступ к дополнительному условию каталога, даже если пароль пользователя верен. Например, этот фильтр задействуется, когда нужно, чтобы поток проверки проходили только пользователи, входящие в определённый OU или группу. Этот подход, оценивая проверку пароля на том же шаге, что и область доступа, создаёт дополнительный слой авторизации.

Как настраивается безопасный транспорт LDAPS?

Когда значение protocol установлено в ldaps, TR7 обычно устанавливает защищённое TLS подключение через порт 636. С помощью sslValidateCertificate проверка сертификата сервера может быть сделана обязательной; sslAllowSelfSigned же определяет, разрешено ли использование self-signed сертификата. В продакшн-среде использование незашифрованного LDAP не рекомендуется; пароль сервисной учётной записи и учётные данные пользователей не должны передаваться по сети незащищёнными.

Как определяется несколько серверов LDAP/AD?

Добавлением в массив hosts нескольких записей серверов создаётся конфигурация с несколькими серверами. Параметром lbMethod выбирается метод балансировки нагрузки roundrobin, weighted или failover. В режиме failover при недоступности первичного сервера TR7 автоматически переходит на альтернативный. Механизм пула подключений и circuit breaker предотвращает влияние постоянно сбоящих серверов на поток.

Синхронизация списка пользователей работает только на определённом node?

Да. В кластерной среде выборка списка пользователей работает только на primary node. Это ограничение предотвращает одновременную выборку одного и того же списка несколькими узлами и излишнюю нагрузку на сервер каталога. Поток bind аутентификации же продолжает работать на всех узлах кластера согласно определённой модели подключения.

Поддерживаются ли также RADIUS и TACACS+?

Да, но они находятся в разных местах, и это различие важно. RADIUS — источник личности конечного пользователя наряду с LDAP/Active Directory; он настраивается в разделе дополнительных интеграций поставщиков личности вместе с OAuth2, HTTP API и локальной базой пользователей. TACACS+ относится к плоскости управления — вход администратора в саму TR7 с полным учётом команд — и настраивается вместе с административными ролями, а не с доступом к приложениям. Эта страница описывает LDAP и Active Directory.

Сделайте ваш корпоративный каталог нативной частью управления доступом

Подключение LDAP/AD, политика на основе групп, безопасный транспорт LDAPS и централизованный аудит на одной платформе. Проведём вас по живой установке в вашей собственной среде.