Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

Von Authentifizierung zu Autorisierung

Bis hierhin haben wir beschrieben, wie sich der 389 DS nutzen lässt, um Benutzerinformationen aus verschiedenen Active Directories zu extrahieren und Anfragen an den richtigen AD-Server weiterzuleiten. Diese Konfiguration ist nützlich, wenn sich alle User an allen Servern anmelden dürfen, aber das ist selten der Fall. Typischerweise dürfen sich einige Benutzer nur an bestimmten Maschinen einloggen und deshalb braucht es einen Mechanismus, um festzustellen, welche Benutzer für welche Server autorisiert sind. Um das zu erreichen bietet »pam_access« einen einfachen Weg, um eine Zugriffssteuerung einzurichten. Für jeden Linux-Client gilt es festzulegen, welcher Benutzer auf ihn zugreifen darf. Im 389 DS sind dann entsprechende Gruppen einzurichten, auf die das PAM-Modul zugreift. Sie lassen sich entweder über die grafische Oberfläche oder die Kommandozeile anlegen. Listing 5 zeigt das Beispiel eines LDIF-Files, das ein Gruppenobjekt beschreibt, dessen Mitglieder durch das Attribut »uniqueMember« identifiziert werden. Sobald das File »linuxadmin.ldif« existiert, erzeugt das folgende Kommando einen neuen Eintrag für ein Gruppenobjekt auf dem 389 DS:

Listing 5

linuxadmins.ldif

 

ldapmodify -x -D "cn=Directory Manager" -W -f linuxadmins.ldiff

Nun kann man festlegen, welche Benutzer und Gruppen sich an welcher Maschine anmelden dürfen. Sie hinterlegt man dabei im File »/etc/security/access.conf« (Auszug in Listing 6). Die ersten beiden Zeilen erlauben es »root« und »joe« , sich vom lokalen System und überall her einzuloggen. Die dritte Zeile gestattet es der Gruppe »LinuxAdmins« auf den Server »server1.example.local« aus dem Netz 10.1.1.0/24 zuzugreifen. Die vierte Zeile verbietet alle anderen Zugriffe.

Listing 6

/etc/security/access.conf

 

Der letzte Schritt besteht darin, PAM so zu konfigurieren, dass es »access.conf« verwendet. Das geht einfach, indem man die folgende Zeile in »/etc/pam.d/systen-auth-ac« ergänzt:

account required pam-access.so

Zugabe Failover

Was aber, wenn einer der Windows-Domänen-Controller ausfällt? Glücklicherweise ist es sehr einfach, das System ausfallsicher zu machen. Dazu braucht es zuerst einen weiteren 389 Directory Server mit identischer Konfiguration. Auf ihm schaltet man die Replikation ein und synchronisiert so alle lokalen Objekte.

Zusätzlich müssen die Chaining- und Pass-Through-Plugins so konfiguriert werden, dass sie mehrere AD-Server im Zuge eines Failovers unterstützen. Das geht wie Abbildung 7 zeigt, indem die IP-Adresse eines zweiten AD-Servers unter »Failover Servers« eingetragen wird. Auch das Pass-Through-Plugin unterstützt mehrere Authentication-Server als mit Leerzeichen separierte Liste.

Schließlich lassen sich die Linux-Clients so konfigurieren, dass sie ihre Benutzer und Gruppen von einem anderen 389 DS empfangen, sollte der erste ausgefallen sein. Dazu spezifiziert man eine alternative URI in der »/etc/ldap.conf« .

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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

Google+

Ausgabe /2019