Cloud UPN / Anmeldename

Jeder Dienst in der Cloud erfordert eine Anmeldung durch den Anwender. Wenn wir und auf Office 365 bzw. Azure-AD beschränken, dann ist dazu eine Identität in der Cloud erforderlich und natürlich ein Kennwort. Die Identität kann durch einen Administrator manuell oder durch einen DirSync automatisch angelegt werden. Die Anmeldung erfolgt mit einem Kennwort, welches gegen die Office 365 Identität oder per ADFS gegen das lokale AD verifiziert wird, ehe der Zugriff erfolgt. Aber was ist genau diese "Identität"?

Only Users can have UPNs
Quelle: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-duplicate-attribute-resiliency/

Der UPN und die DNS-Domäne

Viele Anwender melden sich historisch an ihrem PC mit einem Benutzernamen an. Selbst die "Domäne" ist vielen Anwendern nicht bekannt, wenn es in der Firma nur eine AD-Domäne gibt. Wer in einer Umgebung mit mehreren Domänen arbeitet, wird vielleicht die Schreibweise "DOMÄNE\Username" bei der Anmeldung können.

Anmeldedialog mit Domain

Da hier bei der "Domänenname" aber nicht eindeutig sein muss, ist diese Anmeldung an Office 365 nicht sinnvoll nutzbar. Hier muss ein eindeutiger Anmeldename über alle Firmen hinweg gefordert werden. Und was ist eindeutiger als eine DNS-Domäne im Internet. Diese kann immer nur genau einer Firma gehören und niemals doppelt vergeben werden.

Daher bietet es an, neben der Anmeldung mit "Domäne\Username" auch eine Schreibweise in der Form "Benutzername@domäne.tld" zu erlauben. Genau so eine Anmeldung ist seit Windows 2000 möglich. Diese Form der Anmeldung kommt also bei Office 365 auch zum Einsatz. Damit wird aber nun die DNS-Domäne für die Anmeldung relevant.

Die DNS-Domäne ist nicht zwingend identisch mit dem internen Namensraum ihres Active Directory Forests. Wenn ihr Forest intern z.B. "firma.local" heißen wollte, dann können Sie dennoch als Anmeldename eine "benutzername@<öffentliche Domain>" verwenden. In Verbindung mit Office 365 muss der Anmeldename allerdings immer eine öffentliche Domain sein.

Nur mit einer im Internet bekannten Domäne können Sie als Besitzer über entsprechende DNS-Einträge auch Office 365 dazu bringen, diese Anmeldenamen zu akzeptieren. Die Domäne muss aber nicht die gleiche Domäne sein, unter der Sie auch ihre offizielle Webseite betreiben. Es gibt aber auch fast keinen Grund dies nicht zu tun.

Denn es bietet sich an, dass der Anmeldename z.B. mit der Mailadresse und der SIP-Adresse übereinstimmt, um die Anmeldung und Konfiguration zu erleichtern. Zudem "kennen" die Anwender in der Regel ihre Mailadresse.

Die Bedeutung des UPN und der UPN-Domäne

Damit dies funktioniert hat aber jeder Benutzer immer auch einen "UserPrincipalName" (UPN), der ebenfalls zur Anmeldung genutzt werden kann. Das Format ist dabei "username@domäne.tld". Wichtig ist dabei zu verstehen, dass dieser Anmeldename nicht nur wie eine Mail oder SIP-Adresse aussieht, sondern der FQDN der Domäne nichts mit dem FQDN der Active Directory Domäne zu tun haben muss. Der Administrator kann im Active Directory weitere "UPN-Suffixe" pflegen und dann beim Benutzerobjekt eine Domäne aus dieser Liste auswählen:

Dies ist wichtig, da dieser Anmeldename der alleinig gültige Name in Office365 und Azure AD ist. Jede andere Kombination aus "Username" alleine oder "Domäne\Username" kann in einem weltweiten Active Directory gar nicht funktionieren. Aber auch die Wahl der Domäne ist nicht frei möglich. Es muss zwingend eine "öffentliche Domäne" sein, die Sie in Office 365 auch eingetragen haben müssen. Sie müssen diese Domäne also auch "besitzen, damit sie dort die zur Verifikation erforderlichen DNS-Einträge addieren können.

Die Domäne ist später auch für die Anmeldung per ADFS erforderlich, denn die Cloud-Dienste erwarten zuerst die Eingabe des Anmeldenamens, also des UPN, um dann abhängig von der Domäne den passenden Authentifizierungsserver anzusprechen. Das kann dann der Office 365 ADFS-Server sein, ein in Azure gehosteter ADFS-Dienst beim Einsatz von Azure AD-Premium oder ein lokaler selbst betriebener ADFS-Service sein.

Nehmen Sie einfach mit, dass alle Identitäten in der Cloud einen gültigen weltweit eindeutigen "UPN" benötigen, dessen Domäne ihnen gehört und Sie beim Einsatz des DirSync entsprechend auch in ihrem lokalen Active Directory den UPN entsprechend einrichten müssen.

Ich empfehle den UPN, die Mailadresse und die SIP-Adresse identisch zu halten. Dies macht es für Anwender besonders einfach. Die Gefahr einer DoS-Attacke auf das Konto, da man aus der Mail-Adresse den ersten Teil einer Anmeldung ableiten kann, muss man generelle begegnen, z.B. per Lockout Policy oder ADFS-Throttling etc.

UPN und verwandte Felder

Neben dem UPN gibt es in einem Active Directory natürlich noch viele andere Felder, die teilweise ähnliche oder identische Inhalte aufweisen und daher mit dem UPN quasi logisch verknüpft sind.

  • Mail
    Jedes AD-Objekt hat auch das Feld "Mail", welches  üblicherweise eine Mailadresse enthält. Wer Exchange 2000 oder höher verwendet wird wissen, dass die Exchange Verwaltungstools diese Feld immer anhand der primären SMTP-Adresse aktualisieren. für Exchange dies dieses Feld aber nicht "zwingend" maßgeblich aber ein Objekt wird von Exchange als "defekt" angesehen, wenn das Feld nicht gesetzt ist. Es sollte also die primäre Adresse des Benutzers enthalten.
    Dieses Feld wird beim DirSync auch herangezogen, um Objekte zu "Matchen", d.h. wenn der DirSync ein neues Objekt "OnPremise" erkennt, dann legt es dieses neue Objekt nicht stupft im Ziel an, sondern sucht nach einem eventuell vorhandenen Objekt.
    Technisch können Sie natürlich nicht per LDAP auf das Azure AD von Office 365 zugreifen.
  • ProxyAddresses
    Für Exchange ist dieses Feld interessanter beim Management von Exchange Empfängern per DirSync/ADSync und Exchange Online. Hier steht die primäre SMTP-Adresse mit dem "großgeschriebenem" Prefix "SMTP: drin. Gemäß meiner Empfehlung sollte dies mit dem UPN übereinstimmen. Weitere SMTP-Adressen, sind problemlos denkbar.
    Bei get-MSOLUser erscheinen diese Adressen alle unter "AlternateEmailAddresses". Besser ist natürlich die Verwaltung mit der Exchange PowerShell gegen Office 365
  • msRTCSipURI
    Diese Feld enthält die SIP-Adresse des Benutzers, wenn er auch eine entsprechende Lizenz bekommen hat. Diese Adresse ist bei Cloud Usern immer identisch mit dem UPN und kann auch nicht abweichend konfiguriert werden. Beim Skype for Business Hybrid Mode hingegen kann dies abweichend sein. Empfohlen ist es aber nicht und anscheinend gibt es z.B.: Probleme bei der Anmeldung am Skype Meeting Broadcast-Portal.

Andere Felder, die Exchange in das OAB einpackt und damit Outlook anzeigt, habe ich nicht weiter betrachtet.

UPN ändern

Nun kann es ja mal passieren, dass der UPN geändert werden muss. Dies kann den "Userpart" betreffen, z.B. durch Heirat aber auch die Domäne kann sich bei einer Umfirmierung ändern. Eine Änderung des UPN kann aber z.B. auch erforderlich sein, weil Sie beim DirSync nicht "aufgepasst" haben und der lokale UPN nicht mit der für Office 365 freigeschalteten Domäne übergestimmt hat. Office 365 legt dann die Benutzer mit der "username@%tenantname%.onmicrosoft.com" an. Mehrere Fälle sind zu unterscheiden:

Objekt Lizenz Ergebnis

Cloud User

nicht relevant

Sie können über den Browser im Admin-Portal einfach den UPN ändern. Office 365 ändert im gleichen Zug neben dem Anmeldenamen auch die SIP-Adresse und die primäre Mailadresse und weist darauf auch explizit hin:

DirSync User

Ohne Lizenz

Wenn die Identitäten in der Cloud mittels DirSync verwaltet werden, dann können Sie den UPN "lokal" ändern. für die Änderungen eventuell mit replizierter Information aus den Proxy-Addresses oder SIP-Adressen müssen sie selbst sorgen.

Der UPN und die anderen Felder werden in der Cloud entsprechend der Quelle nachgehalten. Wobei die Bedeutung von Mailadressen und SIP-Adressen ohne Lizenz natürlich nicht relevant ist.

DirSync User

Mit Lizenz

Sobald das Objekt in der Cloud aber eine Lizenz zugewiesen wurde, verhält sich auch der DirSync anders. Der UPN in der Cloud wird in dem Fall nämlich nicht geändert. Sie müssen als Administrator in dem Fall von Hand nacharbeiten und den UPN der Konten entsprechend ändern. Das geht per Azure PowerShell

Set-MsolUserPrincipalName `
   -UserPrincipalName alterupn@firmen.domain `
   -NewUserPrincipalName neuerupn@firmen.domain

Ich kann mir das nur so erklären, dass eine Änderung des UPN ein durchaus tiefgreifender Einschnitt in eine Identität ist und so eine Änderung noch einmal manuell kontrolliert werden sollte.

UPN und Applikationen

Der UPN wird natürlich auch an anderen Stellen verwendet, z.B. im Outlook Profil, Lync als SIP-Adresse,

Produkt  Auswirkung

Office 365 Pro Plus Windows

Wer Office 365 ProPlus nutzt und daher über den UPN gegen die Cloud aktiviert, wird nach einiger Zeit aufgefordert, den neuen Namen einzugeben, da unter dem alten Namen kein Konto mehr zu finden ist. Sie können das auch beschleunigen, indem Sie in Office 365 Pro Plus die Verknüpfung lösen und wieder neu mit dem neuen Namen einrichten.

Office Mobile Apps (iPad, etc.)

Viele Firmen lizenzieren Office 365 CALs, damit die Mobile-Version von Word, Excel, PowerPoint nicht weiter beschränkt sind.

Skype für Business

Die Änderung des UPN ändert auch die SIP-Adresse. In der Kontaktliste des Anwenders wird sich nichts ändern, aber er muss seine Anmeldedaten in den verschiedenen Clients neu angeben. Andere externe Personen müssen aber auch in ihren Kontakten die SIP-Adresse neu aufnehmen, um weiter die Präsenz zu sehen. Wenn ich es recht gesehen habe, könnten auch die Meeting-URLs ungültig werden. Das trifft aber wohl eher bei einem Rename des UserParts durch Heirat o.ä.

Outlook Profil

Neben der Lizenzierung kann sich mit der Änderung des UPN auch die Mailadresse ändern. Outlook kann in dem Zuge natürlich auch nicht mehr mit den alten Zugangsdaten weiter arbeiten.

OneDrive für Business

Die Verbindung geht auch hier über den UPN 

ActiveSync

Wohl dem, bei dem Mailadresse = UPN ist und die Anwender dann alleine sich entsprechend behelfen können. Die Sync Partnerschaft wird die Eingabe der neuen Mailadresse erwarte und als Folge davon wird natürlich das Postfach quasi neu synchronisiert.

Hier muss ich noch ein paar Testfälle durchspielen 

UPN und MFA

Die Anmeldung per UPN betrifft nicht nur die direkte Anmeldung, sondern auch der Einsatz der Multi Faktor Authentifizierung (MFA). Sollte der UPN geändert werden, dann funktioniert der Link zwischen den App und der Anmeldung nicht mehr. Der Anwender bekommt weiterhin die Aufforderung auf dem Smartphone aber Sie "passt" nicht mehr zu einem der hinterlegten Konten. Das Konto auf der App kann aber nicht umbenannt werden.

Der Anwender kann sich in dem Fall aber weiterhin über die 6-stellige Nummer alternativ authentifizieren.

Um wieder die App zu nutzen, muss er über https://aka.ms/MFASetup seine MFA-Einstellungen einfach aktualisieren. In der App wird dann ein neues zweites Konto angelegt. Erst wenn dies erfolgreich war, sollte der Anwender das "alte" Konto in der App löschen.

Weitere Links