Mit Open Management Architecture Benutzer in hybriden Umgebungen verwalten
Einer für alle
von Andreas Roscher
Veröffentlicht in Ausgabe 03/2021 - PRAXIS
In einem offenen IT-Umfeld mit Windows, macOS und Linux ist eine zentrale Administration von Benutzern und deren Rechten auf Servern, Desktops und Notebooks ein kaum lösbares Problem. Der Wechsel der Geräte zwischen Home Office und Firmennetz verschärft die Problematik. Einen Ausweg bietet ein zentrales User-Management, das Kennungen nach Bedarf lokal oder aus der Ferne in Verzeichnisdiensten verwaltet. Wir zeigen anhand der Open Management Architecture sowie des OpenDirectory, wie das möglich ist.
Um den Einsatz von Linux, Windows und macOS im bunten Anforderungsmix eines IT-Umfeldes zu bewältigen, bedarf es einer plattformunabhängigen Verwaltung der Benutzerkennungen. Die Cloud ist meist nur teilweise eine Lösung in Verbindung mit bestimmten Onlinediensten. In diesem Workshop setzen wir deshalb auf ein zentrales Management von lokalen Kennungen. Das Managementsystem ist in der Lage, die nötigen Benutzerkennungen auf die Mac-, Windows- und Linux-Systeme zu verteilen. So können sich nur die Benutzer anmelden, die auch lokal eingerichtet sind.
Das Active Directory schaffen wir in unserem Beispiel komplett ab, da es nur Teilbereiche abdeckt. Der stattdessen verwendete OpenDirectory-Service auf Apple-File-Servern wird derweil komplett durch das Managementsystem verwaltet. Das gilt auch für die Profile der Benutzer. Neben Windows-Profilen lassen sich dabei auch Linux- und macOS-Profile administrieren.
Open Management Architecture
Windows, macOS und Linux sind Multi-User-Systeme und bieten entsprechende Werkzeuge zum Verwalten mehrerer Benutzerkennungen. Aber welcher Administrator will für jedes Gerät durch die Lande ziehen und Kennungen lokal verwalten? Die Verwendung zentraler Verzeichnisdienste wie Active Directory oder OpenDirectory ist eine mögliche Lösung. Doch sind diese Werkzeuge immer an bestimmte Server-Betriebssysteme gekoppelt und das Anbinden von Clients aus anderen Systemwelten mit mehr oder weniger Einschränkungen verbunden.
Um den Einsatz von Linux, Windows und macOS im bunten Anforderungsmix eines IT-Umfeldes zu bewältigen, bedarf es einer plattformunabhängigen Verwaltung der Benutzerkennungen. Die Cloud ist meist nur teilweise eine Lösung in Verbindung mit bestimmten Onlinediensten. In diesem Workshop setzen wir deshalb auf ein zentrales Management von lokalen Kennungen. Das Managementsystem ist in der Lage, die nötigen Benutzerkennungen auf die Mac-, Windows- und Linux-Systeme zu verteilen. So können sich nur die Benutzer anmelden, die auch lokal eingerichtet sind.
Das Active Directory schaffen wir in unserem Beispiel komplett ab, da es nur Teilbereiche abdeckt. Der stattdessen verwendete OpenDirectory-Service auf Apple-File-Servern wird derweil komplett durch das Managementsystem verwaltet. Das gilt auch für die Profile der Benutzer. Neben Windows-Profilen lassen sich dabei auch Linux- und macOS-Profile administrieren.
Open Management Architecture
Windows, macOS und Linux sind Multi-User-Systeme und bieten entsprechende Werkzeuge zum Verwalten mehrerer Benutzerkennungen. Aber welcher Administrator will für jedes Gerät durch die Lande ziehen und Kennungen lokal verwalten? Die Verwendung zentraler Verzeichnisdienste wie Active Directory oder OpenDirectory ist eine mögliche Lösung. Doch sind diese Werkzeuge immer an bestimmte Server-Betriebssysteme gekoppelt und das Anbinden von Clients aus anderen Systemwelten mit mehr oder weniger Einschränkungen verbunden.
Einen Ausweg bietet das Verwenden eines Managementsystems, das aus der Ferne dafür sorgt, dass Kennungen nur dort existieren, wo sie auch gebraucht werden. Damit lassen sich Zielstellungen verwirklichen, bei denen der Fokus wahlweise auf Kennungen in zentralen Verzeichnisdiensten und/oder auf lokalen Benutzern liegen kann.
Das Produkt "Open Management Architecture" verwendet das verschlüsselte SSH-Protokoll, um die Benutzerdaten zu übertragen und User-Daten aus der Ferne zu verwalten. Alle Aktivitäten im Umgang mit diesen Informationen erfolgen mit den Werkzeugen der Zielsysteme (Windows, macOS, Linux, AD, OpenDirectory et cetera). Die in diesem Beitrag aufgezeigte Vorgehensweise funktioniert auch unter Solaris, FreeBSD und anderen nicht zu häufig vorkommenden Multi-User-Betriebssystemen.
Benutzerdaten richtig anlegen
Schon bei der Wahl eines Benutzernamens driften die Möglichkeiten auseinander. Der Name "Andreas Roscher" kann wegen des Leerzeichens beispielsweise nicht verwendet werden, wenn überall der gleiche Login-Name zum Einsatz kommen soll. Der Name "andreasroscher" passt dagegen überall. Wer unpersönliche Kennungen bevorzugt, kann beispielsweise Personalnummern oder andere eindeutige Zuordnungen favorisieren. Wem auch immer Sie einen Benutzernamen zur Verwendung übergeben, der Anwender sollte für den sicheren Umgang mit seinen Zugangsdaten verantwortlich sein.
Jede interaktive Kennung in einem Unternehmen sollte auch immer eine persönliche Kennung sein. In allen Systemwelten sind die Kennungen an Benutzergruppen gebunden. Gehören Nutzer einer bestimmten Gruppe wie etwa Remote-Desktop-Nutzer an, dürfen sie bestimmte Ressourcen verwenden. Mehr oder minder offensichtlich sind die Benutzer- und Gruppennamen in Unternehmen noch mit einer Benutzernummer und einer Gruppennummer verbunden. Im Extremfall kommen so furchterregend lange Zeichenketten heraus, die bis hinein in die Zugriffsrechte auf Verzeichnisse, Dateien und andere Ressourcen Verwendung finden. Sind erst einmal Daten angelegt, die mit Kennungen verknüpft sind, stehen Sie vor dem Problem, eine Kennung immer wieder mit denselben Eigenschaften anlegen zu müssen, um die gleichen Zugriffsrechte zu gewährleisten.
Ein weiterer Aspekt beim Anlegen von Benutzerkennungen: Wenn Sie Plattenplatz zwischen den Systemwelten verschieben, ist es von unschätzbarem Vorteil, wenn die Platte am neuen Server auf die gleichen Kennungen mit identischen Eigenschaften trifft. Die Eigenschaftsliste eines Users kann dabei recht umfangreich ausfallen. In der Verwaltung eines zentralen Managementsystems müssen sich alle Informationen unterbringen lassen, die zum korrekten Anlegen der Kennungen auf den diversen Systemen erforderlich sind. Bild 1 zeigt einen Bruchteil der umfangreichen Daten, die zum Anlegen einer Kennung unter Linux, Windows, macOS und dem LDAP erforderlich sind. Sollten Sie nicht alle genannten Systeme einsetzen, können Sie bestimmte Daten weglassen.
Bild 1: Die Daten zum Anlegen einer User-Kennung sind vielfältig.
Während das Home-Verzeichnis in Windows fest verankert ist und auf dem Mac keiner von "/Users" abweicht, besteht unter Linux die freie Auswahl. Um uns das Leben leicht zu machen, nehmen wir auch für Linux das "/Users"-Verzeichnis. Die vielen Fragen nach den LDAP-Eigenschaften eines Benutzers ergeben sich aus dem Einsatz der LDAP-Software "OpenDirectory" auf einem macOS-Server.
Identische Benutzer im LDAP
Üblicherweise ist die Bereitstellung eines Dateiservers der Grund dafür, eine Benutzerverwaltung aufzubauen, mit der sich die Zugriffe auf die Daten des Servers regeln lassen. Die Gruppen und Benutzer eines OpenDirectory-Servers, der auch als Dateiserver fungiert, lassen sich exportieren. Die gewonnenen Informationen können so leicht in das Managementsystem importiert und bei Bedarf korrigiert werden. Beim Aufsetzen eines zweiten OpenDirectory-Servers legen Sie identische Kennungen an.
Der Umzug von Festplatten etwa von einem bestehenden Server auf den neuen Server läuft dann ohne Probleme ab, weil die auf dem alten Server verwendete "GeneratedUID" einer Kennung erneut zum Einsatz kommt. Auch die gennutzten GeneratedUIDs der Gruppen sind identisch. So lassen sich zwei autarke OpenDirectory-Server betreiben, an denen jeder externe Storage gleichermaßen funktioniert. Das Managementsystem erzeugt dabei aus den Daten der zugewiesenen Kennungen und Gruppen die für einen OpenDirectory-Server nötige Importdatei für die LDAP-Gruppen mit folgenden Informationen:
Die Informationen beginnend mit "0x0A" bis "GeneratedUID" stehen in einer Zeile und sind hier nur der Übersichtlichkeit halber auf mehrere Zeilen verteilt. Der Gruppendatensatz "geometries" mit der GID 1039, dem Namen "geometries" und der generierten UID "9C41D884-0E7C-482C-B40A-21B0879F1329" ist der erste Datensatz in der Importdatei. Die anderen Gruppen folgen Zeile für Zeile. Für die LDAP-Kennungen ist eine zweite Datei anzulegen und zu importieren:
Der Kennungsdatensatz "user1" mit dem Passwort "password", der UID 10543, der primären Gruppe 20, dem Login-Programm "/usr/bin/false", dem Home-Verzeichnis "/dev/null", dem Vornamen "Usr", dem Nachnamen "1", dem vollen Namen "Usr1" und der generierten UID "EABBA8E6-E90C-4472-83EE-F746745B6E36" ist der erste Datensatz in der Importdatei. Die anderen Kennungen folgen auch hier Zeile für Zeile.
Datensätze importieren
Eine Importdatei ist noch kein Import und so fehlt noch das Kommando, mit dem der Managementserver nach dem Übertragen der Dateien den Import ausführt. Auch die Kommandos zur Aufnahme der Kennungen in bestimmte Gruppen generiert der Managementserver. Wenn Sie das manuell ausführen möchten, geht das wie folgt – der Benutzer "dir-admin" ist der Administratorname für das OpenDirectory auf dem Mac-Server.
dsimport usersfile
/LDAPv3/127.0.0.1 M
--username diradmin
--password passwort
--loglevel 7
dsimport groupsfile
/LDAPv3/127.0.0.1 M
--username diradmin
--password passwort
--loglevel 7
Die erstellten Logfiles finden Sie im Verzeichnis "/var/root/Library/Logs/ImportExport". Diese Dateien muss der Managementserver abholen und auswerten, um fehlerhafte Benutzerkonfigurationen aufzudecken. Die Mitgliedschaft der Anwender in den Gruppen regelt:
dseditgroup -o edit -n /LDAPv3/127.0.0.1
-u diradmin -P passwort -t user
-a user1 com.apple.access_smb
dseditgroup -o edit -n /LDAPv3/127.0.0.1
-u diradmin -P passwort -t user
-a user1 geometries
Durch den Einsatz der passenden Kommandos entfällt die Notwendigkeit, die Benutzerverwaltung auf beiden LDAP-Servern bemühen zu müssen. Lassen Sie immer alle Kommandos automatisch auf beiden LDAP-Servern ausführen, erhalten Sie eine hinreichende Redundanz. Die Skripte, in denen das Passwort des OpenDirectory-Administrators zu sehen ist, werden durch das Managementsystem verschlüsselt übertragen, ausgeführt und sofort wieder gelöscht. So verbleiben auf Mac-Servern keine Dateien, in denen Passwörter im Klartext stehen. Ein Kommando, mit dem sich einzelne Kennungen oder Gruppen auf einem OpenDirectory-Server anlegen lassen, gibt es für LDAP-Kennungen nicht. Die Importdateien überschreiben die übrigen vorhandenen Einstellungen, sofern eine Gruppe oder eine Kennung schon existiert.
Benutzer unter Linux
Auch Linux kann als Dateiserver verwendet werden, auf den die Anwender per SMB-Protokoll zugreifen. Lokale Kennungen eines Linux-Servers müssen Sie als Benutzer für den Fileserver freischalten. Auch hier greift der Managementserver per SSH auf den Linux-Server zu und verwendet die verfügbaren Kommandos, um Kennungen und Gruppen anzulegen. Diese Kennungen sind identisch zu denen auf dem OpenDirectory-Dateiserver. Es kommen die gleichen Namen, Passwörter, UIDs, GIDs et cetera zum Einsatz. Ziel soll es sein, dass sich ein Anwender auf einem Mac- oder Windows-Client mit völlig identischen Zugangsdaten wahlweise Plattenplatz vom Mac-Server und vom Linux-Server einhängen kann. Das Anlegen der Gruppen und Kennungen führen Sie mit den folgenden Kommandos durch:
Die Erlaubnis für den Zugriff auf die SMB-Freigaben des Linux-Servers regelt die Datei "/etc/samba/smb.conf". Hier ein Auszug mit der Freigabe "VIDEO" :
[VIDEO]
path = /home4/VIDEO
public = no
writable = yes
comment = smb share
printable = no
guest ok = no
valid users andreasroscher user1
create mask = 0775
directory mask = 0775
Die Freigabe einer Kennung für den Plattenzugriff regelt:
/usr/bin/smbpasswd -a user1
Access Control Lists (ACL) zur Erweiterung der Zugriffsrechte ssind auf einem Mac-Server Pflicht, auf einem Linux-Server optional. Kleinster gemeinsamer Nenner zwischen den beiden Systemen sind die UID und die GID, die das Managementsystem identisch hält. In jedem Fall erreichen Sie, dass die Anwender mit identischen Zugangsdaten auf die verschiedenen Dateiserver zugreifen können. Beim Einsatz lokaler Kennungen auf Windows-, Mac- und Linux-Clients erfolgt auch die lokale Anmeldung mit den gleichen Zugangsdaten.
Benutzer unter macOS
Nach einem lokalen Login auf einem Mac lassen sich die Freigaben der SMB-Server einhängen. Auch hier sollen die Daten für das lokale Login identisch sein zu den Daten für die Netzwerkzugriffe. Der Managementserver greift per SSH auf die Mac-Systeme zu und legt die gewünschten Gruppen und Kennungen an, sofern diese nicht schon existieren:
Den Zugriff auf die File-Server starten Sie mit der Tastenkombination "Command + K". Bild 2 zeigt die Eingabemaske für die Auswahl der Serversysteme.
Bild 2: Die Eingabemaske für die Auswahl der Serversysteme unter macOS.
Für Zugriffe auf die Dateiserver müssen einmalig die Zugangsdaten (Login und Passwort) eingegeben werden (Bild 3). Der Mac-Rechner speichert die Zugangsdaten, sofern der Anwender das entsprechende Häkchen setzt. Wird wieder auf die Fileserver zugegriffen, erfolgt keine erneute Abfrage von Login und Passwort. Das gilt sowohl für den Zugriff auf Linux- als auch Mac-Dateiserver.
Bild 3: Die Zugangsdaten für den Zugriff auf Dateiserver müssen einmalig eingegeben werden.
Benutzer unter Windows
Nach einem lokalen Login auf einem Windows-Rechner lassen sich auch hier die Freigaben der SMB-Server einhängen. Dabei sollen die Daten für das lokale Login ebenfalls identisch zu den Daten für die Netzwerkzugriffe sein. Der Managementserver greift per SSH auf die Windows-Systeme zu und legt die gewünschten Gruppen und User an:
net user "user1" password /add /expires:never /passwordreq:yes /passwordchg:yes
net localgroup "Remotedesktopbenutzer" "user1" /add
net localgroup "Remote Desktop Users" "user1" /add
So richtig in Gang kommt die Kennung erst nach dem ersten Anmelden. Dann wird ein Profil eingerichtet und Sie haben die Möglichkeit, Skripte laufen zu lassen. Für die Zugriffe auf die Dateiserver kommen die Login- und Passwortdaten zum Einsatz, die beim Anmelden an Windows benutzt wurden. Da durch den Einsatz des Managementservers die Logindaten identisch sind, lassen sich die Zugriffe aller Anwender über ein Login-Skript aktivieren, ohne in diesen Skripten Passwörter eintragen zu müssen. Es erfolgt ein Verbindungsversuch zu jeder Freigabe – wo die Berechtigung stimmt, kommt die Freigabe unter dem gewünschten Laufwerksbuchstaben zum Vorschein. Damit ein einziges Skript für alle möglichen Shares funktioniert, erstellen wir pro Freigabe eine eigene Batch-Datei, zum Beispiel "Connect2Videoserver2.bat", mit folgendem Inhalt:
@echo off
title NETUSE
net use V: \\videoserver2\VIDEO /PERSISTENT:NO
Eine Steuerdatei ruft die einzelnen Batch-Dateien nacheinander auf und bricht final alle misslungenen Versuche ab. So lässt sich ein einziges Skript für alle Anwender verwenden:
@echo off
if %username% == Administrator goto end
net use * /delete /yes
start /min Connect2Videoserver2.bat
start /min Connect2Officeserver2.bat
ping -n 5 localhost
taskkill /F /FI "IMAGENAME eq net.exe"
taskkill /F /FI "WINDOWTITLE eq NETUSE"
:end
Exit
Das ping-Kommando verschafft den zuletzt aufgerufenen Skripten die notwendige Atempause, um ihre Arbeit abzuschließen, bevor final alle noch laufenden erfolglosen Versuche abgebrochen werden. Sofern Sie jeden Dateiserver zweimal vorliegen haben, können Sie den Anwendern auch zwei Skripte bereitstellen. Das eine Skript stellt Verbindungen zum aktuell aktiven Fileserver her, das andere Skript zum passiv mitlaufenden File-Server. Jede Nacht kann dann ein Abgleich der Daten zwischen aktivem und passivem Dateiserver stattfinden.
Bleibt final nur die Aufgabe, das Steuerskript in den Autostart-Ordner für alle Benutzer zu platzieren. Mit einem optionalen Link auf dem Desktop für alle User geben Sie den Anwendern die Möglichkeit, abgebrochene Verbindungen zum File-Server erneut aufzubauen. Ist der Windows-Client ein mobiles Gerät, das im Home Office agiert, können sich die Anwender zuerst per VPN mit der Firma verbinden und dann den Link auf dem Desktop starten. Durch die Verwendung lokaler Kennungen funktioniert das Anmelden auf dem Arbeitsgerät jederzeit. Findet sich zu Hause oder unterwegs eine Internetverbindung, kommt der Anwender per VPN und verlinktem Skript an seine Freigaben und sonstigen Ressourcen, wie etwa Lizenzserver.
Passwörter verwalten
Aus den Regeln, die Sie für das Zuweisen von Passwörtern verwenden, ergibt sich das einzusetzende Verfahren. Sie können beispielsweise Anwender mit einem Initialpasswort versehen, das der Nutzer ändern muss. Gibt es Probleme mit dem Passwort, können Sie aus der Ferne erneut ein Initialpasswort vergeben. Für Windows kommt per SSH aus der Ferne das Programm "net.exe" zum Einsatz.
net.exe user user1 passwort
Für Linux besteht die Möglichkeit, die verschlüsselte Fassung des Initialpasswortes auf dem Managementserver zu hinterlegen. Im Fernzugriff wird für den Anwender der Eintrag in der Datei "/etc/ shadow" ausgetauscht. Alternativ lässt sich das Passwort als abgelaufen deklarieren. Dann muss sich der Anwender beim nächsten Anmelden ein neues Passwort geben: passwd -e user1. Auch ein Setzen des Passwortes im Klartext ist unter Linux möglich:
echo -e "passwort\npasswort" | passwd user1
Unter macOS wird das Passwort ebenfalls im Klartext übergeben:
/usr/bin/dscl . -passwd /Users/user1 passwort
Zusätzlich können Sie die in Keychain hinterlegten Passwörter entfernen:
rm -r /Users/user1/Library/Keychains/*
Profile und Policies setzen
Wechselt der Anwender von einem Gerät auf ein anderes, gilt es, die lokalen Kennungen dort zu entfernen, wo sie nicht länger benötigt werden. Auch das regelt der Managementserver mit den entsprechenden Kommandos. Folgende Befehle löschen die Daten des Anwenders – verwenden Sie andere Varianten der Befehle, wenn Sie Daten nicht löschen oder nur verschieben wollen:
Unter Windows:
net.exe user user1 /delete
rm -r /cygdrive/c/Users/user1
Unter Linux:
userdel -r user1
Unter macOS:
dscl . delete /Users/user1
rm -r /Users/user1
Falls Sie für Clients kompromisslos geregelt haben, dass lokale Daten unzulässig sind, können Sie auch den kompletten Arbeitsplatzrechner neu aufsetzen. Das Verwalten von Benutzerprofilen erlaubt es Ihnen, dem Anwender sein aufgebautes Profil zurückzugeben, ohne einen Verzeichnisdienst zu bemühen. Mithilfe des Managementservers lassen sich regelmäßige Sicherungen erstellen und in verschiedenen Abstufungen aufheben. Das Profil eines Linux-Anwenders besteht aus bestimmten Dateien in seinem Home-Verzeichnis. Das gilt auch im weitesten Sinn für Mac-Systeme. Für Windows gibt es das "User State Migration Tool", um Profile per Kommando zu sichern und wiederherzustellen [1].
Das Setzen einheitlicher Policies lässt sich bei Verzicht auf einen Verzeichnisdienst durch Softwarepakete regeln. Im einfachsten Fall besteht das Softwarepaket aus nur einem Kommando. Als Beispiel nehmen wir den Wunsch, GateKeeper auf Mac-Systemen auszuschalten:
spctl -master-disable
Die auf dem Managementserver aufgebaute Benutzerverwaltung regelt, dass die Anwender niemals Mitglied der Gruppe "Administratoren" sind. Anwender dürfen somit keine Software installieren. Aber selbst ein administrativer Account wird bei eingeschaltetem GateKeeper mit Bestätigungsfenstern belästigt. Mit dem Ausschalten des GateKeeper darf Software ohne Einschränkung der Installationsquelle und lästige Rückfragen aufgespielt werden. Die Installation erfolgt ausschließlich online durch den Managementserver auf die laufenden Mac-Systeme. Neustarts sind im Normalfall beim Installieren von Software auf dem Mac nicht erforderlich. Alle Installationsskripte in den Softwarepaketen laufen ohne Unterbrechung durch.
Benutzer ausblenden
Lokalen Benutzern können Sie das Leben beim Anmelden erleichtern. Dürfen sich mehrere Anwender lokal einloggen, sehen die User eine bildbehaftete Liste der Konten. Das gilt für Windows, Linux und Mac gleichermaßen. Sie können aber auch ein Geheimnis aus den eingerichteten Benutzern machen. Dann gibt es nur ein Fenster, in dem der Login-Name und das Passwort einzugeben sind. Sie müssen letztendlich entscheiden, wie der Anmeldeschirm aussehen soll.
Unter Windows gibt es noch eine Zwischenlösung. Obwohl es auf den Systemen eine aktivierte Kennung "Administrator" gibt und die SSH-Software "Cygwin" die Kennung "cyg_server" angelegt hat, sollen diese beiden Kennungen nicht in der Kennungsliste auf dem Anmeldebildschirm zu sehen sein. Mithilfe eines Softwarepakets, das nur aus einem Skript besteht, lassen sich die notwendigen Einträge in der Registry realisieren. Der Anmeldeschirm bietet dann weder einen Login als "Administrator" noch als "cyg_server" an. Das Skript ruft hierfür das Kommando "reg.exe" auf:
set K1=HKLM
set K2=Software
set K3=Microsoft
set K4=Windows NT
set K5=CurrentVersion
set K6=Winlogon
set K7=SpecialAccounts
set K8=UserList
set KALL=%K1%\%K2%\%K3%\%K4%\%K5%\%K6%\%K7%
set KOPT=/t reg_dword /d 0 /f
set CMD1=reg add "%KALL%" /f
set CMD2=reg add "%KALL%\%K8%" /v "Administrator" %KOPT%
set CMD3=reg add "%KALL%\%K8%" /v "cyg_server" %KOPT%
%CMD1%
%CMD2%
%CMD3%
Der Aufruf "%CMD1%" legt den benötigten Registry-Zweig an. Die Aufrufe "%CMD2%" und "%CMD3%" erstellen die Einträge für die Kennung "Administrator" und "cyg_server".
Fazit
Um eine Umgebung mit unterschiedlichen Betriebssystemen sowohl auf Client- als auch Serverseite zu verwalten, bietet sich ein zentrales Management über die Open Management Architecture an. Es bleibt aber trotz aller Systemunterschiede in der Verwaltung von Kennungen bei der Frage "Welche Kennung soll auf welches System?". Die Gleichheit aller Eigenschaften einer Kennung auf allen Systemen gibt den Anwendern die Möglichkeit, sich überall dort anzumelden, wo sie dies auch dürfen. Ob das ein lokales System oder ein Verzeichnisdienst ist, kann sich nach den Anforderungen des Unternehmens richten.