Протокол ldap. каталоги ldap и их применение

Системы настройки и управления LDAP

  • Zentyal,
  • GOsa,
  • Webmin,
  • phpLDAPadmin,
  • Lume.

Для чего можно использовать LDAP?

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

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

Примеры промышленного использования служб каталогов:

  • Идентификация компьютеров
  • Аутентификация пользователей в единой системе
  • Группировка пользователей (в том числе системные группы)
  • Адресные книги
  • Представление штатно-кадровой структуры организации
  • Учет закрепления имущества организации за сотрудниками
  • Телефонные справочники
  • Управление пользовательскими ресурсами
  • Справочники адресов электронной почты
  • Хранение конфигурации приложений
  • Хранение конфигурации АТС

Использование LDAP

  • Какой тип информации может храниться в директориях? Информационная модель LDAP основана на записях (entry). Запись — это коллекция атрибутов (attribute), обладающая уникальным именем (Distinguished Name, DN). DN глобально-уникально для всего каталога и служит для однозначного указания на запись. Каждый атрибут записи имеет свой тип (type) и одно или несколько значений (value). Обычно типы — это мнемонические строки, в которых отражено назначение атрибута, например «cn» — для общепринятого имени (common name), или «mail» — для адреса электронной почты. Синтаксис значений зависит от типа атрибута. Например, атрибут cn может содержать значение Babs Jensen. Атрибут mail может содержать значение «[email protected]». Атрибут jpegPhoto будет содержать фотографию в бинарном формате JPEG.
  • Как информация храниться в LDAP? Записи каталога LDAP выстраиваются в виде иерархической древовидной структуры. Традиционно, такая структура отражает географические и организационные границы. Записи, обозначающие страны, находятся наверху дерева. Чуть ниже располагаются записи о регионах и организациях. Еще ниже — информация об отделах, людях, принтерах, документах или о том, о чем вы подумаете. Дерево может быть создано, основываясь на доменных именах интернета такое именование позволяет узнать расположение службы директорий, используя Раздел DNS: Что такое DNS.
  • Как можно обратиться к информации? К записи обращаются по ее уникальному имени, которое состоит из собственно имени записи (так называемое относительное уникальное имя (Relative Distinguished Name, RDN) с прибавлением к нему имён записей-предков. Так, запись, описывающая Barbara Jensen в приведенном выше примере с Internet-именованием, имеет RDN uid=babs, и DN — uid=babs,ou=People,dc=example,dc=com.
  • Что такое slapd и что он может сделать? slapd (Stand-alone LDAP демон) это сервер директорий LDAP. Вы можете использовать его для обеспечения собственного сервера директорий. Ваша директория может содержать любую информацию, которую вы захотите. Вы так же можете подключить свою директорию к глобальной службе директорий LDAP или запустить службу директорий самостоятельно. Некоторые возможности slapd: пункт 1.9., например SASL, TLS (или SSL), поддерживает Unicode и языковые теги.
  • Что такое slurpd и что он может делать? slurpd(8) — демон, который, с помощью slapd(8), обеспечивает работу службы репликаций. Он отвечает за распространение изменений, сделанных в главной БД slapd, на другие БД slapd. Slurpd освобождает slapd от необходимости беспокоится, если другие БД slapd выключены или недоступны, когда произошли изменения в главной БД. Slurpd автоматически повторяет запросы на обновление. Slapd и Slurpd связаны через простой текстовый файл, который используется для записи изменений.

Ссылки

  • LDIF — формат обмена данными LDAP.
  • LDAP

  • PHP LDAP

  • Про LDAP по-русски: Руководство администратора OpenLDAP 2.4, Перевод учебника «LDAP for Rocket Scientists» и статьи.
  • samba_pdc + ddns + dhcp — с хранением всех данных в LDAP

Настройки среды¶

После того, как основные настройки были сделаны и протестированы, теперь можно выполнять настройки, зависящие от конкретной среды. Эти параметры определяют, какие деревья содержат объекты определенных типов, а также имена определенных атрибутов объектов. С помощью этих параметров Veyon может извлекать всю необходимую информацию из каталога LDAP.

Деревья объектов

Деревья объектов — это организационные или структурные единицы, в которых хранятся определенные типы объектов (пользователи, группы, компьютеры). Соответствующие CN (Общие имена) или OU (Организационные единицы) должны быть введены без базовой части DN в соответствующем поле ввода. Рядом с каждым полем ввода расположены кнопки для открытия диалоговых окон просмотра и для тестирования отдельных настроек.

Дерево пользователей
Здесь должно быть введено дерево LDAP (без базового DN), в котором расположены пользовательские объекты, например, или .
Дерево групп
Здесь необходимо ввести дерево LDAP (без базового DN), в котором расположены объекты группы, например, или .
Дерево компьютеров
Здесь должно быть введено дерево LDAP (без базового DN), в котором расположены компьютерные объекты, например, или .
Дерево групп компьютеров
Если группы компьютеров расположены в дереве, отличном от обычных групп пользователей, или в поддереве, здесь можно указать соответствующее дерево LDAP. В противном случае дерево групп используется для запроса компьютерных групп и фильтрации их с помощью определенного , если это необходимо.
Выполнить рекурсивные действия по поиску в деревьях объектов

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

Default: disabled

Подсказка

Если объекты одного типа хранятся в разных деревьях объектов (например, пользователи как в , так и в ), параметр для соответствующего дерева объектов можно оставить пустым и активировать опцию Perform recursive search operations in object trees. Затем выполняется рекурсивный поиск во всем каталоге LDAP, начиная с базового DN. В этом случае, однако, настоятельно рекомендуется установить для соответствующего типа объекта.

Настройки схемы членства

 Настройка

Описание

 Атрибут участников группы

Поле атрибута, используемое при загрузке членов группы. Пример:

         member

 Атрибут членства пользователя

Поле атрибута, используемое при загрузке групп пользователей. Пример:

         memberOf

 Используйте атрибут членства пользователя при поиске членства в группе пользователя

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

  •          Если этот флажок установлен, ваше приложение будет использовать атрибут членства группы для пользователя при получении списка групп, к которым принадлежит данный пользователь. Это приведет к более эффективному извлечению.
  •          Если этот флажок не выбран, ваше приложение будет использовать атрибут members в группе («член» по умолчанию) для поиска.
  •          Если флажок Включить вложенные группы отключен, ваше приложение будет игнорировать параметр «Использовать атрибут членства пользователя» и будет использовать атрибут members в группе для поиска.

 Используйте атрибут членства пользователя при поиске членов группы

Проверьте это, если ваш сервер каталогов поддерживает атрибут членства пользователя в группе. (По умолчанию это атрибут ‘member’.)

  •          Если этот флажок установлен, ваше приложение будет использовать атрибут членства группы для пользователя при извлечении членов данной группы. Это приведет к более эффективному поиску.
  •          Если этот флажок не выбран, ваше приложение будет использовать атрибут members в группе («член» по умолчанию) для поиска.

Интерфейс командной строки¶

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

Эта команда может быть использована для автоматического определения используемого базового DN и постоянной записи его в конфигурацию. В качестве параметров необходимо указать URL-адрес сервера LDAP и, необязательно, атрибут контекста именования:

veyon-cli ldap autoconfigurebasedn ldap://192.168.1.2/ namingContexts
veyon-cli ldap autoconfigurebasedn ldap://Administrator:[email protected]:389/

Подсказка

Специальные символы, такие как или – особенно в пароле — могут быть указаны с помощью URL-процентной кодировки.

Эта команда позволяет запрашивать объекты LDAP (, , , ) и в основном используется для тестирования. Эта функция также может быть использована для разработки сценариев для задач системной интеграции.

veyon-cli ldap query users
veyon-cli ldap query computers

Настройка соединения в файлах.properties

Если у вас отсутствует возможность запустить Server Manager, вы можете настроить интеграцию с LDAP в файле trackstudio.security.properties

  1. Включите поддержку LDAP в trackstudio.security.properties:
  1. Если требуется, включите опцию «Использовать LDAP поверх SSL
    «
  1. Укажите адрес сервера LDAP и его порт
  1. Установите Base DN к cn=users
    для вашего доменного имени. Вы можете указать несколько Base DN в
    настройках LDAP. Используйте точку с запятой в качестве разделителя.
  1. Укажите учетную запись пользователя, через которую будет осуществляться вход в Active Directory:
  1. Укажите пароль к этой записи:

Для того, чтобы пользователи, зарегистрированные в LDAP, имели доступ к TrackStudio, для них должны быть созданы учетные записи. Эти учетные записи должны совпадать с записями в LDAP по названию аккаунта, либо по имени пользователя.

  1. Чтобы входить по имени и фамилии пользователя установите:
  1. Чтобы входить по названию учетной записи:

Основные компоненты данных LDAP

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

Атрибуты

Сама информация в LDAP-системе в основном хранится в элементах, называемых атрибутами. Атрибуты, в основном, являются парами ключ-значение. В отличие от некоторых других систем, ключи имеют предопределённые имена, которые продиктованы выбранным для данной записи объектными классами (об этом мы поговорим чуть позже). Более того, данные в атрибуте должны соответствовать типу, определённому в исходном определении атрибута.

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

При обращении к атрибуту и его данным (когда он не задан), две стороны соединяются знаком равенства:

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

Записи

Атрибуты сами по себе не очень полезны. Чтобы иметь смысл, они должны быть связаны с чем-то. В LDAP вы используете атрибуты в пределах записи (entry). Запись, по сути, представляет собой набор атрибутов под именем, используемым для описания чего-либо.

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

Пример записи, отображаемой в LDIF (LDAP Data Interchange Format), будет выглядеть примерно так:

Приведенный выше пример может быть валидной записью в системе LDAP.

DIT

Начав знакомиться с LDAP, легко понять, что данные, определяемые атрибутами, представляют собой лишь часть доступной информации об объекте. Остальное — это расположение записи в системе LDAP и связи, проистекающие из этого.

Например, если можно иметь записи как для пользователя, так и для объекта инвентаризации, как кто-то сможет отличить их друг от друга? Один из способов отличить записи разных типов — это создание отношений и групп. Это в значительной степени зависит от того, где находится запись при ее создании. Все записи добавляются в систему LDAP в виде веток на деревьях, называемых Data Information Trees, или DIT-ы.

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

Таким образом, у вас может быть запись для «people» и запись для «inventoryItems». Ваши фактические записи данных могут быть созданы как дочерние записи приведенных выше, чтобы лучше различать их тип. Ваши организационные записи могут быть произвольно определены, чтобы наилучшим образом представить ваши данные.

В примере записи в разделе выше мы видим одно указание на DIT, в строке :

Эта строка называется distinguished name («dn», «отличительное имя») записи (подробнее об этом позже) и используется для идентификации записи. Она функционирует как полный путь до «корня» DIT. В данном случае у нас есть запись под названием , которую мы создаем. Прямым родителем является запись с именем , которая, вероятно, используется в качестве контейнера для записей, описывающих людей. Родители этой записи произошли от доменного имени , которое выступает как корень нашей DIT.

Example 2: LDAP number filter

Here you have to specify your search criteria for number look ups.

When you type in this field for example:(|(telephoneNumber=%)(Mobile=%)(ipPhone=%))the result of your search will be all LDAP records which have the “telephoneNumber” OR “Mobile” OR “ipPhone” field equal to the entered prefix.

When you type in this field: (&(telephoneNumber=%)(sn=*))the result of your search will be all LDAP records which have the “sn” field set AND the “telephoneNumber” field equal to the entered prefix.

Additionally as of version 10.1.27.0 the greater or equal, less or equal and approximate filters are supported. What is returned is dependent on the server implementation. When you type (telephoneNumber >= 5) , it could result in a numeric or lexicographic comparison, and the subsequent result. Likewise

Настройки схемы

 Настройка

 Описание

 Базовое имя DN (различающееся имя)

Коренное различающееся имя (DN) для использования при запуске запросов к серверу каталогов. Примеры:

  •          o=example,c=com
  •          cn=users,dc=ad,dc=example,dc=com
  •          Для Microsoft Active Directory укажите базовое DN в следующем формате: dc = domain1, dc = local. Вам нужно будет заменить domain1 и local для вашей конкретной конфигурации. Microsoft Server предоставляет инструмент ldp.exe, который полезен для определения и настройки структуры LDAP вашего сервера.

 Дополнительное пользовательское DN (имя)

Это значение используется в дополнение к базовому DN при поиске и загрузке пользователей. Если значение не задано, поиск поддерева будет начинаться с базового DN. Пример:

         OU = Users

 Дополнительное имя группы DN

Это значение используется в дополнение к базовому DN при поиске и загрузке групп. Если значение не задано, поиск поддерева будет начинаться с базового DN. Пример:

         ou=Groups

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

Блокировка доступа по защищенному протокол LDAP через Интернет

Предоставление доступа к управляемому домену по защищенному протоколу LDAP через Интернет создает угрозу безопасности. Управляемый домен доступен из Интернета через порт 636. Мы рекомендуем ограничить доступ к управляемому домену только из определенных IP-адресов, имеющих отношение к конкретной среде. Для ограничения доступа по защищенному протоколу LDAP можно использовать правило группы безопасности сети Azure.

Давайте создадим правило, которое разрешит входящий доступ по защищенному протоколу LDAP через TCP-порт 636 только для указанного набора IP-адресов. Правило DenyAll с низким приоритетом по умолчанию применяется ко всему остальному входящему трафику из Интернета, а значит доступ к управляемому домену по защищенному протоколу LDAP можно будет получить только с указанных адресов.

  1. На портале Azure выберите Группы ресурсов в панели навигации слева.

  2. Выберите группу ресурсов, например myResourceGroup, а затем выберите группу безопасности сети, например aaads-nsg.

  3. Отобразится список существующих правил безопасности для входящих и исходящих подключений. В левой части окна свойств для группы безопасности сети выберите Параметры > Правила безопасности для входящего трафика.

  4. Щелкните Добавить и создайте правило, открывающее TCP-порт 636. Для повышения безопасности выберите IP-адреса в качестве источника и укажите допустимый IP-адрес или диапазон адресов, принадлежащих вашей организации.

    Параметр Значение
    Источник IP-адреса
    IP-адреса источника или диапазоны в нотации CIDR Допустимый IP-адрес или диапазон для вашей среды
    Диапазоны исходных портов *
    Назначение Любой
    Диапазоны портов назначения 636
    Протокол TCP
    Действие Allow
    Приоритет 401
    Имя AllowLDAPS
  5. Когда все будет готово, щелкните Добавить, чтобы сохранить и применить это правило.

Реализации

Серверная часть

LDAP является широко используемым стандартом доступа к службам каталогов. Из свободно распространяемых открытых реализаций наиболее известен сервер OpenLDAP, из проприетарных — поддержка протокола имеется в Active Directory — службе каталогов от компании Microsoft, предназначенной для централизации управления сетями Windows. Сервер IBM Lotus Domino в своём составе также имеет службу LDAP. Свои реализации служб каталогов, поддерживающие LDAP как протокол доступа, предлагают и другие крупные компании, например, Novell и Sun — OpenDS и, впоследствии, OpenDJ.

Перечень наиболее известных на сегодняшний день LDAP-серверов:

  1. OpenLDAP
  2. ForgeRock OpenDJ
  3. Novell eDirectory
  4. Apple Open Directory (форк проекта OpenLDAP)
  5. Microsoft Active Directory
  6. Samba4 LDAP (OpenSource-реализация MS AD)
  7. RedHat Directory Server
  8. 389 Directory Server (по сути тестовая версия предыдущего)
  9. Oracle Directory Server
  10. Apache Directory Server
  11. IBM Tivoli Directory Server
  12. IBM Domino LDAP
  13. CommuniGate LDAP

Клиентская часть

В качестве клиентов LDAP выступают как адресные книги почтовых клиентов, так и back-end’ы различных сетевых служб (серверы DNS, SMTP, Samba, UTS и т. д.).

Организация данных

Мы рассмотрели общие элементы, которые используются для построения записей в LDAP системе и поговорили о том, как эти «строительные блоки» определяются в системе. Однако мы еще не много говорили о том, как организована и структурирована сама информация в LDAP DIT.

Размещение записей в DIT

DIT — это просто иерархия, описывающая взаимосвязь существующих записей. После создания, каждая новая запись должна «подключаться» к существующему DIT, помещая себя в качестве дочерней по отношению к какой-либо существующей записи. Это создает древовидную структуру, которая используется для определения отношений и присвоения значения.

Верхний DIT — это самая широкая категория, под которой каждый последующий узел является чьим-то потомком. Обычно самая верхняя часть записи просто используется как метка, называющая организацию, для которой DIT используется. Эти записи могут быть иметь любой объектный класс, но обычно они строятся с использованием доменных компонентов ( dc=example,dc=com для управляющей информации LDAP, связанной с example.com ), местоположений ( l=new_york,c=us для организации или сегмента в Нью-Йорке), или подразделений организации ( ou=marketing,o=Example_Co ).

Записи, используемые для организации (используемые как папки) часто используют объектный класс organizationalUnit , что позволяет использовать простую описательную метку атрибута с названием ou= . Такого рода записи часто используются для общих категорий в записи DIT верхнего уровня (пример часто используемых — ou=people , ou=groups и ou=inventory ). LDAP оптимизирован для поиска информации по дереву в направлении «вправо-влево», а не «вверх-вниз», поэтому зачастую лучше поддерживать иерархию DIT не глубокой, с обобщенными организационными ветвями, и дальнейшим указанием на различия через задание определенных атрибутов.

Именование (Naming) и ссылочные записи (Referencing Entries) в DIT

Мы ссылаемся на записи по их атрибутам. Это означает, что каждая запись должна иметь однозначный атрибут или группу атрибутов на своем уровне в иерархии DIT. Этот атрибут или группа атрибутов называется относительное отличительное имя или RDN (от relative distinguished name), и несет ту же функцию, что и имя файла в каталоге.

Чтобы однозначно ссылаться на запись, вы используете её RDN в сочетании со всеми RDN её родительских записей. Эта цепочка RDN ведет назад, вверх по иерархии DIT и указывает однозначный путь к соответствующему элементу. Мы называем эту цепочку RDN различимым именем или DN (от distinguished name). Вы должны указать DN для записи во время создания, чтобы система LDAP знала, где разместить новую запись, и могла убедиться, что RDN записи уже не используется другой записью.

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

Например, запись для человека по имени Джон Смит может быть помещена под запись «People» в организации example.com . Так как в организации может быть несколько Джонов Смитов, идентификатор пользователя может быть лучшим выбором для RDN записи. Запись может быть указана вот так:

Нам пришлось использовать объектный класс inetOrgPerson , чтобы получить доступ к атрибуту uid в данном случае (кроме того, мы ещё имеем доступ ко всем атрибутам, определенным в объектном классе person , причина этого будет понятна в следующем разделе).

GOsa2

  • Сайт проекта: oss.gonicus.de/labs/gosa.
  • Лицензия: GNU GPL.
  • Дистрибутивы: пакеты — Debian/Ubuntu, RedHat/CentOS/Fedora, openSUSE/SLES, из исходных текстов — любой *nix.

Проект GOsa2, являющийся надстройкой для популярных опенсорсных приложений, предоставляет администратору единый центр управления всей ИТ-инфраструктурой. Интерфейс позволяет управлять учетными записями *nix и Samba, правами пользователей и групп, компьютерами, списками рассылок, приложениями, настройками основных сетевых служб: DHCP, DNS, HTTP, SMTP и т. д. Разработка ведется под эгидой компании Gonicus GmbH, которая использует GOsa в своих сервисах.

Все функции вынесены в плагины (принцип «один сервис = один плагин»), поэтому админ собирает конфигурацию в соответствии со своими нуждами.

В настоящее время реализовано более 30 плагинов, обеспечивающих управление такими сервисами, как Squid, DansGuardin, Postfix, Courier-IMAP, Maildrop, GNARWL, Cyrus-SASL, OpenSSL, ISC DHCP, WebDAV, PureFTPd, PPTP, Kerberos, Asterisk, Nagios, OPSI, Netatalk, FAI, rsyslog, и серверами коллективной работы: SOGo, OpenGroupware, Kolab, Scalix. При этом все вышеуказанные плагины не обязательно должны работать на одном сервере, некоторые из них можно установить на отдельные хосты.

GOsa позволяет управлять учетными записями *nix и сервисами

Учетные записи пользователей объединяются в группы, для которых назначаются разрешенные приложения. При создании новых аккаунтов применяются шаблоны (админ создает их сам) с прописанными правами доступа к объектам. Набор разрешений ACL состоит из типа, определяющего видимость, объектов (пользователей/групп) и разрешений. Разрешения определяют все возможные действия: создание, удаление, перемещение, чтение, запись и т. д.

GOsa — единственный в нашем обзоре проект с локализованным интерфейсом управления. Правда, локализован он пока не полностью, но использование gettext позволяет при необходимости сделать это самостоятельно.

Поддерживается установка в любом дистрибутиве Linux. Разработчики рекомендуют Debian, под который создан отдельный репозиторий. Также доступны пакеты для Red Hat/CentOS/Fedora и openSUSE/SLES, но, как правило, разработчики не спешат их собирать, поэтому версии немного запаздывают. Можно использовать любой веб-сервер, однако предпочтение отдается Apache2 и nginx. Документация доступна только на английском и не поспевает за развитием проекта, многие моменты отражены в ней весьма поверхностно.

Девиз Identity Policy Audit хорошо поясняет сущность FreeIPA
 

INFO

FreeIPA используется для аутентификации и авторизации в решении oVirt для виртуализации, построенном на основе KVM.

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

Для синхронизации 389DS с Active Directory необходимо установить Windows Sync.

После установки пакета 389-ds для конфигурации 389DS следует запустить скрипт.

Утилита system-config-autentification, входящая в состав Fedora, содержит вкладку, позволяющую активировать аутентификацию через FreeIPA.

Заключение

Даже невооруженным глазом видно, что наиболее многофункциональным инструментом является GOsa2. Это решение обеспечивает управление учетными записями и многочисленными сервисами, поддерживает установку в большинстве дистрибутивов Linux, имеет локализованный интерфейс. Однако окончательный выбор зависит от конкретной задачи.

Что такое политики LDAP в Active Directory и зачем они нужны

Под термином “политики” в связи с Active Directory обычно имеются в виду групповые политики – мощное и легко расширяемое средство для централизованного управления многими настройками ОС и приложений. Некоторые ещё вспоминают “политики паролей” – PSO, которые появились с Windows Server 2008.

Однако, есть ещё одно применение термина “политики Active Directory” – благодаря объектам, которые относятся к классу , существует возможность тонкой настройки работы контроллеров домена (DC) и серверов глобального каталога (GC), а также ощутимого повышения скорости, надёжности и безопасности их функционирования. Все эти параметры будут относиться именно к клиентским запросам по LDAP и ограничивать размер ответа, занимаемую память, диапазон значений, тайм-ауты и другие подобные свойства. Давайте разберёмся что это, и как это можно (и нужно) эффективно использовать.

Вариации протокола LDAP

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

Стоит упомянуть, что вы можете увидеть некоторые варианты в обычном формате:

  • ldap://: Это основной протокол LDAP, позволяющий получить структурированный доступ к службе каталогов.
  • ldaps://: Этот вариант используется для доступа к LDAP поверх SSL/TLS. Обычно трафик LDAP не шифруется, но большинство реализаций LDAP поддерживают подобный вариант доступа. Такой способ шифрования LDAP-соединений на самом деле устарел, и вместо него рекомендуется использовать шифрование STARTTLS. Если вы работаете с LDAP через незащищенную сеть, настоятельно рекомендуется шифрование.
  • ldapi://: Это используется для указания LDAP через IPC. Это часто используется для безопасного соединения с локальной LDAP-системой в административных целях. Он связывается через внутренние сокеты вместо того, чтобы использовать открытый сетевой порт.

Все три формата используют протокол LDAP, но последние два указывают на дополнительную информацию о том, как он используется.

Рейтинг
( Пока оценок нет )
Editor
Editor/ автор статьи

Давно интересуюсь темой. Мне нравится писать о том, в чём разбираюсь.

Понравилась статья? Поделиться с друзьями:
Работатека
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: