Office 365 – User Principal Name

Hintergrundinformationen

Um den vollständigen Funktionsumfang von Office365 zu gewährleisten, sind Anpassungen an den Benutzer-Attributen notwendig. Diese Anpassungen beziehen sich auf die Einführung/ Änderungen des User PrincipalNames (UPN). User PrincipalNamesals Alias für den Realm-basierten Benutzernamen konfiguriert werden. Sie erlauben u.a. die bequemere Anmeldung an Domänen-Clients auch unter einem Benutzernamen, der eher einer Email-Adresse gleicht. Dieses ist unabhängig von technischen Details wie dem exakten Namen der benutzten Active Directory Domäne. Der UPN ist mit dem Benutzerkonto verknüpft.

Beispiele von User Principal Namen sind:

Torben.Ritter@tri-demo.de

tri-demo\Torben.Ritter

Ein nicht Routingfähiger UPN ist zum Beispiel:

Max.Mustermann@tri-demo.local

Der UPN sollte beim Kunden als zusätzliche Anmeldeoption im Active Directory gesetzt werden. Da nicht routbare Domains (z.B. tri-demo.local) in Office365 nicht verifiziert werden können, erfordert Microsoft, dass alle Benutzer-Login-IDs vollständig internetfähig sind. 

Wenn eine Änderung der lokalen UPN aufgrund von Authentifizierungsanforderungen im Active Directory sowie Anforderungen an lokale Anwendungen nicht möglich ist, wird die Einrichtung einer alternativen Anmelde-ID empfohlen. Mit dieser alternativen Anmelde-ID kann der Anmeldeprozess so konfiguriert werden, das sich Benutzer mit einem anderen Attribut als ihrem UPN anmelden (Beispiel E-Mail – Adresse). 

Ein Vorteil dieser Funktion ist, dass Office365-Dienste eingesetzt werden können, ohne den lokalen UPNs anzupassen. Auch die Weiternutzung von eigenen Anwendungen oder von branchenspezifischen Serviceanwendungen (Beispiel SAP) ist mit den bisherigen Identitäten möglich. Wenn die integrierte Windows-Authentifizierung (WIA) ausgeführt wird, wird UPN zur Authentifizierung verwendet.


Zusätzliche Überlegungen

Die Funktion „alternative Login-ID“ ist nur in föderierten Umgebungen mit ADFS verfügbar. Sie wird in den folgenden Szenarien nicht unterstützt:

  • Nichtroutbare Domains (z.B. tri-demo.local)
  • Verwaltete Umgebungen, in denen ADFS nicht installiert ist.

Diese Funktion ist nur für Benutzername/ Passwort-Authentifizierung verfügbar, die die folgenden ADFS-Protokolle unterstützt: 

  • SAML-P
  • WS-Fed
  • WS-Trust
  • OAuth

Wenn die integrierte Windows-Authentifizierung (WIA) ausgeführt wird, wird UPN zur Authentifizierung verwendet.Wenn Anspruchsregeln für Vertrauenspersonen für die alternative Login-ID-Funktion konfiguriert sind, muss sichergestellt sein, dass diese Regeln im WIA-Fall weiterhin gültig sind.Wenn die alternative Login-ID aktiviert ist, muss mindestens ein globaler Katalogserver vom ADFS-Server für jede von ADFS unterstützte Benutzerkontenstruktur erreichbar sein. Wenn ein globaler Katalogserver nicht erreichbar ist, wird ADFS auf die Verwendung von UPN zurückgreifen. Standardmäßig sind alle Domänencontroller globale Katalogserver.Findet der ADFS-Server mehr als ein Benutzerobjekt mit dem gleichen alternativen Login-ID-Wert, der in allen konfigurierten Forest angegeben ist, wird die Anmeldung fehlschlagen. Der ADFS-Server versucht, den Anwender zuerst mit der alternativen Anmelde-ID zu authentifizieren und greift dann auf UPN zurück, wenn kein Konto gefunden wird.Es muss sichergestellt werden, dass es keine Konflikte zwischen der alternativen Login-ID und der UPN gibt, wenn die UPN-Anmeldung weiterhin unterstützt werden soll. Wenn ein konfigurierter AD-Forest ausgefallen ist, sucht der ADFS-Server weiterhin nach einem Benutzerkonto mit alternativer Login-ID in anderen konfigurierten AD-Forest. Wenn der ADFS-Server einen eindeutigen Benutzer in den von ihm gesuchten Forest findet, wird er erfolgreich eingeloggt. Die Anmeldeseite des ADFS-Servers kann angepasst werden, um den Endbenutzern einen Hinweis auf die alternative Anmelde-ID zu geben.


Impliziter und expliziter UPN 

Technisch gesehen gibt es zwei UPNs, den impliziten und den expliziten. Der explizite UPN steht im AD-Attribut userPrincipalName (Bild rechts). Der implizite UPN setzt sich zusammen aus <Loginname>@<FQDN der Domäne> z.B. TRI@tri-demo.local

Da bei der Anmeldung an der Domäne der implizite UPN weiterhin funktioniert, sollte der Großteil der Anwendungen weiterhin funktionieren. Wenn eine Anwendung jedoch wie in folgendem Beispiel das AD-Attribut userPrincipalName explizit abfragt und verwendet, sind sehr wahrscheinlich Änderungen notwendig:

<ActiveDirectoryAccessusername=„TRI“ password=„123456789„ ldappath=“LDAP://tri-demo.local/DC=tri-demo,DC=local“ldapfilter=“(&amp;(objectclass=user)(userPrincipalName={0}@tri-demo.local))“ />

Gegebenenfalls kommt es auch zu Problemen wenn eine Anwendung die Funktion „Basic Authentication“ verwendet. 

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.