
Это мой первый вопрос на форуме, поэтому, пожалуйста, не сердитесь, если я пропущу важную информацию по своей проблеме.
Я использую 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
».