Настройка авторизации в LDAP для SSH и Sudo.
Статья описывает процесс настройки системы в которой:
- аккаунты и группы хранятся в LDAP;
- публичные SSH ключи хранятся в LDAP;
- SSH выполняет аутентификацию и авторизацию в LDAP;
- информация о sudoers хранится в LDAP;
- sudo выполняет авторизацию в LDAP;
Настройка сервера.
Серверная часть представляет собой сервер OpenLDAP. Сначала устанавливаем соответствующие пакеты. Установка выполняется с помощью paludis.
# vi /etc/paludis/use.conf
app-admin/sudo ldap
net-misc/openssh ldap
net-nds/openldap odbc
# cave resolve net-nds/openldap app-admin/sudo net-misc/openssh -x
После установки следует сгенерировать пароль который будет использоваться для учетной записи администратора LDAP.
# slappasswd
New password:
Re-enter new password:
{SSHA}9/f5C/34XA2UggRPA8I93MjAt8ju1d/F
Также необходимо создать самоподписанный сертификат и ключ (срок действия - 10 лет) для SSL и TLS подключений.
# openssl req -config /etc/ssl/openssl.cnf -new -x509 -nodes \
-out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
Переходим к настройке slapd - сервера OpenLDAP. Настройка сводится к подключению дополнительных схем, определению настроек для TLS и самое главное, выполняется настройка каталога. Также указываем сгенерированный пароль (rootpw) для административной учетной записи (rootdn)
# vi /etc/openldap/slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/openssh-lpk.schema
include /etc/openldap/schema/sudo.schema
# TLS related settings
TLSCertificateFile /etc/ssl/ldap.pem
TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem
TLSCACertificateFile /etc/ssl/ldap.pem
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# allow users change their passwords
access to attrs=userPassword
by self write
by anonymous auth
by users none
access to * by * read
# Directory settings
database hdb
suffix "dc=thislinux,dc=org"
checkpoint 32 30
rootdn "cn=Manager,dc=thislinux,dc=org"
rootpw {SSHA}9/f5C/34XA2UggRPA8I93MjAt8ju1d/F
directory /var/lib/openldap-data/thislinux.org
index objectClass eq
Теперь создаем каталог для нашего каталога. Копируем недостающую схему, проверяем конфигурацию и запускаем slapd.
# mkdir /var/lib/openldap-data/thislinux.org
# chown ldap: /var/lib/openldap-data/thislinux.org
# chmod 700 /var/lib/openldap-data/thislinux.org
# cp /var/lib/openldap-data/DB_CONFIG.example /var/lib/openldap-data/thislinux.org/DB_CONFIG
# cp /usr/share/doc/sudo-1.8.6_p3/schema.OpenLDAP /etc/openldap/schema/sudo.schema
# slaptest -u -f /etc/openldap/slapd.conf
config file testing succeeded
# /etc/init.d/slapd start
Теперь выполняем настройку локального клиентского подключения к LDAP
# vi /etc/openldap/ldap.conf
BASE dc=thislinux,dc=org
URI ldap://ldap.thislinux.org
TIMELIMIT 15
Сейчас, пожалуй самый сложный этап в настройке - создание схемы каталога. Несколько слов о будущей структуре каталога. Корневым узлом будет наша организация, внутри нее будет две абстрактных сущности в виде организационных единиц (ou): люди (ou=people) и проекты (ou=projects). Внутри people, создадим более четкую структуру: учетные записи (ou=accounts) - здесь будут перечислены учетные записи сотрудников; роли (ou=roles) - здесь мы определим основные роли в организации, на основании ролей мы будем привязываться к sudoers; группы sudo (ou=sudoers) - здесь мы определим конкретные правила для sudo. Вторая сущность - ou=projects - является вместилищем проектов. С этими проектами будут ассоциироваться учетные записи. И на основе принадлежности к проектам будет осуществляться доступ на сервера.
init.ldif - начальная схема каталога
# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f init.ldif
Enter LDAP Password:
adding new entry "dc=thislinux,dc=org"
adding new entry "ou=people,dc=thislinux,dc=org"
adding new entry "ou=accounts,ou=people,dc=thislinux,dc=org"
adding new entry "ou=roles,ou=people,dc=thislinux,dc=org"
adding new entry "ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "ou=projects,dc=thislinux,dc=org"
Дальше создаем роли в виде POSIX групп, с этими группами будут ассоциироваться учетные записи для дальнейшего определения прав sudo.
posix-groups.ldif - схема групп
# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f posix-groups.ldif
Enter LDAP Password:
adding new entry "cn=testers,ou=roles,ou=people,dc=thislinux,dc=org"
adding new entry "cn=support,ou=roles,ou=people,dc=thislinux,dc=org"
adding new entry "cn=developers,ou=roles,ou=people,dc=thislinux,dc=org"
adding new entry "cn=admins,ou=roles,ou=people,dc=thislinux,dc=org"
Создаем учетные записи пользователей, в записи определяем gid группы которой будет принадлежать учетная запись. Таким образом мы определяем привилегии sudo для учетной записи. Пока хватит одной учетной записи.
posix-account.ldif - образец учетной записи
# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f posix-account.ldif Enter LDAP Password:
adding new entry "uid=lesovsky,ou=accounts,ou=people,dc=thislinux,dc=org"
Далее создаем контейнеры наших проектов. Как я уже писал выше, на основе этих контейнеров будет определяться возможность доступа к серверам. Создаем два проекта - thinsearch и widescope.
project.ldif - образцы проектов
# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f project.ldif Enter LDAP Password:
adding new entry "cn=thinsearch,ou=projects,dc=thislinux,dc=org"
adding new entry "cn=widescope,ou=projects,dc=thislinux,dc=org"
И последний этап структуры - sudoers. Команды перечисленные в sudoers взяты самые первые пришедшие в голову, в любом случае, список команд можно изменить или дополнить.
sudoers.ldif - sudoers структуры
# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f sudoers.ldif Enter LDAP Password:
adding new entry "cn=defaults,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=root,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=%testers,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=%support,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=%developers,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=%admins,ou=sudoers,ou=people,dc=thislinux,dc=org"
Настройка сервера может считаться завершенной.
Переходим к клиенту.
Для настройки клиента, также нужно установить несколько пакетов. Здесь стоит отметить что один из пакетов, app-admin/authconfig не идет в официальном дереве portage, поэтому берем его из zugaina.
# vi /etc/paludis/use.conf
net-nds/openldap minimal
sys-libs/tdb python
sys-libs/talloc python
app-crypt/mit-krb5 openldap
net-misc/openssh ldap
app-admin/sudo ldap
# cave resolve app-admin/authconfig sys-auth/pam_ldap sys-auth/sssd net-misc/openssh app-admin/sudo -x
Копируем ранее сгенерированный сертификат на клиентскую машину
# scp ldap.thislinux.org:/etc/ssl/ldap.pem /etc/openldap/cacerts/
Переходим к настройке и запуску sssd.
# vi /etc/sss/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = default
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
[domain/default]
ldap_tls_reqcert = allow
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = ldaps://ldap.thislinux.org
ldap_search_base = dc=thislinux,dc=org
ldap_group_member = uniquemember
ldap_id_use_start_tls = true
chpass_provider = ldap
ldap_chpass_uri = ldaps://ldap.thislinux.org
enumerate = false
cache_credentials = true
entry_cache_timeout = 600
ldap_network_timeout = 3
ldap_access_filter = (&(objectclass=shadowaccount)(objectclass=posixaccount))
Выставляем "суровые" права на файл конфигурации
# chmod 600 /etc/sssd/sssd.conf
И осталось определить порядок просмотра и источники поиска для NSS (Диспечтер служб имен). Находим три строки и приводим их в соответствующий вид:
# vi /etc/nswitch.conf
passwd: files sss
shadow: files sss
group: files sss
Запускаем authconfig, выпавшие ошибки игнорируем, т.к. скрипт написан под специфику RedHat Linux. После чего запускаем сервис sssd.
# authconfig --enablesssd --enablesssdauth --enablecachecreds --enableldap \
--disableldaptls --enableldapauth --ldapserver=ldap.thislinux.org \
--ldapbasedn="ou=accounts,ou=people,dc=thislinux,dc=org" --disablenis \
--disablekrb5 --enableshadow --enablemkhomedir --enablelocauthorize --passalgo=sha512 \
--updateall
# /etc/init.d/sssd start
Теперь правим общие настройки для клиентского подключения к LDAP (обращаем внимание на использование TLS)
# vi /etc/openldap/ldap.conf
BASE ou=accounts,ou=people,dc=thislinux,dc=org
URI ldaps://ldap.thislinux.org/
TIMELIMIT 15
TLS_REQCERT allow
TLS_CACERTDIR /etc/openldap/cacerts
Проверяем работоспособность подключения к LDAP, если проверка завершилось ошибкой "No such user" следует остановиться и все перепроверить, т.к. дальше идти смысла нет.
# id lesovsky
uid=10000(lesovsky) gid=1011(support) groups=1011(support)
В случае успешной проверки настраиваем sshd на работу с LDAP. Способность sshd брать ключи из LDAP каталога, реализована с помощью патчей проекта LPK. При настройке следует учесть один момент, LPK не умеет обращаться напрямую к идентификаторам ldaps:// поэтому он работает только со стандартными ldap:// ссылками, но с инициализацией TLS соединения. Настройка сводится к указанию параметров LPK внутри конфигурации sshd и к определению настроек для подключения к LDAP. Следует обратить внимание на параметр LpkServerGroup - здесь мы указываем тот самый проект. Учетные записи принадлежащие проекту смогут попасть на сервер. Остальным - вход запрещен.
# /etc/ssh/sshd_config
LogLevel VERBOSE
PasswordAuthentication no
UsePAM yes
PrintMotd no
PrintLastLog no
UseLPK yes
LpkLdapConf /etc/ldap.conf
LpkServers ldap://ldap.thislinux.org
LpkUserDN ou=accounts,ou=people,dc=thislinux,dc=org
LpkGroupDN ou=projects,dc=thislinux,dc=org
LpkBindDN cn=Manager,dc=thislinux,dc=org
LpkBindPw klfgflvby
LpkServerGroup widescope
LpkForceTLS yes
LpkSearchTimelimit 3
LpkBindTimelimit 3
LpkPubKeyAttr sshPublicKey
Subsystem sftp /usr/lib64/misc/sftp-server
# vi /etc/ldap.conf
uri ldap://ldap.thislinux.org/
port 636
binddn cn=Manager,dc=thislinux,dc=org
bindpw Здесь_Указываем_Пароль
base ou=accounts,ou=people,dc=thislinux,dc=org
timelimit 30
bind_timelimit 30
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
pam_password md5
# /etc/init.d/sshd restart
Завершающий этап - настройка sudo. Sudo умеет самостоятельно подключаться к LDAP и для этого ему требуется отдельный файл конфигурации.
# vi /etc/ldap.conf.sudo
uri ldap://ldap.thislinux.org
ssl start_tls
sudoers_base ou=sudoers,ou=people,dc=thislinux,dc=org
bind_timelimit 3
timelimit 3
sudoers_debug 0
Для диспетчера NSS указываем источник где брать информацию о sudoers.
# vi /etc/nsswitch.conf
sudoers: ldap files
На этом настройка считается завершенной и можно приступить к тестированию.
Для начала задаем пароль для нашей, пока единственной учетной записи:
# ldappasswd -x -W -D "cn=Manager,dc=thislinux,dc=org" \
-s qwerty "uid=lesovsky,ou=accounts,ou=people,dc=thislinux,dc=org"
Сначала проверим используется ли TLS в ходе подключения к LDAP. Это можно проверить через ldapsearch с параметрами -Z[Z] (часть вывода опущено).
# ldapsearch -x -b -H ldaps://ldap.thislinux.org -D "cn=Manager,dc=thislinux,dc=org" -W -d 1 -ZZ
.....
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 0, err: 0, subject: /C=RU/ST=Sverdlovskaya obl./L=Yekaterinburg/O=Thislinux/OU=development/CN=ldap.thislinux.org/emailAddress=lesovsky@gmail.com, issuer: /C=RU/ST=Sverdlovskaya obl./L=Yekaterinburg/O=Thislinux/OU=development/CN=ldap.thislinux.org/emailAddress=lesovsky@gmail.com
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read server session ticket A
TLS trace: SSL_connect:SSLv3 read finished A
....
Теперь можно приступить к тестированию. Для порядка можно следовать такому плану:
- попытка подключения неавторизованного пользователя - учетная запись не принадлежит ни одной из групп, без ключа, известен только пароль - в результате нельзя попасть на сервер;
- подключения участника thinsearch - учетная запись находится в проекте thinsearch - в результате сервер разрешает входить участникам группы thinsearch;
- подключения участника widescope - учетная запись находится в проекте widescope - в результате сервер НЕ разрешает входить участникам группы widescope;
- проверки sudo. учетной записи присвоен gid %testers - в результате учетная запись способна выполнять команды разрешенные для %testers через sudo.
- проверки sudo. учетной записи присвоен gid %testers - попытка выполнить команду не определенную в sudo, должна завершится неудачей;
- проверки sudo. учетной записи присвоен gid %developers - попытки выполнить команды перечисленные в %developers должны завершаться успешно;
- проверка смены пароля - попытка сменить пароль через passwd, для пользователя подключившегося к серверу, должна завершаться успешно.
На главную "Virtualizing Linux"
Комментариев нет:
Отправить комментарий