Как установить openldap в windows

Обновлено: 04.07.2024

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

Требования

Чтобы начать работу, вы должны иметь доступ к системе с установленным и настроенным OpenLDAP. Все инструкции вы найдете в мануале Установка и настройка OpenLDAP и phpLDAPadmin в Ubuntu 14.04. Вы также должны быть знакомы с базовой терминологией LDAP.

Онлайн-конфигурация OpenLDAP

Системы LDAP собирают данные, которые они хранят, в иерархические структуры, называемые Directory Information Trees, или DIT – информационное дерево каталога. Начиная с версии 2.3, фактическая конфигурация серверов OpenLDAP осуществляется в рамках специального DIT, обычно внедряемого в запись cn=config.

Эта система конфигурации известна как онлайн-конфигурация OpenLDAP, или OLC. В отличие от устаревшего метода конфигурации, который основывается на чтении конфигурационных файлов при запуске сервиса, изменения, внесенные онлайн, выполняются немедленно и обычно не требуют перезапуска сервиса.

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

Этот мануал сосредоточен на базовом управлении OpenLDAP.

Доступ к Root DSE

Для начала рассмотрим конструкцию root DSE – это структура, которая содержит все индивидуальные DIT сервера. По сути это запись, используемая для управления всеми DIT, о которых знает сервер. Начав с этой записи, вы можете запросить данные, чтобы узнать, как организован сервер и куда идти дальше.

Чтобы запросить запись root DSE, нужно выполнить поиск с пустой (нулевой) базой поиска и областью поиска «base». Область поиска «base» означает, что возвращена будет только указанная запись. Как правило, это используется для ограничения глубины поиска, но при работе с root DSE это обязательное условие (никакая информация не будет возвращена, если в запросе выбрана другая область поиска).

Для этого нужна команда:

ldapsearch -H ldap:// -x -s base -b "" -LLL "+"

Предполагается, что вы выполняете ее с самого сервера LDAP и что вы еще не установили никаких ограничений доступа. Результаты должны выглядеть примерно так:

dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=example,dc=com
supportedControl: 2.16.840.1.113730.3.4.18
. . .
supportedLDAPVersion: 3
supportedSASLMechanisms: GS2-IAKERB
supportedSASLMechanisms: GS2-KRB5
supportedSASLMechanisms: SCRAM-SHA-1
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
entryDN:
subschemaSubentry: cn=Subschema

Мы немного сократили вывод. Вы можете увидеть важные метаданные этого LDAP-сервера. Давайте подробнее рассмотрим команду, которая сгенерировала этот вывод.

Поиск DIT-записей текущего сервера

Давайте попробуем выяснить, какие DIT-записи обслуживает данный сервер LDAP. Найти эту информацию можно в значении атрибута namingContexts, которое можно найти в выводе выше.

Если бы это была единственная необходимая информация, можно было бы построить более удобный запрос, который бы выглядел так:

ldapsearch -H ldap:// -x -s base -b "" -LLL "namingContexts"

В этом запросе вызывается точный атрибут, который нужно узнать. Базовая запись каждого DIT на сервере доступна через атрибут namingContexts. Это операционный атрибут, который обычно скрывается, но его можно вызывать явно.

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

dn:
namingContexts: dc=example,dc=com

Этот LDAP-сервер имеет только один DIT, который внедрен в запись с именем (DN) dc=example,dc=com. Возможно, это приведет к возврату нескольких значений, если сервер отвечает за дополнительные DIT.

Поиск конфигурационной DIT-записи

DIT, который может использоваться для настройки сервера OpenLDAP, не возвращается при поиске по namingContexts. Корневая запись конфигурацинного DIT сохраняется в специальном атрибуте configContext.

Чтобы узнать базовое DN для конфигурационного DIT, запросите этот конкретный атрибут:

ldapsearch -H ldap:// -x -s base -b "" -LLL "configContext"
dn:
configContext: cn=config

Конфигурационный DIT основан на DN cn=config. Поскольку вполне вероятно, что это точно соответствует вашему конфигурационному DIT, мы будем использовать это дальше в руководстве. Измените заданные команды, если ваш конфигурационный DIT отличается.

Доступ к конфигурационному DIT

Теперь, когда вы знаете расположение конфигурационного DIT, вы можете запросить его, чтобы увидеть текущие настройки. Для этого нужно немного отклониться от формата, который мы использовали до этого.

Поскольку этот DIT можно использовать для изменения настроек системы LDAP, у него есть некоторые элементы управления доступом. По умолчанию он настроен на поддержку управления пользователями root или sudo.

Нужная команда выглядит так:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q

Чтобы выполнить эту работу, нужно использовать sudo перед командой и заменить -x на -Y EXTERNAL, чтобы указать метод аутентификации SASL. Также необходимо изменить протокол из ldap:// на ldapi://,чтобы сделать запрос через сокет Unix. Это позволяет OpenLDAP проверить пользователя операционной системы, чьи свойства контроля доступа необходимо оценить. Затем нужно использовать запись cn=config в качестве основы для поиска.

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

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q | less

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

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q dn

Это будет гораздо более удобный список, отображающий сами записи (DN), а не весь их контент:

dn: cn=config
dn: cn=module,cn=config
dn: cn=schema,cn=config
dn: cn=core,cn=schema,cn=config
dn: cn=cosine,cn=schema,cn=config
dn: cn=nis,cn=schema,cn=config
dn: cn=inetorgperson,cn=schema,cn=config
dn: olcBackend=hdb,cn=config
dn: olcDatabase=frontend,cn=config
dn: olcDatabase=config,cn=config
dn: olcDatabase=hdb,cn=config

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

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

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q -s base

Типичными элементами в этом разделе являются глобальные параметры авторизации, параметры уровня логирования, указатель на расположение файла PID процесса и информация об аутентификации SASL.

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

Запись админа

Теперь, когда у вас есть доступ к cn= onfig DIT, можно найти rootDN всех DIT в системе. rootDN является в основном административной записью. Также можно найти пароль (обычно хэшированный), который используется для входа в эту учетную запись.

Чтобы найти rootDN каждого из ваших DIT, введите:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" "(olcRootDN=*)" olcSuffix olcRootDN olcRootPW -LLL -Q

Вы получите примерно такой результат:

dn: olcDatabase=hdb,cn=config
olcSuffix: dc=example,dc=com
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW: AOADkATWBqb0SJVbGhcIAYF+ePzQJmW+

Если ваша система обслуживает несколько DIT, вы должны увидеть блок для каждого из них. Здесь запись администратора – это cn=admin,dc=example,dc=com для DIT, основанного на dc=example,dc=com. Также здесь есть хешированный пароль.

Просмотр информации о схеме

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

Просмотр встроенных схем

Встроенные схемы можно найти в записи cn=schema,cn=config. Для этого нужно ввести:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=schema,cn=config" -s base -LLL -Q | less

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

Просмотр дополнительной схемы

Встроенная схема, скорее всего, не будет предоставлять все, что вы хотите использовать в своих записях. Вы можете добавить в свою систему дополнительную схему с помощью обычных методов LDIF. Они будут доступны в виде подзаголовков под элементом cn=schema, который представляет встроенную схему.

Обычно они содержат заключенное в скобки число, за которым следует имя схемы, например cn=core,cn=schema,cn=config. Число в скобках представляет собой индекс, используемый для определения порядка считывания схемы в системе. Обычно это делается системой автоматически.

Чтобы увидеть только имена дополнительной схемы, загруженной в систему, вы можете ввести:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=schema,cn=config" -s one -Q -LLL dn

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

dn: cn=core,cn=schema,cn=config
dn: cn=cosine,cn=schema,cn=config
dn: cn=nis,cn=schema,cn=config
dn: cn=inetorgperson,cn=schema,cn=config

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

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=inetorgperson,cn=schema,cn=config" -s base -LLL -Q | less

Чтобы увидеть все дополнительные схемы, введите:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=schema,cn=config" -s one -LLL -Q | less

Чтобы вывести все схемы, включая встроенные, введите:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=schema,cn=config" -LLL -Q | less

Параметры модулей, бэкэндов и баз данных

Некоторые другие важные области в конфигурации DIT – это модули и различные настройки технологии хранения.

Модули

Модули используются для расширения функциональности системы OpenLDAP. Эти записи используются для указания и загрузки модулей. Фактическая конфигурация выполняется с помощью других записей.

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

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

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q "objectClass=olcModuleList"

Вы увидите, какие модули загружены в систему на данный момент.

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: back_hdb

В этом конкретном примере имеется только один модуль, который позволяет нам использовать бэкэнд-модуль hdb.

Бэкэнд

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

Чтобы узнать, какие серверы активны в данной системе, введите:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q "objectClass=olcBackendConfig"

В результате вы увидите информацию о технологии хранения ваших данных.

dn: olcBackend=hdb,cn=config
objectClass: olcBackendConfig
olcBackend: hdb

Базы данных

Фактическая конфигурация этих систем хранения выполняется в отдельных записях базы данных. Записи базы данных должны быть для каждого из DIT, которые обслуживает система OpenLDAP. Доступные атрибуты будут зависеть от бэкэнда, используемого для каждой из баз данных.

Чтобы увидеть все имена записей базы данных в системе, введите:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q "olcDatabase=*" dn

Вы увидите DN для всех записей БД:

dn: olcDatabase=frontend,cn=config
dn: olcDatabase=config,cn=config
dn: olcDatabase=hdb,cn=config

Давайте рассмотрим все эти записи.

  • olcDatabase=frontend,cn=config: эта запись используется для определения функций специальной базы данных «frontend». Это псевдо-база данных, используемая для определения глобальных параметров, которые должны применяться ко всем другим базам данных (если параметры не переопределены в более узких контекстах).
  • olcDatabase=config,cn=config: эта запись используется для определения настроек cn=configdatabase, которые мы сейчас используем. В большинстве случаев это будут главным образом настройки контроля доступа, репликации и т. д.
  • olcDatabase=hdb,cn=config: эта запись определяет параметры базы данных указанного типа (в этом случае hdb). Она может определять элементы управления доступом, сведения о хранении, кэшировании и буферизации данных, а также корневые записи и административные данные DIT.

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

Вы можете увидеть содержимое любой из этих записей, введя:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "entry_to_view" -LLL -Q -s base | less

Используйте DN записи из вывода предыдущей команды, чтобы заполнить поле entry_to_view.

Отображение атрибутов записи (метаданных)

До сих пор мы работали в основном с DIT cn=config. Остальная часть этого мануала будет работать и с обычным DIT.

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

Чтобы отобразить все атрибуты записи, вы можете указать специальный атрибут «+». Например, чтобы вывести операционные атрибуты записи в dc=example,dc=com, можно ввести:

Это позволяет увидеть, кто изменил или создал запись, когда это случилось и т.д.

Работа с подсхемой

Подсхема – это представление доступных классов и атрибутов. Она показывает аналогичную информацию для записей схемы в cn=config DIT с некоторой дополнительной информацией. Она доступна в обычных DIT, поэтому корневой доступ не требуется.

Поиск подсхемы

Чтобы найти записи подсхемы, вы можете запросить все рабочие атрибуты записи, как показано выше, или запросить конкретный атрибут, который определяет подсхему (subschemaSubentry):

ldapsearch -H ldap:// -x -s base -b "dc=example,dc=com" -LLL subschemaSubentry
[list subchema entry] dn: dc=chilidonuts,dc=tk
subschemaSubentry: cn=Subschema

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

Отображение подсхемы

Чтобы просмотреть содержимое записи подсхемы, нужно запросить запись подсхемы, найденную выше, с областью «base». Вся важная информация хранится в операционных атрибутах, поэтому придется снова использовать специальный селектор «+».

ldapsearch -H ldap:// -x -s base -b "<^>cn=subschema" -LLL "+" | less

Команда выведет всю запись подсхемы. Вы можете отфильтровать вывод на основе типа искомой информации.

Если вы хотите увидеть определения синтаксиса LDAP, вы можете отфильтровать их так:

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL ldapSyntaxes | less

Если вы хотите просмотреть определения, которые контролируют обработку запросов для соответствия вхождениям, введите:

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL matchingRules | less

Чтобы узнать, какие элементы могут использовать правила соответствия, введите:

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL matchingRuleUse | less

Чтобы просмотреть определения доступных типов атрибутов, используйте:

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL attributeTypes | less

Просмотреть определения objectClass можно так:

ldapsearch -H ldap:// -x -s base -b "cn=subschema" -LLL objectClasses | less

Заключение

Работа с сервером OpenLDAP может показаться сложной на первый взгляд, но знакомство с конфигурацией DIT и поиск метаданных в системе поможет вам. Изменение cn=config DIT может сразу же повлиять на запущенную систему. Кроме того, управление системой с помощью DIT позволяет вам настроить удаленное администрирование с помощью инструментов LDAP. Это означает, что вы можете отделить администрирование LDAP от управления сервером.

В последнее время, из-за потребностей проекта, нам нужно настроить сервер LDAP для тестирования и записать его.

Установка: Это относительно просто, далее весь порт по умолчанию - 389, секретный пароль сервера по умолчанию для LDAP, база данных фонового механизма - BDB (Berkeley DataBase);

Учетная запись администратора LDAP. Эта учетная запись может использоваться для добавления, удаления и изменения записей в LDAP. Это более важно и является независимо настроенным файлом. Найдите файл slapd.conf в каталоге установки OpenLDAP и измените

Суффикс является префиксом DN, и все записи LDAP, добавленные после него, должны принадлежать этому пути.

Rootdn указывает администратора, а имя администратора - Manager, который также должен следовать по полному пути, аналогичному имени пакета JAVA.

Windows поддерживает два метода запуска: сервис и CLI. Для отладки и просмотра выходных данных журнала мы используем метод CLI для запуска, сначала останавливаем службу LDAP, которая была запущена в службе Windows, а затем используем slapd для запуска каталога LDAP. Другие статьи в Интернете могут быть запущены без указания файла slapd.conf. Не проверено, команда, которую я могу запустить здесь:

-F указывает информацию, считанную в slapd.conf, а -d относится к уровню отладки. После запуска интерфейса:



После успешного запуска это пустой LDAP. Нам нужно импортировать некоторые тестовые данные. LDAP может импортировать дерево каталогов через файл LDIF. Команда import для нашей версии Windows - через команду slapadd.

Что мне нужно, так это группа, и в ней есть несколько пользовательских структур. Файл LDIF этой структуры выглядит следующим образом:

Вставьте и сохраните вышеуказанное содержимое в файл user3.ldif и импортируйте его через slapadd -v -l ./user3.ldif:

Редактировать файл ldif вручную сложно. Мы можем управлять LDAP графически с помощью стороннего инструмента ldapadmin.

После установки войдите на наш сервер LDAP, интерфейс настройки выглядит следующим образом:



Последние очень просты, добавьте их графически.


Класс Object хранит имена DN каждого пользователя в атрибутах groupOfNames, memeber.

Эта статья взята из " Чжу Кунронг "Блог, пожалуйста, держите этот источник

Развертывание LDAP в CentOS в качестве агента сервера каталогов, агента системы каталогов или DSA (все эти сокращения одинаковы) аналогично более ранним установкам Novell Netware с использованием структуры дерева каталогов с NDS.

Краткая история LDAP

LDAP был в основном создан как эффективный способ доступа к каталогам X.500 с помощью корпоративных ресурсов. И X.500, и LDAP имеют одинаковые характеристики и настолько похожи, что клиенты LDAP могут обращаться к каталогам X.500 с некоторыми помощниками. Хотя LDAP также имеет свой собственный сервер каталогов под названием slapd . Основное различие между LDAP и DAP состоит в том, что облегченная версия предназначена для работы через TCP.

В то время как DAP использует полную модель OSI. С появлением Интернета, TCP / IP и Ethernet в современных сетях редко можно встретить имплантацию служб каталогов, использующую как DAP, так и собственные корпоративные каталоги X.500, выходящие за рамки конкретных моделей устаревших вычислений.

Основные компоненты, используемые с openldap для CentOS Linux:

OpenLDAP Библиотеки поддержки LDAP
OpenLDAP-сервер Сервер LDAP
OpenLDAP-клиенты Клиентские возможности LDAP
OpenLDAP-разви Библиотеки разработки для OpenLDAP
Компай-OpenLDAP Общие библиотеки OpenLDAP
Slapd Сервер каталогов демон OpenLDAP
Slurpd Используется для репликации LDAP через домен предприятия

Установите Open LDAP на CentOS

Установите openldap, openldap-серверы, openldap-клиенты и миграционные инструменты из YUM .

Теперь давайте убедимся, что у нас есть структура openldap в / etc / openldap .

Затем убедитесь, что наш сервис slapd запущен.

Далее, давайте настроим нашу установку Open LDAP .

Убедитесь, что наш системный пользователь ldap создан.

Создайте наши учетные данные LDAP.

Нам нужно сохранить вывод из slappasswd.

Настроить Open LDAP

Во-первых, мы хотим настроить нашу среду openLDAP. Ниже приведен шаблон для использования с командой ldapmodify .

Блог про Linux, Bash и другие информационные технологии

LDAP расшифровывается как Lightweight Directory Access Protocol, облегченный протокол доступа к каталогам. Это достаточно простой протокол, который позволяет производить операции аутентификации, поиска данных, сравнения, добавления, изменения и удаления записей. Сами каталоги используются для хранения структурированной информации. К сожалению, настройка LDAP для неподготовленного человека может быть сложна без предварительной подготовки. Поэтому давайте разберемся, что это такое и как это работает.

Установка OpenLDAP

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

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

Если вам нужна самая свежая версия OpenLDAP, то исходные коды можно скачать на официальном сайте.

Схемы LDAP

top
organization
organizationalUnit
person
inetOrgPerson

При создании объекта вы указываете, к каким классам он относится и, исходя из этого, можно задавать соответствующие атрибуты. Примеры чуть ниже. Файлы схем хранятся в директории /etc/ldap/slapd.d/cn=config/cn=schema. В них хранятся описания классов объектов и атрибутов. Для просмотра объектов, которые используются в данный момент, используется команда

Она выводит содержимое базы данных объектов.

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

Настройка OpenLDAP

Вы увидите такой экран:

Вводим пароль администратора LDAP-сервера. Пароль желательно вводить сложный, это как-никак пароль администратора. Нажимаем ОК.

Повторяем пароль, нажимаем OK

На вопрос удалять ли базу данных при вычистке slapd отвечаем утвердительно

На вопрос о перемещении старой базы данных также отвечаем утвердительно

На предложение включить старый протокол LDAPv2 отвечаем No/Нет

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

Проверим, есть ли данные в базе:

Можно сразу проверить, правильно ли работает сервер OpenLDAP. Это можно сделать следующей командой:

После ввода команды будет запрошен пароль. Если вы не хотите вводить пароль в интерактивном режиме, вы можете использовать параметр -w:

Результат команды поиска будет выглядеть следующим образом:

Можно продолжать настройку

Нажимаем Ctrl+C для выхода

Теперь надо проверить, внесены ли данные:

Всё верно, и теперь можно внести первого пользователя. Сначала сгенерируем хэш пароля для пользователя.

Этот хэш нам понадобится при создании пользователя

Снова запускаем ldapmodify и создаем пользователя. По окончании ввода значений полей дважды нажимаем Enter

После ввода нажимаем Ctrl+C и выходим

Проверяем, есть ли запись с uid=jdoe:

Запись есть, отлично. Теперь надо проверить аутентификацию:

После ввода правильного пароля получаем запрошенную информацию

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

И задать для этой записи пароль. Эти две записи будут существовать в одно и то же время, поэтому вам нужно заранее подумать о том, какое поле вы будете использовать для аутентификации.

date

23.03.2020

directory

Windows Server 2012 R2

comments

комментария 23

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

Так, например, операция смены пароля должна обязательно осуществляться через безопасный канал (например Kerberos или SSL/TLS). Это означает, что например, с помощью функции-php, обеспечивающей работу с AD по протоколу LDAP изменить пароль пользователя в домене не удастся.

Защитить данные, передаваемых по протоколу LDAP между клиентом и контроллером домена можно с помощью SSL версии протокола LDAP – LDAPS, который работает по порту 636 (LDAP «живет» на порту 389). Для этого на контроллере домена необходимо установить специальный SSL сертификат. Сертификат может быть как сторонним, выданным 3-ей стороной (например, Verisign), самоподписанным или выданным корпоративным центром сертификации.

В этой статье мы покажем, как с помощью установки сертификата задействовать LDAPS (LDAP over Secure Sockets Layer) на котроллере домена под управление Windows Server 2012 R2. При наличии требуемого сертификата служба LDAP на контроллере домена может устанавливать SSL соединения для передачи трафика LDAP и трафика сервера глобального каталога (GC).

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

Предположим, в вашей инфраструктуре уже развернут корпоративный удостоверяющий сервер Certification Authority (CA). Это может быть как полноценная инфраструктура PKI, так и отдельной-стоящий сервер с ролью Certification Authority.

Управление шаблонами сертификатов в консоли Certification Authority

На севере с ролью Certification Authority запустите консоль Certification Authority Management Console, выберите раздел шаблонов сертификатов (Certificate Templates ) и в контекстном меню выберите Manage.

Копируем шаблон сертификата

Найдите шаблон Kerberos Authentication certificate и создайте его копию, выбрав в меню Duplicate Template.

Шаблон сертифката LDAP over SSL

На вкладке General переименуйте шаблон сертификата в LDAPoverSSL, укажите период его действия и опубликуйте его в AD (Publish certificate in Active Directory).

На вкладке Request Handling поставьте чекбокс у пункта Allow private key to be exported и сохраните шаблон.

Разрешить экспортировать закрытый ключ сертификата

На базе созданного шаблона, опубликуем новый тип сертификата. Для этого, в контекстном меню раздела Certificate Templates выберем пункт New -> Certificate Template to issue.

Публикация шаблона сертфиката

Из списка доступных шаблонов выберите LDAPoverSSL и нажмите OK.

Выбор шаблона для нового сертфиката

На контроллере домена, для которого планируется задействовать LDAPS, откройте оснастку управления сертификатами и в хранилище сертификатов Personal запросим новый сертификат (All Tasks -> Request New Certificate).

Запросить новый сертификат

В списке доступных сертификатов выберите сертификат LDAPoverSSL и нажмите Enroll (выпустить сертификат).

Выпустить сертификат

Следующее требование – необходимо, чтобы контроллер домена и клиенты, которые будут взаимодействовать через LDAPS доверяли удостоверяющему центру (CA), который выдал сертификат для контроллера домена.

Экспорт корневого сертификата CA

Если это еще не сделано, экспортируем корневой сертификат удостоверяющего центра в файл, выполнив на сервере с ролью Certification Authority команду:
certutil -ca.cert ca_name.cer

Совет. Файл сертификата сохранится в профиле текущего пользователя и в нашем случае имеет имя ca_name.cer.

А затем добавьте экспортированный сертификат в контейнере сертификатов Trusted Root Certification Authorities хранилища сертификатов на клиенте и контроллере домена. Сделать это можно через вручную через оснастку управления сертификатами, через GPO или из командной строки (подробнее здесь).

certmgr.exe -add C:\ca_name.cer -s -r localMachine ROOT

Необходимо перезапустить службы Active Directory на контроллере домена, либо целиком перезагрузить DC.

Осталось протестировать работу по LDAPS. Для этого на клиенте запустим утилиту ldp.exe и в меню выбираем Connection-> Connect->Укажите полное (FQDN) имя контроллера домена, выберите порт 636 и отметьте SSL -> OK. Если все сделано правильно, подключение должно установиться.

Читайте также: