ADSync und UPN
Der UserPrincipalName hat in Verbindung mit Office 365 eine ganz besondere Bedeutung. Daher widme ich ihm eine eigene Seite zum Thema ADSync.
Beachten Sie dazu auch die Seite UPNChange und Applikationen und Office 365:UPN / Anmeldename
Wichtig!
Es gibt immer wieder unklare Aussagen zur Wahl des UPN. Auch wenn meine Empfehlungen nicht alle "zwingend" sind, so sollten sie bei einer Abweichung davon die Folgen kennen.
- UPN mit passender Domain in der Cloud
zwingend
Das ist nicht zu verhandeln. Jeder Benutzer in der Cloud muss einen UPN als Anmeldenamen haben und der Domainanteil muss zu einer Domain gehören, den Sie in ihrem Tenant eingetragen haben. - Cloud UPN = OnPremises UPN (dringend
angeraten)
ADSync repliziert normalerweiser den OnPremises UPN auch in die Cloud. Es ist möglich (Siehe Alternate Login ID), dass Sie in der Cloud einen anderen Loginnamen als im lokalen AD haben, aber ich rate ganz deutlich davon ab. Dazu gehört dann natürlich auch, das bei einer Microsoft 365 Einführung ggfls. auch der lokale UPN des Benutzers erst korrigiert werden muss - UPN = Mail = SIP
Auch dies ist nicht 100% zwingend aber Abweichungen bedeuten Mehraufwand und ggfls. Probleme, die sie ansonsten nie hätten. Die wenigsten Administratoren wissen z.B., dass der UPN in der Cloud auch automatisch als ProxyAddress in der Cloud addiert wird. Das kann zu Konflikten führen wenn ein anderes Objekte diesen Namen als Mailadresse haben sollte. Das mag selten passieren aber gerade daher finden sie es nur mit viel Erfahrung und das kostet einfach Zeit und damit Geld.
Die folgenden Abschnitte beschreiben einige Fälle, wenn Sie von diesen Regeln abweichen.
Leerer UPN
Wenn ihre Active Directory schon einige Jahre alt ist und insbesondere aus einer NT4-Domäne entstanden ist, dann ist es nicht sichergestellt, dass alle Objekte auch einen UPN haben. In neueren Versionen von Windows können Sie in der MMC einen Benutzer gar nicht mehr anlegen, wenn der UPN leer ist.
Aber nicht alle Provisioning-Systeme und Skripte erzwingen den UPN und per ADSIEDIT per "NET User /ADD" können Sie immer wieder Benutzer ohne UPN anlegen. Bei den ersten Versionen des DirSync hat ein fehlender UPN zu einem Fehler beim DirSync geführt. Mittlerweile "löst" ADSync das Problem derart, dass es einen UPN generiert. Im Metaverse hat das Objekt einen UPN bekommen.
In den "Inbound synchronization rule" gibt es in der Regel "In from AD - User Common" auch den entsprechenden Eintrag:
Die hinterlegte Expression ist:
IIF(IsPresent([UserPrincipalName]),[UserPrincipalName], IIF(IsPresent([sAMAccountName]),([sAMAccountName]&"@"&%Domain.FQDN%), Error("AccountName is not present")))
Es wird zuerst der UserPrincipalName genutzt und wenn der nicht da ist, ein UPN aus dem SamAccountName gebildet. Der ist ja schon seit Windows NT4 maximal 15 Stellen lang und enthält keine Leerzeichen.
Ungültiger UPN
Ein UPN in Office 365 muss natürlich ein "gültiger Domainname" einer in Office 365 registrierten Domäne oder eben die "%tenantname%.onmicrosoft.com" sein. Der Standard UPN-Domainname einer On-Prem Domäne ist aber in den seltensten Fällen eine "öffentliche" Domain. Allzu oft heißt die interne Domäne etwas mit ".intern" oder ".local". Sie brauchen natürlich nicht den Namen des AD-Forest zu ändern um einen UPN einer "richtigen" Domäne zu setzen. Über "Active Directory Domain and Trusts" können sie die gültigen UPN-Suffixe pflegen und die UPN der Benutzer dann ändern. Siehe dazu auch Office 365:UPN / Anmeldename. Beachten Sie aber auch die Hinweise auf dieser Seite zum Thema "UPN ändern". Eine Korrektur des UPN in ihren lokalen Active Directory wird nicht in die Cloud übertragen.
Am vorherigen Beispiele haben Sie gesehen, dass ich einen Benutzer "ohne" gültigen UPN angelegt habe und ADSync hat daraus einen UPN anhand der DNS-Domäne des Forest und dem SAM-AccountName generiert. In Office 365 wurde daraus ein gültiger UPN.
ADSync ist hierbei allerdings unschuldig, denn nun sorgt der Office 365 WebService dafür, dass Objekte in der Cloud immer einen für den Tenant gültigen UPN haben. das bedeutet aber auch, dass der Anwender seinen Anmeldenamen nicht wirklich "kennt" und er auch nicht mit der Mailadresse übereinstimmen muss. Im DirSync Protokoll wird in diesem Fall aber keine Fehlermeldung und nicht mal eine Warnung angezeigt. ADSync nutzt den UPN nicht für die Verknüpfung, sondern einen "SourceAnchor", der auf der ObjectGUID des On-Prem-Objects basiert.
UPN-Change ohne Dienste
Interessant wird es dann, wenn ich den UPN On-Premises auf einen gültigen Wert setze. Ich habe in meinem Beispiel dem Benutzer nun einen gültigen UPN verpasst und den ADSync gestartet:
Interessanterweise taucht das Objekt im AD-Connectorspace als "unchanged" auf
Obwohl das Property sich definitiv geändert hat. Warum das hier nicht als "Change" erkennbar wird, weiß ich aktuell noch nicht. Auf der anderen Seite zu Cloud hingegen ist das Objekt als "geändert" sichtbar:
Ein Blick ins Office 365 Admin Center zeigt auch hier, dass der Benutzer geändert wurde:
Dies ist keine Überraschung, da so ein Rename durchaus erlaubt ist, wenn der Benutzer noch keine zusätzlichen Dienste wie Exchange o.ä. nutzt. Sollte der Benutzer aber z.B. ein Postfach haben, dann sieht die Welt schon anders aus.
- Office 365:UPN / Anmeldename
- UserPrincipalName (UPN)
- Namenswechsel
- 2643629 One or more objects don't sync when the Azure Active Directory Sync tool is used
- 2523192 User names in Office 365, Azure, or Intune don't match the On-Premises UPN or alternate login ID
- 2669550 Changes aren't synced by the
Azure Active Directory Sync tool after you
change the UPN of a User account to use a
different federated domain
https://support.microsoft.com/en-us/help/2669550/changes-aren-t-synced-by-the-azure-active-directory-sync-tool-after-yo
UPN Change mit Diensten
Was anderes ist es aber, wenn der User schon ein Exchange Postfach hat. Dann ist die Änderung des UPN nicht mehr ratsam. Interessanterweise können Sie den UPN selbst bei einem "DirSync"-User problemlos über das Admin Center ändern. Wobei problemlos etwas übertrieben ist. Das Admin Center macht ganz groß die Folgen deutlich:
Das kann ein Admin ja gar nicht übersehen. Anders ist es natürlich bei der MMC für Benutzer und Computer im lokalen Active Directory. Hier ist die Änderung des UPN einfach nur ein Mausklick. Wenn Sie dann nicht wüssten, dass dahinter ein ADSync mit Office 365 verbunden ist, könnten die Auswirkungen durchaus schwerwiegend sein. Das bedeutet aber, dass Sie bei einer lokalen Änderung des UPN den Anmeldenamen in der Cloud manuell setzen müssen. Das geht per Azure PowerShell
Set-MsolUserPrincipalName ` -UserPrincipalName alterupn@firmen.domain ` -NewUserPrincipalName neuerupn@firmen.domain
Leider gibt es aber keine Warnung mehr für solche Diskrepanzen.
- Office 365:UPN / Anmeldename
- Set-MsolUserPrincipalName
https://msdn.microsoft.com/en-us/library/azure/dn194135.aspx - Änderungen der UPN und der OneDrive Client
http://www.rakoellner.de/2019/01/aenderungen-der-upn-und-der-onedrive-client/
Hier könnte eine Überwachung auf UPN-Changes oder Diskrepanzen zwischen On-Prem und Azure-AD eine sinnvolle Komponente sein.
Option SynchronizeUpnForManagedUsers
Seit 2016 March release (build 9031.1) hat Microsoft die Funktion "SynchronizeUpnForManagedUsers" addiert. Sie ist bei neueren Tenants sogar schon aktiv und kann bei länger bestehenden Tenants nachträglich aktiviert werden.
# AzureAD PowerShell Verbindung herstellen Connect-MsolService Set-MsolDirSyncFeature ` -Feature SynchronizeUpnForManagedUsers ` -Enable $True # Abfrage Get-MsolDirSyncFeatures | fl SynchronizeUpnForManagedUsers
- Get-MsolDirSyncFeatures
https://learn.microsoft.com/en-us/powershell/module/msonline/get-msoldirsyncfeatures?view=azureadps-1.0 - Set-MsolDirSyncFeature
https://learn.microsoft.com/en-us/powershell/module/msonline/set-msoldirsyncfeature?view=azureadps-1.0
Die Änderungen sind über das "Azure Active Directory Module for Windows PowerShell" (Mindestens Version 1.1.117.0.) zu pflegen. Dann setzt ADSync eine lokale Änderung des UPN auch in der Cloud um.
Das gilt nur für Änderungen im lokalen AD. Hatte ADSync die Werte schon übertragen und im Ziel konnte der UPN nicht gesetzt werden weil sie die Domain noch nicht angemeldet hatten, dann passiert da auch bei einem "Full Sync" nichts.
In dem Fall können Sie den UPN in der Cloud aber per PowerShell ändern, z.B. hier zum Setzen des UPN anhand der primären Mailadresse
Get-MsolUser | ` %{ ` Set-MsolUserPrincipalName ` -ObjectID $_.objectid ` -NewUserPrincipalName ($_.ProxyAddresses | where {$_.startswith("SMTP")}).substring(5) }
- Set-MsolUserPrincipalName
https://msdn.microsoft.com/en-us/library/azure/dn194135.aspx
Allerdings gibt noch eine andere Einschränkung, wenn Sie den UPN von einer Domain zur einer anderen Domain ändern:
- 2669550 Changes aren't synced by the Azure Active Directory Sync tool after you change the UPN of a User account to use a different federated domain
Es ist also weiterhin nicht möglich die UPN-Domain direkt von einer ADFS-Domain auf eine andere ADFS-Domain umzustellen.
Office 365 informiert den Administrator über den Fall per Mail mit der Fehlermeldung
Unable to update this object in Azure Active Directory, because the attribute [FederatedUser.UserPrincipalName], is not valid. Update the value in your local directory services.
- Microsoft Azure Active Directory
PowerShell Module Version Release History
http://social.technet.microsoft.com/wiki/contents/articles/28552.microsoft-azure-active-directory-powershell-module-version-release-history.aspx#Version_9031_1 - Azure AD Connect sync service features
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsyncservice-features/ - Set-MsolUserPrincipalName
https://msdn.microsoft.com/en-us/library/azure/dn194135.aspx - UPN Sync Changes in Azure AD
http://www.highclouder.com/upn-sync-changes-azure-ad/ - 2392130 Troubleshoot User name issues that occur for federated Users when they sign in to Office 365, Azure, or Intune
- 2523192 User names in Office 365, Azure, or Intune don't match the On-Premises UPN or alternate login ID
- A new version of the WAAD PowerShell
module brings support for “settings” for
Azure AD objects
http://www.michev.info/Blog/Post/154/A-new-version-of-the-WAAD-PowerShell-module-brings-support-for-%E2%80%9Csettings%E2%80%9D-for-Azure-AD-objects-
Domain nachträglich aktivieren
Gerade bei Migrationen mit dem Umzug einer DNS-Domain in einen anderen Tenant kann es zu der Konstellation kommen, dass der lokale AD-Benutzer zwar schon einem richtigen UPN hat und ADSync den auch in den neuen Tenant replizieren will, aber dort die UPN-Domain selbst im Tenant noch nicht aktiv ist. Die Cloud vergibt dann eine "onmicrosoft.com"-Adresse.
Allerdings "merkt" sich die Cloud im Hintergrund schon den eigentlich gewünschten UPN und ich habe bei T2T-Migrationen gesehen, dass in dem Moment der Domain-Registrierung bei allen Benutzer die "onmicrosoft.com"-Adresse abgeändert wird. Dazu ist ein weiterer ADSync-Lauf erforderlich.
- ADSync T2T-Migration
- Azure AD UserPrincipalName population
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-userprincipalname
Weitere Links
- Office 365:UPN / Anmeldename
- UPNChange und Applikationen
- 2643629 One or more objects don't sync when the Azure Active Directory Sync tool is used
- Set-MsolUserPrincipalName
https://msdn.microsoft.com/en-us/library/azure/dn194135.aspx - 2523192 User names in Office 365, Azure, or Intune don't match the On-Premises UPN or alternate login ID
- 2669550 Changes aren't synced by
the Azure Active Directory Sync tool after
you change the UPN of a User account to use
a different federated domain
https://support.microsoft.com/en-us/help/2669550/changes-aren-t-synced-by-the-azure-active-directory-sync-tool-after-yo