ADSync und RequireSenderAuthenticationEnabled

Diese Seite beschreibt die Zusammenhänge beim Empfang von Mails von intern und Anonym aus dem Internet anhand des Parameters "RequireSenderAuthenticationEnabled".

Zusammenhänge

Exchange unterscheidet zwischen "authentifizierten" und "nicht authentifizierten" Absendern. Wenn eine Mail an ihr Exchange System durch eine andere Mailbox eingeliefert wird, welche sich vorher erfolgreich authentifiziert hat, dann ist dies ein interner Absender. Dies gilt auch, wenn die Mail über einen Receive Connector eingeliefert wird und Exchange die Gegenseite anhand des Zertifikats erkennt und der Name als "Trusted" klassifiziert ist. Diese Variante ist beim Exchange Hybrid Mode wichtig, wenn Mails aus dem jeweils anderen System der gleichen Firma übertragen werden.

Mit dem Wissen können Sie als Administrator aber steuern, welcher Empfänger Mails nur von authentifizierten Absendern erhalten darf. Dazu gibt es bei den verschiedenen Objekten das Property "RequireSenderAuthenticationEnabled".

Objekt RequireSenderAuthenticationEnabled Beschreibung

Mailbox

$false

Bei einem Postfach ist der Default:$false natürlich sinnvoll, damit der Anwender auch Mails aus dem Internet empfangen kann.

Mailuser

$False

Dies gilt ebenso für einen MailUser. Dies ist oft ein Objekt, bei dem das AD-Konto von einem Mitarbeiter zur Anmeldung genutzt wird aber das Postfach auf einem anderen System, z.B. Notes, liegt und die Mail von Exchange aus dem Internet zwar angenommen aber dann direkt umgeleitet wird.

MailContact

NA

Ein MailContact ist aber in der Regel ein externer Empfänger, der nur im Adressbuch erscheint um von den legitimen Anwender genutzt zu werden. Hier gibt es aber die Einstellung gar nicht.

Distribution Group

$true

Im Gegensatz zu individuellen Adressen sind Verteiler per Default au "$true" gestellt, d.h. ie sind nur von authentifizierten Absendern erreichbar. So sind sie gegen Massenspam aus dem Internet immun. Sie können diese Einstellung aber individuell anpassen.

Ich bin dennoch kein Freund von Verteilern. Denken Sie besser über Microsoft 365 Group, Shared Mailboxes oder gleich ein CRM nach, um Kundenkommunikation an allgemeine Adressen zu verarbeiten.

RemoteMailbox

$false

Interessant ist, dass auch eine RemoteMailbox dieses Property hat. Das schauen wir uns gleich näher an.

Es gibt noch weitere Felder, mit dem Sie den Empfang noch auf einzelne Absender oder Mitgliedern von Verteilern beschränken können.

[PS] C:\>Get-RemoteMailbox aduser1 | fl *messages*,req*

AcceptMessagesOnlyFrom                 : {}
AcceptMessagesOnlyFromDLMembers        : {}
AcceptMessagesOnlyFromSendersOrMembers : {}
RejectMessagesFrom                     : {}
RejectMessagesFromDLMembers            : {}
RejectMessagesFromSendersOrMembers     : {}
RequireSenderAuthenticationEnabled     : True

Ich beschränke mich auf dieser Seite im weiteren auf das Feld "RequireSenderAuthenticationEnabled", welches auch bei einer Remote-Mailbox vorhanden ist. Die Einstellungen lassen sich per PowerShell aber auch per ECP wunderbar vornehmen und auslesen.

EntraID Sync

In Verbindung mit Exchange Online muss es eine Funktion geben, die solche Einstellungen vom lokalen AD in die Cloud replizieren. Dafür ist EntraID Sync zuständig. Dort gibt es die entsprechenden Regeln für Benutzer und Gruppen.

Set-RemoteMailbox <alias> RequireSenderAuthenticationEnabled:$rue

Wenn ich lokal bei einem Demo-Benutzer das Feld von "$False" auf "$true" stelle, dann sehen wir beim nächsten Synchronisierungslauf die Änderung:

Das ist so auch über die Regeln vorgegeben. Hier die Import-Rule für "In from AD - User Exchange".

Die vergleichbare Regel gibt es noch einmal als "Out to AAD - User ExchangeOnline". Es gibt aber keine Regeln, die das Feld aus Entra ID oder Exchange Online zurücklesen. Über die Exchange Online PowerShell kann ich in der Cloud nachschauen, dass das Feld auch entsprechend gesetzt wurde. Der Versuch dann eine Mail direkt an das Postfach zu senden wurde entsprechend mit einem NDR von Exchange Online quittiert:

550 5.7.134 RESOLVER.RST.SenderNotAuthenticatedForMailbox; 
   authentication required; 
   Delivery restriction check failed because the sender was not authenticated when sending to this mailbox

Soweit haben wir das erwartet.

Setzen in Exchange Online

Natürlich gibt es die gleichen Möglichkeiten auch in Exchange Online per Exchange Online PowerShell als auch per Exchange Admin Portal. Hier hat mich aber nicht der klassische "CloudOnly"-User einer kleinen Firma ohne Dirsync interessiert, sondern ein synchronisiertes Konto. Wir kennen alle die Fehlermeldung, wenn ich in Exchange Online z.B. die Mailadresse ändern möchte und dies von Exchange mit folgendem Fehler nicht zugelassen wird:

Error executing request. An Azure Active Directory call was made to keep object in sync 
  between Azure Active Directory and Exchange Online. However, it failed. 
  Detailed error message: Unable to update the specified properties for on-premises 
   mastered Directory Sync objects or objects currently undergoing migration. 
   DualWrite (Graph) RequestId: <guid> The issue may be transient and please retry a couple of minutes later.
   If issue persists, please see exception members for more information.

Nun habe ich aber auch versucht, die Authentifizierung in der Cloud zu setzen.

Das hat allerdings funktioniert!

Das ist schon etwas überraschend, da das Feld auch von ADSync verwaltet wird und es zumindest im Juli 2024 noch keine bidirektionale Synchronisation gibt.

Quasi die gleiche Funktion habe ich per Exchange Online PowerShell nachgestellt:

Sie sehen gut, dass das Ziel mein MSXFAQDEV-Tenant ist und Der User "ADUser1" per DirSync gegen überschreiben geschützt ist aber dies nicht alle Felder betrifft.

Die Details zu anderen Feldern muss ich noch mal nachstellen

Identity Konflikt

Wir haben aber gesehen, dass ich ein Feld sowohl im lokalen AD als auch in Exchange Online ändern kann. Im Juli 2024 hat ADSync aber immer nur "OneWay" synchronisiert. Also habe ich eine kleine Testserie gestartet.

Schritt Ergebnis

AD: Enable-RemoteMailbox + Sync

Ausgangspunkt war mein lokaler AD-Benutzer "ADUSER1" , welcher durch Entra ID Connect in einen MSXFAQDEV-Tenant repliziert wurde. Diesen Benutzer habe ich mit einer "Remote Mailbox" versehen.

Enable-RemoteMailbox `
   -identity aduser1 `
   -RemoteRoutingAddress aduser1@msxfaqdev.onmicrosoft.com

Danach habe ich ADSync seine Arbeit machen lassen.

Achten sie darauf, dass Entra ID Connect Sync auch das Exchange Schema kennt, da ansonsten das Feld gar nicht erst beachtet wird.

ADSync hat einige Änderungen übertragen aber  das waren viel zu wenig Einträge.

Das war mein Fehler, da das lokale AD meiner Test-Umgebung zwar durch die Installation der Exchange Management Tools zwar schon das Exchange Schema hatte aber ich danach noch noch einmal das ADSync-Setup zum Update der SyncRules genutzt habe.

Ich habe daher alles noch mal rückgängig gemacht.

AD: Enable-RemoteMailbox + Sync

Mit nun korrekter ADSync-Konfiguration habe ich den Benutzer erneut als RemoteMailbox aktiviert.  Ausgangspunkt war mein lokaler AD-Benutzer "ADUSER1" , welcher durch Entra ID Connect in einen MSXFAQDEV-Tenant repliziert wurde. Diesen Benutzer habe ich mit einer "Remote Mailbox" versehen.

Enable-RemoteMailbox `
   -identity aduser1 `
   -RemoteRoutingAddress aduser1@msxfaqdev.onmicrosoft.com

Start-ADSyncSyncCycle -PolicyType Delta

Danach habe ich ADSync erneut seine Arbeit machen lassen.

In der Cloud war der Benutzer aber erst ein "MailUser". Ich musste ihm erst einen Exchange Plan zuweisen, damit eine UserMailbox draus wurde.

Das habe ich nach dem Dirsync nachgeholt.

Diesmal hat ADSync deutlich mehr Properties übertragen:

Das Feld msExchRequireAuthToSendTo ist im lokalen AD noch nicht gesetzt und bleibt erst einmal leer. In der Cloud steht das Feld damit auf dem Defaultwert:$False:

AD: RequireSenderAuthenticationEnabled $true

Ich habe dann einmal "Wechselspiel" gespielt und das Feld "OnPremises" erst einmal auf "True" gesetzt.

Set-RemoteMailbox `
   -Identity aduser1 `
   -RequireSenderAuthenticationEnabled $true

Start-ADSyncSyncCycle -PolicyType Delta

Nach dem nächsten ADSync-Lauf war auch in Exchange Online das Feld auf "$True" gesetzt.

Das habe ich so erwartet und die Exchange Online PowerShell hat auch ein "True" geliefert:

EXO: -RequireSenderAuthenticationEnabled $false

Nun habe ich in Exchange Online das Feld auf $False gesetzt. Alle Administratoren hätten aufgrund aktivem Verzeichnisabgleichs eine Fehlermeldung erwartet.

Set-Mailbox `
   -Odentity aduser1 `
   -RequireSenderAuthenticationEnabled $false

Aber bei mir kam kein Fehler und ich konnte den Wert setzen und er war auch wirksam.

Weder beim "Delta Import" noch beim "Full Import" aus dem AzureAD wurde aber eine Änderung im Ziel erkannt und repliziert. Auch das habe ich erwartet, da ADSync ja quasi immer "vom AD zu AzureAD" arbeitet.

Auch ein Delta-Import aus dem AD hatte ja nichts zu importieren, da sich lokal nichts geändert hat.

Wir haben hier eine Inkonsistenz, dass in der Cloud und OnPremises unterschiedliche Einstellungen aktiv sind. Je nachdem, welcher Exchange Server zuerst die Mail routet, unterscheidet sich das Ergebnis

FullSync

Da keiner der beiden Imports etwas gefunden hat, habe ich ein Full Sync gestartet. Ich habe zwar schon geahnt, was passiert, oder besser nicht passiert aber ein Versuch war es wert.

Ich habe nicht erwartet, dass beim Import sich etwas ändert aber vielleicht würde der Export die inkonsistente Einstellung in Exchange Online wieder geraderücken? Aber auch das ist nicht passiert, denn es hat sich ja nichts geändert.

Die Inkonsistenz, dass in der Cloud und OnPremises unterschiedliche Einstellungen aktiv sind, überlegt auch einen "FullSync!

Doppel Änderung mit 2x Sync

Um die Cloud wieder anzupassen, habe ich die lokale Einstellung geändert, synchronisiert und wieder geändert.

Set-RemoteMailbox aduser1 -RequireSenderAuthenticationEnabled $false
Start-ADSyncSyncCycle -PolicyType delta
# warte Sync ab

Set-RemoteMailbox aduser1 -RequireSenderAuthenticationEnabled $true
Start-ADSyncSyncCycle -PolicyType Delta

Diese Eingriffe haben dazu geführt, dass ADSync die Werte in Exchange Online wieder mit den Einstellungen im lokalen Exchange in Übereinstimmung gebracht haben.

Beim ersten Ändern hat sich in der Cloud noch nichts getan, weil ich ja OnPrem den Wert gesetzt habe, der in Exchange Online eh schon manuell geändert wurde. Erst beim Zurückändern wurde dann die Cloud auch wieder auf den Wert korrigiert

Erkenntnis

Eigentlich wollte ich für einen Kunden nur ermitteln, welche Postfächer von extern anonym erreichbar sind und welche Postfächer nur für authentifizierte Absender erreichbar sind. Ein einfaches "Get-Mailbox/Get-Remotemailbox" mit der Identität und der Einstellung von RequireSenderAuthenticationEnabled in eine CSV-Datei hätte hier reichen können. Aber dann das erste Ticket, dass ein User nicht erreichbar war, obwohl die Exchange PowerShell gesagt hat, dass er hätte erreichbar sein müssen. Wurde eine Mail an den Exchange Online Server gesendet, dann wurde Sie angenommen, während eine Mail über den OnPremises Server abgelehnt wurde. Natürlich schauen wir beim Postfach in Exchange Online nach den Einstellungen und konnten nichts finden. Auf dem lokalen Exchange Server aber war im Message Tracking natürlich der NDR zusehen. So ist dann erstmalig aufgefallen, dass die Werte in Exchange OnPremises und Exchange Online unterschiedlich sind. Für mich bedeutet dies:

  • Bitte nie Felder in Exchange Online ändern
    Nicht alle Fehler sind gegen direkte Veränderungen in der Cloud durch das Exchange Admin Center oder die Exchange Online PowerShell geschützt. Welche das alles genau sind, ist Thema für eine eigene Seite.
  • Änderungen in der Cloud werden von ADSync nicht gesehen
    Weder beim "Delta Import" noch beim "Full Import" bemerkt ADSync, dass der Inhalt des Felds sich geändert hat. Damit können solche "Cloud Only"-Änderungen nicht detektiert und damit auch nicht Rückgängig gemacht werden
  • Kein "Repair" durch Full Sync
    Da sich in dem Fall auch im lokalen AD keine Properties geändert haben, wird ADSync weder bei einem "Full"- noch "Delta"-Sync die Informationen aus dem lokalen AD wieder in die Cloud schreiben. Die betroffenen Felder müssten sich ändern, damit ADSync diese neu repliziert

Es liegt also am Inhaber der entsprechenden Rollen, z.B. "Exchange Admin Rolle". "Recipient Management Rolle", dass Sie sich schon aus eigenem Interesse freundlich und korrekt verhalten und jegliche Änderungen immer nur im lokalen AD erfolgen.

Weitere Links