Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server

в 3:46, , рубрики: kerberos, ldap, linux, системное администрирование, метки: , , , ,

Введение
Продолжение серии туториалов. Предыдущие части:
Развёртывание DNS/DDNS и DHCP сервера на ROSA Enterpise Linux Server за несколько минут
Почтовый сервер на базе ROSA Server Enterpise Linux за несколько минут
Простой домен на базе ROSA Enterprise Linux Server и Samba 3 с поддержкой перемещаемых профилей

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

Для настройки сервера аутентификации нам потребуется ROSA Enterprise Linux Server (далее RELS) и любая рабочая станция на базе Linux. В этой статье качестве рабочей станции будет использована ROSA Desktop Fresh 2012 с рабочим окружением KDE.

Немного о самом протоколе Kerberos от Википедии:

«Kerberos — сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга.»

От себя добавлю, что данный протокол является обязательным промышленным стандартом для организации аутентификации на предприятиях, и что самое главное, он необходим для создания систем использующих технологию единого входа, более известную как Single Sign-On. В настоящий момент, актуальной версией протокола является Kerberos 5. Данный протокол используется в Active Directory (начиная с Windows 2000), 389 Directory Server и многих других местах где требуется создание хоть сколько-нибудь серьёзного решения для централизованной аутентификации пользователей в сети. В том числе он используется и в ROSA Directory Server (далее RDS).

О терминологии используемой при работе с Kerberos:

Принципал — специальная уникальная сущность, которой можно выдать билет. Состоит из трёх частей: основы, экземпляра и области.
Основа — первая часть принципала Kerberos. Если это пользователь, то соответствует его имени. Если сервис — имя сервиса. Экземпляр — вторая часть, служит для уточнения первой части. Может не содержатся в имени принципала, если есть, то это его описание. В случае хоста — его fqdn. Область — идет последней частью.
Билет — данные, используемые клиентом для аутентификации на сервере, у которого клиент запрашивает службу. Подтверждают идентичность пользователя или сервиса.
KDC — центр выдачи ключей Kerberos
REALM (область) — область Kerberos. Как правило, соответствует доменному имени, написанному в верхнем регистре.

В качестве вводной — более чем достаточно. Подробности о протоколе, его реализациях можно почитать в Сети, поскольку это материал для более глубокого изучения и одной статьёй здесь уже не обойтись.

Подготовка и развёртывание

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

Как и во всех предыдущих статьях цикла, используются следующие параметры сети:

Имя домена: rosa.int
IP-адрес: 192.168.100.1

Также будем считать, что DNS, LDAP и Kerberos работают на одном и том же физическом сервере.

Прочие подробности настройки читайте в предыдущих статьях цикла.

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

Сперва нам потребуется залогиниться в ROSA Management Console по адресу hostname/mmc/ и зайти в раздел «DNS зоны». Для существующей зоны (в нашем случае rosa.int) требуется создать алиас на нужный нам хост, который будет в дальнейшем являться KDC (Key Distribution Center). Центром распространения ключей, то бишь. В данном разделе нажимаем на ссылку с FQDN-именем, либо на пиктограмму изображающую два компьютера.

Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server

Там необходимо найти запись отвечающую за named-сервер. В моём случае это ns.rosa.int. Ищем значок «Изменить», в открывшемся окне нажимаем кнопку «Добавить» и в появившемся поле для ввода текста пишем любое понравившееся нам слово в нижнем регистре, которое будем именем KDC. Например, kerberos.

Проверяем:

[rels@rosa tmp]$ ping kerberos.rosa.int
PING ns.rosa.int (192.168.100.1) 56(84) bytes of data.
64 bytes from rosa (192.168.100.1): icmp_seq=1 ttl=64 time=0.011 ms
64 bytes from rosa (192.168.100.1): icmp_seq=2 ttl=64 time=0.026 ms
64 bytes from rosa (192.168.100.1): icmp_seq=3 ttl=64 time=0.022 ms

Теперь можно идти устанавливать необходимые компоненты для будущего сервера аутентификации, для чего проследуем в ROSA Server Setup и выбираем компонент «Аутентификация Kerberos с RDS backend». Дожидаемся окончания установки всех необходимых компонентов и нажимаем «Продолжить» для первоначальной настройки. Откроется вот такая замечательная формочка:

Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server

Дам некоторые пояснения по представленному выше скриншоту:

  • Область — собственно, определяет область на которую распространяется Kerberos. В большинстве случаев, это имя используемого домена в верхнем регистре.
  • Имя узла KDC — сервер, на котором будет располагаться сервер дистрибуции ключей. В нашем случае, всё размещается на одной машине. FQDN-имя сервера должно указываться без имени домена. Т.е. вместо kerberos.rosa.int просто kerberos.
  • DNS домен — Имя домена. Собственно в нашем случае, совпадает с областью.
  • Порт KDC — порт для сервера дистрибуции ключей.
  • Порт сервера администратора — порт, по которому Kerberos связывается со своей базой данных.
  • Основной ключ базы данных KDC — пароль для базы данных Kerberos.
  • DNS-поиск для KDC — проверяет в SRV записях DNS наличие информации о сервере Kerberos.
  • DNS-поиск для области — поиск доступных серверов Kerberos информации в TXT-поле DNS.
  • Временной сдвиг — указывает допустимое время смещения часов относительно «эталонных». В качестве эталона у нас будет выступать сервер Kerberos, на котором работает сервис NTP. Время смещения указывается в секундах.
  • Типы шифрования TGS — поддерживаемые алгоритмы шифрования допустимые на сервере выдачи билетов. Как правило, не трогается.
  • Типы шифрования TKT — поддерживаемые алгоритмы шифрования для выдаваемых сервером билетов. Как правило, не трогается.
  • Разрешённые типы шифрования — типы шафрования для сессионного ключа.
  • Разрешить типы шифрования невысокой криптостойкости — собственно, позволяет разрешить использование слабозащищённых алгоритмов шифрования. Если мучает паранойя и требуется бОльшая безопасность при подключении к серверу, снимите этот чекбокс.

На всякий случай дам совет. На момент написания этой статьи, в ROSA Server Setup существовал крайне неприятный баг, приводивший к тому, что если вы неправильно с первой попытки заполнили одно из обязательных полей, то ветка для Kerberos данными в БД LDAP всё равно создавалась. Это приводило к тому, что при повторно заполненной форме, но уже с правильными значениями, нельзя было продолжить дальнейшую настройку. В следующих версиях эту проблему гарантированно устранят, так что на всякий случай выполните команду yum update в эмуляторе терминала перед установкой.

Если же всё-таки напоролись на эту ошибку, возьмите любой редактор для LDAP. Сойдёт даже такой простой как luma. Как правило, он есть в репозиториях любого дистрибутива. Подключитесь к серверу и удалите полностью следующие записи:

dn: ou=kerberos,SUFFIX@
dn: uid=kadmin,ou=System Accounts,SUFFIX@
dn: uid=kdc,ou=System Accounts,SUFFIX@
dn: cn=Kerberos Admins,ou=System Groups,SUFFIX@
dn: cn=Kerberos Readers,ou=System Groups,SUFFIX@

Ещё на всякий случай проверьте существование следующих записей:

dn: relativeDomainName=kerberos,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,SUFFIX@
dn: relativeDomainName=_kerberos._udp,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,SUFFIX@
dn: relativeDomainName=_kerberos-master._udp,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,SUFFIX@
dn: relativeDomainName=_kerberos-adm._tcp,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,SUFFIX@
dn: relativeDomainName=_kpasswd._udp,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,SUFFIX@

Если они имеются, тоже удалите. После чего, перезапустите мастер установки.

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

uid=LDAP Admin,ou=System Accounts,dc=rosa,dc=int

В настройках luma использовать Simple authentication. Пароль — тот, что вы указывали при настройке с помощью ROSA Server Setup. Естественно, вместо dc=rosa,dc=int должен быть указан ваш домен. Шифрование при подключении не применяется.

Теперь нам необходимо обязательно (!) настроить NTP как на сервере так и клиентах, в противном случае наши клиентские машины могут не подключиться из-за неправильных настроек часов.

На сервере достаточно проделать:

sudo yum install ntp
sudo chkconfig ntpd on
sudo vim /etc/ntp.conf

Как можем увидеть, серверы NTP уже прописаны. Остаётся только скомандовать:

ntpdate pool.ntp.org
service ntpd start.

Проверьте и синхронизируйте часы на клиентских системах. Это очень важный момент настройки.

Создание принципалов

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

Для начала заглянем в список принципалов Kerberos и удостоверимся, что все служебные принципалы на месте:
Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server
Теперь создадим уже нашего пользователя и принципала Kerberos. Для этого мы переходим в ROSA Management Console и добавляем тестового пользователя через «Добавить пользователя» в главном меню. Заполняем поля логина и пароль. Если прокрутить форму чуть ниже, то можно увидеть параметры относящиеся к настройкам Kerberos. Можно задать следующие параметры:

  • Использование парольной политики
  • Установить срок действия принципала
  • Установить срок действия пароля принципала

Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server
Думаю, объяснять смысл всех трёх пунктов нет смысла. Всё достаточно очевидно.

В случае успешного и правильного заполнения полей, после нажатия на кнопку «Подтвердить» появится соответствующее уведомление:
Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server

Проверка в действии

Для начала проверим, что всё действительно работает средствами консольных утилит. Это позволит сразу отследить возникающие ошибки. Для начала необходимо установить пакет krb5-workstation, после чего в командной строке запустить команду kinit, а после ввода пароля ввести команду klist, чтобы удостовериться в правильности сделанного запроса.

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

kinit test@ROSA.INT
Password for test@ROSA.INT:

klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: test@ROSA.INT

Valid starting Expires Service principal
10/19/11 01:46:33 10/20/11 01:46:33 krbtgt/ROSA.INT@ROSA.INT
renew until 10/26/11 01:46:33

Если вы видите всё именно так, как в листинге выше, то вам прилетает правильный билет Kerberos, а это значит, что можно приступить к настройке рабочего места.

В качестве клиентской операционной системы я использовал дистрибутив Linux ROSA Desktop Fresh 2012. Там уже есть мастер настройки подключения к таким серверам. Для остальных дистрибутивов я приведу листинги рабочих конфигурационных файлов чуть позднее, чтобы вы могли использовать любой другой дистрибутив, который вам лично по вкусу.

Для подключения к серверу RELS необходимо открыть «Настройки рабочего стола» и выбрать найти пиктограмму с надписью «Аутентификация». Выбираем пункт Kerberos 5. Затем, прописываем сервер, как указано на скриншоте. Обратите внимание на расставленные чекбоксы. Если оставить последний активированным, то могут не установиться необходимые для подключения пакеты и их зависимости.

Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server

На следующем скриншоте прошу обратить внимание на две опции: «Использовать локальный файл с данными пользователей» и «Использовать LDAP с данными о пользователях».

Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server

Если вы будете использовать пункт «локальный файл с данными пользователей», то вам придётся удостовериться в наличии существования учётной записи с нужным именем на локальной машине. В случае её отсутствия на одной из сторон, создать на сервере и клиенте пользователя с одинаковым логином. Но задать ему разные пароли. Это не очень хорошо и добавляет уйму головной боли администратору. К тому же, из-за довольно больших таймаутов по умолчанию, первый вход в систему с использованием такого метода входа будет очень медленным. Более правильным является выбор второго пункта: «Использовать LDAP с данными о пользователях». В этом случае, вам нет необходимости заводить две учётные записи, все данные будут браться с сервера. Что, согласитесь, куда приятнее. Будьте внимательными, адрес должен быть указан в виде IP-адреса, а не FQDN-имени. После чего нажать на кнопку «Получить данные DN».

Проверяется корректность получения билета очень просто и аналогично тому, как мы проверяли его на сервере. То есть, командой klist, но без каких-либо дополнительных параметров. Так как машина уже включена в область Kerberos и билет должен прилететь при входе в систему.

И обещанные листинги конфигурационных файлов:

/etc/krb5.conf

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = ROSA.INT
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

/etc/ldap.conf

base dc=rosa,dc=int
host 192.168.100.1
nss_base_group dc=rosa,dc=int?sub
nss_base_shadow dc=rosa,dc=int?sub
nss_base_passwd dc=rosa,dc=int?sub

/etc/nsswitch.conf

passwd:         files ldap
shadow:         files ldap
group:          files ldap

hosts:           mdns4_minimal files nis dns wins mdns4 
networks:       files

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files ldap
aliases:        files

/etc/pam.d/system-auth

#%PAM-1.0

auth        required      pam_env.so
auth        sufficient    pam_tcb.so shadow nullok prefix=$2a$ count=8
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

account     sufficient    pam_tcb.so shadow
account     sufficient    pam_krb5.so use_first_pass
account     required      pam_deny.so

password    required      pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8
password    sufficient    pam_krb5.so
password    required      pam_deny.so

session     optional      pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_tcb.so
session     optional      pam_krb5.so

Если кому-то нужно аутентифицироваться исключительно через LDAP не применяя Kerberos, то всё значительно упрощается.

Точно также запускаете мастер настройки, только вместо пункта Kerberos требуется выбрать LDAP. Для дистрибутивов ROSA Marathon 2012 (LTS) и ROSA Desktop Fresh 2012 все необходимые пакеты требуемые для подключения уже входят в состав дистрибутива. Остальным следует знать, что для настройки клиента потребуются следующие пакеты: openldap-clients, pam_ldap, autofs.

На этом этапе необходимо указать адрес LDAP-сервера. Как и в прошлый раз, адрес не забываем указывать в виде октетов. В противном случае, будет сгенерирован нерабочий конфигурационный файл (впрочем, его всегда можно исправить руками в случае чего). База пользователей определяется автоматическим образом при нажатии на кнопку «Получить DN». Как и в прошлом примере, необходимо снять флаг «Автономный режим», иначе настройка будет произведена не совсем верно.

Также проверить работоспособность в консоли можно с помощью команды getent paswd, либо выполнить команду su имя_пользователя_в_БД_ldap. Первая команда покажет список пользователей, среди которых будут перечислены пользователи каталога LDAP. Во врем выполнения второй команды будет выполнен вход в систему с использованием учётных данных пользователя каталога LDAP и автоматически создастся каталог аутентифицировавшегося пользователя внутри директории /home.

Примеры конфигурационных файлов:

Содержимое ldap.conf:

base dc=rosa,dc=int
host 192.168.100.1
nss_base_group dc=rosa,dc=int?sub
nss_base_shadow dc=rosa,dc=int?sub
nss_base_passwd dc=rosa,dc=int?sub
Содержимое nsswitch.conf:
passwd:         files ldap
shadow:         files ldap
group:          files ldap

hosts:           mdns4_minimal files nis dns wins mdns4 
networks:       files

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files ldap
aliases:        files

И, наконец, system-auth:

#%PAM-1.0

auth        required      pam_env.so
auth        sufficient    pam_tcb.so shadow nullok prefix=$2a$ count=8
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     sufficient    pam_tcb.so shadow
account     sufficient    pam_ldap.so use_first_pass
account     required      pam_deny.so

password    required      pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8
password    sufficient    pam_ldap.so
password    required      pam_deny.so

session     optional      pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_tcb.so

Заключение

На этом всё, пожалуй. Мы научились быстро и без проблем создавать собственный сервер аутентификации с использованием Kerberos и LDAP. В дальнейшем, керберизацию можно использовать для самых различных целей. Например, связать Kerberos с сервером PostgreSQL, например и использовать принципалов Kerberos для входа. Или создание инфраструктуры Single Sign-On и многое другое.
Традиционно надеюсь, что материал пригодится как начинающим, а также просто ленивым (в хорошем смысле) системным администраторам.

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

Автор: r0g3r

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js