Authentifizierung über eDirectory

From NJH-Wiki

Jump to: navigation, search
Autor 
Frank Prößdorf

Contents

Grundgedanken

Es gibt eine Vielzahl von Verzeichnisdiensten für alle möglichen Betriebssysteme (z.B. Active Directory bei Microsoft, OpenLDAP für Unix, SUN iPlanet für Solaris, NetWare Directory Service für NetWare). Der grosse Nachteil aller dieser Lösungen zeigt sich jedoch, sobald in einem Netzwerk mehrere Betriebssysteme und Anwendungen zusammen betrieben werden. Hier verwendet man nun Meta-Directories.

Ein Meta-Directory ist nicht an eine bestimmte Plattform oder einen Hersteller gebunden, sondern kann die Informationen aller Systeme verwalten und alle Betriebssysteme und Anwendungen mit den benötigten Informationen versorgen. Dabei werden alle Informationen an einer zentralen Stelle gesammelt und verwaltet und das Meta-Directory sorgt für die angepasste Verteilung der angeschlossenen Systeme.

Ein solches Meta-Directory ist zum Beispiel das um das Directory-Synchronisationstool Nsure Identity Manager (vormals DirXML) erweiterte eDirectory. Dies kann eine bidirektionale Verbindung zu anderen Verzeichnisdiensten we dem Active Directory herstellen und so veränderte Benutzerdaten und andere Strukturen abgleichen.

Aufgabe ist es die Authentifizierung von Linuxbenutzern an OpenLDAP in vorhandene Meta-Directory/eDirectory Strukturen zu integrieren. Das heisst wir wollen das LDAP Clients die Benutzerdaten aus dem Meta-Directory/eDirectory nutzt. Diese Aufgabe kann man grob in zwei Bereiche unterteilen. - LDAP Clients/Server in Struktur integrieren - Benutzer migrieren

Aufgabe ist es nun, die Authentifizierung von Linuxbenutzern an OpenLDAP in vorhandene Strukturen zu integrieren. Das heißt, es ist bereits ein eDirectory vorhanden (Novell's Implementation eines X.500-basierenden Directory Service) und wir wollen, dass die LDAP-Clients der Linux Rechnern auf das eDirectory oder das entsprechend höher liegende Meta-Directory zugreifen.

Diese Aufgabe kann man grob in zwei Schritte unterteilen:

  1. LDAP Clients/Server in Struktur integrieren
  2. Benutzer migrieren

Ausführung

LDAP Clients/Server in Struktur integrieren

Es gibt verschiedene Möglichkeiten LDAP Clients gegen ein eDirectory/Meta-Directory zu authentifizieren.

  1. Einmal der direkte Weg bei dem sich LDAP Clients direkt am eDirectory zu erkennen geben.
  2. Dann indem man einen OpenLDAP Server mit eDirectory oder zum Beispiel Novell's Meta-Directory Identity Manager synchronisiert und die Clients sich gegen den OpenLDAP server authentifizieren.
  3. Weiterhin gibt es für Novell's MetaDirectory auch einen Linux Treiber, der die Aktualisierung auf den Linux Clients direkt in den Files vornimmt.

Authentifizierungsmöglichkeit 1

Eine Lösungsmöglichkeit für den Weg ist:

  • Novell eDirectory für Linux System Authentication konfigurieren
    1. cd /usr/lib/nds-schema
    2. Die Datei "/usr/lib/nds-schema/rfc2307-usergroup.ldif" enthält das Schema das für die Authentifizierung notwendig ist
    3. Um nun das Schema zu erweitern: ndssch -h localhost -t YOUR_TREE ADMIN.FDN rfc2307-usergroup.sch
    4. In diesem Schema müssen nun noch die folgenden Änderungen mit der ConsoleOne vorgenommen werden:
    • Löschen der Mappings:
    • UID -> uidNumber
    • GID -> groupID
    • Hinzufügen der Mappings:
    • loginShell -> loginShell
    • uidNumber -> uidNumber
    • gidNumber -> gidNumber
    1. Refreshen des LDAP Servers
  • Nun muss man einen Proxy Benutzer erstellen der die Daten anonym abfragt
    1. Man muss sich zunächst als Administrator anmelden
    2. Man erstellt dann einen neuen Benutzer mit Passwort
    3. Bei den Accounteigenschaften das Recht zur Passwortänderung löschen
    4. Im Tree Root Objekt im entsprechenden Unterbaum folgende Rechte an den Proxy User verteilen:
    • Lesen
    • Vergleichen
    • Durchsuchen
    1. Nun den LDAP Server refreshen
  • Was man jetzt tun muss, ist Accounts "linuxfähig" zu machen
    1. Nachdem man rechts auf einen angewählten Benutzer geklickt hat
    2. Wählt man "Extensions of this Object..."
    3. und klickt auf "Add Extension..."
    4. Auszuwählen ist "posixAccount"
    5. Und nun die entsprechenden Felder ausfüllen:
    • Name: posixAccount
    • homeDirectory: /home/proessdo
    • uniqueID: proessdo
    • Common Name: Frank Prößdorf
    • gidNumber: 515
    • uidNumber: 515
    • loginShell: /bin/bash (Other)
  2. Jetzt bleibt nur noch den Client zu konfigurieren
    1. Hierzu trägt man in die /etc/ldap.conf und /etc/openldap/ldap.conf folgendes mit ein 
base ou=vertrieb,o=firma
uri ldap://hostname ldap://hostname2
binddn cn=proxyuser,o=firma
bindpw secret
pam_password nds

Es ist möglich bei der URI mehrere Server anzugeben. Fällt der erste Server aus springt dann der zweite ein.

  • Nun muss man noch entsprechend dieses Tutorial weiter oben PAM ändern und der Benutzer kann sich gegen das eDirectory authentifizieren
  • Wollen wir den Verkehr jetzt noch durch Verschlüsselung absichern so fügen wir einfach in die /etc/ldap.conf und in die /etc/openldap/ldap.conf die Zeile ssl start_tls. Haben wir dies getan so können wir beobachten wie Client und Server sich je ein Paket mit der OID 1.3.6.1.4.1.1466.20037 schicken, was Start TLS bedeutet, und wie danach jegliche Transaktion verschlüsselt stattfindet.

sudo

  • Wollen wir das ganze sudo-fähig machen müssen wir das weiter oben dargestellte sudo LDAP Schema ins NDS Format bringen was so aussehen könnte: 
-- Sudo LDAP Schema Definitions
-- Frank Prößdorf
-- Straße XYZ
-- Berlin

-- Schema Source:		ldap_sudo.sch
-- Description:			Schema definitions for having sudoers support
-- %version:			0.1
-- %date_modified:		Thu Feb 23 15:14:47 2006 %

SUDOSchemaExtentions DEFINITIONS ::=
BEGIN

-- DESC 'the SUDOers Object Class'
"sudoRole" OBJECT-CLASS ::=
{
	Operation	ADD,
	SubClassOf	{"TOP"},
	Flags		{DS_AUXILIARY_CLASS},
	MustContain	{"CN"},
	MayContain	{"sudoUser", "sudoHost", "sudoCommand", "sudoRunAs", "sudoOption", "description"},
	ASN1ObjID	{1 3 6 1 4 1 15953 9 2 1}	
}


-- DESC 'User(s) who may  run sudo'
"sudoUser" ATTRIBUTE ::=
{
	SyntaxID	SYN_CI_STRING,
	Flags		{ DS_SINGLE_VALUED_ATTR },
	ASN1ObjID 	{1 3 6 1 4 1 15953 9 1 1}
}

-- DESC 'Host(s) who may run sudo'
"sudoHost" ATTRIBUTE ::=
{
	SyntaxID	SYN_CI_STRING,
	Flags		{ DS_SINGLE_VALUED_ATTR },
	ASN1ObjID 	{1 3 6 1 4 1 15953 9 1 2}
}

-- DESC 'Command(s) to be executed by sudo'
"sudoCommand" ATTRIBUTE ::=
{
	SyntaxID	SYN_CI_STRING,
	Flags		{ DS_SINGLE_VALUED_ATTR },
	ASN1ObjID 	{1 3 6 1 4 1 15953 9 1 3}
}

-- DESC 'User(s) impersonated by sudo'
"sudoRunAs" ATTRIBUTE ::=
{
	SyntaxID	SYN_CI_STRING,
	Flags		{ DS_SINGLE_VALUED_ATTR },
	ASN1ObjID 	{1 3 6 1 4 1 15953 9 1 4}
}

-- DESC 'Options(s) followed by sudo'
--       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
"sudoOption" ATTRIBUTE ::=
{
	SyntaxID	SYN_CI_STRING,
	Flags		{ DS_SINGLE_VALUED_ATTR },
	ASN1ObjID 	{1 3 6 1 4 1 15953 9 1 5}
}

END

Nach dem Einspielen kann man den Benutzern nun eine Objektklasse sudoRole zuordnen und dann entsprechend die Attribute setzen. Anschliessend verfahren wir wie im OpenLDAP sudo Howto beschrieben. D.h. sudoers_base hinzufügen etc.

Wichtig : Falls die Benutzer mit der sudo Erweiterung nicht in einen einzigen sudoers Container sollen, sondern in einem Unterbaum verteils sind, muss man die ldap.c des Sudopaketes vor dem Kompilieren so anpassen, das alle SEARCH_SCOPE_ONELEVEL gegen SEARCH_SCOPE_SUBTREE ausgetauscht werden, so das beim Durchsuchen nach sudoUsern auch der ganze Unterbaum durchsucht wird.

Authentifizierung 2

Hier geht es nun darum, dass sich die Clients gegen einen OpenLDAP Server authentifizieren, der die gleichen Daten wie das eDirectory beinhaltet. Hier gibt es theoretisch wiederum zwei Möglichkeiten.

  1. eDirectory und OpenLDAP replizieren sich automatisch
  2. Man exportiert die Daten des eDirectorys und importiert sie in den OpenLDAP Server

Automatische Replikation

Hier gibt es auf OpenLDAP Seite zwei Lösungsmölichkeiten.

  • Einmal das noch nicht fertige jedoch schon implementierte syncrepl welches nach dem LDUP Sync Draft implementiert wurde
  • und einmal das schon vorgestellte Replizieren über slurpd.

Wenn man die Hilfestellung zum syncrepl liest fällt einem folgender Satz auf: "While slapd (8) can function as the LDAP Sync provider only when it is configured with either back-bdb or back-hdb backend, the syncrepl engine, which is a consumer-side replication engine, can work with any backends.". Da eDirectory weder back-bdb noch back-hdb als backend benutzt noch eine sid, welche das Session Log beschreibt, beinhaltet fällt diese Möglichkeit augenscheinlich zunächst ins Wasser.

Weiterhin erscheint es ebenfalls als wenn auch die zweite Möglichkeit nicht genutzt werden kann, da auf dem Master kein slurpd läuft und sich somit der Client auch nicht die veränderten Daten holen kann.

Auf Meta-Directory Seite gibt es wiederum eine teure Lösung. Das ist ein Treiber für den Identity Manager, der die Daten mit allen LDAP Version 3 kompatiblen Implementierungen austauschen kann.

Export und Import der Daten

Betrachtet man diese Möglichkeit so würde man die Daten nachdem man sie als ldif exportiert hat über ldapadd bzw. ldapmodify wiederum importieren. Hierbei ist der Zeitfaktor zu beachten. Wie oft soll aktualisiert werden?

Ich komme an das Passwort im eDirectory nicht ran. Wie heisst das Attribut? Authentifizierung funktioniert laut einer Studienarbeit und nach Beobachten mit ethereal so, dass zuerst mit einer Suchanfrage nach der uid der distinguishable name (DN) abgefragt wird und danach versucht wird mit diesem einen LDAP Bind an das Verzeichnis zu starten, wobei gleichzeitig eine Frage in Form einer OID (1.3.6.1.4.1.42.2.27.8.5.1) gestellt wird ob das Passwort (noch) okay ist. Der Server hat darauf mehrere Antwortmöglichkeiten.

Authentifizierungsmöglichkeit 3

NIS/Files Treiber für das eDirectory ist natürlich eine teure Alternative.

http://fp.njh6.de/dirxml_linux.PNG

Bei diesem Treiber für den Identity Manager gibt es zwei Kanäle. Durch den einen werden Änderungen vom eDirectory in die Files geholt (Subscriber) und durch den anderen werden Änderungen an den Daten in den Konfigurationsdateien auf den Linux Clients zurück ins eDirectory publiziert (Publisher).

Wie bring ich den Treiber zum laufen?

Um einen DirXML Treiber zu aktivieren muss innerhalb von 90 Tagen nach der Installation folgendes geschehen:

  • DirXML Lizenz kaufen
  • Eine Produktaktivierungsanfrage erstellen
  • Die Produktaktivierungsanfrage abschicken
  • Die Informationen die man von Novell erhält im Nachhinein installieren
Auf den Linux Clients

Um den Treiber zu starten muss man den Remote Loader nutzen oder aber eDirectory und DirXML Engine 2.0 lokal installiert haben.

  • Wir starten als root das nis-drv-install Script.
  • Folgende Dateien werden installiert:
    • NDS2NIS.jar - Treiber Jar Datei, die in /usr/lib/dirxml/classes installiert wird
    • dxnis - Kommando in /usr/sbin
    • Vorkonfigurierte XML Dateien in /usr/lib/dirxml/rules/nds2nis
    • pam_xmdl - Bibliothek im selben Verzeichnis die genutzt wird um das Passwort abzufangen
  • Nun wollen wir das PAM Modul einrichten. Hierzu müssen wir es auf den Clients konfigurieren: 
 nis-drv-config -pam
  • Und tragen danach in die /etc/pam.d/passwd folgende Zeile mit ein: 
 password required pam_dxml.so host=<IP> db=nis mapfilesdir=/var/yp/nisdomain shadowmerged=true
  • Wir installieren nun den Remote Loader der im Identity Manager mitgeliefert wird. Die Passwörter sind die im eDirectory festgelegten. 
mkdir /usr/local/remote_loader
cd /usr/local/remote_loader
touch com.novell.nds.dirxml.driver.nisdriver.NISDriverShim
/usr/bin/rdxml -config com.novell.nds.dirxml.driver.nisdriver.NISDriverShim <remoteloadpass> <driverpass>
/usr/bin/rdxml -config com.novell.nds.dirxml.driver.nisdriver.NISDriverShim
Im eDirectory
  • Require TLS for simple Binds muss im eDirectory ausgestellt werden
  • Wir starten 
 nis-drv-config -h hostname -D adminContext -w adminPassword -x
  • Im iManager erstellen wir unter DirXML Utilities einen neuen Treiber
  • Nachdem wir den Namen ausgesucht haben wählen wir Files für die Speicherung in lokalen Dateien
  • Wir wählen unsere enstsprechenden Optionen (also zum Beispiel: Ja, erstelle ein Homeverzeichnis wenn Benutzer erstellt wird)
  • Desweiteren wählen wir bidirektionale Kommunikation so das Benutzer von Linux aus ihr Passwort ändern können und Benutzer aber auch über das eDirectory angelegt werden können.

Benutzer migrieren

Um nun die Benutzer zu migrieren muss man zunächst die vorhandenen Linuxmaschinen durchgehen und die Benutzer einsammeln und die UIDs vereinheitlichen. Dazu kann man folgende zwei Schritte unternehmen:

  • Sammeln der Benutzer, UIDs und Gruppen
  • Verteilen der vereinheitlichten UIDs auf den servern

Sammeln der Benutzer, UIDs und Gruppen

Eine solche Prozedur zur Sammlung der UIDs und Gruppen könnte ein PHP Script sein, dass die Daten zum Beispiel in Dokuwiki Tabellenformat umwandelt. Mit diesem Script bekommt man eine Tabelle der UIDs.

Austeilen der neuen UIDs

Nun kann man zum Ändern der UID des Benutzers und aller seiner Dateien wieder ein PHP Script verwenden. Es enthält ein Array mit den Benutzernamen und neuen UIDs. Zunächst werden alle Dateien des Benutzers zusammen gesammelt. Dann wird die UID in der /etc/passwd geändert und zu letzt wird der owner der gesammelten Dateien auf die neue UID gesetzt.

NDS Schema HOWTO

Erklärung

Es kann passieren das wir in das eDirectory neue Schema Dateien einfügen wollen um zusätzliche Funktionalität zu gewährleisten. Dies ist zum Beispiel der Fall wenn wir eDirectory sudo-fähig machen wollen. Nun haben wir aber meist nur ein LDAP Schema, was entsprechend abgeändert werden muss, da eDirectory es in diesem Format nicht versteht. Hierzu gleich mal ein direkter Vergleich:

NDS Schema 

-- Sudo LDAP Schema Definitions
 
SUDOSchemaExtentions DEFINITIONS ::=
BEGIN
 
"sudoRole" OBJECT-CLASS ::=
{
	Operation	ADD,
	SubClassOf	{"TOP"},
	Flags		{DS_AUXILIARY_CLASS},
	MustContain	{"CN"},
	MayContain	{"sudoUser", "sudoHost", "sudoCommand", "sudoRunAs", "sudoOption", "description"},
	ASN1ObjID	{1 3 6 1 4 1 15953 9 2 1}	
}
 
-- this is the user name of the sudo User
"sudoUser" ATTRIBUTE ::=
{
	SyntaxID	SYN_CI_STRING,
	Flags		{ DS_SINGLE_VALUED_ATTR },
	ASN1ObjID 	{1 3 6 1 4 1 15953 9 1 1}
}


LDAP Schema 

#
# Sudo LDAP Schema Definitions
#

objectclass ( 1.3.6.1.4.1.15953.9.2.1 
      NAME 'sudoRole' 
      SUP top STRUCTURAL
      DESC 'Sudoer Entries'
      MUST ( cn )
      MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoOption $
            description )
      )

attributetype ( 1.3.6.1.4.1.15953.9.1.5
      NAME 'sudoOption'
      DESC 'Options(s) followed by sudo'
      EQUALITY caseExactIA5Match
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Syntax

Wie wir aus diesem Beispiel leicht erkennen können gibt es doch recht große Unterschiede zwischen den beiden Schema Formaten. Hier also eine Gegenüberstellung in tabellarischer Form:

NDS Format OpenLDAP Format LDAPv3 Spezifikation
Kommentare: Werden hier durch -- eingeleitet Werden wie Unixüblich mit # eingeleitet Es ist im Protokoll nicht definiert wie Kommentare in Schemadateien auszusehen haben.
Allgemein: Die Parameter der Objekte werden durch Komma getrennt in geschweiften Klammern geschrieben Hier werden die Parameter durch NewLine getrennt und Parameternamen werden groß geschrieben In jeder Objektdefinition müssen wenigstens die vier Attribute cn (hier: Name), objectClass (hier Subklasse), objectClasses, attributeTypes.
ObjektID: Wird hier in der Objektdeklaration über ASN1ObjID {1 2 3 4 5 67890 1 2 3} Steht am Anfang der Objektdeklaration direkt hinter der runden Klammer im Format 1.2.3.4.5.67890.1.2.3 Der Objekt Identifier kann einen gepunkteten numerischen Wert als Repräsentation annehmen
Name: Wird als Objektdeklaration gleich an den Anfang in " geschrieben also zum Beispiel "sudoUser" ATTRIBUTE ::= Wird als Name Parameter im Objekt deklariert und in Hochkommata geschrieben: NAME 'sudoRole'
Objektklasse: Für must und may Optionen wird ein MustContain und MayContain angegeben, wobei die Inhalte der geschweiften Klammern in " stehen Für must und may werden genau die Wörter genutzt also MUST (cn) zum Beispiel Jedes neue Objekt im LDAP muss mindestens eine Objektklasse haben. Durch diese werden die Attribute definiert die man für das Objekt verwenden kann.
Beschreibung: Wird, wenn vorhanden, als Kommentar übers Objekt geschrieben Wird durch DESC 'kommentar' gemacht
Subklasse: Wird in der Objektklasse als SubClassOf {"TOP"} definiert Wird als Parameter in der Form SUP top übergeben Eins der vier Attribute die in jedem Objekt vorhanden sein müssen. Es muss wenigstens "top" mit angegeben werden. Dabei handelt es sich natürlich auch um eine Objektklasse.
Operation: In einer Objektklasse muss man mitangeben welche Operation man ausführen möchte, das heisst entweder ADD oder MODIFY, wenn die Objektklasse zum Beispiel schon existiert Hier habe ich so etwas bisher nicht gefunden
Vergleichsregeln: SyntaxID im Attributobjekt gibt an welche Art von Daten das Attribut beinhaltet. Also zum Beispiel String, Integer und ähnliches. Es sind u.a. folgende Attributtypen möglich: SYN_CE_STRING, SYN_CI_STRING, SYN_PR_STRING, SYN_NU_STRING, SYN_BOOLEAN, SYN_INTEGER, SYN_OCTET_STRING, SYN_TEL_NUMBER, SYN_FAX_NUMBER, SYN_NET_ADDRESS, ... Hier gibt man über EQUALITY an was für ein Datentyp verwendet werden kann, bespielsweise: EQUALITY numericStringMatch oder EQUALITY booleanMatch Mit diesen Vergleichsregeln wird angegeben wie der Server den bei einer Anfrage erhaltenen Wert mit dem gespeicherten Abstrakten Datenwert vergleichen soll. Diese können wiederum entweder in Form eines String oder in Form der OID angegeben werden. IA5 steht hierbei für ASCII Strings.
Flags: Weitere Definition der Attribute. Zum Beispiel wird gesagt ob das Attribut mehrere Werte beinhalten kann. Hier sind mögliche Varianten: DS_SINGLE_VALUED_ATTR, DS_SIZED_ATTR, DS_HIDDEN_ATTR, DS_STRING_ATTR, DS_PUBLIC_READ, ... Ich weiß nicht ob es sowas für LDAP gibt. Möglicherweise im EQUALITY mit drin

Bitte ergänzen, berichtigen und vervollständigen.

Siehe auch

Quellen und weiterführende Informationen sind hier zu finden.

Retrieved from "http://wiki.njh.eu/Authentifizierung_%C3%BCber_eDirectory"
Personal tools