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 Generierung in AzureAD/Office 365

In Office 365 muss jeder Anwender einen "UserPrincipalName" haben, um sich anmelden zu können. In der Regel haben aber lokale Benutzer im Active Directory keinen UPN oder nutzen z.B. eine Domäne, die in Office 365 gar nicht registriert ist. AADConnect muss in dem Fall einen UPN erzeugen. Das erfolgt nicht zufällig sondern auch anhand bekannter Regeln:

AADConnect und AzureAD generieren neben dem UPN auch einen "AzureAD MailNickName". Das ist üblicherweise der Exchange Alias des lokalen Users aber wenn der lokale Anwender kein Postfach hat, muss dieses Feld dennoch gefüllt werden, weil davon andere Dienste, unter anderem der UPN, abhängen. Der AzureAD MailNickName wird in der Reihenfolge erstelle

  • On-premises mailNickName Attribut
  • Prefix der primären SMTP Adresse
  • Prefix des On-premises Attributes "mail"
  • Prefix des On-premises userPrincipalName attribute bzw. Alternate login ID
  • Prefix der sekundären SMTP-Adressen

Es kommt das erste Feld zum Tragen, welches gefüllt ist. Wenn dieses nicht eindeutig ist, wird eine Nummer angehängt.

Der UPN wird dann, wenn er nicht durch AADConnect aus dem lokalen AD genutzt werden kann, aus diesem AzureAD MailNickName und der DefaultDomain des Tenant gebildet.

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 On-Premises 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 = SIP = MAIL

Ich vertrete den Standpunkt, dass Sie die weniger Probleme haben, wenn die drei Felder den identischen Inhalten haben. Ich gebe zu, dass damit ein Angreifer natürlich schon einen teil der Anmeldedaten erraten kann, wenn er von ihrer Visitenkarte die Mailadresse abliest. Aber Security by Obscurity war noch nie ein guter Ratgeber. Auch andere Anmeldedaten können sehr einfach in Erfahrung gebracht werden. Denken Sie einfach mal daran, dass diese Informationen für jeden "Domain Benutzer" lesbar ist. Und dann überlegen Sie mal, wie viele Azubis, Gäste, Dienstleiter und natürlich auch Schadcode auf einem PC eines Anwenders die Möglichkeit haben, diese Informationen zu lesen und zu exportieren. Einen Zugang müssen Sie anders schützen als durch verfremdete Anmeldedaten.

Umgekehrt können Sie aber viel gewinnen, wenn alle drei Felder "gleich" sind.

  • Autodiscover
    Wenn Sie Outlook oder ein Smartphone per Autodiscover einrichten, dann werden ihre Anwender nach "Mail-Adresse und Kennwort" gefragt. Als Administrator sollten Sie wissen, dass der Client direkt mit der Mailadresse auch eine Anmeldung versucht und nur wenn dies nicht möglich ist, dann bekommt der Anwender einen weiteren Dialog zu sehen, in dem er nun bitteschön den "richtigen" Anmeldenamen eingeben soll
  • SIP = UPN
    In Office 365 haben Sie gar keine Wahlmöglichkeit. Die SIP-Adresse Ist mit dem UPN in fast allen Fällen identisch. Wenn Sie nun wirklich eine "Unified Communication"-Integration wüschen, dann sollte ihre SIP-Adresse und Mailadresse identisch sein. Nur so kann Outlook direkt bei der Mail schon ermitteln, ob der Empfänger oder Absender "online" sind. Und wenn MAIL=SIP  und weiter auch SIP= UPN, dann ist auch UPN=MAIL.
  • Verwirrende Anmeldedialoge
    An vielen Stellen ist dem Anwender gar nicht bekannt, dass er den UPN eintragen muss und an anderen Stellen doch wieder die Mailadresse. Kan verwirrend wird es dann, wenn Windows selbst es "falsch" macht. So kommt bei einem Windows 210-Dialog zu UAC folgendes Fenster

    Ihnen sich sicher klar, dass hier mitnichten die Maildresse sondern der UPN eingegeben werden muss. Mit der Mailadresse kann sich der Anwender nicht anmelden.

Ich könnte ihnen noch viele weitere Beispiele anführen, bei denen Unterschiede beim UPN, Mail-Adresse und SIP-Adresse zu Problemen, Störungen oder zumindest Verzögerungen führt. Aus meiner Sicht ist es richtig, wenn alle drei Felder den gleichen Wert haben und Sie sich natürlich Gedanken machen, wie sie generell die Konten gegen Angriffe schützen.

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