Единая аутентификация Linux и Windows пользователей на Windows сервере в AD с использованием Kerberos и LDAP по SSL (для безопасности).
Авторы: Журавлев Николай и Зеленчук Илья
e-mails: znick [ yeah! ] hackerdom.ru and ilya [ some doggy ] hackerdom.ru
Введение
Общая идея – хочется иметь единое место для хранения информации, как Windows, так и UNIX пользователей. К тому же, у нас в институте имеется несколько серверов (вычислительные кластеры) под управлением ОС GNU/Linux на которых работают пользователи, и было бы очень удобно для них иметь единый пароль для доступа ко всем ресурсам. Учетные данные пользователей будут храниться в домене Active Directory.
И так, Kerberos будет использоваться для проведения авторизации (проверка имя пользователя и пароля), а также для смены паролей на учетных записях пользователей. А LDAP понадобится для извлечения информации о UNIX пользователе: домашняя директория, шел, uid, gid и т.д.
Все действия я проводил на Windows 2003 Server SP1, Fedora Core 4 и CentOS 5. Если у вас другой дистрибутив, ничего страшного, возможно небольшое отличие в названиях пакетов и местах хранения конфигурационных файлах.
Замечание: при настройке UNIX сервера, всегда держите одну консоль открытой с root привилегиями, что бы в случае сбоя или других причин вы в любой момент могли вернуть все обратно.
Замечание2: если у вас Windows 2003 Server R2, тогда вы можете пропустить главу «Настройка Windows сервера». Что бы получить возможность хранить данные о UNIX пользователях можно воспользоваться встроенными средствами Windows. Для это зайдите в «Control Panel», и там откройте «Add/Remove Windows Componets», затем в «Active Directory Services» и установите «Identify Management for UNIX».
Настройка Windows сервера
Для того, что бы пользователи UNIX смогли нормально проходить аутентификацию на Windows сервере необходимо расширить существующую схему AD, так как стандартная не предусматривает записей типа uid, gid, домашняя директория, шелл по умолчанию и т.д., что необходимо для UNIX клиентов. Для расширения существующей схемы можно воспользоваться утилитой от VAS (Vintela Authentication Services). Она включает набор программ, которые позволяют с легкостью (как утверждают на то сами разработчики) провести интеграцию Windows и UNIX. Но для проведения простой аутентификации достаточно 3-х утилит из всего набора – это SchemaWizard.exe, dsreg32.exe и VAS-3.0.1.31.msi:
SchemaWizard – расширяет существующую схему AD. Для этого нужно запустить её на контроллере домена и установить расширение R2 subset for VAS. Этого будет вполне достаточно, что бы проводить аутентификация UNIX пользователей.
dsreg32.exe – обновляет графический интерфейс управления пользователями и группами в AD, что бы стало возможным производить настройки для UNIX пользователей.
VAS-3.0.1.31.msi – устанавливает программы для конфигурирования UNIX пользователей, а так же интерфейс для управления пользователями и группами в AD. Конфигуратор можно найти в “Пуск ->Программы->Quest software->VAS”, он позволяет задавать параметры по умолчанию для UNIX, такие как shell и домашний каталог. Помимо этого становиться доступным и вкладка для управления UNIX пользователями и группами в AD. Для этого нужно открыть свойства пользователя или группы и выбрать вкладку “UNIX Account”. Что бы пользователи имели возможность аутентифицироваться на UNIX их необходимо включить (Enable Unix Account), иначе их shell будет установлен в /bin/false.
Для завершения настройки Windows сервера необходимо добавить учетную запись в AD, под которой UNIX машины могли бы подключаться к LDAP и выполнять запросы информации. Например, пусть это будет unix_manager. И в связи с тем, что LDAP сам по себе не безопасен, то лучше его использовать поверх SSL. Для этого достаточно установить «центр сертификатов» на котроллере доменов. После этого становиться доступным 636 порт (LDAP over SSL).
Настройка UNIX машин
Что бы стало возможным проводить аутентификацию UNIX пользователей в AD, понадобится 3-а пакета – это pam_krb5, openldap и nss_ldap. И ещё желательно установить пакет krb5-workstation и openldap-clients, в них содержатся основные утилиты (kinit, klist, kpasswd, ldapsearch…) для работы с Kerberos и ldap.
Настройка Kerberos
Конфигурация 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 = FQDN.OF.YOUR.DOMAIN.NAME
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
FQDN.OF.YOUR.DOMAIN.NAME = {
kdc = dc.fqdn.of.your.domain.name:88
kdc = copy_dc.fqdn.of.your.domain.name:88
admin_server = dc.fqdn.of.your.domain.name:749
default_domain = fqdn.of.your.domain.name
}
[domain_realm]
.fqdn.of.your.domain.name = FQDN.OF.YOUR.DOMAIN.NAME
fqdn.of.your.domain.name = FQDN.OF.YOUR.DOMAIN.NAME
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
FQDN.OF.YOUR.DOMAIN.NAME обязательно пишется в верхнем регистре!
dc.fqdn.of.your.domain.name – имя доменного контролера, который ответственный за аутентификацию.
Для проверки работоспособности Kerberos воспользуйтесь утилитой kinit и klist.
Первая позволит пройти аутентификацию на домене, а при помощи второй можно посмотреть, получили ли вы билет или нет. Если билета нет, значит неправильно набрали пароль, имя пользователя или неверно настроили /etc/krb5.conf или ещё какая причуда случилась. Советую в этом случае воспользоваться снифером и посмотреть, что происходит в сети. При аутентификации используется всего 2-а пакета.
Openldap и nss_ldap
При конфигурировании nss_ldap и openldap необходимо поправить 2-а файла конфигурации. Первый из них это /etc/ldap.conf (в некоторых Linux дистрибутивах он называется libnss_ldap.conf), а второй – /etc/openldap/ldap.conf. Но перед тем, как начать их настраивать, необходимо скачать сертификат из «Центра Сертификатов».
Загрузка сертификата с сервера.
Сертификат понадобится при шифровании. Что бы его получить необходимо на одном из контроллеров домена Active Directory установить службу «Центр Сертификатов». Во время установки она автоматически сконфигурирует IIS. После этого нужно зайти любимым браузером по адресу http://cc.fqdn.of.your.domain.name/certsrv/ и загрузить сертификат ЦС. Где cc.fqdn.of.your.domain.name – это доменный контролер на котором установлен Центр Сертификатов. Во время загрузки сертификата можно выбрать метод, которым будет закодирован сам сертификат, я выбрал base64.
Скаченный сертификат необходимо сохранить на UNIX машине. Пусть это будет /etc/openldap/cacerts/domain.cer
Настройка /etc/ldap.conf (он же /etc/libnss_ldap.conf)
# Используем Ldap over SSL. Для отказоустойчивости, советую прописать (через пробел)
# не один, а несколько адресов контроллеров домена.
uri ldaps://dc.fqdn.of.your.domain.name:636/ ldaps://copy_dc.fqdn.of.your.domain.name:636/
# Версия протокола Ldap.
ldap_version 3
# Учетные записи для пользователя, под которым заходим (unix_manager.)
# unix_manager это не Login name, а First name, если кто-то забыл :)
binddn cn=unix_manager,ou=domain_users,dc=imm,dc=uran,dc=ru
# Пароль.
bindpw secret
# Порт, на который устанавливаем соединение, хотя он уже прописан выше.
port 636
# Как искать.
scope sub
# Различные таймауты.
timelimit 10
bind_timelimit 120
idle_timelimit 3600
# Имя пользователей, которых не смотреть в ldap, они точно локальные.
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon
# Это нужно!
nss_map_attribute rfc2307attribute mapped_attribute
nss_map_objectclass rfc2307objectclass mapped_objectclass
# RFC 2307 (AD) mappings
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User
pam_password ad
# Говорим, что будем использовать ssl.
ssl start_tls
ssl yes
tls_checkpeer yes
# Где расположен сертификат от сервера (тот, который скачали).
tls_cacertfile /etc/openldap/cacerts/domain.cer
# Папка с сертификатом.
tls_cacertdir /etc/openldap/cacerts
tls_ciphers TLSv1
То, что имя пользователя и пароль для доступа к AD серверу доступен всем пользователем, ничего страшного. Он не имеет никаких особых прав и ничего не видит, кроме небольшого объема не критичной информации о пользователях.
Настройка /etc/openldap/ldap.conf
# Информация о контроллере домена
BASE dc=fqdn,dc=of,dc=your, dc=domain, dc=name
URI ldaps://dc.fqdn.of.your.domain.name:636
HOST dc.fqdn.of.your.domain.name
# Информация о сертификатах.
TLS_REQCERT never
TLS_CACERTDIR /etc/openldap/cacerts
TLS_CACERT /etc/openldap/cacerts/domain.cer
Для завершения настройки nss_ldap внесите изменения в файл /etc/nsswitch.conf
…
passwd: files ldap
shadow: files ldap
group: files ldap
…
Это говорит о том, что при извлечении информации о пользователе сначала смотреть в файлах (/etc/passwd), и если ничего не нашлось, попытаться получить информацию через ldap. Если этого не сделать, то может произойти забавная ситуация, имя пользователя и пароль будет проверяться на сервере Active Directory по средствам Kerberos, а переменные сессии – из локальных файлов.
Настройка PAM для SSH сервера.
Для начала, в конфигурации sshd необходимо разрешить использовать PAM. В файле /etc/sshd/sshd_config
UsePAM yes
А теперь необходимо сказать sshd, что бы имя пользователя и его пароль проверять через Kerberos. В файле /etc/pam.d/sshd
#%PAM-1.0
auth sufficient pam_krb5.so
auth include system-auth
account required pam_nologin.so
account include system-auth
account required pam_access.so
password include system-auth
session required pam_mkhomedir.so skel=/etc/skel umask=0077
session optional pam_keyinit.so force revoke
session include system-auth
session required pam_loginuid.so
Добавить в начало: auth sufficient pam_krb5.so.
Этим мы сообщаем pam, что авторизацию по ssh первым делом необходимо отдать на проверку модулю pam_krb5.so, а sufficient говорит о том, что удачное прохождение этого модуля обязательно. Это значит, что в случае неверного имени пользователя или пароля аутентификация тут же прекратится.
Так как пользователей никто на системе заводить не будет у них, по умолчанию, не будет домашнего каталога. Что бы при первом входе в систему у пользователя создавался домашний каталог с необходимыми правами и файлами можно воспользоваться PAM модулем pam_mkhomedir.so. Прописывается он в секции session. Например:
session required pam_mkhomedir.so skel=/etc/skel umask=0077
И это все!
Общая картина
Теперь, как это все будет работать вместе:
Пользователь при входе на UNIX машину по ssh вводит имя пользователя и пароль.
Сервер SSH приняв данные от пользователя отдает их на обработку в PAM. Проверка имени и пароля будет осуществляться модулем Kerberos (pam_krb5.so), его конфигурация находится в файле /etc/krb5.conf.
Если имя пользователя или пароль неверны, тогда аутентификация тут же завершается с ошибкой и пользователь получает в ответ “Login incorrect”. Если же имя пользователя и пароль указан правильно, следующим этапом будет вход пользователя в систему.
Для входа пользователя в систему необходимо узнать его переменные сессии, т.е. домашний каталог, uid, gid и шелл. Место хранения этих переменные система узнает из файла /etc/nsswitch.conf. В нашем случае там указано следующее:
passwd: files ldap
shadow: files ldap
group: files ldap
Это означает, что информацию о пользователе в начале нужно поискать в локальных файлах и если ничего не найдется, попробовать в nss_ldap. В качестве конфигурационных файлов nss_ldap будет использовать /etc/ldap.conf (или /etc/libnss_ldap.conf) и /etc/openldap/ldap.conf.
В случае успешного получения переменных сессии, PAM признает аутентификацию состоявшейся. Обращаем ваше внимание, что получение переменных сессии является необходимым шагом для успешной авторизации. Даже если имя пользователя и пароль верный, но не удается (по каким-либо причинам) получить переменные сессии, получим “Login Incorect”.
Заключение
Для проверки, что все работает правильно, попробуйте войти на систему через ssh и наберите команду id, что бы узнать UID и GID пользователя. Для смены пароля пользователя с UNIX машины используйте утилиту kpasswd.
Всего наилучшего! Если возникнут вопросы или проблемы, обращайтесь. Я уверен, на других системах могут быть немного другие настройки и я их с удовольствием включу в качестве дополнения к статье.
