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

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

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

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.

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.

Weitere Links