| Sun Java Enterprise System 2003Q4 Installation Guide |
Kapitel 12
Bereitstellung und Schema-Konzepte f�r Messaging Server 6.0In diesem Kapitel werden Ihre Bereitstellungsm�glichkeiten hinsichtlich Messaging Server 6.0 erl�utert. Au�erdem enth�lt es Themen, die Ihnen die Konzepte und Technologien von Sun ONE LDAP Schema, v.2 verdeutlichen.
Dieses Kapitel enth�lt die folgenden Abschnitte:
LDAP Directory Information Tree (DIT) und Messaging ServerDer Verzeichnisinformationsbaum (Directory Information Tree, DIT) dient der Organisation von LDAP-Eintr�gen in einer Baumstruktur mit Knoten, die f�r Dom�nen, Subdom�nen, Benutzer und Gruppen stehen. In fr�heren Versionen von Messaging Server wurde eine zwei B�ume umfassende Struktur verwendet. Es gab einen DC-Baum mit Dom�nenknoten, die mit allen zugeh�rigen Dom�nenattributen versehen waren, und einen Organisationsbaum mit Dom�nenknoten, die mit allen Benutzer- und Gruppenattributen versehen waren. In der oberen H�lfte von Abbildung 12–1 ist diese Art von DIT-Struktur dargestellt. Mithilfe dieser Struktur konnten mehrere DC-Baumknoten auf denselben Organisationsbaum-Dom�nenknoten verweisen, da im DC-Baum Aliasnamen definiert waren.
In Messaging Server 6.0 wird eine Struktur mit nur einem Baum verwendet, die keinen DC-Baum enth�lt. Au�erdem werden s�mtliche Dom�neninformationen in Dom�nenknoten des Organisationsbaums verwaltet. Das zwei B�ume umfassende Modell wird weiterhin unterst�tzt, weist jedoch die unter „Schema v.2-Auswahlm�glichkeiten: Nativer Modus oder Kompatibilit�tsmodus“ erl�uterten �nderungen auf.
In der unteren H�lfte von Abbildung 12–1 ist eine aus einem Baum bestehende LDAP-(Lightweight Directory Access Protocol-)Struktur dargestellt. Aliasing wird in der neuen, aus einem DIT bestehenden Struktur v�llig anders gehandhabt. Achten Sie in der Darstellung mit einem Baum besonders darauf, wo sich die Dom�neninformationen befinden.
Abbildung 12–1 Nativer Modus im Vergleich mit dem Kompatibilit�tsmodus in der LDAP-Struktur
Schema-M�glichkeiten f�r Messaging Server 6.0F�r Messaging Server 6.0 gibt es folgende drei Schema-M�glichkeiten:
Sun ONE LDAP Schema, v.2 im nativen Modus
Der standardm��ige Modus f�r neue Kundeninstallationen, bei denen keine Version von iPlanet™ Messaging Server installiert ist, ist Sun ONE LDAP Schema, v.2. Hierbei wird davon ausgegangen, dass Identity Server 6.1 vor Messaging Server 6.0 installiert wird.
Diesen Modus k�nnen Sie auch dann ausw�hlen, wenn eine iPlanet Messaging Server-Installation vorhanden ist. In diesem Fall m�ssen Sie Ihre LDAP-Datenbank jedoch auf das aus einem Baum bestehende Modell migrieren.
F�r Bereitstellungs- und Administrationszwecke steht eine befehlszeilenbasierte-Oberfl�che zur Verf�gung. Die LDAP-Bereitstellung kann ebenfalls durchgef�hrt werden.
Sun ONE LDAP Schema, v.2 im Kompatibilit�tsmodus
Wenn Sie �ber eine iPlanet Messaging Server-Installation verf�gen, k�nnen Sie alternativ Sun ONE LDAP Schema v.2 im Kompatibilit�tsmodus ausw�hlen. In diesem Modus ist die Migration auf ein aus einem Baum bestehendes Modell nicht erforderlich. Sie k�nnen das zwei B�ume umfassende Modell beibehalten, �ber das Sie bereits verf�gen. Hierbei wird ebenfalls davon ausgegangen, dass Identity Server 6.1 vor Messaging Server 6.0 installiert wird.
F�r Bereitstellungs- und Administrationszwecke steht eine befehlszeilenbasierte-Oberfl�che zur Verf�gung. Die LDAP-Bereitstellung kann ebenfalls durchgef�hrt werden.
Sun ONE LDAP Schema, v.1
Sun ONE LDAP Schema v.1 ist der Standardmodus f�r neue Kundeninstallationen, bei denen Identity Server nicht installiert ist. F�r Sun ONE LDAP Schema v.1 muss ein zwei B�ume umfassendes LDAP-Modell installiert werden.
Kunden mit bestehender iPlanet Messaging Server-Installation k�nnen sich zur Beibehaltung von Sun ONE LDAP Schema, v.1 entschlie�en und zu Bereitstellungs- und Administrationszwecken bzw. f�r die LDAP-Bereitstellung weiterhin die grafische Benutzeroberfl�che verwenden.
Hinweis
In diesem Handbuch wird lediglich die LDAP-Bereitstellung f�r Sun ONE LDAP Schema, v.2 beschrieben.
Ermitteln der geeigneten BereitstellungstoolsNachdem Sie sich f�r ein Schema-Modell entschieden haben, erfahren Sie im nachfolgenden Abschnitt, welche Bereitstellungstools und Dokumentation zu verwenden sind.
In diesem Abschnitt finden Sie folgende Informationen:
Bereitstellungsmatrix
Tabelle 12–1 enth�lt eine Matrix, in der Ihre Schema-Auswahl zusammgefasst wird. Hieraus ist ersichtlich, welche Bereitstellungstools verf�gbar sind und welche Dokumentation jeweils verwendet werden sollte. In den auf die Tabelle folgenden Abschnitten finden Sie Erl�uterungen zur Auswahl.
In dieser Tabelle werden Sie in der ersten Spalte gefragt, ob eine fr�here Version von Messaging Server (iPlanet Messaging Server 5.0, 5.1 oder 5.2) installiert ist. In der zweiten Spalte werden Sie gefragt, ob Sie Identity Server bereits installiert haben bzw. dies vor der Bereitstellung beabsichtigen.
Tabelle 12–1 Bereitstellungsmatrix
iPlanet Messaging Server (5.0, 5.1, 5.2) installiert?
Identity Server installiert?
Durch Messaging Server 6.0 installierter Schema-Typ
Bereitstellungstools
Informationen in folgenden Dokumenten
Nein
Nein
Sun ONE LDAP Schema, v.1 (Standard)
Delegated Administrator
iPlanet Delegated Administrator for Messaging and Collaboration 1.2 Installation and Administration Guide (http://docs.sun.com/doc/816-6011-10)
LDAP-Bereitstellung
iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6018-10)
Nein
Ja
Sun ONE LDAP Schema, v.2 im nativen Modus (Standard)
User Management Utility (commadmin)
Sun ONE Messaging and Collaboration 1.0 User Management Utility Installation and Reference Guide (http://docs.sun.com/doc/817-4216-10)
LDAP-Bereitstellung
Informationen im vorliegenden Handbuch, Kapitel 11, „Bereitstellen von Organisationen und Benutzern“
Ja
Nein
Sun ONE LDAP Schema, v.1
Delegated Administrator
iPlanet Delegated Administrator for Messaging and Collaboration 1.2 Installation and Administration Guide (http://docs.sun.com/doc/816-6011-10)
LDAP-Bereitstellung
iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6018-10)
Ja
Ja
Sun ONE LDAP Schema, v.2 entweder im nativen Modus oder im Kompatibilit�tsmodus (von Ihnen festgelegt)
User Management Utility (commadmin)
Sun ONE Messaging and Collaboration User Management Utility 1.0 Installation and Reference Guide (http://docs.sun.com/doc/817-4216-10)
LDAP-Bereitstellung
Informationen im vorliegenden Handbuch, Kapitel 11, „Bereitstellen von Organisationen und Benutzern“
Ermitteln Ihres Schema-Modells
Wenn keine �ltere Version von Messaging Server installiert ist und Identity Server als Erstes installiert wurde, wird Ihre neue Installation von Messaging Server 6.0 bei Verwendung von Sun ONE LDAP Schema, v.2 im nativen Modus automatisch installiert. Wenn Identity Server nicht installiert ist, verwendet Messaging Server standardm��ig Sun ONE LDAP Schema, v.1.
Wenn eine �ltere Version von Messaging Server installiert ist und Sie das neue Sun ONE LDAP Schema, v.2 verwenden m�chten, m�ssen Sie sich f�r eine der folgenden M�glichkeiten entscheiden:
Abh�ngig von Ihrer Entscheidung wird f�r LDAP-Suchvorg�nge eine von zwei standardm��igen Suchvorlagen verwendet:
Weitere Informationen zu den beiden Modi von Sun ONE LDAP Schema, v.2 finden Sie unter „Schema v.2-Auswahlm�glichkeiten: Nativer Modus oder Kompatibilit�tsmodus“.
Empfehlung hinsichtlich zu verwendenden Tools
F�r Sun ONE LDAP Schema, v.2 k�nnen Sie entweder das Sun ONE User Management Utility (commadmin) verwenden oder die LDAP-Bereitstellung durch direktes Schreiben von LDIF-Datens�tzen in LDAP durchf�hren.
F�r Sun ONE LDAP Schema, v.1 k�nnen Sie entweder iPlanet™ Delegated Administrator verwenden oder die LDAP-Bereitstellung durchf�hren.
Weitere Informationsquellen hinsichtlich der Bereitstellung
Ziehen Sie zur Durchf�hrung der LDAP-Bereitstellung f�r Sun ONE LDAP Schema, v.2 (nativer Modus und Kompatibilit�tsmodus) das vorliegende Handbuch zurate. Weitere Informationen finden Sie unter Kapitel 11, „Bereitstellen von Organisationen und Benutzern“. Ziehen Sie hinsichtlich der LDAP-Bereitstellung f�r Sun ONE LDAP Schema, v.1 iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6011-10) zurate.
Wenn Sie die Verwendung des User Management Utility-Bereitstellungstools (f�r Sun ONE LDAP Schema, v.2) beabsichtigen, ziehen Sie Sun ONE Messaging and Collaboration User Management Utility 1.0 Installation and Reference Guide (http://docs.sun.com/doc/817-4216-10) zurate. Wenn Sie die Verwendung des Delegated Administrator-Bereitstellungstools (f�r Sun ONE LDAP Schema, v.l) beabsichtigen, ziehen Sie iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6011-10) zurate.
Schema v.2-Auswahlm�glichkeiten: Nativer Modus oder Kompatibilit�tsmodusDie LDAP-Strukturierung kann mit Sun ONE Schema, v.2 auf zwei Arten vorgenommen werden: im nativen Modus (bevorzugte Methode), in dem nur der Organisationsbaum zum Einsatz kommt, oder im Kompatibilit�tsmodus (f�r Abw�rtskompatibilit�t mit fr�heren Versionen von Sun ONE- oder iPlanet-LDAP-basierten Produkten), in dem sowohl ein Dom�nenkomponentenbaum (Domain Component, DC) als auch ein Organisationsbaum zum Einsatz kommt. Die LDAP-Bereitstellung variiert abh�ngig davon, welches dieser Modelle ausgew�hlt wird.
Ziehen Sie folgende Punkte in Erw�gung, bevor Sie entscheiden, welche Modi von Sun ONE Schema, v.2 verwendet werden sollen:
Warum wurde die LDAP-Struktur ver�ndert?
In Java Enterprise System wurde ein grundlegende �nderung der Strukturierung von LDAP umgesetzt: es wird eine aus einem Baum bestehende Struktur implementiert. Nachfolgend sind die beiden gr��ten Vorteile der aus einem Baum bestehenden Struktur (nativer Modus) aufgef�hrt:
Die LDAP-Struktur mit einem Baum ist weniger komplex als die Struktur mit zwei B�umen. Wie aus der nachfolgenden Abbildung ersichtlich ist, verwiesen in der Struktur mit zwei B�umen einige Knoten auf einen Knoten im Organisationsbaum (mithilfe des Attributs inetDomainBaseDN). Bei anderen Knoten handelte es sich um Alias-Knoten, die nicht direkt auf einen Organisationsbaumknoten, sondern auf einen anderen DC-Baumknoten verwiesen (mithilfe des Attributs aliasedObjectName).
Abbildung 12–2 Aliasing mit zwei B�umen unter Verwendung von aliasedDomainName und inetDomainBaseDN
In obiger Abbildung verweist sesta.com im DC-Baum auf siroe.com im DC-Baum, mithilfe von aliasedObjectName. siroe.com verweist auf den entsprechend benannten Knoten im Organisationsbaum, mithilfe von inetDomainBaseDN.
Wie aus der folgenden Abbildung hervorgeht, konnten im DC-Baum au�erdem ein oder mehrere Knoten mithilfe von inetDomainBaseDN direkt auf denselben Knoten im Organisationsbaum verweisen. In solchen F�llen war in einem der DC-Baumknoten ein so genanntes Tie Break-Attribut erforderlich, n�mlich inetCanonicalDomainName, das bestimmte, welches der „echte“ Dom�nenname war. Hiermit wurde also die Dom�ne bezeichnet, in der die Mail tats�chlich vorhanden war und an die die Weiterleitung erfolgte.
Abbildung 12–3 Aliasing mit zwei B�umen unter Verwendung von inetCanonicalDomainName
Im Vergleich dazu ist die neue LDAP-Struktur weniger komplex: eine Struktur mit einem Baum enth�lt nur einen Organisationsbaum, wie aus Abbildung 12–4 hervorgeht.
In der Struktur mit einem Baum enthalten Dom�nenknoten im Organisationsbaum alle Dom�nenattribute, die sich zuvor im DC-Baum befanden. Jeder Dom�nenknoten wird durch die Objektklasse sunManagedOrganization sowie das Attribut sunPreferredDomain identifiziert, das den DNS-Dom�nennamen enth�lt. Ein Dom�nenknoten kann auch eines oder mehrere associatedDomain-Attribute aufweisen, die die Aliasnamen auflisten, unter denen diese Dom�ne bekannt ist. Au�erdem gibt es im Gegensatz zur Struktur mit zwei B�umen keine doppelt vorhandenen Knoten f�r Aliasnamen.
Abbildung 12–4 Aliasing mit einem Baum unter Verwendung von associatedDomain
Nativer Modus: Vorteile und eine R�ckentwicklung
F�r neue Bereitstellungen von Messaging Server werden LDAP-Informationen nun mithilfe einer Struktur mit nur einem Verzeichnisinformationsbaum (Directory Information Tree, DIT) organisiert. Der einzelne Messaging Server-DIT wird als Organisationsbaum bezeichnet. Er enth�lt Benutzer-, Gruppen- und Dom�neneintr�ge sowie Suchvorlagen.
Vorteile eines DIT mit einem Baum
Eine DIT-Struktur mit einem Baum wirkt sich vorteilig auf die Datenpartitionierung f�r unternehmensspezifische Zugriffssteuerung aus. Der Vorteil liegt darin, dass jede Organisation �ber einen separaten Teilbaum im DIT verf�gen kann, in dem sich Benutzer- und Gruppeneintr�ge befinden. Der Zugriff auf diese Daten kann in diesem Bereich des Teilbaums auf Benutzer beschr�nkt werden. Auf diese Weise k�nnen lokale Anwendungen ohne Sicherheitsbedenken verwendet werden.
Au�erdem erfolgt bei neuen Bereitstellungen von Messaging Server 6.0 die Zuordnung einer Struktur mit einem Baum zu vorhandenen LDAP-Anwendungen mit einem einzelnen Baum reibungsloser.
R�ckentwicklung hinsichtlich des nativen Modus
Bei einer Struktur mit zwei B�umen k�nnen zwei DC-Baum-Dom�nenknoten auf denselben Organisationsbaum-Dom�nenknoten verweisen. Jede der beiden DC-Baum-Dom�nen konnte unterschiedliche Weiterleitungsattribute aufweisen. Auf diese Weise konnte Mail f�r dieselbe Organisationsbaum-Dom�ne auf unterschiedliche Weise verarbeitet und weitergeleitet werden, abh�ngig davon, welcher Dom�nen-Alias angegeben wurde. Da diese Art des Aliasing in einer Struktur mit einem Baum nicht mehr m�glich ist, steht diese Funktion nicht mehr zur Verf�gung.
Das Aliasing wird nun mithilfe des Attributs associatedDomain durchgef�hrt und ist mit der Funktionsweise von mit dem Attribut aliasedObjectName versehenen Alias-Dom�nen im Kompatibilit�tsmodus identisch. Die Alias-Dom�ne wies also keine Dom�nenweiterleitungsattribute auf, sondern verlie� sich auf die Attribute, mit denen die Alias-Dom�ne versehen war (deren dn wurde im Attribut aliasedObjectName verwaltet), sodass die Weiterleitung von Nachrichten f�r die Alias-Dom�ne mit der Alias-Dom�ne identisch war.
Konvertieren in den nativen Modus
Wenn Sie �ber eine Sun ONE Schema, v.1-LDAP-Struktur mit zwei B�umen verf�gen und die Konvertierung in den nativen Modus durchf�hren m�chten, finden Sie nachfolgend eine allgemeine Liste mit �nderungen, die am Organisationsbaum vorgenommen werden m�ssen.
- F�gen Sie s�mtlichen Dom�nenknoten die Objektklassen sunISManagedOrganization und sunManagedOrganization sowie deren entsprechende Attribute hinzu.
- F�gen Sie die Objektlasse sunNameSpace allen entsprechenden Dom�nenknoten hinzu. (Siehe auch „Deklarieren von Namespaces“.)
- Kopieren Sie alle zugeh�rigen Dom�nenattribute aus dem DC-Baum in die entsprechenden Organisationsbaum-Dom�nenknoten.
- Komprimieren Sie alle Aliasnamen aus dem DC-Baum im associatedDomain-Attribut.
- F�gen Sie den Organisationsbaumknoten Zugriffssteuerungsinformationen (Access Control Information, ACI) hinzu.
- Identity Server f�gt dem Root-Knoten (basisdn) globale Suchvorlagen hinzu. M�glicherweise ist es auch empfehlenswert, f�r einzelne Knoten Vorlagen f�r die pers�nliche Au�erkraftsetzung (private override) anzugeben.
Details zu Objektklassen und Attribute finden Sie in Sun ONE Messaging and Collaboration 6.0 Schema Reference Manual (http://docs.sun.com/doc/816-6710-10).
Kompatibilit�tsmodus: Struktur mit zwei B�umen weiterhin unterst�tzt
Messaging Server 6.0 unterst�tzt die Struktur mit zwei B�umen f�r �ltere Version von Messaging Server weiterhin, wenn die Beibehaltung dieser Struktur erforderlich ist. Die Beibehaltung einer LDAP-Struktur mit zwei B�umen ist beispielsweise dann erforderlich, wenn andere Anwendungen davon abh�ngig sind.
Wenn Sie die Struktur mit zwei B�umen beibehalten, verwendet Messaging Server f�r die Suche nach Benutzereintr�gen eine RFC 2247-f�hige Suchvorlage.
F�r die Migration von Sun ONE Schema, v1 auf Sun ONE Schema, v.2 (Kompatibilit�tsmodus) m�ssen folgende Schritte durchgef�hrt werden:
- Das Attribut inetDomainStatus muss aus den DC-Baumknoten in die entsprechenden Organisationsbaum-Knoten kopiert werden. (Wenn beide Knoten inetDomainStatus enthalten, hat der Status im Organisationsbaum-Knoten gegen�ber dem im DC-Baumknoten Vorrang.)
- F�r die standardm��ige Suchvorlage f�r zwei B�ume muss das Attribut rfc2247Flag eingestellt sein, damit alle Anwendungen, die das LDAP durchsuchen, weiterhin den DC-Baum f�r den Zugriff auf die richtigen Knoten im Organisationsbaum verwenden, wie in bisherigen Versionen von Messaging Server.
- S�mtliche Organisationsbaum-Knoten m�ssen �ber die entsprechenden Identity Server-Markierungs-Objektklassen und -attribute verf�gen.
- Die entsprechenden ACI f�r Identity Server m�ssen s�mtlichen Knoten hinzugef�gt werden.
- Globale Suchvorlagen f�r Dom�nen, Benutzer und Gruppen werden von Identity Server im Root-Knoten zur Verf�gung gestellt. F�r bestimmte Knoten m�ssen Suchvorg�nge jedoch m�glicherweise angepasst werden. Zur Anpassung m�ssen Sie in den jeweiligen Knoten Vorlagen f�r die Au�erkraftsetzung hinzuf�gen.
Datenmodelle f�r nativen Modus und Kompatibilit�tsmodusF�r das grundlegende Datenmodell von Sun ONE-Objektklassen werden LDAP-Eintragstypen (z. B. „Benutzer“, „Gruppe“ oder „Dom�ne“), die durch Core-Objektklassen erstellt wurden, durch �berlagerung mit gemeinsam genutzten Klassen (Objektklassen k�nnen von mehreren Diensten gemeinsam genutzt werden) und dienstspezifischen Objektklassen (Klassen, die f�r einen bestimmten Servertyp spezifisch sind) erweitert.
Diese Beziehung wird in den nachfolgenden Tabellen dargestellt. Hinsichtlich LDAPs im nativen Modus mit nur einem Organisationsbaum ziehen Sie die nachfolgende Tabelle zurate. F�r LDAPs im Kompatibilit�tsmodus mit einem DC-Baum und einem Organisationsbaum ziehen Sie Tabelle 12–3 zurate.
Unter Verwendung des Benutzer-Eintragstyps als Beispiel stellen folgende Objektklassen folgende Attributtypen zur Verf�gung:
person Stellt Attribute zur Beschreibung einer Person zur Verf�gung.
organizationalPerson Stellt Attribute zur Beschreibung einer Person zur Verf�gung, die einer Organisation angeh�rt.
inetOrgPerson Stellt grundlegende Internetbenutzerattribute zur Verf�gung.
ipUser Verwaltet das pers�nliche Adressbuchattribut, die Dienststufen-Vorlage sowie den DN (Distinguished Name) des Familienkontos nach Bedarf.
inetUser Stellt ein Benutzerkonto dar und wird in Verbindung mit inetMailUser und ipUser zur Erstellung eines Mailkontos verwendet.
inetSubscriber Ist eine optionale Objektklasse, die ein Abonnentenkonto darstellt. Sie stellt die Konto-ID sowie Attribute f�r Anfrage/Antwort zur Verf�gung.
inetMailUser Stellt ein Mailkonto dar und macht den Gro�teil der benutzerspezifischen Mailkonto-Attribute verf�gbar.
inetLocalMailRecipient Stellt einen lokalen (innerhalb der Organisation befindlichen) E-Mail-Empf�nger durch Angabe der E-Mail-Adresse des Empf�ngers und Bereitstellung von auf den Empf�nger bezogenen Weiterleitungsinformationen dar.
Deklarieren von NamespacesNamespaces definieren Organisationseinheiten, in denen ein oder mehrere Attribute in allen Eintr�gen eindeutig sein m�ssen.
Wenn Sie eine Organisation (normalerweise eine Dom�ne) als Namespace bereitstellen m�chten, f�gen Sie dem Eintrag der Organisation die Objektklasse sunNameSpace hinzu. Hierdurch wird er als eindeutiger Namespace markiert, die Funktion f�r die Eindeutigkeit wird jedoch nicht aktiviert. Dies bedeutet, dass durch die Objektklasse sunNameSpace allein das Systemverhalten nicht ge�ndert wird.
Zur Aktivierung der Funktion f�r die Eindeutigkeit m�ssen Sie das Attribut sunNameSpaceUniqueAttrs zum Eintrag der Organisation hinzuf�gen. Das Attribut enth�lt den Namen eines Attributs, mit dem eindeutige Eintr�ge in dieser Organisation unterschieden werden. Mehrere Attribute k�nnen zu Zwecken der Eindeutigkeit verwendet werden.
Wenn die Funktion f�r die Eindeutigkeit zu einer Dom�ne hinzugef�gt wird, bedeutet dies, dass kein Teilbaum unterhalb der Dom�ne mit denselben Attributen als Namespace deklariert werden kann.
Die Eindeutigkeit wird durch das Befehlszeilendienstprogramm-Bereitstellungstool commadmin erzwungen. Hierdurch wird unterbunden, dass ein doppelter Eintrag hinzugef�gt wird, der die Funktion f�r die Eindeutigkeit verletzt. Wenn Sie die Bereitstellung direkt mit LDAP durchf�hren, m�ssen Sie die Eindeutigkeit selbst erzwingen. Durch den LDAP-Befehl ldapmodify wird die Eindeutigkeit nicht erzwungen. Er l�sst die Eingabe doppelter Datens�tze zu.
Die Attributeindeutigkeit ist eine Funktion von Identity Server, die von Messaging Server verwendet wird. Damit Ihre LDAP-Datenbank von Identity Server verwaltet werden kann, m�ssen Sie die Bereitstellung so durchf�hren, dass die Einschr�nkungen hinsichtlich der Eindeutigkeit beachtet werden, die durch sunNameSpace und sunNameSpaceUniqueAttrs auferlegt werden.
In der nachfolgenden Abbildung finden Sie ein Beispiel von Dom�nen als Namespaces.
Abbildung 12–5 Dom�nen als Namespaces
In der obigen Abbildung sind drei Dom�nen enthalten, von denen jede mit der Objektklasse sunNameSpace und einem auf uid eingestellten sunNameSpaceUniqueAttrs-Attribut versehen ist. Bei jeder Dom�ne handelt es sich um einen Namespace, in der keine zwei Eintr�ge dieselbe uid aufweisen d�rfen. Hierdurch wird es au�erdem m�glich, dass mehrere Dom�nen Eintr�ge mit derselben eindeutigen ID enthalten, ohne dass hierdurch die Einschr�nkungen hinsichtlich der Eindeutigkeit der separaten Dom�nen verletzt werden. Jede der drei Dom�nen enth�lt beispielsweise einen Eintrag, dessen uid jdoe lautet. Dies ist zul�ssig, da es sich bei jeder Organisation um einen separaten Namespace handelt. Um einen bestimmten jdoe in diesem Beispiel ausfindig zu machen, muss f�r die Suchvorlage der Name der Organisation (Dom�ne) angegeben werden.
Jeder Dom�ne k�nnen weitere unterschiedliche Attribute zugewiesen werden. Es ist beispielsweise m�glich, dass die Benutzer einer Dom�ne alle �ber eine eindeutige telephoneNumber verf�gen. F�r diese Dom�ne w�re der Eintrag folglich zus�tzlich mit sunNameSpaceUniqueAttrs=telephoneNumber versehen, und keine zwei Benutzer k�nnten �ber dieselbe Telefonnummer verf�gen.
Sich �berschneidende Namespaces und der Root-Knoten
Das �berschneiden von Namespaces ist in Sun ONE LDAP Schema v.2 m�glich, der Root-Knoten darf jedoch nicht zu einem Namespace gemacht werden.
Wenn Ihre Installation mehrere Dom�nen enthalten soll, weisen Sie das Attribut sunNameSpaceUniqueAttrs nicht dem Root-Suffix-Knoten zu (in unserem Beispiel: basisdn), da hierdurch allen Dom�nen unter dem Root die Verwendung der im Root-Eintrag genannten Attribute zur Erzwingung der Eindeutigkeit untersagt wird.
Wenn beispielsweise sunNameSpaceUniqueAttrs=uid im Root-Knoten vorhanden ist, k�nnen keine der anderen Dom�nen die uid zum Erzwingen der Eindeutigkeit in ihrer Dom�ne verwenden.
Identity Server stellt sunNameSpace automatisch f�r den Root-Knoten bereit, das Attribut wird jedoch nicht hinzugef�gt. Da die Funktion f�r die Eindeutigkeit ohne das Vorhandensein von sunNameSpaceUniqueAttrs nicht aktiviert wird, kann der Root-Knoten nicht als Namespace verwendet werden, es sei denn, Sie f�gen das Attribut ausdr�cklich hinzu.
Hinweis
F�gen Sie in Hinblick auf Messaging Server sunNameSpaceUniqueAttrs nicht zum Root-Knoten hinzu.
SuchvorlagenIn diesem Abschnitt werden Funktion und Formatierung von Suchvorlagen erl�utert.
Hinweis
�nderungen des Formats von Suchvorlagen sind vorbehalten. Die Verwaltung von Suchvorlagen sollte �ber Identity Server erfolgen.
�berblick �ber Suchvorlagen
Bei Vorlagen handelt es sich um Eintr�ge im Organisationsbaum, die speziellen Zwecken dienen. In Messaging Server werden sie wie folgt zum Ausfindigmachen von LDAP-Eintr�gen f�r Dom�nen, Benutzer und Gruppen verwendet:
- Im nativen Modus verwendet Messaging Server die BasicOrganizationSearch-Vorlage und f�hrt mithilfe des in der Vorlage enthaltenen Suchfilters eine spezifische Suche durch.
- Im Kompatibilit�tsmodus pr�ft Messaging Server mithilfe der BasicDomainSearch-Vorlage die Einstellung von rfc2247Flag. Wenn die Flagge auf true eingestellt ist, wird der Suchfilter ignoriert und der DC-Baum verwendet, um den richtigen Organisationsbaumknoten zu finden, wie in fr�heren Versionen von Messaging Server.
Es gibt zwei Arten von Suchvorlagen:
- Interne Suchvorlagen – Jede Organisation kann �ber Vorlagen verf�gen, die sich ausschlie�lich auf Vorg�nge innerhalb dieser Organisation beziehen. Diese internen Vorlagen werden im DIT unterhalb der einzelnen Organisationen gespeichert, und zwar unter:
ou=default,ou=OrganizationConfig,ou=1.0,ou=DAI,ou=services, orgdn.
Weitere Informationen zu Objektklassen und Attributen finden Sie in Sun ONE Messaging and Collaboration 6.0 Schema Reference Manual (http://docs.sun.com/doc/816-6710-10).
Format von Suchvorlagen
Suchvorlagen weisen folgende Elemente auf:
Ein Boolescher Wert („true“, „false“), der Anwendungen anweist, anstatt des angegebenen Suchfilters den RFC 2247-Algorithmus zur DN-Erstellung des zu suchenden LDAP-Eintrags zu verwenden. (Dies dient der Abw�rtskompatibilit�t mit Installationen, in denen LDAP-Strukturen im Kompatibilit�tsmodus vorhanden sind, beispielsweise Installationen von iPlanet Messaging Server 5.2.) Durch dieses Element wird das System gezwungen, den DC-Baum nach einem passenden inetDomainBaseDN-Attribut zu durchsuchen, das auf den richtigen Organisationsknoten im Organisationsbaum verweist. Weitere Informationen zu DC-B�umen finden Sie in iPlanet Messaging Server 5.2 Provisioning Guide (http://docs.sun.com/doc/816-6011-10).
Gruppen (Adresslisten)�ber Gruppen (in Messaging Server als Adresslisten bezeichnet) k�nnen Benutzer von Diensten eine Gruppe anderer Benutzer kontaktieren, ohne die Mitglieder einzeln nennen zu m�ssen. In Messaging Server ist dies gleichbedeutend mit dem Senden von E-Mail-Nachrichten an mehrere Mailboxen, ohne jede E-Mail-Adresse einzeln angeben zu m�ssen. Messaging Server unterst�tzt sowohl statische als auch dynamische Adresslisten (Gruppen). Jeder Listentyp weist einen LDAP-Eintrag auf, der von der Objektklasse inetMailGroup unterst�tzt wird.
In statischen Adresslisten werden Mitglieder der Liste direkt im LDAP-Gruppeneintrag aufgef�hrt. Bei dynamischen Adresslisten werden Mitglieder �ber einen LDAP-Suchfilter (RFC-2254) angegeben.
In dynamischen Gruppen ist eine weitere Unterteilung m�glich: Eine dynamische Gruppe ist entweder zuweisbar oder gefiltert. Au�erdem k�nnen s�mtliche Gruppentypen entweder offen (Abonnement m�glich) bzw. geschlossen (Abonnement nicht m�glich) sein. Eine Ausnahme stellt die gefilterte dynamische Gruppe dar, die nicht offen sein kann.
Es kann sich als hilfreich erweisen, sich die unterschiedlichen Kombinationen vor Augen zu f�hren, die in folgender Tabelle aufgef�hrt sind:
Offen/Geschlossen
Statisch
Zuweisbar und dynamisch
Gefiltert und dynamisch
Offen (Abonnement m�glich)
Ja
Ja
Nein
Geschlossen (Abonnement nicht m�glich)
Ja
Ja
Ja
Gruppentypen
Es gibt drei Gruppentypen:
- Statisch. Eine statische Gruppe weist einen LDAP-Eintrag auf, mit dem alle Mitglieder aufgelistet werden. Hierbei wird das Attribut uniqueMember f�r interne Mitglieder und das Attribut mgrpRFC822MailMember f�r externe Mitglieder verwendet.
- Zuweisbar und dynamisch. Der LDAP-Eintrag einer zuweisbaren dynamischen Gruppe enth�lt einen Suchfilter, der im Attribut mgrpDeliverTo festgelegt wird. Bei dem gefilterten Attribut muss es sich um ein bekanntes Attribut handeln. Das standardm��ige bekannte Attribut f�r Messaging Server ist memberOf, ein Attribut, das nun von Identity Server unterst�tzt wird, unter Verwendung der Objektklasse inetAdmin.
F�r die dynamische Gruppe mit der Bezeichnung HRStaff, weist das Attribut mgrpDeliverTo beispielsweise folgenden Wert auf:
(&(objectclass=inetAdmin) (memberOf=cn=HRStaff, ou=Groups, o=sesta.com, o=basisdn))
Au�erdem enth�lt der Benutzereintrag jedes Mitglieds folgende Zeilen:
objectClass: inetAdmin
memberOf: HRStaff
- Gefiltert und dynamisch. Wie bei zuweisbaren dynamischen Gruppen enth�lt der LDAP-Eintrag einer gefilterten dynamischen Gruppe einen Suchfilter, der im Attribut mgrpDeliverTo festgelegt wird. In diesem Fall k�nnen Gruppenmitglieder durch die Filterung mit beliebigen Attributen (einem oder mehreren) ermittelt werden. Ein Filter kann beispielsweise folgenderma�en aussehen:
(&((objectclass=inetMailUser)(city=tokyo)&(objetclass=inetOrgPerson)(uid=jdoe)))
Au�erdem k�nnen statische Gruppen ebenfalls dynamische Mitglieder enthalten. Hierzu muss das Attribut mgrpDeliverTo zum LDAP-Eintrag der statischen Gruppe hinzugef�gt werden.
Jeder Gruppentyp verf�gt �ber eine eigene Identity Server-Objektklasse. In der folgenden Tabelle werden s�mtliche Gruppentypen sowie die Identity Server-Objektklasse aufgelistet, die jeweils bei der Bereitstellung zum Einsatz kommt:
Gruppentyp
Identity Server-Objektklasse
Statisch
iplanet-am-manged-static-group
Zuweisbar und dynamisch
iplanet-am-managed-assignable-group
Gefiltert und dynamisch
iplanet-am-managed-filtered-group
Hinweis
Die iplanet-am-managed-group-Objektklasse ist die �bergeordnete Klasse f�r alle drei dieser Klassen, ihre Verwendung im LDAP-Eintrag einer Gruppe ist jedoch optional.
Offene und geschlossene Gruppen
Offene Gruppen sind Gruppen, die von jedem Benutzer abonniert werden k�nnen. Wenn das Attribut iplanet-am-group-subscribable im LDAP-Eintrag der Gruppe mit dem Wert true vorhanden ist, ist die Gruppe offen (Abonnement ist m�glich). Dies ist ein optionales Attribut. Wenn das Attribut nicht vorhanden ist, gelten Gruppen als geschlossen (Abonnement nicht m�glich). Das Attribut kann auch den Wert false aufweisen, was bedeutet, dass die Gruppe geschlossen ist (Abonnement nicht m�glich).
Dienststufe (Class of Service, CoS)Mit dem erweiterten CoS-Eintragsverwaltungsmechanismus k�nnen Sie virtuelle Attribute erstellen, die nicht in den Eintr�gen gespeichert wurden. Stattdessen werden sie vom CoS-Mechanismus generiert, wenn der Eintrag an die Client-Anwendung �bertragen wird. Genau wie bei Gruppen und Rollen ist CoS von Hilfseintr�gen in Ihrem Verzeichnis abh�ngig.
Folgende drei Mechanismen sind verf�gbar:
Die klassische CoS ist der empfohlene Mechanismus f�r die Bereitstellung der Messaging Server-CoS und wird in diesem Abschnitt erl�utert.
Weitere Informationen zu diesen erweiterten Eintragsverwaltungsmechanismen finden Sie in Sun ONE Directory Server 5.2 Administration Guide und in Sun ONE Directory Server 5.2 Reference Manual. Diese Dokumente finden Sie auf der Dokumentations-Website von Sun:
http://docs.sun.com/prod/s1dirsrv
CoS f�r Messaging Server
�ber die CoS-Funktion k�nnen Sie eine benannte Gruppe fester Funktionen und Attribute erstellen, die auf angegebene Benutzer angewendet werden k�nnen. Mit der CoS-Funktion k�nnen Sie eine Vorlage mit Attributen erstellen, die auf Benutzereintr�ge mit einem einzelnen Attribut �bertragen werden kann. Als Internetdienstanbieter k�nnen Sie beispielsweise zwei Stufen f�r den Maildienst erstellen, die die Bezeichnung MS1 und MS2 tragen, indem Sie folgende Schritte durchf�hren:
- Auf der MS1-Dienststufe k�nnten den Benutzern IMAP-, Secure IMAP-, POP3- und HTTP-(Web-Mail-)Maildienste sowie 5 GB Festplattenspeicher f�r Nachrichten zur Verf�gung gestellt werden.
- Auf der MS2-Dienststufe k�nnten POP3-Maildienste sowie 5 MB Festplattenspeicher f�r Nachrichten verf�gbar gemacht werden.
Hinweis
LDAP-Suchanforderungen mit einem Filter, der auf ein Attribut verweist, das durch eine Dienststufe definiert wird, werden nicht unterst�tzt. Es kann beispielsweise keine erfolgreiche Suche zum Attribut mailquota durchgef�hrt werden, wenn mailquota nur in einer Dienststufen-Vorlage, nicht in Benutzereintr�gen, definiert wurde. Wenn eine Anforderung dieser Art an den Server �bermittelt wird, gibt er die Fehlermeldung Ausf�hrung verweigert aus.
Diese und andere Einschr�nkungen sind in Sun ONE Directory Server 5.2 Administration Guide (http://docs.sun.com/doc/816-6698-10) aufgef�hrt (siehe fr�herer Verweis).
Einrichten von CoS in Messaging Server
Die anspruchsvolle �bersicht zum Hinzuf�gen der Dienststufen-Funktion umfasst folgende Vorg�nge:
- Aktivieren des Dienststufen-Plug-Ins
Das Dienststufen-Plug-In wird automatisch mit Directory Server installiert. Um das Plug-In und somit CoS zu aktivieren, muss die SLAPD-Konfigurationsdatei ge�ndert werden.
Informationen zur Konfiguration des Dienststufen-Plug-Ins finden Sie in Sun ONE Directory Server 5.2 Administration Guide (http://docs.sun.com/doc/816-6698-10).
- Neustarten von Directory Server
- Erstellen des CoS-Containers f�r CoS-Vorlagen und -Definitionen
- Erstellen eines CoS-Mailschemas unterhalb des CoS-Containers
Jeder Mailschemaeintrag enth�lt Folgendes:
- CoS-Mailschemaeintrags-DN (mit ou:CoS).
- Objektklasse, die den Dienststufen-Schemaeintrag definiert (objectClass:cosClassicDefinition).
- Attribut mit mehreren Werten, das Teilb�ume (Namen von Verzeichnissen) enth�lt, unter denen die CoS-Vorlageneintr�ge f�r dieses Schema gespeichert sind (cosTemplateDN).
- Attribut mit mehreren Werten, das den Teilbaum enth�lt, auf den sich das CoS-Schema bezieht (cosTargetTree).
- Name des Attributs, das zur Angabe der CoS-Vorlage verwendet wird, die auf einen Benutzereintrag angewendet wird (cosSpecifier:inetCOS).
- In einem Vorlageneintrag zu verwendende Attribute (cosAttribute mit mehreren Werten).
- Erstellen des Containers f�r die CoS-Vorlagen
- Erstellen der CoS-Vorlagen
- Zuweisen einer Dienststufe zu Benutzereintr�gen
So erstellen Sie eine CoS – Beispiel
Bei diesem Beispiel wird davon ausgegangen, dass das CoS-Plug-In bereits installiert und konfiguriert ist und dass Directory Server ausgef�hrt wird. Aus diesem Beispiel geht hervor, wie ein Maildienst f�r zwei Dienststufen, MS1 und MS2, in der Host-Dom�ne sesta.com erstellt wird. Die beiden Dienststufen erf�llen folgende Zwecke:
- Auf der MS1-Dienststufe werden den Benutzern IMAP-, Secure IMAP-, POP3- und HTTP-(Web-Mail-)Maildienste sowie 5 GB Festplattenspeicher f�r Nachrichten zur Verf�gung gestellt.
- Auf der MS2-Dienststufe werden POP3-Maildienste sowie 5 MB Festplattenspeicher f�r Nachrichten verf�gbar gemacht.
- Erstellen Sie den Container f�r CoS-Schemata- und -Vorlagen.
Durch diesen Eintrag wird der Container als organizationalUnit (ou) definiert.
Aus folgendem Codebeispiel ist der LDIF-Eintrag f�r die Erstellung des CoS-Containers ersichtlich:
- Erstellen Sie mit folgendem LDIF-Beispieleintrag ein CoS-Mailschema:
- Erstellen Sie den Container f�r Mailschema-Vorlagen.
Verwenden Sie zur Containererstellung folgende LDIF-Beispielanweisung:
dn: ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basisdn
changetype: modify
add: organizationalunit
ou: MailSchemeClasses
- Erstellen Sie CoS-Vorlagen.
Verwenden Sie nachfolgendes LDIF-Beispiel, um die beiden Vorlageneintr�ge f�r die MS1- und MS2-Vorlagen zu erstellen.
dn: cn=MS2,ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basisdn
objectClass: top
objectClass: costemplate
objectClass: extensibleobject
objectClass: ldapsubentry
mailQuota: 5000000
mailAllowedServiceAccess: +pop3:*
dn: cn=MS1,ou=MailSchemeClasses,ou=CoS,o=sesta.com, o=basisdn
objectClass: top
objectClass: costemplate
objectClass: extensibleobject
objectClass: ldapsubentry
mailQuota: 5000000000
mailAllowedServiceAccess: +imap, imaps, pop3, http:*
- F�gen Sie eine Dienststufe zu einem Benutzereintrag hinzu.
