Настройка OpenLDAP и Kerberos для использования доменной авторизации в Linux

sudo nano /etc/default/named

В данной статье протокол IPv6 не используется, так как предполагается использование локальной сети предприятия, для которой будет достаточно адресного пространства IPv4.

Для применения настроек перезапускаем bind:

sudo systemctl restart bind9

Открываем файл настроек опций bind:

sudo nano /etc/bind/named.conf.options

Перед блоком options создаем новый блок ACL (список контроля доступа, https://ru.wikipedia.org/wiki/ACL) под псевдонимом trusted. В нем нужно определить список клиентов или подсеть целиком, из которых вы будете разрешать рекурсивные DNS-запросы.

cl "trusted" {
        10.0.2.1 # ns1.da-test.loc;

        10.0.2.0/24;
};

Далее, в секции options, после параметра directory добавьте:

recursion yes;                 # разрешить использование рекурсивных запросов
allow-recursion { trusted; };  # разрешить рекурсивные запросы для доверетильных клиентов (для acl "trusted")

listen-on { 10.0.2.1; };       # ip-адрес dns-сервера (адрес текущего сервера)
allow-transfer { none; };      # disable zone transfers by default

 
forwarders {

    8.8.8.8;
    8.8.4.4;

};

Обратите внимание на блок переадресации ("forwarders"). Он включает в себя два IP-адреса: 8.8.8.8 и 8.8.4.4. Этот блок определяет адреса переадресации (специальный механизм, который BIND использует для уменьшения трафика по ссылкам на внешние dns-серверы).

sudo nano /etc/bind/named.conf.local

zone "da-test.loc" {
    type primary;

    file "/etc/bind/zones/db.da-test.loc"; # путь к файлу описания forward зоны
};

 
zone "2.0.10.in-addr.arpa" {

    type primary;
    file "/etc/bind/zones/db.2.0.10";      # Файл подсети 10.0.2.0/24 (reverse)

};

Теперь нужно создать сам файл forward зоны. В этом файле вы определяете записи для прямого поиска dns. То есть, когда сервер имен получает запрос имени, например, app1.da-test.loc, он будет искать в файле forward-зоны соответствующий ip-адрес для компьютера с именем app1.

В соответствии с конфигурационным файлом named.conf.local, это местоположение должно быть /etc/bind/zones:

sudo mkdir /etc/bind/zones

Файл зоны будем содавать не с нуля, а с помощью базового файла:

sudo cp /etc/bind/db.local /etc/bind/zones/db.da-test.loc

После копирования файла откроем его в редакторе:

sudo nano /etc/bind/zones/db.da-test.loc

@       IN      SOA     ns1.da-test.loc. admin.da-test.loc. (

@       IN      NS      localhost.    
@       IN      A       127.0.0.1       
@       IN      AAAA    ::1

; NS-записи
    IN      NS      ns1.da-test.loc.

; Серверы имен - A-записи
ns1.da-test.loc.          IN      A      10.0.2.1
 
; 10.0.2.0/24 - A-записи

da1.da-test.loc.          IN      A      10.0.2.2
app1.da-test.loc.         IN      A      10.0.2.3

dbms1.da-test.loc.        IN      A      10.0.2.4
pc1.da-test.loc.          IN      A      10.0.2.5

$TTL    604800
@       IN      SOA     ns1.da-test.loc. admin.da-test.loc. (

                  3     ; Serial
             604800     ; Refresh

              86400     ; Retry
            2419200     ; Expire

             604800 )   ; Negative Cache TTL
;

; NS-записи
    IN      NS      ns1.da-test.loc.

 
; Серверы имен - A-записи

ns1.da-test.loc.          IN      A       10.0.2.1 
; 10.0.2.0/24 - A-записи

da1.da-test.loc.          IN      A      10.0.2.2
app1.da-test.loc.         IN      A      10.0.2.3

dbms1.da-test.loc.        IN      A      10.0.2.4
pc1.da-test.loc.          IN      A      10.0.2.5

Файл reverse-зоны мы будем создавать также с помощью копирования файла:

sudo cp /etc/bind/db.127 /etc/bind/zones/db.2.0.10

sudo nano /etc/bind/zones/db.2.0.10

@       IN      SOA     ns1.da-test.loc. admin.da-test.loc. (

@       IN      NS      localhost.      
1.0.0   IN      PTR     localhost.

      IN      NS      ns1.da-test.loc.

2.1   IN      PTR     ns1.da-test.loc.    ; 10.0.2.1
2.2   IN      PTR     da1.da-test.loc.    ; 10.0.2.2

2.3   IN      PTR     app1.da-test.loc.   ; 10.0.2.3
2.4   IN      PTR     dbms1.da-test.loc.  ; 10.0.2.4

2.5   IN      PTR     pc1.da-test.loc.    ; 10.0.2.5

$TTL    604800
@       IN      SOA     ns1.da-test.loc. admin.da-test.loc. (

                              3         ; Serial
                         604800         ; Refresh

                          86400         ; Retry
                        2419200         ; Expire

                         604800 )       ; Negative Cache TTL
; Серверы имен - NS-записи

      IN      NS      ns1.da-test.loc. 
; PTR-записи

2.1   IN      PTR     ns1.da-test.loc.    ; 10.0.2.1
2.2   IN      PTR     da1.da-test.loc.    ; 10.0.2.2

2.3   IN      PTR     app1.da-test.loc.   ; 10.0.2.3
2.4   IN      PTR     dbms1.da-test.loc.  ; 10.0.2.4

2.5   IN      PTR     pc1.da-test.loc.    ; 10.0.2.5

sudo named-checkconf

Если в конфигурационных файлах нет синтаксических ошибок, вывод команды будет пустым. При возникновении проблем с конфигурационными файлами, внимательно прочтите сообщение об ошибке и попробуйте проанализировать конфигурационные файлы на предмет ошибок. Затем повторно выполните named-checkconf когда обнаруженные ошибки будут исправлены.

С помощью команды named-checkzone можно проверить правильность настройки файлов зоны. Первый аргумент указывает на имя зоны, а второй на соответствующий файл зоны, которые должны быть определены в named.conf.local.

Например, чтобы проверить настройку домена da-test.loc для forward-зоны, выполните следующую команду:

sudo named-checkzone da-test.loc /etc/bind/zones/db.da-test.loc

Output
zone da-test.loc/IN: loaded serial 3

OK

sudo named-checkzone 2.0.10.in-addr.arpa /etc/bind/zones/db.2.0.10

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

sudo systemctl restart bind9  

Также не забудьте, если у вас настроен брандмауэр UFW, то нужно открыть доступ к BIND с помощью команды:

sudo ufw allow Bind9  

Ваш основной DNS-сервер теперь настроен и готов отвечать на DNS-запросы.

Прежде чем все серверы и клиентские компьютеры в доверенном ACL смогут запрашивать ваш DNS-сервер, вы должны настроить каждый из них на использование ns1.da-test.loc в качестве сервера имен.

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

ip address

Запустите следующую команду на каждой из ваших клиентских машин, заменив выделенную подсеть своей собственной:

ip address show to 10.0.2.0/24  

Результатом будет вывод:

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 
    inet 10.0.2.5/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 511sec preferred_lft 511sec  

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

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

Создадим новый файл в /etc/netplan, который будет называться 00-private-nameservers.yaml:

sudo nano /etc/netplan/00-private-nameservers.yaml  

После чего добавим текст следующего содержания:

network: 
    version: 2
    ethernets: 
        enp0s3:                             # Частный сетевой интерфейс
            nameservers: 
                addresses:
                - 10.0.2.1                 # IP-адрес для for ns1.da-test.loc 
                search: [ da-test.loc ]     # Зона DNS

Сохраните и закройте файл настроек.

sudo netplan try

При возникновении проблем с работой в сети, Netplan в таком случае автоматически откатит изменения по истечении тайм-аута:

Output 
Warning: Stopping systemd-networkd.service, but it can still be activated by:
  systemd-networkd.socket 
Do you want to keep these settings?
   
Press ENTER before the timeout to accept the new configuration
   
Changes will revert in 120 seconds  

Теперь проверьте, что система видит сервер имен, чтобы определить, была ли применена ваша конфигурация DNS:

sudo resolvectl status  

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

Link 2 (enp0s3) 
Current Scopes: DNS
     Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported 
   DNS Servers: 10.0.2.1
    DNS Domain: da-test.loc 

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

С помощью команды nslookup, мы можем проврить доступность сервера имен.

nslookup app1  

При запросе app1, его имя расширяется до app1.da-test.loc поскольку параметр Search установлен для поиска поддомена da-test.loc (в соответствии с ранее настроенным 00-private-nameservers.yaml), и DNS-запросы будут пытаться выполнить поиск в этом поддомене, прежде чем искать хост в другом месте. Команда вернет вывод, подобный следующему:

Server:         10.0.2.1 
Address:        10.0.2.1#53
  
Name:    app1.da-test.loc
Address: 10.0.2.3  

Чтобы протестировать обратный поиск, запросите сервер имен с частным IP-адресом app1:

nslookup 10.0.2.3  

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

3.2.0.10.in-addr.arpa   name = app1.da-test.loc.2.0.10.in-addr.arpa.  

На этом настройка сервера имен закончена.

3. Установка OpenLDAP и Kerberos

passwd 
Введите новый пароль UNIX:
Повторите ввод нового пароля UNIX:

После нужно установить необходимые пакеты

sudo apt-get install slapd ldap-utils krb5-kdc-ldap sudo-ldap  

Во время установки Вам будет предложено задать некоторые настройки:

Пароль учётной записи admin для доступа к конфигурации OpenLDAP - укажите свой

Сервер Kerberos для нашей области - da1.da-test.loc

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

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

dpkg --get-selections|egrep '(slapd|ldap-utils|krb5-kdc-ldap|sudo-ldap)' 
krb5-kdc-ldap                                   install
ldap-utils                                      install 
slapd                                           install
sudo-ldap                                       install  

4. Настройка OpenLDAP

mkdir ~/ldap 
cd ~/ldap

Теперь удалим установленные по умолчанию конфигурации службы OpenLDAP (slapd) вместе с базой данных:

sudo systemctl stop slapd 
sudo rm -rf /etc/ldap/slapd.d
sudo rm -rf /var/lib/ldap  

После этого добавим пустую директорию, где будет храниться новая конфигурация:

mkdir /etc/ldap/slapd.d

Теперь можно приступать к настройке OpenLDAP. Создадим файл init-ldap-config.ldif:

nano init-ldap-config.ldif  

После чего добавим в него текст:

dn: cn=config 
objectClass: olcGlobal
cn: config 
olcPidFile: /var/run/slapd/slapd.pid
olcArgsFile: /var/run/slapd/slapd.args  
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig 
olcDatabase: {0}config
olcAccess: to * 
  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
  
dn: cn=schema,cn=config
objectClass: olcSchemaConfig 
cn: schema  

Первым делом в файле мы определили корневую запись DIT (Directory Information Tree, https://en.wikipedia.org/wiki/Directory_information_tree), cn=config. Далеее, с помощью директив olcPidFile и olcArgsFile указали расположения, где будут записаны идентфиикатор процесса службы каталогов вместе с его аргументами запуска.

И в конце файла мы добавляем в конфигурацию контейнер для наборов схем данных (olcSchemaConfig).

sudo slapadd -n 0 -F /etc/ldap/slapd.d -l init-ldap-config.ldif 
_#################### 100.00% eta   none elapsed            none fast!
Closing DB...

Далее проверим состояние применения конфигурации:

sudo slaptest -uF /etc/ldap/slapd.d 
config file testing succeeded  

Исправим права доступа, разрешив пользователю openldap управлять файлами и директориями в /etc/ldap/slapd.d:

sudo chown -R openldap:openldap /etc/ldap/slapd.d 
sudo chmod 750 /etc/ldap/slapd.d  

Так как в начале статьи для сервера имен установили использование только IPv4, то укажем службе каталогов использовать только этот протокол. Для этого в файле /etc/default/slapd зададим SLAPD_OPTIONS="-4". 

SLAPD_OPTIONS="-4"  

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

# Файл журнала службы каталогов /var/log/slapd.log 
if $programname == 'slapd' then /var/log/slapd.log
& ~  

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

sudo touch /var/log/slapd.log 
sudo chmod 0640 /var/log/slapd.log
sudo chown syslog:adm /var/log/slapd.log

Затем перезапустим rsyslog, чтобы изменения вступили в силу:

sudo systemctl restart rsyslog  

Далее настраиваем правила ротации логов службы каталогов. Для этого создаем файл конфигурации /etc/logrotate.d/slapd и добавляем в него текст:

/var/log/slapd.log { 
 daily
 missingok 
 rotate 7
 compress 
 delaycompress
 notifempty 
}  

Делаем проверку настройки ротации:

sudo logrotate -df /etc/logrotate.conf  

И запускаем службу каталогов:

sudo systemctl start slapd 
 * Starting OpenLDAP slapd  [ OK ]  

Выполним проверку записи в журнал событий:

sudo tail /var/log/slapd.log 
...
slapd starting  

Проверим статус запуска службы (по умолчанию служба работает на порту 389):

sudo ss -tan | grep 389 
LISTEN  0 128 *:389  *:*
  
sudo ss -xa | grep ldap
u_str LISTEN  0 128 /var/run/slapd/ldapi  44345  * 0  

И в конце проверим текущую конфигурацию каталога:

sudo ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'cn=config' dn 
dn: cn=config
dn: cn=schema,cn=config 
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config  

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

dn: cn=module,cn=config 
objectClass: olcModuleList
cn: module 
olcModulePath: /usr/lib/ldap
olcModuleLoad: back_mdb.la 
olcModuleLoad: back_monitor.la  

Далее применем содержимое файла в конфигурацию:

sudo ldapadd -QY EXTERNAL -H ldapi:/// -f switch-dynamic-modules.ldif 
adding new entry "cn=module,cn=config"  

Теперь нам нужно установить набор схем данных. Набор схем данных - это удобное хранилище для содержания объектных классов и атрибутов из одной предметной области. Но перед установкой нужно наборы схем из пакетов krb5-kdc-ldap и sudo-ldap перевести в формат LDIF.

zcat /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz > ~/ldap/kerberos.schema 
cp /usr/share/doc/sudo-ldap/schema.OpenLDAP ~/ldap/sudo.schema  

Далее создадим файл convert-schema-to-ldif.sh и добавим в него текст:

#!/bin/bash  
SCHEMAD=~/ldap
  
tmpd=`mktemp -d`
pushd ${tmpd} >>/dev/null  
echo '' > convert.dat
  
for schema in ${SCHEMAS} ; do
    echo include ${SCHEMAD}/${schema} >> convert.dat 
done
  
mkdir output
slaptest -f convert.dat -F ./output  
if [ $? -ne 0 ] ; then
    echo "slaptest conversion failed" 
    exit
fi  
for schema in ${SCHEMAS} ; do
    fullpath=${SCHEMAD}/${schema} 
    schema_name=`basename ${fullpath} .schema`
    schema_dir=`dirname ${fullpath}` 
    ldif_file=${schema_name}.ldif
  
    find . -name *${schema_name}.ldif -exec mv '{}' ./${ldif_file} \;
    sed -i "/dn:/ c dn: cn=${schema_name},cn=schema,cn=config" ${ldif_file} 
    sed -i "/cn:/ c cn: ${schema_name}" ${ldif_file}
    sed -i '/structuralObjectClass/ d' ${ldif_file} 
    sed -i '/entryUUID/ d' ${ldif_file}
    sed -i '/creatorsName/ d' ${ldif_file} 
    sed -i '/createTimestamp/ d' ${ldif_file}
    sed -i '/entryCSN/ d' ${ldif_file} 
    sed -i '/modifiersName/ d' ${ldif_file}
    sed -i '/modifyTimestamp/ d' ${ldif_file} 
    sed -i '/^ *$/d' ${ldif_file}
  
    mv ${ldif_file} ${schema_dir}
done  
popd >>/dev/null
rm -rf $tmpd

После чего сделаем его исполняемым и запустим:

chmod +x convert-schema-to-ldif.sh 
SCHEMAS='kerberos.schema sudo.schema' convert-schema-to-ldif.sh
config file testing succeeded  

На выходе должны получить два набора схем данных в формате LDIF:

ls ~/ldap | egrep '(kerberos.ldif|sudo.ldif)' 
kerberos.ldif
sudo.ldif  

Переместим  их в каталог к остальным наборам схем и поправим права доступа:

sudo  mv ~/ldap/{kerberos.ldif,sudo.ldif} /etc/ldap/schema 
sudo  chown root:root /etc/ldap/schema/{kerberos.ldif,sudo.ldif}
sudo  chmod 0644 /etc/ldap/schema/{kerberos.ldif,sudo.ldif}

Создадим LDIF-файл include-schemas.ldif с необходимыми нам наборами схем данных. Внимание! Порядок их следования в файле важен! Атрибуты наборов схем иерархически связаны и требуют их объявления с соблюдением иерархии. В include-schemas.ldif добавим текст:

include: file:///etc/ldap/schema/core.ldif 
include: file:///etc/ldap/schema/cosine.ldif
include: file:///etc/ldap/schema/inetorgperson.ldif 
include: file:///etc/ldap/schema/collective.ldif
include: file:///etc/ldap/schema/corba.ldif 
include: file:///etc/ldap/schema/duaconf.ldif
include: file:///etc/ldap/schema/openldap.ldif 
include: file:///etc/ldap/schema/dyngroup.ldif
include: file:///etc/ldap/schema/java.ldif 
include: file:///etc/ldap/schema/misc.ldif
include: file:///etc/ldap/schema/nis.ldif 
include: file:///etc/ldap/schema/ppolicy.ldif
include: file:///etc/ldap/schema/kerberos.ldif 
include: file:///etc/ldap/schema/sudo.ldif  

В конце файла мы указываем получившиеся в результате конвертации наборы схем kerberos.ldif и sudo.ldif.

sudo ldapadd -QY EXTERNAL -H ldapi:/// -f include-schemas.ldif 
adding new entry "cn=core,cn=schema,cn=config"
adding new entry "cn=cosine,cn=schema,cn=config" 
adding new entry "cn=inetorgperson,cn=schema,cn=config"
adding new entry "cn=collective,cn=schema,cn=config" 
adding new entry "cn=corba,cn=schema,cn=config"
adding new entry "cn=duaconf,cn=schema,cn=config" 
adding new entry "cn=openldap,cn=schema,cn=config"
adding new entry "cn=dyngroup,cn=schema,cn=config" 
adding new entry "cn=java,cn=schema,cn=config"
adding new entry "cn=misc,cn=schema,cn=config" 
adding new entry "cn=nis,cn=schema,cn=config"
adding new entry "cn=ppolicy,cn=schema,cn=config" 
adding new entry "cn=kerberos,cn=schema,cn=config"
adding new entry "cn=sudo,cn=schema,cn=config"  

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

slappasswd -h '{SSHA}' 
New password:
Re-enter new password: 
{SSHA}gP24e9Cs4FFw5yHw7PcohG1ekQGtFBD  

Создаем конфигурационный LDIF-файл init-db.ldif для базы данных добавляем в него текст olcRootPW:

dn: olcDatabase=mdb,cn=config 
objectClass: olcMdbConfig
olcDatabase: mdb 
olcSuffix: dc=da-test,dc=ru
olcDbDirectory: /var/lib/ldap 
olcDbMaxsize: 1073741824
olcRootDN: cn=admin,dc=da-test,dc=ru 
olcRootPW: {SSHA}gP24e9Cs4FFw5yHw7PcohG1ekQGtFBD
olcAccess: {0}to * 
  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
  by * break 
olcAccess: {1}to attrs=userPassword
  by self write 
  by anonymous auth
olcAccess: {2}to * 
  by self read
  
dn: olcDatabase=monitor,cn=config
objectClass: olcDatabaseConfig 
olcDatabase: monitor  

В качестве параметра olcRootPW подставьте ранее скопированный хэш пароля с префиксом {SSHA}.

Механизм mdb требует указания максимального размера базы данных (olcDbMaxsize). Он задается в байтах и должен быть больше её ожидаемого размера, даже с учётом прироста. В файловой системе должно быть достаточно свободного места для размещения базы данных такого размера.

Для пользователя, указанного в атрибуте olcRootDN, задавать правило в ACL не нужно, он обладает полным доступом к данным в базе.

Доступ ко всей базе данных:

- продолжить анализ ACL, если нет совпадений с субъектами доступа, указанными с помощью директивы by.

- разрешить доступ для смены пароля самим пользователем.

Доступ к остальной базе данных:

С помощью механизма monitor включаем мониторинг базы данных (добавляем базу данных monitor).

Далее для нашей базы данных необходимо создать каталог и задать ему права доступа:

sudo  mkdir /var/lib/ldap 
sudo  chown openldap:openldap /var/lib/ldap
sudo  chmod 0700 /var/lib/ldap  

Теперь загружаем конфигурацию базы данных:

sudo  ldapadd -QY EXTERNAL -H ldapi:/// -f init-db.ldif  
adding new entry "olcDatabase=mdb,cn=config"
adding new entry "olcDatabase=monitor,cn=config"  

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

sudo  ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'cn=config' dn olcAccess  
dn: cn=config
  
dn: cn=module{0},cn=config
  
dn: cn=module{1},cn=config
  
dn: cn=schema,cn=config
  
dn: cn={0}core,cn=schema,cn=config
  
dn: cn={1}cosine,cn=schema,cn=config
  
dn: cn={2}inetorgperson,cn=schema,cn=config
  
dn: cn={3}collective,cn=schema,cn=config
  
dn: cn={4}corba,cn=schema,cn=config
  
dn: cn={5}duaconf,cn=schema,cn=config
  
dn: cn={6}openldap,cn=schema,cn=config
  
dn: cn={7}dyngroup,cn=schema,cn=config
  
dn: cn={8}java,cn=schema,cn=config
  
dn: cn={9}misc,cn=schema,cn=config
  
dn: cn={10}nis,cn=schema,cn=config
  
dn: cn={11}kerberos,cn=schema,cn=config
  
dn: cn={12}sudo,cn=schema,cn=config
  
dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external 
 ,cn=auth manage by * break
olcAccess: {1}to dn.base="" by * read 
olcAccess: {2}to dn.base="cn=subschema" by * read
  
dn: olcDatabase={0}config,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external 
 ,cn=auth" manage
  
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external 
 ,cn=auth" manage by * break
olcAccess: {1}to attrs=userPassword,userPKCS12 by self write by anonymous auth 
olcAccess: {2}to attrs=shadowLastChange by self write
olcAccess: {3}to dn.subtree="cn=kerberos,ou=services,dc=pacman,dc=loc" by dn.e 
 xact="cn=krbadmin,ou=users,dc=pacman,dc=loc" manage
olcAccess: {4}to * by dn.base="cn=nssproxy,ou=users,dc=pacman,dc=loc" read by 
 self read
  
dn: olcDatabase={2}monitor,cn=config

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

sudo ldapwhoami -WD cn=admin,dc=da-test,dc=ru 
Enter LDAP Password:
dn:cn=admin,dc=da-test,dc=ru  

Отредактируем файл /etc/ldap/ldap.conf. Это нужно только для того, чтобы использовать короткие имена и не печатать fqdn полностью

BASE  dc=da-test,dc=ru 
URI  ldap://da1.da-test.ru
# TLS_CACERT /etc/ssl/certs/rootca.crt 
# TLS_REQCERT demand
TIMELIMIT 15 
TIMEOUT  20  

Основные настройки выполнены. Теперь осталось добавить службу каталогов в автозапуск:

sudo systemctl enable slapd  

5. Инициализация пользователей и групп

nano init-units.ldif  

И добавим в него текст:

dn: dc=da-test,dc=ru 
dc: example
objectClass: top 
objectClass: domain
  
dn: ou=users,dc=da-test,dc=ru
ou: Users 
objectClass: top
objectClass: organizationalUnit 
description: Пользователи организации
  
dn: ou=groups,dc=da-test,dc=ru
ou: Groups 
objectClass: top
objectClass: organizationalUnit 
description: Группы организации  

Теперь применим конфигурацию для службы каталогов:

sudo  ldapmodify -a -xZZWD cn=admin,dc=da-test,dc=ru -f 4-users+groups.ldif 
Enter LDAP Password:
adding new entry "dc=da-test,dc=ru" 
adding new entry "ou=users,dc=da-test,dc=ru"
adding new entry "ou=groups,dc=da-test,dc=ru"  

Убедимся, что организационные единицы были созданы

ldapsearch -xZZLLLWD cn=admin,dc=da-test,dc=ru 
Enter LDAP Password:
dn: dc=da-test,dc=ru 
dc: example
objectClass: top 
objectClass: domain
  
dn: ou=users,dc=da-test,dc=ru
ou: Users 
objectClass: top
objectClass: organizationalUnit 
description: Пользователи организации
  
dn: ou=groups,dc=da-test,dc=ru
ou: Groups 
objectClass: top
objectClass: organizationalUnit 
description: Группы организации  

Когда основные единицы созданы, добавим еще несколько групп:

- nssproxy - группа, которая будет использоваться для опроса сервера вместо анонимного запроса;

Для добавления этих групп создадим новый LDIF-файл с именем init-groups.ldif и содержимым:

dn: cn=sysadmin,ou=groups,dc=da-test,dc=ru 
cn: sysadmin
objectClass: top 
objectClass: posixGroup
gidNumber: 1100 
description: Системные администраторы
  
dn: cn=nssproxy,ou=groups,dc=da-test,dc=ru
cn: nssproxy 
objectClass: top
objectClass: posixGroup 
gidNumber: 801
description: Служебная группа опроса сервера  
dn: cn=test.group,ou=groups,dc=da-test,dc=ru
cn: tester 
objectClass: top
objectClass: posixGroup 
gidNumber: 1101
description: Группа для тестирования  

Затем применяем LDIF в корневой каталог:

sudo ldapmodify -a -xZZWD cn=admin,dc=da-test,dc=ru -f init-groups.ldif 
Enter LDAP Password:
adding new entry "cn=sysadmin,ou=groups,dc=da-test,dc=ru" 
adding new entry "cn=nssproxy,ou=groups,dc=da-test,dc=ru"
adding new entry "cn=testing,ou=groups,dc=da-test,dc=ru"  

После создания групп, как правило, нужно создать пользователей для них:

- user1 - основной пользователь, под которым мы будем работать;

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

Создаем еще один конфигурационный файл с именем init-users.ldif, в которои мы опишем новых пользователей 

dn: cn=user1,ou=users,dc=da-test,dc=ru 
uid: user1
gecos: User #1 
objectClass: top
objectClass: account 
objectClass: posixAccount
objectClass: shadowAccount 
userPassword: {SSHA}EdXkkdLF2JaWE4TkgDxmHwgXjqRHC1Dw
shadowLastChange: 15140 
shadowMin: 0
shadowMax: 99999 
shadowWarning: 7
loginShell: /bin/bash 
uidNumber: 1100
gidNumber: 1100 
homeDirectory: /home/user1
  
dn: cn=nssproxy,ou=users,dc=da-test,dc=ru
uid: nssproxy 
gecos: Network Service Switch Proxy User
objectClass: top 
objectClass: account
objectClass: posixAccount 
objectClass: shadowAccount
userPassword: {SSHA}EdXkkdLF2JaWE4TkgDxmHwgXjqRHC1Dw 
shadowLastChange: 15140
shadowMin: 0 
shadowMax: 99999
shadowWarning: 7 
loginShell: /bin/false
uidNumber: 801 
gidNumber: 801
homeDirectory: /home/nssproxy  
dn: cn=tester,ou=users,dc=da-test,dc=ru
uid: tester 
gecos: Tester
objectClass: top 
objectClass: account
objectClass: posixAccount 
objectClass: shadowAccount
userPassword: {SSHA}EdXkkdLF2JaWE4TkgDxmHwgXjqRHC1Dw 
shadowLastChange: 15140
shadowMin: 0 
shadowMax: 99999
shadowWarning: 7 
loginShell: /bin/bash
uidNumber: 1101 
gidNumber: 1101
homeDirectory: /home/tester

Обратите внимание, что пользователи связаны с группами с помощью атрибута gidNumber

sudo ldapmodify -a -xZZWD cn=admin,dc=da-test,dc=ru -f init-users.ldif 
Enter LDAP Password:
adding new entry "cn=user1,ou=users,dc=da-test,dc=ru" 
adding new entry "cn=nssproxy,ou=users,dc=da-test,dc=ru"
adding new entry "cn=tester,ou=users,dc=da-test,dc=ru"  

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

sudo ldappasswd -xZZWD cn=admin,dc=da-test,dc=ru -S cn=user1,ou=users,dc=da-test,dc=ru 
New password:
Re-enter new password: 
Enter LDAP Password:
  
sudo ldappasswd -xZZWD cn=admin,dc=da-test,dc=ru -S cn=nssproxy,ou=users,dc=da-test,dc=ru
New password: 
Re-enter new password:
Enter LDAP Password:  
sudo ldappasswd -xZZWD cn=admin,dc=da-test,dc=ru -S cn=tester,ou=users,dc=da-test,dc=ru
New password: 
Re-enter new password:
Enter LDAP Password:

Если теперь посмотреть журнал /var/log/slapd.log, то можно увидеть строки, говорящие об изменении записи:

...
slapd[5319]: conn=1022 op=1 PASSMOD id="cn=nssproxy,ou=users,dc=da-test,dc=ru" new 
slapd[5319]: conn=1022 op=1 RESULT oid= err=0 text=
...   

Для того, чтобы пользователь nssproxy имел доступ к информации каталога, необходимо поправить ACL базы данных с пользователями и группами.

Создадим конфигурационный файл init-nssproxy.ldif и добавим следующий текст:

dn: olcDatabase={1}mdb,cn=config 
changetype: modify
replace: olcAccess 
olcAccess: {0}to *
  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage 
  by * break
- 
add: olcAccess
olcAccess: {1}to attrs=userPassword 
  by self write
  by anonymous auth 
-
add: olcAccess 
olcAccess: {2}to *
  by self read 
  by dn.base="cn=nssproxy,ou=users,dc=da-test,dc=ru" read  

После чего сохраним файл и загрузим LDIF-файл с изменениями:

sudo ldapmodify -xZZWD cn=admin,dc=da-test,dc=ru -f init-nssproxy.ldif 
Enter LDAP Password:
modifying entry "olcDatabase={1}mdb,cn=config"  

Теперь нужно проверить, можно ли просматривать информацию в каталоге от имени nssproxy. Для этого выполним запрос с использованием его учётных данных. Результатом запроса должно быть всё DIT (Directory Information Tree).

ldapsearch -xZZLLLWD cn=nssproxy,ou=users,dc=da-test,dc=ru "(objectClass=*)" 
Enter LDAP Password:
dn: dc=da-test,dc=ru 
...  

Не забудьте проверить, что другие учётные записи пользователей не имеют доступа к DIT:

ldapsearch -xZZLLLWD cn=pablo,ou=users,dc=da-test,dc=ru "(objectClass=*)" 
Enter LDAP Password:
No such object (32)  

6. Настройка защищенного соединения (TLS)

С помощью OpenSSL в этом разделе будет создан импровизированный удостоверяющий центр и с последующей настройкой TLS.

Для начала создадим централизованную инфраструктуру открытых ключей (PKI). Для этого сгенерируем пару закрытый ключ/корневой сертификат УЦ. Сертификат УЦ также будет подписан этим же закрытым ключом (т. е. станет самоподписанным).

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

Первым делом создадим директорию для УЦ (CA) и следом установим безопасные права доступа. Затем зададим значение umask таким, чтобы вновь создаваемые файлы имели права доступа чтения и записи только для создавшего их пользователя:

sudo mkdir /root/CA 
sudo chmod u=rwx,g=,o= /root/CA
sudo cd /root/CA 
sudo umask 066  

В конфигурационном файле /etc/ssl/openssl.cnf в секции [ CA_default ] поменяем значение директивы dir = ./demoCA на dir = ./. В этом же разделе директивой default_days задаётся срок действия выпускаемых сертификатов. Можете поменять её значение по своему усмотрению.

Файлы index.txt и serial будут выступать в качестве базы данных, чтобы отслеживать статус выпущенных закрытых ключей и сертификатов.

Создадим структуру каталогов и файлов для УЦ:

sudo mkdir certs crl newcerts private 
sudo chmod 700 private
sudo touch index.txt 
sudo echo 1000 > serial  

Сгенерируем закрытый ключ УЦ с длиной 4096 бит. Он должен храниться особенно бережно. Поэтому защитим его при помощи шифра AES. Вам будет предложено ввести пароль для доступа к новому закрытому ключу. Скопируйте его и сохраните в надежном месте. Без этого пароля выпустить новые сертификаты не получится.

sudo openssl genrsa -aes256 -out private/rootca.key 4096  

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

sudo chmod 400 private/rootca.key 

Откроем конфигурационный файл OpenSSL (openssl.cnf) и найдем секции [ usr_cert ] и [ v3_ca ]. Убедитесь, что в них присутствуют следующие директивы:

[ usr_cert ] 
# Эти расширения будут добавлены при подписывании запроса УЦ.
basicConstraints=CA:FALSE 
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
nsComment = "OpenSSL Generated Certificate" 
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer  
[ v3_ca ]
# Расширения для типового УЦ 
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer 
basicConstraints = CA:true
keyUsage = cRLSign, keyCertSign  

Теперь мы можем выпустить корневой сертификат УЦ, подписав его закрытым ключом rootca.key. Так как это сертификат УЦ, используем расширение v3_ca:

[ usr_cert ] 
# Эти расширения будут добавлены при подписывании запроса УЦ.
basicConstraints=CA:FALSE 
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
nsComment = "OpenSSL Generated Certificate" 
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer  
[ v3_ca ]
# Расширения для типового УЦ 
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer 
basicConstraints = CA:true
keyUsage = cRLSign, keyCertSign  

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

C  - Country Name (страна) - RU 
ST - State or Province Name (штат или провинция) - Moscow
L  - Locality Name (город) - Moscow 
O  - Organization Name (наименование организации) - MyCompany
OU - Organizational Unit Name (наименование подразделения) - IT 
CN - Common Name (имя субъекта или FQDN сервера) - ca-server
  
emailAddress - Email Address (адрес электронной почты) - admin@da-test.ru

Чтобы посмотреть содержимое сертификата выполните следующую команду:

sudo openssl x509 -in certs/rootca.crt -noout -text  

УЦ готов к выпуску сертификата для сервера службы каталогов.

Создадим закрытый ключ для сервера службы каталогов в директории /root/CA:

sudo openssl genrsa -out private/da1.da-test.ru.key 4096 
sudo chmod 400 private/da1.da-test.ru.key  

Сгенерируем запрос на подпись сертификата. Наименование организации (MyCompany) должно совпадать с наименованием в корневом сертификате УЦ. В качестве Common Name укажем FQDN сервера службы каталогов:

sudo openssl req -sha256 -new -key private/da1.da-test.ru.key -out certs/da1.da-test.ru.csr -subj /C=RU/ST=Moscow/L=Moscow/O=MyCompany/OU=IT/CN=da1.da-test.ru/emailAddress=admin@da-test.ru  

Следующим шагом должно быть платное подписание запроса CSR существующим доверенным УЦ (например, Verisign). Но не обязательно использовать платные сервисы УЦ, если у вас нет  корпоративного CA, или это просто тестовая конфигурация. В тестовых целях мы можем подписать запрос с помощью собственного УЦ:

sudo openssl ca -extensions usr_cert -notext -md sha256 -keyfile private/rootca.key -cert certs/rootca.crt -in certs/da1.da-test.ru.csr -out certs/da1.da-test.ru.crt 
sudo chmod 444 certs/da1.da-test.ru.crt  

Далее создадим директорию для ключевой информации сервера и поместим туда получившиеся файлы:

sudo mkdir /etc/ldap/ssl 
sudo chown openldap:openldap /etc/ldap/ssl
sudo chmod 0500 /etc/ldap/ssl 
sudo cp certs/da1.da-test.ru.crt private/da1.da-test.ru.key /etc/ldap/ssl  

После установим права доступа для ключевой информации:

sudo chown openldap:openldap /etc/ldap/ssl/{da1.da-test.ru.crt,da1.da-test.ru.key} 
sudo chmod 0400 /etc/ldap/ssl/{da1.da-test.ru.crt,da1.da-test.ru.key}  

И в конце поместим корневой сертификат в каталог с сертификатами операционной системы и зададим для него права доступа:

sudo cp certs/rootca.crt /etc/ssl/certs/ 
sudo chmod 0644 /etc/ssl/certs/rootca.crt  

Запрос CSR больше не требуется. Вы можете удалить его на свое усмотрение:

sudo rm -rf certs/da1.da-test.ru.csr  

Каталог /root/CA теперь выполняет роль удостоверяющего центра. Аналогичным образом его можно создать на другой машине, тогда нужно будет копировать секретные ключи и подписанные сертификаты по сети с помощью scp или через съёмный носитель. Хорошей практикой считается хранение этой директории на отдельном носителе и монтировать его только для выпуска новых сертификатов. Сам носитель можно хранить в защищенном месте, например, в сейфе. Процесс создания новых пар ключ-сертификат в будущем будет состоять из трёх этапов:

- подписание сертификата с помощью закрытого ключа УЦ (rootca.key);

Осталось только настроить OpenLDAP на работу с TLS. Для этого вернёмся во временный каталог:

cd ~/ldap  

И создадим конфигурационный файл init-tls-config.ldif для внесения в каталог конфигурации TLS и добавим в него:

dn: cn=config 
add: olcTLSVerifyClient
olcTLSVerifyClient: never 
-
add: olcTLSCertificateFile 
olcTLSCertificateFile: /etc/ldap/ssl/da1.da-test.ru.crt
- 
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/da1.da-test.ru.key 
-
add: olcTLSCACertificateFile 
olcTLSCACertificateFile: /etc/ssl/certs/rootca.crt  

Этими настройками мы указываем службе slapd, где лежит сертификат и ключ, где лежит корневой сертификат УЦ. С помощью olcTLSVerifyClient: never указываем, что от клиентов требовать наличие сертификата не нужно.

sudo ldapmodify -QY EXTERNAL -H ldapi:/// -f init-tls-config.ldif 
modifying entry "cn=config"  

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

sudo ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls 
olcTLSCertificateFile: /etc/ldap/ssl/da1.da-test.ru.crt
olcTLSCertificateKeyFile: /etc/ldap/ssl/da1.da-test.ru.key 
olcTLSCACertificateFile: /etc/ssl/certs/rootca.crt
olcTLSVerifyClient: never  

Вновь отредактируем конфигурационный файл /etc/ldap/ldap.conf и включим поддержку TLS:

BASE            dc=example,dc=com 
URI             ldap://da1.da-test.ru
TLS_CACERT      /etc/ssl/certs/rootca.crt 
TLS_REQCERT     demand
TIMELIMIT       15 
TIMEOUT         20  

Обычно для конфигурации cn=config перезагрузка службы не требуется, но, чтобы созданная ключевая информация была применена, придётся это сделать:

sudo systemctl restart slapd  

Осталось проверить соединение с сервером с использованием TLS (модификатор -ZZ). Для этого выполним запрос с использованием DN администратора:

sudo ldapsearch -xZZLLLWD cn=admin,dc=da-test,dc=ru -b cn=config -s base 
Enter LDAP Password:
dn: cn=config 
objectClass: olcGlobal
cn: config 
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid 
olcTLSCACertificateFile: /etc/ssl/certs/rootca.crt
olcTLSCertificateFile: /etc/ldap/ssl/da1.da-test.ru.crt 
olcTLSCertificateKeyFile: /etc/ldap/ssl/da1.da-test.ru.key
olcTLSVerifyClient: never  

Обратите внимание, что в запросе ldapsearch нам не пришлось указывать имя хоста (-H ldap://da1.da-test.ru).  Всё потому что оно указано в файле /etc/ldap/ldap.conf. Что касается TLS, то во время инициирования соединения клиент (на данном этапе клиентский запрос выполняет сам сервер) получает от сервера его подписанный сертификат (da1.da-test.ru.crt). Клиент может ничего не знать о сервере, но у него есть сертификат CA (rootca.crt), с помощью которого и проверяется сервер.

7. Настройка подключения клиентов к OpenLDAP

Для начала установим необходимые пакеты:

sudo apt-get install ldap-utils libnss-ldapd libpam-ldapd  

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

URI сервера LDAP: ldap://da1.da-test.ru; 
База поиска сервера LDAP: dc=da-test,dc=ru;
Имена настраиваемых служб: group,netgroup,passwd,shadow.

Прежде чем делать запросы к LDAP-серверу, проверим параметры клиента в /etc/ldap/ldap.conf:

BASE  dc=da-test,dc=ru 
URI  ldap://da1.da-test.ru
TLS_CACERT /etc/ssl/certs/rootca.crt 
TLS_REQCERT demand
TLS_CRLFILE /etc/ssl/rootca.crl 
TIMELIMIT 15
TIMEOUT  20  

Конечно, для того, чтобы всё заработало, сертификат нашего Certificate Authority (rootca.crt) и CRL-файл (rootca.crl) должны быть на месте (нужно их будет скопировать с сервера УЦ, если вы еще этого не сделали).

$  ldapsearch -xZZLLLWD cn=nssproxy,ou=users,dc=da-test,dc=ru 
Enter LDAP Password:
dn: dc=da-test,dc=ru 
...  

Изменим конфигурацию локальной службы имён LDAP в файле /etc/nslcd.conf. Для начала измените значение директивы bindpw на пароль записи cn=nssproxy,ou=users,dc=da-test,dc=ru, который мы задавали ранее:

uid nslcd 
gid nslcd
uri ldap://da1.da-test.ru 
base dc=da-test,dc=ru
binddn cn=nssproxy,ou=users,dc=da-test,dc=ru 
bindpw <Пароль пользователя nssproxy>
rootpwmoddn cn=admin,dc=da-test,dc=ru 
base group ou=groups,dc=da-test,dc=ru
base passwd ou=users,dc=da-test,dc=ru 
base shadow ou=users,dc=da-test,dc=ru
bind_timelimit 5 
timelimit 10
idle_timelimit 60 
ssl start_tls
tls_reqcert allow 
tls_cacertfile /etc/ssl/certs/rootca.crt
nss_initgroups_ignoreusers bin,daemon,games,lp,mail,nobody,nslcd,root,sshd,sync,uucp 
nss_initgroups_ignoreusers sys,man,news,proxy,www-data,backup,list,irc,gnats,landscape  

Описание использованных директив:

• base - с помощью этой директивы сообщаем службе nslcd, где в DIT искать ту или иную информацию;
• bind_timelimit - параметр ограничивает время на установление соединения с сервером пятью секундами;
• timelimit - устанавливает максимальное время ожидания ответа от сервера в 10 секунд;
• idle_timelimit - принудительно заставит nslcd разорвать соединение с сервером, если в течении минуты в соединении не было никакой активности;
• ssl - принуждает клиента использовать TLS при подключении к серверу;
• tls_reqcert и tls_cacertfile - эти директивы подобны TLS_REQCERT и TLS_CACERT в конфигурации /etc/ldap/ldap.conf. Нужны для проверки сертификата сервера и путь к корневому сертификату для выполнения проверки;
• nss_initgroups_ignoreusers - директива описывает пользователей системы, поиск которых не нужно производить в DIT. Это позволит работать с компьютером при проблемах с доступом к серверу каталогов. В значение этой директивы следует внести имена всех общесистемных пользователей. 

Теперь поменяем права доступа к nslcd.conf, потому что теперь в нём хранится информация для аутентификации:

sudo chmod 600 /etc/nslcd.conf 
sudo chown nslcd:nslcd /etc/nslcd.conf

Проверим содержимое /etc/nsswitch.conf:

passwd:         compat ldap 
group:          compat ldap
shadow:         compat ldap  
hosts:          files dns
networks:       files  
protocols:      db files
services:       db files 
ethers:         db files
rpc:            db files  
netgroup:       nis ldap  

Убедимся в том, что служба nslcd запускается при старте системы и перезапустим ее:

sudo systemctl enable nslcd 
sudo systemctl restart nslcd

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

grep nssproxy /etc/passwd  

И убедимся, что кэширующий служба службы имён загружается при старте системы и перезапустим ее:

sudo systemctl enable nscd 
sudo systemctl restart service nscd
  
Теперь сделаем запросы к LDAP-серверу, используя настроенную систему:
  
getent passwd tester
tester:x:1101:1101:Tester Tester:/home/tester:/bin/bash  
getent group tester
tester:*:1101:  

Для того, чтобы проверить доступность информации о пароле потребуется выполнить getent от имени пользователя root:

getent shadow tester 
tester:*:15140:0:99999:7:::0

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

sudo nano /etc/pam.d/common-session  

Добавим в него текст:

session required      pam_mkhomedir.so   skel=/etc/skel umask=0002  

Далее выполним команду:

su - tester  

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

Служба ssh по умолчанию должна работать с поддержкой PAM (и, соответственно, поддерживать аутентификацию через LDAP). Но на всякий случай приведём добавим текст в /etc/ssh/sshd_config:

AddressFamily inet 
AllowGroups sysadmin tester
SyslogFacility AUTHPRIV 
PasswordAuthentication yes
AllowTcpForwarding no 
ClientAliveInterval 120
ClientAliveCountMax 2  

Обратите внимание на строку с директивой AllowGroups. С помощью неё мы ограничиваем список групп пользователей, которые могут быть аутентифицированы через ssh..

ssh tester@da-test.ru 
Password:
tester@da-test.ru:~$

Если появляется приглашение командной строки, значит всё в порядке!

da1 slapd[2109]: <= mdb_equality_candidates: (objectClass) not indexed 
da1 slapd[2109]: <= mdb_equality_candidates: (uid) not indexed  

С помощью следующей команды мы можем убедиться, что в каталоге пока нет никаких индексов:

sudo ldapsearch -xZZLLLWD cn=admin,dc=da-test,dc=ru -b olcDatabase={1}mdb,cn=config olcDbIndex 
Enter LDAP Password:
dn: olcDatabase={1}mdb,cn=config  

Для решения проблемы, надо создать индексы для атрибутов из журнала  /var/log/slapd.log. 

dn: olcDatabase={1}mdb,cn=config 
changetype: modify
add: olcDbIndex 
olcDbIndex: default pres,eq
- 
add: olcDbIndex
olcDbIndex: uid 
-
add: olcDbIndex 
olcDbIndex: cn,sn pres,eq,sub
- 
add: olcDbIndex
olcDbIndex: objectClass eq 
-
add: olcDbIndex 
olcDbIndex: memberUid eq
- 
add: olcDbIndex
olcDbIndex: uniqueMember eq 
-
add: olcDbIndex 
olcDbIndex: uidNumber
- 
add: olcDbIndex
olcDbIndex: gidNumber eq  

Далее загрузим конфигурацию в каталог:

sudo ldapadd -xZZWD cn=admin,dc=da-test,dc=ru -f init-account-indexes.ldif 
Enter LDAP Password:
modifying entry "olcDatabase={1}mdb,cn=config"  

Проверим результат изменений:

sudo ldapsearch -xZZLLLWD cn=admin,dc=da-test,dc=ru -b olcDatabase={1}mdb,cn=config olcDbIndex 
Enter LDAP Password:
dn: olcDatabase={1}mdb,cn=config 
olcDbIndex: default pres,eq
olcDbIndex: uid 
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: objectClass eq 
olcDbIndex: memberUid eq
olcDbIndex: uniqueMember eq 
olcDbIndex: uidNumber
olcDbIndex: gidNumber eq  

После этих изменений в журнале /var/log/slapd.log не должно быть ошибок.

8. Настройка Kerberos

sudo  apt-get install krb5-kdc krb5-pkinit krb5-admin-server wamerican libsasl2-modules-gssapi-mit  

В разделе "4. Настройка OpenLDAP" была установилена схема Kerberos для OpenLDAP сервера. Чтобы проверить, что схема установлена, выполните:

sudo ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn | grep -i kerberos 
dn: cn={11}kerberos,cn=schema,cn=config  

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

sudo ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b cn={11}kerberos,cn=schema,cn=config | grep NAME | cut -d' ' -f5 | sort  

Она должна вернуть список объектов. Если новых атрибутов Kerberos LDAP нет, то kdb5_ldap_util(8) выдаст следующую ошибку:

kdb5_ldap_util: Kerberos Container create FAILED: No such object while creating realm 'DA-TEST.RU'

Итак, у нас есть набор схемы данных и объекты, в котором отсутствует контейнер для принципалов Kerberos:

# Создание контейнера для Kerberos 
dn: cn=kerberos,ou=services,dc=da-test,dc=ru
cn: kerberos 
objectClass: top
objectClass: krbContainer  
# Создание группы krbadmin
dn: cn=krbadmin,ou=groups,dc=da-test,dc=ru 
objectClass: top
objectClass: posixGroup 
cn: krbadmin
gidNumber: 800 
description: Kerberos administrator's group.
  
# Создание пользователя krbadmin
dn: cn=krbadmin,ou=users,dc=da-test,dc=ru 
objectClass: inetOrgPerson
objectClass: organizationalPerson 
objectClass: person
objectClass: posixAccount 
objectClass: top
cn: krbadmin 
givenName: Kerberos Administrator
mail: kerberos.admin@da-test.ru 
sn: krbadmin
uid: krbadmin 
uidNumber: 800
gidNumber: 800 
homeDirectory: /home/krbadmin
loginShell: /bin/false 
displayname: Kerberos Administrator

Далее загружаем конфигурационный файл в сервер каталогов:

sudo ldapadd -xZZWD cn=admin,dc=da-test,dc=ru -f ~/ldap/9.1-kerberos.ldif 
Enter LDAP Password:
adding new entry "cn=kerberos,ou=services,dc=da-test,dc=ru" 
adding new entry "cn=krbadmin,ou=groups,dc=da-test,dc=ru"
adding new entry "cn=krbadmin,ou=users,dc=da-test,dc=ru"  

Теперь зададим пароль для пользователя krbadmin. Рекомендуетя сохранить пароль в надежном месте.

sudo ldappasswd -xZZWSD "cn=admin,dc=da-test,dc=ru" "cn=krbadmin,ou=users,dc=da-test,dc=ru"

Когда пароль будет установлен, создадим конфигурационный файл Kerberos /etc/krb5.conf и добавим в него текст:

[logging] 
 default = SYSLOG:INFO:LOCAL1
 kdc = SYSLOG:NOTICE:LOCAL1 
 admin_server = SYSLOG:WARNING:LOCAL1
  
[libdefaults]
 default_realm = DA-TEST.RU 
 dns_lookup_realm = false
 dns_lookup_kdc = false 
 ticket_lifetime = 24h
 renew_lifetime = 7d 
 forwardable = true
  
[realms]
 DA-TEST.RU = { 
  kdc = da1.da-test.ru
  admin_server = da1.da-test.ru 
  default_domain = da-test.ru
  database_module = openldap_ldapconf 
 }
  
[domain_realm]
 .da-test.ru = DA-TEST.RU 
 da-test.ru = DA-TEST.RU
  
[appdefaults]
 pam = { 
  debug = false
  ticket_lifetime = 36000 
  renew_lifetime = 36000
  forwardable = true 
  krb4_convert = false
 }  
[dbmodules]
 openldap_ldapconf = { 
  db_library = kldap
  ldap_kerberos_container_dn = cn=kerberos,ou=services,dc=da-test,dc=ru 
  ldap_kdc_dn = cn=krbadmin,ou=users,dc=da-test,dc=ru
  ldap_kadmind_dn = cn=krbadmin,ou=users,dc=da-test,dc=ru 
  ldap_service_password_file = /etc/krb5.d/stash.keyfile
  ldap_servers = ldapi:/// 
  ldap_conns_per_server = 5
 }

Теперь создадим список контроля доступа (ACL) администратора Kerberos. ACL и ACL OpenLDAP - это не одно и то же. Создадим файл /etc/krb5kdc/kadm5.acl и добавим в него содержимым:

*/admin@DA-TEST.RU *

Далее изменим файл /etc/krb5kdc/kdc.conf:

[kdcdefaults] 
 kdc_ports = 88
 kdc_tcp_ports = 88  
[realms]
 DA-TEST.RU = { 
  #master_key_type = aes256-cts
  acl_file = /etc/krb5kdc/kadm5.acl 
  dict_file = /usr/share/dict/words
  admin_keytab = /etc/krb5kdc/kadm5.keytab 
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }  

Создаем скрытую директорию для пароля. В файле /etc/krb5.conf она указана в переменной ldap_service_password_file:

sudo mkdir /etc/krb5.d 
sudo chmod u=rwx,g=,o= /etc/krb5.d

Извлечем пароль пользователя krbadmin, c помощью kdb5_ldap_util:

sudo kdb5_ldap_util -D "cn=admin,dc=da-test,dc=ru" stashsrvpw -f /etc/krb5.d/stash.keyfile cn=krbadmin,ou=users,dc=da-test,dc=ru  

Вам будет предложено ввести мастер-пароль базы данных. Внимание! Вам нужно обязательно сохранить этот пароль!

Далее в терминале выполните следующую команду для добавления записей Kerberos в базу данных OpenLDAP:

sudo kdb5_ldap_util -D "cn=admin,dc=da-test,dc=ru" create -subtrees "cn=kerberos,ou=services,dc=da-test,dc=ru" -r DA-TEST.RU -s

Эта команда создаст необходимые записи в cn=kerberos,ou=services,dc=da-test,dc=ru. 

sudo ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b cn=kerberos,ou=services,dc=da-test,dc=ru dn  

Далее дадим права доступа на чтение/запись администратору Kerberos к поддереву cn=kerberos,ou=services,dc=da-test,dc=ru. Никакой другой пользователь не должен иметь доступа к этой информации, кроме администратора каталога.

dn: olcDatabase={1}mdb,cn=config 
changetype: modify
replace: olcAccess 
olcAccess: {0}to *
  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage 
  by * break
olcAccess: {1}to attrs=userPassword,userPKCS12 
  by self write
  by anonymous auth 
olcAccess: {2}to attrs=shadowLastChange
  by self write 
olcAccess: {3}to dn.subtree="cn=kerberos,ou=services,dc=da-test,dc=ru"
  by dn.exact="cn=krbadmin,ou=users,dc=da-test,dc=ru" manage 
olcAccess: {4}to *
  by dn.base="cn=nssproxy,ou=users,dc=da-test,dc=ru" read 
  by self read  

И после этого загружаем конфигурационный файл в сервер каталогов:

sudo ldapmodify -QY EXTERNAL -H ldapi:/// -f init-kerberos-acl.ldif  

Проверим, что новые ACL работают. Администраторы должны иметь доступ к поддереву cn=kerberos,ou=services,dc=da-test,dc=ru. Пользователь nssproxy не должен обнаружить само существование контейнера Kerberos, а krbadmin должен не только видеть контейнер, но и иметь для него права на чтение/запись. Кроме этого, нужно убедиться, что обычные пользователи всё ещё могут использовать сервер OpenLDAP для аутентификации и что они могут менять пароли самостоятельно.

sudo ldapsearch -xZZLLLWD cn=krbadmin,ou=users,dc=da-test,dc=ru -b cn=kerberos,ou=services,dc=da-test,dc=ru dn

Следующая команда должна завершиться с ошибкой No such object (32):

sudo ldapsearch -xZZLLLWD cn=nssproxy,ou=users,dc=da-test,dc=ru -b cn=kerberos,ou=services,dc=da-test,dc=ru dn  

Теперь c любого другого хоста (например, app1.da-test.ru) убедимся, что пользователь, учётная запись которого хранится на сервере каталогов, может менять свой пароль:

su - tester 
passwd
(current) LDAP Password: 
Новый пароль :
Повторите ввод нового пароля : 
passwd: password updated successfully

Возвращаемя на хост, на котором расположена служба каталогов, и настраиваем журналирование событий с помощью правки конфигурации rsyslog (все строки добавляются в конец файлоа /etc/rsyslog.conf):

...  
# Журнал krb5-kdc в /var/log/krb5kdc.log:
if $programname == 'krb5kdc' then /var/log/krb5kdc.log 
& ~
  
# Журнал krb5-admin-server в /var/log/kadmind.log:
if $programname == 'kadmind' then /var/log/kadmind.log 
& ~  

После сразу же создаем файлы этих журналов и зададим для них права доступа:

sudo touch /var/log/{krb5kdc,kadmind}.log 
sudo chmod 0640 /var/log/{krb5kdc,kadmind}.log
sudo chown syslog:adm /var/log/{krb5kdc,kadmind}.log

И настраиваем параметры ротации этих логов. Для этого создаем два конфигурационных файла:

sudo namo /etc/logrotate.d/krb5kdc  

После чего добавляем текст:

/var/log/krb5kdc.log { 
 daily
 missingok 
 rotate 7
 compress 
 delaycompress
 notifempty 
}

И для службы krb5-admin-server:

sudo nano /etc/logrotate.d/kadmind  

В этот файл добавляем текст:

/var/log/kadmind.log { 
 daily
 missingok 
 rotate 7
 compress 
 delaycompress
 notifempty 
}  

Далее перезапускаем службу rsyslog, чтобы изменения вступили в силу. Добавим службы krb5-kdc и krb5-admin-server в автозапуск, а после запустим их:

sudo systemctl restart rsyslog   
sudo systemctl enable krb5-kdc
sudo systemctl enable krb5-admin-server  
sudo systemctl start krb5-kdc
sudo systemctl start krb5-admin-server

Проверим, что службы запустились и работают на необходимых портах (krb5kdc - 88, kadmind - 464 и 749):

ss -tan | egrep ':88|:464|:749' 
LISTEN     0      2                         *:749                      *:*
LISTEN     0      5                         *:464                      *:* 
LISTEN     0      5                         *:88                       *:*

Далее необходимо создать принципал для локального сервера. Затем принципала для пользователя tester.

sudo su - 
kadmin.local
Authenticating as principal admin/admin@DA-TEST.RU with password.

Далее создаём принципала хоста для текущего сервера:

kadmin.local:  addprinc -randkey host/da1.da-test.ru@DA-TEST.RU 
WARNING: no policy specified for host/da1.da-test.ru@DA-TEST.RU; defaulting to no policy
Principal "host/da1.da-test.ru@DA-TEST.RU" created  

После создания принципала сервера мы можем добавить его в набор ключей Kerberos (/etc/krb5.keytab):

kadmin.local:  ktadd host/da1.da-test.ru@DA-TEST.RU 
Entry for principal host/da1.da-test.ru@DA-TEST.RU with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/da1.da-test.ru@DA-TEST.RU with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab. 
Entry for principal host/da1.da-test.ru@DA-TEST.RU with kvno 2, encryption type des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/da1.da-test.ru@DA-TEST.RU with kvno 2, encryption type arcfour-hmac added to keytab FILE:/etc/krb5.keytab. 
Entry for principal host/da1.da-test.ru@DA-TEST.RU with kvno 2, encryption type des-hmac-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/da1.da-test.ru@DA-TEST.RU with kvno 2, encryption type des-cbc-md5 added to keytab FILE:/etc/krb5.keytab.

Следующим шагом создадим принципал для пользователя user1 и зададим для него пароль:

kadmin.local:  addprinc user1@DA-TEST.RU 
WARNING: no policy specified for user1@DA-TEST.RU; defaulting to no policy
Enter password for principal "user1@DA-TEST.RU":  
Re-enter password for principal "user1@DA-TEST.RU":                             
Principal "user1@DA-TEST.RU" created.  

Теперь создадим принципал пользователя с правами администратора. С помощью файла /etc/krb5kdc/kadm5.acl, пользователи с префиксом /admin имеют права администратора на доступ к области Kerberos. Это значит, что они могут создавать и удалять записи пользователей и политики доступа.

kadmin.local:  addprinc user1/admin@DA-TEST.RU 
WARNING: no policy specified for user1/admin@DA-TEST.RU; defaulting to no policy
Enter password for principal "user1/admin@DA-TEST.RU":  
Re-enter password for principal "user1/admin@DA-TEST.RU": 
Principal "user1/admin@DA-TEST.RU" created.

Проверим список текущих принципалов в области DA-TEST.RU:

kadmin.local:  get_principals 
K/M@DA-TEST.RU
krbtgt/DA-TEST.RU@DA-TEST.RU 
kadmin/admin@DA-TEST.RU
kadmin/changepw@DA-TEST.RU 
kadmin/history@DA-TEST.RU
kadmin/da1.da-test.ru@DA-TEST.RU 
host/da1.da-test.ru@DA-TEST.RU
user1@DA-TEST.RU 
user1/admin@DA-TEST.RU

С помощью команды getprinc можно посмотреть подробную информацию о принципале host/da1.da-test.ru@DA-TEST.RU:

kadmin.local:  getprinc host/da1.da-test.ru@DA-TEST.RU 
Principal: host/da1.da-test.ru@DA-TEST.RU
Expiration date: [never] 
Last password change: []
Password expiration date: [none] 
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 0 days 00:00:00 
Last modified: []
Last successful authentication: [never] 
Last failed authentication: [never]
Failed password attempts: 0 
Number of keys: 6
Key: vno 2, aes256-cts-hmac-sha1-96, no salt 
Key: vno 2, aes128-cts-hmac-sha1-96, no salt
Key: vno 2, des3-cbc-sha1, no salt 
Key: vno 2, arcfour-hmac, no salt
Key: vno 2, des-hmac-sha1, no salt 
Key: vno 2, des-cbc-md5, no salt
MKey: vno 1 
Attributes:
Policy: [none] 
kadmin.local:  exit  

Теперь проверим содержимое /etc/krb5.keytab:

sudo klist -ek /etc/krb5.keytab 
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal 
---- ---------------------------------------------------------------
   2 host/da1.da-test.ru@DA-TEST.RU (aes256-cts-hmac-sha1-96) 
   2 host/da1.da-test.ru@DA-TEST.RU (aes128-cts-hmac-sha1-96)
   2 host/da1.da-test.ru@DA-TEST.RU (des3-cbc-sha1) 
   2 host/da1.da-test.ru@DA-TEST.RU (arcfour-hmac)
   2 host/da1.da-test.ru@DA-TEST.RU (des-hmac-sha1) 
   2 host/da1.da-test.ru@DA-TEST.RU (des-cbc-md5)  

Как мы можем видеть, это список ключей шифрования, доступные для da1.da-test.ru.

mdb_equality_candidates: (krbPrincipalName) not indexe  

Для ее исправления создадим LDIF-файл init-kerberos-indexes.ldif, который внесёт поправки в индексы:

dn: olcDatabase={1}mdb,cn=config 
changetype: modify
add: olcDbIndex 
olcDbIndex: krbPrincipalName eq
- 
add: olcDbIndex
olcDbIndex: ou eq  

После этого внеснем правки в конфигурацию сервера каталогов:

sudo ldapadd -QY EXTERNAL -H ldapi:/// -f init-kerberos-indexes.ldif  

После загрузки конфигурации ошибка должна быть устранена.