Der System Security Services Daemon

Abgesteckt

Zentrale Sudo-Regeln auf einem LDAP-Server abzulegen, vereinfacht die Administration von Workstations und Clients im Firmennetz. Schwierigkeiten gibt es aber, wenn der so betreute Client-Rechner vom Netz getrennt ist. Abhilfe schafft die aktuelle Version des System Security Services Daemon (SSSD).
NAS-Speicher mit einer Kapazität von einigen Dutzend Terabyte, wie sie sich für mittelständische Anwender eignen, nimmt die ADMIN-Redaktion in der Ausgabe ... (mehr)

Beim Mittagessen mit einem Kollegen kamen wir neulich auf das Thema SSSD und neue Features in Fedora 17 zu sprechen. Dabei ging es auch um die Sudo-Integration und andere nützliche Features. Zur Erinnerung: Beim SSSD (System Security Services Daemon [1] ) handelt es sich um einen Client-Daemon, der die Kommunikation von Clients mit zentralen Verzeichnisdiensten regelt. Hierfür können unterschiedliche Authentifizierungsmechanismen zum Einsatz kommen. Die Kommunikation mit dem Client erfolgt dabei über die klassischen PAM- und NSS-Schnittstellen, im Backend gibt es dann unterschiedliche Security-Provider, beispielsweise für die Kommunikation mit einem LDAP- oder FreeIPA-Server [2] .

Das Tolle dabei ist, dass die Authentifizierung von einem Client auch dann noch funktioniert, wenn der zentrale Backend-Server gar nicht zur Verfügung steht. Dies kann natürlich durch einen Ausfall des Servers passieren, öfter ist die Ursache aber viel trivialer. Für Roaming-Benutzer, die für ihr Notebook nicht immer einen Netzanschluss haben, ist die Kommunikation zu einem zentralen Verzeichnisdienst somit auch nicht immer möglich.

Der SSSD arbeitet mit einem Cache für Authentifizierungsinformationen. Möchte sich ein Benutzer am System anmelden, und der zentrale Server im Backend steht nicht zur Verfügung, klappt die Anmeldung am System trotzdem, da in diesem Fall die Informationen aus dem SSSD-Cache kommen. Die Konfigurationsdatei »/etc/sssd/sssd.conf« gestattet es natürlich, ganz genau festzulegen, wie dieser Cache verwendet werden darf. So legt beispielsweise der Parameter »offline_credentials_expiration« fest, wie lange die Daten aus dem Cache Gültigkeit besitzen sollen, wenn der Backend-Server nicht zur Verfügung steht.

Schutz gegen Brute Force

Die Anweisung »offline_failed_login_attempts« sorgt dafür, dass ein Benutzer nicht beliebig oft versuchen kann, das Passwort eines anderen Benutzers zu erraten. Ist der hier definierte Integer-Wert überschritten, wird der angriffsfreudige Benutzer für die in der Option »offline_failed_login_delay« definierte Zeit von weiteren Anmeldeversuchen ausgesperrt. Steht die Option auf 0, ist ein Login gar nicht mehr möglich, solange der Backend-Server nicht zur Verfügung steht.

Ein Problem bei diesem Ansatz ergibt sich aber dann, wenn beispielsweise auch die Sudo-Regeln für einen Benutzer und ganze Gruppen auf dem zentralen LDAP-Server im Backend liegen. Sudo überprüft anhand der Datei »/etc/nsswitch.conf« , auf welchen Backends nach Regeln zu suchen ist. Üblicherweise ist dort ein Eintrag wie beispielsweise »sudoers = files ldap« vorhanden. Die Kommunikation erfolgt in einem solchen Fall direkt mit dem LDAP-Server. Ist der nicht verfügbar, geht die Anfrage natürlich ins Leere, und der Benutzer kann die gewünschte Aktion nicht ausführen, da es nicht möglich ist, zu verifizieren, ob sie denn überhaupt für den Benutzer gestattet ist. Der SSSD löst dieses Problem dadurch, dass die Sudo-Informationen ebenfalls in einen Cache wandern. Hierfür musste aber natürlich die Sudo-Software um ein Plugin erweitert werden, sodass bei einem entsprechenden Eintrag in der Datei »/etc/nsswitch.conf« , die Anfrage auch tatsächlich an den SSSD geschickt wird. Dieser braucht ebenfalls einen neuen Security-Provider, der die Anfragen des Sudo-Tools entgegennimmt. Die aktuellen Sudo- und SSSD-Versionen in Fedora 16 haben die entsprechende Unterstützung bereits eingebaut.

LDAP-Import

Wer das Ganze nun einmal ausprobieren möchte und noch keine Sudo-Regeln im LDAP gespeichert hat, findet hier eine kleine Anleitung. Die in Listing 1 dargestellte LDIF-Datei ist beispielsweise mittels »ldapadd« in den persönlichen Lieblings-LDAP-Server zu laden. Die Anweisungen erzeugen zuerst den Container »ou=SUDOers« , in dem dann die eigentlichen Sudo-Regeln liegen. Hiervon existieren in meinem Beispiel zwei Stück, eine für die »goodboys« und eine für die »badboys« . Erstere dürfen, da sie immer lieb und artig sind, sämtliche Dateien auf dem System editieren. Die Badboys müssen noch lernen und dürfen daher die Dateien bisher nur lesen.

Listing 1

LDIF-Anweisungen für die LDAP-Integration von sudo

 

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023