Univention Bugzilla – Bug 20138
Normalen Benutzern den Zugriff auf Domänencontroller verweigern
Last modified: 2023-09-07 15:01:55 CEST
Standardmässig kann sich jeder UCS-Benutzer auf jedem Domänencontroller anmelden. Ich denke es wäre sinnvoll mittelfristig in der Grundeinstellung die Anmeldung per SSH und lokal nur noch für root und die Mitglieder der Gruppe "Domain Admins" zu erlauben. Das ganze könnte per UCR konfigurierbar sein, so dass etwa auf UCS-Terminalservern die Anmeldung wieder erlaubt wird. Dies macht es deutlich schwieriger einen lokalen root-Exploit auszunutzen.
Bitte auch direkt univention-pam übernehmen.
univention-pam nach 3.0 übernommen
Ziel: Benutzern Zugriff per ssh auf DomainController verhindern. Es müssen aber ,z.B. für den Join von Rechnern, spezielle Gruppen weiterhin Zugriff haben (Computers). Es gibt bereits die Möglichkeit den ssh Zugriff auf "Admin" Benutzer einzuschränken -> auth/admin/services (es wird dann für das Modul "admin-account" mit der Access Konfiguration "access-admin.conf" verwendet). Dann haben jedoch die Rechner-Gruppen keinen Zugriff mehr und das Joinen schlägt fehl. Die Rechner-Gruppen kann man aber auch nicht in die allgemeine "access-admin.conf" eintragen, da dies dann für alle Dienste aktiv wäre. Variante 1 Wir geben eine "auth/sshd/accessfile" Datei vor, die den Zugriff für die Rechner-Gruppen erlaubt. Diese Datei wird unabhängig von auth/admin/services bzw. auth/user/services eingebunden. Dann braucht man aber wieder eine extra Konfiguration für das default "auth/sshd/accessfile", es soll ja weiterhin die Möglichkeit geben, Benutzern den Zugriff per ssh zu erlauben. Außerdem wäre dann die ssh Einstellung in auth/admin/services bzw. auth/user/services sinnlos. Variante 2 Für den ssh Dienst wird im "Admin Modus" eine eigene "admin-account" mit einer eigenen "access-admin.conf" verwendet, die dann den Zugriff für Administratoren und Rechner-Gruppen zulässt. Das hätte den Vorteil, dass weiterhin "auth/admin/services" bzw. "auth/user/services" verwendet werden könnte. In normalen Modus darf jeder ssh verwenden, im "Admin" Modus dann alle Administratoren und Rechner. Alle anderen Dienste verwenden aber weiterhin die Standard "admin-account" Konfiguration. Nachteil hier: Eigenes Pam Konfiguration/anderes Template für den ssh Dienst. Variante 3 ...
Vielleicht schmeißt man diese PAM admin/common Konfiguration für die Dienste auch komplett weg und macht alles über UCR pam/ssh/allow pam/ssh/deny pam/ftp/... pam/login/... ...
Wir sollten hier den generischen Ansatz umsetzen: Beispiele: # nur root und Domain Admins und DC Backup Hosts dürfen sich per ssh anmelden auth/ssh/restrict=yes auth/ssh/user/root=allow auth/ssh/group/Domain Admins=allow auth/ssh/group/DC Backup Hosts=allow # am GDM dürfen sich alle anmelden, access.conf-Datei wird in diesem Fall nicht eingebunden auth/gdm/restrict=no # per login darf sich nur root anmelden auth/login/restrict=yes auth/login/user/root=yes Somit kann man einfach Gruppen den Zugriff erlauben bzw. verwehren und kann auch ganz einfach die Limitierung für einen Dienst global an- / abschalten.
Es soll nur noch ein PAM Schema common-* geben, admin-* und deny-* entfällt. Es gab ein paar kleinere Unterschiede zw. common- und admin- die nun in common- zusammengeführt wurden: Aus admin-* nach common-* übernommene Änderungen: * + auth requisite pam_securetty.so in common-auth * + default "die" anstatt "bad" in auth [default=die] pam_runasroot.so program=/usr/lib/univention-pam/lock-user in common-auth ("die" war default in admin.auth) * + minlen=8 in password requisite pam_cracklib.so minlen=8 in common-password (wurde in admin-password gesetzt) Nicht übernommene Änderungen: * - für pam_krb5, pam_ldap und pam_winbind in common-auth ist der default wie bisher "<unknown>", nicht "<fail>" wie in admin-auth * - die winbind und krb5 session wurde in admin-session nicht verwendet, bleibt aber in common-session
aus auth/admin/methods und auth/user/methods wird auth/methods
minlen=8 in common-password entfällt (war nur für root, andere Benutzer bekommen die Passwort-Richtlinie der Domäne).
auth requisite pam_securetty.so in common-auth entfällt auch erstmal, da sich sonst root nicht per ssh anmelden kann. /etc/securetty ist i.M. noch kein Template, sodass dort erst händisch ssh aufgenommen werden müsste. Falls dies irgendwann ein Template wird und ssh dort standardmäßig aktiviert wird, könnte man pam_securetty.so in common-auth wieder aufnehmen.
Alle (PAM) Dienste verwenden nun die common-* Dateien. Außerdem wird eine pam_access Konfiguration eingebunden, falls auth/DIENST/restrict gesetzt ist. Damit wird dann erstmal alles verboten. Mit auth/DIENST/group/GRUPPE=yes, auth/DIENST/user/USER=yes und auth/DIENST/accessfile kann man das verhalten dann anpassen. Die Defaults wurden soweit aus 2.4 übernommen, außer bei sshd und login. Dies dürfen nun nur noch "Administrators", "Domain Admins", "root" und bei sshd "Computers" (domain join) verwenden. Die Variablen auth/user/services und auth/admin/services gibt es nicht mehr. auth/user/methods und auth/admin/methods sind zu auth/methods zusammengeführt. Es sind nun noch weitere Pakete anzupassen, die PAM Einstellungen setzen/erzeugen.
In univention-server debian/univention-mobile-client.postinst, debian/univention-managed-client.postinst und check_connection entsprechend abgepasst.
PAM Konfig Template in univention-management-console angepasst (auth/user/methods -> auth/methods).
Auf domaincontroller* Rechnern wird sshd nun per univention-config-registry set \ auth/sshd/restrict?"yes" \ "auth/sshd/group/Domain Admins?yes" \ auth/sshd/group/Computers?"yes" \ auth/sshd/group/Administrators?"yes" \ auth/sshd/user/root?"yes" auf Admins beschränkt. Auf Terminalservern muss dann auth/sshd/restrict entsprechend auf no gesetzt werden. Es sollte ausführliche Hinweise in den Release Notes geben. Changelog Eintrag vorhanden.
Wie ist die Migration beim Update von den alten UCRV auth/user/services auf die neuen UCRV zu lösen? (Automatisch im postinst, oder manuell? Im univention-pam oder in jedem Paket einzeln?)
(In reply to comment #14) > Wie ist die Migration beim Update von den alten UCRV auth/user/services auf die > neuen UCRV zu lösen? (Automatisch im postinst, oder manuell? Im univention-pam > oder in jedem Paket einzeln?) Am besten in univention-lib. Für die Migration von UCR-Variablen hatte ich bereits 22611 angelegt. Das werden wir auch in mehreren anderen 3.0-Paketen benötigen.
Im Moment funktioniert die ldap-Authentifizierung nicht, wenn Kerberos nicht läuft, weil die entsrpechenden Paramter auf "die" stehen.
(In reply to comment #16) > Im Moment funktioniert die ldap-Authentifizierung nicht, wenn Kerberos nicht > läuft, weil die entsrpechenden Paramter auf "die" stehen. Das ist auch schon mit 2.4 so, daher sollte das (wenn überhaupt) über einen neuen Bug gelöst werden -> Bug #23024
(In reply to comment #14) > Wie ist die Migration beim Update von den alten UCRV auth/user/services auf die > neuen UCRV zu lösen? (Automatisch im postinst, oder manuell? Im univention-pam > oder in jedem Paket einzeln?) Wird alles per Doku / Release Notes gemacht.
Der Join von Systemen des Typs domaincontroller_slave funktioniert damit zur Zeit nicht mehr, da diese nicht in der Gruppe "Computers" sind (Download der SSL-Zertifikate schlägt fehl). Vermutlich wäre das Beste univention-server-join so anzupassen, dass Slaves zusätzlich in die Gruppe "Computers" aufgenommen werden, und für Update-Szenarien etwas ähnliches im Postup zu machen. Wenn das aus irgendeinem Grund nicht sinnvoll sein sollte, dann müsste entweder branches/ucs-3.0/ucs/base/univention-pam/conffiles/etc/security/access-sshd.conf angepasst werden oder zumindest im postinst von univention-pam univention-config-registry set auth/sshd/group/"DC Slave Hosts"?true gesetzt werden.
(In reply to comment #19) > Der Join von Systemen des Typs domaincontroller_slave funktioniert damit zur > Zeit nicht mehr, da diese nicht in der Gruppe "Computers" sind (Download der > SSL-Zertifikate schlägt fehl). > > Vermutlich wäre das Beste univention-server-join so anzupassen, dass Slaves > zusätzlich in die Gruppe "Computers" aufgenommen werden, und für > Update-Szenarien etwas ähnliches im Postup zu machen. > > Wenn das aus irgendeinem Grund nicht sinnvoll sein sollte, dann müsste entweder > branches/ucs-3.0/ucs/base/univention-pam/conffiles/etc/security/access-sshd.conf > angepasst werden oder zumindest im postinst von univention-pam > univention-config-registry set auth/sshd/group/"DC Slave Hosts"?true > gesetzt werden. Ssh auf DC's wird nun auch für die Gruppen "DC Slave Hosts", "DC Backup Hosts" und Computers erlaubt.
In UCS 3.0-0 MS1 funktioniert ssh per Kerberos-Ticket nicht mehr ohne Angabe der Client-Option "-K". Ursache ist, dass in /etc/univention/templates/files/etc/ssh/ssh_config noch auth/user/methods ausgelesen wird. Das müsste durch auth/methods ersetzt werden. Das Template kommt aus univention-base-files/conffiles/ssh/ssh_config.
(In reply to comment #21) > In UCS 3.0-0 MS1 funktioniert ssh per Kerberos-Ticket nicht mehr ohne Angabe > der Client-Option "-K". Ursache ist, dass in > /etc/univention/templates/files/etc/ssh/ssh_config noch auth/user/methods > ausgelesen wird. Das müsste durch auth/methods ersetzt werden. Das Template > kommt aus univention-base-files/conffiles/ssh/ssh_config. Wurde in univention-base-files entsprechend angepasst. Andere Stellen an denen auth/admin/methods und auth/user/methods noch verwendet werden, konnte ich nicht finden.
Funktioniert: Join von Backup, Slave, Member, Managed, Mobile funktioniert. Auf allen DC wird ssh für normale Benutzer abgelehnt. Das root Passwort muss einen minimale Länge haben. ssh per Kerberos funktioniert auch ohne -K. Funktioniert nicht: Die Beschreibungen der UCRV sind für auth/*/group/* etc.
(In reply to comment #23) > Funktioniert: > > Join von Backup, Slave, Member, Managed, Mobile funktioniert. > > Auf allen DC wird ssh für normale Benutzer abgelehnt. > > Das root Passwort muss einen minimale Länge haben. > > ssh per Kerberos funktioniert auch ohne -K. > > > Funktioniert nicht: > Die Beschreibungen der UCRV sind für auth/*/group/* etc. angepasst
(In reply to comment #24) > (In reply to comment #23) > > Funktioniert nicht: > > Die Beschreibungen der UCRV sind für auth/*/group/* etc. > angepasst Stimmt Changelog OK
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"
*** Bug 6446 has been marked as a duplicate of this bug. ***