Zentrale sudo-Regeln sind einer der Punkte, an denen Identity Management im Linux-Betrieb konkret wird. Es reicht nicht, Benutzer zentral anzulegen; entscheidend ist, wer auf welchem Host welche administrativen Kommandos ausführen darf.

Dieser Beitrag zeigt FreeIPA sudo rules aus einem realen Zwei-Knoten-Lab: ein FreeIPA-Server, ein angebundener Linux-Client, eine Benutzergruppe, eine Hostgruppe, eine Command Group und mehrere Gegenproben.

Zielbild: nicht pauschal sudo, sondern ein konkretes Kommando

Im Lab durfte die Gruppe ops-sudo-status auf dem Client client01.idm.lab.test genau /usr/bin/systemctl status sshd per sudo ausführen. Ein Restart des Dienstes war nicht erlaubt. Ein zweiter Benutzer außerhalb der Gruppe durfte auch den erlaubten Status-Befehl nicht ausführen.

Das ist der Unterschied zwischen einer groben Admin-Gruppe und einer prüfbaren Delegation: Die Regel beschreibt Benutzer, Zielhosts, erlaubte Kommandos und optional RunAs-Kontext getrennt.

HBAC und sudo sind unterschiedliche Schichten

HBAC beantwortet die Frage, ob ein Benutzer einen Dienst auf einem Host überhaupt nutzen darf, etwa SSH auf einem bestimmten System. Sudo beantwortet danach die Frage, welches privilegierte Kommando dieser bereits angemeldete Benutzer ausführen darf.

In produktiven Umgebungen sollte beides bewusst geprüft werden: Ein Benutzer kann per HBAC auf einen Host kommen, aber trotzdem kein sudo-Recht haben. Umgekehrt hilft eine sudo-Regel nicht, wenn der Benutzer den Host oder den relevanten Dienst nicht erreichen darf.

Aufbau der Regel

Die getestete Struktur bestand aus einer FreeIPA-Benutzergruppe für berechtigte Operatoren, einer Hostgruppe für Zielsysteme, einem sudo command für /usr/bin/systemctl status sshd, einer sudo command group und einer sudo rule, die diese Bausteine zusammenführt.

Als CLI-Logik lässt sich das nachvollziehbar formulieren: ipa group-add, ipa hostgroup-add, ipa sudocmd-add, ipa sudocmdgroup-add, ipa sudorule-add, danach die Verknüpfungen für Benutzergruppe, Hostgruppe und erlaubte Command Group.

Client-Voraussetzungen

Auf dem Client müssen sudo und SSSD zusammenspielen. Im Lab waren services = nss, pam, ssh, sudo in sssd.conf und sudoers: files sss in nsswitch.conf die entscheidenden Prüfstellen.

Wenn eine Regel in FreeIPA korrekt aussieht, aber auf dem Client noch nicht greift, ist das kein Beweis gegen die Regel. Dann müssen SSSD-Sudo-Provider, Cache und Refresh betrachtet werden.

Positive Prüfung

Der Benutzer opsallowed war Mitglied der erlaubten Gruppe. Der Test über SSH auf client01 zeigte: id löste den zentralen Benutzer korrekt auf, sudo /usr/bin/systemctl status sshd lieferte den Status des laufenden sshd.service, und der Rückgabewert war 0.

Damit war nicht nur die Web-UI-Regel sichtbar, sondern die tatsächliche Client-Ausführung belegt.

Negative Gegenproben

Die erste Gegenprobe war ein anderer Befehl mit demselben Benutzer: opsallowed durfte sudo /usr/bin/systemctl restart sshd nicht ausführen. Der Rückgabewert war 1.

Die zweite Gegenprobe war ein anderer Benutzer: opsdenied war nicht Mitglied der sudo-Gruppe und durfte auch den eigentlich erlaubten Status-Befehl nicht ausführen. Auch hier war der Rückgabewert 1.

Stolperstein: SSSD-Sudo-Refresh

Ein realer Befund im Lab war wichtig: Die erste Client-Prüfung meldete noch, dass opsallowed nicht sudo auf client01 ausführen darf, obwohl die FreeIPA-Objekte bereits angelegt waren.

Erst nach gezielter Diagnose, Cache-Refresh und SSSD-Neustart wurde die Regel korrekt ausgewertet. Für Betriebsanleitungen ist dieser Punkt zentral: Regelanlage und Client-Sicht müssen separat verifiziert werden.

Technische Abnahme

PASS: FreeIPA Server installiert, Client enrolled, Benutzer und Gruppen zentral sichtbar, Hostgruppe vorhanden, sudo command und command group vorhanden, positive sudo-Ausführung erfolgreich, negativer Command-Test erfolgreich, negativer User-Test erfolgreich.

PARTIAL: Der Cache-/Refresh-Pfad muss pro Distribution und SSSD-Version in der eigenen Umgebung sauber beobachtet werden. Der Artikel beschreibt das Lab-Verhalten, ersetzt aber keine kundenspezifische SSSD-Policy.

Praxis-Checkliste

Vor der Freigabe sollten Administratoren prüfen: Benutzerauflösung per id, Gruppenzugehörigkeit, Hostgruppenmitgliedschaft, sudoers: files sss, SSSD services inklusive sudo, ipa sudorule-show, sudo -l als Zielbenutzer, erlaubtes Kommando, nicht erlaubtes Kommando und nicht berechtigter Benutzer.

Fazit

FreeIPA sudo rules sind dann wertvoll, wenn sie nicht als Ersatz für lokales Wildcard-sudo genutzt werden, sondern als zentral gepflegte, nachvollziehbare Delegation. Die eigentliche Abnahme passiert auf dem Client: erst positive und negative Tests machen die Regel produktionsnah belastbar.