Dies ist meine erste Frage im Forum, also seien Sie bitte nicht böse, wenn ich wichtige Informationen zu meinem Problem übersehe.
Ich verwende Debian 8 und bin einer Active Directory-Domäne (Windows Server 2012) mit SSSD beigetreten gemäßdieses Tutorial.
Alles funktioniert gut, ich kann mich mit einem AD-Konto anmelden. Darüber hinaus habe ich eine Active Directory-Gruppe erstellt, um Benutzer zu sammeln, die eine Verbindung zu diesem Server herstellen dürfen.
Ich erlaube diese Gruppe mit dem Befehl:
realm permit -g [email protected]
Bis jetzt ist alles ok und wenn ich mich das erste Mal mit einem Active Directory-Konto auf meinem Linux-Server verbinde, /home/domain/userwird das erstellt.
Wenn ich jedoch einem Benutzer die Berechtigung zum Herstellen einer Verbindung mit dem Server entziehen möchte (also das Konto aus der Gruppe entferne), /home/domain/userverbleibt dessen Ordner weiterhin auf dem Server und außerdem kann sich das Root-Konto (oder Konto mit Sudo-Berechtigungen) mit dem Benutzer verbinden, der keine Berechtigungen mehr hat (mit einer Warnmeldung Access Denied (ignored)).
Die einzige Möglichkeit, die Berechtigung zu verweigern, su <deleted user>besteht darin, das AD-Konto zu entfernen (ich kann das AD-Konto jedoch nicht jedes Mal entfernen, wenn ich die Berechtigung widerrufe).
Meiner Meinung nach ist das ein schreckliches Sicherheitsproblem. Ist es möglich, den Benutzer (und seinen Ordner) auf dem Linux-Server endgültig zu entfernen, wenn ich die Berechtigungen des AD-Kontos widerrufe?
Können Sie mir Informationen zur Authentifizierung zwischen AD und SSSD geben?
Bitte sehen Sie sich die folgenden Konfigurationsdateien an:
Inhalt von /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
Inhalt von /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
Bevor ich mit SSSD gearbeitet habe, habe ich versucht, Winbind zu verwenden, aber ich hatte dasselbe Problem.
Danke für deine Antwort.
Antwort1
Meiner Meinung nach ist es ein schreckliches Sicherheitsproblem.
Sie glauben also, dass die Tatsache, dass sudoBenutzer eine Verbindung zu einem Konto auf einem Linux-Server herstellen können, ein Sicherheitsrisiko darstellt? Alles, was der sudoBenutzer mit diesem Konto tut, wird entsprechend protokolliert, einschließlich des Benutzers, der die Verbindung ursprünglich hergestellt hat sudo.
Sie könnten einen Daemon einrichten, der LDAP abfragt und die Konten synchronisiert. Er muss nicht einmal auf jeder Linux-Box installiert sein, vorausgesetzt, er kann eine Verbindung zu den Boxen herstellen.
EDIT: Eine weitere Möglichkeit, weiterzumachen, besteht darin, sicherzustellen, dass die Kerberos-Caches entfernt werden. Verwenden Sie sie kdestroyin /etc/bash.bash_logout. Auf diese Weise kann ein Benutzer nur lokalen „Schaden“ anrichten, und das könnte er sowieso, da Root alles lokal tun kann.
Hinweis: Dies ist auch bei Windows ziemlich ähnlich, da der lokale Administrator problemlos zum lokalen System werden kann und das lokale System alles auf der Box tun kann, einschließlich der Übernahme der Identität aktuell angemeldeter Benutzer … und die Verwendung kdestroybei der Abmeldung emuliert das Windows-Verhalten.
Deshalb hat mich Ihre Frage überrascht. Schlimmer noch: Sofern Sie keine speziellen Überwachungsregeln unter Windows einrichten, werden Sie weder sehen, wer sich als Benutzer imitiert, noch wer „aktuell diese lokale Systemsitzung steuert und Dinge als ... tut jdoe“.