☰

SSSD удалить пользователей

tag-icon • tag-icon debian users active-directory domain sssd
SSSD удалить пользователей

Это мой первый вопрос на форуме, поэтому, пожалуйста, не сердитесь, если я пропущу важную информацию по своей проблеме.

Я использую Debian 8 и присоединился к домену Active Directory (Windows Server 2012) с помощью SSSD согласноэтот урок.

Все работает хорошо, я могу войти с учетной записью AD. Более того, я создал группу Active Directory для сбора пользователей, которым будет разрешено подключаться к этому серверу.

Я разрешаю эту группу с помощью команды:

realm permit -g [email protected]

До сих пор все было в порядке, и когда я впервые подключаюсь к своему серверу Linux с помощью учетной записи Active Directory, /home/domain/userсоздается файл.

Однако, когда я хочу отозвать разрешение на подключение к серверу для одного пользователя (поэтому я удаляю учетную запись из группы), ее папка /home/domain/userвсе равно остается на сервере, и, более того, учетная запись root (или учетная запись с правами sudo) может подключиться к пользователю, у которого больше нет разрешений (с предупреждающим сообщением Access Denied (ignored)).

Наконец, единственный способ запретить доступ su <deleted user>— удалить учетную запись AD (но я не могу удалять учетную запись AD каждый раз, когда отзываю разрешения).

По-моему, это ужасная проблема безопасности. Возможно ли окончательно удалить пользователя (и его папку) на сервере Linux, когда я отзываю разрешения учетной записи AD?

Можете ли вы поделиться информацией об аутентификации между AD и SSSD?

Ниже приведены файлы конфигурации:

Содержание /etc/nsswitch.conf:

passwd:         compat sss
group:          compat sss
shadow:         compat sss
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files

netgroup:       nis sss
sudoers:        files sss

Содержание /etc/sssd/sssd.conf:

[sssd]
domains = mydomain.com
config_file_version = 2
services = nss, pam

[domain/mydomain.com]
ad_domain = mydomain.com
krb5_realm = MYREALM.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
access_provider = simple
simple_allow_groups = MyGroupAllowed

До работы с SSSD я пробовал использовать Winbind, но у меня возникла та же проблема.

Спасибо за Ваш ответ.

решение1

По моему мнению, это ужасная проблема безопасности.

Итак, вы считаете, что тот факт, что sudoпользователи могут подключаться к учетной записи на сервере Linux, является проблемой безопасности? Все, что sudoпользователь делает с этой учетной записью, соответствующим образом регистрируется, включая пользователя, который изначально выполнил sudo.

Что вы могли бы сделать, так это иметь демона, опрашивающего LDAP и синхронизирующего учетные записи. Он даже не обязательно должен быть на каждом Linux-ящике, при условии, что он может подключаться к ящикам.

EDIT: Другой способ двигаться вперед — убедиться, что кэши Kerberos удалены; использовать kdestroyв /etc/bash.bash_logout. Таким образом, единственный «вред», который может нанести пользователь, будет локальным, и он это сделает в любом случае, потому что root может сделать все что угодно локально.

Примечание: Это также очень похоже на Windows, поскольку локальный администратор может легко стать локальной системой, а локальная система может делать все на компьютере, включая выдачу себя за пользователей, вошедших в систему... а использование kdestroyпри выходе из системы эмулирует поведение Windows.

Вот почему ваш вопрос стал для меня сюрпризом. Хуже того, если вы не настроите специальные правила аудита в Windows, вы не увидите, как локальная система выдает себя за пользователей, и кто «в настоящее время управляет этим сеансом локальной системы, делая что-то как jdoe».

Связанный контент