Alternate Login ID

Diese Seite beschreibt die Aspekte einer Alternate Login ID in Verbindung mit Office 365 / Microsoft 365 für die Fälle, bei denen der lokale UPN nicht genutzt werden kann oder eine Änderung nicht einfach möglich ist. Es handelt sich dabei aber um eine vom Standard abweichende Konfiguration, wie Microsoft selbst explizit schreibt:

Microsoft's recommended best practices are to match UPN to primary SMTP address. This article addresses the small percentage of customers that cannot remediate UPN's to match.
https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/operations/configuring-alternate-login-id.

Hintergründe

Jeder Anwender, der einen Dienst in Office365 oder Microsoft 365 nutzt, muss sich natürlich authentifizieren. Das ist nicht neu und schon bei lokalen Diensten mussten sich Benutzer natürlich schon mit einer Kombination aus Benutzername und Kennwort anmelden. Die meisten Anwender aber einfach nur einen "Benutzername" eingegeben und nur ein Administrator wusste, dass im Hintergrund damit der "samaccountname" gemeint war. Wer lokal schon mit mehreren Domänen zu tun hatte, kennt sicher auch die Anforderung, eine Domäne in der Form "Domäne\Username" davor zu stellen. Da aber weder ein Benutzername und erst recht nicht die Domäne weltweit eindeutig ist, können diese Anmeldeinformationen so nicht in der Cloud genutzt werden.

In den Cloud braucht es einen Anmeldenamen, der weltweit eindeutig ist, damit die Cloud immer zuverlässig den Anwender erkennt. Da liegt es ja nahe, die "Mail-Adresse" zu verwenden, die weltweit zwingend eindeutig ist und den Anwendern auch entsprechend bekannt ist.

Allerdings ist die Mail kein Kriterium für die Anmeldung an Active Directory oder AzureAD. Das hier genutzte Feld ist der "UserPrincipalName" (Siehe auch Cloud UPN / Anmeldename), den es auch im Active Directory gibt und durch ADSync auch in die Cloud repliziert wird.

Ideal ist es, wenn die Mailadresse und der UPN identisch ist, weil Sie dann ohne Änderung loslegen können. Aber oft ist die aus unterschiedlichsten Gründen genau nicht der Fall.

  • "private" AD-Domain
    Wenn Sie ein Active Directory einrichten, dann müssen Sie einen DNS-Namen vorgeben, aus dem sich auch das UPN-Suffix ableitet. Die meisten Firmen haben sich damals schwer damit getan, die interne Domäne wie die externe Domäne zu nennen. Split-DNS etc. ist hier nur ein Aspekt. Damit haben alle Benutzer einen UPN dieser Domäne
  • Angst vor UPN-Änderung
    Natürlich können Sie in einer AD-Domäne wie "uclabor.intern" problemlos auch weitere UPN-Suffixe anlegen und bei den Benutzern verwenden. Es gibt keine feste Zuordnung. Die Änderung des UPN kann natürlich andere Effekte hervorrufen (Kerberos, Zertifikate, 802.1x, SmartcardLogin), so dass die Änderung als Risiko gesehen wird
  • MultiForest und UPN-Domains
    Eine UPN-Domain darf auch immer nur genau einem Forest zugewiesen sein. Wenn mehrere Forests die gleiche UPN-Domain nutzen, sind Vertrauensstellungen nur bedingt nutzbar.

Und so gibt es noch weitere Gründe, die eine Änderung des UPNs im lokalen Active Directory erschweren oder sogar auf einige Zeit unmöglich machen. Aber die Mail-Adresse ist natürlich immer eindeutig und dem Benutzer bekannt. Dennoch sollten Sie die Empfehlung von Microsoft immer im Hinterkopf haben:

Microsoft's recommended best practices are to match UPN to primary SMTP address. This article addresses the small percentage of customers that cannot remediate UPN's to match.
Quelle: Configuring Alternate Login ID https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-login-id

Wählen Sie den Weg der "Alternate Login ID" bitte nur, wenn sie den UPN im lokalen Active Directory nicht ändern können. Es ist keine gute Idee, wenn Sie den UPN im AD aus Bequemlichkeit einfach nicht ändern wollen. Alternate Login ID hat durchaus Einschränkungen und ist nicht der Regelfall.

Im Weiteren gehe ich, wie Microsoft, davon aus, dass Sie die Mailadresse als "Office 365 Anmeldenamen" verwenden. Andere Felder sind im Prinzip auch möglich aber nicht beschrieben.

Alternative Anmeldenamen

Wenn eine Änderung des UPN nicht zur Debatte steht, aber Office 365 genutzt werden soll, dann muss ein anderes Feld zu Hilfe genommen werden. Das hat aber Einfluss auf zwei Dinge:

  • ADSync
    Die Pflege der Identitäten in der Cloud erfolgt bei fast allen Firmen über eine lokale ADSync-Instanz, die lokale AD-Benutzer und Gruppen in den Tenant übertragen. Dieser Synchronisationsprozess muss angepasst werden, dass der UPN in der Cloud auf Basis eines anderen lokalen Felds zu setzen ist.
  • Authentifizierung
    Wenn der Anmeldename in der Cloud aber von dem lokalen Anmeldenamen getrennt ist, muss auch die Überprüfung der Anmeldung durch ADFS aber auch PHS/PTA dies berücksichtigen.

Genau diese Besonderheiten hat Microsoft im April 2014 berücksichtigt, also Sie das Verfahren einer "Alternate Login ID" angekündigt haben.

Required reliance on UPN has been removed for the synchronized identity and federated identity models, and you can now select an alternate login ID for use with Office 365 and Azure Active Directory if you use either of these models to create your user accounts. The use of UPN is still the default for these two models. If you want your users to be able to use an alternate login ID, you have to configure your system. When you configure, you can select the Mail attribute or any other attribute in your On-Premises Active Directory.
Quelle: Alternate Login ID”
https://www.microsoft.com/en-us/microsoft-365/blog/2014/05/06/alternate-login-id-for-office-365-reduces-dependence-on-upn/

Anforderung an die AlternateLoginID

Wenn Sie statt des UPN ein anderes Feld nutzen wollen oder müssen, dann sollten Sie das Feld weise wählen. Es gibt nämlich ein paar Voraussetzungen, die sich aber selbst erklären.

  • Inhalt im UPN-Format
    Erklärt sich eigentlich alleine, da ADFS vom Client ja einen Anmeldenamen bekommt, nach dem er dann suchen muss.
  • Feld muss im GC sein
    Auch wenn Sie nur eine Domäne haben, sucht ADFs doch im GC. Das Feld muss daher im GC repliziert werden
  • Feld muss indexiert sein
    Ansonsten wird jede Anfrage an einen DC sehr lange dauern oder nicht schnell genug gelingen
  • ADFS ServiceAccount braucht Read
    Da ADFS per LDA sucht, muss er auch das Recht zum Lesen des Feldes haben.

Dass das alles erst ab Windows 2012R2 oder höher funktioniert, erwähne ich nur zur Vollständigkeit. Ich erwarte nicht, dass jemand noch so eine alte Version aus dem Internet erreichbar macht.

Einrichtung ADSync

Ohne entsprechende Anpassungen wird ADSync natürlich den UPN aus dem lokalen Active Directory lesen und ins AzureAD übertragen. Hier muss eine entsprechende Transformation erfolgen. Zum Glück hat Microsoft hier schon vorgearbeitet, denn direkt in der GUI bei der Einrichtung können Sie das Feld auswählen, aus dem ADSync die Anmeldedaten übernehmen soll:

Der UserPrincipalName ist der "Default". Es gibt durchaus Firmen, die den UPN nicht ändern wollen aber sich dann auf das normalerweise eindeutige Feld "Mail" festlege. Denkbar ist aber auch ein andere Felder. Generell ist aber daran zu denken.


Quelle: https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-install-custom#azure-ad-sign-in-configuration

Achtung
Diesen Dialog sehen Sie nur bei der ersten Einrichtung und ist später nicht mehr per GUI erreichbar. Eine nachträgliche Änderung ist aber durch eine Neuinstallation oder manuelle Anpassung der Regeln möglich.

Eine Beschreibung, wie Sie den Attribute Flow im ADSync umstellen finden Sie auf der WIKI Seite DirSync: "Using Alternate Login IDs with Azure Active Directory" (https://social.technet.microsoft.com/wiki/contents/articles/24096.dirsync-using-alternate-login-ids-with-azure-active-directory.aspx)

Einrichtung ADFS

Beim der Einrichtung von ADFS muss nun natürlich auch dieser neue Wert berücksichtigt werden, dass die Anwender sich in der Cloud ja mit der Mailadresse anmeldet und der Authentifizierungsdienst der Cloud (EvoSTS) dank der Konfiguration als "Federated" den Anwender zum lokalen ADFS-Server sendet. Dor kommt der Anwender nun aber mit seiner Mailadresse an. ADFS darf nun nicht nach dem String im lokalen UPN-Feldern suchen, sondern nach Mail. Dies erfolgt durch die Anpassung von ClaimRules.

Achtung: Wenn Sie den ADFS-Server auch für andere Service nutzen, dann müssen Sie prüfen, dass diese Anpassung für die anderen "Relying Party Trust"-Partner keine negativen Auswirkungen hat

Auch hier hat Microsoft aber schon entsprechende PowerShell-Befehle vorbereitet:

Set-AdfsClaimsProviderTrust `
   -TargetIdentifier "AD AUTHORITY" `
   -AlternateLoginID mail `
   -LookupForests uclabor.de,msxfaq.de

Das Beispiel setzt nicht nur die AlternateLoginID, sondern gibt auch für, für welchen Forest der ADFS-Server in diesem Feld statt dem UPN suchen soll. Sie können On-Premises durchaus mehrere Forests betreiben, die per Trusts verbunden sind. Sie können sich gerne in der ADFS-Konfiguration auch die Claim Rules anschauen. Der Default sieht so aus

Nach der Umstellung wurde der userPrincipalName durch das Feld "mail" ersetzt

Wenn Sie dann doch irgendwann ihren UPN umgestellt haben und die Funktion beim ADFS wieder rückgängig machen wollen, dann geht das mit folgender Zeile:

Set-AdfsClaimsProviderTrust `
   -TargetIdentifier "AD AUTHORITY" `
   -AlternateLoginID $NULL `
   -LookupForests $NUL

Einrichtung PHS/PTA

Immer mehr Firmen verzichten aber auf einen ADFS-Server und vertrauen dem evoSTS von Microsoft zur Authentifizierung. Ich habe noch keinen Information gefunden, ob ich als Office 365 Tenant Admin dem evoSTS eine Konfiguration mitgeben muss. Bei PHS kann der evoSTS den Benutzer zwar sicher einfach anmelden aber in Verbindung mit "Seamless Signon", bei dem der Client ein Kerberos-Ticket an den evoSTS sendet, hätte ich erst einmal gezögert. Bei PTA muss der lokale Agent die Authentifizierung durchführen. Ich habe aber eine Quelle bei Microsoft gefunden, die die Funktionsfähigkeit anzeigt:

Q: Does Pass-through Authentication support "Alternate ID" as the username, instead of "userPrincipalName"?
A: Yes, sign-in using a non-UPN value, such as an alternate email, is supported for both pass-through authentication (PTA) and password hash sync (PHS)
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta-faq#does-pass-through-authentication-support-alternate-id-as-the-username-instead-of-userprincipalname

Konfiguration auf dem Client

Neben den Änderungen am ADSync und den Authentifizierungsdiensten müssen auch die Clients damit zurecht kommen. Dazu sind erst einmal "Mindestversionen" von Office (Outlook, Skype for Business, Word, Excel, OneDrive etc.) ab 1712 (build 8827.2148) erforderlich und auch Windows muss 1709 oder neuer sein. Zudem müssen Sie für Windows 7/8 und ältere Office-Versionen ein paar lokale Registrierungsschlüssel setzen, damit die Applikationen auch den richtigen Wert zur Cloud senden.

Email als AlternateID

Im EntraID-Portal gibt es noch eine weitere Option, die aber nichts mit Federated Domains zu tun hat. Sie können hier die Option aktivieren, dass der Anmeldedialog auch in den Proxy-Addresses nach den eingegebenen Namen sucht. Damit kann ein Anwender dann eine seiner Mailadressen nutzen und Microsoft 365 findet das passende Benutzerkonto dazu:


https://portal.azure.com/#view/Microsoft_AAD_IAM/EmailAsAltIDManagement.ReactView

Die beiden Links gehen zu:

Alternate Login ID und Azure

Dass Office Applikationen sich an Office 365-Diensten mit einer Alternate Login ID anmelden können, ist damit sichergestellt. Aber die Anmeldung an Azure Diensten ist damit noch nicht realisiert. Diese Funktion ist im Juni 2020 noch in Preview. Über die Preview-Version der AzureAD-PowerShell können Sie eine bestehende Policy anpassen oder anlegen.

Eine finale Anleitung von Microsoft steht noch aus aber die ersten Blog-Posts zum Thema habe bis dahin verlinkt

Weitere Links