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)

Schematisch

Damit der Import in den LDAP-Server funktioniert, muss dieser natürlich über das passende Schema verfügen, ansonsten meckert dieser über viele unbekannte Attribute, und der LDIF-Import schlägt fehl. Das passende Schema bringt Sudo aber glücklicherweise von Haus aus mit. Unter Fedora gibt es für verschiedene LDAP-Server im Verzeichnis »/usr/share/doc/sudo-1.8.x/« entsprechende Schema-Dateien, diese gelangen ebenfalls wieder mit einem »ldapadd« in den Server.

Damit nun auch der System Security Services Daemon von seinem neuen Security-Provider weiß, ist dieser über die Datei »/etc/sssd/sssd.conf« entsprechend zu konfigurieren. Listing 2 zeigt ein Beispiel für eine Konfiguration mit einem reinem LDAP-Server im Backend. Natürlich kann hier auch ein FreeIPA-Server zum Einsatz kommen. Die Manpage für »sssd.conf« hilft dann weiter und zeigt eine beispielhafte Konfiguration für einen solchen Fall.

Listing 2

Caching von Sudo-Regeln

 

Damit im Cache nun nicht nur die Regeln landen, die bereits einmal von einem Benutzer aufgerufen wurden, sind unbedingt die beiden Anweisungen »ldap_sudo_refresh_enabled« und »ldap_sudo_refresh_timeout« zu verwenden. Diese sorgen dafür, dass wirklich alle Sudo-Regelsätze in bestimmten Abständen vom LDAP-Server geladen werden. Damit beim Aufruf von »sudo« auch der neue Security-Provider des SSSD-Dienstes angesprochen wird, ist zwingend noch die folgende Zeile in der Datei »/etc/nsswitch.conf« notwendig:

sudoers = files sss

Nach einem Neustart des SSSD-Dienstes ist dieser nun also in der Lage, die Sudo-Regeln in einem lokalen Cache abzulegen. Die Performance der Abfragen sollte von nun an auch besser sein, selbst beim Online-Betrieb, da nicht mehr für jede einzelne Anfrage eine neue Verbindung zum LDAP-Server aufgebaut wird. Sämtliche LDAP-Abfragen laufen nur noch über eine einzelne Verbindung vom »sssd« zum LDAP-Server. Zum Schluss sei noch erwähnt, dass der Artikel davon ausgeht, dass die Authentifizierung von Benutzern bereits über den System Security Services Daemon stattfindet. Sollte dies nicht der Fall sein, reicht ein Aufruf von »system-config-authentication« , um dies zu ändern.

Schneller Snack

Da nach der ganzen Schreiberei nun mein Magen knurrt und ich nicht mehr viel Zeit habe, bis der Flieger in die Heimat geht, gibts jetzt noch einen schnellen Besuch in der British Beer Company. Anders als der Name vermuten lässt, gibt es hier neben gutem Bier nämlich auch hervorragendes Essen. (ofr)

Infos

  1. System Security Services Daemon (SSSD): https://fedorahosted.org/sssd/
  2. Thorsten Scherf, FreeIPA: http://www.admin-magazin.de/Online-Artikel/Technical-Review/FreeIPA

Der Autor

Thorsten Scherf arbeitet als Senior Consultant für Red Hat EMEA. Er ist oft als Vortragender auf Konferenzen anzutreffen. Wenn neben Arbeit und Familie noch Zeit bleibt, nimmt er gerne an Marathonläufen teil.

comments powered by Disqus
Mehr zum Thema

SSSD für lokale Benutzerdaten

Der Zugriff auf Benutzer- und Gruppen-Informationen kann unter Umständen eine recht kostspielige Aktion werden, wenn er ein zentrales Directory oder Dateien einbezieht. Mit Caches lässt sich die Performance dieser Zugriffe steigern. Dies gilt aber nicht unbedingt in allen Fällen. Dieser Open-Source-Tipp nimmt daher den neuen FILES-Provider des System Security Services Daemon näher unter die Lupe.
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