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

  • Tutorial
Введение
Продолжение серии туториалов. Предыдущие части:
Развёртывание 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 и многое другое.
Традиционно надеюсь, что материал пригодится как начинающим, а также просто ленивым (в хорошем смысле) системным администраторам.

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

Ну. И что?
Реклама
Комментарии 10
    0
    Было интересно, только вот у меня вопрос возник, я правильно понял, что рабочие станции должны быть под Linux, чтобы использовать этот сервер аутенфикации? Или это не важно? Ну и я не совсем понял для чего этот сервер, для аутенфикации рабочей станции, чтобы из любого места сети можно было подключиться или же это для авторизованного выхода в интернет?
    Я просто как раз начинающий, поэтому не совсем знаком с этим.
      0
      Я обкатывал это только на Linux. BSD-системы в таком окружении тоже должны работать, но наверняка будут нюансы. Наверняка можно будет и Mac докрутить, PAM и утилиты Kerberos там тоже есть, только глубоко уж очень засунуты. Что до применения, по сути — это снова для построения систем с единой точкой аутентификации. Т.е. использовать один логин/пароль для всего. Можно таким образом связать множество сервисов. Базы данных, файлопомойки, почту, и.т.п. У меня заготовка статьи на эту тему уже есть, но когда я её допишу полностью — хороший вопрос.
        0
        Спасибо, ну мне было бы интересно про это почитать. А где используются такие системы и для чего это собственно нужно?
          +1
          Собственно, самый известный вам пример системы использующей подобную схему — Microsoft Active Directory или Novell eDirectory. Если помните, с пользователями в AD можно связать что угодно. Для чего нужно? Централизация и упрощение администрирования всего зоопарка пользователей и компьютеров в локальной сети предприятия. Вместо генерации кучи паролей к каждому сервису, для каждого юзера достаточно создать один, и что самое главное, этот пароль не будет гулять по сети в открытом виде. Керберизация позволяет также связать служебные сервисы. Например, базы данных. Вместо того, чтобы производить изменения в БД с помощью вебморды какой и опять же передавать где-то там пароль в открытом виде, можно разрешить ходить только вот таким юзерам. Что резко увеличивает безопасность.
            0
            Благодарю!
        0
        Не важно в целом. Даже windows можно подключить для аутентификации.
        0
        Тут есть один интересный момент. У вас ldap что позволяет анонимно читать данные в нем?
          0
          Позволяет. Но если полностью закрыть anonymous bind, потеряем возможность чтения тех же адресных книг. ACL для LDAP — очень и очень тонкая вещь. И требует очень вдумчивого разбора. Кстати, этим тоже занимаемся в настоящее время.
            +1
            Технически просто должно происходить как.
            1. Пользователь авторизуется в Kerberos V
            2. Идет LDAP bind под его учеткой в Kerberos и происходит чтение данных.
              +1
              Да, так без проблем делается, надо будет просто поправить дефолтную конфигурацию тогда. Фидбэк дельный, сенкс.

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

        Самое читаемое