Cloud ProxyAddresses

Die Bedeutung des Felds "ProxyAddresses" im lokalen Active Directory sollten zumindest die meisten Exchange Administratoren auswendig kennen. Aber mit Blick auf die Cloud gibt es noch die ein oder andere Überraschung zu entdecken.

Beachten Sie dazu auch die Seite ADSync und MailUser

Microsoft Definition

Zuerst habe ich eine sehr umfangreiche Quelle von Microsoft.

The proxyAddresses attribute in Active Directory is a multi-value property that can contain various known address entries. For example, it can contain SMTP addresses, X500 addresses, SIP addresses, and so on. When an object is synchronized to Azure AD, the values that are specified in the proxyAddresses attribute in Active Directory are compared with Azure AD rules, and then the proxyAddresses attribute is populated in Azure AD. Therefore, the values of the proxyAddresses attribute for the object in Active Directory may not be the same as the values of the proxyAddresses attribute in Azure AD.
Quelle: How the proxyAddresses attribute is populated in Azure AD https://docs.microsoft.com/en-us/troubleshoot/azure/active-directory/proxyaddresses-attribute-populate

Damit könnte die Seite schon wieder zu Ende sein. Aber auch wenn die Quelle sogar noch einige Fragen und deren Antworten liefert, gibt es weitere Details, die Microsoft noch nicht beschrieben hat.

Anzeige

Ich starte einfach mit einem Microsoft 365 Tenant, in dem ein Benutzer mit einer Microsoft 365 E3-Lizenz versehen ist. Er hat damit nicht nur ein Exchange Postfach sondern auch Teams, OneDrive und anderen Dienste.

Ich habe die Teste auch mit einem Benutzer nachvollzogen, der nur eine Exchange Online P1-Lizenz hatte und kein OneDrive/SharePoint oder Teams. Es wurden dennoch SPO und SIP-Adressen angelegt.

Ich kann über zwei Admin-Portale und zwei PowerShell-Module die ProxyAddresses anzeigen. Aber schon da finde ich ersten interessanten Unterschiede:

  • Exchange Admin Portal
    Ein Mailbox-Benutzer in der Cloud muss natürlich Exchange Lizenz haben, so dass ich ihn im Exchange Admin Portal auch sehen und editieren könnte. das gilt nicht für Kontakte oder On-Premises Mailboxen.
  • Exchange PowerShell
    Es sollte nicht weiter verwundern, dass auch die Exchange Online PowerShell die gleichen Daten liefert:
PS C:\> Get-Mailbox aduser2 | fl identity,emailaddresses

Identity       : ADUser2
EmailAddresses : {SMTP:ADUser2@carius.onmicrosoft.com, smtp:ADUser2@carius.de,
                 SIP:df30efefafe7421ab577e3be83171d1eaduser2@carius.de,
                 SPO:SPO_9962499f-eb60-4c27-9402-cd438f673854@SPO_eef62a09-7718-4063-82db-d7582dc8916f}
  • Azure Admin Portal
    Die ProxyAdressen sind beim Benutzer "ReadOnly" und nur zum Teil sichtbar. Ich sehe nur die SMTP-Adressen und die sind auch noch "ReadOnly"

    Die SIP-Adresse ist nicht bei den Proxyaddres sichtbar sondern bei IM-Address
  • AzureAD PowerShell
    Hier sehe ich auch nur die SMTP-Adressen, die mir das Portal liefert.
PS C:\> Get-AzureADUser -SearchString aduser2 | fl userprincipalname,proxy*

UserPrincipalName : ADUser2@carius.de
ProxyAddresses    : {smtp:ADUser2@carius.de, SMTP:ADUser2@carius.onmicrosoft.com}

Hier halten wir schon einmal fest, dass das AzureAD für diese Feld nicht autoritativ ist, sondern Exchange Online den Inhalt bestimmt. Zudem sind die Werte für SIP und SPO schon einmal sehr zufällig.

Der Benutzer ADUser2 hatte zu dem Zeitpunkt nur eine Exchange Online Plan1 Lizenz aus einem Teams Exploratory License aber weder eine Skype for Business Lizenz, noch Teams Lizenz noch OneDrive.

Dennoch hat die Cloud auch SIP und SPO-Adressen addiert.

Adresstypen

Die meisten Administratoren werden die Prefixe SMTP und "smtp" kennen. Auch SIP und SPO sind nun bekannt, Aber es gibt durchaus weitere Einträge die auch in der Cloud vorkommen können.

Beachten Sie, dass Einträge durchaus mehrfach vorkommen können aber nur ein Eintrag darf "GROSS" geschrieben sein. Das ist die primäre Adresse, mit der eine ausgehende Kommunikation gestartet wird. Es gibt Einträge wie z.B. .SIP, die nur genau einmal vorkommen dürfen.

Prefix Multivalue Bedeutung

SMTP

Ja

Diese Feld enthält alle Mailadressen, unter denen ein Anwender erreichbar ist. Die Werte müssen eindeutig sein, d.h. es darf diese nicht doppelt geben.

Bei einer Zeile muss das Prefix "Uppercase" sein, damit Exchange Online weiß, welche Quelladresse er nutzen soll.

Postfächer können nur Adressen mit im Tenant registrierten Domains haben. Nur MailContacts und MailUser können auch externe Adressen bekommen.

SPO

Nein

Diese Adresse ist wohl der Anker zur SharePoint Identität.

SIP

Nein

Die Adresse wurde Anfangs nur durch Skype for Business genutzt, damit Outlook und der SfB Client zueinander gefunden haben. Für das SIP-Routing war On-Premises schon immer das Feld "msRTCSIP-PrimaryUserAddress" maßgeblich.

If the ProxyAddresses attribute contains a sip address, also update that value as a best practice. Although the sip address in ProxyAddresses is ignored by O365 if msRTCSIP-PrimaryUserAddress is populated, , it may be used by other On-Premises components.
Quelle: Decide how to manage attributes after decommissioning
https://docs.microsoft.com/en-us/skypeforbusiness/hybrid/cloud-consolidation-managing-attributes#method-1---manage-sip-addresses-and-phone-numbers-for-users-in-active-directory

Auch wenn Sie heute kein Skype for Business Online mehr nutzen können (Siehe SfBOnline Ende), so ist die Adresse weiterhin wichtig für die Federation mit anderen Firmen oder der eigenen On-Premises-Umgebung.

X500

Ja

X.500 Adressen sind verkappte "LegacyExchangeDN"-Adressen, die früher zum Routing genutzt wurden. Über den Weg können alte Adressen weiterhin erreichbar bleiben, wenn Anwender in andere Exchange Umgebungen migriert werden. Schon durch die Migration von Exchange On-Premises zur Cloud erhalten Sie diese Adressen.

EUM

Ja

Diese Adressen sind meist "Altlasten" einer Exchange Unified Messaging-Konfiguration, die mit Exchange 2010-2016 nutzbar war. Mittlerweile sollten diese Adresse keine Funktion mehr haben.

JRNL

?

Bei einigen Objekten habe ich diesen Adresstyp gefunden. Der Inhalt war die Mailadresse des Benutzers. Ich vermute einen Zusammenhang mit Journalfunktionen.

Ich schreibe nicht, dass das alle Adresse-Typen gibt. On-Premises können Sie auch noch "MSMAIL:" ,"CCMAIL:", "GWISE", "FAX:" und andere Felder haben. Aber nicht alles, was ADSync ausliest und in die Cloud sendet, wird dort auch angenommen.

ADSync Merge

Ich habe mit einem Cloud-Objekt angefangen, welches durch ADSync verwaltet wird aber lokal keine Einträge im Feld "ProxyAddresses" hat. Das Objekt selbst wird aber durch den AzureAD Cloud Sync verwaltet. Wir haben auch schon beschrieben, dass ich das Feld nicht direkt im AzureAD schreiben kann aber die Verwaltung mit Exchange nur in Verbindung mit einer Lizenz möglich ist. Aber ich kann ja das Feld im lokalen AD setzen und den DirSync die Arbeit machen lassen:

Also habe ich mit ADSIEDIT die Felder gesetzt.

Achtung: Dies ist nicht der Regelfall. Wenn Sie Exchange On-Premises nutzen, dann sind diese Felder lokal schon gepflegt.

In meinem Beispiel addiere ich aber nun einfach eine eigene SIP-Adresse und weitere SMTP-Adressen und lasse mich überraschen, was passiert.

Nun musste ich nur den nächsten Lauf von AzureAD Cloud Sync abwarten und die Ergebnisse anschauen. Es gab erst einmal keine Warnungen oder Fehler in den Protokollen und im AzureAD sind folgende Adressen angekommen. Sie können sehen, dass nicht alle ProxyAddresses übertragen wurden sondern nur die SMTP-Adresse mit der carius.de-Domain. Sie wurde aber sogar als primäre Adresse gesetzt und die früher führende carius.onmicrosoft.com-Adresse wurde sekundär.

Die SIP, SPO oder MSXFAQ-Adresse wird aber im AzureAD nicht angezeigt oder eingetragen.

Wichtige Aussage: Exchange Online übernimmt für Benutzer mit einer Exchange Lizenz nur die Mailadressen, deren Domain auch im Tenant registriert ist. Das gilt nicht für Kontakte ohne Lizenz

Interessanter ist hier aber die Liste der Adressen im Exchange Online Directory. Wie Sie auf der Seite "Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr" lesen können, gibt es in der Cloud mehrere Verzeichnisdienste und für die ProxyAddresses ist nun mal Exchange Online zuständig.

Hier sehen Sie auch die geänderte primäre SMTP-Adresse aber zusätzlich wurde die SIP-Adresse ersetzt. Die alte kryptische SIP-Adresse ist verschwunden aber die SPO-Adresse wurde nicht überschrieben. Das lässt Rückschlüsse auf die Funktionsweise des Verzeichnisabgleichs und die Bedeutung der ProxyAddresses zu:

  • SMTP:
    Wenn aus dem lokalen AD eine neue primäre Adresse kommt, wird diese dominant. Allerdings werden nur Adressen übernommen, die im Tenant auch als gültige DNS-Domain registriert sind.
  • SIP
    Es kann anscheinend nur genau eine SIP-Adresse geben und ein Eintrag aus dem lokalen AD überstimmt die Cloud
  • SPO
    Die SharePoint-Adresse wird wohl nur in der Cloud verwaltet und kann nicht durch einen Eintrag im lokalen AD überstimmt werden
  • MSXFAQ und andere Custom Typen
    Werden in der Cloud einfach ignoriert.

Der Versuch, diese Werte in der Cloud mit der Exchange Online PowerShell manuell zu ändern wird natürlich durch den DirSync unterbunden.

ADSync kein Backsync

In meinem Testlab war nun nicht der ADSync im Einsatz sondern die Cloud-Variante und die schreibt aktuell keine Daten in das lokale AD zurück. Insofern wurden die neuen ProxyAddresses aus der Cloud nicht in das lokale AD zurückgeschrieben. Mit dem richtigen ADSync ist dies aber der Fall, wie ich auf ADSync Bidirektional schon beschrieben habe. ADSync schreibt nicht nur ein paar Felder zurück, die für die Spamfilterung relevant sind, sondern auch die ProxyAddresses.

Wenn Sie den klassischen ADSync nutzen, dann hängt es von der Einstellung "Exchange Hybrid" ab, was zurückrepliziert wird. Ohne aktivierte "Exchange Hybrid"-Einstellung ist es ein OneWay-Ticket, d.h. Proxy-Adressen aus der lokalen AD-Umgebung werden in die Cloud repliziert aber nicht zurück. Es kann durchaus passieren dass Microsoft 365 eine Benutzer in der Cloud zusätzliche Adressen vergibt, die dann nicht ins lokale AD zurück kommen. Auf der Seite ADSync und MailUser habe ich dazu einige Fälle gesehen, bei denen ein MailUser in der Cloud zusätzliche Adressen bekommen hat, die aber nur partiell ins lokale AD geschrieben wurden, Hier nur ein Auszug

On-Premises AzureAD

Ich habe bei der Neuanlage nur den MailUser angelegt. ADSync hat den Kontakt im AzureAD und Exchange Online angelegt. Die Microsoft Cloud hat aber selbständig drei weitere Adressen addiert. Bei der nächsten ADSync-Replikation wurde aber NUR die X500-Adresse in das lokale AD übertragen. Schon beim Export aus der Cloud mit ADSync kommen die zusätzlichen SMTP-Adressen eines MailUser nicht mit.

Wichtig: Diese Verhalten unterscheidet sich von dem Verhalten bei Postfächern (Mailbox/RemoteMailbox). Dort werden auch SMTP-Adressen übertragen

ADSync Remove

Natürlich habe ich dann im lokalen AD das Feld "Proxy-Adresse" wieder geleert und etwas gewartet. Im AzureAD Auditlog für das Konto ADUser2 habe ich dann die Änderungen gesehen:

Das Leeren des Felds ProxyAddresses im lokalen AD hat in der Cloud nicht alle Felder entfernt. Die vorher hinzugefügte primäre On-Premises-Adresse wurde entfernt aber nun wurde nicht mehr die carius.onmicrosoft.com-Adresse wieder hergestellt, sondern die Adresse der carius.de-Domain. Das sehe ich auch in der PowerShell.

PS C:\> Get-AzureADUser -SearchString aduser2 | fl userprincipalname,proxy*

UserPrincipalName : ADUser2@carius.de
ProxyAddresses    : {SMTP:ADUser2@carius.de, smtp:ADUser2@carius.onmicrosoft.com}
PS C:\> Get-Mailbox aduser2 | fl identity,emailaddresses

Identity       : ADUser2
EmailAddresses : {SIP:df30efefafe7421ab577e3be83171d1eaduser2onprem@carius.de, SMTP:ADUser2@carius.de,
                 smtp:ADUser2@carius.onmicrosoft.com,
                 SPO:SPO_9962499f-eb60-4c27-9402-cd438f673854@SPO_eef62a09-7718-4063-82db-d7582dc8916f}

ADSync und MailUser

Auch beim Einsatz von MailUsern gibt es einige besondere Effekte, die ich aber auf der eigenen Seite ADSync und MailUser beschrieben habe.

Bewertung

Das Feld "ProxyAddresses" hat nicht nur in Exchange On-Premises sondern auch in der Cloud eine besondere Bedeutung. Der Inhalt ist, warum auch immer, nur teilweise im AzureAD vorhanden und dort generell nicht änderbar. Die einzige editierbare Instanz in der Cloud ist das Exchange Online Verzeichnis. Objekte, die aber durch ADSync / AADConnect oder AzureAD Cloud Sync von einem lokalen Active Directory abgeglichen werden, sind für den Cloud Admin aber ReadOnly. Das hindert die Cloud selbst aber nicht daran, das Feld ebenfalls zu ändern. Diese Daten werden aber nicht ins lokale AD zurückgeschrieben.

So bekommen jeder Cloud-Anwender auch immer eine SIP und SPO-Adresse, selbst wenn er keine Lizenz für Skype for Business oder SharePoint bekommen hat. Zumindest die SIP-Adresse wird durch ADSync überschrieben, wenn es im lokalen AD einen passenden Eintrag gibt. Von der SPO-Adresse sollten Sie als Administrator aber die Finger weg lassen. Die wichtigste Funktion ist allerdings weiterhin, dass Exchange Online eingehende Mails anhand der SMTP-Adresse zustellen kann.

Weitere Links