1

It is my first question on the forum, so please, don't be mad if I miss important information about my issue.

I use Debian 8 and I joined an Active Directory domain (Windows server 2012) with SSSD according to this tutorial.

Everything works well , I can login with AD account. Moreover, I created an Active directory group to gathers users who will be allowed to connect to this server.

I allow this group with the command :

realm permit -g mygroup@mydomain.com

Until now, everything is o.k. and when I connect for the first time on my Linux server with an Active directory account, the /home/domain/user is created.

However, when I want revoke permission to connect to the server for one user (so I remove the account from the group). Its folder /home/domain/user still remains on the server and moreover the root account (or account with sudo permissions) can connect to the user witch doesn't have permissions anymore (with a warning message Access Denied (ignored)).

Finally, the only way to not allow su <deleted user> is to remove the AD account (but I can't remove AD account each time that I revoke permissions).

In my opinion, it is a terrible security issue. Is it possible to definitely remove the user (and its folder) on the Linux server when I revoke the AD account permissions?

Can you share me information about authentication between AD and SSSD ?

Please see below configuration files:

Content of /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

Content of /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

Before work with SSSD, I tried to use Winbind, but I had the same issue.

Thanks for your answer.

  • Would you expect the user's home directory to be unconditionally deleted by default, even if it possibly has non-trivial content and is possibly a network mount also used from machines where the user is still legitimate? – Ulrich Schwarz Nov 22 '17 at 6:16
  • The most important for me is that I don't want that the root account (or account with root permissions) can su <deleted user> after this user is not enable to connect to the server (decided by Active directory). – L.Vasseur Nov 22 '17 at 6:46
  • 1
    @L.Vasseur, so what exactly is the issue with being able to su to a deleted/nonexisting account? Access to a local home directory and data within it? Access to a remotely mounted home directory? Access to some other external resource? What resource? – ilkkachu Nov 22 '17 at 11:20
  • For me the issue is that with the su , it can access to the local home directory or do command like wget to download files for example. – L.Vasseur Nov 27 '17 at 2:13
1

In my opinion, it is a terrible security issue.

So, you think the fact that sudo users can connect to an account on a Linux server is a security issue ? Everything the sudo user does with that account is logged accordingly, including the user that initially performed sudo.

What you could do is have a daemon polling LDAP and synchronizing the accounts. It does not even have to be on every Linux box, provided it can connect to the boxes.

EDIT: Another way to go forward is to make sure the Kerberos caches are removed; use kdestroy in /etc/bash.bash_logout. This way, the only "harm" a user can do is local, and that he could anyway, 'coz root can do anything local.

Note: This is pretty similar to Windows as well, as local admin can easily become local system, and local system can do everything on the box, including impersonate currently logged in users ... and using kdestroy at logout emulates Windows behavior.

This is why your question was a surprise to me. Worse, actually, unless you setup specific audit rules on Windows, you will not see local System impersonating users, nor who "currently controls this local system session doing stuff as jdoe".

  • Sorry for this answer so late. Indeed, I didin't know that we could find all these information in the log file. Thank you a lot. – L.Vasseur Nov 27 '17 at 2:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.