Разное

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-ов, второй для наших данных.

План установки будет такой:

  1. Установка первого сервера на ldap00;
  2. Настройка репликации на ldap00;
  3. Установка и настройка ldap инстанса на ldap01;
  4. Установка admin server-а на ldap01;
  5. Установка и настройка 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

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

  • Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)
  • Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
  • Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
  • Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
  • Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
  • Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
  • Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
  • Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
  • Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
  • Нажмите, чтобы поделиться в Skype (Открывается в новом окне)

Включение LDAPS на контроллере домена под управлением Windows Server 2008 R2 / Песочница / Хабр

Исходные данные:

  • организация, использующая в качестве базы данных сотрудников Microsoft Active Directory, базирующуюся на Windows Server 2008 R2 контроллере домена;
  • написанная на php информационная система, поддерживающую протокол LDAP для взаимодействия с MS AD (например, Moodle).

Проблема: при соединении с AD по протоколу LDAP (порт 389) не работает функция php для смены пароля пользователю AD. Решением является переход на SSL-версию протокола — LDAPS (порт 636). На поиск способа включить поддержку LDAPS на контроллере домена было потрачено приличное количество времени, сэкономить которое может помочь данная статья.

Шаг 1, установка служб сертификатов на контроллер домена.

Заходим в панель управления сервером (Start — Administrative Tools — Server Manager). Add Roles — Active Directory Certificate Services — Next — Next — отмечаем Certification Authority Web Enrollment (Add Required Role Services) — Next — Enterprise — Next — Root CA — далее Next до конца.

Шаг 2, запрос на сертификат.

Создаём файл request.inf с текстом:
[Version]

Signature= "$Windows NT$"

[NewRequest]

KeySpec = 1

KeyLength = 1024

Exportable = TRUE

MachineKeySet = TRUE

SMIME = FALSE

PrivateKeyArchive = FALSE

UserProtected = FALSE

UseExistingKeySet = FALSE

ProviderName = "Microsoft RSA SChannel Cryptographic Provider"

ProviderType = 12

RequestType = PKCS10

KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1

OID=1.3.6.1.5.5.7.3.2

[Extensions]

2.5.29.17=MDiCFURDNC5sb3JlLnVuaS1kdWJuYS5ydaAfBgkrBgEEAYI3GQGgEgQQhePOUDQ+

_continue_=7Uy5GtDgYOzldA==

Critical=2.5.29.17


Затем выполняем
certreq -new request.inf request.req

Шаг 3, получение сертификата у CA.

Вот тут самое интересное. Если попробовать разместить запрос на сертификат штатным способом, т.е. через MMC snap-in «Certification Authority» или командой
certreq -attrib "CertificateTemplate:DomainController" request.req, получаем ошибку «The DNS name is unavailable and cannot be added to the Subject Alternate name. 0x8009480f», которую обойти никаким способом так и не удалось. Зато сработала выдача сертификата через веб.
Заходим на localhost/certsrv/certrqxt.asp и вставляем в первое поле код из файла request.req; в поле Certificate Template выбираем Web Server. Скачиваем получившийся сертификат по ссылке Download certificate.

Шаг 4, импорт сертификата.

Winkey+R — mmc; нажимаем Ctrl+M, Certificates — Add — Computer Account — Next — Local Computer — Finish — OK. Certificates (local computer) — Personal — Certificates (правой кнопкой) — All Tasks — Import. Указываем файл, сделанный на шаге 3.

Шаг 5, проверка.

Winkey+R — ldp; Connection — Connect… Server — это FQDN нашего контроллера домена, например, dc.company.org. Port: 636, галочка SSL. OK. «Cannot open connection» означает, что цель не достигнута. Положительный результат будет выглядеть как много строк в правой половине окошка, включая «Established connection to dc.company.org». Теперь можно указывать ldaps://dc.company.org в качестве url ldap-сервера в информационной системе.

Включение активного каталога LDAP над функцией SSL

Skip to content

  • Home
  • Tutorials
  • Books
  • Youtube Channels
  • About
  • Русский
    • English
    • Português
    • Español
    • Deutsch
    • Français
    • Nederlands
    • 日本語
    • 简体中文
    • हिन्दी
    • العربية
    • Italiano
    • 한국어
    • Dansk
    • Suomi
    • עברית
    • Norsk bokmål
    • Svenska
  • Search for:

Univention Corporate Server (UCS) — установка простого и удобного LDAP сервера с web-панелью и его связка с Nextcloud

Рано или поздно на любом маленьком или среднем предприятии возникает задача по созданию единого центра авторизации пользователей в многочисленных сервисах и порталах компании. Среди кандидатов на такой центр авторизации сразу приходит в голову Microsoft Active Directory или одна из реализаций на базе Linux.

В данном цикле статей мы будем использовать Univention Corporate Server (далее по тексту UCS) как удобный и простой в использовании сервер LDAP авторизации с понятным web-интерфейсом и встроенным магазином приложений. Данный продукт разработан немецкой компанией Univention GmbH.

В этой статье мы опишем установку UCS и разворачивание Nextcloud с возможностью последующей авторизации через LDAP.

В следующих статьях мы так же подключим к UCS еще почтовый сервер Zimbra и портал OnlyOffice.

Univention Corporate Server (UCS) — это серверная операционная система, созданная на основе Debian GNU/Linux, с интегрированной системой управления для централизованного и межплатформенного администрирования серверов, служб, клиентов, рабочих столов и пользователей, а также виртуализированных компьютеров, работающих в UCS. В дополнение к работе с локальными виртуальными экземплярами, UCS также может работать в облачных средах на основе OpenStack, Microsoft Azure и Amazon EC2.

Благодаря интеграции программного обеспечения с открытым исходным кодом Samba 4, Univention также поддерживает функции, предоставляемые во многих компаниях Microsoft Active Directory для администрирования компьютеров, работающих под управлением Microsoft Windows. Компоненты на основе UCS и сертифицированные UCS, установленные сторонние продукты могут быть установлены и интегрированы через Центр приложений Univention.

UCS предоставляет всем приложениям Центра приложений среду выполнения и сервисы для работы, включая централизованное, согласованное управление приложениями. Контейнеры Docker также можно запускать в системах UCS, и некоторые из приложений, доступных в Центре приложений, основаны на Docker.
Страница на GitHub

по данным wikipedia

Nextcloud — облачное хранилище с функциями защиты и контроля данных, а также локальная служба подключения аудио- и видеочатов. Загруженные файлы могут быть доступны сторонним участникам на любой платформе. Система позволяет оптимизировать рабочий процесс между коллегами и клиентами. Предусмотрены интеграции с iOS, Android, Mac, Windows, Linux, Outlook и Thunderbird.

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

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

Ключевые особенности:

  • Повышенные опции конфиденциальности
  • Несколько учётных записей с унифицированным почтовым ящиком
  • Интеграция внешних ресурсов календаря (WebCal)
  • HD аудио / видеозвонки
  • Код на GitHub

Описание взято на coba.tools/nextcloud

Так же там можно найти видео и скриншоты продукта.

Оглавление:

  • Установка ОС
  • Первый запуск, подтверждение почты и обновление системы
  • Установка Nextcloud из App Center
  • Создание пользователя и первый запуск Nextcloud

Установка ОС

ISO-образ для установки, можно получить на официальном сайте по ссылке
https://www.univention.com/downloads/

Приступаем к установке с образа

Первый пункт – выбор типа установки.

Выбираем самый оптимальный вариант – Start with default settings

Следующий пункт – выбор языка установки

Поддерживаемые языки: английский, французский и немецкий. Выбираем Russian. Установка продолжится на английском, но это необходимый шаг, т.к. следующий пункт (Select your location) предлагает страны на выбор, основываясь на выбранном нами языке

Выбор местоположения

Поскольку мы выбрали русский язык, в данном списке нам предлагают выбрать Russian Federation

Выбор раскладки клавиатуры

Из-за предыдущих шагов нам предлагают русскую раскладку, меняем на American English

Установка пароля для root пользователя

Инсталлятор предупреждает нас о том, что пароль должен быть надежным. Он может содержать буквы, цифры и знаки препинания. Минимальная длина – 8 символов. На скриншоте активирован чек-бокс Show Password in Clear, отображающий вводимый мною пароль

Настройка часового пояса

Мой выбор – Moscow

Настройка жесткого диска

Это можно сделать вручную (пункт Manual), однако для большинства случаев подойдет и дефолтный вариант – Guide – use entire disk and set up LVM.

LVM (Logical Volume Manager) – подсистема, позволяющая объединить несколько дисков в один, а затем разбить его удобным образом.

Далее инсталлятор предлагает нам выбрать диск и предупреждает, что после подтверждения диск будет отформатирован

Необходимо указать схему разбиения. Я выбираю пункт по-умолчанию All files in one partition

После инсталлятор просит подтверждения применяемого разделения и предупреждает о форматировании диска, выбираем Yes

Вам предлагается обзор конфигурации

Инсталлятор предлагает сохранить конфигурацию. Если все устраивает – Continue

Инсталлятор просит подтвердить предстоящие изменения – Yes

Начался процесс инициализации

По завершении установки нас приветствует окно настройки домена. На этом этапе нам нужно определить роль домена.

Для этого есть четыре опции:

  • Create a new UCS domain – создание нового домена. Если выбрать эту опцию, позже дополнительные системы могут присоединиться к этому домену;
  • Join into an existing UCS domain – если мы хотим присоединить новую систему к существующему домену UCS в качестве ведомого или резервного хранилища;
  • Join to an existing Active Directory domain – стать частью домена Active Directory;
  • Do not use any domain – не использовать домен.

Для создания нового домена, выбираем первую опцию – Create a new UCS domain, далее мы сможем посмотреть процесс создания домена

Инсталлятор предлагает нам указать некоторую информацию о нас

После чего, основываясь на указанные нами данные в предыдущем шаге, генерирует доменное имя. Его можно изменить, тогда нам понадобится ввести полное доменное имя. Рекомендуется выбирать поддомен домена DNS, которым мы управляем. Например, если мы зарегистрировали домен livelinux.org, мы можем использовать ldap.livelinux.org. ldap в данном случае – имя хоста.

Выделенная база LDAP определяется автоматически.

На скриншоте представлено конечное имя домена

На следующем этапе нам предлагают выбрать программные компоненты, которые мы хотим включить в первоначальную установку

На текущем этапе, оставляем все по умолчанию.

Следующий этап – подтверждение настроек

После чего начинается процесс применения финальных настроек

Finish! Установка Univention успешно завершена

Первый запуск, подтверждение почты и обновление системы

После установки системы нас ждет инструкция по открытию Web Management Interface в браузере

Открываю браузер и пишу в адресной строке 192.168.0.103

где 192.168.0.103 — ip адрес сервера, который мы назначили при установке

Браузер предупреждает меня о небезопасности сайта, после чего я попадаю на главную страницу

Авторизуемся, нажав по кнопке замка в правом верхнем углу

Эту пару логин/пароль мы задавали при установке ОС

После логина нас кидает на главный экран, где нам необходимо нажать на System and domain settings

В открывшемся окне нас встречает уведомление

Notification

 

As root you have neither access to the domain administration nor to the App Center. For this you need to log in as Administrator.

Уведомление

 

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

Авторизуемся под пользователем Administrator

В UCS по умолчанию создается пользователь Administrator c паролем указанным root-пользователю при установке

Возвращаемся в System and domain settings уже под пользователем Administrator, где нас ждет приветственное окно. Жмем Next

Нам предлагают подтвердить почту, чтобы активировать систему UCS, без этого мы не сможем устанавливать приложения из App Center.

Вводим свою почту

После на наш e-mail приходит письмо следующего содержания

The installation of various applications and third party apps from the App Center requires the activation of UCS.

For this you can find a license key attached to this mail. To import the license key, first save it locally on your computer.

Then upload the license key as specified. If you need help with the setup and operation of UCS, feel free to visit our user forum ‘Help’ [https://help.univention.com/].

Best regards

Your Univention team

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

Начинаем обновление системы жмем Software Update

В открывшемся окне INSTALL RELEASE UPDATE

Непосредственно процесс установки

Инсталлятор предупреждает нас, что страница будет перезагружена после завершения обновления

После установки нам снова предлагают авторизоваться

Авторизуемся под пользователем Administrator

Установка Nextcloud из App Center

После того, как мы авторизовались под пользователем Administrator

Открываем уже нам знакомый System and domain setting, где нас интересует пункт App Center

Мы видим окно, в котором нас предупреждают о том, что компания собирает статистику о наших действиях в магазине

Жмем Continue. Рекомендуется поставить галочку напротив пункта Do not show this message again, чтобы не наблюдать при каждом входе данное сообщение

Ищем приложение Nextcloud

После чего начинаем установку

Приложение установлено

Создание пользователя и первый запуск Nextcloud

Для создания нового пользователя необходимо перейти в категорию Users

Где мы выбираем следующие пункты

В открывшемся окне нам предлагают ввести имя создаваемого пользователя

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

Задаем ему пароль

Пользователь создан. Авторизуемся под ним в Nextcloud

Nextcloud встречает нас разделом Все файлы, где хранятся предустановленные по умолчанию файлы

Если у Вас есть опыт взаимодействия с облачными хранилищами, то Вы без труда разберетесь в интерфейсе

Наш файл загрузился

В случае, если нам необходимо удалить файлы

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

Зайдя под пользователем Administrator, мы уже не увидим наш файл test.txt

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

Спасибо вам за внимание,

Автор: Менгеша Ефрем, под редакцией Алексея Жадан и команды «Лайв Линукс»

LDAP-«аутентификация» — это антипаттерн / Блог компании Avanpost / Хабр

Сегодня в любой организации есть LDAP-каталог, наполненный пользователями этой организации. Если присмотреться, вы найдете одно или несколько приложений, которые используют этот же каталог для «аутентификации». И кавычки здесь неспроста, ведь LDAP — это протокол доступа к каталогам, спроектированный для чтения, записи и поиска в службе каталогов. Это не протокол аутентификации. Термин «LDAP-аутентификация», скорее, относится к той части протокола (операции bind), где определяется, кто вы такой, и какие права доступа имеете к информации каталога.

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

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

Чтобы разобраться в том, что это за уязвимости, сперва нужно понять, как работает LDAP-аутентификация.

Как работает LDAP-аутентификация

Представьте себе следующую ситуацию (она далека от реальности, но отлично передает суть).

Предположим, я делаю заказ в интернет-магазине так, чтобы его доставили мне домой в мое отсутствие. Курьер приезжает и оставляет под дверью записку с текстом «извините, мы вас не застали» и просит меня забрать заказ в ближайшем пункте выдачи в удобное время. В пункте выдачи сотрудник спрашивает мое имя, адрес и просит ключи от дома, чтобы подтвердить мою личность. Затем сотрудник службы доставки приезжает ко мне домой и открывает дверь моим ключом. Он заходит внутрь, чтобы убедиться, что я там живу, например, по фотографиям на стене или по имени адресата на корреспонденции. После этого сотрудник возвращается в пункт выдачи и сообщает мне, что успешно подтвердил мою личность, и я могу получить свою посылку! Ура!

Помимо проблем с логистикой, данная ситуация полна других вопросов. Что, если недобросовестный проверяющий сделал копию моего ключа? Или он оставил ключ надолго без присмотра, и это сделал кто-либо еще? Что, если на проверяющего напали и забрали мой ключ? Когда я отдаю ключ от своей квартиры незнакомцу, я не могу быть уверен в его порядочности и своей безопасности.

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

В мире 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 администратора имеет форму [email protected] – она должна совпадать с тем, что мы указывали при тестировании 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.

  • Учетная запись хост-компьютера должна иметь доступ к закрытому ключу.

Публикация сертификата, поддерживающего аутентификацию сервера

  1. На компьютере выдающего центра сертификации откройте консоль сертификатов или консоль Certsrv. Чтобы открыть Certsrv, щелкните
    Старт . Введите certsrv.msc , а затем щелкните
    ОК
    .
  2. Убедитесь, что центр сертификации расширен, а также имя центра сертификации.
  3. Щелкните правой кнопкой мыши Шаблоны сертификатов , а затем щелкните Управление .

  4. В консоли шаблонов сертификатов щелкните правой кнопкой мыши Kerberos Authentication и выберите
    Дубликат шаблона . Вам не обязательно использовать шаблон Kerberos. Вы можете создать свой собственный или использовать один из существующих шаблонов, предназначенных для проверки подлинности сервера, например
    Аутентификация контроллера домена , Контроллер домена ,
    Веб-сервер и компьютер .Важно: вы должны планировать
    только один сертификат на каждом сервере LDAP (то есть на контроллере домена или компьютере AD LDS) с целью
    Аутентификация сервера . Если у вас есть законные причины для использования более чем одного, у вас могут возникнуть проблемы с выбором сертификата, которые обсуждаются далее в
    Хранилище сертификатов доменных служб Active Directory.

  5. В диалоговом окне Duplicate Template оставьте значение по умолчанию выбранным.
    Выбран Windows Server 2003 Enterprise и нажмите ОК .
  6. Появятся свойства нового шаблона . Убедитесь, что настройки соответствуют вашим требованиям для этого шаблона сертификата. Обратите особое внимание на то, чтобы
    Отображаемое имя шаблона установлено на соответствующее имя вместе со следующими настройками:

    • Срок действия и периоды продления устанавливаются в соответствии с политикой безопасности вашей организации.
    • Соответствующие длины ключей
    • Выберите, хотите ли вы разместить сертификат в Active Directory.
    • Вкладка «Имя субъекта»: выбраны имя DNS и имя участника службы (SPN)
    • Если вы планируете импортировать сертификат в домен Active Directory Хранилище сертификатов служб, тогда также следует отметить закрытый ключ как экспортируемый.

  7. Нажмите ОК .
  8. Вернитесь в консоль Certificates или Certsrv и на панель сведений
    Шаблоны сертификатов
    , щелкните правой кнопкой мыши открытую область консоли, щелкните
    Новый
    , а затем щелкните Шаблон сертификата для выпуска .

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

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

  1. Откройте консоль Certificates . Нажмите Пуск , введите
    MMC , а затем нажмите клавишу ВВОД. Если система управления учетными записями пользователей запрашивает, убедитесь, что в нем отображается нужное действие, а затем нажмите
    Есть .
  2. В открывшейся консоли MMC (обычно Console1) щелкните File
    а затем нажмите Добавить / удалить оснастку
  3. В Добавить или удалить оснастки в разделе Доступные оснастки , нажмите
    Сертификаты , а затем щелкните Добавить .
  4. В оснастке «Сертификаты » выберите Учетная запись компьютера и нажмите
    Далее .
  5. В Выберите Компьютер , если вы управляете сервером LDAP, требующим сертификат, выберите
    Местный . В противном случае выберите Другой компьютер и нажмите
    Просмотрите , чтобы найти сервер LDAP, для которого требуется сертификат.
  6. После того, как вы выбрали правильный компьютер, нажмите ОК , а затем нажмите
    Отделка .
  7. В Добавить или удалить оснастки нажмите ОК .
  8. В дереве консоли разверните Сертификаты (<компьютер>)
  9. щелкните правой кнопкой мыши Сертификаты , щелкните Все задачи , а затем щелкните
    Запросить новый сертификат .

  10. В Certificate Enrollment щелкните Next .
  11. В Выберите политику регистрации сертификатов , как правило, вы оставляете значение по умолчанию
    Политика регистрации в Active Directory .Если у вас есть другая политика, которой вы должны следовать, выберите ее и нажмите
    Далее .
  12. Выберите сертификат, который разрешает проверку подлинности сервера, Kerberos работает, но вы можете использовать настраиваемый сертификат, как описано в разделе «Публикация сертификата, поддерживающего проверку подлинности сервера». Нажмите
    Записаться .

  13. В диалоговом окне «Регистрация сертификата » щелкните Завершить .
  14. В области результатов дважды щелкните полученный сертификат, чтобы открыть
    Сертификат диалоговое окно свойств.
  15. Щелкните вкладку 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, необходимо знать несколько важных деталей.

  1. Автоматическая регистрация сертификатов (автоматическая регистрация) не может использоваться с сертификатами в хранилище сертификатов NTDS \ Personal.
  2. Текущие инструменты командной строки не позволяют управлять сертификатами хранилища сертификатов NTDS \ Personal.
  3. Сертификаты необходимо импортировать в хранилище, а не перемещать (с помощью перетаскивания) через консоль сертификатов (MMC)
  4. Каждому серверу LDAP потребуется свой собственный сертификат для использования этой опции, но необходимо использовать эту опцию только на сервере, имеющем несколько сертификатов, с целью аутентификации сервера в локальном хранилище сертификатов.Лучшее решение
    иметь только один сертификат в личном сертификате компьютера

Следующие шаги продемонстрируют, как экспортировать сертификат с включенным LDAPS из локального хранилища сертификатов компьютера контроллера домена в хранилище сертификатов службы доменных служб Active Directory (NTDS \ Personal). Вам нужно будет выполнить этот шаг
для каждого контроллера домена, имеющего несколько сертификатов с включенной аутентификацией сервера. Эти сертификаты необходимо будет обновить вручную, когда срок их действия истечет, и они работают только начиная с контроллеров домена Windows Server 2008, поскольку это было
первый выпуск операционной системы Windows Server, в котором NTDS была выделена как отдельная служба.

  1. Щелкните Start , введите mmc и затем щелкните
    ОК
    .
  2. Щелкните Файл , а затем щелкните Добавить / удалить оснастку .
  3. Щелкните Сертификаты , а затем щелкните Добавить .
  4. В Certificates snap-in выберите Computer account и затем нажмите
    Далее .
  5. В Выберите Компьютер , если вы работаете на сервере LDAP, требующем сертификат, выберите
    Местный .В противном случае выберите Другой компьютер и нажмите
    Просмотрите , чтобы найти сервер LDAP, для которого требуется сертификат.
  6. После того, как вы выбрали правильный компьютер, нажмите ОК , а затем нажмите
    Отделка .

    В Добавить или удалить оснастки нажмите ОК .

  7. В дереве консоли разверните Сертификаты (<компьютер>)
  8. В консоли сертификатов компьютера, который содержит сертификат, который может использоваться для проверки подлинности сервера, щелкните сертификат правой кнопкой мыши, щелкните
    Все задачи , а затем щелкните Экспорт .

  9. На экране приветствия мастера экспорта сертификатов щелкните
    Далее
    .
  10. На экране Экспорт закрытого ключа выберите Да, экспортировать закрытый ключ и затем щелкните
    Далее . Если у вас нет возможности экспортировать закрытый ключ, значит, шаблон сертификата не позволял экспортировать закрытый ключ (см.

    Публикация сертификата, поддерживающего аутентификацию сервера).

  11. На экране Export File Format вы должны выбрать
    Экспортируйте все расширенные свойства
    . Остальные варианты не обязательны.

  12. На экране «Пароль» введите пароль, который будет использоваться при импорте сертификата. Вам нужно будет ввести пароль дважды: один раз в
    Пароль в поле , а затем снова в поле Введите и подтвердите пароль (обязательно) .Затем щелкните
    Далее .
  13. На экране Файл для экспорта введите путь, имя файла и расширение файла .pfx в поле
    Имя файла , а затем щелкните Далее .

  14. Подтвердите настройки на экране завершения и нажмите Готово . Вы должны увидеть всплывающее сообщение об успешном экспорте. Нажмите
    ОК .
  15. Щелкните Файл , а затем щелкните Добавить / удалить оснастку .
  16. Щелкните Сертификаты , а затем щелкните Добавить .
  17. Выберите Сервисный аккаунт , а затем щелкните Далее .

  18. В диалоговом окне Select Computer убедитесь, что выбран соответствующий компьютер. Если вы используете Microsoft Management Console (MMC) и хотите настроить таргетинг на локальный компьютер, вы можете оставить выбор по умолчанию:
    Локальный компьютер . В противном случае выберите Другой компьютер , а затем используйте
    Обзор , чтобы выбрать соответствующий компьютер.Затем нажмите
    Далее
    .
  19. Выберите Доменные службы Active Directory и затем щелкните
    Закончить
    .

  20. В диалоговом окне Добавить или удалить оснастки нажмите ОК .
  21. Разверните Сертификаты — Службы (доменные службы Active Directory) и щелкните
    NTDS \ Персональный .
  22. Щелкните правой кнопкой мыши NTDS \ Personal , щелкните Все задачи , а затем щелкните
    Импорт .

  23. На экране приветствия мастера импорта сертификатов щелкните
    Далее
    .
  24. На экране Файл для импорта щелкните Обзор , а затем найдите файл сертификата, который вы экспортировали ранее.
  25. На экране Открыть убедитесь, что Обмен личной информацией (* pfx, *. P12) выбран в качестве типа файла, а затем перейдите в файловую систему, чтобы найти сертификат, который вы экспортировали ранее, и затем щелкните этот сертификат.

  26. Щелкните Открыть , а затем щелкните Далее .
  27. На экране Пароль введите пароль, который вы установили для файла, а затем нажмите
    Далее .

  28. На странице Хранилище сертификатов убедитесь, что Поместить все сертификаты в следующее хранилище выбрано и читает
    Хранилище сертификатов: NTDS \ Personal , а затем щелкните Далее .

  29. На экране завершения мастера импорта сертификатов щелкните
    Закончить
    . Затем вы должны увидеть сообщение об успешном импорте. Нажмите
    ОК .
  30. На панели навигации в разделе NTDS \ Personal щелкните Сертификаты
  31. В области сведений щелкните правой кнопкой мыши импортированный сертификат и выберите
    Открыть
    .

  32. Щелкните Details , а затем щелкните Enhanced Key Usage, вы должны увидеть, что
    Аутентификация сервера (1.3.6.1.5.5.7.3.1) является одной из целей сертификата, а затем щелкните
    ОК .

После установки сертификата выполните следующие действия, чтобы убедиться, что LDAPS включен:

  1. Запустите инструмент администрирования Active Directory (Ldp.exe)
  2. В меню Connection щелкните Connect .
  3. Введите имя сервера LDAP (например, контроллера домена или сервера AD LDS / ADAM), к которому вы хотите подключиться.
  4. Введите 636 в качестве номера порта.
  5. Щелкните ОК .

Когда у вас возникают проблемы с 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-адресом и идентификатором привязки клиента каждый раз, когда выполняется или предпринимается попытка привязки без знака.

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

2022 © Все права защищены. Карта сайта