Sudo/Domain: различия между версиями
мНет описания правки |
м (→Ссылки по теме) |
||
(не показано 29 промежуточных версий этого же участника) | |||
Строка 1: | Строка 1: | ||
{{DISPLAYTITLE:Управление правилами sudo в доменной (AD/Samba) среде}} | {{DISPLAYTITLE:Управление правилами sudo в доменной (AD/Samba) среде}} | ||
Строка 4: | Строка 5: | ||
В доменной среде удобно размещать правила sudo не в виде отдельных файлов в /etc/sudoers.d, а хранить их в LDAP каталоге. Именно это реализовано при использовании домена на базе FreeIPA. Но и в среде AD/Samba такая же возможность присутствует и не сложна в настройке. Ниже я опишу 2 варианта конфигурации исходя из того на базе чего поднят домен. | В доменной среде удобно размещать правила sudo не в виде отдельных файлов в /etc/sudoers.d, а хранить их в LDAP каталоге. Именно это реализовано при использовании домена на базе FreeIPA. Но и в среде AD/Samba такая же возможность присутствует и не сложна в настройке. Ниже я опишу 2 варианта конфигурации исходя из того на базе чего поднят домен. | ||
== Microsoft ActiveDirectory == | Для того, чтобы иметь возможность хранить правила sudo в LDAP, нужно расширить текущую схему добавив класс sudoRole и его атрибуты. | ||
== Формат правил sudo == | |||
Класс sudoRole предоставляет множество опций задания правил. Самые базовые это <tt>sudoCommand</tt>, <tt>sudoHost</tt>, <tt>sudoUser</tt>. Кроме этого доступны также <tt>sudoOption</tt>, <tt>sudoRunAsUser</tt>, <tt>sudoRunAsGroup</tt>, <tt>sudoNotBefore</tt>, <tt>sudoNotAfter</tt> и т.п. | |||
Таким образом, правило с именем 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 | |||
Для задания имени пользователя можно использовать короткое имя (<tt>username1</tt>), длинное (<tt>username1@test.alt</tt>), числовой идентификатор (<tt>#12345678</tt>). Для группы перед именем указывается знак <tt>%</tt> - (<tt>%mygroup</tt>) | |||
== Изменение 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=test,DC=alt" #schemaNamingContext | |||
Для хранения правил рекомендуется создать подразделение <tt>OU=sudoers,DC=test,DC=alt</tt> | |||
Для непосредственного создания правил, на стороне MS нужно использовать инструмент '''Редактирование ADSI''' в котором нужно создать объект класса <tt>sudoRole</tt> с соответствующими атрибутами. | |||
[[File:Adsi_sudoRole.png]] | |||
=== 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 из шаблона схемы на реальный путь, в нашем случае <tt>DC=test,DC=alt</tt> | |||
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 | |||
После чего <strike>сделать бэкап/снапшот ВМ</strike>, применить изменения схемы | |||
[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 | |||
Схема расширена, класс с атрибутами добавлен. | |||
==== Создание правил sudo ==== | |||
Создадим подразделение, для хранения правил | |||
[root@dc ~]# samba-tool ou add 'ou=sudoers' | |||
Теперь нужно создать само правило. На текущий момент нативных графических или консольных инструментов для этого не найдено, предлагаю делать через ldif файл. | |||
Создадим текстовый файл <tt>sudoRole-object.ldif</tt>. Из полей все ясно, что к чему | |||
== | 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 | |||
Более правильно, для дальнейшей эксплуатации, делать правила не для конкретных пользователей, а для групп т.е. правило будет выглядеть вот так | |||
dn: CN=run-apt,OU=sudoers,DC=test,DC=alt | |||
changetype: add | |||
objectClass: top | |||
objectClass: sudoRole | |||
cn: run-apt | |||
name: run-apt | |||
sudoUser: %apt_users | |||
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]] | |||
[[File:Admc-sudorole.png|750px]] | |||
На этом можно было бы закончить, если бы не одна проблема. | |||
На вновь созданные правила установлены неверные атрибуты, и <tt>sssd</tt> не сможет их найти и получить. | |||
Атрибуты задаются в формате SDDL, и выглядят примерно так | |||
[root@dc user]# samba-tool dsacl get --objectdn='CN=run-apt,OU=sudoers,DC=test,DC=alt' | |||
descriptor for CN=run-apt2,OU=sudoers,DC=test,DC=alt: | |||
O:DAG:DAD:AI(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a86-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RPLCLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIID;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)(A;CIID;LC;;;RU)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)S:AI(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) | |||
Не очень читабельно для человека. Нам нужно добавить два разрешения которые тут отсутствуют. | |||
Прямой и очевидный путь говорит нам использовать <tt>samba-tool dsacl set ... </tt>, но увы это не работает. | |||
Идем обходным путем, меняя атрибут <tt>ntSecurityDescriptor</tt>, для чего последовательно выполняем нижеприведенные команды | |||
[root@dc user]# echo -e "dn: CN=run-apt,OU=sudoers,DC=test,DC=alt\nchangetype: modify\nreplace: nTSecurityDescriptor" > ntGen.ldif | |||
[root@dc user]# ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b 'CN=run-apt,OU=sudoers,DC=test,DC=alt' 'nTSecurityDescriptor' | sed -n '/^#/d;s/O:DAG:DAD:AI/O:DAG:DAD:AI\(A\;\;RPLCRC\;\;\;AU\)\(A\;\;RPWPCRCCDCLCLORCWOWDSDDTSW\;\;\;SY\)/;3,$p' | sed ':a;N;$!ba;s/\n\s//g' | sed -e 's/.\{78\}/&\n /g' >> ntGen.ldif | |||
Получили новый атрибут в файл ntGen.ldif | |||
[root@dc user]# cat ntGen.ldif | |||
dn: CN=run-apt,OU=sudoers,DC=test,DC=alt | |||
changetype: modify | |||
replace: nTSecurityDescriptor | |||
nTSecurityDescriptor: O:DAG:DAD:AI(A;;RPLCRC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDT | |||
SW;;;SY)(A;;RPLCRC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(OA;CIIOID;RP;4c16 | |||
4200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;C | |||
IIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa0030 | |||
49e2;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc- | |||
9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967a | |||
ba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04f | |||
c2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d | |||
0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;59ba | |||
2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;C | |||
IIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa0030 | |||
49e2;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc- | |||
9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967a | |||
ba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c9 | |||
83f608;bf967a86-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d | |||
2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c6 | |||
9e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)(OA;C | |||
IIOID;RPLCLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RPLCLORC;;b | |||
f967a9c-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RPLCLORC;;bf967aba-0de6-11d0 | |||
-a285-00aa003049e2;RU)(OA;CIID;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS | |||
)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)(A;CIID;LC;;;RU)(A;CIID;RPWPCRCCLCLOR | |||
CWOWDSDSW;;;BA)S:AI(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967a | |||
a5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000 | |||
f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) | |||
Осталось его применить | |||
[root@dc user]# ldbmodify -v -H /var/lib/samba/private/sam.ldb ntGen.ldif | |||
Modified CN=run-apt,OU=sudoers,DC=test,DC=alt | |||
Modified 1 records successfully | |||
{{Note|При наличии графики, атрибуты можно выставить и в ADMC. Добавить 2 ''известных доверенных лица''. | |||
[[File:Sddl 1.png|600px]] | |||
[[File:Sddl 2.png|600px]]}} | |||
И переходить к настройке клиентской части т.е. непосредственно службы <tt>sssd</tt> | |||
== Настройка клиентской части == | |||
* Для того чтобы правила 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 | |||
#ldap_sudo_search_base не обязателен если вместо samba используется ms ad | |||
ldap_sudo_search_base = ou=sudoers,dc=test,dc=alt | |||
* Добавить в /etc/nsswitch.conf | |||
sudoers: files sss | |||
Кроме всего прочего можно гибко менять пути поиска правил, таймайты и прочее. | |||
Подробная информация - <tt>man sssd-sudo</tt> | |||
== Отладка == | |||
чуть позже.. | |||
== Примечания == | == Примечания == | ||
Все это работает при использовании sssd. В случае использования winbind, вероятно, придется | Все это работает при использовании <tt>sssd</tt>. В случае использования <tt>winbind</tt>, вероятно, придется пересобирать <tt>sudo</tt> с поддержкой <tt>ldap</tt> (получив в награду небезопасное решение). | ||
Очень надеюсь на расширение функционала [[ADMC]] в плане создания произвольных объектов с произвольным <tt>ObjectClass</tt> | |||
== Может быть интересно == | |||
По мотивам статьи создан пакет, с текстовым интерфейсом для расширения схемы и создания правил. | |||
<gallery> | |||
Sudo-samba-schema1.jpeg|Sudo-samba-schema | |||
Sudo-samba-schema2.jpeg|Sudo-samba-schema | |||
Sudo-samba-schema3.jpeg|Sudo-samba-schema | |||
Sudo-samba-schema4.jpeg|Sudo-samba-schema | |||
</gallery> | |||
Пакет доступен по ссылке http://altrepo.ru/local-p10/noarch/RPMS.local-p10/sudo-samba-schema-1.0-alt1.noarch.rpm | |||
== Ссылки по теме == | == Ссылки по теме == | ||
https://learn.microsoft.com/ru-ru/windows/win32/secauthz/sid-strings | # https://github.com/sudo-project/sudo/blob/main/docs/schema.ActiveDirectory | ||
https://learn.microsoft.com/ru-ru/windows/win32/secauthz/security-descriptor-string-format | # https://learn.microsoft.com/ru-ru/windows/win32/secauthz/sid-strings | ||
https://learn.microsoft.com/ru-ru/windows/win32/secauthz/security-descriptor-definition-language-for-conditional-aces- | # https://learn.microsoft.com/ru-ru/windows/win32/secauthz/security-descriptor-string-format | ||
# https://learn.microsoft.com/ru-ru/windows/win32/secauthz/security-descriptor-definition-language-for-conditional-aces- | |||
== Ссылки не совсем по теме == | |||
[[Ssh/Domain]] |
Текущая версия от 14:14, 25 сентября 2024
Предназначение
В доменной среде удобно размещать правила 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=test,DC=alt" #schemaNamingContext
Для хранения правил рекомендуется создать подразделение OU=sudoers,DC=test,DC=alt
Для непосредственного создания правил, на стороне 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
Схема расширена, класс с атрибутами добавлен.
Создание правил sudo
Создадим подразделение, для хранения правил
[root@dc ~]# samba-tool ou add 'ou=sudoers'
Теперь нужно создать само правило. На текущий момент нативных графических или консольных инструментов для этого не найдено, предлагаю делать через ldif файл.
Создадим текстовый файл sudoRole-object.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
Более правильно, для дальнейшей эксплуатации, делать правила не для конкретных пользователей, а для групп т.е. правило будет выглядеть вот так
dn: CN=run-apt,OU=sudoers,DC=test,DC=alt changetype: add objectClass: top objectClass: sudoRole cn: run-apt name: run-apt sudoUser: %apt_users 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
На этом можно было бы закончить, если бы не одна проблема.
На вновь созданные правила установлены неверные атрибуты, и sssd не сможет их найти и получить.
Атрибуты задаются в формате SDDL, и выглядят примерно так
[root@dc user]# samba-tool dsacl get --objectdn='CN=run-apt,OU=sudoers,DC=test,DC=alt'
descriptor for CN=run-apt2,OU=sudoers,DC=test,DC=alt: O:DAG:DAD:AI(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a86-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RPLCLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIID;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)(A;CIID;LC;;;RU)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)S:AI(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
Не очень читабельно для человека. Нам нужно добавить два разрешения которые тут отсутствуют. Прямой и очевидный путь говорит нам использовать samba-tool dsacl set ... , но увы это не работает. Идем обходным путем, меняя атрибут ntSecurityDescriptor, для чего последовательно выполняем нижеприведенные команды
[root@dc user]# echo -e "dn: CN=run-apt,OU=sudoers,DC=test,DC=alt\nchangetype: modify\nreplace: nTSecurityDescriptor" > ntGen.ldif [root@dc user]# ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b 'CN=run-apt,OU=sudoers,DC=test,DC=alt' 'nTSecurityDescriptor' | sed -n '/^#/d;s/O:DAG:DAD:AI/O:DAG:DAD:AI\(A\;\;RPLCRC\;\;\;AU\)\(A\;\;RPWPCRCCDCLCLORCWOWDSDDTSW\;\;\;SY\)/;3,$p' | sed ':a;N;$!ba;s/\n\s//g' | sed -e 's/.\{78\}/&\n /g' >> ntGen.ldif
Получили новый атрибут в файл ntGen.ldif
[root@dc user]# cat ntGen.ldif dn: CN=run-apt,OU=sudoers,DC=test,DC=alt changetype: modify replace: nTSecurityDescriptor nTSecurityDescriptor: O:DAG:DAD:AI(A;;RPLCRC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDT SW;;;SY)(A;;RPLCRC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(OA;CIIOID;RP;4c16 4200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;C IIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa0030 49e2;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc- 9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967a ba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04f c2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d 0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;59ba 2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;C IIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa0030 49e2;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc- 9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967a ba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c9 83f608;bf967a86-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d 2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c6 9e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)(OA;C IIOID;RPLCLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RPLCLORC;;b f967a9c-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RPLCLORC;;bf967aba-0de6-11d0 -a285-00aa003049e2;RU)(OA;CIID;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS )(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)(A;CIID;LC;;;RU)(A;CIID;RPWPCRCCLCLOR CWOWDSDSW;;;BA)S:AI(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967a a5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000 f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
Осталось его применить
[root@dc user]# ldbmodify -v -H /var/lib/samba/private/sam.ldb ntGen.ldif Modified CN=run-apt,OU=sudoers,DC=test,DC=alt Modified 1 records successfully
И переходить к настройке клиентской части т.е. непосредственно службы sssd
Настройка клиентской части
- Для того чтобы правила 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 #ldap_sudo_search_base не обязателен если вместо samba используется ms ad ldap_sudo_search_base = ou=sudoers,dc=test,dc=alt
- Добавить в /etc/nsswitch.conf
sudoers: files sss
Кроме всего прочего можно гибко менять пути поиска правил, таймайты и прочее. Подробная информация - man sssd-sudo
Отладка
чуть позже..
Примечания
Все это работает при использовании sssd. В случае использования winbind, вероятно, придется пересобирать sudo с поддержкой ldap (получив в награду небезопасное решение).
Очень надеюсь на расширение функционала ADMC в плане создания произвольных объектов с произвольным ObjectClass
Может быть интересно
По мотивам статьи создан пакет, с текстовым интерфейсом для расширения схемы и создания правил.
Пакет доступен по ссылке http://altrepo.ru/local-p10/noarch/RPMS.local-p10/sudo-samba-schema-1.0-alt1.noarch.rpm
Ссылки по теме
- https://github.com/sudo-project/sudo/blob/main/docs/schema.ActiveDirectory
- https://learn.microsoft.com/ru-ru/windows/win32/secauthz/sid-strings
- https://learn.microsoft.com/ru-ru/windows/win32/secauthz/security-descriptor-string-format
- https://learn.microsoft.com/ru-ru/windows/win32/secauthz/security-descriptor-definition-language-for-conditional-aces-