Eigenständiges LDAP-Repository auf eine LDAP-Repository-Konfiguration mit eingebundenen Repositorys migrieren
Wenn Sie die Sicherheit für Ihren Anwendungsserver konfigurieren, müssen Sie möglicherweise eine eigenständige LDAP-Registry auf eine LDAP-Repository-Konfiguration mit eingebundenen Repositorys migrieren.
Vorbereitende Schritte
Notieren Sie die Spezifikationen Ihres eigenständigen LDAP-Repositorys als Referenz, wenn Sie das LDAP-Repository in eingebundenen Repositorys konfigurieren möchten. Um auf diese Felder in der Administrationskonsole zuzugreifen, klicken Sie auf Sicherheit > Globale Sicherheit und wählen dann unter "Repository für Benutzeraccounts" im Feld "Verfügbare Realmdefinitionen" Eigenständige LDAP-Registry oder Eingebundene Repositorys aus. Klicken Sie anschließend auf Konfigurieren. Wenn Sie auf diese Felder in einer Umgebung mit mehreren Sicherheitsdomänen zugreifen möchten, klicken Sie auf Sicherheit > Globale Sicherheit > Sicherheitsdomänen > Domänenname. Erweitern Sie dann unter "Sicherheitsattribute" den Eintrag "Benutzerrealm", und klicken Sie auf Für diese Domäne anpassen. Wählen Sie den Realmtyp Eigenständige LDAP-Registry oder Eingebundene Repositorys aus, und klicken Sie dann auf Konfigurieren.

In der folgenden Tabelle sind die Anzeigen der Administrationskonsole und die Felder für die Konfiguration des eigenständigen LDAP-Repositorys angegeben, denen die entsprechenden Felder für eine LDAP-Repository-Konfiguration mit eingebundenen Repositorys zugeordnet sind.
Konfiguration des eigenständigen LDAP-Repositorys | LDAP-Repository in einer Konfiguration mit eingebundenen Repositorys |
---|---|
Globale Sicherheit > Eigenständige LDAP-Registry Allgemeine Eigenschaften - Name des primären Benutzers mit Verwaltungsaufgaben |
Globale Sicherheit > Eingebundene Repositorys Allgemeine Eigenschaften - Name des primären Benutzers mit Verwaltungsaufgaben |
Globale Sicherheit > Eigenständige LDAP-Registry LDAP-Server - Typ des LDAP-Servers |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID LDAP-Server - Verzeichnistyp |
Globale Sicherheit > Eigenständige LDAP-Registry LDAP-Server - Host |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID LDAP-Server – Name des primären Hosts |
Globale Sicherheit > Eigenständige LDAP-Registry LDAP-Server - Port |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID LDAP-Server - Port |
Globale Sicherheit > Eigenständige LDAP-Registry LDAP-Server - Failover-Hosts |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID LDAP-Server - Failover-Server, der verwendet wird, wenn der primäre Server nicht verfügbar ist |
Globale Sicherheit > Eigenständige LDAP-Registry LDAP-Server - Basis-DN |
Globale Sicherheit > Eingebundene Repositorys > Repository-Referenz (auf "Basiseintrag zum Realm hinzufügen" klicken) Allgemeine Eigenschaften - Definierter Name (DN) eines Basiseintrags, der diese Gruppe von Einträgen im Realm eindeutig identifiziert und Allgemeine Eigenschaften - Definierter Name (DN) eines Basiseintrags in diesem Repository |
Globale Sicherheit > Eigenständige LDAP-Registry LDAP-Server - Suchzeitlimit |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID
Allgemeine Eigenschaften - Dauer der Suche beschränken |
Globale Sicherheit > Eigenständige LDAP-Registry
LDAP-Server - Angepasste Eigenschaften |
Globale Sicherheit > Eingebundene Repositorys > Angepasste Eigenschaften |
Globale Sicherheit > Eigenständige LDAP-Registry
LDAP-Server - Benutzeridentität des Servers |
Globale Sicherheit > Eingebundene Repositorys Allgemeine Eigenschaften - Benutzeridentität des Servers |
Globale Sicherheit > Eigenständige LDAP-Registry
Sicherheit - Definierter Name für Bindung |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID Sicherheit - Definierter Name für Bindung |
Globale Sicherheit > Eigenständige LDAP-Registry
Sicherheit - Kennwort für Bindung |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID Sicherheit - Kennwort für Bindung |
Globale Sicherheit > Eigenständige LDAP-Registry > Erweiterte Einstellungen für LDAP-Benutzerregistry Allgemeine Eigenschaften - Kerberos-Benutzerfilter |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID Sicherheit - LDAP-Attribut für Kerberos-Principal-Namen |
Globale Sicherheit > Eigenständige LDAP-Registry > Erweiterte Einstellungen für LDAP-Benutzerregistry Allgemeine Eigenschaften - Modus für Zertifikatszuordnung |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID Sicherheit - Zertifikatszuordnung |
Globale Sicherheit > Eigenständige LDAP-Registry > Erweiterte Einstellungen für LDAP-Benutzerregistry Allgemeine Eigenschaften - Zertifikatsfilter |
Globale Sicherheit > Eingebundene Repositorys > Repositorys verwalten > Repository-ID Sicherheit - Zertifikatsfilter |
Das Feld "Realmname", das sich in der Anzeige "xxx" unter "Allgemeine Eigenschaften" befindet, ist in der vorherigen Tabelle nicht aufgelistet, da es keine Eins-zu-eins-Entsprechung zu einem Feld in der Anzeige für die eigenständige LDAP-Repository-Konfiguration gibt. Der Hostname und die Portnummer stellen den Realmnamen für den eigenständigen LDAP-Server in der WebSphere-Application-Server-Zelle dar. Informationen zum Ändern des Realmnamens finden Sie im Artikel zu den Realmkonfigurationseinstellungen.
Die Felder "Benutzerfilter", "Gruppenfilter", "Zuordnung von Benutzer-IDs", "Zuordnung von Gruppen-IDs" und "Zuordnung von Gruppenmember-IDs" sind in der obigen Tabelle ebenfalls nicht aufgelistet, weil es in der Anzeige für die LDAP-Repository-Konfiguration mit eingebundenen Repositorys keine Felder mit Eins-zu-eins-Entsprechung gibt. Diese LDAP-Attribute werden in der LDAP-Repository-Konfiguration mit eingebundenen Repositorys anders definiert, was mehrere Schritte erfordert. In den folgenden Abschnitten sind diese Einstellungen und die erforderliche Vorgehensweise ausführlich erläutert.
Informationen zu diesem Vorgang
Wenn Sie eine Konfiguration mit eigenständigem LDAP-Repository auf eine LDAP-Repository-Konfiguration mit eingebundenen Repositorys migrieren möchten, müssen Sie die Konfigurationsparameter migrieren. Wie Sie aus Tabelle 1 ersehen können, gibt es für die meisten dieser Parameter eine direkte Entsprechung. Das Migrieren der Suchfilter ist ein wichtiger Teil der Migration einer Konfiguration mit eigenständigem LDAP-Repository auf eine LDAP-Repository-Konfiguration mit eingebundenem Repository. Aus dem Grund sind die LDAP-Suchfilter und ihre Migration nachfolgend ausführlich beschrieben.
Für Suchfilter einer eigenständigen LDAP-Registry gilt die LDAP-Filtersyntax, die vorsieht, dass Sie ein Attribut als Basis für die Suche und den Wert dieses Attributs angeben.
Mit dem Benutzerfilter wird die Registry nach Benutzern durchsucht. Der Filter funktioniert so, dass ein Benutzer mithilfe des im Filter angegebenen Attributs authentifiziert wird.
Mit dem Gruppenfilter wird die Registry nach Gruppen durchsucht. Der Filter gibt die Eigenschaft an, nach der Gruppen gesucht werden sollen.
(&(uid=%v)(objectclass=ePerson))
Es wird nach Benutzern gesucht, bei denen das Attribut "uid" mit dem angegebenen Suchmuster der Objektklasse "ePerson" übereinstimmt.
(&(cn=%v)(objectclass=user))
Es wird nach Benutzern gesucht, bei denen das Attribut "cn" mit dem angegebenen Suchmuster der Objektklasse "user" übereinstimmt.
(&(sAMAccountName=%v)(objectcategory=user))
Es wird nach Benutzern gesucht, bei denen das Attribut "sAMAccountName" mit dem angegebenen Suchmuster der Objektkategorie "user" übereinstimmt.
(&(userPrincipalName=%v)(objectcategory=user))
Es wird nach Benutzern gesucht, bei denen das Attribut "userPrinciplalName" mit dem angegebenen Suchmuster der Objektkategorie "user" übereinstimmt.
(&(mail=%v)(objectcategory=user))
Es wird nach Benutzern gesucht, bei denen das Attribut "mail" mit dem angegebenen Suchmuster der Objektkategorie "user" übereinstimmt.
(&(|(sAMAccountName=%v)(userPrincipalName=%v))(objectcategory=user))
Es wird nach Benutzern gesucht, bei denen der "sAMAccountName" oder "userPrincipalName" mit dem angegebenen Suchmuster der Objektkategorie "user" übereinstimmt.
Beispiele für häufig verwendete Gruppenfilter:
(&cn=%v)(objectCategory=group)
Sucht Gruppen ausgehend von ihren allgemeinen Namen (cn).
(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)))
Sucht Gruppen ausgehend von ihren allgemeinen Namen (cn) und verwendet dafür die Objektklasse "groupOfNames" oder "groupOfUniqueNames".
Diese Beispiele zeigen, dass ein Suchfilter einer eigenständigen LDAP-Registry aus LDAP-Attributen und Objektklassen besteht, die die Grundlage für die Suche oder Anmeldung bilden.
Sie können die LDAP-Attribute und Objektklassen auch in der LDAP-Adapterkonfiguration von eingebundenen Repositorys angeben. Die Attribute und Klassen werden dort jedoch anders konfiguriert und ermöglichen mehr Flexibilität. In eingebundenen Repositorys wird der Benutzer als eine Entität vom Typ "PersonAccount" dargestellt und eine Gruppe als Entität vom Typ "Group". Jeder Entitätstyp kann eigene Eigenschaften des relativ definierten Namens (rdnProperties) und eigene Objektklassen haben. Die RDN-Standardeigenschaft von "PersonAccount" ist beispielsweise "uid", und die RDN-Standardeigenschaft von "Group" ist "cn". Die Standardobjektklassenzuordnung hängt vom Typ des LDAP-Servers ab. Für Tivoli Directory Server ist die Objektklasse für "PersonAccount" beispielsweise "inetOrgPerson" und die Objektklasse für "Group" ist "groupOfNames". PersonAccount kann auch Anmeldeeigenschaften haben. Wenn sich ein Benutzer anmeldet oder eine Benutzerregistry nach einem Benutzer durchsucht wird, werden diese Anmeldeeigenschaften mit dem Muster abgeglichen. Wenn die Anmeldeeigenschaften beispielsweise "uid" und "mail" sind, bedeutet das Suchmuster a*, dass alle Benutzer, die mit "uid=a*" oder "mail=a*" übereinstimmen, zurückgegeben werden.

Für die Migration von Suchfiltern ist mindestens einer der folgenden Schritte erforderlich: Festlegen der richtigen Anmeldeeigenschaften, Zuordnen der Attribute des Back-End-Repositorys zu den Eigenschaften der eingebundenen Repositorys, Festlegen der Objektklassen, Definieren des Suchfilters mit Objektklasse oder Objektkategorie und Setzen des Memberattributs oder des Zugehörigkeitsattributs. Die Zuordnung und Konfiguration eingebundener Repositorys wird in der Datei "wimconfig.xml" verwaltet.
- Attributfilter für Benutzer oder Gruppen
- Objektklassen- oder Objektkategoriefilter für Benutzer oder Gruppen
- Der Attributfilter ist (cn=%v).
- Der Objektklassenfilter ist (objectclass=user).
- Der Attributfilter wird für Benutzer den RDN-Eigenschaften oder Anmeldeeigenschaften zugeordnet und für Gruppen der Konfiguration der RDN-Eigenschaften.
- Der Objektklassenfilter wird der Konfiguration des Entitätstyps des LDAP-Adapters zugeordnet.
- Attributfilter:
- Festlegen der RDN-Eigenschaften und/oder der Anmeldeeigenschaften (sofern anwendbar)
- Zuordnen der Eigenschaft des eingebundenen Repositorys zum LDAP-Attribut (sofern anwendbar)
- Objektklassenfilter:
- Festlegen der Objektklasse für den Entitätstyp (sofern anwendbar)
- Festlegen des Suchfilters für den Entitätstyp (sofern anwendbar)
- Beispiel 1 ist auf ein Szenario anwendbar, in dem Sie den Suchfilter (&(cn=%v)(objectclass=ePerson)) von einem eigenständigen LDAP-Repository (IBM Tivoli Directory Server) auf ein LDAP-Repository (Kennung LDAPTDS) mit eingebundenen Repositorys migrieren.
- Beispiel 2 ist auf ein Szenario anwendbar, in dem Sie den Suchfilter (&(|(sAMAccountName=%v)(userPrincipalName=%v))(objectcategory=user)) von einem eigenständigen LDAP-Repository (Microsoft Active Directory) auf ein LDAP-Repository (Kennung LDAPAD) mit eingebundenen Repositorys migrieren. Da die Attribute "sAMAccountName" und "userPrincipalName" in eingebundenen Repositorys nicht definiert sind, müssen diese Attribute Eigenschaften eines eingebundenen Repositorys zugeordnet werden.