Windows ldap server: LDAP. Настройка отказоустойчивого LDAP сервера / Хабр
LDAP. Настройка отказоустойчивого LDAP сервера / Хабр
В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).
Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.
Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)
Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:
- Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
- Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
- Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback’ов, репликация работает без проблем, которые присущи RDBMS;
- Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
- Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.
Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).
Ключевые особенности этого LDAP-сервера:
- Мультимастер репликация. На все сервера, участники MM-репликации, можно записывать данные одновременно, причем конфликты репликации разрешаются автоматически благодаря ведению changelog базы и системе автоматического разрешения конфликтов. MM-репликацию можно комбинировать с master-slave и каскадной репликацией, благодаря чему можно получить гибкий и масштабируемый сервис. Так же поддерживается частичная репликация, что крайне полезно, если мы не хотим, чтобы некоторые данные присутствовали на реплике;
- Мощный механизм ACL. С помощью ACL можно указать кому, когда, на каком LDAP-сервере, с каким атрибутом и какое действие выполнять. ACL хранится вместе с данными как операционные атрибуты, благодаря этому для них, как и для других данных, работают операции репликации и резервного копирования.
- Синхронизация с Microsoft Active Directory. Поддерживается двунаправленная синхронизация пользователей, групп и паролей (для синхронизации паролей из AD в 389-ds необходимо поставить специальный софт на каждый контроллер домена)
- SSL/TLS. Простой поддержкой SSL/TLS сейчас никого не удивишь. 389-ds поддерживает аутентификацию/авторизацию на основании SSL-сертификатов. Так же есть возможность шифрования атрибутов при записи на диск. При ручном вводе ключа при запуске сервера это может защитить от утечки данных путем копирования файлов с БД.
- Управление сервером через протокол LDAP. Сервер поддерживает конфигурацию путем изменения атрибутов в cn=config, большинство параметров применяются без перезагрузки сервера. Так же на сервере можно запускать резервное копирование/восстановление и другие task-и путем добавления новой записи в cn=tasks,cn=config.
- Plugins. Весь функционал реализован в виде plugin-ов (MM-репликация, синхронизация с AD, ACL, и т.п.). Написать и добавить свой plugin довольно легко, т.к. имеется хорошая документация с примерами.
После обзора возможностей 389 Directory Server познакомимся поближе с его структурой.
Общая структура 389 Directory Server
389 DS состоит из нескольких компонентов.
- Сам сервер каталогов. Это приложение ns-slapd, именно этот процесс принимает и обрабатывает запросы от клиента, производит репликацию, читает и записывает данные в базу, передает управление плагинам, и т.д.
- Сервер администрирования (Administration Server). Он управляет сервером каталогов. Сервер предоставляет интерфейс управления через протокол HTTP(S), так же предоставляет веб-интерфейс для просмотра логов и статуса репликации. Физически это apache + модули для управления ns-slapd.
- Консоль администрирования. Java-приложение, которое подключается к серверу администрирования и позволяет настраивать сервер каталогов через удобный интерфейс. Есть версия под windows и linux, под mac os работает через проброс X-сессии с linux-машины.
Сначала я хотел написать теоретическую и практическую части отдельно, но потом стало ясно, что первая часть стала бы слишком скучной, а вторая слишком сухой. Поэтому сразу за куском теории будет идти практическое применение.
Итак, задача. Необходимо настроить отказоустойчивый сервис службы каталогов. Для этого настроим два сервера, настроим multimaster-репликацию между ними и поднимем перемещающийся IP-адрес (pacemaker + openais).
Если один из серверов станет недоступен, другой возьмет на себя этот IP и сервис продолжит работу.
После восстановления сервера данные будут реплицированы на него и IP-адрес переключится обратно на LDAP00, или же, в зависимости от настройки кластера, останется на LDAP01.
На одном сервере может быть несколько изолированных инстансов ns-slapd со своими настройками, схемой, правилами репликации и т.д. Чтобы иметь возможность управлять этими инстансами из консоли управления на каждом сервере должен стоять сервер Administration Server (далее admin server). admin server сам нуждается в одном инстансе LDAP сервера, поскольку хранит там run-time конфигурацию. По умолчанию конфигурация admin server хранится вместе с пользовательскими данными, но я считаю это небезопасным, поэтому у нас будет два инстанса на каждом сервере: один будет содержать конфигурацию для admin server-а, а второй данные. В такой схеме в случае отказа одной из нод сохраняется не только работоспособность LDAP-сервиса, но и возможность управления им.
Для нашего сервиса службы каталогов мы используем два сервера ldap00 и ldap01. На каждом из них будут установлены два инстанса LDAP сервера, один для нужд admin server-ов, второй для наших данных.
План установки будет такой:
- Установка первого сервера на ldap00;
- Настройка репликации на ldap00;
- Установка и настройка ldap инстанса на ldap01;
- Установка admin server-а на ldap01;
- Установка и настройка ldap инстансов для хранения пользовательских данных.
Установка первого сервера на ldap00
Готовые rpm собраны в репозитории EPEL для Centos, RHEL и Fedora Core. Если у вас одна из этих систем — подключите репозиторий EPEL и выполните установку через yum.
Мы используем SLES, поэтому нам пришлось собирать все пакеты под эту систему в нашем OpenSUSE Build Service. Если у вас debian/ubuntu — прочтите этот документ.
Вместе с 389 DS идет набор perl скриптов, которые используются для установки инстансов сервера.
Вот некоторые из них:
- setup-ds.pl — устанавливает инстанс LDAP-сервера, сервер создается не подключенным к admin server-у;
- setup-ds-admin.pl — устанавливает admin server, при необходимости устанавливает инстанс LDAP-сервера для хранения своей конфигурации;
- register-ds-admin.pl — подключает инстанс к admin server-у, при необходимости устанавливает admin server;
- remove-ds.pl — удаляет инстанс;
- remove-ds-admin.pl — удаляет admin server и все инстансы;
- dsktune — выводит параметры системы, которые нужно изменить, чтобы добиться большей производительности.
Для начала запустим dsktune:
ldap00:~ # dsktune
389 Directory Server system tuning analysis version 10-AUGUST-2007.NOTICE: System is x86_64-unknown-linux2.6.27.42-0.1-xen (1 processor).
NOTICE: The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.WARNING: There are only 1024 file descriptors (hard limit) available, which
limit the number of simultaneous connections.WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.
Утилита написала о системных параметрах, которые нужно подкрутить. В моем случае это net.ipv4.tcp_keepalive_time и лимит открытых файлов.
tcp_keepalive_time — это время от последнего посланного пакета до первой посылки keepalive. При большом значении, если клиент «умер», соединение останется открытым долгое время (по умолчанию 120 минут). Установим это значение в 10 минут.
echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time
Добавим в /etc/sysctl.conf:
net.ipv4.tcp_keepalive_time = 600
для увеличения лимита открытых файлов добавляем в /etc/security/limits.conf:
* - nofile 8192
запускаем еще раз dsktune и убедимся, что у нас все готово для установки.
Теперь запускаем скрипт setup-ds-admin.pl
Нас спросят, хотим ли мы установить 389 Directory и Administration Server, согласны ли мы с лицензией, еще раз запустят dsktune и, наконец, появится меню выбора типа установки.
Choose a setup type:
1. Express
Allows you to quickly set up the servers using the most
common options and pre-defined defaults. Useful for quick
evaluation of the products.2. Typical
Allows you to specify common defaults and options.3. Custom
Allows you to specify more advanced options. This is
recommended for experienced server administrators only.To accept the default shown in brackets, press the Enter key.
Choose a setup type [2]:
Выбираем третий пункт (мы же experienced server administrators =) )
Далее будет предложено указать FQDN и имя/группу, от которого(ой) будет запускаться LDAP-сервер.
If you do not yet have a configuration directory server, enter ‘No’ to
be prompted to set up one.Do you want to register this software with an existing
configuration directory server? [no]:
Тут нас спрашивают, хотим ли мы использовать существующий сервер каталогов для сохранения информации о сервере. Так как это наш первый сервер, отвечаем No.
Далее идут вопросы об admin server-е: administrator ID, пароль, Administration Domain, ответы на них оставляем по умолчанию (кроме пароля).
Затем надо будет указать, какой порт будет слушать LDAP-сервер. Мы договорились, что это инстанс, который хранит лишь конфигурацию для admin server-а, поэтому пересаживаем его на порт 6389. Далее указываем Directory server identifier. Назовем свой инстанс config-instance. На вопрос о суффиксе корневого дерева отвечаем по умолчанию, корневого дерева в этом инстансе не будет, так что его потом можно удалить.
Затем нас ждет вопрос о Directory Manager DN.
Directory Manager — это пользователь с правами root-а в LDAP-сервере. У каждого инстанса есть свой локальный Directory Manager.
Далее следуют вопросы о пароле к Directory Manager-у, хотим ли мы поставить примеры записей в наш root suffix и хотим ли мы заполнить наш новый инстанс какими-нибудь данными, спросят имя порта, IP-адрес и имя пользователя от которого admin server будет работать. После этого последний раз спросят подтверждение и начнут установку.
Настройка репликации на ldap00
Для подключения к серверу нужно поставить и запустить консоль управления 389-console.
В качестве Adminstration URL нужно ввести адрес admin server-а и порт который вы указали при установке.
Далее мы попадаем в панель управления серверами. У нас сейчас только один инстанс, выберем его.
Из консоли управления удаляем суффикс dc=edu,dc=scalaxy,dc=local
У нас остался всего один суффикс и база, в которой находятся конфигурационные данные для admin server-а.
Теперь немного теории о принципах репликации.
В репликации участвуют два типа серверов, supplier и consumer.
supplier — сервер, который копирует реплику на другой сервер.
обязанности supplier сервера:
- отвечать на запросы клиентов на чтение и запись;
- поддержание информации о состоянии изменений реплики;
- инициализация репликации на consumer сервера.
supplier сервер должен быть всегда доступен, поскольку запись производится только на этом сервере, а потом реплицируется на другие севера.
Если связь с supplier сервером будет потеряна, то запись в каталог станет невозможна.
consumer — сервер, который сохраняет реплику с другого сервера. В случае с мультимастер репликацией, два сервера одновременно являются supplier-ом и consumer-ом.
consumer должен:
- отвечать на read запросы клиентов;
- пересылать запросы на обновления данных на сервер;
- при получении запроса на добавление, удаление или обновления записи, запрос пересылается на supplier сервер.
Каждый supplier сервер имеет свой changelog, в котором хранится информация обо всех изменениях, которые произошли на реплике.
Supplier сервер повторяет эти изменения на каждом consumer сервере.
Теперь, когда мы немного подкованы теоретически, можно настраивать мультимастер репликацию инстанса с конфигурацией.
Ведение changelog-а изменений по умолчанию выключено, включается он во вкладке Replication. Changelog включается для всех баз одновременно.
Дальше включаем репликацию для базы NetscapeRoot. Необходимо указать Replica ID и Supplier DNs.
Supplier DN — это имя пользователя, которому разрешено выполнять репликацию на LDAP-сервере. Такого пользователя нужно создать на всех LDAP-серверах, которые участвуют в мультимастер репликации.
Быстрее всего это сделать через утилиту ldapmodify. Эта утилита позволяет модифицировать данные в LDAP в интерактивном режиме или брать команды из ldif файла.
ldapmodify -h 127.0.0.1 -p 6389 -x -D "cn=root" -W
Enter LDAP Password:
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword: <password>
passwordExpirationTime: 20380119031407Z
Ответ должен бытьadding new entry "cn=replication manager,cn=config"
Итого, у нас получилось:
Сразу же создадим Replication Agreement для второго сервера. В контекстном меню для базы NetscapeRoot выбираем New Replication Agreement и заполняем аналогичным образом:
Нас предупредят, что подключение к серверу невозможно (так как его еще нет), доходим до последнего пункта, ставим Do not initialize consumer.
Установка и настройка ldap инстанса на ldap01
Теперь нужно настроить второй LDAP-сервер. С ним несколько иначе, т.к. установка admin server-а должна уже происходить в установленный LDAP-сервер и первичную настройку мы будем производить из консоли с помощью утилиты ldapmodify (что является нехилым плюсом, если стоит задача разобраться, как же работает этот сервер каталогов).
Сначала на втором сервере с помощью скрипта setup-ds.pl нужно создать инстанс, который не управляется admin server-ом.
Ответы на вопросы скрипта аналогичны предыдущим.
После установки LDAP-сервера подключаемся к нему через ldapmodify и настраиваем.
Подключение производится примерно так:
ldapmodify -h 127.0.0.1 -p 6389 -D "cn=root" -W
1) Включаем changelog:
dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap01/changelogdb
changelogdir должен указывать на директорию с названием вашего инстанса.
2) добавляем пользователя replication manager:
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword: <passowrd>
passwordExpirationTime: 20380119031407Z
20380119031407Z означает, что срок действия пароля не ограничен.
3) Создаем суффикс netscaperoot:
dn: cn="o=netscaperoot",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: NetscapeRoot
cn: "o=netscaperoot"
4) Создаем базу для суффикса netscaperoot:
dn: cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: o=netscaperoot
Кстати, 389 DS по умолчанию для хранения записей каталога использует модифицированную версию нереляционной базы данных Berkeley DB. Если есть желание, подробнее вы можете прочитать тут.
5) Создаем корневой o=NetScapeRoot:
dn: o=NetscapeRoot
changetype: add
objectClass: organization
objectClass: top
o: NetscapeRoot
6) Разрешаем репликацию для o=netscaperoot:
dn: cn=replica,cn="o=netscaperoot", cn=mapping tree, cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaId: 2
nsDS5ReplicaRoot: o=netscaperoot
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsds5ReplicaChangeCount: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaType: 3
Не забываем изменить nsDS5ReplicaId на номер вашего сервера (nsDS5ReplicaType — тип репликации, 3 — multimaster).
На данном этапе у нас уже есть настроенная репликация в одну сторону с ldap00 на ldap01.
Последним этапом будет:
7) Настройка репликации от ldap01 на ldap00:
dn: cn=Multimaster replication, cn=replica, cn="o=netscaperoot", cn=mapping
tree, cn=config
changetype: add
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Multimaster replication
description: replication for netscaperoot
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsds5replicaChangesSentSinceStartup:
nsDS5ReplicaCredentials: <password>
nsDS5ReplicaHost: ldap00.edu.scalaxy.local
nsDS5ReplicaPort: 6389
nsDS5ReplicaRoot: o=netscaperoot
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaUpdateInProgress: FALSE
nsDS5ReplicaBindDN — имя пользователя, от имени которого будет производится репликация
nsDS5ReplicaCredentials — пароль
8) Первичная инициилизация репликации с ldap00 на ldap01:
На первом сервере выполняем эту команду:dn: cn=Multimaster replication,cn=replica,cn="o=netscaperoot",cn=mapping tree,cn=config
changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start
Эта команда реплицирует данные с ldap00 на ldap01, эта операция обязательна, тк на втором сервер сейчас пустой o=netscaperoot.
Теперь мы имеем полностью реплицируемые каталоги с конфигурацией admin server-а.
Установка admin server-а на ldap01
Нужно поднять admin server на втором сервере. Запускаем скрипт register-ds-admin.pl
Когда нам предложат указать Configuration directory server URL, вводим LDAP URL второго сервера ldap://ldap01.edu.scalaxy.local:6389/o=NetscapeRoot
Дальнейшая настройка тривиальна, следуем указаниям скрипта.
Установка и настройка ldap инстансов для хранения пользовательских данных
Теперь подключаться через консоль управления можно к любому admin server-у.
На каждом из серверов в Server Group создаем новый инстанс LDAP server-а, это будет LDAP-server, в котором мы будем хранить наши данные.
Настраиваем мультимастер репликацию между двумя инстансами по тому же принципу (теперь вы можете настроить репликацию как через GUI, так и через консоль).
Поздравляю! Вы настроили отказоустойчивый сервис службы каталогов! Далее нужно настроить openais+pacemaker, чтобы исключить простои в работе сервиса.
Использовалась документация:
directory.fedoraproject.org/wiki/Documentation
www.redhat.com/docs/manuals/dir-server
LDAP: Установка и настройка LDAP-сервера
LDAP расшифровывается как Lightweight Directory Access Protocol, облегченный протокол доступа к каталогам. Это достаточно простой протокол, который позволяет производить операции аутентификации, поиска данных, сравнения, добавления, изменения и удаления записей. Сами каталоги используются для хранения структурированной информации. К сожалению, настройка LDAP для неподготовленного человека может быть сложна без предварительной подготовки. Поэтому давайте разберемся, что это такое и как это работает.
Установка OpenLDAP
Для всех современных дистрибутивов в официальных репозиториях есть уже готовые пакеты, поэтому установка обычно сводится к установке соответствующих пакетов:
apt-get install slapd ldap-utils
По зависимостям будет установлено еще несколько пакетов. При установке будет запрошен пароль пользователя admin. Задавайте любой, мы все равно будем после установки задавать собственную конфигурацию.
Если вам нужна самая свежая версия OpenLDAP, то исходные коды можно скачать на официальном сайте.
Схемы LDAP
По умолчанию OpenLDAP включает уже готовые схемы. Схемы — это структуры, определяющие объекты, используемые в системе каталогов. Схемы включают в себя классы объектов, у каждого класса есть определенный набор атрибутов. Каждая запись может относиться к одному или нескольким классам и, соответственно, иметь те наборы атрибутов, которые включены в соответствующие классы. В терминологии LDAP классы так и называются — ObjectClass. Вот несколько классов объектов, которые можно использовать:
top
organization
organizationalUnit
person
inetOrgPerson
При создании объекта вы указываете, к каким классам он относится и, исходя из этого, можно задавать соответствующие атрибуты. Примеры чуть ниже. Файлы схем хранятся в директории /etc/ldap/slapd.d/cn=config/cn=schema. В них хранятся описания классов объектов и атрибутов. Для просмотра объектов, которые используются в данный момент, используется команда
slapcat
Она выводит содержимое базы данных объектов.
# slapcat dn: dc=nodomain objectClass: top objectClass: dcObject objectClass: organization o: nodomain dc: nodomain structuralObjectClass: organization entryUUID: 353459a6-590e-1034-99e4-6b77cb057f89 creatorsName: cn=admin,dc=nodomain createTimestamp: 20150307120702Z entryCSN: 20150307120702.099143Z#000000#000#000000 modifiersName: cn=admin,dc=nodomain modifyTimestamp: 20150307120702Z dn: cn=admin,dc=nodomain objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9L3k1MTBJalk2WFRJMVBVY0t1NzVBSXBGVzFhSm9YTHM= structuralObjectClass: organizationalRole entryUUID: 3542135c-590e-1034-99e5-6b77cb057f89 creatorsName: cn=admin,dc=nodomain createTimestamp: 20150307120702Z entryCSN: 20150307120702.189090Z#000000#000#000000 modifiersName: cn=admin,dc=nodomain modifyTimestamp: 20150307120702Z
Редактировать файлы схемы не рекомендуется. Хотя в интернете достаточно много статей по настройке LDAP, где рекомендуют отредактировать ldif-файлы схемы, это делать не нужно, более того, в самих файлах указан комментарий о том, что файлы нельзя редактировать вручную и необходимо для редактирования использовать команду ldapmodify. К сожалению, информации об использовании этой команды гораздо меньше, чем о ручном редактировании файлов .ldif, хотя ее использование в чем-то даже проще, чем редактирование файлов напрямую.
Настройка OpenLDAP
После установки пакетов надо переконфигурировать сервер, задать свои данные. Первое, что мы сделаем — создадим свой домен «mydomain.com». Для этого выполним команду
dpkg-reconfigure slapd
Вы увидите такой экран:
Отвечаем No.
Введем данные для нашего домена. У нас это будет «mydomain.com». Нажимаем OK.
Вводим название организации «mydomain». Нажимаем OK.
Вводим пароль администратора LDAP-сервера. Пароль желательно вводить сложный, это как-никак пароль администратора. Нажимаем ОК.
Повторяем пароль, нажимаем OK
Выбираем «HDB» для типа сервера, нажимаем ОК.
На вопрос удалять ли базу данных при вычистке slapd отвечаем утвердительно
На вопрос о перемещении старой базы данных также отвечаем утвердительно
На предложение включить старый протокол LDAPv2 отвечаем No/Нет
На этом первоначальная настройка завершена. Если сервис не стартовал, запускаем его вручную командой
service slapd start
Проверим, есть ли данные в базе:
# slapcat dn: dc=mydomain,dc=com objectClass: top objectClass: dcObject objectClass: organization o: mydomain dc: mydomain structuralObjectClass: organization entryUUID: 1ee47d10-5a0e-1034-91ab-1d2fe74d4d59 creatorsName: cn=admin,dc=mydomain,dc=com createTimestamp: 20150308183855Z entryCSN: 20150308183855.828659Z#000000#000#000000 modifiersName: cn=admin,dc=mydomain,dc=com modifyTimestamp: 20150308183855Z dn: cn=admin,dc=mydomain,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9ckhnNjlMNkt3MDFJVmNFUDNGTWdQZXlHcVF4Y0NPOG4= structuralObjectClass: organizationalRole entryUUID: 1ef22a64-5a0e-1034-91ac-1d2fe74d4d59 creatorsName: cn=admin,dc=mydomain,dc=com createTimestamp: 20150308183855Z entryCSN: 20150308183855.918294Z#000000#000#000000 modifiersName: cn=admin,dc=mydomain,dc=com modifyTimestamp: 20150308183855Z
Можно сразу проверить, правильно ли работает сервер OpenLDAP. Это можно сделать следующей командой:
ldapsearch -D "cn=admin,dc=mydomain,dc=com" -W
После ввода команды будет запрошен пароль. Если вы не хотите вводить пароль в интерактивном режиме, вы можете использовать параметр -w:
ldapsearch -D "cn=admin,dc=mydomain,dc=com" -w ваш-пароль
Результат команды поиска будет выглядеть следующим образом:
# ldapsearch -D "cn=admin,dc=mydomain,dc=com" -W -b "dc=mydomain,dc=com" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=mydomain,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # mydomain.com dn: dc=mydomain,dc=com objectClass: top objectClass: dcObject objectClass: organization o: mydomain dc: mydomain # admin, mydomain.com dn: cn=admin,dc=mydomain,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9ckhnNjlMNkt3MDFJVmNFUDNGTWdQZXlHcVF4Y0NPOG4= # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2
Параметр «-b» определяет поисковую базу, то есть тот узел дерева объектов, с которого будет начинаться поиск.
Можно продолжать настройку
Создадим группу пользователей с названием «users» при помощи команды ldapmodify
# ldapmodify -D "cn=admin,dc=mydomain,dc=com" -W Enter LDAP Password: dn: ou=users,dc=mydomain,dc=com changetype: add objectClass: top objectClass: organizationalUnit ou: users description: Domain Users
Всё, начиная с «dn: » вводим руками точно так, как написано выше. После ввода строки описания («description: Domain Users») нажимаем Enter два раза. Если всё введено без ошибок, вы должны увидеть такое сообщение:
adding new entry "ou=Users,dc=mydomain,dc=com"
Нажимаем Ctrl+C для выхода
Теперь надо проверить, внесены ли данные:
# ldapsearch -D "cn=admin,dc=mydomain,dc=com" -W -b "dc=mydomain,dc=com" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=mydomain,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # mydomain.com dn: dc=mydomain,dc=com objectClass: top objectClass: dcObject objectClass: organization o: mydomain dc: mydomain # admin, mydomain.com dn: cn=admin,dc=mydomain,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9T1ZtbWxpTGI2aGNXd1ltQ0RiMjlXOGhFR2FSaGo2Ujc= # users, mydomain.com dn: ou=users,dc=mydomain,dc=com objectClass: top objectClass: organizationalUnit ou: users description: Domain Users # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3
Всё верно, и теперь можно внести первого пользователя. Сначала сгенерируем хэш пароля для пользователя.
# slappasswd
New password:
Re-enter new password:
{SSHA}OdfUh9z71wKbHxb2dQodbaqEvlqHmhwaЭтот хэш нам понадобится при создании пользователя
Снова запускаем ldapmodify и создаем пользователя. По окончании ввода значений полей дважды нажимаем Enter
# ldapmodify -D "cn=admin,dc=mydomain,dc=com" -W
Enter LDAP Password:
dn: cn=John Doe,ou=users,dc=mydomain,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: John Doe
ou: users
uid: jdoe
givenName: John
sn: Doe
userPassword: {SSHA}OdfUh9z71wKbHxb2dQodbaqEvlqHmhwa
adding new entry "cn=John Doe,ou=Users,dc=mydomain,dc=com"После ввода нажимаем Ctrl+C и выходим
Проверяем, есть ли запись с uid=jdoe:
# ldapsearch -D "cn=admin,dc=mydomain,dc=com" -b "dc=mydomain,dc=com" -W "(uid=jdoe)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=mydomain,dc=com> with scope subtree # filter: (uid=jdoe) # requesting: ALL # # John Doe, users, mydomain.com dn: cn=John Doe,ou=users,dc=mydomain,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: John Doe ou: users uid: jdoe givenName: John sn: Doe userPassword:: e1NTSEF9T2RmVWg5ejcxd0tiSHhiMmRRb2RiYXFFdmxxSG1od2E= # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
Запись есть, отлично. Теперь надо проверить аутентификацию:
# ldapsearch -D "cn=John Doe,ou=users,dc=mydomain,dc=com" -b "dc=mydomain,dc=com" -W "(uid=jdoe)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=mydomain,dc=com> with scope subtree # filter: (uid=jdoe) # requesting: ALL # # John Doe, users, mydomain.com dn: cn=John Doe,ou=Users,dc=mydomain,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: John Doe ou: users uid: jdoe givenName: John sn: Doe userPassword:: e1NTSEF9T2RmVWg5ejcxd0tiSHhiMmRRb2RiYXFFdmxxSG1od2E= # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
После ввода правильного пароля получаем запрошенную информацию
Обратите внимание на то, что даже если для записи указан uid, представляющий собой логин пользователя, вы не сможете использовать его для логина. Причина этого в том, что само поле не является первичным ключом записи. Если вы хотите использовать именно jdoe, то вам придется создать запись
dn: uid=jdoe,ou=users,dc=mydomain,dc=com
И задать для этой записи пароль. Эти две записи будут существовать в одно и то же время, поэтому вам нужно заранее подумать о том, какое поле вы будете использовать для аутентификации.
Представьте себе следующую ситуацию (она далека от реальности, но отлично передает суть).
Предположим, я делаю заказ в интернет-магазине так, чтобы его доставили мне домой в мое отсутствие. Курьер приезжает и оставляет под дверью записку с текстом «извините, мы вас не застали» и просит меня забрать заказ в ближайшем пункте выдачи в удобное время. В пункте выдачи сотрудник спрашивает мое имя, адрес и просит ключи от дома, чтобы подтвердить мою личность. Затем сотрудник службы доставки приезжает ко мне домой и открывает дверь моим ключом. Он заходит внутрь, чтобы убедиться, что я там живу, например, по фотографиям на стене или по имени адресата на корреспонденции. После этого сотрудник возвращается в пункт выдачи и сообщает мне, что успешно подтвердил мою личность, и я могу получить свою посылку! Ура!
Помимо проблем с логистикой, данная ситуация полна других вопросов. Что, если недобросовестный проверяющий сделал копию моего ключа? Или он оставил ключ надолго без присмотра, и это сделал кто-либо еще? Что, если на проверяющего напали и забрали мой ключ? Когда я отдаю ключ от своей квартиры незнакомцу, я не могу быть уверен в его порядочности и своей безопасности.
К счастью, в реальном мире у нас есть документы для подтверждения личности, например, водительские права или паспорт, которые выданы государственными органами, и их подлинность не вызывает сомнений. Я могу предоставить эти документы курьеру для собственной идентификации без передачи ключей.
В мире LDAP мы все еще должны передавать наши ключи, чтобы открыть дверь от нашего имени. Мы передаем наш пароль стороннему лицу, и он пытается с его помощью проникнуть на сервер LDAP. Если ему удается получить доступ, мы не можем быть уверены, что наши учетные данные не скомпрометированы. При этом злоумышленник получит не только возможность разблокировать дверь LDAP, но и доступ к любому приложению, использующему те же учетные данные.
К счастью, в более полном мире аутентификации у нас также есть паспорта и водительские права! Протоколы аутентификации, такие как Kerberos, SAML и OpenID Connect, выпускают токены третьим лицам. Токены подтверждают, что вы являетесь тем, за кого себя выдаете, и нет необходимости передавать кому-либо свои ключи. Поскольку LDAP никогда не разрабатывался как протокол аутентификации, соответствующие механизмы у него отсутствуют.
Недостатки LDAP как системы аутентификации
В 2007 году Шумон Хак выпустил фантастическую статью (LDAP Weaknesses as a Central Authentication System), в которой он описывает три конкретные проблемы при использовании LDAP в качестве системы аутентификации.
1. Приложение, вероятно, недостаточно защищено, чтобы оперировать учетными данными
Автор подчеркивает, что защитить от атаки небольшой набор серверов аутентификации гораздо проще, чем защитить большое количество серверов приложений.
В своем большинстве серверы аутентификации, как правило, находятся под тщательным присмотром специалистов, обладающих значительным опытом в области информационной безопасности.
С другой стороны, серверы приложений имеют совершенно иной уровень безопасности и более подвержены риску компрометации. Они менее защищены, работают с более сложными программными стеками и с большей вероятностью имеют уязвимости. И чаще они находятся под управлением людей, которые не имеют глубоких знаний о безопасности. Построение правильной системы безопасности — сложнейший процесс, в котором очень легко допустить ошибку.
Проблема заключается в том, что если один сервер приложений скомпрометирован, то все учетные данные, которыми пользовались их владельцы во время атаки, также скомпрометированы. Под угрозой находится и любая другая система, которая использует тот же каталог LDAP для аутентификации.
2. Сервер LDAP не может обеспечить безопасность механизма аутентификации, используемого для получения учетных данных
LDAP-сервер не может гарантировать безопасность транзакции. Несмотря на то, что LDAP-сервер, например, может обеспечить принудительное выполнение операции bind по TLS, чтобы гарантировать, что учетные данные не передаются в открытом виде, сам сервер никогда не принимал никакой роли в получении учетных данных от пользователя. Существует риск, что приложение будет получать пароль по небезопасному каналу.
3. Пользователь вынужден делиться своим секретом аутентификации с третьей стороной
Пароль пользователя или секрет аутентификации должен оставаться секретом. Он должен быть известен только самому пользователю и системе аутентификации. При использовании LDAP-аутентификации пользователь вынужден поделиться своим секретом с третьей стороной, чтобы она затем смогла использовать данный секрет для взаимодействия с LDAP-каталогом от имени пользователя.
Важно упомянуть, что при использовании специально предназначенных протоколов аутентификации, таких как Kerberos, и даже с более раннего — NTLM, секрет пользователя никогда не передается по сети. Клиентское устройство и сервер используют криптографические операции, чтобы доказать друг другу, что у них один и тот же секрет и при этом даже не обмениваются самим секретом.
К пунктам Шумона Хука добавлю описание нескольких нюансов LDAP-аутентификации, основываясь на собственном опыте. Прежде всего, тема касается использования Active Directory.
4. Многие разработчики знают о механизмах работы LDAP недостаточно, чтобы правильно его использовать
В одном из моих прошлых постов блога описывается, как анонимные и неаутентифицированные bind’ы позволяли обхитрить разработчиков приложений и заставляли пропускать неавторизованных пользователей. Возможность выполнения операции bind без проверки подлинности — одна из тонкостей протокола, о которой не знают даже самые опытные специалисты по LDAP.
Каталоги устроены непросто и способны хранить огромное количество организационной информации и предоставляют множество настраиваемых способов ее хранения. Я видел очень много случаев, когда разработчик приложения предполагал, что существует определенный класс объекта или атрибут, а когда их не обнаруживалось, приложение падало. Для аутентификации пользователя не должны требоваться и применяться знания о структуре данных, хранящихся в каталоге. Протокол аутентификации должен абстрагироваться от деталей хранилища объектов, расположенного уровнем ниже.
5. Администраторы приложений зачастую не настраивают LDAP-клиенты корректным образом
При управлении Active Directory в большой распределенной среде есть один неприятный нюанс: трудно определить, какие конкретно приложения используют Active Directory в качестве LDAP-каталога, и как именно администраторы приложений настроили LDAP-клиент.
Ниже представлены примеры ужасов некорректной настройки.
- Хардкодинг DN в приложениях или использование DN при выполнении операции bind. Постоянно случаются неприятности при переименовании или перемещении объектов внутри директории, а все потому, что кто-то где-то захардкодил DN. (Примечание для тех, кто выполняет простые операции bind с Active Directory: нет необходимости использовать DN. Active Directory также предоставляет альтернативные форматы DN, которые являются более надежными, чем использование традиционного формата).
- Для операции bind используется не сервисный аккаунт, а персональный аккаунт разработчика или администратора (представьте, что будет, когда владелец аккаунта покинет компанию).
- Отправка паролей в открытом виде на 389-й порт.
- Существуют приложения, где чекбокс «Валидировать сертификат» не является обязательным при подключении к AD с использованием TLS (порт 636). Почему такое вообще допустимо? Как можно передать пароль стороннему сервису, не убедившись в его достоверности?
Заставить LDAP-клиент работать легко. Но только тот факт, что он работает, не означает, что конфигурация правильная.
6. LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга
Приложение, использующее LDAP для аутентификации, всегда будет вынуждено опираться на имена пользователей и пароли. Попытка реализовать современные технологии, такие как многофакторная аутентификация и единый вход, практически невозможна (если только вы не собираетесь внедрять свои собственные технологии, что само по себе является плохой идеей). Альянс FIDO стремится сделать пароли пережитком прошлого, а каждое приложение, использующее аутентификацию LDAP, будет помехой на пути к беспарольной политике.
Какие есть варианты?
Сегодня веб-приложения действительно могут обойтись без LDAP-аутентификации. Существует множество прекрасных веб-протоколов аутентификации, таких как SAML, WS-Federation и OpenID Connect, которые не требуют учетных данных пользователя для работы со сторонними приложениями. Бесчисленное количество продуктов предоставляют эти услуги, включая Active Directory Federation Service (встроенные в Windows Server) или сторонние сервисы, такие как Microsoft Azure AD, Okta, Ping и другие. Если в организации нет федеративного IdP, первое, что нужно сделать — внедрить его.
Главное, на что стоит обратить внимание при выборе нового ПО — поддержка современных протоколов аутентификации. Даже если приложение требуется бизнесу здесь и сейчас, не стоит спешить с выбором решения, особенно, если этот выбор ограничен только продуктами с LDAP-аутентификацией. Стоит попробовать донести до выбранного вендора необходимость доработки продукта с использованием более современных протоколов аутентификации. Возможно он прислушается и пересмотрит свой план разработки.
Число десктоп-приложений с «толстым клиентом», поддерживающих современные протоколы аутентификации, растет, и это действительно радостная тенденция. Эти приложения обычно были оплотом LDAP-аутентификации. Растет число SDK, таких, как Microsoft Authentication Library (MSAL), которые позволяют разработчикам легко добавлять поддержку современных сервисов аутентификации в свои мобильные и десктоп-приложения.
В конечном счете, стоит признать, что в сегодняшней реальности не все приложения поддерживают современные протоколы аутентификации, и, возможно, никогда и не будут. Внедрение полного запрета LDAP-аутентификации, вероятно, невозможно ни в одной организации. Однако ни в коей мере не стоит поощрять применение LDAP-аутентификации внутри организации. Использование LDAP следует рассматривать только при отсутствии других вариантов.
Аутентификация файловых серверов GNU/Linux в домене Windows на базе AD. Часть 2 / Хабр
1. Конфигурационные файлы.
Мы будем настраивать только доступ к серверу GNU/Linux с использованием Samba. Авторизация пользователей останется локальной, с использованием /etc/passwd.
Мы присвоим нашему новому серверу статический IP-адрес. Пусть им будет 192.168.7.9.
Для начала нужно проверить, какой сервер у нас используется в качестве DNS. Им в нашей сети должен быть контроллер домена. У нас адрес сервера определен как 192.168.7.2. Правим файл /etc/resolv.conf. Он должен выглядеть следующим образом:
search lab.local
nameserver 192.168.7.2
Проверим, все ли работает:
#host 192.168.7.2
2.7.168.192.in-addr.arpa domain name pointer lab-dc1.lab.local.
#
Естественно, в Вашем случае имена будут другими. Обязательно сделайте в домене lab.local запись в DNS, ссылающуюся на наш новый сервер. Запись в DNS не означает того, что наш GNU/Linux сервер включен в домен. Проверим:
linux-test:~ # host 192.168.7.9
9.7.168.192.in-addr.arpa domain name pointer test-linux.lab.local.
linux-test:~ # host test-linux
test-linux.lab.local has address 192.168.7.9
linux-test:~ #
Для корректной работы в домене Windows требуется несколько служб: Kerberos, LDAP и Samba. В общем случае требуется только настройка Samba, настройка других служб не является обязательной. Но будет лучше, если мы их настроим – они могут пригодиться в будущем.
Kerberos настраивается просто – через один файл /etc/krb5.conf. Основными параметрами является REALM, указывающий на наш домен и адрес сервера Kerberos – это адрес контроллера домена. Файл /etc/krb5.conf выглядит примерно так:
linux-test:~ # more /etc/krb5.conf
[libdefaults]
default_realm = LAB.LOCAL
clockskew = 300
# default_realm = EXAMPLE.COM
[realms]
LAB.LOCAL = {
kdc = 192.168.7.2
default_domain = lab.local
admin_server = 192.168.7.2
}
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON
[domain_realm]
.lab.local = LAB.LOCAL
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
minimum_uid = 1
external = sshd
use_shmem = sshd
clockskew = 300
}
Секция [libdefaults] указывает на домен по умолчанию. У нас это LAB.LOCAL. Далее, в секции [realms] указываются параметры для LAB.LOCAL – имя домена и адрес сервера Kerberos. В нашем случае, в качестве сервера Kerbeors выступает контроллер домена. В секции [logging] указывается местоположение лог-файлов. Эти файлы пригодятся для процедуры поиска неисправности, если что-то пойдет не так.
Проверим работу Kerberos:
linux-test:~ # kinit [email protected]
Password for [email protected]:
linux-test:~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
04/05/12 11:22:23 04/05/12 21:22:35 krbtgt/[email protected]
renew until 04/06/12 11:22:23
linux-test:~ #
Команда kinit получает от сервера тикет, а klist показывает полученные тикеты от сервера. Выполнение kinit не является обязательным, но ведь нужно как-то проверить работу Kerberos?
Настройка LDAP тоже не является обязательной – Samba сама построит необходимые файлы и сделает нужные запросы. Но LDAP может пригодиться в дальнейшем. Конфигурация OpenLDAP хранится в файле /etc/openldap/ldap.conf. Обратите внимание – в системе может быть два файла ldap.conf. У них разные предназначения и даже немного разный синтаксис. В каталоге /etc/openldap лежит файл ldap.conf для OpenLDAP (и для Samba), а в файле /etc/ldap.conf хранится конфигурация для разрешения имен через LDAP (для nss_ldap). К файлу /etc/ldap.conf мы вернемся в других статьях, сейчас настроим /etc/openldap/ldap.conf
linux-test:~ # cat /etc/openldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
uri ldap://192.168.7.2
base DC=lab,DC=local
linux-test:~ #
Как видите, все очень просто – нужно указать URI сервера LDAP (это наш контроллер домена) и базу для поиска.
Теперь переходим к самому сложному – настройке Samba.
В состав Samba входят 3 демона – smbd, nmbd и winbind. Все они берут настройки из файла /etc/samba/smb.conf.
Smbd отвечает за доступ клиентов к службе SMB/CIFS (собственно это и есть сервер Samba). Nmbd – это служба разрешения имен для Netbios. Winbind – служба разрешения имен (и компьютеров и пользователей) через доменные службы Windows.
Во многих руководствах можно встретить упоминание того, что кроме Samba требуется настраивать и winbind – службу, отвечающую за отношения между GNU/Linux и контроллером домена Windows. В частном случае, когда нужно настроить только Samba, настройки winbind можно опустить. Winbind обеспечивает авторизацию в домене Windows самых различных служб, обеспечивая интерфейс между модулями PAM и контроллером домена Windows. При неработающем winbind Samba остается работоспособной. Но настроив winbind мы делаем возможным дальнейшее расширение нашего сервера за счет добавления различных служб, авторизующихся через контроллер домена.
Мы сделаем самый простой сервер, открыв всем пользователям доступ к некоторому общему каталогу файлов и к домашнему каталогу пользователей. Более подробно о настройке доступа к серверу Samba мы будем говорить в других статьях.
В файле /etc/samba/smb.conf мы должны указать следующие строки:
[global]
workgroup = LAB
passdb backend = ldapsam:ldap://192.168.7.2
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
logon path = \\%L\profiles\.msprofile
logon home = \\%L\%U\.9xprofile
logon drive = P:
usershare allow guests = Yes
Здесь мы указываем сокращенное наименование нашего домена (LAB) и место, где хранятся пароли – параметр passdb backend, указывающий на то, что пароли находятся на сервере LDAP, в качестве которого выступает контроллер домена. Кстати, можно указать и несколько серверов, перечислив их через пробел. Это пригодится в том случае, если у нас несколько контроллеров домена. Строка usershare allow guests = Yes разрешает пользователям управлять доступом к своим папкам, открывая их для гостей. Остальные строки относятся к управлению печатью и процессу регистрации. В нашем случае они не являются обязательными и перекочевали из конфигурационного файла дистрибутива Samba.
Продолжим редактирование секции [global] файла smb.conf.
domain logons = No
domain master = No
security = ADS
encrypt passwords = yes
Строки domain logons и domain master разрешают использовать Samba в качестве контроллера домена. Это не наш случай и поэтому для них установлено No.
Строка security = ADS имеет ключевое значение. Тем самым мы указываем Samba, что сервер является членом домена Windows и за авторизацию отвечает AD. Строка encrypt passwords = yes означает, что используются зашифрованные пароли.
Продолжим редактировать все ту же секцию [global].
ldap admin dn = [email protected]
ldap delete dn = No
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap machine suffix = ou=Computers
ldap passwd sync = Yes
ldap ssl = No
ldap suffix = DC=lab,DC=local
ldap timeout = 5
ldap user suffix = ou=Users
Эти строки относятся к управлению соединением с LDAP сервером. Заметьте, что форма записи DN администратора имеет форму user@domain – она должна совпадать с тем, что мы указывали при тестировании Kerberos. Остальные строки указывают суффиксы различных местоположений в AD.
Следующие строки относятся уже к Kerberos:
realm = LAB.LOCAL
template homedir = /home/%D/%U
winbind refresh tickets = yes
kerberos method = system keytab
Здесь мы указываем REALM и метод аутентификации в Kerberos.
Теперь строки, которые относятся к настройке winbind:
winbind separator = /
winbind enum users = yes
winbind enum groups = yes
winbind nested groups = yes
winbind use default domain = No
winbind nss info = rfc2307
winbind offline logon = yes
Здесь указаны различные параметры работы Winbind – форма разделитя имен домена и пользователя, разрешение для winbind перечислять имена пользователей и групп, разрешение оффлайновой аутентификации и т.п. Эти настройки рекомендованы разработчиками Samba.
Секция глобальных настроек закончена. Обратите внимание, что у нас нет строк password server и idmap backend, которые можно встретить в других руководствах. Samba должна сама разобраться, откуда берутся пароли.
Переходим к настройке каталогов. Здесь все просто:
[homes]
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes
available = Yes
[profiles]
comment = Network Profiles Service
path = %H
read only = No
store dos attributes = Yes
create mask = 0600
directory mask = 0700
[users]
comment = All users
path = /home
read only = No
inherit acls = Yes
veto files = /aquota.user/groups/shares/
[groups]
comment = All groups
path = /home/groups
read only = No
inherit acls = Yes
[SRV]
comment = Common files
path = /local
write list = Administrator
guest ok = Yes
hosts allow = 192.168.7.
К стандартному списку разделяемых каталогов, распространяемому вместе с дистрибутивом Samba мы добавили только секцию [SRV] – общедоступный каталог.
Конфигурирование всех необходимых файлов закончено, и мы приступаем к проверке работоспособности нашего сервера.
2. Проверка работоспособности.
Здесь мы проверим корректность наших настроек и включим наш новый сервер в домен Windows. Сначала проверим корректность настройки Samba:
l
inux-test:~ # testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[homes]"
Processing section "[profiles]"
Processing section "[users]"
Processing section "[groups]"
Processing section "[SRV]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions
Как видно, каких либо серьезных предупреждений и ошибок конфигурации у нас нет.
Теперь запустим по очереди демоны smbd, nmbd и winbindd. Сделаем это через файлы /etc/init.d/smb, /etc/init.d/nmb и /etc/init.d/winbind. Можно выполнить это и вручную, что может оказаться полезным для получения различной дополнительной информации. О том, как это сделать можно прочесть во встроенных руководствах (man) по smbd, nmbd и winbindd.
Проверим состояние нашего домена и нашего сервера в домене. Состояние домена можно получить командой net ads info
linux-test:~ # net ads info
LDAP server: 192.168.7.2
LDAP server name: LAB-DC1.lab.local
Realm: LAB.LOCAL
Bind Path: dc=LAB,dc=LOCAL
LDAP port: 389
Server time: Thu, 05 Apr 2012 13:03:47 MSK
KDC server: 192.168.7.2
Server time offset: 4
linux-test:~ #
Как видно, все в порядке. Если какие-то параметры, выводимые командой не совпадают с нашим планом – надо искать причину. Теперь проверим состояние нашего сервера в домене:
l
inux-test:~ # net ads status -U Administrator
Enter Administrator's password:
No machine account for 'LINUX-TEST' found
linux-test:~ #
Отсюда следует, что наш сервер не включен в домен. Запрос к контроллеру домена делается от имени администратора, и пароль нужно указывать от учетной записи администратора домена Windows.
Теперь мы должны включить наш сервер в домен:
l
inux-test:~ # net ads join -U Administrator
Enter Administrator's password:
Using short domain name -- LAB
Joined 'LINUX-TEST' to realm 'lab.local'
DNS Update for linux-test.lab.local failed: ERROR_DNS_UPDATE_FAILED
DNS update failed!
linux-test:~ #
Итак, наш новый сервер включен в домен, о чем свидетельствуют строки:
Using short domain name -- LAB
Joined 'LINUX-TEST' to realm 'lab.local'
Динамическое изменение DNS у нас не прошло. Это не страшно, поскольку оно и не планировалось. Теперь рекомендуется перезапустить все наши процессы – smbd, nmbd и winbindd. Заметим, что после перезапуска до дальнейших проверок должно пройти несколько минут.
Проверим статус нашего сервера в домене:
linux-test:~ # net ads status -U Administrator
Enter Administrator's password:
В ответ мы получим распечатку состояния нашего нового сервера в домене. Там будут указаны различные поля AD, относящиеся к нашему серверу. Так же наш сервер GNU/Linux мы увидим на вкладке Computers, запустив средство администратора AD на контроллере домена.
Можно проверить список пользователей домена:
l
inux-test:~ # net ads user -U Administrator
Enter Administrator's password:
Administrator
Guest
krbtgt
usertest
linux-test:~ #
И проверим работу winbind:
linux-test:~ # wbinfo -t
checking the trust secret for domain LAB via RPC calls succeeded
linux-test:~ #
И получим список пользователей в домене:
l
inux-test:~ # wbinfo -u
LAB/administrator
LAB/guest
LAB/krbtgt
LAB/usertest
linux-test:~ #
Можно проверить состояние домена через wbinfo:
l
inux-test:~ # wbinfo -D LAB
Name : LAB
Alt_Name : lab.local
SID : S-1-5-21-3914562201-450990341-53424453
Active Directory : Yes
Native : Yes
Primary : Yes
linux-test:~ # wbinfo -P
checking the NETLOGON dc connection succeeded
linux-test:~ #
Все в порядке. Теперь самая главная проверка – попробуем открыть каталоги на нашем новом сервере, используя рабочую станцию под управлением Windows 7. Наша рабочая станция включена в домен. Мы должны увидеть наш новый сервер на вкладке Network обозревателя Windows, либо указав имя или IP адрес:
Теперь можно переходить к дальнейшим процедурам настройки нашего сервера. В дальнейшем мы рассмотрим некоторые нюансы описанного процесса в зависимости от дистрибутива GNU/Linux и подробнее рассмотрим настройку прав доступа к серверу Samba.
Работа выполнена на базе Информационно-вычислительного центра МЭИ.
Инструменты LDAP — LDAP.com
Существует множество приложений с поддержкой LDAP. Многие из них могут каким-либо образом использовать LDAP, даже если это не является основной целью приложения. Например, многие почтовые клиенты имеют возможность использовать сервер LDAP в качестве адресной книги, а многие веб-контейнеры поддерживают аутентификацию на сервере LDAP. Но есть также множество приложений и утилит, основная цель которых связана с обменом данными по протоколу LDAP. Некоторые из них перечислены здесь.
Если есть другие инструменты LDAP, которые, по вашему мнению, должны быть перечислены здесь, не стесняйтесь отправлять их по адресу [email protected].
Графические инструменты для взаимодействия с данными на сервере каталогов LDAP.
Каждый из следующих продуктов предоставляет ряд инструментов командной строки для взаимодействия с серверами каталогов:
- OpenLDAP:
- ldapadd
- ldapcompare
- ldapdelete
- ldapexop
- ldapmodify
- ldapmodrdn
- ldappasswd
- ldapsearch
- ldapurl
- ldapwhoami
- UnboundID LDAP SDK для Java:
- авторизация
- base64
- сгенерировать схему из источника
- сгенерировать источник из схемы
- идентифицировать ссылки на отсутствующие записи
- конфликты уникальных атрибутов идентификации
- сервер каталога в памяти
- indent-ldap-фильтр
- LDAP-отладчик
- ldapcompare
- ldapdelete
- ldapmodify
- ldappasswordmodify
- ldapsearch
- ldif-diff
- ldifmodify
- ldifsearch
- менеджмент-сертификаты
- мод.
- поддерево движения
- скорость поиска и модификации
- скорость поиска
- сплит-ldif
- преобразование-ldif
- проверить схему LDAP
- проверить-LDIF
Кроме того, доступны следующие дополнительные инструменты командной строки:
Эти инструменты могут помочь вам измерить производительность сервера каталогов LDAP или помочь убедиться, что он может выдержать ожидаемую производственную нагрузку.
Большинство серверов каталогов предоставляют определенный уровень поддержки для репликации своих данных с другими серверами каталогов того же типа. Но если вы хотите синхронизировать данные между серверами разных типов или если вы хотите синхронизировать данные между сервером каталогов и каким-либо другим типом репозитория, вам понадобится более специализированный инструмент, например следующий:
Эти шлюзы обеспечивают поддержку взаимодействия с данными на сервере каталогов LDAP через альтернативный (обычно веб-протокол):
На предприятии серверы каталогов часто используются для аутентификации пользователей на рабочих станциях и серверах.В этом могут помочь следующие инструменты:
- Панель инструментов LDAP — набор связанных с LDAP приложений, инструментов администрирования и других утилит.
- NetTools — набор инструментов для LDAP и Active Directory.
Нравится:
Нравится Загрузка …
.
OpenLDAP для Windows скачать | SourceForge.net
Полное имя
Телефонный номер
Должность
Промышленность
Компания
Размер компании
Размер компании: 1 — 2526 — 99100 — 499500 — 9991,000 — 4,9995,000 — 9,99910,000 — 19,99920,000 или более
Получайте уведомления об обновлениях для этого проекта.Получите информационный бюллетень SourceForge.
Получайте информационные бюллетени и уведомления с новостями сайта, специальными предложениями и эксклюзивными скидками на ИТ-продукты и услуги.
Да, также присылайте мне специальные предложения о продуктах и услугах, касающихся:
Программное обеспечение для бизнеса
Программное обеспечение с открытым исходным кодом
Информационные технологии
Программирование
Оборудование
Вы можете связаться со мной через:
Электронная почта (обязательно)
Телефон
смс
Я согласен получать эти сообщения от SourceForge.сеть. Я понимаю, что могу отозвать свое согласие в любое время. Пожалуйста, обратитесь к нашим Условиям использования и Политике конфиденциальности или свяжитесь с нами для получения более подробной информации.
Я согласен получать эти сообщения от SourceForge.net указанными выше способами. Я понимаю, что могу отозвать свое согласие в любое время. Пожалуйста, обратитесь к нашим Условиям использования и Политике конфиденциальности или свяжитесь с нами для получения более подробной информации.
Для этой формы требуется JavaScript.
Подписывайся
Кажется, у вас отключен CSS.Пожалуйста, не заполняйте это поле.
Кажется, у вас отключен CSS.
Пожалуйста, не заполняйте это поле.
.
Бесплатный браузер LDAP для Windows
LDAPSoft Ldap Browser предоставляет простой интерфейс для просмотра каталогов LDAP. Это инструмент только для чтения, разработанный для начинающих пользователей и администраторов ldap, которые просто намереваются просматривать каталоги, не беспокоясь о каких-либо случайных изменениях в каталогах. С помощью браузера LDAPSoft ldap вы можете искать записи, просматривать все доступные атрибуты и запускать операторы SQL-LDAP. Браузер предоставляет только интерфейс только для чтения, поэтому, если вам нужно изменить атрибуты и значения, вам понадобятся наши расширенные инструменты, такие как стандартная и профессиональная версии LDAP Admin Tool.Браузер LDAP позволяет получить доступ к OpenLDAP, Netscape / iPlanet, Novell eDirectory, Oracle Internet Directory, IBM Tivoli Directory, Lotus Domino, Microsoft Active Directory или любому другому серверу каталогов LDAP v2 или LDAPv3. Вы можете подключиться к нескольким серверам каталогов одновременно и быстро просматривать большие каталоги.
Основная функция LDAPSoft Ldap Browser:
LDAPSoft Ldap-браузер доступен только на платформе Windows .Вы можете загрузить бесплатный браузер ldap, используя следующую ссылку для скачивания.
Инструкции по установке
( только Windows):
Просто скачайте файл и нажмите, чтобы открыть после завершения загрузки. Следуйте инструкциям на экране.
Вопросы и ответы:
В. В чем разница между бесплатным браузером LDAPSoft AD и бесплатным браузером LDAPSoft LDAP.
A. Единственное различие между двумя бесплатными продуктами заключается в том, что браузер рекламы автоматически обнаруживает активный каталог, если вы подключены к домену, и запрашивает подключение.
.Сертификат
LDAP через SSL (LDAPS) — Статьи TechNet — США (английский)
Применимо к Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
По умолчанию связь LDAP между клиентскими и серверными приложениями не шифруется. Это означает, что можно было бы использовать
устройство или программное обеспечение сетевого мониторинга и просмотр обмена данными между клиентом LDAP и сервером.Это особенно проблематично, когда используется простая привязка LDAP, поскольку учетные данные (имя пользователя и пароль) передаются по сети.
незашифрованный. Это может быстро привести к компрометации учетных данных.
Причины включения облегченного протокола доступа к каталогам (LDAP) через Secure Sockets Layer (SSL) / Transport Layer Security (TLS), также известного как LDAPS, включают:
- Некоторые приложения проходят проверку подлинности в доменных службах Active Directory (AD DS) с помощью простого BIND.Поскольку простой BIND предоставляет учетные данные пользователей открытым текстом, использование Kerberos является предпочтительным. Если необходим простой BIND, использование SSL / TLS для шифрования аутентификации
сессия настоятельно рекомендуется. - Использование привязки прокси или смены пароля через LDAP, для чего требуется LDAPS. (например.
Привязка к экземпляру AD LDS через прокси-объект)
- Некоторые приложения, которые интегрируются с серверами LDAP (например, Active Directory или контроллеры домена Active Directory), требуют шифрованной связи.Чтобы зашифровать связь LDAP в сети Windows, вы можете включить LDAP через SSL (LDAPS).
| Осторожно |
|---|
| Перед установкой центра сертификации (ЦС) вы должны знать, что вы создаете или расширяете инфраструктуру открытого ключа (PKI). Обязательно разработайте PKI, подходящую для вашей организации. Видеть Краткий обзор конструкции PKI для получения дополнительной информации. |
LDAP через SSL / TLS (LDAPS) автоматически включается при установке Enterprise Root CA на контроллер домена (хотя установка CA на контроллере домена не рекомендуется).Вы можете увидеть примеры этого в
Руководство по тестовой лаборатории Базовая конфигурация для Windows Server 2008 R2,
Создание корпоративного корневого центра сертификации в малых и средних предприятиях, а также
Установите и настройте службы сертификации Microsoft Active Directory (AD CS) с помощью Windows Server 2008 R2.
Если у вас многоуровневая (например, двухуровневая или трехуровневая) иерархия ЦС, у вас не будет автоматически соответствующего сертификата для проверки подлинности LDAPS на контроллере домена. Чтобы включить LDAPS в многоуровневой иерархии ЦС, вы должны запросить
сертификат, соответствующий следующим требованиям:
- Сертификат должен быть действителен для аутентификации сервера.Это означает, что он также должен содержать идентификатор объекта аутентификации сервера (OID):
1.3.6.1.5.5.7.3.1 - Имя субъекта или имя в альтернативном имени субъекта (SAN) должны соответствовать
Полное доменное имя (FQDN) хост-компьютера, например Subject: CN = server1.contoso.com. Для получения дополнительной информации см.
Как добавить альтернативное имя субъекта к защищенному сертификату LDAP.
- Учетная запись хост-компьютера должна иметь доступ к закрытому ключу.
Публикация сертификата, поддерживающего аутентификацию сервера
- На компьютере выдающего центра сертификации откройте консоль сертификатов или консоль Certsrv. Чтобы открыть Certsrv, щелкните
Старт . Введите certsrv.msc , а затем щелкните
ОК . - Убедитесь, что центр сертификации расширен, а также имя центра сертификации.
- Щелкните правой кнопкой мыши Шаблоны сертификатов , а затем щелкните Управление .
- В консоли шаблонов сертификатов щелкните правой кнопкой мыши Kerberos Authentication и выберите
Дубликат шаблона . Вам не обязательно использовать шаблон Kerberos. Вы можете создать свой собственный или использовать один из существующих шаблонов, предназначенных для проверки подлинности сервера, например
Аутентификация контроллера домена , Контроллер домена ,
Веб-сервер и компьютер .Важно: вы должны планировать
только один сертификат на каждом сервере LDAP (то есть на контроллере домена или компьютере AD LDS) с целью
Аутентификация сервера . Если у вас есть законные причины для использования более чем одного, у вас могут возникнуть проблемы с выбором сертификата, которые обсуждаются далее в
Хранилище сертификатов доменных служб Active Directory. - В диалоговом окне Duplicate Template оставьте значение по умолчанию выбранным.
Выбран Windows Server 2003 Enterprise и нажмите ОК . - Появятся свойства нового шаблона . Убедитесь, что настройки соответствуют вашим требованиям для этого шаблона сертификата. Обратите особое внимание на то, чтобы
Отображаемое имя шаблона установлено на соответствующее имя вместе со следующими настройками:- Срок действия и периоды продления устанавливаются в соответствии с политикой безопасности вашей организации.
- Соответствующие длины ключей
- Выберите, хотите ли вы разместить сертификат в Active Directory.
- Вкладка «Имя субъекта»: выбраны имя DNS и имя участника службы (SPN)
- Если вы планируете импортировать сертификат в домен Active Directory Хранилище сертификатов служб, тогда также следует отметить закрытый ключ как экспортируемый.
- Нажмите ОК .
- Вернитесь в консоль Certificates или Certsrv и на панель сведений
Шаблоны сертификатов , щелкните правой кнопкой мыши открытую область консоли, щелкните
Новый , а затем щелкните Шаблон сертификата для выпуска . - В диалоговом окне Включить шаблоны сертификатов выберите имя нового шаблона, который вы создали, и нажмите
ОК .
Чтобы запросить сертификат у вашего сервера LDAPSL, выполните следующие действия на каждом контроллере домена, который требует подключения LDAPS:
- Откройте консоль Certificates . Нажмите Пуск , введите
MMC , а затем нажмите клавишу ВВОД. Если система управления учетными записями пользователей запрашивает, убедитесь, что в нем отображается нужное действие, а затем нажмите
Есть . - В открывшейся консоли MMC (обычно Console1) щелкните File
а затем нажмите Добавить / удалить оснастку - В Добавить или удалить оснастки в разделе Доступные оснастки , нажмите
Сертификаты , а затем щелкните Добавить . - В оснастке «Сертификаты » выберите Учетная запись компьютера и нажмите
Далее . - В Выберите Компьютер , если вы управляете сервером LDAP, требующим сертификат, выберите
Местный . В противном случае выберите Другой компьютер и нажмите
Просмотрите , чтобы найти сервер LDAP, для которого требуется сертификат. - После того, как вы выбрали правильный компьютер, нажмите ОК , а затем нажмите
Отделка . - В Добавить или удалить оснастки нажмите ОК .
- В дереве консоли разверните Сертификаты (<компьютер>)
- щелкните правой кнопкой мыши Сертификаты , щелкните Все задачи , а затем щелкните
Запросить новый сертификат . - В Certificate Enrollment щелкните Next .
- В Выберите политику регистрации сертификатов , как правило, вы оставляете значение по умолчанию
Политика регистрации в Active Directory .Если у вас есть другая политика, которой вы должны следовать, выберите ее и нажмите
Далее . - Выберите сертификат, который разрешает проверку подлинности сервера, Kerberos работает, но вы можете использовать настраиваемый сертификат, как описано в разделе «Публикация сертификата, поддерживающего проверку подлинности сервера». Нажмите
Записаться . - В диалоговом окне «Регистрация сертификата » щелкните Завершить .
- В области результатов дважды щелкните полученный сертификат, чтобы открыть
Сертификат диалоговое окно свойств. - Щелкните вкладку Details , в столбце Field выберите Enhanced Key Usage . Подтвердите это
Аутентификация сервера (1.3.6.1.5.5.7.3.1) .
Другие пошаговые примеры запроса сертификата для аутентификации сервера и реализации LDAP через SSL (LDAPS) см. В следующих статьях:
Включение LDAPS на клиенте не обязательно для защиты учетных данных, передаваемых от клиента серверу, когда LDAPS уже включен на сервере.Это просто позволяет клиенту фактически аутентифицироваться на сервере — дополнительный уровень защиты для
убедитесь, что клиент, подключающийся как COMPUTER_X, на самом деле является COMPUTER_X, а не каким-либо другим компьютером, пытающимся аутентифицироваться с учетными данными COMPUTER_X. Клиент должен использовать сертификат от ЦС, которому доверяет сервер LDAP. Сертификаты клиентов и AD
Учетные записи DS сопоставляются с помощью altSecurityIdentities, что можно сделать различными способами. Для получения дополнительной информации об этих методах см.
HowTo: сопоставьте пользователя с сертификатом с помощью всех методов, доступных в атрибуте altSecurityIdentities.Сертификаты представляются серверу во время обмена ключами Transport Layer Security (TLS) (описанного в параграфе 7.4.
RFC 2246). Чтобы включить аутентификацию LDAPS для клиента, убедитесь, что сертификат размещен в личном хранилище для учетной записи пользователя.
Когда сертификат выбран из хранилища локального компьютера (как в
CertEnumCertificatesInStore) первый действительный сертификат, который может использоваться для аутентификации сервера (OID: 1.3.6.1.5.5.7.3.1), возвращается для использования. В случаях, когда у клиентов есть несколько сертификатов, действительных для проверки подлинности сервера на сервере LDAP (например,г.
Контроллер домена AD DS,
AD LDS или
Сервер ADAM) хранилище сертификатов локального компьютера, может увидеть, что для связи LDAPS используется другой сертификат, чем тот, который им нужен. Лучшее решение такой проблемы — удалить все ненужные сертификаты из сертификата локального компьютера.
store и иметь только один сертификат, действительный для проверки подлинности сервера.
Однако, если есть законная причина, по которой два или более сертификата и клиент использует по крайней мере серверы LDAP Windows Server 2008, хранилище сертификатов доменных служб Active Directory (NTDS \ Personal) может использоваться для связи LDAPS.
Важно Прежде чем приступить к использованию хранилища сертификатов доменных служб Active Directory, необходимо знать несколько важных деталей.
- Автоматическая регистрация сертификатов (автоматическая регистрация) не может использоваться с сертификатами в хранилище сертификатов NTDS \ Personal.
- Текущие инструменты командной строки не позволяют управлять сертификатами хранилища сертификатов NTDS \ Personal.
- Сертификаты необходимо импортировать в хранилище, а не перемещать (с помощью перетаскивания) через консоль сертификатов (MMC)
- Каждому серверу LDAP потребуется свой собственный сертификат для использования этой опции, но необходимо использовать эту опцию только на сервере, имеющем несколько сертификатов, с целью аутентификации сервера в локальном хранилище сертификатов.Лучшее решение
иметь только один сертификат в личном сертификате компьютера
Следующие шаги продемонстрируют, как экспортировать сертификат с включенным LDAPS из локального хранилища сертификатов компьютера контроллера домена в хранилище сертификатов службы доменных служб Active Directory (NTDS \ Personal). Вам нужно будет выполнить этот шаг
для каждого контроллера домена, имеющего несколько сертификатов с включенной аутентификацией сервера. Эти сертификаты необходимо будет обновить вручную, когда срок их действия истечет, и они работают только начиная с контроллеров домена Windows Server 2008, поскольку это было
первый выпуск операционной системы Windows Server, в котором NTDS была выделена как отдельная служба.
- Щелкните Start , введите mmc и затем щелкните
ОК . - Щелкните Файл , а затем щелкните Добавить / удалить оснастку .
- Щелкните Сертификаты , а затем щелкните Добавить .
- В Certificates snap-in выберите Computer account и затем нажмите
Далее . - В Выберите Компьютер , если вы работаете на сервере LDAP, требующем сертификат, выберите
Местный .В противном случае выберите Другой компьютер и нажмите
Просмотрите , чтобы найти сервер LDAP, для которого требуется сертификат. - После того, как вы выбрали правильный компьютер, нажмите ОК , а затем нажмите
Отделка .В Добавить или удалить оснастки нажмите ОК .
- В дереве консоли разверните Сертификаты (<компьютер>)
- В консоли сертификатов компьютера, который содержит сертификат, который может использоваться для проверки подлинности сервера, щелкните сертификат правой кнопкой мыши, щелкните
Все задачи , а затем щелкните Экспорт . - На экране приветствия мастера экспорта сертификатов щелкните
Далее . - На экране Экспорт закрытого ключа выберите Да, экспортировать закрытый ключ и затем щелкните
Далее . Если у вас нет возможности экспортировать закрытый ключ, значит, шаблон сертификата не позволял экспортировать закрытый ключ (см.Публикация сертификата, поддерживающего аутентификацию сервера).
- На экране Export File Format вы должны выбрать
Экспортируйте все расширенные свойства . Остальные варианты не обязательны. - На экране «Пароль» введите пароль, который будет использоваться при импорте сертификата. Вам нужно будет ввести пароль дважды: один раз в
Пароль в поле , а затем снова в поле Введите и подтвердите пароль (обязательно) .Затем щелкните
Далее . - На экране Файл для экспорта введите путь, имя файла и расширение файла .pfx в поле
Имя файла , а затем щелкните Далее . - Подтвердите настройки на экране завершения и нажмите Готово . Вы должны увидеть всплывающее сообщение об успешном экспорте. Нажмите
ОК . - Щелкните Файл , а затем щелкните Добавить / удалить оснастку .
- Щелкните Сертификаты , а затем щелкните Добавить .
- Выберите Сервисный аккаунт , а затем щелкните Далее .
- В диалоговом окне Select Computer убедитесь, что выбран соответствующий компьютер. Если вы используете Microsoft Management Console (MMC) и хотите настроить таргетинг на локальный компьютер, вы можете оставить выбор по умолчанию:
Локальный компьютер . В противном случае выберите Другой компьютер , а затем используйте
Обзор , чтобы выбрать соответствующий компьютер.Затем нажмите
Далее . - Выберите Доменные службы Active Directory и затем щелкните
Закончить . - В диалоговом окне Добавить или удалить оснастки нажмите ОК .
- Разверните Сертификаты — Службы (доменные службы Active Directory) и щелкните
NTDS \ Персональный . - Щелкните правой кнопкой мыши NTDS \ Personal , щелкните Все задачи , а затем щелкните
Импорт . - На экране приветствия мастера импорта сертификатов щелкните
Далее . - На экране Файл для импорта щелкните Обзор , а затем найдите файл сертификата, который вы экспортировали ранее.
- На экране Открыть убедитесь, что Обмен личной информацией (* pfx, *. P12) выбран в качестве типа файла, а затем перейдите в файловую систему, чтобы найти сертификат, который вы экспортировали ранее, и затем щелкните этот сертификат.
- Щелкните Открыть , а затем щелкните Далее .
- На экране Пароль введите пароль, который вы установили для файла, а затем нажмите
Далее . - На странице Хранилище сертификатов убедитесь, что Поместить все сертификаты в следующее хранилище выбрано и читает
Хранилище сертификатов: NTDS \ Personal , а затем щелкните Далее . - На экране завершения мастера импорта сертификатов щелкните
Закончить . Затем вы должны увидеть сообщение об успешном импорте. Нажмите
ОК . - На панели навигации в разделе NTDS \ Personal щелкните Сертификаты
- В области сведений щелкните правой кнопкой мыши импортированный сертификат и выберите
Открыть . - Щелкните Details , а затем щелкните Enhanced Key Usage, вы должны увидеть, что
Аутентификация сервера (1.3.6.1.5.5.7.3.1) является одной из целей сертификата, а затем щелкните
ОК .
После установки сертификата выполните следующие действия, чтобы убедиться, что LDAPS включен:
- Запустите инструмент администрирования Active Directory (Ldp.exe)
- В меню Connection щелкните Connect .
- Введите имя сервера LDAP (например, контроллера домена или сервера AD LDS / ADAM), к которому вы хотите подключиться.
- Введите 636 в качестве номера порта.
- Щелкните ОК .
Когда у вас возникают проблемы с LDAPS, есть несколько разных вещей, которые могут ошибаться. Один из лучших пошаговых документов по устранению неполадок LDAPS находится в блоге Ask DS, в котором старший инженер по эскалации проводит проверку и устранение неполадок:
Устранение неполадок LDAP через SSL. Существует только один идентификатор события, который напрямую связан с LDAP через SSL, это событие 1220, развернутое в месте назначения ссылки в списке ниже.Остальные ссылки относятся к подписи LDAP. Подписание LDAP делает
не шифровать обмен данными между сервером LDAP и клиентом. Подписание LDAP проверяет личность клиента, пытающегося выполнить привязку LDAP, и помогает снизить вероятность повторного воспроизведения и атак типа «злоумышленник в середине». Для получения дополнительной информации о подписи LDAP,
см. Подписание LDAP
и
Как включить подписку LDAP в Windows Server 2008.
- Код события 1220 — LDAP через SSL
- Идентификатор события 2886 — подпись LDAP: регистрируется каждый раз при запуске контроллера домена, если подпись не требуется.
включен на вашем контроллере домена. - Идентификатор события 2887 — Если требуется подпись не включена, это событие ведет счет того, сколько неподписанных привязок произошло в
предыдущие 24 часа. Событие регистрируется каждые 24 часа. - Идентификатор события 2888 — Если включено требование подписи, то даже ведется подсчет количества неподписанных привязок LDAP, произошедших в предыдущем
24 часа. Поскольку требуется подпись LDAP, привязки будут отклонены. Это уведомление администраторам о необходимости проверки клиентских компьютеров, которые пытаются выполнить привязку без подписи. - Событие с кодом 2889. Администраторы могут включить это событие, чтобы помочь идентифицировать клиентские компьютеры, которые пытаются выполнить привязку без
подписание. Это событие регистрируется с IP-адресом и идентификатором привязки клиента каждый раз, когда выполняется или предпринимается попытка привязки без знака.
.