Sudo/Domain: различия между версиями

Версия от 05:28, 5 декабря 2023

Предназначение

В доменной среде удобно размещать правила sudo не в виде отдельных файлов в /etc/sudoers.d, а хранить их в LDAP каталоге. Именно это реализовано при использовании домена на базе FreeIPA. Но и в среде AD/Samba такая же возможность присутствует и не сложна в настройке. Ниже я опишу 2 варианта конфигурации исходя из того на базе чего поднят домен.

Для того, чтобы иметь возможность хранить правила sudo в LDAP, нужно расширить текущую схему добавив класс sudoRole и его атрибуты.

Формат правил sudo

Класс sudoRole предоставляет множество опций задания правил. Самые базовые это sudoCommand, sudoHost, sudoUser. Кроме этого доступны также sudoOption, sudoRunAsUser, sudoRunAsGroup, sudoNotBefore, sudoNotAfter и т.п.

Таким образом, правило с именем run-coreutils разрешающее запускать /bin/ls, /usr/bin/cat для пользователя username1 и username2 на всех хостах без запроса пароля будет выглядеть примерно так

cn=run-coreutils,ou=sudoers,dc=test,dc=alt 
sudoCommand: /bin/ls
sudoCommand: /usr/bin/cat
sudoHost: ALL
sudoUser: username1
sudoUser: username2
sudoOption: !authenticate

Для задания имени пользователя можно использовать короткое имя (username1), длинное (username1@test.alt), числовой идентификатор (#12345678). Для группы перед именем указывается знак % - (%mygroup)

Изменение LDAP схемы

Схема LDAP для хранения правил sudo - https://github.com/sudo-project/sudo/blob/main/docs/schema.ActiveDirectory

Microsoft ActiveDirectory

Для MS AD все достаточно просто.

Скачиваем файл схемы - https://raw.githubusercontent.com/sudo-project/sudo/main/docs/schema.ActiveDirectory
В скачаном файле меняем DC=X на корень нашего домена (к примеру, DC=test,DC=alt)
В консоли с правами доменного администратора, втягиваем схему командой

ldifde -i -f schema.ActiveDirectory -c "CN=Schema,CN=Configuration,DC=X" #schemaNamingContext

Для хранения правил рекомендуется создать подразделение OU=sudoers,DC=вашпуть

Для непосредственного создания правил, на стороне MS нужно использовать инструмент Редактирование ADSI в котором нужно создать объект класса sudoRole с соответствующими атрибутами.

Samba DC

Не смотря на всю схожесть с AD, конфигурация данного решения требует некоторых корректив.

Для начала скачаем файл схемы

[root@dc ~]#  wget  https://raw.githubusercontent.com/sudo-project/sudo/main/docs/schema.ActiveDirectory

Желательно привести его "внутренний мир" к *nix стандарту

[root@dc ~]# dos2unix schema.ActiveDirectory

Заменим DC=X на реальный путь, в нашем случае DC=test,DC=alt

sed -i 's/DC=X/DC=test,DC=alt/g' schema.ActiveDirectory

Теперь необходимо исходный файл разделить на две части

[root@dc ~]#  head -$(grep -B1 -n '^dn:$' schema.ActiveDirectory | head -1 | grep -oP '\d+') schema.ActiveDirectory > first.ldif

[root@dc ~]#  tail +$(grep -B1 -n '^dn:$' schema.ActiveDirectory | head -1 | grep -oP '\d+') schema.ActiveDirectory | sed '/^-/d' > second.ldif

После чего ~~сделать бэкап/снапшот ВМ~~, применить изменения схемы

[root@dc ~]# ldbadd -H /var/lib/samba/private/sam.ldb first.ldif --option="dsdb:schema update allowed"=true
Added 10 records successfully
[root@dc ~]# ldbmodify -v -H /var/lib/samba/private/sam.ldb second.ldif --option="dsdb:schema update allowed"=true
Modified 
Modified CN=sudoRole,CN=Schema,CN=Configuration,DC=test,DC=alt
Modified 2 records successfully

Схема расширена, класс с атрибутами добавлен.

Создадим подразделение, для хранения правил

[root@dc ~]# samba-tool ou add 'ou=sudoers'

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

Создадим его. Из полей все ясно, что к чему

dn: CN=run-apt,OU=sudoers,DC=test,DC=alt
changetype: add
objectClass: top
objectClass: sudoRole
cn: run-apt
name: run-apt
sudoUser: domainuser1
sudoHost: ALL
sudoCommand: /usr/bin/apt-get

Импортируем это правило

[root@dc ~]# ldbadd -H /var/lib/samba/private/sam.ldb sudoRole-object.ldif
Added 1 records successfully

Можно проверить с помощью ldapsearch

[user@dc /tmp]$ ldapsearch -LLL -Y GSSAPI -h localhost -b ou=sudoers,dc=test,dc=alt '(cn=run-apt)' 
SASL/GSSAPI authentication started
SASL username: da-01@TEST.ALT
SASL SSF: 56
SASL data security layer installed.
dn: CN=run-apt,OU=sudoers,DC=test,DC=alt
objectClass: top 
objectClass: sudoRole
cn: run-apt
instanceType: 4
whenCreated: 20231130073526.0Z
uSNCreated: 10579
name: run-apt
objectGUID:: 3KvR7QAQOkONbk8ZV5F23g==
objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=test,DC=alt
sudoUser: domainuser1
sudoHost: ALL
sudoCommand: /usr/bin/apt-get
whenChanged: 20231130111213.0Z
uSNChanged: 10623
distinguishedName: CN=run-apt,OU=sudoers,DC=test,DC=alt

Редактировать правила, можно теперь и в admc

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

Для того чтобы правила sudo из LDAP можно было использовать нужно установить пакет libsss_sudo

apt-get update; apt-get install libsss_sudo

Сконфигурировать службу sssd (/etc/sssd/sssd.conf)

[sssd]
services = nss,pam,sudo
....
[domain/TEST.ALT]
sudo_provider = ad
#ad_sudo_search_base не обязателен если вместо samba используется ms ad 
ad_sudo_search_base = ou=sudoers,dc=test,dc=alt

Добавить в /etc/nsswitch.conf

sudoers: files sss

Примечания

Все это работает при использовании sssd. В случае использования winbind, вероятно, придется пересобирать sudo с поддержкой ldap (получив в награду небезопасное решение).

Ссылки по теме