Введение
Продолжение серии туториалов. Предыдущие части:
Развёртывание DNS/DDNS и DHCP сервера на ROSA Enterpise Linux Server за несколько минут
Почтовый сервер на базе ROSA Server Enterpise Linux за несколько минут
Простой домен на базе ROSA Enterprise Linux Server и Samba 3 с поддержкой перемещаемых профилей
В этой статье мы рассмотрим создание сервера для централизованной аутентификации пользователей посредством 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.
Проверяем:
Теперь можно идти устанавливать необходимые компоненты для будущего сервера аутентификации, для чего проследуем в ROSA Server Setup и выбираем компонент «Аутентификация Kerberos с RDS backend». Дожидаемся окончания установки всех необходимых компонентов и нажимаем «Продолжить» для первоначальной настройки. Откроется вот такая замечательная формочка:
Дам некоторые пояснения по представленному выше скриншоту:
На всякий случай дам совет. На момент написания этой статьи, в ROSA Server Setup существовал крайне неприятный баг, приводивший к тому, что если вы неправильно с первой попытки заполнили одно из обязательных полей, то ветка для Kerberos данными в БД LDAP всё равно создавалась. Это приводило к тому, что при повторно заполненной форме, но уже с правильными значениями, нельзя было продолжить дальнейшую настройку. В следующих версиях эту проблему гарантированно устранят, так что на всякий случай выполните команду yum update в эмуляторе терминала перед установкой.
Если же всё-таки напоролись на эту ошибку, возьмите любой редактор для LDAP. Сойдёт даже такой простой как luma. Как правило, он есть в репозиториях любого дистрибутива. Подключитесь к серверу и удалите полностью следующие записи:
Ещё на всякий случай проверьте существование следующих записей:
Если они имеются, тоже удалите. После чего, перезапустите мастер установки.
Для подключения к серверу 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, чтобы удостовериться в правильности сделанного запроса.
Выглядеть это будет примерно следующим образом:
Если вы видите всё именно так, как в листинге выше, то вам прилетает правильный билет Kerberos, а это значит, что можно приступить к настройке рабочего места.
В качестве клиентской операционной системы я использовал дистрибутив Linux ROSA Desktop Fresh 2012. Там уже есть мастер настройки подключения к таким серверам. Для остальных дистрибутивов я приведу листинги рабочих конфигурационных файлов чуть позднее, чтобы вы могли использовать любой другой дистрибутив, который вам лично по вкусу.
Для подключения к серверу RELS необходимо открыть «Настройки рабочего стола» и выбрать найти пиктограмму с надписью «Аутентификация». Выбираем пункт Kerberos 5. Затем, прописываем сервер, как указано на скриншоте. Обратите внимание на расставленные чекбоксы. Если оставить последний активированным, то могут не установиться необходимые для подключения пакеты и их зависимости.
На следующем скриншоте прошу обратить внимание на две опции: «Использовать локальный файл с данными пользователей» и «Использовать LDAP с данными о пользователях».
Если вы будете использовать пункт «локальный файл с данными пользователей», то вам придётся удостовериться в наличии существования учётной записи с нужным именем на локальной машине. В случае её отсутствия на одной из сторон, создать на сервере и клиенте пользователя с одинаковым логином. Но задать ему разные пароли. Это не очень хорошо и добавляет уйму головной боли администратору. К тому же, из-за довольно больших таймаутов по умолчанию, первый вход в систему с использованием такого метода входа будет очень медленным. Более правильным является выбор второго пункта: «Использовать LDAP с данными о пользователях». В этом случае, вам нет необходимости заводить две учётные записи, все данные будут браться с сервера. Что, согласитесь, куда приятнее. Будьте внимательными, адрес должен быть указан в виде IP-адреса, а не FQDN-имени. После чего нажать на кнопку «Получить данные DN».
Проверяется корректность получения билета очень просто и аналогично тому, как мы проверяли его на сервере. То есть, командой klist, но без каких-либо дополнительных параметров. Так как машина уже включена в область Kerberos и билет должен прилететь при входе в систему.
И обещанные листинги конфигурационных файлов:
/etc/krb5.conf
/etc/ldap.conf
/etc/nsswitch.conf
/etc/pam.d/system-auth
Если кому-то нужно аутентифицироваться исключительно через 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:
И, наконец, system-auth:
Заключение
На этом всё, пожалуй. Мы научились быстро и без проблем создавать собственный сервер аутентификации с использованием Kerberos и LDAP. В дальнейшем, керберизацию можно использовать для самых различных целей. Например, связать Kerberos с сервером PostgreSQL и использовать принципалов Kerberos для входа. Или создание инфраструктуры Single Sign-On и многое другое.
Традиционно надеюсь, что материал пригодится как начинающим, а также просто ленивым (в хорошем смысле) системным администраторам.
Дельные комментарии, вопросы по существу и фичреквесты всегда приветствуются.
Продолжение серии туториалов. Предыдущие части:
Развёртывание DNS/DDNS и DHCP сервера на ROSA Enterpise Linux Server за несколько минут
Почтовый сервер на базе ROSA Server Enterpise Linux за несколько минут
Простой домен на базе ROSA Enterprise Linux Server и Samba 3 с поддержкой перемещаемых профилей
В этой статье мы рассмотрим создание сервера для централизованной аутентификации пользователей посредством 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 и многое другое.
Традиционно надеюсь, что материал пригодится как начинающим, а также просто ленивым (в хорошем смысле) системным администраторам.
Дельные комментарии, вопросы по существу и фичреквесты всегда приветствуются.
