Folgendes ist erforderlich, wenn Sie einen bereits vorhandenen LDAP-Server für Configuration Manager einsetzen möchten:
Erweitern des Server-Schemas zur Unterstützung der benutzerdefinierten Objektklassen und Attribute, die zum Speichern von Konfigurationsdaten durch Configuration Manager benötigt werden.
Anpassen der Zuordnungsinformationen für die Einträge in der Datensammlung sowie der von Configuration Manager unterstützten Entitäten und Speichern dieser auf dem Server.
Für den Einsatz eines bereits vorhandenen LDAP-Servers mit Configuration Manager werden die folgenden auf der Installations-CD befindlichen Bereitstellungstools benötigt:
88apoc-registry.ldif: Eine Schemadatei, mit der die zum Speichern von Konfigurationsdaten erforderlichen Objektklassen und Attribute eingeführt werden.
OrganizationMapping: Eine Standardeigenschaftendatei, in der die Zuordnung zwischen LDAP-Einträgen und Configuration Manager-Entitäten beschrieben ist.
UserProfileMapping: Eine Standardeigenschaftendatei, in der die Zuordnung zwischen den Attributen für LDAP-Benutzereinträge und Attriuten für Configuration Manager-Benutzerprofile beschrieben ist.
createServiceTree: Ein Skript, durch das die Zuordnungsdateien in der LDAP-Datensammlung abgelegt werden.
deployApoc: Ein Skript zum Erweitern des Schemas des LDAP-Servers und Ablegen der Zuordnungsdateien in der LDAP-Datensammlung.
Die Konfigurationsdaten werden in Eintragsbäumen abgelegt, die an die Einträge anschließen, auf welche sich die Daten beziehen. Bevor die Objektklassen und Attribute für diese Bäume auf einem LDAP-Server gespeichert werden können, müssen Sie sie in das LDAP-Serverschema einfügen. Die zum Hinzufügen der Objekte und Klassen zu Sun JavaTM System Directory Server mitgelieferte Erweiterungsdatei verwendet das Format LDIF. Um diese Objekte einem anderen LDAP-Server hinzuzufügen, müssen Sie ein von diesem Server unterstütztes Format verwenden.
Zur Definition der Zuordnung zwischen LDAP-Einträgen und Configuration Manager-Entitäten muss die Datei Organization bearbeitet werden. Dabei sind für die verschiedenen Schlüssel Werte anzugeben, die der Struktur der LDAP-Datensammlung entsprechen.
Benutzerentitäten sind durch eine für alle Entitäten geltende Objektklasse sowie ein Attribut gekennzeichnet, dessen Wert im Bereich der gesamten Datensammlung einmalig sein muss. Sie können ein Namensanzeigeformat liefern, das sich auf die Anzeige der Benutzernamen in der Verwaltungsanwendung auswirkt, und haben die Möglichkeit, einen Behältereintrag zu definieren, für den Fall, dass für die Benutzereinträge in der Organisation solche Einträge verwendet werden. Sehen Sie hier die Schlüsselnamen und ihre Standardwerte:
# Objektklasse für alle Benutzereinträge User/ObjectClass=inetorgperson # Attribut, dessen Wert in Benutzereinträgen im Bereich der Datensammlung einmalig sein muss User/UniqueIdAttribute=uid # Optionaler Behälter in Organisationseinträgen der Benutzereinträge; # entfernen Sie diese Zeile, sofern sie nicht erforderlich ist User/Container=ou=People # Namensanzeigeformat innerhalb der Verwaltungsanwendung User/DisplayNameFormat=sn, givenname
Rollenentitäten sind durch eine Liste möglicher Objektklassen und die entsprechenden Namensattribute gekennzeichnet. Diese Listen müssen im Format <Element1>,<Element2>,...,<ElementN> vorliegen und sich decken. Das heißt, dass die Listen dieselbe Elementanzahl aufweisen müssen und die n-te Objektklasse mit dem n-ten Namensattribut verbunden sein muss. Zwei Schlüssel bestimmen sowohl das Verhältnis zwischen Rollen und Benutzern als auch zwischen Rollen und Rechnern. Mit dem Schlüssel VirtualMemberAttribute ist ein Attribut anzugeben, dessen Werte von einem Benutzer- oder Rechnereintrag abgefragt werden können. Außerdem muss der Schlüssel die vollständigen DNs der Rollen enthalten, zu welchen der Eintrag gehört. Mit dem Schlüssel MemberAttribute ist ein Attribut aus einem Benutzer- oder Rechnereintrag für den Suchfilter anzugeben. Außerdem muss der Schlüssel die vollständigen DNs der Rollen enthalten, zu welchen der Benutzer oder Rechner gehört. Während der Schlüssel VirtualMemberAttribute ein virtuelles Attribut vom Typ Class Of Service sein kann, muss für den Schlüssel MemberAttribut ein tatsächliches, in einem Filter verwendbares Attribut angegeben werden. Sehen Sie hier die Schlüsselnamen und ihre Standardwerte:
# Liste von Objektklassen für Rollen Role/ObjectClass=nsRoleDefinition # Sich deckende Liste mit entsprechenden Namensattributen Role/NamingAttribute=cn # Tatsächliches Attribut (in einem Filter verwendbar), das die DNs der # Rollen eines Benutzers/Rechners enthält Role/MemberAttribute=nsRoleDN # Attribut, durch dessen Abfrage für einen Benutzer oder Rechner die DNs # der zugehörigen Rollen geliefert werden Role/VirtualMemberAttribute=nsRole
Organisationsentitäten werden ähnlich wie Rollen durch zwei bündige Listen von Objektklassen und den dazugehörigen Namensattributen definiert. Sehen Sie hier die Schlüsselnamen und ihre Standardwerte:
# Liste von Objektklassen für Organisationen Organization/ObjectClass=organization # Sich deckende Liste mit entsprechenden Namensattributen Organization/NamingAttribute=o
Domänenentitäten werden ähnlich wie Organisationsentitäten definiert. Sehen Sie hier die Schlüsselnamen und ihre Standardwerte:
# Liste von Objektklassen für Domänen Domain/ObjectClass=ipNetwork # Sich deckende Liste mit entsprechenden Namensattributen Domain/NamingAttribute=cn
Rechnerentitäten werden ähnlich wie Benutzerentitäten definiert. Sehen Sie hier die Schlüsselnamen und ihre Standardwerte:
# Objektklasse für alle Rechnereinträge Host/ObjectClass=ipHost # Attribut, dessen Wert in Rechnereinträgen im Bereich der Datensammlung einmalig sein muss Host/UniqueIdAttribute=cn # Optionaler Behälter in Domäneneinträgen der Rechnereinträge; # entfernen Sie diese Zeile, sofern sie nicht erforderlich ist. Host/Container=ou=Hosts
Zur Definition der Zuordnung zwischen den Attributen der LDAP-Benutzereinträge und den Attributen der Configuration Manager-Benutzerentitäten muss die Datei UserProfileMapping bearbeitet werden. Jeder Schlüssel entspricht einem Configuration Manager-Benutzerattribut. Dem Namen eines Attributs in einem Benutzereintrag kann gemäß der Definition durch die organisatorische Zuordnung ein Schlüssel als Wert zugewiesen werden. Attribute, die in der User/DisplayNameFormat-Einstellung verwendet werden, müssen in der Datei UserProfileMapping eine Zuordnung erhalten. Sehen Sie hier die Schlüsselnamen und ihre Standardwerte:
# inetOrgPerson.givenName org.openoffice.UserProfile/Data/givenname = givenname # person.sn org.openoffice.UserProfile/Data/sn = sn # inetOrgPerson.initials org.openoffice.UserProfile/Data/initials = initials # organizationalPerson.street org.openoffice.UserProfile/Data/street = street,postalAddress,streetAddress # organizationalPerson.l (Stadty) org.openoffice.UserProfile/Data/l = l # organizationalPerson.st (Bundesland/Kreis) org.openoffice.UserProfile/Data/st = st # organizationalPerson.postalCode org.openoffice.UserProfile/Data/postalcode = postalcode # country.c (Land) org.openoffice.UserProfile/Data/c = # organizationalPerson.o (Firma) org.openoffice.UserProfile/Data/o = o,organizationName # deprecated -- keine logische Folge für LDAP org.openoffice.UserProfile/Data/position = # organizationalPerson.title org.openoffice.UserProfile/Data/title = title # inetOrgPerson.homePhone org.openoffice.UserProfile/Data/homephone = homephone # organizationalPerson.telephoneNumber org.openoffice.UserProfile/Data/telephonenumber = telephonenumber # organizationalPerson.facsimileTelephoneNumber org.openoffice.UserProfile/Data/facsimiletelephonenumber = facsimiletelephonenumber,officeFax # inetOrgPerson.mail org.openoffice.UserProfile/Data/mail = mail
Nachdem Sie die Zuordnungsdateien an die Gegebenheiten der LDAP-Datensammlung angepasst haben, können sie bereitgestellt werden. Wenn das Schema des LDAP-Servers die erforderlichen Objektklassen und Attribute bereits umfasst, kann das Skript createServiceTree direkt ausgeführt werden. Anderenfalls ist zunächst das Skript deployApoc auszuführen.
Das Skript deployApoc ist auf Sun JavaTM System Directory Servers zugeschnitten. Es kopiert die mitgelieferte Schema-Erweiterungsdatei in das richtige Verzeichnis, beendet den LDAP-Server und startet ihn neu und ruft anschließend das Skript createServiceTree auf. Für die Ausführung des Skripts müssen Sie über die Berechtigung zum Kopieren von Dateien in die Schema-Datensammlung, zum Beenden und zum Starten des Servers verfügen. Es wird mit folgendem Befehl aufgerufen:
./deployApoc <Directoy_Server-Verzeichnis>
Dabei ist der Parameter <Directoy_Server-Verzeichnis> der Pfad zu dem Unterverzeichnis slapd-<Servername> einer Verzeichnisserver-Installation. Angenommen, bei der Installation wurden die Standardverzeichnisse übernommen und der Servername lautet meinServer.meineDomäne, so heißt das Verzeichnis /var/Sun/mps/slapd-meinServer.meineDomäne.
Unabhängig davon, ob es direkt oder durch das Skript deployApoc aufgerufen wird, fordert das Skript createServiceTree den Benutzer zur Eingabe der Adresse des LDAP-Servers (Host-Name, Port-Nummer und Basis-DN) und der Definition eines Benutzers mit Administrationsrechten (vollständiger DN und Passwort) auf. Anschließend erstellt es im LDAP-Server einen Startdienst-Baum und legt die Zuordnungsdateien darin ab. Das Skript kann mit beliebigen Berechtigungen ausgeführt werden. Der Aufrufbefehl lautet:
./createServiceTree
Daraufhin wird der Benutzer zur Eingabe von Folgendem aufgefordert:
Rechnername (Standardwert: localhost): Rechnername des LDAP-Servers,
Port-Nummer (Standardwert: 389): Port-Nummer des LDAP-Servers,
Base-DN: Base-DN der LDAP-Datensammlung,
Benutzer-DN (Standardwert: cn=Directory Manager): vollständiger DN eines Benutzers mit ausreichenden Berechtigungen zum Erstellen neuer Einträge unter dem Base-DN,
Passwort: Passwort dieses Benutzers,
Es wird ein Eintrag mit dem DN:
ou=ApocRegistry,ou=default,ou=OrganizationConfig,ou=1.0,ou=ApocService,ou=services, <Base-DN>
erzeugt und mit dem Inhalt der zwei Zuordnungsdateien angefüllt.
Wie bereits angemerkt, wird für die durch das Skript deployApoc durchgeführten Operationen ein LDAP-Server vorausgesetzt, der sich in Bezug auf die Installationsverzeichnisse, seine Struktur und die Schema-Erweiterungsprozedur so gut wie nicht von Sun Java System Directory Server unterscheidet. Bei anderen Verzeichnissen ist das Schema manuell zu erweitern, bevor das Skript createServiceTree ausgeführt werden kann. Weitere Informationen zur Verwendung von OpenLDAP und ActiveDirectory finden Sie in Anhang C, Verwenden von OpenLDAP und Active Directory mit Configuration Manager.
Der erzeugte Baum, der mit dem Baum zum Ablegen der Konfigurationsdaten für die Entitäten übereinstimmt, deckt sich mit der Struktur der Bäume, die in Sun Java System Identity Server für die Dienstverwaltung zum Einsatz kommen.