Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки...

Инструменты пользователя

Инструменты сайта


unix-linux:centos:join-centos-linux-7-4-to-active-directory-domain-with-sssd-and-realmd-for-authentication-and-configure-ad-domain-security-group-authorization-for-sudo-and-ssh-with-putty-sso

CentOS Linux 7 - Присоединение к домену Active Directory средствами realmd/SSSD и настройка аутентификации и авторизации через доменные группы безопасности

Процедура присоединения Linux-системы к домену Active Directory с помощью SSSD (System Security Services Daemon) и RealmD (Realm Discovery) подробно рассматривалась ранее на примере Debian GNU/Linux 8.6. Данная статья является «выжимкой» основных этапов присоединения к домену Active Directory для системы на базе CentOS Linux 7.4.


Предварительные условия

На нашей Linux-системе, для успешного присоединения и членства в домене Active Directory, должно быть соблюдено как минимум два условия:


Присоединение к домену Active Directory

Устанавливаем необходимые для работы пакеты:

# yum install realmd sssd adcli krb5-workstation

Проверяем успешность обнаружения домена:

# realm discover ad.holding.com --verbose

Настраиваем параметры системы, которые будут использованы при присоединении к домену для заполнения атрибутов operatingSystem и operatingSystemVersion.

# nano /etc/realmd.conf
realmd.conf
[active-directory]
os-name = CentOS Linux
os-version = 7.4.1708 (Core)

Выполняем присоединение к домену (в ходе присоединения будет запрошен пароль доменного пользователя с правами на ввод в домен, указанного в опции –user):

# realm join --verbose --user=volodya \
 --user-principal="host/kom-vm01.ad.holding.com@AD.HOLDING.COM" \
 --computer-ou="OU=Linux Servers,OU-KOM,DC=ad,DC=holding,DC=com" \
 kom-dc01.ad.holding.com


Настройка Kerberos-клиента

Настраиваем конфигурационный файл, ранее установленного клиента Kerberos. Это может быть нужно в случае если мы захотим использовать удалённое Single sign-on (SSO) подключение через сервер SSHD (например через клиент Putty с Windows-системы, как это было описано ранее)

# nano -Y sh /etc/krb5.conf

Пример готовой конфигурации:

krb5.conf
# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
 
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
     dns_lookup_kdc = no
     dns_lookup_realm = false
     ticket_lifetime = 24h
     renew_lifetime = 7d
     forwardable = true
     rdns = false
     default_ccache_name = KEYRING:persistent:%{uid}
     default_realm = AD.HOLDING.COM
 
[realms]
    AD.HOLDING.COM = {
        kdc = kom-dc01.ad.holding.com
        kdc = kom-dc02.ad.holding.com
        admin_server = kom-dc01.ad.holding.com
        default_domain = ad.holding.com
    }
 
[domain_realm]
    ad.holding.com = AD.HOLDING.COM
    .ad.holding.com = AD.HOLDING.COM


Настройка SSSD

Настраиваем конфигурацию службы sssd

# nano -Y sh /etc/sssd/sssd.conf

Пример готовой конфигурации:

sssd.conf
[sssd]
domains = ad.holding.com
config_file_version = 2
services = nss, pam
default_domain_suffix = ad.holding.com
 
[domain/ad.holding.com]
ad_server = kom-dc01.ad.holding.com, kom-dc02.ad.holding.com
ad_backup_server = msk-dc01.ad.holding.com, spb-dc01.ad.holding.com
ad_domain = ad.holding.com
krb5_realm = AD.HOLDING.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
ldap_idmap_default_domain_sid = S-1-5-21-2955347524-3617349964-1548486448
ldap_idmap_range_size = 2000000
ldap_use_tokengroups = False
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
subdomains_provider = none

Очищаем кэш sss и перезапускаем службу sssd:

# systemctl stop sssd
# ( rm -f /var/lib/sss/db/* ) && ( rm -f /var/lib/sss/mc/* )
# systemctl start sssd


Проверка взаимодействия с AD

Проверяем то, что в системе успешно зарегистрированы модули работы SSSD с PAM/NSS:

# cat /etc/nsswitch.conf | grep sss
passwd: files sss shadow: files sss group: files sss services: files sss netgroup: files sss
# cat /etc/pam.d/system-auth | grep sss
auth sufficient pam_sss.so forward_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so

Проверяем успешность получения информации о пользователе из AD по логину:

# getent passwd petya
petya@ad.holding.com:*:398447:200613:Петя Резинкин:/home/petya@ad.holding.com:/bin/bash

Проверяем успешность получения информации о пользователе из AD по UPN:

# getent passwd petya@ad.holding.com
petya@ad.holding.com:*:398447:200613:Петя Резинкин:/home/petya@ad.holding.com:/bin/bash

Проверяем успешность получения информации из AD о членах доменной группы безопасности:

# getent group KOM-Linux-Admins@ad.holding.com
kom-linux-admins@ad.holding.com:*:396844:petya@ad.holding.com,vova@ad.holding.com

Пробуем войти в сессию доменного пользователя:

# su - petya@ad.holding.com

Успешно войдя в сессию доменного пользователя пробуем получить информацию о текущем пользователе (должен быть возвращён набор доменных групп, в которые входит пользователь):

$ id

uid=398447(petya@ad.holding.com) gid=200613(domain users@ad.holding.com) groups=200613(domain users@ad.holding.com),445177(internet-users@ad.holding.com), 396844(kom-linux-admins@ad.holding.com)


Доступ к SUDO

Настроим доступ к возможности вызывать команду sudo, основанный на членстве в доменной группе безопасности: Создадим в каталоге /etc/sudoers.d/ новый файл, в котором будут перчислены группы безопасности:

# nano -Y sh /etc/sudoers.d/kom-linux-admins

Наполним файл (каждая отдельная группа с правилами доступа в отдельной строчке. в нашем примере используется одна группа с полным доступом):

kom-linux-admins
%KOM-Linux-Admins@ad.holding.com ALL=(ALL) ALL

Войдём в сесcию доменного пользователя, входящего в группу, которой мы разрешили выполять sudo:

# su - petya@ad.holding.com

Успешно войдя в сессию доменного пользователя пробуем выполнить любую команду с правами администратора системы используя sudo:

$ sudo whoami
[sudo] password for petya@ad.holding.com: ****** root

Как видим, работает. Осталось ограничить доступ на редактирование файла, в котором описаны правила предоставления доступа к sudo:

# chmod 0440 /etc/sudoers.d/kom-linux-admins


Настройка SSHD

Насстроим службу sshd для того, чтобы можно было использовать SSO-подключение.

# nano -Y sh /etc/ssh/sshd_config

Включим опции конфигурационного файла:

sshd_config (фрагмент)
...
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
...

Перезапустим службу:

# systemctl restart sshd


Ограничение доступа к системе через PAM

Чтобы ограничить доступ к CentOS Linux 7 на базе доменных групп безопасности, создадим новый конфигурационный файл, в котором будут перечислены группы (как локальные так и доменные), которым нужно обеспечить вход в систему:

# nano -Y sh /etc/security/access-groups-to-login
access-groups-to-login
sudo
root
KOM-Linux-Admins@ad.holding.com

Обратите внимание на то, что настраивая ограничение локального входа лучше не забыть добавить локальные группы root и sudo, иначе с дальнейшем вход в систему под локальными административными учётными записями может стать невозможен.

Ограничим доступ к файлу:

# chown root:root /etc/security/access-groups-to-login
# chmod 600 /etc/security/access-groups-to-login

Настроим в системном конфиге /etc/pam.d/login правила PAM таким образом, чтобы в ходе авторизации при локальном входе на консоль нашей Linux-системы использдвался созданный нами выше файл со списком разрешённых групп:

# nano -Y sh /etc/pam.d/login

Вставляем перед строкой «account include system-auth» вызов проверки нашего файла с группами:

login (фрагмент)
#
# Restricted access to service from local and domain groups
account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/security/access-groups-to-login
#

Внимание! Невнимательное редактирование данного файла может привести в невозможности локального входа в систему, поэтому в ходе дальнейших проверок не закрывайте текущую сесиию, чтобы была возможность исправить возможные ошибки.

Теперь попробуем подключиться на консоль нашей Linux-системы, используя доменные учётные записи (те, которым разрешен вход через группу безопасности и те, которым не разрешён вход). В процессе проверки в отдельной сессии запустим наблюдение за логом безопасности, чтобы видеть то, что происходит в ходе авторизации для разрешённых и неразрешённых для входа пользователей.

# tail -f /var/log/secure

Теперь аналогичным образом настроим в конфиге, относящемся к обработке авторизации в SSHD (/etc/pam.d/sshd) правила PAM таким образом, чтобы в ходе авторизации при удалённом входе через SSH-сервер использовался созданный нами выше файл со списком разрешённых групп (в нашем примере используется тот же файл, что и для локального входа, хотя это могут быть разные файлы и группы доступа):

# nano -Y sh /etc/pam.d/sshd

Вставляем перед строкой «account include password-auth» вызов проверки нашего файла с группами:

sshd (фрагмент)
#
# Restricted access to service from local and domain groups
account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/security/access-groups-to-login
#

Внимание! Невнимательное редактирование данного файла может привести в невозможности входа в систему через SSH-сервер, поэтому в ходе дальнейших проверок не закрывайте текущую сесиию, чтобы была возможность исправить возможные ошибки

Теперь попробуем удалённо подключиться к SSH-серверу нашей Linux-системы, используя доменные учётные записи (те, которым разрешен вход через группу безопасности и те, которым не разрешён вход). В процессе проверки в отдельной сессии запустим наблюдение за логом безопасности, чтобы видеть то, что происходит в ходе авторизации для разрешённых и неразрешённых для входа пользователей.

# tail -f /var/log/secure

Если дополнительно требуется доменная аутентификация/авторизация в других сервисах CentOS Linux, например в веб-сервере Apache то, в качестве примера можно использовать статью Настройка Kerberos аутентификации с SSO на веб-сервере Apache с помощью SSSD


Проверено на следующих конфигурациях:

Версия ОС
CentOS Linux release 7.4.1708 (Core)
CentOS Linux release 7.5.1804 (Core)

Автор первичной редакции:
Алексей Максимов
Время публикации: 22.03.2018 10:34

Обсуждение

ArturArtur, 31.05.2018 09:17
Добрый день.
ldap_idmap_default_domain_sid = S-1-5-21-2955347524-3617349964-1548486448
Что это за строка?
Алексей МаксимовАлексей Максимов, 31.05.2018 09:56
Здравствуйте, Артур.

Это SID домена, который должен использоваться по умолчанию. Полезен как в много-доменных средах, так и средах с суб-доменами. https://linux.die.net/man/5/sssd-ad
ЕрвандЕрванд, 05.06.2019 15:51
Отличная статья, большое спасибо. Все как вы пишите я сделал - в домен вошел, но почему то A запись на DNS сервер не добавилась. И не резолвится теперь имя в IP.

Как можно поправить эту беду не заходя на DNS сервер и ручками не добавляя запись?
Алексей МаксимовАлексей Максимов, 05.06.2019 16:27
Не изучал вопрос динамического обновления записей в DNS, так как у нас на Linux только серверы, а для них в нашем окружении используются только статические записи в DNS (добавления/изменения A-записей контролируется администраторами самостоятельно).
ЯрафейЯрафей, 04.09.2019 01:20
windows server dhcp -> Свойства области или IPv4 -> Служба DNS -> Динамически обновлять DNS-записи для DHCP-клиентов, не требующий обновления (например, клиентов с Windows NT 4.0)
ЕрвандЕрванд, 06.06.2019 11:22
Алексей, большое спасибо за ответ. Скорее всего что то не совсем так настроено.
Я ведь из какой логики предполагал - когда виндовую машину ввожу в домен ведь сразу все что нужно она подхватывает, сразу и пингуется по имени и даже обратная запись чудесным образом появляется. А что касается Linux приходится админов домена просить добавить. Просил их хоть глянуть может какой -то отлуп в лог записывается. Они не хотят заморачиваться.
ДмитрийДмитрий, 01.10.2019 02:01
Спасибо за интересную статью, при вводе в домен с помощью sssd и realm столкнулся с таким поведением:
При авторизации доменного пользователя, после 1-2 логинов перестает запрашиваться его пароль.
Что интересно, при использовании способа ввода в домен с помощью связки winbind + samba, пароль всегда запрашивается. Но, к сожалению, способом winbind + samba, не удалось нормально завести сервер в домен.
Можете что-либо посоветовать в сторону sssd + realm и обязательный запрос пароля пользователя.

Спасибо.
ДмитрийДмитрий, 01.10.2019 02:03
Сорри, не указал что использовал сервер на Centos 8
Алексей МаксимовАлексей Максимов, 01.10.2019 09:28, 01.10.2019 09:29
1. Пароль запрашивается не при авторизации, а при аутентификации. Это разные процедуры.
2. Не понятно, о чём вообще идёт речь. Пароль системой может запрашиваться (или не запрашиваться) в самых разных ситуациях. Правильно сформулированный вопрос содержит в себе половину ответа.
3. Всё, что описано в статье, проверялось мной исключительно на тех конфигурациях, которые указаны в конце статьи. И нет никакой гарантии того, что это будет работать на других конфигурациях без дополнительных манипуляций.
Ваш комментарий:
 
unix-linux/centos/join-centos-linux-7-4-to-active-directory-domain-with-sssd-and-realmd-for-authentication-and-configure-ad-domain-security-group-authorization-for-sudo-and-ssh-with-putty-sso.txt · Последнее изменение: 18.08.2018 21:29 — Алексей Максимов

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki