Copyright 2016 Lexmark. All rights reserved. Lexmark is a trademark of Lexmark International, Inc., registered in the U.S. and/or other countries.

Transkript

1 Best Practice LDAP

2 Copyright 016 Lexmark. All rights reserved. Lexmark is a trademark of Lexmark International, Inc., registered in the U.S. and/or other countries. All other trademarks are the property of their respective owners. No part of this publication may be reproduced, stored, or transmitted in any form without the prior written permission of Lexmark.

3 Inhaltsverzeichnis 1 Was ist LDAP?... LDAP und SAPERION....1 Vorbemerkungen.... Ablauf einer LDAP-Synchronisation Verbindung zum LDAP-Server herstellen..... Anmelden am LDAP-Server SSL-Authentifizierung Rekursives Durchlaufen ab BaseDN Erzeugen von Gruppen und Organisationseinheiten Update der Benutzerverwaltung....3 Single Sign-On Ablauf Single Sign-On gegen Active Directory Einrichtung Single Sign-On für ADS....4 INI-Einträge Sektion [LDAP Sync] Sektion [LDAPMapping.User]....5 Wichtige Hinweise Ändern des Passwortes eines synchronisierten Benutzers Synchronisation mit ADS Mandantenfähige Systeme Globale Suche Verwenden von Filtern... 3 Glossar DIT (Directory Information Tree) DN (Distinguished Name) LDIF (LDAP Data Interchange Format) RDN (Relative Distinguished Name) SASL (Simple Authentication and Security Layer) X

4 Best Practice LDAP 1 Was ist LDAP? LDAP (Lightweight Directory Access Protocol) ist ein auf dem Client/ Server-Modell basierendes Anwendungsprotokoll, das die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes über das TCP/IP-Netzwerk erlaubt. Bei einem Verzeichnisdienst (directory services) handelt es sich um eine im Netzwerk verteilte hierachische Datenbank. LDAP beschreibt die Kommunikation zwischen dem sog. LDAP-Client und dem Verzeichnis (Directory Server), aus dem objektbezogene Daten, wie beispielsweise Personendaten oder Rechnerkonfigurationen, ausgelesen werden. So kann das Verzeichnis beispielsweise ein Adressbuch enthalten. Sucht ein Anwender nun eine bestimmte Mailadresse, stößt er die Aktion "Suche die Mailadresse xyz" an. Der -Client formuliert eine entsprechende LDAP-Abfrage an das Verzeichnis, das die Adressinformationen bereitstellt. Das Verzeichnis formuliert die Antwort und übermittelt sie an den Client. Im administrativen Sprachgebrauch hat sich inzwischen für einen Directory-Server, dessen Datenstruktur der LDAP-Spezifikation entspricht und der über das LDAPv3-Protokoll Daten austauscht, die Bezeichnung LDAP-Server eingebürgert. Das Protokoll bietet alle Funktionen, die für eine solche Kommunikation notwendig sind: Anmeldung am Server Formulierung der Suchabfrage Modifikation der Daten Die aktuelle LDAP-Spezifikation ist die Version RFC Neuere über RFC 51 hinausgehende Implementierungen berücksichtigen die Replikation der Daten zwischen verschiedenen Verzeichnissen. LDAP und SAPERION.1 Vorbemerkungen Bei LDAP handelt es sich um eine Zugriffsmethode auf einen Verzeichnisdienst. Es gibt davon mehrere, wie beispielsweise Active Directory, SUNOne usw. SAPERION sieht genau das, was ein LDAP-Browser (z.b. jxplorer) auch sieht. Bitte beachten Sie folgende Merkmale: Standardports Der Standardport für LDAP ist 389. Wird ein anderer Port verwendet, muss dieser explizit angegeben werden. Wenn beispielsweise bei Active Directory über Domaingrenzen hinweg gesucht wird ("Global Catalog"), muss hinter der Serveradresse "368" für den entsprechenden Port eingeben werden.

5 LDAP und SAPERION Der Standardport für LDAPS ist 636. Wird ein anderer Port verwendet, muss dieser explizit angegeben werden. Zertifikat Folgende Zertifikat-Formate werden unterstützt: PEM DER LDAP-Systeme Folgende LDAP-Systeme werden unterstützt: OpenLDAP Windows Domäne. i Ablauf einer LDAP-Synchronisation Die nachfolgenden Punkte gelten für alle LDAP-Systeme. Wenn alle Punkte erfüllt sind, ist eine Synchronisierung (ohne Single Sign-On) möglich. Die Synchronisation der SAPERION Benutzerverwaltung läuft nach dem folgenden Schema ab: i Verbindung zum LDAP-Server wird hergestellt Anmeldung an den LDAP-Server Rekursives Durchlaufen ab BaseDN Erzeugung von Gruppen und Organisationseinheiten Update der Benutzerverwaltung Beim folgenden Beispiel handelt es sich um eine Synchronisation mit OpenLDAP. Die zu verwendenden Anmeldedaten sind abhängig vom verwendeten LDAP-System (z.b. edirectory, Active Directory). Verbindung zum LDAP-Server herstellen Um eine Verbindung zum LDAP-Server herstellen zu können, muss dessen IPAdresse bekannt sein, die bei den Anmeldedaten eingegeben werden muss. Der Standardport ist Port 389. Der Port muss nur dann angegeben werden, wenn ein abweichender Standardport verwendet wird. i Bei der Nutzung von Zertifikaten kann hier der Name der Zertifikatsdatei angegeben werden. Anmelden am LDAP-Server Für die Anmeldung am LDAP-Server müssen neben der IP-Adresse des LDAP-Servers folgende Daten angegeben werden: Benutzer (DN) 3

6 4 Passwort BaseDN Der Benutzer muss im LDAP-Directory existieren und das Recht haben, das Directory zu durchsuchen. Der Benutzer wird als DN, also "Distinguished Name" angegeben (z.b. "cn=admin,dc=nodomain"). Über den DN wird ein Objekt im LDAP Directory eindeutig identifiziert. Abb. 1: LDAP Directory In der Schemaerweiterung der SAPERION Benutzerverwaltung muss das eindeutige Feld "UID" existieren, das auf ein eindeutiges Feld im LDAP-Schema gemappt ist. Der Parameter "UID" dient dazu, dass sich nach der Änderung des DN eines AD-Benutzers (z.b. Verschiebung in andere OU) die ID des SAPERION-Benutzers bei einer Benutzersynchronisation nicht ändert. Dies ist vor allem wichtig bei einem Einsatz von ACLs. Für Single SignOn unter Active Directory gibt es ein weiteres Attribut "GUID", welches unabhängig von "UID" wirkt. Abb. : LDAP-Zuordnung

7 LDAP und SAPERION Bei Active Directory kann als eindeutiges Feld z.b. "objectguid" verwendet werden. Abb. 3: LDAP-Anmeldung Die BaseDN (=Context) ist der Startcontainer im LDAP, wo nach Benutzern gesucht werden soll. In der obigen Abbildung könnte dies z.b. die Organisationseinheit "development" sein. In diesem Fall müsste als BaseDN "ou=development,o=saperion" angegeben werden. SSL-Authentifizierung Es gelten folgende Voraussetzung für eine SSL-Authentifizierung: das SSL-Zertifikat muss vorliegen der Herausgeber des Zertifikats muss ebenso als Zertifikat vorliegen Wenn Sie im Anmelde-Dialog die Authentifizierung "SSL" ausgewählt haben, müssen Sie im Feld "Zertifikat" den Pfad zum entsprechenden Herausgeber-Zertifikat angeben. Abb. 4: SSL-Zerfitifikat angeben! Die Zertifikate müssen von allen Installationen, die die Zertifikate verwenden wollen, z.b. Adminclient, Java Core Server, erreichbar sein. Der Pfad zu den Zertifikaten wird in der zentralen PROGRAM.INI am Core Server gespeichert. In einem Mehrserversystem muss die PROGRAM.INI auf anderen Servern ggf. entsprechend angepasst werden. Rekursives Durchlaufen ab BaseDN Ausgehend vom BaseDN (Context) werden rekursiv alle Benutzer, die der Filterbedingung entsprechen aufgesammelt. Gerade bei großen LDAP-Directories wird der Einsatz von Filtern empfohlen, da ansonsten der Synchronisationsvorgang erhebliche Zeit in Anspruch nehmen kann. 5

8 6 Abb. 5: LDAP-Synchronisation Im Beispiel werden nur die Benutzer übernommen, die im Attribut "l" (Location) den Wert "Berlin" haben, also alle Benutzer aus Berlin. Erzeugen von Gruppen und Organisationseinheiten Bei der Synchronisation werden die einzelnen Gruppen ausgewertet. Dabei wird anhand bestimmter Felder überprüft, welche Benutzer Mitglieder in diesen Gruppen sind. Das entsprechende Feld, das ausgewertet wird, ist abhängig vom verwendeten LDAP-Server. Möglich sind die folgenden Felder: member (z.b. Domino, OpenLDAP) uniquemember (z.b. SunOne) memberuid (z.b. OpenLDAP) Wenn ein Benutzer, der Mitglied einer Gruppe ist, den Filterkriterien entspricht, wird die zugehörige Gruppe in der Benutzerverwaltung von SAPERION erzeugt. i Bei Active Directory werden die Benutzer direkt ausgewertet. Das heißt, bei den Benutzern wird überprüft, in welchen Gruppen sie Mitglied sind. Diese Gruppen werden dann in der Benutzerverwaltung von SAPERION erzeugt (wenn der Benutzer den Filterkriterien entspricht). Was unbedingt berücksichtigt werden muss Um sicherzustellen, dass Gruppen aus dem LDAP synchronisiert werden, muss der Schalter IncludeGroupMembers=TRUE gesetzt werden (Sektion [LDAP Sync]). Beim Setzen der Filterbedingung sollte berücksichtigt werden, dass ein Benutzer nur in maximal 50 Gruppen Mitglied sein kann. Wenn ein Benutzer in mehr als 50 Gruppen Mitglied ist, scheitert die Synchronisation. Beim Synchronisieren von Gruppen ist zu berücksichtigen, dass die primären Gruppen des Benutzers nicht in jedem Fall synchronisiert werden. In der Regel ist dies die Gruppe "Domain Users". Es sollten keine Berechtigungen auf Basis dieser Gruppen vergeben werden. Update der Benutzerverwaltung Anhand des eindeutigen Feldes wird in der SAPERION Benutzerverwaltung geprüft, ob der Benutzer bereits existiert. Wenn er nicht existiert, wird er angelegt.

9 LDAP und SAPERION i Wenn für die Synchronisierung die Checkbox "Nur existierende Benutzer synchronisieren" aktiviert ist, ist auf LDAP-Seite ebenfalls ein eindeutiges Feld "UID" erforderlich. Löschen von Benutzern Bei der Synchronisation werden Benutzer in der SAPERION Benutzerverwaltung nur gelöscht, wenn die Methode "nur existierende Benutzer" gewählt wird und zusätzlich der Haken "Löschungen berücksichtigen" gesetzt wird. Im ADS deaktivierte Benutzer werden auch in SAPERION mit dem Hinweis "Konto gesperrt" versehen. Wird der Benutzer im ADS wieder aktiviert wir auch die Kennzeichnung im SAPERION wieder entfernt..3 Single Sign-On Derzeit nur für Active Directory verfügbar. Bei der Anmeldung bekommt der Core Server als Login-Parameter Domäne Benutzername. Der Core Server schickt die Anfrage, ob dieser Benutzer in der Domäne existiert, an den Domain-Controller (DC). Ist dies der Fall, gibt der DC den DN des Benutzers zurück. Jetzt schaut der Core Server in seiner Benutzerdatenbank nach, ob dieser Benutzer existiert. Wenn ja, wird das Single Sign-On ausgeführt. Um ein Single Sign-On durchzuführen, muss zunächst ein Schema-Mapping durchgeführt werden. Auf das einzufügende Feld "GUID" muss die LDAP-Eigenschaft "objectguid" gemappt werden. i Das Attribut "GUID" ist nicht mit dem Attribut "UID" verknüpft und ist nur für Single Sign-On wirksam. Durch eine Benutzersynchronisation wird nun die passende ID des Benutzers in das Feld gemappt. Es handelt sich dabei um eine weltweiteindeutige ID, die eine Zuordung des Benutzers komplett sicher macht. Für die Single Sign-On Anmeldung muss der Benutzer so in die Domäne integriert sein, dass er alle Account Informationen vom Domain Controller erhalten kann. Zum Test kann hier das von SAPERION zur Verfügung gestellte Tool "GetUserName.exe" verwendet werden. Nach dem Start muss die "GUID" des angemeldeten Benutzers angezeigt werden. Versucht der Benutzer nun ein Single Sign-On, so werden am Client der DN und die "ObjectGUID" des Benutzers ermittelt und an den Core Server übertragen. Dieser überprüft nun, ob die Informationen mit den ihm bekannten Informationen zusammen passen und lässt nur dann das Login zu. Aufgrund der Eindeutigkeit der "GUID" ist ein Manipulationsversuch durch einen gleichnamigen Account nicht möglich. Ablauf Single Sign-On gegen Active Directory Am Client wird über WIN-API der Distinguished Name des angemeldeten Benutzers und die Windows-GUID (ObjectGUID), die dem Benutzer zugeordnet ist ermittelt. Um die GUID zu ermitteln, muss der Client-Rechner mit dem Domain-Controller kommunizieren können. Name und GUID werden an den Core Server geschickt. Der Core Server sucht in seiner Benutzerverwaltung nach dem Benutzer. Wenn es eine Schemaerweiterung mit dem Feld "GUID" gibt, werden die Inhalte von "GUID" und "ObjectGUID" miteinander verglichen. Fällt der Vergleich positiv aus, ist die Anmeldung erfolgreich. 7

10 8 Einrichtung Single Sign-On für ADS Um gegen ADS über LDAP synchronisieren zu können muss in der Schemaerweiterung von SAPERION das eindeutige Feld "UID" auf das Feld "ObjectGUID" im LDAP gemappt werden. Hierfür sind folgende Schritte erforderlich: Erstellen der Systemtabelle "XSUSR_Schema" durch einen Doppelklick auf das Feld neben "Benutzer" in der Spalte "Tabelle" der Schemaerweiterung. Hinzufügen des Feldes "GUID", wobei dieses Feld eindeutig sein muss. Mappen des Feldes in der Schemaerweiterung mit "ObjectGUID". Es handelt sich dabei um eine weltweiteindeutige ID, die eine Zuordung des Benutzers komplett sicher macht. Die "ObjectGUID" bleibt für die Existenz des Benutzers konstant..4 INI-Einträge Sektion [LDAP Sync] In der Sektion [LDAP Sync] existieren folgende INI-Einträge: [LDAP Sync] SynchedWithOS= IncludeGroupMembers=TRUE Count=1 Number of LDAP server Server1= Parameter der Sektion [LDAP Sync] Parameter Beschreibung SynchedWithOS Bewirkt, dass bei der Neuanlage von Benutzern über die LDAP-Synchronisation die Checkbox "Mit Betriebssystem synchronisiert" deaktiviert wird. Standardmäßig ist FALSE eingestellt. IncludeGroupMembers Bewirkt, dass bei der Synchronisation mit LDAP (außer Active Directory) die Gruppen der Benutzer mit übernommen werden. Standardmäßig ist diese Option ausgeschaltet. Count Enthält die Liste der LDAP-Server. Sektion [LDAPMapping.User] LDAP-Zuordnung für Benutzer (Schemaerweiterung). =mail Language=preferredLanguage Passwd=userPassword Description=description uid=objectguid guid=objectguid DisplayName=(EXIST uid)?uid:(givenname " " sn)

11 LDAP und SAPERION.5 Wichtige Hinweise Ändern des Passwortes eines synchronisierten Benutzers Der Administrator eines SAPERION-Systems kann das Passwort eines synchronisierten Benutzers ändern. Dazu muss er lediglich die Checkboxen "Synchronisieren mit Betriebssystem" und "Synchronisieren mit LDAP" deaktivieren. Dieses Verhalten ist so beabsichtigt. Wenn die Möglichkeit der Änderung der Passwörter von synchronisierten Benutzern ausgeschlossen werden soll, wird folgende Vorgehensweise empfohlen: Setzen einer ACL auf den betreffenden Benutzer Festlegen eines technischen SAPERION-Benutzers, der für diese ACL Berechtigungen erhält Passwort dieses technischen SAPERION-Benutzers ist zwei unabhängigen Administratoren zur Hälfte bekannt Der technische SAPERION-Benutzer ist durch dieselbe ACL geschützt i Der technische Benutzer und seine ACL muss ebenfalls durch die angelegte ACL geschützt sein. Synchronisation mit ADS Für die Synchronisation mit ADS sollte ein Feld gemappt werden, das auch standardmäßig gefüllt wird. Mandantenfähige Systeme Bei mandantenfähigen Systemen muss immer im Kontext eines Mandanten synchronisiert werden. Globale Suche Wenn "Global Search" angekreuzt ist, werden keine Container-Objekte ab dem BaseDN (Context) als Gruppen übernommen. Im anderen Fall werden im Baum angetroffene Container als Gruppen übernommen. Wenn Sie keinen BaseDN angeben, beginnt die Suche beim Context des Login-Parameter. Bei der globalen Suche werden nur bereits existierende Benutzer im LDAP gesucht und abgeglichen. Neue Benutzer und Gruppen werden nicht übernommen. Dabei werden alle Objekte unterhalb des BaseDN synchronisiert. Verwenden von Filtern Die Filter müssen so gebaut sein, dass das Attribut mit dem Wert verglichen wird. Beispiel "l=berlin" Bei "MemberOf" müssen Sie aufpassen, da "MemberOf" vom Typ Distinguished Name (DN) ist. Dort ist in Active Directory (AD) standardmäßig keine Wildcard-Suche möglich, sondern nur direkte Stringvergleiche. 9

12 10 Man kann aber prinzipiell in der Active Directory einen DB-Index aufbauen, über den die Wildcard-Suche dann realisiert wird. Nachteil hierbei ist jedoch, dass bei großen Active Directories die Performance der Active Directory selbst beeinträchtigt werden kann. 3 Glossar 3.1 DIT (Directory Information Tree) Die hierarchische Baumstruktur wird als Directory Information Tree (DIT) bezeichnet, der den gesamten von einem Server vorgehaltenen Namensraum abbildet. 3. DN (Distinguished Name) Der Distinguished Name ist ein globaler, autoritärer Name einer Instanz im OSI-Directory nach X.500. Der Distinguished Name ist ein im gescannten Datenbestand eindeutiger Name. Beispiel uid=admin, dc=structure-net, dc=de 3.3 LDIF (LDAP Data Interchange Format) Es handelt sich hierbei um ein ASCII basierendes Dateiformat, welches zum Datenaustausch genutzt wird und welches die Synchronisation der Daten mit Hilfe eines LDAP-Servers unterstützt. Beispiel dn: dc=saperion, dc=de objectclass: organization objectclass: top o: Structure Net l: Berlin postalcode: 1063 streetadress: Steinplatz dn: ou=sales, dc=saperion, dc=de objectclass: organizationalunit ou: Sales description: Verkauf telephonenumber: facsimiletelephonenumber: dn: ou=development, dc=saperion, dc=de objectclass: organizationalunit ou: Development description: Entwicklung telephonenumber: facsimiletelephonenumber: dn: ou=support, dc=saperion, dc=de

13 3 Glossar 11 objectclass: organizationalunit ou: Support description: Support telephonenumber: facsimiletelephonenumber: dn: uid=admin, dc=structure-net, dc=de objectclass: person objectclass: organizationalperson objectclass: inetorgperson cn: admin cn: Systemverwalter cn: SAPERION sn: SAPERION uid: admin mail: l: Berlin postalcode: 1063 streetadress: Steinplatz telephonenumber: facsimiletelephonenumber: RDN (Relative Distinguished Name) Relativer Name eines Objekts in einem (LDAP-) Verzeichnisdienst. Der RDN wird aus einem oder mehreren Attributtyp-Wert-Paaren gebildet. Durch die Aneinanderreihung der einzelnen RDNs in den verschiedenen Hierarchie-Ebenen von einem Wurzelknoten bis hin zum RDN des Eintrags, wird der so genannte Distinguished Name (DN) gebildet, welcher ein im gesamten Datenbestand eindeutiger Name ist. Die Unterscheidung in RDN und DN ist wichtig. Wenn der DN wie ein absoluter Pfad zwischen der Wurzel eines Dateisystems und der entsprechenden Datei anmutet, so ist der RDN wie der Dateiname an sich. Beispiel uid=admin 3.5 SASL (Simple Authentication and Security Layer) SASL ist ein Framework, das von verschiedenen Protokollen zur Authentifizierung im Internet verwendet wird. Es wurde im Oktober 1997 als RFC definiert und im Juni 006 durch RFC 44 ersetzt. SASL bietet dem Applikationsprotokoll damit eine standardisierte Möglichkeit der Aushandlung von Kommunikationsparametern. Im Regelfall wird nur eine Authentifizierungsmethode ausgehandelt, es kann aber auch vereinbart werden, dass zuerst auf ein verschlüsseltes Transportprotokoll, wie beispielsweise TLS, gewechselt wird. Die SASL-Implementierungen auf Client- und Server-Seite einigen sich auf ein Verfahren und dieses kann dann von der Applikation transparent benutzt werden. Durch diesen Standard wird die Entwicklung sicherer Applikationsprotokolle wesentlich vereinfacht. Der

14 1 Entwickler muss lediglich eine bestehende SASL-Implementierung nutzen anstelle ein komplettes Verfahren zur Authentifizierung und Datenverschlüsselung selbst zu implementieren. SASL wird unter anderem benutzt bei SMTP, IMAP, POP3, LDAP und XMPP. 3.6 X.500 Bei X.500 handelt es sich um eine Empfehlung für einen Verzeichnisdienst von der International Telecommunication Union (ITU) im Rahmen der X-Serie (Data Networks and Open System Communications). Die Empfehlung erschien erstmals im Jahr Es handelt sich dabei um keinerlei technische Implementierung, sondern um Gestaltungsrahmen für die Konzeption eines Verzeichnisdienstes. X.500 ist offen gelegt und vielfältig implementiert worden; viele Hersteller haben im Bereich der Administration ihrer Infrastruktur eine eigene Implementierung im Angebot. Um dem offenen Ansatz gerecht zu werden, gibt es keine festen Vorgaben hinsichtlich der zu speichernden Informationen. Vielmehr gibt es allgemein nur Objekte und Verbindungen zwischen diesen.