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.

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 OnPremise 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 "SourceAncor", der auf der ObjectGUID des OnPremise-Objects basiert.

UPN-Change

Interessant wird es dann, wenn ich den UPN "OnPremise" 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 "Changes" 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.

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.

Hier könnte eine Überwachung auf UPN-Changes oder Diskrepanzen zwischen OnPremise 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

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. Allerdings gibt es immer noch eine Einschränkung:

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

Weitere Links

  • Office 365:UPN / Anmeldename
  • 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