test

Java Desktop System Configuration Manager Release 1.1 - Installationsanleitung

Einrichtung

Folgendes ist erforderlich, wenn Sie einen bereits vorhandenen LDAP-Server für Configuration Manager einsetzen möchten:

Bereitstellungstools

Für den Einsatz eines bereits vorhandenen LDAP-Servers mit Configuration Manager werden die folgenden auf der Installations-CD befindlichen Bereitstellungstools benötigt:

Schema-Erweiterung

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.

Organisatorische Zuordnung

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. The MemberAttribute key must specify an attribute from a user or host entry for the search filter. 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

Benutzerprofil-Zuordnung

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

Bereitstellung

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:

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. For further information concerning the use of OpenLDAP and ActiveDirectory, refer to 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.