Глава 5. Примеры OpenLDAP

5.4 Создание и добавление объектов

Содержание

5.1.1 Проектирование DIT
5.1.2 Выбор структурного объектного класса
5.1.3 Файл slapd.conf
5.1.4 Файл LDIF
5.1.5 Загрузка LDIF-файла
5.1.6 Добавление записей с помощью LDIF
5.1.7 Изменение записей с помощью LDIF
5.1.8 Напоследок просто подурачимся

5.2 Защита каталога

5.2.1 Политика безопасности
5.2.2 Добавление групп
5.2.3 ACL — директивы access файла slapd.conf
5.2.4 Тестирование ACL

5.3 Расширение иерархии

5.3.1 Расширение требований
5.3.2 Реализация расширения
5.3.3 LDIF для реализации расширения
5.3.4 ACL — директивы access файла slapd.conf
5.3.5 Тестирование ACL

5.4 Создание и добавление объектов

5.4.1 Требования
5.4.2 Реализация
5.4.3 Определения атрибутов
5.4.4 Определение объектного класса и набора схемы
5.4.5 ACL — директивы access файла slapd.conf
5.4.6 LDIF
5.4.7 Тестирование изменений

5.5 Технология единого входа (Single Sign On)
5.6 Отсылки и репликация

5.4 Создание и добавление объектов

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

5.4.1 Требования

Видя ещё более успешное внедрение LDAP, руководители нашей корпорации решили добавить в текущую реализацию нашего каталога следующие возможности:

Атрибут dohicky. Этот атрибут будет содержать логические значения. Его смогут просматривать и обновлять только владелец записи и любой член группы hrpeople.
Атрибут ageAtBirth (обратите внимание на особенно глупую псевдовенгерскую нотацию — Вы видите такое в последний раз). Этот атрибут будет содержать числовые значения. Его смогут просматривать и обновлять только владелец записи и любой член группы hrpeople.
Атрибут gobbledegook. Этот атрибут будет содержать строковые значения и будет публично доступен для просмотра всем пользователям, прошедшим аутентификацию. Его смогут обновлять только владелец записи и любой член группы hrpeople. Од должен быть доступен для поиска с помощью поисковых фильтров <= и >=.
В рамках нашего перехода на технологию единого входа (SSO), мы добавим каждому пользователю стандартный объектный класс posixAccount. Данная запись будет доступна для просмотра только группе itpeople.

5.4.2 Реализация

Мы очень старались найти среди существующих атрибутов объектного класса inetorgperson такие, которые можно было бы использовать под наши нужды (попросту, использовать существующие атрибуты с необходимым синтаксисом (SYNTAX), несмотря на то, что их оригинальное "предназначение" разрабатывалось для иных целей), но, увы, ничего не вышло. Итак, нам остаётся только создать свои собственные объекты. Вот что мы хотим, или точнее, что мы должны сделать:

Атрибут dohicky. Создадим свой собственный, используя OID существующего синтаксиса boolean.
Атрибут ageAtBirth. Создадим свой собственный, используя OID существующего синтаксиса integer.
Атрибут gobbledegook. Создадим свой собственный, используя OID существующего синтаксиса PrintableString. А для того, чтобы получить возможность пользоваться поисковыми фильтрами <= и >=, нужно использовать правило соответствия ORDERING (caseIgnoreOrderingMatch).
Для этих трёх атрибутов мы создадим новый объектный класс и назовём его ourObject (довольно креативное имя). Поскольку в каждой записи у нас уже есть структурный (STRUCTURAL) объект (inetorgperson), мы будем использовать вспомогательный (AUXILIARY) объектный класс.

Если бы нам требовались структурные объекты, нам пришлось бы делать их всех дочерними по отношению к нашим текущим записям inetorgperson, как мы уже делали на предыдущем шаге с частными адресными книгами. Альтернативный путь: мы могли бы сделать ourObject структурным и использовать в его определении sup inetOrgPerson, добавляя его, таким образом, в конец иерархии объектных классов Person ->organizationalPerson ->inetOrgPerson (смотрите определение объектного класса).
При создании и объектного класса и атрибутов требуется, чтобы они были глобально уникальными. В данном примере используются глобально уникальные OID, которые можно безопасно использовать В ЦЕЛЯХ ТЕСТИРОВАНИЯ ЭТОГО ПРИМЕРА. НЕ ПОДДАВАЙТЕСЬ ИСКУШЕНИЮ ПОВТОРНО ИСПОЛЬЗОВАТЬ ЭТИ ИЛИ ЛЮБЫЕ ДРУГИЕ OID. Получение собственного номера для своего предприятия, позволяющего определять свои собственные атрибуты и объектные классы — простая и бесплатная процедура, предоставляемая IANA. Использование существующих OID — очень скверная штука (VERY BAD THING™).
Поскольку наше любимое и уважаемое корпоративное руководство вряд ли остановится на этом, мы решили упаковать эти фенечки (атрибуты и объектный класс) в набор схемы, который мы назовём ourco.schema (опять же, весьма оригинально).
Слава Богу, объектный класс posixAccount — это вспомогательный (AUXILIARY) класс. Поскольку некоторые атрибуты данного объектного класса используются и в других объектных классах, мы пересмотрим ту драконовскую директиву, которая разрешает доступ к атрибутам posixAccount только для itpeople. Теперь мы ограничим доступ только к уникальным атрибутам данного объектного класса, в частности — homedirectory, gidnunber, uidnumber, loginshell и gecos.

5.4.3 Определения атрибутов

Мы создали следующие определения атрибутов:

dohicky — boolean

attributetype ( 1.3.6.1.4.1.6863.2.3.107 NAME 'dohicky'
  EQUALITY booleanMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

OID данного атрибута построен согласно предполагаемому нами соглашению о нумерации. Мы используем OID стандартного синтаксиса типа данных boolean. Правило соответствия — только EQUALITY. Дополнительную информацию по определению атрибутов можно найти здесь.

ageAtBirth — integer

attributetype ( 1.3.6.1.4.1.6863.2.3.108 NAME 'ageAtBirth'
  EQUALITY integerMatch
  ORDERING integerOrderingMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

OID данного атрибута построен согласно предполагаемому нами соглашению о нумерации. Мы используем OID стандартного синтаксиса типа данных integer. Правила соответствия — EQUALITY и ORDERING. Дополнительную информацию по определению атрибутов можно найти здесь.

gobbledegook — PrintableString

Порой можно встретить варианты gobbledigook или даже gobbledygook — не обращайте внимания, у нас самый точный вариант написания!

attributetype ( 1.3.6.1.4.1.6863.2.3.109 NAME 'gobbledegook'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  ORDERING caseIgnoreOrderingMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{200} )

OID данного атрибута построен согласно предполагаемому нами соглашению о нумерации. Для данного атрибута мы используем OID стандартного синтаксиса типа данных PrintableString и определяем максимальную длину строки в 200 символов (в фигурных скобках). Правила соответствия — EQUALITY, SUBSTR и ORDERING. . Дополнительную информацию по определению атрибутов можно найти здесь.

5.4.4 Определение объектного класса и набора схемы

objectclass ( 1.3.6.1.4.1.6863.2.4.57 NAME 'ourObject'
  DESC 'A very useful object'
  SUP top AUXILIARY 
  MUST ( dohicky $ gobbledegook )
  MAY ageAtBirth )

OID данного объектного класса построен согласно предполагаемому нами соглашению о нумерации.

SUP top ограничивает иерархию объектных классов с помощью удобного объектного класса top.

AUXILIARY позволяет нам использовать данный объектный класс совместно с любым структурным объектным классом.

MUST ( dohicky $ gobbledegook ) определяет, что атрибуты dohicky и gobbledegook должны присутствовать в той записи, куда добавляется данный объектный класс. А MAY ageAtBirth, напротив, говорит о том, что данный атрибут является необязательным.

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

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

Немного о белках: Пункт DESC большинства объектных классов и типов атрибутов, как правило, столь же значим и полезен, как и в примере нашего объектного класса. В этой жизни множество раздражающих вещей, и одна из них, — то, что мы называем "комплексом белки", — неестественное желание скрыть суть или предназначение того или иного предмета. Однажды поэта лорда Байрона спросили о значении строки одного из его стихотворений. Он ответил: "Когда я писал это, значение было известно мне и Богу, а теперь — одному только Богу". Всё рано или поздно забывается. Почему бы не добавить несколько слов осмысленного описательного текста? Особенно если разработчики предусматривают какие-нибудь серьёзные ограничения или особое использование своего объекта.

# ФАЙЛ НАБОРА СХЕМЫ EXAMPLE.COM
# атрибут принимает значение:
# true = надевает свежие носки по понедельникам
# false = не надевает свежие носки по понедельникам
attributetype ( 1.3.6.1.4.1.6863.2.3.107 NAME 'dohicky'
  EQUALITY booleanMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

# если присутствует, должен быть равен 0
attributetype ( 1.3.6.1.4.1.6863.2.3.108 NAME 'ageAtBirth'
  EQUALITY integerMatch
  ORDERING integerOrderingMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

# строка, используемая для описания роста человека в футах/дюймах или метрах
# може быть представлена в виде xfyi, например  5f7i (5 футов 7 дюймов) или x.ym, например 1.95m (1.95 метра)
# значения f, i, m не чувствительны к регистру
attributetype ( 1.3.6.1.4.1.6863.2.3.109 NAME 'gobbledegook'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  ORDERING caseIgnoreOrderingMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{200} )

# объектный класс, используемый в адресной книге для определения необходимой информации
# согласно Федеральному закону 5.7.3 — эти данные определены как конфиденциальные — требуется ограниченный доступ
objectclass ( 1.3.6.1.4.1.6863.2.4.57 NAME 'ourObject'
  DESC 'A very useful object'
  SUP top AUXILIARY 
  MUST ( dohicky $ gobbledegook )
  MAY ageAtBirth )

5.4.5 Изменения slapd.conf

Мы должны внести изменения в файл slapd.conf, во-первых, для того, чтобы подправить права доступа, а главное — для того, чтобы сообщить OpenLDAP о нашем новом объектном классе с помощью директивы include /usr/local/etc/openldap/schema/ourco.schema, чтобы он не задохнулся при виде атрибута dohicky. Вот наш изменённый slapd.conf:

#
###### ПРИМЕР 4 — КАТАЛОГ с доморощенными объектным классом и атрибутами ############
#
# Примечание: inetorgperson использует атрибуты и
#     объектные классы из всех трёх наборов схемы
#     объектный класс device определён в core.schema
#     объектный класс posixAccount — в nis.schema
#     добавляется ourco.schema
#
# NB: В RH Linux наборы схемы располагаются в /etc/openldap
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/ourco.schema
# НЕТ ОТСЫЛОК

# НЕ заботимся о файле ARGS, пока не обретём уверенность в своих силах
# stop-скрипту slapd следующая строка необходима для работы:
pidfile /var/run/slapd.pid

# Включаем большое количество вывода в журнал — нам это может понадобиться
loglevel 	-1 

# НЕТ динамических модулей backend

# НЕТ соединений TLS

#######################################################################
# Определение базы данных bdb
# 
# Замените ниже example и com на подходящее имя домена
# 
# Если у Вас нет домена, то, поскольку example.com зарезервирован для
# экспериментов, можете оставить его, либо поменять на my.inc
#######################################################################

database bdb
suffix "dc=example, dc=com"
# ACL1
# только владелец и члены itgroup могут просматривать и обновлять
access to attrs=userpassword
  by self       write
  by anonymous  auth
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by *          none

# ACL1A
# только владелец и члены itgroup могут просматривать и обновлять
access to attrs=homedirectory,uidnumber,gidnumber,loginshell,gecos
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by *          none
	
# ACL2
# разрешаем читать addressbook владельцу и itpeople; остальные не могут её просматривать
access to dn.regex="^ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
    attrs=entry
  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" read
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by users none

# ACL3
# разрешаем itgroup создавать addressbook, но не просматривать записи
access to dn.regex="cn=[^,]+,ou=people,dc=example,dc=com$"
   attrs=children
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by users none break

# ACL4
# разрешаем создавать записи в своей собственной addressbook;
# остальные не могут получить к ней доступ, требуются права на запись
# в атрибут ENTRY (ACL5) и дочерние (CHILDREN) записи данной записи (ACL4)
access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
   attrs=children
  by dn.regex,expand="cn=$1,ou=people,dc=example,dc=com" write
  by users none

# ACL5
# разрешаем создание записей в своей addressbook;
# остальные не могут получить к ней доступ, требуются права на запись
# в атрибут ENTRY (ACL5) и дочерние (CHILDREN) записи данной записи (ACL4)
access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
   attrs=entry
  by dn.regex,expand="cn=$1,ou=people,dc=example,dc=com" write
  by users none

# ACL6
# разрешаем создание записей в своей addressbook;
# остальные не могут получить к ней доступ
access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
   filter=(objectclass=inetorgperson)
  by dn.regex,expand="cn=$1,ou=people,dc=example,dc=com" write
  by users none

# В LDAP 2.2+ ACL5 и ACL6 заменяются на:
#access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
#   attrs=entry,@inetorgperson
#  by dn.regex,expand="cn=$1,ou=people,dc=example,dc=com" write
#  by users none

# ACL7
# разрешаем sales создание записей в customers
# пользователи, прошедшие аутентификацию получают доступ только на чтение
access to dn.one="ou=customers,dc=zytrax,dc=com"
   attr=children
  by group.exact="cn=salespeople,ou=groups,dc=example,dc=com" write
  by users read

# ACL8
access to attr=carlicense,homepostaladdress,homephone,dohicky,ageatbirth
  by self       write
  by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write
  by *          none

# ACL8A — контроль доступа к equipment
access to dn.one="ou=equipment,dc=example,dc=com"
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by users      read
	by *          none
# ACL9
access to *
  by self       write
  by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write
  by users      read
  by *          none
# root или администратор
rootdn "cn=jimbob, dc=example, dc=com"
rootpw dirtysecret
# Директория базы данных ДОЛЖНА существовать до того, как Вы запустите slapd 
# Не забудьте поменять путь на подходящий Вам
directory	/var/db/openldap/example-com

# Устанавливаемые для каталога индексы
# Только полное соответствие для unique id
index	uid	eq
# Стандартный поиск для commonname, givenname и email
index	cn,gn,mail eq,sub
# Несколько вариантов для поиска surname
index sn eq,sub
# В индексах выше sub включает в себя subintial,subany,subfinal
# Оптимизируем поиск по подразделениям
index ou eq
# Если при поиске будет встречаться objectClass, раскомментируйте следующую строку
# index objectClass eq
# Продемонстрировано использование параметра индексирования default
index default eq,sub
# Настройка индексирования пропущена, по умолчанию используется eq,sub
index telephonenumber

# Другие параметры базы данных
# Дополнительная информация в разделе справочника по slapd.conf
cachesize 10000
checkpoint 128 15

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

Примечания:

Мы добавили директивы include для подключения наборов схемы nis.schema (для posixAccount) и ourco.schema (для ourObject и различных атрибутов).
Мы добавили директиву access (ACL1A), чтобы ограничения доступа касались только атрибутов homedirectory, uidnumber и gidnumber (к ним доступ получают только члены itgroup согласно требованиям нашей политики безопасности). В OpenLDAP версий 2.2+ мы можем использовать синтаксис attr=@posixaccount (все атрибуты объектного класса posixAccount), но тогда у нас будет незначительный побочный эффект ограничения доступа к cd! Не совсем то, что мы хотим.
Мы добавили dohickey и ageatbirth в директиву access (ACL8), предоставляя доступ к этим атрибутам только членам группы hrgroup и владельцу записи.

Теперь нам нужно остановить и снова запустить OpenLDAP, чтобы он принял новый файл slapd.conf. Это делается с помощью следующих команд:

# Остановка и запуск OpenLDAP (slapd)
# Linux/Redhat
/etc/rc.d/init.d/ldap restart

# BSD
[bsd] /usr/local/etc/openldap/slapd.sh stop
# затем
[bsd] /usr/local/etc/rc.d/slapd.sh start

# убеждаемся, что slapd запущен
ps ax | grep slapd

5.4.6 LDIF

С помощью приведённого ниже LDIF в наши записи вносятся изменения. Добавляется объектный класс posixAccount и его обязательные атрибуты, а также объектный класс ourObject со своими обязательными атрибутами.

Ни один из используемых нами LDAP-браузеров не позволяет добавлять новые вспомогательные (AUXILIARY) объектные классы. Видимо, LDIF — единственный способ сделать это.

version: 1

dn: cn=john smith,ou=people,dc=example,dc=com
changetype: modify
objectclass: inetorgperson
objectclass: posixaccount
uidnumber: 200
gidnumber: 203
homedirectory: /var/mail/example.com/jsmith
objectclass: ourObject
dohicky: false
gobbledegook: john
ageatbirth: 0

dn: cn=sheri smith,ou=people,dc=example,dc=com
changetype: modify
objectclass: inetorgperson
objectclass: posixaccount
uidnumber: 201
gidnumber: 203
homedirectory: /var/mail/example.com/ssmith
objectclass: ourObject
dohicky: true
gobbledegook: sheri

dn: cn=robert smith,ou=people,dc=example,dc=com
changetype: modify
objectclass: inetorgperson
objectclass: posixaccount
uidnumber: 202
gidnumber: 203
homedirectory: /var/mail/example.com/rsmith
objectclass: ourObject
dohicky: false
gobbledegook: robert
ageatbirth: 17

Примечания:

При использовании утилиты ldapmodify директива changetype не является строго обязательной, поскольку она подразумевается как значение по умолчанию.
Строка objectclass: inetorgperson необходима, поскольку она сообщает OpenLDAP с каким структурным (STRUCTURAL) объектным классом будут использоваться вспомогательные (AUXILIARY) объектные классы.
Обязательные (MUST) атрибуты каждого объектного класса должны присутствовать. Наличие необязательных (MAY) атрибутов — по желанию.

Предположим, что мы сохранили приведённый выше LDIF как modify.ldif в директории /tmp. Тогда мы будем загружать LDIF-файл с помощью примерно такого вызова ldapmodify (приведённая ниже команда разбита на две строки только из соображений форматирования HTML и должна записываться в одну строку):

ldapmodify -H ldap://ldaphost.example.com -x -D "cn=jimbob,dc=example,dc=com" 
 -f /tmp/modify.ldif -w dirtysecret

Замените ldaphost.example.com на имя того хоста, на котором располагается Ваш каталог LDAP. Если мы вызываем команду на том же хосте, на котором работает LDAP-сервер, параметр -H может быть опущен. Параметр -x указывает, что мы не будем использовать SASL-аутентификацию, он требуется только начиная с OpenLDAP версий 2.x. В параметре -D указан DN, от имени которого мы производим подключение, в данном случае rootdn — администратору приходится выполнять всю работу. Указывать пароль вслед за параметром -w, как мы это сделали в примере, мягко скажем, небезопасно, Вы можете использовать -W, тогда пароль будет запрошен после вызова команды.

5.4.7 Тестирование изменений

Теперь нужно проверить внесённые нами изменения. Для проверки ACL используйте Ваш LDAP-браузер и следующие тесты:

Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=Robert Smith, ou=people, dc=example, dc=com с паролем (userpassword) rJsmitH (регистр символов имеет значение). Поскольку у данной записи есть привилегии hrpeople, её владелец сможет просматривать и изменять все записи, в том числе атрибуты carlicense, homepostaladdress и homephone, но не атрибут userpassword (за исключением своей собственной записи), а также сможет читать записи customers и equipment, но не писать в них. Robert Smith также может просматривать и добавлять записи в свою собственную подзапись адресной книги (addressbook), но может только догадываться, есть ли у кого-нибудь еще адресная книга (то есть не может увидеть запись addressbook у кого-либо другого). Он не может видеть атрибуты homedirectory, guidnumber, gidnumber, loginshell и gecos объектного класса posixAccount в своей собственной и в любой другой записи.
Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=Sheri Smith, ou=people, dc=example, dc=com с паролем (userpassword) sSmitH (регистр символов имеет значение). Поскольку у данной записи есть привилегии itpeople, её владелица сможет просматривать и изменять атрибуты userpassword, homedirectory, guidnumber, gidnumber, loginshell и gecos всех записей, не не сможет просматривать атрибуты carlicense, homepostaladdress и homephone какой-либо записи, за исключением своей собственной. Она сможет читать записи в ветке customers, но не сможет писать туда. Она сможет читать и записывать записи в ветку equipment. Sheri Smith также может просматривать и добавлять записи в свою собственную подзапись адресной книги (addressbook), а также видеть подзапись addressbook (но не дочерние ей подзаписи) у любого человека. Она может также удалить подзапись addressbook у любой записи (и если Вы хотите это попробовать, не переживайте, Вы также можете добавить её назад!)
Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=John Smith, ou=people, dc=example, dc=com с паролем (userpassword) jSmitH (регистр символов имеет значение). Поскольку у данной записи нет привилегий, её владелец не сможет просматривать атрибуты carlicense, homepostaladdress, homephone и userpassword какой-либо записи, за исключением своей собственной (которую, также, сможет и модифицировать). Поскольку данная запись является членом группы salespeople, её владелец сможет читать и записывать записи в ветке customers, а записи в ветке equipment сможет только читать. John Smith также может просматривать и добавлять записи в свою собственную подзапись адресной книги (addressbook), но может только догадываться, есть ли у кого-нибудь еще адресная книга (то есть не может увидеть запись addressbook у кого-либо другого). Он не может видеть атрибуты homedirectory, guidnumber, gidnumber, loginshell и gecos объектного класса posixAccount в своей собственной и в любой другой записи.
Настройте Ваш LDAP-браузер на анонимное подсоединение и убедитесь, что доступ запрещён.
Пройдите аутентификацию от имени настроенного нами rootdn или администратора (определён в slapd.conf как cn=jimbob,dc=example,dc=com, пароль dirtysecret) и убедитесь, что в этом случае игнорируются все наши привилегии и можно просматривать и изменять всё что угодно.
На данном этапе может быть полезно экспортировать текущее состояние каталога в LDIF с помощью функции экспорта Вашего LDAP-браузера, либо slapcat.

Примечание: Во всех приведённых выше тестах Вы должны быть в состоянии с помощью Вашего LDAP-браузера просматривать ветки customers, equipment и groups, а также записи в них. Если этого не происходит, то, вероятно, Вы установили значение Base DN (или Root DN) Вашего LDAP-браузера в ou=people,dc=example,dc=com. Установите его в dc=example,dc=com, и тогда Вы сможете просматривать все эти записи.

Шаг 5 — Технология единого входа (Single Sign On, SSO)

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Нашли ошибку в переводе? Сообщите переводчикам!