Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server
ВНИМАНИЕ: СТАТЬЯ В ПРОЦЕССЕ ФОРМАТИРОВАНИЯ!
В этой статье мы рассмотрим создание сервера для централизованной аутентификации пользователей посредством Kerberos, а также аутентификацию с помощью 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-именем, либо на пиктограмму изображающую два компьютера.
Там необходимо найти запись отвечающую за 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. В большинстве случаев, это имя используемого домена в верхнем регистре. Имя узла 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. Для этого мы переходим в ROSA Management Console и добавляем тестового пользователя через «Добавить пользователя» в главном меню. Заполняем поля логина и пароль. Если прокрутить форму чуть ниже, то можно увидеть параметры относящиеся к настройкам Kerberos. Можно задать следующие параметры: Использование парольной политики Установить срок действия принципала Установить срок действия пароля принципала
Думаю, объяснять смысл всех трёх пунктов нет смысла. Всё достаточно очевидно.
В случае успешного и правильного заполнения полей, после нажатия на кнопку «Подтвердить» появится соответствующее уведомление:
Проверка в действии
Для начала проверим, что всё действительно работает средствами консольных утилит. Это позволит сразу отследить возникающие ошибки. Для начала необходимо установить пакет 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. Затем, прописываем сервер, как указано на скриншоте. Обратите внимание на расставленные чекбоксы. Если оставить последний активированным, то могут не установиться необходимые для подключения пакеты и их зависимости.
На следующем скриншоте прошу обратить внимание на две опции: «Использовать локальный файл с данными пользователей» и «Использовать LDAP с данными о пользователях».
Если вы будете использовать пункт «локальный файл с данными пользователей», то вам придётся удостовериться в наличии существования учётной записи с нужным именем на локальной машине. В случае её отсутствия на одной из сторон, создать на сервере и клиенте пользователя с одинаковым логином. Но задать ему разные пароли. Это не очень хорошо и добавляет уйму головной боли администратору. К тому же, из-за довольно больших таймаутов по умолчанию, первый вход в систему с использованием такого метода входа будет очень медленным. Более правильным является выбор второго пункта: «Использовать 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 и многое другое. Традиционно надеюсь, что материал пригодится как начинающим, а также просто ленивым (в хорошем смысле) системным администраторам.
