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

Материал из ALT Linux Wiki
мНет описания правки
 
(не показано 8 промежуточных версий этого же участника)
Строка 30: Строка 30:
Для MS AD все достаточно просто.
Для MS AD все достаточно просто.
# Скачиваем файл схемы - https://raw.githubusercontent.com/sudo-project/sudo/main/docs/schema.ActiveDirectory
# Скачиваем файл схемы - https://raw.githubusercontent.com/sudo-project/sudo/main/docs/schema.ActiveDirectory
# В скачаном файле меняем DC=X на корень нашего домена (к примеру, DC=test,DC=alt)
# В скачаном файле меняем '''DC=X''' на корень нашего домена (к примеру, '''DC=test,DC=alt''')
# В консоли с правами доменного администратора, втягиваем схему командой  
# В консоли с правами доменного администратора, втягиваем схему командой  
  ldifde -i -f schema.ActiveDirectory -c "CN=Schema,CN=Configuration,DC=X" #schemaNamingContext
  ldifde -i -f schema.ActiveDirectory -c "CN=Schema,CN=Configuration,DC=test,DC=alt" #schemaNamingContext


Для хранения правил рекомендуется создать подразделение <tt>OU=sudoers,DC=вашпуть</tt>
Для хранения правил рекомендуется создать подразделение <tt>OU=sudoers,DC=test,DC=alt</tt>
   
   
Для непосредственного создания правил, на стороне MS нужно использовать инструмент ''Редактирование ADSI'' в котором нужно создать объект класса sudoRole с соответствующими атрибутами.
Для непосредственного создания правил, на стороне MS нужно использовать инструмент '''Редактирование ADSI''' в котором нужно создать объект класса <tt>sudoRole</tt> с соответствующими атрибутами.
 
[[File:Adsi_sudoRole.png]]


=== Samba DC ===
=== Samba DC ===
Строка 58: Строка 60:
  [root@dc ~]# ldbadd -H /var/lib/samba/private/sam.ldb first.ldif --option="dsdb:schema update allowed"=true
  [root@dc ~]# ldbadd -H /var/lib/samba/private/sam.ldb first.ldif --option="dsdb:schema update allowed"=true
  Added 10 records successfully
  Added 10 records successfully
 
  [root@dc ~]# ldbmodify -v -H /var/lib/samba/private/sam.ldb second.ldif --option="dsdb:schema update allowed"=true
  [root@dc ~]# ldbmodify -v -H /var/lib/samba/private/sam.ldb second.ldif --option="dsdb:schema update allowed"=true
  Modified  
  Modified  
Строка 72: Строка 74:
  [root@dc ~]# samba-tool ou add 'ou=sudoers'
  [root@dc ~]# samba-tool ou add 'ou=sudoers'


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


Создадим текстовый файл <tt>sudoRole-object.ldif</tt>. Из полей все ясно, что к чему
Создадим текстовый файл <tt>sudoRole-object.ldif</tt>. Из полей все ясно, что к чему
Строка 129: Строка 131:
Редактировать правила, можно теперь и в [[admc]]
Редактировать правила, можно теперь и в [[admc]]


[[File:Admc-sudorole.png|700px]]
[[File:Admc-sudorole.png|750px]]


На этом можно было бы закончить, если бы не одна проблема.  
На этом можно было бы закончить, если бы не одна проблема.  


На вновь созданные правила установлены неверные атрибуты, и sssd не сможет их найти и получить.  
На вновь созданные правила установлены неверные атрибуты, и <tt>sssd</tt> не сможет их найти и получить.  


Атрибуты задаются в формате SDDL, и выглядят примерно так
Атрибуты задаются в формате SDDL, и выглядят примерно так
Строка 144: Строка 146:
Не очень читабельно для человека. Нам нужно добавить два разрешения которые тут отсутствуют.
Не очень читабельно для человека. Нам нужно добавить два разрешения которые тут отсутствуют.
Прямой и очевидный путь говорит нам использовать <tt>samba-tool dsacl set ... </tt>, но увы это не работает.
Прямой и очевидный путь говорит нам использовать <tt>samba-tool dsacl set ... </tt>, но увы это не работает.
Идем обходным путем, меняя атрибут ntSecurityDescriptor последовательно выполняя нижеприведенные команды
Идем обходным путем, меняя атрибут <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]# echo -e "dn: CN=run-apt,OU=sudoers,DC=test,DC=alt\nchangetype: modify\nreplace: nTSecurityDescriptor" > ntGen.ldif  
Строка 186: Строка 188:
  Modified 1 records successfully
  Modified 1 records successfully


И переходить к настройке клиентской части т.е. непосредственно службы sssd
{{Note|При наличии графики, атрибуты можно выставить и в ADMC. Добавить 2 ''известных доверенных лица''.
[[File:Sddl 1.png|600px]]
[[File:Sddl 2.png|600px]]}}
 
И переходить к настройке клиентской части т.е. непосредственно службы <tt>sssd</tt>


== Настройка клиентской части ==
== Настройка клиентской части ==
Строка 198: Строка 204:
  [domain/TEST.ALT]
  [domain/TEST.ALT]
  sudo_provider = ad
  sudo_provider = ad
  #ad_sudo_search_base не обязателен если вместо samba используется ms ad  
  #ldap_sudo_search_base не обязателен если вместо samba используется ms ad  
  ad_sudo_search_base = ou=sudoers,dc=test,dc=alt
  ldap_sudo_search_base = ou=sudoers,dc=test,dc=alt


* Добавить в /etc/nsswitch.conf
* Добавить в /etc/nsswitch.conf
Строка 212: Строка 218:
   
   
== Примечания ==
== Примечания ==
Все это работает при использовании sssd. В случае использования winbind, вероятно, придется пересобирать sudo с поддержкой ldap (получив в награду небезопасное решение).
Все это работает при использовании <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>


Очень надеюсь на расширение функционала ADMC в плане создания произвольных объектов с произвольным ObjectClass
Пакет доступен по ссылке http://altrepo.ru/local-p10/noarch/RPMS.local-p10/sudo-samba-schema-1.0-alt1.noarch.rpm


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

Текущая версия от 11:26, 11 апреля 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 все достаточно просто.

  1. Скачиваем файл схемы - https://raw.githubusercontent.com/sudo-project/sudo/main/docs/schema.ActiveDirectory
  2. В скачаном файле меняем DC=X на корень нашего домена (к примеру, DC=test,DC=alt)
  3. В консоли с правами доменного администратора, втягиваем схему командой
ldifde -i -f schema.ActiveDirectory -c "CN=Schema,CN=Configuration,DC=test,DC=alt" #schemaNamingContext

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

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

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 из шаблона схемы на реальный путь, в нашем случае 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

Admc-sudorole.png

На этом можно было бы закончить, если бы не одна проблема.

На вновь созданные правила установлены неверные атрибуты, и 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
Примечание: При наличии графики, атрибуты можно выставить и в ADMC. Добавить 2 известных доверенных лица.

Sddl 1.png

Sddl 2.png


И переходить к настройке клиентской части т.е. непосредственно службы 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

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

  1. https://github.com/sudo-project/sudo/blob/main/docs/schema.ActiveDirectory
  2. https://learn.microsoft.com/ru-ru/windows/win32/secauthz/sid-strings
  3. https://learn.microsoft.com/ru-ru/windows/win32/secauthz/security-descriptor-string-format
  4. https://learn.microsoft.com/ru-ru/windows/win32/secauthz/security-descriptor-definition-language-for-conditional-aces-