Kerberos-Login

Active Directory Authentifizierung via Kerberos

Kerberos ist ein verteilter Authentifizierungsdienst für offene und unsichere Computernetze. In einer Active Directory Umgebung stellt der Domaincontroller ein Key Distribution Center (KDC) für die Schlüsselverwaltung bereit. Das KDC greift dabei auf das Active Directory der Domäne zu, um die Benutzerinformationen zu laden.

In CURSOR-CRM wird für die Kerberos-Authentifizierung die Angabe der KDC-Server und der zugehörigen Domänen-Namen benötigt.

Für die Nutzung der Kerberos-Authentifizierung muss das Modul "Single Sign-on" lizensiert aktiviert sein.

Nutzung des Active Directory Benutzerpassworts zur Anmeldung an CURSOR-CRM

Beim Standard-Login von CURSOR-CRM werden bei der Anmeldung Benutzername und Passwort mit den Mitarbeiter-Daten in der CURSOR-CRM Datenbank verglichen. Aktiviert man die Active Directory Authentifizierung, so entfällt die Passwortprüfung gegen die Mitarbeiterdaten. Der Benutzer muss nun bei der Anmeldung den Benutzernamen und das Passwort seines Active Directory Benutzers eingeben. Damit der korrekte Mitarbeiter bei der Anmeldung ermittelt werden kann, müssen der Benutzername in der Domäne und das Kürzel des Mitarbeiters im CRM übereinstimmen. Alternativ kann der Administrator den Login-Namen im Mitarbeiter setzen, um eine explizite Zuordnung zwischen dem Domänen-Benutzer und dem Mitarbeiter in CURSOR-CRM herzustellen. Falls mehrere Domänen für die Anmeldung verwendet werden, sind die Informationen im Abschnitt Wahl des Administrationsbereichs zu beachten.

Das Mitarbeiter-Kürzel und der Login-Name aller Mitarbeiter müssen in CURSOR-CRM jeweils eindeutig sein, da es sonst nicht möglich, bei der Anmeldung einen Login-Namen auf genau einen Mitarbeiter abzubilden. Wenn diese Zuordnung nicht eindeutig ist, ist die Anmeldung für keinen der konfliktierenden Mitarbeiter möglich.

Bei der Anmeldung sendet der Client (Rich Client, Web Client, App) die Anmeldedaten über eine gesicherte, verschlüsselte Verbindung an den Applikationsserver. Um diese Verbindung abzusichern, ist ein gültiges SSL-Zertifikat (X.509-Zertifikat) im JBoss Applikationsserver einzurichten.
Der Applikationsserver fordert mit Hilfe der Anmeldedaten ein Ticket beim KDC an und prüft deren Gültigkeit. Die Anmeldedaten werden verschlüsselt für die Sitzung im Arbeitsspeicher gehalten und bei Bedarf (z.B. Kommunikation mit WebServices oder Groupware) weiterverwendet.

Bei besonderen, nicht auf HTTPS basierenden, externen Schnittstellen wie der JMX-Konsole wird das Passwort gegebenenfalls unverschlüsselt übertragen. Daher ist bei der Nutzung von unverschlüsselten Schnittstellen Vorsicht geboten.

Nutzung des Active Directory Benutzerpassworts zur Anmeldung an WebServices und Groupware

Werden vom Benutzer WebServices in CURSOR-CRM aufgerufen, so kann gegebenenfalls auf die für die aktuelle Sitzung verschlüsselt gespeicherten Anmeldeinformation des Benutzers zugegriffen werden. Hier muss im WebService die Konfiguration enableLoginViaCurrentUser(true); erfolgen. Wenn für die Anmeldung Single Sign-on verwendet wurde, ist in der Sitzung kein Passwort gespeichert und der Benutzer muss das Passwort einmalig eingeben. Danach wird dieses dann genau wie bei der Anmeldung mit Passwort verschlüsselt für die Sitzung im Arbeitsspeicher gehalten.

Für die serverseitige Groupware Anbindung (IMAP, SMTP, Domino, EWS) kann der Administrator die Active Directory Authentifizierung explizit in den Systemeinstellungen aktivieren. Bei der Anmeldung an das Groupwaresystem wird dann das eingegebene Domänenpasswort und der Benutzername des Domänenbenutzers verwendet. Bei der Verwendung von Single Sign-on gibt der Benutzer kein Passwort ein. Da die serverseitige Groupware-Integration ein Passwort benötigt, muss der Benutzer das Passwort einmalig eingeben. Das Passwort für die Dauer der Sitzung im Speicher gehalten. Das Passwort kann auch im Mitarbeiterdatensatz gespeichert werden. Dieses wird symmetrisch verschlüsselt in der Datenbank persistiert. Das Mitarbeiter-Feld 'Groupware Benutzername' ist dann schreibgeschützt und wird nicht mehr verwendet. Wird eine Mail-Konfiguration genutzt und einem Benutzer zugewiesen, so wird der dort eingestellte Benutzername bzw. das Passwort weiterhin genutzt.

Single Sign-on (Autologin) mit Kerberos

Über Kerberos ist die automatische Anmeldung von Mitarbeitern nach dem Single Sign-on-Prinzip möglich. Bei der Anmeldung an CURSOR-CRM wird dann auf die auf dem Windows-Rechner bestehende Kerberos-Sitzung zurückgegriffen. Der CURSOR-CRM Client lässt sich dann ein so genanntes Service-Ticket ausstellen und sendet dieses an den Applikationsserver. Dieser prüft die Gültigkeit des Tickets und kann damit den Benutzer sicher authentifizieren.
Dadurch entfällt die Eingabe von Benutzerpasswörtern bei der Anmeldung an CURSOR-CRM.

Die Single Sign-on-Technologie wird sowohl vom Rich Client als auch vom Web Client unterstützt. Technisch verwendet der Rich Client direkt das Kerberos-Protokoll, während der Web Client auf das SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) Protokoll zurückgreift, damit die Kerberos-Anmeldung auch mit dem Browser möglich wird.

Damit Single Sign-on eingesetzt werden kann, müssen zunächst die zugehörigen Einstellungen in der Domäne, im Applikationsserver und in der Rich Client Konfiguration korrekt konfiguriert werden. Bei der Verwendung von Single Sign-on für den Web Client müssen gegebenenfalls zusätzlich die verwendeten Browser konfiguriert werden. Die Konfiguration der genannten Bereiche wird in den zugehörigen Abschnitten genauer beschrieben.

Nach der Einrichtung kann für jeden Mitarbeiter die automatische Anmeldung einzeln eingeschaltet werden. Dazu muss im Mitarbeiterdatensatz das "Autom. Einloggen"-Kontrollkästchen aktiviert werden. Bei der Verwendung von Single Sign-on findet die Abbildung von Domänenbenutzern auf Mitarbeiter in CURSOR-CRM auf die gleiche Weise statt, wie bei der Anmeldung mit dem Active Directory Benutzerpasswort. Daher muss auch hier gegebenenfalls das Feld "Login Name" mit dem korrekten Wert gefüllt werden.

• Die Active Directory Authentifizierung wird auf der App nur ohne Single Sign-on unterstützt. Hier muss die Anmeldung also mit dem Active Directory Benutzernamen und Passwort erfolgen.

• Nutzt der Benutzer z.B. die serverseitige Groupware-Schnittstelle oder WebServices, so muss der Benutzer einmalig sein Domänenpasswort eingeben, da diese Schnittstellen keine Kerberos Ticket-Anmeldung unterstützen.

Anforderungen an die Installation

Der JBoss Applikationsserver muss bei aktiver Kerberos-Authentifizierung im Benutzerkontext eines gültigen Domänenbenutzers ausgeführt werden, damit ein Zugriff auf das KDC möglich ist. Alle Mitarbeiter im CURSOR-CRM müssen einem Domänenbenutzer zugewiesen werden. Dies gilt auch für den Standardbenutzer TECH_USER . Hierfür muss ein technischer Benutzer in der Domäne angelegt werden.

Zusatzanforderungen für Single Sign-on

Für Single Sign-on wird zusätzlich die Konfiguration eines sogenannten Service Principal Name (SPN) in der Domäne benötigt. Für maximale Kompatibilität sollte der SPN nach folgendem Schema aufgebaut sein: HTTP/<vollqualifizierter Hostname des Applikationsservers>.
Durch die Mitgliedschaft dieses SPNs in einer Domäne ergibt sich folgender vollqualifizierter Prinzipalname: HTTP/<vollqualifizierter Hostname des Applikationsservers>@<Domänen-Name>

Damit Single Sign-on im Web Client funktioniert, muss der SPN auf den exakten Hostnamen eingerichtet werden, der auch später in der Web Client URL verwendet wird.

Bei der Einrichtung des SPN in Verbindung mit Aliasnamen für den Applikationsserver ist besondere Vorsicht geboten. Hierbei ist darauf zu achten, dass der dem SPN zugehörige Aliasname im DNS als A-Record geführt wird.

Bei der Verwendung von CNAME-Records können je nach verwendetem Browser bzw. Betriebssystem unterschiedliche Probleme auftreten. Da das Verfahren für die SPN-Konstruktion in Verbindung mit CNAME-Records nicht standardisiert ist, kann das Verhalten sich sogar je nach Version des verwendeten Browsers und/oder Betriebssystems ändern. Aus diesem Grund sollten für diese Hostnamen niemals CNAME-Records, sondern immer A-Records verwendet werden.

Der SPN muss zunächst in der Domäne eingerichtet werden. Bei Verwendung von Microsoft Active Directory (AD) muss dies von einem Domänenadministrator durchgeführt werden. Dafür wird dem vom Applikationsserver verwendeten Dienstbenutzer der SPN zugewiesen. Innerhalb von AD wird die Schreibweise HTTP/<vollqualifizierter Hostname des Applikationsservers> verwendet. Der Domänen-Suffix (z.B. @CURSOR.DE) wird von AD automatisch abgeleitet und darf nicht mit eingetragen werden.

Um den SPN in Active Directory setzen zu können, muss in der AD-Administrationskonsole zunächst im Menü "Ansicht" die "Erweiterte Ansicht" (Englisch: "Advanced Features") aktiviert werden.
Dadurch wird in den Eigenschaften der AD-Benutzer der Reiter "Attribut-Editor" freigeschaltet. Hier kann dann der SPN gesetzt werden.

Durch die Verwendung des CURSOR-CRM Dienstbenutzers für die Kerberos-Anmeldung ist es besonders wichtig, dass das Passwort des Dienstbenutzers lang und sicher ist. Insbesondere sollte es nicht leicht erratbar sein, sondern möglichst lang und zufällig generiert sein.

Für diesen Einsatzzweck bietet Active Directory die Möglichkeit, sogenannte "Managed Service Accounts" bzw. "Group Managed Service Accounts" einzurichten. Diese verwenden intern automatisch verwaltete, extrem lange, sichere und sogar sich automatisch periodisch ändernde Passwörter. Wenn möglich sollte diese Form der Passwortverwaltung für maximale Sicherheit gewählt werden.

Beim Betrieb des CURSOR-CRM Servers auf Linux können ohne weitere Konfigurationsarbeit solche managed accounts leider nicht genutzt werden. Hier muss stattdessen manuell ein sehr langes und sicheres Passwort vergeben werden und auch periodisch geändert werden.

Falls nach der Konfiguration aller Komponenten Single Sign-on nicht funktioniert, kann zur Fehlersuche die SPN-Konfiguration von jedem Windows-Rechner in der Domäne aus überprüft werden. Dazu wird das mit Windows mitgelieferte Programm setspn verwendet.

Der Befehl setspn -L <Benutzername> listet alle SPNs auf die für den angegebenen Benutzer konfiguriert sind.

Der Befehl setspn -Q <SPN> zeigt den Benutzer an dem der angegebene SPN zugewiesen ist.

Um das Abrufen des Service-Tickets für die CRM-Anmeldung testweise manuell durchzuführen, kann das mit Windows mitgelieferte Programm klist verwendet werden.

Der Befehl klist get <SPN> verwendet die aktuelle Kerberos-Sitzung um ein Service-Ticket für den angegebenen SPN abzurufen. Im Fehlerfall wird eine Fehlermeldung ausgegeben. Im Erfolgsfall wird eine Liste aller gespeicherten Tickets der aktuellen Sitzung ausgegeben, inklusive des neu angeforderten Tickets. Diese Informationen können bei der Fehlersuche behilflich sein.

Konfiguration des Applikationsservers

Für den JBoss Applikationsserver muss in den Systemeinstellungen unter Passwort Einstellungen die Kerberos-Authentifizierung aktiviert werden. In Web Client, CURSOR-App und Serverschnittstellen (z.B. WebServices) wird die Serverkonfiguration verwendet. Die "Erweiterte Passwortsicherheit" wird deaktiviert, wenn die Kerberos-Authentifizierung aktiv ist. Ein Mischbetrieb von Datenbank-Authentifizierung und Kerberos-Authentifizierung ist nicht möglich. Das Ändern des Benutzerpasswortes über die Anwendung ist nun nicht mehr möglich. Damit die Änderungen wirksam werden, ist eine Neuanmeldung erforderlich.

Die folgenden Einstellungen stehen zur Verfügung:

Option	Beschreibung
ActiveDirectory zur Authentifizierung aktivieren	Eingeschaltet Hier kann die Kerberos-Authentifizierung aktiviert bzw. deaktiviert werden. Ausgeschaltet Sollte die Konfiguration von Kerberos nicht funktionieren und sich als Folge dessen keiner mehr am System anmelden können, so kann die Kerberos-Authentifizierung über folgendes SQL-Statement deaktiviert werden: SQL update propertymapper set propertyvalue = 'false' where id = '/de/cursor/jevi/common/session/SessionVO$!!$use.LDAP';
Administrationsbereiche (Domains)	Der Administrationsbereich kann beispielsweise der DNS-Domänen-Name sein ("CURSOR.DE"). Ab der Version 17.1.8 ist es möglich, Komma-getrennt weitere Administrationsbereiche anzugeben ("CURSOR.DE,AKADEMIE.CURSOR.DE"). Es können sich dann Anwender aus allen angegebenen Bereichen anmelden. Ab der Version 17.2 wurde das Konfigurationsformat erweitert, um für jede Domäne sowohl den NetBIOS-Domänennamen als auch den vollqualifizierten Domänennamen (FQDN) anzugeben. Dies ist vor allem dann relevant, wenn sich der NetBIOS-Domänenname und der FQDN unterscheiden. Das Format sieht wie folgt aus: <NetBIOS Domainname1>[<FQDN1>],<NetBIOS Domainname2>[<FQDN>] (und so weiter) Um die Abwärtskompatibilität zu gewährleisten, ist die Angabe des FQDN bei Applikationsservern auf Windows-Basis optional.
Domain Controller	Der Name des zum Administrationsbereich passenden KDC-Servers ("KDC.CURSOR.DE"). Sofern mehrere Administrationsbereiche angegeben wurden, sind Komma-getrennt auch weitere KDC-Server anzugeben ("KDC.CURSOR.DE,KDC2.CURSOR.DE"). Dabei ist darauf zu achten, dass die Reihenfolge der KDC-Server-Einträge mit der Reihenfolge der Domänen-Einträge übereinstimmt.
Benutzername des Dienstbenutzers (Linux)	Wird nur bei Applikationsservern auf Linux für Single Sign-on benötigt. Bei Windows-Servern kann das Ausfüllen dieser Einstellung entfallen, da der der Benutzerkontext des Dienstes verwendet wird. Der vollqualifizierte Benutzername des Domänenbenutzers, der Zugriff auf den Kerberos Service Principal Name (SPN) des Servers hat. ("cursor-crm-user@CURSOR.DE") Für die Anmeldung an den KDC-Server muss im JBoss Server eine Kerberos Keytab-Datei konfiguriert werden.
Groupware-Kerberos-Authentifizierung	Eingeschaltet Für die Anmeldung an serverseitigen Groupware-Systemen für die Kerberos-Authentifizierung genutzt. Ausgeschaltet

Erstellung und Konfiguration einer Kerberos Keytab-Datei (Linux)

Für die Kerberos Authentifizierung unter Linux muss für die Anmeldung am KDC-Server (Domain Controller) ein Domänenbenutzer hinterlegt werden. Der Benutzername kann in den Systemeinstellungen zur Passwortsicherheit hinterlegt werden. Das Passwort wird in einer Kerberos Keytab-Datei auf dem Server gespeichert und im JBoss Server konfiguriert. Hierbei muss sichergestellt werden, dass nur der eigene Benutzer auf die Datei Zugriff hat.

JBoss/bin/standalone.conf

...
# Pfad für Keytab Passwort Datei für Kerberos Login unter Linux. [Standard 'leer', z.B. $HOME/user.keytab]
export KEYTAB_PATH=$HOME/user.keytab
...

Unter Linux kann eine Keytab-Datei mit dem Tool ktutil erzeugt werden. Dabei sind die folgenden Schritte auszuführen.

Achtung

Besonders auf Linux-Betriebssystemen muss der Domain-Name immer in Großbuchstaben (zum Beispiel EXAMPLE.COM) angegeben werden, da sonst die diversen Kerberos-Hilfsprogramme nicht ordnungsgemäß funktionieren.

Im folgenden Beispiel wird ein Keytab mit verschiedenen Encryption Types für maximale Kompatibilität sowohl mit älteren als auch aktuellen Versionen von Active Directory und Windows erstellt. Sollten bestehende Sicherheitsrichtlinien manche dieser Typen verbieten, kann der entsprechende Eintrag bei der Erstellung ausgelassen werden. Beispielsweise wird mittlerweile häufig RC4 (arcfour-hmac) domainweit deaktiviert.

Bei Problemen beim Single Sign-on in Verbindung mit Linux-Servern kann es sinnvoll sein, mittels des Windows-Befehls klist auf den Client-Rechnern zu prüfen, welcher Verschlüsselungstyp für das Kerberos Ticket verwendet wird. Dieser Verschlüsselungstyp muss dann auch im Keytab enthalten sein.

Shell auf dem Linux-Server

# Anmeldung als Dienstbenutzer
$ kinit <Benutzername@DOMAINNAME>
Password for <Benutzername@DOMAINNAME>: 


# Ermitteln der kvno, wird im nächsten Schritt benötigt
$ kvno <SPN>
<SPN>: kvno = 17


# Abmeldung des Dienstbenutzers
$ kdestroy


# Erstellen des Keytabs
$ ktutil
ktutil:  addent -password -p <Benutzername@DOMAINNAME> -k <kvno> -e arcfour-hmac
Password for <Benutzername@DOMAINNAME>:
ktutil:  addent -password -p <Benutzername@DOMAINNAME> -k <kvno> -e aes128-cts-hmac-sha1-96
Password for <Benutzername@DOMAINNAME>:
ktutil:  addent -password -p <Benutzername@DOMAINNAME> -k <kvno> -e aes256-cts-hmac-sha1-96
Password for <Benutzername@DOMAINNAME>:
ktutil:  wkt /home/<Linux JBoss Benutzer>/<Benutzername>.keytab
ktutil:  q


# Zum Prüfen der Anmeldung:
$ kinit -k -t /home/<Linux JBoss Benutzer>/<Benutzername>.keytab <Benutzername@DOMAINNAME>


# Abmeldung des Dienstbenutzers
$ kdestroy

Konfiguration des Rich Clients

Die Kerberos-Authentifizierung wird für den Rich Client in der Datei configuration.bat eingestellt. Hierfür stehen die Variablen KERBEROS_REALM bzw. KERBEROS_KDC bereit. Diese sind analog zu den Systemeinstellungen Administrationsbereich (Domain) und Key Distribution Center (KDC) zu füllen.

Zusätzlich gibt es für Single Sign-on die Variable KERBEROS_SPN. Hier muss der für den Applikationsserver konfigurierte Service Principal Name (SPN) eingetragen werden.
An dieser Stelle muss das Format HTTP/<vollqualifizierter Hostname des Applikationsservers>@<Domain-Name> verwendet werden, also beispielsweise "HTTP/CURSORCRM-HOST.CURSOR.DE@CURSOR.DE".

Nach dem Update sollten Sie sicherstellen, dass die Datei configuration.bat die richtigen Werte enthält, da sonst keine Anmeldung möglich ist.
Je nach Konfiguration Ihrer Windows-Domäne werden Mitarbeiter möglicherweise nach einer bestimmten Anzahl von Fehlversuchen in der domänenweit gesperrt.

Konfiguration der Browser

Für die Nutzung von Single Sign-on im Web Client müssen zusätzlich die verwendeten Browser konfiguriert werden. Dabei greifen der Microsoft Internet Explorer, Microsoft Edge und Google Chrome auf die Internetoptionen von Windows zurück. Firefox dagegen verwendet eine eigene Einstellung. Die korrekte Konfiguration für die jeweiligen Browser wird nachfolgend beschrieben.

Bei einer fehlerhaften Konfiguration des Browsers kann es beim Öffnen des Web Clients zu einer Passwortabfrage ähnlich zum folgenden Screenshot kommen:

Temporär kann das Problem umgangen werden, indem in diesem Dialog "Abbrechen" ausgewählt wird. Dann kann über die CURSOR-CRM-Anmeldemaske ein manueller Login-Vorgang mit Benutzername und Passwort durchgeführt werden.

Wenn dieser Fall auftritt, sollte die Konfiguration des verwendeten Browsers auf dem betroffenen Rechner erneut geprüft werden.

Internetoptionen (Internet Explorer, Edge und Chrome)

Die Browser Microsoft Internet Explorer, Microsoft Edge und Google Chrome greifen alle intern auf die Internetoptionen von Windows zurück. Diese können am einfachsten in den Einstellungen des Internet Explorers über den Menüpunkt "Internetoptionen" erreicht werden.
Dort müssen folgende Einstellungen getätigt werden:

Manuelle Einstellungen

1. Internetoptionen → Reiter "Erweitert" → Abschnitt "Sicherheit" → "Integrierte Windows-Authentifizierung aktivieren": Eingeschaltet
   

   

   
   

2. Internetoptionen → Reiter "Sicherheit" → Zone "Lokales Intranet" → "Stufe anpassen" → Abschnitt "Benutzerauthentifizierung" → Abschnitt "Anmeldung": "Automatische Anmeldung mit aktuellem Benutzername und Passwort" oder "Automatisches Anmelden nur in der Intranetzone"
   

   

   
   

3. Internetoptionen → Reiter "Sicherheit" → Zone "Lokales Intranet" → "Sites" → "Erweitert": Entweder per Platzhalter die gesamte Domäne (zum Beispiel *.example.com) oder den FQDN des CRM-Servers (zum Beispiel cursor-crm.example.com) hinzufügen
   

   

Einstellung per Gruppenrichtlinie

Um diese Einstellungen nicht händisch auf jedem Rechner vornehmen zu müssen, können sie per Gruppenrichtlinie in der Domäne verteilt werden. Die dafür verwendeten Gruppenrichtlinien heißen wie folgt:

1. Benutzerkonfiguration\Einstellungen\Systemsteuerungseinstellungen\Interneteinstellungen → Neue erstellen → "Internet Explorer 10": Wie bei der manuellen Einstellung auch "Integrierte Windows-Authentifizierung aktivieren"

2. Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Internet Explorer\Internetsystemsteuerung\Sicherheitsseite\Intranetzone →  „Anmeldungsoptionen“: "Automatische Anmeldung mit aktuellem Benutzername und Passwort" oder "Automatisches Anmelden nur in der Intranetzone"
   

3. Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Internet-Explorer\Internetsystemsteuerung\Sicherheitsseite → „Liste der Site zu Zonenzuweisung“: FQDN des CRM-Servers oder Platzhalter für die gesamte Domäne hinterlegen

Firefox

Unter about:config → network.negotiate-auth.trusted-uris muss die SPNEGO-Authentifizierung für den CRM-Host erlaubt werden. Der Wert dieser Einstellung ist eine kommagetrennte Liste von URL-Präfixen oder Domains. 
Ist das CRM beispielsweise unter https://crm.example.com erreichbar, kann hier https://crm.example.com oder crm.example.com eingetragen werden.

Soll beispielsweise in einem Unternehmen die SPNEGO-Authentifizierung für alle Subdomains ermöglicht werden, kann eine Art Wildcard definiert werden. So erlaubt der Wert .example.com die SPNEGO-Authentifizierung auf allen Subdomains von example.com.

Weitere Informationen zu dieser Konfiguration können der Mozilla-Dokumentation entnommen werden. Für die automatische Verteilung dieser Einstellung ist die Dokumentation von Mozilla zu konsultieren.

Wahl des Administrationsbereichs

 Über den Benutzernamen kann der Administrationsbereich gewählt werden, gegen den authentifiziert wird. Zur Auswahl stehen nur die in den Systemeinstellungen konfigurierten Bereiche. Dabei ist sowohl die neuere Schreibweise "Anwender@ADMINISTRATIONSBEREICH" als auch die ältere Schreibweise "ADMINISTRATIONSBEREICH\Anwender" möglich. Initial ist die Anmeldemaske mit dem Administrationsbereich vorbelegt, mit dem der Anwender im Betriebssystem angemeldet ist. Unter Windows wird zunächst versucht aus der Umgebungsvariable "USERDOMAIN" den Administrationsbereich zu bestimmen. Ist diese nicht gesetzt (weil z.B. ein lokales Konto verwendet wird), wird der Default-Administrationsbereich (der erste in der Liste) verwendet. Unter Unix wird in diesem Fall direkt der Default-Administrationsbereich genutzt. Lässt man den Administrationsbereich weg und gibt nur den Benutzernamen an, so greift das gleiche Vorgehen.

Beispiele:

Administrationsbereiche: "CURSOR.DE,AKADEMIE.CURSOR.DE"

• In Windows mit bne@cursor.de angemeldet: bne => bne@CURSOR.DE

• In Windows mit bne@akademie.cursor.de angemeldet: bne => bne@AKADEMIE.CURSOR.DE

• In Windows mit lokalem Konto angemeldet: bne => bne@CURSOR.DE

• Egal wie angemeldet: bne@CURSOR.DE bleibt bne@CURSOR.DE