Im letzten Beitrag “Opensuse 12.1 – LDAP IV” hatten wir uns mit Password Policy Objekten auf dem LDAP Server befasst. Nun wollen wir einen weiteren Schritt in Richtung auf eine LDAP-basierte Userverwaltung in einem (kleinen) Opensuse-basierten Netzwerk gehen. Ich setze hierbei die Lektüre der früheren Beiträge “LDAP I” bis “LDAP IV” voraus.

Wir haben in den vorhergehenden Beiträgen erkundet, was man tun muss, um User mittels YaST2 auf dem LDAP-Server anzulegen und zu verwalten. Wir hatten auch gesehen, dass und wie wir uns über Binds vom LDAP-Server für einen Login auf anderen Hosts im Netzwerk authentisieren und autorisieren lassen können . Das lokale PAM auf dem jeweiligen Host sorgt dabei – wenn erforderlich – für die Anlage eines Home-Verzeichnisses bei einem initialen Login. Zudem hatten wir uns damit auseinandersetzt, wie eine zentrale LDAP Password Policy mit den lokalen PAM-Prüfmodulen auf den Netzwerk-Hosts zusammenwirkt.

Noch nicht geklärt haben wir dagegen, was wir tun müssen, um den Zugang von einzelnen Usern auf definierte Hosts im Netzwerk zu begrenzen. U.a. soll sich ja nicht jeder User auf dem sicherheitsrelevanten LDAP-Server einloggen können. Es geht uns also um eine host-bezogene Zugangsautorisierung über LDAP. Interessiert sind wir dabei an einer Politik, die nicht zulässt, was nicht explizit erlaubt ist.

In unserem Muster-Scenario gibt es   – wie in den früheren Beiträgen auch –   einen OpenLDAP-Server “vms2” auf Basis von Opensuse 12.1 und einen weiteren Opensuse 12.1-Host “vms1” im Netzwerk, auf dem unsere gewöhnlichen User arbeiten sollen. Das letztere System repräsentiert einen beliebigen Opensuse-Host in unserem Netzwerk. Das Setup der beiden Systeme hatten wir in den Beiträgen “LDAP I” bis “LDAP IV” ausführlich besprochen.

Ein simpler, aber unzureichender Ansatz für die Zugangsbeschränkung zum Server

Im Beitrag “LDAP II” hatten wir uns die Erweiterung der “/etc/passwd” um den Verweis auf NIS/LDAP-Accounts angesehen. Nun könnte man zum Schutz des LDAP-Servers “vms2” auf den Gedanken kommen, jeglichen Login von Usern, die über LDAP verwaltet werden, durch ein “/sbin/nologin” oder /bin/false” zu unterbinden, indem man aus der letzten Zeile der “/etc/passwd” auf “vms2”

+::::::

ein

+::::::/sbin/nologin

oder ein

+::::::/bin/false

macht.

Das ist sehr wirksam, aber eben auch nur auf diesen Server begrenzt und dort bzgl. der User nicht besonders selektiv. Ggf. will man auch einem über LDAP verwalteten User Zugriff auf den LDAP_Server gewähren. Wir belassen unsere “/etc/passwd”-Einträge daher lieber in der ursprünglichen Form.

Auf einem anderen Host als “vms2” nutzt uns das beschrieben Verfahren sowieso herzlich wenig:
Auf den normalen Hosts sollen sich ja gerade zumindest einige der über LDAP verwalteten User einloggen dürfen. Wenn auch vielleicht nicht alle …

Wir brauchen im Netz also ein Verfahren, bei dem userspezifisch entschieden werden kann, zu welchem Host ein User Zugang erhält und zu welchem nicht.

Zwei LDAP-basierte Standardverfahren zur Zugriffssteuerung

In diesem Artikel bespreche ich deshalb zwei einfache Methoden, mit deren Hilfe man es in einem kleinen Netzwerk schafft, Usern, die über einen zentralen LDAP-Server verwaltet werden, einen Zugang nur auf vordefinierte Hosts zu gewähren. Die Host-User-Relationen, die erlaubt sind, werden dabei auf dem LDAP-Server selbst hinterlegt.

Kennzeichnend für diese Verfahren ist Folgendes:

• Verfahren 1: Im Verfahren 1 analysiert der LDAP-Server im Auftrag des “pam_ldap”-Moduls eines Netzwerk-Hosts den Inhalt eines Zusatzfeldes “host”, das man den Useraccounts auf dem LDAP-Server hinzufügen muss. Über diesen Feldtyp werden explizit alle Hosts aufgelistet, zu denen der User Zugang erhalten soll. Man baut in diesem Verfahren also eine (1:n)-Relation der Form “User >> hosts” auf und betrachtet die Zugangserlaubnis aus Sicht des Users.
• Verfahren 2: Das zweite Verfahren basiert dagegen auf dem Aufbau einer Host-Verwaltung in einem dafür geeigneten Ast – z.B. ou=hosts – des LDAP-Verzeichnisbaum. Jedem Hosteintrag wird dann über ein spezielles Feld “uniquemember” eine Liste von registrierten Usern aus dem Zweig “ou=people” zugeordnet. Man baut in diesem Verfahren also eine (1:n)-Relation der Form “host >> user” auf und betrachtet die Zugangserlaubnis aus Sicht des Hosts.

Welches Verfahren man bevorzugt, ist mehr eine Frage der Philosophie und der Pflege-Technik. Die Anzahl der einzutragenden Sätze bleibt letztlich gleich:

Für jeden User und jeden Host, zu dem der Zugang erlaubt werden soll, muss in beiden Verfahren explizit ein Eintrag angelegt werden. Beim ersten Verfahren kann man die Host-Zuordnung jedoch bereits während der Useranlage mit erledigen. Im zweiten Verfahren muss der Administrator bei der Anlage neuer User dagegen explizit daran denken, den User danach auch bei ausgewählten Host-Objekten des LDAP-Baums explizit zu hinterlegen.

Ich persönlich finde die zweite Variante in einem kleinen Netzwerk etwas besser:

Erstens ist die Anlage einer Liste von Hosts auf dem LDAP-Server auch für andere Zwecke – wie etwa die LDAP-Unterstützung von Samba etc. – eine sehr gute Idee. Zweitens zwingt sie einen regelmäßig dazu, darüber nachzudenken, wer eigentlich auf welchem Rechner werkeln soll. Und wenn man tatsächlich mal einen Eintrag für einen Host vergessen sollte – es schadet nicht wirklich. Die User rühren sich bestimmt.

Bei beiden Verfahren ist es übrigens so, dass man die LDAP-Client-Konfiguration auf allen zu schützenden Hosts um bestimmte Einträge erweitern muss. Wir werden weiter unten zudem sehen, dass beide Verfahren dabei sogar kombiniert werden können.

Verfahren 1: Zugangskontrolle über das Attribut “pam_check_host_attr”

Der LDAP-Server soll in diesem Verfahren bei einem Login-Versuch auf einem Host von eben diesem Host aufgefordert werden, einen “host”-Eintrag in den LDAP-Daten des Users zu kontrollieren. Hierzu sind einerseits Änderungen an der Datei “/etc/ldap.conf” auf dem betroffenen Host erforderlich. Andererseits muss das “host”-Feld in den Userdaten des LDAP-Servers vorhanden und gefüllt sein.

Wie aber ergänzen wir nun auf dem LDAP-Server die User-Einträge unter dem Zweig   “ou=people”   um das benötigte “host”-Feld? Ein Blick mit dem YaST2-LDAP-Browser zeigt uns nämlich schnell, dass dieses Feld bisher leider nicht angelegt worden ist.

Bis zu diesem Zeitpunkt hatte uns YaST2 weitgehend von solchen “Niederungen” des Umgangs mit dem LDAP-Server abgeschirmt. Nutzen wir YaST2 zur Userverwaltung, so werden neue User-Einträge im Zweig “ou=people, dc=anracona,dc=de” unseres LDAP-Servers “vms2” fix und fertig aufbereitet angelegt. Nun sind wir auch als eventuelle LDAP-Beginner gezwungen, ein wenig über den Tellerrand von YaST hinausblicken.

Die Felder, die zu jedem Objekt im LDAP-Baum erfasst werden können, entsprechen den Möglichkeiten, die sich aus einer Kombination von “LDAP-Objektklassen” ergeben. Letztere werden wiederum über LDAP-Schemata bereitgestellt, die auf unserem LDAP-Server geladen sein müssen. Wie man sich mit YaST2 ein Übersicht über die auf dem LDAP-Server installierten Schemata verschaffen kann, hatte ich u.a. im Beitrag “LDAP IV” gezeigt.

Ein konkretes Objekt des LDAP-Baumes erhält seine Felddefinitionen also aus einer für das Objekt getroffenen Festlegung hinsichtlich seiner konstituierenden Objektklassen. Diese Festlegung wird im Objekt selbst hinterlegt. Die Felddefinitionen einer einzelnen Klasse sind dabei eindeutig. Es gibt unter den Feldern einer Objektklasse – wie in anderen Datenbanken auch – in der Regel einige Mussfelder, die man bei der Anlage eines konkreten Objektes mit einem Wert belegt muss.

Für ein neues, weiteres Feld muss man einem LDAP-Objekt daher eine neue Objektklasse zuordnen, die im Rahmen eines der auf dem Server geladenen Schemata definiert ist. Daneben gibt es noch die Möglichkeit, ein konkretes Objekt zu einem sog. “Extensible Object” zu machen. Einem solchen Objekt können dann einzelne weitere Felder aus dem Schema-Vorrat hinzugefügt werden.

In unserem Fall benötigen wir zusätzlich zu den Feldern, die unsere User-Einträge bisher aufweisen, nur noch genau ein Feld – nämlich eines des Typs “host”.

An dieser Stelle unserer Überlegungen prüfen wir über YaST2’s LDAP Browser mal, welche Objektklassen die YaST2 “User- und Gruppenverwaltung” unseren Usereinträgen bei deren Anlage im LDAP-Baum eigentlich zugewiesen hat:

Wir erkennen die Klassen

• “top”,
• “PosixAccount”,
• “InetOrgPerson”.

Diese Kombination wurde sicher nicht ohne Grund von SuSE’s Entwicklern ausgewählt. Daran wollen wir vorsichtshalber auch nichts verändern. Allerdings kann ein Festhalten an einer Objektklassen-Kombination dann problematisch werden, wenn sich eine weitere, zusätzliche Objektklasse nicht mit den genannten vertragen sollte.

Das benötigte Feld “host” ist über das “cosine.schema” definiert und taucht in der Objektklasse “account” auf. Das “cosine.schema” ist bei der Anlage unseres OpenLDAP-Servers mittels YaST2 übrigens automatisch bereitgestellt worden.

Die Objektklasse “account” harmoniert gut mit der Klasse “PosixAccount”. Beide Klassen setzen das Feld “uid” ein und dieses ist im übrigen auch das einzige “Muss”-Feld der Klasse “account”. Leider ergeben sich jedoch Probleme zwischen den Klassen “InetOrgPerson” und “account”. Wie kann man das sehen ?

Nachfolgend werden wir bei Experimenten mit dem LDAP-Verzeichnisbaum statt YaST2’s “LDAP Browser” öfter mal den LDAP-Browser “gq” einsetzen, da wir nun langsam an die Grenzen der YaST-Tools geraten.

“gq” ist bei Opensuse schnell über ein RPM-Paket installiert. Die erforderliche Konfiguration des Zugangs zum Server über Binds (z.B. mit der rootdn – in unserem Testscenario: “cn=Administrator,dc=anracona,dc=de”) sollte zumindest auf dem LDAP-Server “vms2” einfach von der Hand gehen. Die notwendigen Default-Einträge macht unter dem Menüpunkt “File >> Preferences”.

Mit “gq” kann man in der Ansicht zu den Feldern eines Objektes im LDAP-Baum schnell weitere Einträge für bestimmte Feldtypen anlegen. Neue Einträge werden über die rechts außen liegenden größeren Tasten mit dem nach unten gerichteten Pfeil erzeugt. Feldinhalte wählt man ggf. über die Combobox-Tasten am rechten Rand der Felder aus.

Nachfolgend sieht man das Ergebnis eines Versuches auf dem “vms2”, mittels “gq” ein User-Objekt um die Objektklasse “account” zu erweitern.

Das ging so richtig schief !

Einige weitere Tests, bei denen wir systematisch mit LDIF-Dateien und dem Kommando “ldapmodify” neue Objekte mit unterschiedlichen Objektklassenkombinationen anlegen, zeigen, dass man entweder auf die Objektklasse “inetOrgperson” oder die Klasse “account” verzichten muss. Das hier im Einzelnen darzustellen, erspare ich mir. (Leser, für die der Umgang mit LDIF-Dateien etwas Neues darstellt, sollten bei dieser Gelegenheit anfangen, sich damit auseinanderzusetzen. Das Studium der zugehörigen “man”-Seiten hilft dabei.)

Um in unseren User-Objekten im Zweig “ou=people,dc=anracona,dc=de” trotz der Probleme mit der “account”-Klasse noch ein “host”-Feld unterzubringen, greifen wir zu dem oben bereits angedeuteten Umweg:

Wir machen versuchsweise unseren Test-User “tarja” zu einem “Extensible Object” ! Wir ergänzen dazu mit “gq” und seinen Tasten die Einträge des Feldtyps “objectClass” um eine weitere Objektklasse, nämlich die Klasse “extensibleObject”:

Wir drücken dann auf den “Apply”-Button und danach auf “Refresh”.

Im nächsten Schritt fügen wir unserem modifzierten Objekt mit einer weiteren “gq”-Methode unser gewünschtes “host”-Feld hinzu. Dazu drücken wir auf das “gelbe” Symbol links oberhalb der Felddarstellung. Dieses öffnet den Dialog für die Felderweiterung eines “Extensible Objects”:

Wir drücken in kleineren Dialog zunächst auf “OK” und danach auf “Apply” und erhalten tatsächlich unser neues Feld:

Dieses füllen wir durch Editieren gleich mit einem Host-Eintrag für unser System “vms1”. Hier gibt man den FQDN des Hosts an, unter dem der Host im Netzwerk gefunden werden kann.

Für diejenigen, die statt mit “gq” lieber mit LDIF-Dateien sowie “ldapadd” und “ldapmodify” arbeiten wollen, hier der Inhalt einer LDIF-Datei, die unserem “tarja”-Datensatz entspricht:

dn: uid=tarja,ou=people,dc=anracona,dc=de
cn: tarja Turunen
gidNumber: 100
givenName: tarja
homeDirectory: /home/tarja
loginShell: /bin/bash
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: extensibleObject
sn: Turunen
uid: tarja
uidNumber: 1010
userPassword: {ssha}PTvGho95jW9reNdggxgJUWRDxTBNQktKTg==
host: vms1.anracona.de

Für unseren Testuser “tarja” heißt das, dass wir ihm/ihr den Zugang zum Host “vms1” gewähren wollen.

Das ist zwar nett von uns, doch wir hatten ja im letzten Beitrag “LDAP IV” schon mehrfach von der Tatsache Gebrauch gemacht, dass “tarja” Zugang zu diesem Host hatte. Warum sollte sich daran jetzt etwas durch den zusätzlichen Eintrag auf dem LDAP-Server geändert haben verändert haben?

Hat sich auch nicht ! Der User “tarja” hat – wie im übrigen auch alle anderen User in unserem LDAP Zweig “ou=people” – nach wie vor Zugang zu “vms1”. Bislang ist der Zugang für unsere Accounts, die über LDAP verwaltet werden, ja in keiner Weise (außer über das Passwort) eingeschränkt. Das kann der Leser gerne selber testen.

Dieser Zustand ändert sich erst, wenn wir an der LDAP-Client-Konfiguration von “vms1” etwas ändern. Künftig soll der PAM-LDAP-Client auf “vms1” unser “host”-Feld durch den LDAP-Server abfragen lassen, bevor er einen Zugang gewährt. Welcher Eintrag ist dafür notwendig?

Ein Studium der Erläuterungstexte zu den vielen auskommentierten Statements in der Datei   “/etc/ldap.conf”   auf “vms1”
macht uns auf folgende Zeile aufmerksam, von der wir nach der Lektüre mutig den Kommentar entfernen:

# Check the "host" attribute for access control
# Default is no; if set to yes, and user has no
# value for the host attribute, and pam_ldap is
# configured for account management (authorization)
# then the user will not be allowed to login.
pam_check_host_attr    yes

Wenn dieser Eintrag tatsächlich das bewirkt, was sein Erläuterungstext verspricht, so sollte sich nun außer dem User “tarja” kein weiterer User, der auf dem LDAP-Server gepflegt ist, auf “vms1” einloggen können.

Wir machen diesen Negativtest mit dem User “tuxer”, den wir im letzten Beitrag schon öfter bemüht haben. In seinem LDAP-Eintrag existiert bislang ja nicht einmal ein zusätzliches Feld “host”. Das Ergebnis ist:

Genau so hatten wir uns das vorgestellt !

Analog geht es mit allen anderen Testusern unter “ou=people,dc=anracona,dc=de” – außer “tarja”.

Der Positivtest mit “tarja” verläuft dagegen, wie wir das erhofft haben, tatsächlich positiv:

Unser erstes Verfahren funktioniert also schon mal.

Wenn man nun dem User “tarja” Zugang zu mehreren Hosts gewähren will, so ergänzt man den Datensatz für “tarja” auf dem LDAP-Server z.B. per “gq” einfach um weitere Feldeinträge des Typs “host”:

Oder man nutzt eine LDIF-Datei der Form:

dn: uid=tarja,ou=people,dc=anracona,dc=de
cn: tarja Turunen
gidNumber: 100
givenName: tarja
homeDirectory: /home/tarja
loginShell: /bin/bash
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: extensibleObject
sn: Turunen
uid: tarja
uidNumber: 1010
userPassword: {ssha}PTYGho95jW9reNdxUdgJUWRDxTBNQktMTg==
host: vms1.anracona.de
host: vmsx.anracona.de
host: vmsy.anracona.de

Hinweis : Natürlich muss man dann auf den anderen Hosts auch die Dateien “/etc/ldap.conf” um den Eintrag

pam_check_host_attr    yes

ergänzen!

Das genannte Verfahren führt man dann sukzessive für alle User durch. Bei größeren Installatinen wird man dabei um ein wenig Scripting, den Einsatz von “ldapsearch” und “ldapmodify” nicht herumkommen.

Auf einen YaST2-Unterstützung können wir bei diesem Verfahren auf Opensuse-Systemen also nicht mehr zählen!

Verfahren 2 – Zugangskontrolle durch User-Einträge in “host”-Objekten des LDAP-Baums

Für unser zweites Verfahren müssen wir Host-Einträge im LDAP-Verzeichnisbaum unterbringen. YaST2 können wir hierfür abschreiben – mir ist zumindest keine Möglichkeit bekannt, mit YaST2’s LDAP-Tools eine Host-Verwaltung auf einem LDAP-Server vorzunehmen und damit auch noch Zugriffsberechtigungen für User zu organisieren.

Damit unsere “host”-Einträge im LDAP-Baum aufgeräumt sind, wollen wir einen neuen Zweig des LDAP-Baums eröffnen:

ou=hosts,dc=anracona,dc=de

In diesem Zweig wollen wir als ersten Eintrag gleich unseren LDAP-Server unterbringen. Hier stellt sich erneut die Frage der Objektklassen-Zuordnung für die gewünschten Einträge.

Ich greife zu folgenden Klassen, die aus meiner Sicht die notwendigsten Felder zur Beschreibung eines Hosts enthalten:

• objectClass: posixGroup
• objectClass: groupOfUniqueNames
• objectClass: extensibleObject
• objectClass: ipHost

Wie beim ersten Verfahren sehen wir hier aus Flexibilitätsgründen den Einsatz der Klasse “extensibleObject” vor. Zwingend erforderlich ist diese Klasse diesmal aber nicht.

Es ergibt sich folgende Struktur einer LDIF-Datei, die wir auf dem Server zur Ausführung bringen müssen:

LDIF-Datei für die Anlage des neuen Zweiges und eines Hosteintrags für “vms2”:

dn: ou=hosts,dc=anracona,dc=de
objectClass: organizationalUnit
ou: hosts

dn: cn=vms2,ou=hosts,dc=anracona,dc=de
objectClass: posixGroup
objectClass: groupOfUniqueNames
objectClass: extensibleObject
objectClass: ipHost
ipHostNumber: 192.168.0.12
cn: vms2.anracona.de
cn: vms2
gidNumber: 1
uniqueMember: uid=tuxer,ou=people,dc=anracona,dc=de

Man erkennt an der letzten Zeile, dass wir dem Host-Eintrag gleich auch noch einen ersten User mitgegeben haben !

Aufgrund unserer Objektklassenzusammenstellung ergeben sich in diesem Fall einige Muss-Felder, für die ein Eintrag zwingend vorzunehmen ist, nämlich:

• cn    ( für die Bezeichnung des Hosts)
• gidNumber    ( für die Zugehörigkeit zu einer Gruppe von Hosts)
• ipHostNumber    ( für die IP-Adresse des Hosts)
• uniqueMember    ( mindestens einen User des Hosts)

Wem diese Mussfelder zuviel sind oder wen im Besonderen das Mussfled “uniqueMember” stört, kann für die Hosteinträge auch folgende Alternative verwenden:

LDIF-Alternative für Host-Einträge :

dn: cn=vms2,ou=hosts,dc=anracona,dc=de
objectClass: device
objectClass: ipHost
objectClass: extensibleObject
ipHostNumber: 192.168.0.12
cn: vms2.anracona.de
cn: vms2
member: uid=tuxer,ou=people,dc=anracona,dc=de

Hinweise zur Alternative:

• Um dem Host Feldeinträge vom Typ “member” zuordnen zu können, ist die Klasse “extensibleObject” zwingende Voraussetzung.
• Das Feld “member” ist dann kein Mussfeld. Man kann es daher auch leer lassen.
• Man muss bei Verwendung dieser Alternative weiter unten bei der Einrichtung der LDAP-Clients auf den Hosts aufpassen und als zu untersuchendes Feld “member” statt “uniqueMember” angeben.

Unsere Vorgaben bringen wir nun in einer Datei “host_vms2.ldif” in einem Verzeichnis unserer Wahl auf “vms2” unter. In diesem Verzeichnis führen wir nun diese Datei für den LDAP-Server aus:

vms2:~ # ldapadd -D "cn=Administrator,dc=anracona,dc=de" -w MY_LDAP_PASSWD -x -a -f hosts_vms2.ldif

Danach kontrollieren wir das Erreichte über “gq”:

Der aufmerksame Leser erkennt, das ich auf meinem Testserver “vms2” zwischenzeitlich schon mal dem User “rmo” Zugang gewährt hatte.

Gemäß des LDAP-Eintrags für unseren Server “vms2” dürfte sich jetzt also auch unser User “tuxer” dort einloggen.

Bisher ist auf dem Server der Zugang von Usern, die per LDAP erfasst wurden, aber noch gar nicht beschränkt worden, weil wir auf dem System “vms2” noch keine Änderung unserer ursprünglichen LDAP-Client-Konfiguration vorgenommen haben!

Für die Anwendung unseres Verfahrens 2 müssen die Einträge in der Datei “/etc/ldap.conf” auf “vms2” folgendermaßen aussehen:

# Group to enforce membership of
#pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com
pam_groupdn cn=vms2,ou=hosts,dc=anracona,dc=de

# Group member attribute
#pam_member_attribute uniquemember
pam_member_attribute uniquemember

oder im Fall der angesprochenen Alternative:

# Group to enforce membership of
#pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com
pam_groupdn cn=vms2,ou=hosts,dc=anracona,dc=de

#pam_groupdn - Eintrag
pam_member_attribute member

Nachdem wir unseren LDAP-Server hiermit ausgestattet haben, versuchen wir einen Positiv-Test mit dem User “tuxer”:

Hm, das ging so halb. Was soll aber die Meldung bzgl. des Home-Verzeichnisses? Hier bitte ich den Leser, noch einmal einen Blick in den Beitrag “LDAP IV” zu werfen. Aha, dort hatte ich die automatische Anlage von “home”-Verzeichnissen ja explizit ausgeschlossen ! Daher ist die Meldung nicht verwunderlich.

Für meinen User “tuxer” mache ich testweise mal eine Ausnahme :

vms2:~ # cp -r /etc/skel /home/tuxer
vms2:~ # chown -R tuxer.users /home/tuxer
vms2:~ #

Danach sieht die Sache schon besser aus:

Alles OK also mit unserem User “tuxer” ! Er hat nun die Ehre, sich auf unserem LDAP-Server einloggen zu dürfen. Unser Positiv-Test war offenbar erfolgreich.

Nun müssen wir aber noch einen Negativtest machen. Hierzu verwenden wir den User “tarja”:

Genauso wollen wir das !

Kombination beider Verfahren auf einem Host

Abschließend schauen wir uns interesserhalber an, was auf “vms1” passiert, wenn wir beide Verfahren kombinieren. Dazu erfassen wir den Host “vms1” zunächst mit Hilfe einer geeigneten LDIF-Datei “vms1.ldif” im Zweig “ou=hosts,dc=anracona,dc=de” des LDAP-Baums:

dn: cn=vms1,ou=hosts,dc=anracona,dc=de
# objectClass: device
objectClass: posixGroup
objectClass: groupOfUniqueNames
objectClass: extensibleObject
objectClass: ipHost
ipHostNumber: 192.168.0.11
cn: vms1.anracona.de
cn: vms1
uniqueMember: uid=tuxer,ou=people,dc=anracona,dc=de
gidNumber: 1

Diese Datei bringen wir auf “vms2” zur Anwendung:

vms2:~ # ldapadd -D "cn=Administrator,dc=anracona,dc=de" -w MY_LDAP_PASSWD -x -a -f hosts_vms1.ldif
adding new entry "cn=vms1,ou=hosts,dc=anracona,dc=de"

Der Check mit “gq” zeigt:

Auf “vms1” ändern wir nun die Datei “/etc/ldap.conf” so ab, dass (hoffentlich) auch Verfahren 2 zur
Anwendung kommt:

# Group to enforce membership of
#pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com
pam_groupdn cn=vms1,ou=hosts,dc=anracona,dc=de

# Group member attribute
#pam_member_attribute uniquemember
pam_member_attribute uniquemember

Bislang war ein Login von “tarja” auf “vms1” zwar nach dem ersten Verfahren zugelassen, aber nicht nach dem zweiten ! Dagegen ist unser User “tuxer” zwar nach dem zweiten Verfahren zugelassen, nicht aber nach dem ersten !

Wir erwarten daher, dass sich keiner der beiden User mehr auf “vms1” einloggen darf. Und tatsächlich:

Tarja darf nicht mehr auf “vms1” zugreifen. Und “tuxer” ?

Der darf auch nicht ! Ganz offenbar werden bei einer Kombination beider Verfahren also beide Zugangsberechtigungen geprüft !

Nun fügen wir “tarja” auf dem LDAP-Server auch dem “vms1”-Host-Eintrag als “uniquemember” hinzu:

Dann versuchen wir erneut, “tarja” auf “vms1” einzuloggen :

Alles wieder OK !

Abschließende Anmerkungen

Ich hoffe, dieser Ausflug in die LDAP-Welt unter Opensuse hat gezeigt, was man mit Yast2’s Hausmitteln machen kann und was nicht mehr.

Ein Server ist schnell angelegt, Hosts lassen sich auch relativ schnell als LDAP-Clients konfigurieren. Bei einer einfachen Useranlage unterstützt YaST2 hinreichend. Ebenso hilft YaST2 beim Umgenag mit einer zentralen Password Policy.

Bei der Konfiguration von Zugangsbeschränkungen für Hosts beißt es dann aber aus! Hier würde ich mir wünschen, dass YaST2 erweitert wird, damit auch User, die keine LDAP-Profis sind, eine Chance haben, LDAP sinnvoll in einem kleinen Netz einzusetzen.