Praxistipp zur Benutzerübernahme
Vorbereitung
ELO Benutzer und ihre Zugriffsrechte im Repository sind für die E-Mail-Ablage von zentraler Bedeutung, weil Nachrichten – geschäftlich oder nicht – in der Regel nicht kompromittiert werden sollten. Das kann durch eine manuelle Vorbereitung des Repositorys vor der ersten E-Mail-Archivierung geschehen. Es kann aber auch automatisch von ELOxc bewerkstelligt werden. Im Zentrum dieser Überlegungen steht immer der externe Postfachbesitzer, dessen Nachrichten verarbeitet werden und später im Repository geeignet zur Verfügung stehen sollen. Alle zu verarbeitenden externen Postfachbesitzer werden von ELOxc in Postfachkatalogen zusammengefasst, die bei Abfragen der externen Verzeichnisse entstehen.
Praxisbeispiel, BenutzerübernahmeBenutzerübernahme, PraxisbeispielDie automatische Übernahme von Benutzerkonten aus dem Katalog ist keine Standardeinstellung von ELOxc, da sie möglicherweise zu Konflikten mit dem LDAP-Import der ELO Administration Console oder bereits vorhandenen Altdaten führen kann. Wird dagegen zuvor schon die LDAP-Anbindung des ELO Indexservers eingesetzt, steht einer gleichzeitigen Nutzung der Benutzerübernahme durch ELOxc zwar nichts im Wege, jedoch sollte abgewogen werden, ob diese tatsächlich notwendig ist oder ob die LDAP-Anbindung nicht die vollständigere Übernahme durchführt. ELOxc reduziert sich auf Postfachattribute. Beide Übernahmeformen sind jedoch kompatibel, da sie beide die externen Benutzer über eine in den Verzeichnissen vorhandene GUID identifizieren. Damit kann ELOxc vor dem ersten Einsatz der LDAP-Anbindung des ELO Indexservers Benutzerdaten übernehmen, ohne deren späteren Einsatz zu verhindern.
Die automatische Übernahme von Benutzerkonten sollte deshalb sorgfältig geplant werden. Wenn diese Planung abgeschlossen ist, kann gegebenenfalls ELOxc die relevanten Katalogdaten der Benutzer automatisch übernehmen und dazu auch konfigurierte Berechtigungseinstellungen für archivierte Elemente setzen. Diese Entscheidung würde vermutlich dann getroffen werden, wenn Nachrichten abgelegt werden sollen, bevor die Postfachbesitzer Gelegenheit haben, sich das erste Mal im Repository anzumelden.
Zusätzlich beeinflussen die unterschiedlichen Postfachtypen, welche von ELOxc verarbeitet werden, wie auch der Ablagepfad die resultierenden Berechtigungseinstellungen nach E-Mail-Ablage. Deshalb besteht dieses Praxisbeispiel aus mehreren Teilen, die aufeinander aufbauend beschrieben sind und dabei auch zentrale Steuerungsmechanismen der ELO Zugriffsberechtigungen illustrieren.
Wir empfehlen, die Beispielkonfigurationen auszuprobieren und dieses Praxisbeispiel – je nach individuellem Erfahrungsstand – mit eigenen Tests nachzuvollziehen.
Sie benötigen:
- ELO 20
- ELO Administration Console
- ELO Client
- Microsoft Outlook
- 3x Benutzerpostfach – 1x Absender, 2x Empfänger
- 1x freigegebenes Postfach (mit diesen Benutzerpostfächern als Delegaten)
- ELOxc
- Microsoft Active Directory
- Microsoft 365
- Remote-PowerShell (Standardauthentifizierung)
- App-Registrierung für Microsoft Graph API (OAuth2)
Standardverfahren
Der Standardfall von ELOxc legt die Annahme zugrunde, dass vor der ersten Postfacharchivierung die gewünschte Benutzerstruktur im Repository vorbereitet wurde. Postfächer werden nur über den Ablagepfad mit ELO Daten assoziiert, wofür die Automatismen der Maskenberechtigungen genutzt werden, die auch in den nachfolgenden Beispielen bei automatischer Benutzerübernahme eine wesentliche Rolle spielen. Das Standardverfahren wird gezielt eingesetzt, wenn eine Entkoppelung der externen Benutzer von den ELO Benutzern gewünscht ist. Notwendig ist es dagegen, wenn ein statischer Postfachkatalog konfiguriert wurde.
In diesem Beispiel soll ein Benutzer im Hauptordner E-Mails (vorbereitet) seinen eigenen Ordner erhalten, wo Nachrichten entsprechend der Ordnerstruktur in Outlook abgelegt werden sollen. Dieser Ordner soll nach seiner SMTP-Adresse benannt werden:
Beide Ordner werden mit der Standardordnermaske so erzeugt, dass alle Benutzer für sie berechtigt sind. Da jedoch eine benutzerbezogene E-Mail-Ablage konfiguriert werden soll, müssen die abgelegten E-Mails vor unbefugtem Zugriff anderer Benutzer durch geeignete Berechtigungseinstellungen geschützt werden.
Zuerst muss der Benutzer angelegt werden. Das geschieht mit der ELO Administration Console:
Nach dem Speichern taucht der neue Benutzer in der Liste auf:
Im Client werden nun die Berechtigungen für beide Ordner gesetzt. Navigieren Sie im Client zum Hauptordner E-Mails (vorbereitet).
Auf den Hauptordner können alle Benutzer lesend zugreifen:
Der Benutzerordner, der das abgelegte Postfach enthalten soll, bekommt Berechtigungseinstellungen, die xc191 die Rechte gewähren, die E-Mails zu lesen, sie zu verschieben und ihre Metadaten bei Bedarf anzupassen:
Nachdem die Ordner so konfiguriert wurden, können Nachrichten für xc191 abgelegt werden. Die zu erwartende Ordnerstruktur von Outlook wird über die Berechtigungseinstellungen der verwendeten Masken automatisch abgesichert. Die Standardmasken Ordner und E-Mail besitzen bereits die erforderliche Berechtigungseinstellung Vorgängerrechte, womit sichergestellt wird, dass die Berechtigungen auf die übertragenen Postfachordner und Nachrichten während der Verarbeitung richtig weitergegeben werden.
Mit ELOxc wird nun eine einfache E-Mail-Ablage konfiguriert. Sie beruht auf den beiden Metadatenvorlagen KW_DEFAULT_DOCUMENT und KW_DEFAULT_FOLDER. KW_DEFAULT_DOCUMENT wird den abgelegten Dokumenten bzw. Nachrichten zugeordnet und KW_DEFAULT_FOLDER den erzeugten Ordnern:
Beide Metadatenvorlagen gehören zu den Voreinstellungen von ELOxc, weshalb ihre Existenz bei jedem Start von ELOxc geprüft wird. Fehlen sie, werden sie von ELOxc automatisch neu erzeugt. Zudem enthalten sie bereits die Standardabbildungen von Nachrichtenattributen auf Metadatenfelder. Sie sollten deshalb also nicht verändert werden. Wenn abweichende Vorlagen benötigt werden, können diese jederzeit - auch als angepasste Kopien der beiden Standardvorlagen - neu erstellt werden.
Diese einfache Ablage verwendet einen aktiven Aktionsbaum Archive Simple.
Der aktive Aktionsbaum ruft einen sogenannten Subtree (Unterbaum bzw. Vorlagenbaum) auf, in dem Export, Archivierung, Markierung und Speichern konfiguriert sind.
Damit das richtige Ablageziel im Repository verwendet wird, muss die Aktion Ablagepfad passend vorbereitet werden:
Der Pfad wird während der Ablage so erzeugt, dass bereits vorhandene Pfadsegmente verwendet und fehlende erzeugt werden. Damit wird sichergestellt, dass die Einstellungen der vorbereiteten Ordner E-Mails (vorbereitet) und xc191@xc.local unverändert bleiben. Das bedeutet gleichzeitig aber auch, dass die Pfadsegmente im Repository nach ihrer Erzeugung von ELOxc nicht mehr verändert werden, weil außer der Ordnernamen kein anderes Erkennungsmerkmal verwendet wird.
Das Segment für den Hauptordner wird so konfiguriert:
Da der Name E-Mails (vorbereitet) vorbelegt ist und feststeht, muss der Segmenttyp auf constant gesetzt werden. Die Metadatenvorlage dieses Pfadsegments bleibt leer, da die Vorlage KW_DEFAULT_FOLDER bereits auf oberster Ebene für die gesamte Aktion festgelegt ist. Möchten Sie für einzelne Pfadsegmente des Ablagepfads abweichende Vorlagen verwenden – beispielsweise mit anderen Masken – können Sie das in diesem Feld des Segments konfigurieren. In diesem Beispiel wird aber auf segmentgebundene Metadaten verzichtet.
Der automatisch ermittelte Name des nächsten Segments ist in diesem Beispiel die SMTP-Adresse des Postfachs. Hierfür ist die Variable BoxAddr zuständig.
Das dritte Pfadsegment verwendet die Variable BoxPath, womit während der Ablage die Struktur aus Outlook übertragen wird.
Wenn nun Nachrichten verarbeitet werden, können Sie im Repository sehen, dass die gewünschten Berechtigungseinstellungen automatisch richtig übernommen werden:
Automatische Übernahme von Benutzerkonten
In diesem Beispiel mit automatischer Benutzerübernahme bei E-Mail-Ablage wird ebenfalls die Verwendung eines Hauptordners angenommen, der nun E-Mails (unvorbereitet) benannt werden soll, in dem sich nach Ablage dann die Postfachordner mit Outlook-Strukturen befinden sollen. Hierfür muss im Repository nichts vorbereitet werden. Es werden auch keine ELO Benutzer erzeugt. Sie sollten während Ihrer Tests nur darauf achten, die erzeugten Benutzer immer wieder zu löschen, um bei neuen Beispielen auch Änderungen der Benutzerübernahme sehen zu können.
Dazu muss in der Instanzenkonfiguration die Übernahme aktiviert werden.
Parameter:
- Besitzübernahme: Bewirkt, dass der automatisch erzeugte Benutzer im Repository auch als Besitzer der neu erzeugten Dokumente eingetragen wird.
- Benutzerbenachrichtigungen: Aktiviert das automatische Versenden einer Nachricht, in der die Anmeldedaten des Benutzers stehen.
- Identitätsformat: Dieses Auswahlfeld stellt ein, welches Katalogattribut als ELO Benutzername verwendet werden soll. Die möglichen Attribute sind UserPrincipalName, sAMAccountName und displayName.
- Passwort: Hier kann ein Standardpasswort für alle übernommenen Benutzer konfiguriert werden. Bleibt das Feld leer, erzeugt ELOxc ein zufälliges Passwort, wobei in diesem Fall eine Benutzerbenachrichtigung notwendig wird, da das Passwort sonst unbekannt ist. Wird ein ELO Benutzer erzeugt, erhält er bei erster Anmeldung immer die Gelegenheit, dieses Passwort durch ein eigenes zu ersetzen.
- Standard-ACL: Hier wird die ACL für den Benutzerordner festgelegt. Diese Berechtigungseinstellung wird durch die Vererbungsmechanismen der Maske auf alle übertragenen Elemente angewendet (die Belegung mit RW ist hier willkürlich zur Abgrenzung von RWDELP gewählt).
- Gruppenzugehörigkeit und Gruppenpräfix: Jeder übernommene Benutzer wird automatisch als Mitglied einer Gruppe angelegt, deren Name mit diesen beiden Feldern eingestellt wird. Die Trennung in einen Gruppennamen und ein Präfix ist erforderlich, um die von ELOxc generierten Gruppen zu erkennen. Wird ein Benutzerpostfach verarbeitet, dann wird damit der Gruppenname ELOxc_USERS verwendet. In anderen Fällen kann der Namensteil USERS jedoch Namen von freigegebenen Postfächern überschrieben werden.
Führen Sie mit diesen Einstellungen eine E-Mail-Ablage durch, erhalten Sie folgendes Ergebnis:
Die Nachricht Automatisiert ohne Besitzerübernahme wird archiviert und erhält die konfigurierten Berechtigungseinstellungen RW. Zusätzlich erhält der Benutzer xc191 eine Nachricht, die ihn über sein neu erstelltes ELO Benutzerkonto informiert:
Damit kann sich der Benutzer auch gleich am Repository anmelden und wird dazu aufgefordert, sein eigenes Kennwort zu setzen:
Aktivieren Sie in der Instanzenkonfiguration Besitzübernahme, wird jede abgelegte E-Mail und jeder auf dieser Weise erzeugte Ordner des Ablagepfads dem Postfachbesitzer zugeordnet, als ob er sie selbst abgelegt hätte:
Verzichten Sie auf die Verwendung der Besitzübernahme, wird die abgelegte Nachricht automatisch dem Dienstkonto zugewiesen.
Die Rechtevergabe der automatischen Benutzerübernahme funktioniert nur dann sinnvoll, wenn der Ablagepfad eine Variable verwendet, die mit dem Postfachbesitzer assoziiert wird:
Die Variablen werden folgendermaßen belegt:
| Variable | LDAP-Benutzerattribut |
| BoxAccount | sAMAccountName |
| BoxAddr | |
| BoxName | displayName |
| BoxUPN | UserPrincipalName |
Information: Wenn im Ablagepfad eine dieser Variablen erkannt und mit einem entsprechenden Wert belegt wird, setzt ELOxc für das Pfadsegment gleichzeitig die konfigurierte ACL. Es ist deshalb sinnvoll, pro Ablagepfad nur eine postfachassoziierte Variable zu verwenden. Gleichzeitig muss für eine erfolgreiche und sichere Postfachemulation immer eine dieser Variablen konfiguriert werden. Geschieht dies nicht, können Daten kompromittiert werden.
Bei der Überprüfung der Übernahme in der ELO Administration Console finden Sie sowohl den Benutzer xc191 als auch die Benutzergruppe ELOxc_USERS:
Der Benutzername xc191@xc.local wird aus dem Verzeichnisattribut UserPrincipalName übernommen. Bei dieser Wahl der Identität wird Windows-Benutzer automatisch im Format <Domäne>\<Konto> gesetzt. Die SMTP-Adresse wird als E-Mail übernommen, und der neu erstellte Benutzer wird automatisch der Gruppe ELOxc_USERS zugeordnet, die in der Konfiguration mit den Parametern Gruppenpräfix und Gruppenzugehörigkeit eingetragen wurde:
Information: Die Benutzer-ID kann nicht verändert werden, da sie vom ELO Access Manager automatisch bestimmt wird. Sie ist eine interne Identifikation und spielt für die Übernahme von Benutzern eine wichtige Rolle, da sie die Verbindung von Benutzerdatensätzen und Berechtigungseinstellungen herstellt. Sie ist damit der wesentliche Grund dafür, dass bei Benutzerübernahme aus einem externen Verzeichnis bereits übernommene Benutzer in ELO identifiziert werden müssen, da ansonsten Berechtigungseinstellungen verloren gehen, verwaisen oder gar falsch zugeordnet werden. Bei Benutzerübernahme mit der LDAP-Anbindung des Indexservers oder bei Übernahme durch ELOxc wird die Identifizierung über das Verzeichnisattribut objectGUID gewährleistet. Bei Benutzerübernahme mit dem LDAP-Import der ELO Administration Console müssen Sie zur Verwendung der objectGUID eine Anpassung vornehmen.
Bei Verwendung von LDAP-Postfachkatalogen werden ELO Vorgesetzte automatisch ELO Benutzern zugeordnet. Voraussetzung dafür ist das LDAP-Attribut manager.
Der Benutzer xc192 erhält im lokalen Verzeichnis xc191 als Vorgesetzten zugeordnet:
Bei aktiver Benutzerübernahme wird der ELO Benutzer xc192 so erzeugt, dass der ELO Benutzer xc191 als dessen Vorgesetzter eingetragen ist:
Wenn das Attribut manager nicht gesetzt ist, wird ELO Administrator als Vorgesetzter gesetzt. Sollte bei einer nachfolgenden Verarbeitung das Attribut verfügbar sein oder sich geändert haben, wird die Einstellung übernommen.
ELO Benutzereinträge bei automatischer Übernahme
Um mit der automatischen Benutzerübernahme zusätzlich auch den Bereich ELO Benutzereinträge zu unterstützen und E-Mails in diesen Strukturen abzulegen, muss die Konfiguration des Ablagepfades geändert werden. Anstatt des Standardwertes archive wird user verwendet:
Die ELO Benutzereinträge gehören zur Standardkonfiguration eines Repositorys und werden mit allen ELO Benutzern geteilt. Darin befindet sich ein persönlicher Bereich, der vor dem Zugriff anderer Benutzer geschützt ist. Setzen Sie die Wurzel auf user, werden die E-Mails genau darunter abgelegt. Damit entfällt der Erzeugungszwang eines postfachassoziierten Ordners, weshalb sich die Konfiguration des Ablagepfades vereinfacht:
Legen Sie nun eine Nachricht ab, erkennen Sie am Ergebnis, dass die Berechtigungseinstellungen des persönlichen Bereichs automatisch übernommen werden:
Freigegebene Postfächer bei automatischer Übernahme
Wenn Nachrichten eines freigegebenen Postfachs (shared mailbox) abgelegt werden sollen, stehen zwei verschiedene Postfachtypen zur Verfügung – shared und user:
Ein freigegebenes Postfach shared19 mit den konfigurierten Delegaten xc191 und xc192 wird mit der Einstellung shared verarbeitet, was die Postfachemulation auslöst, in deren Verlauf das Postfach shared19 als die Postfächer xc191 und xc192 verarbeitet wird. Damit das möglich ist, muss der Ablagepfad auch hier wieder eine Variable verwenden, die mit dem Postfach und damit indirekt den Delegaten als dessen Besitzer assoziiert wird. Die Pfadkonfiguration sieht beispielsweise so aus:
Wird die E-Mail-Ablage als Postfachtyp shared durchgeführt, entsteht im Repository dieses Ergebnis:
Jeder Delegat erhält ein Exemplar der verarbeiteten Nachricht. Die Berechtigungseinstellungen entsprechen der Konfiguration aus der Instanzenkonfiguration. Wird die Verarbeitung jedoch mit dem Typ="user" – im sogenannten nativen Modus – durchgeführt, dann erzeugt ELOxc diese Ablage:
Für das freigegebene und in diesem Fall nicht emulierte (bzw. aufgelöste) Postfach shared19@xc.local wird genau ein Nachrichtenexemplar abgelegt.
Für die Berechtigungseinstellungen wird bei Verarbeitung eines freigegebenen Postfachs unabhängig des konfigurierten Typen - user oder shared – immer eine ELO Benutzergruppe erzeugt, deren Mitglieder die Delegaten von shared19@xc.local sind. Dabei gilt jedoch, dass Typ="shared" individuelle Zugriffsrechte und Typ="user" Gruppenrechte zuweist.
In der ELO Benutzerverwaltung können Sie sehen, dass für shared19@xc.local eine Benutzergruppe ELOxc_SHARED19 erzeugt wurde, die selbst Mitglied in der allgemeinen Gruppe ELOxc_USERS ist. Das geschieht unabhängig von Typ="shared" und Typ="user", womit die Postfachkonfiguration und damit wahrscheinliche Postfachnutzung wiedergegeben wird.
Die Postfachdelegaten sind der Benutzergruppe ELOxc_SHARED19 zugewiesen:
Die Verarbeitung mit Postfachemulation und im nativen Modus erzeugt bei Pfadwurzel user ein kongruentes Ergebnis zur Pfadwurzel archive.
Hier sehen Sie das Ergebnis mit Postfachemulation:
Hier sehen Sie den nativen Modus bzw. ohne Postfachemulation:
Journalempfänger bei automatischer Übernahme
Auch bei Verarbeitung von Journalempfängern werden Benutzerkonten automatisch übernommen. Hierbei gilt jedoch, dass im Unterschied zu freigegebenen Postfächern ein Journal nicht im Sinne einer Zusammenarbeit verwendet wird. Ein Journalempfänger ist ein Benutzerpostfach und wird ELO deshalb auch als Benutzer repräsentiert.
Journalempfänger, Benutzer übernehmenSolange ein Journal als Postfachtyp journal in ELOxc konfiguriert wird, findet die zu erwartende Postfachemulation mit automatischer Erzeugung aller Benutzer statt, deren Postfächer auf derselben Postfachdatenbank des Exchange Servers liegen. Wird das Journal jedoch nativ verarbeitet, werden Benutzerkonten für alle Postfachbesitzer des Journals zuzüglich des Benutzerkontos des Journalempfängers in ELO erzeugt.
Eine E-Mail-Ablage mit Postfachemulation ( Typ="journal") des Journalempfängers journal19@xc.local:
Die Ablage mit dem Typ="user" im nativen Modus ergibt dieses Resultat:
Aufgrund der nativen Postfachverarbeitung taucht der Journalempfänger wie die im Journal befindlichen Postfachbesitzer in der Benutzerverwaltung auf:
Wird eine postfachemulierende Ablage im Bereich ELO Benutzereinträge (Pfadwurzel user) vorgenommen, finden Sie im Repository eine benutzerorientierte Ablage vor:
Bei nativer Verarbeitung (Typ="user") des Journalempfängers in ELO Benutzereinträge wird für genau ein Nachrichtenexemplar im Repository für journal19@xc.local abgelegt:
Die Ablage von Journalempfängern im nativen Modus unterscheidet sich nicht nur hinsichtlich des zusätzlich übernommenen Benutzers journal19 vom nativen Modus freigegebener Postfächer. Es werden auch andere Nachrichten abgelegt:
Das Nachrichtenoriginal befindet sich wie im Postfach des Journalempfängers als Anhang eines sogenannten Umschlags. Der Umschlag enthält die Adressaten der Nachricht. Damit ist die native Ablageform von Journalempfänger am ehesten dazu geeignet, einer Nachweispflicht für E-Mail-Korrespondenz nachzukommen, als eine benutzerorientierte Ablage direkt zu nutzen. Sollten diese Nachrichten später dennoch ELO Benutzern zur Verfügung stehen, besteht die Möglichkeit, das Nachrichtenoriginal durch nachgelagerte Prozesse zu extrahieren und über die Adressatenliste den automatisch übernommenen ELO Benutzern mit geeigneten Berechtigungseinstellungen zur Verfügung zu stellen.
Postfachkataloge bei automatischer Übernahme
Die verschiedenen Katalogtypen von ELOxc ermitteln alle die zentralen Benutzereigenschaften Name, Windows-Benutzer und E-Mail. ELOxc übernimmt auch die GUID (Attribut objectGUID) des externen Postfachbesitzers als ELO Benutzer-GUID. Bei manueller Benutzererzeugung existiert keine externe GUID, und der LDAP-Import der ELO Administration Console muss manuell angepasst werden, damit diese GUID verwendet werden kann. Die Orientierung an der externen GUID ist für spätere Datenübernahmen unerlässlich, weshalb sie mit der LDAP-Anbindung des ELO Indexservers auch als Standardvorgabe definiert wurde.
Neben der zentralen Benutzereigenschaften speichert ELOxc in der Tabelle ldapuserprops des ELO Access Managers zusätzliche Katalogdaten, die über die Indexserver-API abgerufen werden können.
Die Attributabbildung gemäß der Zugriffskonstanten in der Indexserver-API sehen Sie in der folgenden Übersicht.
| Externer Name | ldap | ps | UserInfoC |
| displayName | X | X | LDAP_KEY_DISPLAY_NAME |
| distinguishedName | X | X | LDAP_KEY_DISTINGUISHED_NAME |
| legacyExchangeDN | X | X | LDAP_KEY_LEGACY_EXCHANGE_DN |
| X | LDAP_KEY_MAIL | ||
| PrimarySmtpAddress | X | LDAP_KEY_MAIL | |
| Manager | X | LDAP_KEY_MANAGER | |
| msExchRecipientTypeDetails | X | LDAP_KEY_EXCH_RECIPIENT_TYPE_DETAILS | |
| RecipientTypeDetails | X | LDAP_KEY_EXCH_RECIPIENT_TYPE_DETAILS | |
| person | person | LDAP_KEY_OBJECT_CLASS | |
| objectGUID | X | LDAP_KEY_OBJECT_GUID | |
| Guid | X | LDAP_KEY_OBJECT_GUID | |
| false | LDAP_KEY_ONLINE | ||
| true | LDAP_KEY_ONLINE | ||
| sAMAccountName | X | LDAP_KEY_SAM_ACCOUNT_NAME | |
| samAccountName | X | LDAP_KEY_SAM_ACCOUNT_NAME | |
| userPrincipalName | X | X | LDAP_KEY_USER_PRINCIPAL_NAME |
Die Übernahme externer Attribute als zentrale Benutzereigenschaften (Name, Windows-Benutzer und E-Mail ) kann über den Parameter Identitätsformat konfiguriert werden, obwohl die Belegung Name=UserPrincipalName, Windows-Benutzer=Domäne\Konto und E-Mail=SMTP-Adresse der bevorzugte Standard bleiben sollte.
Die Möglichkeit, die Belegung Name=Konto und Windows-Benutzer=UserPrincipalName zu nutzen, kann für ältere Repositorys hilfreich sein. Da die Benutzerdaten nur bei Fehlen erzeugt und danach nicht mehr aktualisiert werden, muss sorgfältig abgewogen werden, ob Datenbanken des ELO Access Manager auf den bevorzugten Standard verzichten.
LDAP-Anbindung des ELO Indexservers
Die LDAP-Anbindung des ELO Indexservers übernimmt bei Standardeinstellungen diese folgenden Attribute:
| LDAP | UserInfoC |
| Cn | LDAP_KEY_CN |
| displayName | LDAP_KEY_DISPLAY_NAME |
| distinguishedName | LDAP_KEY_DISTINGUISHED_NAME |
| LDAP_KEY_DOMAIN | |
| groupType | LDAP_KEY_GROUP_TYPE |
| mailNickname | LDAP_KEY_MAIL_NICK_NAME |
| manager | LDAP_KEY_MANAGER |
| msExchMailboxGuid | LDAP_KEY_MS_EXCHANGE_MAILBOX_GUID |
| name | LDAP_KEY_NAME |
| objectCategory | LDAP_KEY_OBJECT_CATEGORY |
| objectGUID | LDAP_KEY_OBJECT_GUID |
| objectSid | LDAP_KEY_OBJECT_SID |
| proxyAddresses | LDAP_KEY_PROXY_ADDRESSES |
| sAMAccountName | LDAP_KEY_SAM_ACCOUNT_NAME |
| sAMAccountType | LDAP_KEY_SAM_ACCOUNT_TYPE |
| userAccountControl | LDAP_KEY_USER_ACCOUNT_CONTROL |
| userPrincipalName | LDAP_KEY_USER_PRINCIPAL_NAME |
Information: In der Dokumentation der LDAP-Anbindung finden Sie Hinweise, wie die Attributzuordnungen individuell angepasst werden können. Es ist dennoch sinnvoll, mit der LDAP-Anbindung und der Benutzerübernahme von ELOxc das gleiche Ergebnis für die zentralen ELO Benutzereigenschaften Name, Windows-Benutzer und E-Mail zu erzielen.
Zusammenfassung
ELOxc kann im Repository grundsätzlich nur die Berechtigungen neu erzeugter Elemente einstellen. Die Einstellungen von Daten, die sich bereits im Repository befinden, können nach der Erstarchivierung nicht mehr verändert werden. Die Zugriffsberechtigungen auf Repository-Elementen müssen deshalb grundsätzlich mit dem Client vorgenommen werden. Automatisch übertragene Benutzer bleiben auch dann erhalten, wenn sie danach im Verzeichnis gelöscht werden. Das trifft auch auf das LDAP-Attribut manager zu.
Im Standardfall müssen die Strukturen für die E-Mail-Ablage im Repository inklusive der Berechtigungseinstellungen vorbereitet werden. Die Standardmasken Ordner und E-Mail sind dabei nützliche Hilfsmittel der Konfiguration und stehen als Standardmetadatenvorlagen von ELOxc immer zur Verfügung.
Die automatische Übernahme von Benutzerkonten ist eine Konfigurationsmöglichkeit, um die manuelle Vorbereitung der Ablagestrukturen zu vermeiden. Dabei werden die Postfachbesitzer als ELO Benutzer importiert und mit Zugriffsrechten ausgestattet, die dem Postfachtyp in Abhängigkeit des konfigurierten Verarbeitungstyps entsprechen. Für alle Katalogtypen können die zentralen Benutzerattribute GUID, Name, SMTP-Adresse und Konto bzw. UserPrincipalName übernommen werden. Darüber hinaus werden zusätzliche Verzeichnisdaten im ELO Access Manager gespeichert.
Bei allen möglichen Abbildungen der externen Daten auf Benutzerattribute in ELO ist aber stets darauf zu achten, dass Konflikte vermieden werden, da beispielsweise schon allein die manuelle Benutzererzeugung parallel zur Übernahme durch ELOxc eine Mehrdeutigkeit verursachen kann, die Sie erst spät entdecken und einige Zeit später kaum noch unkompliziert entfernen können.
Es ist deshalb sehr wichtig, dass Sie bei der Inbetriebnahme oder dem Neuaufbau eines Repositorys folgende Fragen beantworten:
- Wie werden Benutzer langfristig verwaltet? Wo (überall) werden sie verwaltet?
- Soll es (auch) reine ELO Benutzer geben, oder werden alle Benutzerdaten von einer externen Quelle übernommen?
- Wurde sichergestellt, dass ELO Administrator und ELO Service (und gegebenenfalls andere Dienstkonten) nicht aus externen Quellen erzeugt werden? Wenn diese zentralen Benutzerkonten extern verwaltet werden sollen, ist dann sichergestellt, dass ihre Passwörter unverändert bleiben, um aktive ELO Komponenten nicht außer Betrieb zu setzen?
- Welche Komponente – LDAP-Anbindung, LDAP-Import oder ELOxc – befriedigt die Bedürfnisse der administrativen Praxis bei automatischer Benutzerübernahme?
Die relevanten Eckpunkte der Berechtigungskonfiguration bei E-Mail-Ablage aus diesem Praxisbeispiel sind:
- ELO Administration Console: Erzeugung und Prüfung von Benutzern und Benutzergruppen
- LDAP-Anbindung: Allgemeine und granular konfigurierbare Übernahme von Benutzerkonten
- Masken und Felder: Standardmasken Ordner und E-Mail
- Metadatenvorlagen: KW_DEFAULT_FOLDER und KW_DEFAULT_DOCUMENT
- Postfachtypen: user, shared, journal
- Übernahme von Benutzerkonten: Aktivierung, Identitätsformat, Besitzübernahme
- Ablagepfade: Pfadwurzel archive oder user, postfachassoziierte Variablen
Der Postfachtyp user ist immer eine native Verarbeitung. Die Postfachtypen journal und shared können auch nativ verarbeitet werden, was wir jedoch nicht empfehlen, da dadurch die Benutzerorientierung verloren geht. Der empfohlene Standard für diese beiden Postfachtypen ist die Postfachemulation.
Die Konsequenzen bei automatischer Benutzerübernahme entnehmen Sie der folgenden Tabelle:
| Postfach | Konfiguration | Pfadwurzel | Berechtigungseinstellungen |
| Benutzer | user | archive | benutzerorientiert |
| user | benutzerorientiert | ||
| Freigabe | shared | archive | benutzerorientiert (zuzüglich eigene Gruppe) |
| user | benutzerorientiert (zuzüglich eigene Gruppe) | ||
| user | archive | gruppenorientiert über eigene Gruppe | |
| user | gruppenorientiert über eigene Gruppe | ||
| Journal | journal | archive | benutzerorientiert |
| user | benutzerorientiert | ||
| user | archive | Zuweisung zu Journalempfänger | |
| user | Zuweisung zu Journalempfänger |