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/

Achtung: Der UPN wird von Exchange Online auch automatisch als SIP und SMTP-Adresse in den ProxyAddresses addiert, wenn der Benutzer eine Exchange Lizenz hat. Dies gilt selbst, wenn On-Premises diese Adresse nicht vorhanden oder sogar einem anderen Konto zugewiesen wurde und damit ein Konflikt aufkommt.

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.

Maximale Anzahl der UPN Domains

Ein Tenant ist nicht auf eine Domain beschränkt. Sie können sehr viele Domänen in einem Tenant registrieren und damit auch verschiedene Töchter eines Konzerns mit einer eigenen Identität versehen. Allerdings gibt es hier Grenzen.

  • Office 365
    In Office 365 können Sie bis zu 900 (Stand Jan 2019) einzelne DNS-Domains mit "Add-MSOLDomain" addieren. Früher war das Limit sogar schon bei 600 Domänen. Die Fehlermeldung weist sie aber auch hier auf den richtigen Weg:

Office 365Office 365 Service Descriptions Office 365 Platform Service DescriptionDomains
You can add up to 900 domains to your Office 365 subscription. However, you can't add a domain to Office 365 that you're already using in another Microsoft cloud service. That means that you can't add the same domain to multiple Office 365 subscriptions
Quelle https://docs.microsoft.com/en-us/office365/servicedescriptions/office-365-platform-service-description/domains

# Anlegen von 1000 Domains
1..1000 | %{new-msoldomain -name "$($_).msxfaq.com"}

new-msoldomain : Unknown error occurred.
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [New-MsolDomain], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.TooManyVerifiedDomainException,Microsoft.Onli
ne.Administration.Automation.NewDomain


# Anzeige der Anzahl aktuell vorhandener Domains
(Get-MsolDomain).count
900

#Cleanup
1..900 | %{remove-msoldomain -DomainName "$($_).msxfaq.com"}
  • Active Directory
    In Verbindung mit AADConnect müssen Sie natürlich jede Domäne auch als UPNSuffix im Forest hinterlegen. Auch hier gibt es ein Limit, was durch die Größe des Feldes UPNSuffixes an dem Objekte CN=Partitions,CN=Configuration,DC=rootdomain,DC=tld vorgegeben ist. Hier sind theoretisch 3937 Einträge möglich. Praktisch dürfte die Grenze aber eben bei 1200 Domänen liegen.

Insofern kommt das AD-Limit bei Office 365 so erst mal nicht zu tragen.

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 erstellt

  • 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 Default-Domain 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.

Microsoft empfiehlt zumindest, dass der UPN und die Mailadresse identisch sind.


Quelle: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-login-id (Feb 2019)

This changes the person's userPrincipalName attribute and has no bearing on their email address. It is best practice, however, to have the person's logon UPN match their primary SMTP address.
Quelle: https://docs.microsoft.com/de-de/office365/admin/add-users/change-a-user-name-and-email-address?view=o365-worldwide

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-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 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