Hybrid SendAs

Es ist eine normale Anforderung, dass ein Exchange Benutzer auch eine Mail für einen anderen Anwender oder eine Shared-Mailbox versendet. Dazu gibt es das SendAs-Recht, welches im AD hinterlegt wird. Das Feld wird aber durch ADSync nicht in die Cloud übertragen. Hier ist Handarbeit angesagt.

Hybrid deployments between an On-Premises Exchange organization and Microsoft 365 or Office 365 support the Full Access and Send on Behalf delegated mailbox permissions. However, depending on the version of Exchange you have installed in your On-Premises organization, you might need to perform additional configuration to use delegated mailbox permissions in a hybrid deployment.
https://docs.microsoft.com/de-de/exchange/hybrid-deployment/set-up-delegated-mailbox-permissions#enable-acls-on-remote-mailboxes

Der Schwerpunkt dieser Seite ist "Send-As".

Informationen zu Stellvertretungen finden Sie auf Hybrid Delegate.

SendAs-Szenarien

Mit der Einrichtung von Exchange Hybrid und den ersten Postfächern in der Cloud gibt es vier Konstellationen.

Bei allen Konstellationen sollten Sie im Hinterkopf behalten, dass die Überprüfung durch die Exchange Instanz durchgeführt wird, auf der der aktive Benutzer arbeitet.

 In der weiteren Beschreibung nutze ich "Shared Mailbox" als Platthalter für das Postfach, mit dessen Mailadresse gesendet werden soll.

Shared Mailbox Anwender AD/Exchange Beschreibung
OnPrem OnPrem OnPrem

Diese Konstellation kennen wir seit vielen Jahren. Wir vergeben auf der lokalen Shared Mailbox die Berechtigungen für den Anwender. Die Einstellung wird im Active Directory im Security-Descriptor der Shared Mailbox gespeichert. Die SendAs-Rechte stehen aber nicht in der Mailbox sondern am AD-Objekt.

Add-ADPermission `
   -Identity SharedMailbox `
   -User Anwender `
   -AccessRights ExtendedRight `
   -ExtendedRights Send-As
Online OnPrem OnPrem

Wenn ein lokale Anwender "als Remote Shared Mailbox" sendet, dann verarbeitet der lokale Exchange Server die Mail. Der Anwender muss also das "SendAs" recht auf der lokalen "RemoteMailbox" haben.
OnPrem Online Online

Ein Exchange Online-User kann auch eine Mail als "OnPrem"-Postfach versenden. Hier verarbeitet aber Exchange Online die Mail und muss wissen, dass der Exchange Online Benutzer auch das Recht dazu hat. Dieses Recht wird z.B. mit Exchange 2010 nicht migriert und muss von Hand mit Add-RecipientPermission nachgetragen werden.
Online Online Online

Auch wenn beide Postfächer in Exchange Online sind, werden bei der Migration von Exchange On-Premises in die Cloud die Send-As Rechte nicht immer mitgenommen. Auch hier ist eine Nachkonfiguration mit Add-RecipientPermission erforderlich.

Die Funktion "Send-As" ist demnach sowohl in der Exchange Online Only-Welt als auch bei gemischten Postfächern nutzbar. Allerdings migriert der "Move-Request" die Postfachrechte aus dem MsExch-MailboxSecurityDescriptor aber nicht immer die am AD-Objekt hinterlegten SendAs und SendOnBehalf-Rechte.

Migration und Rechte

Die Probleme mit den Berechtigungen und die vier Fälle habe ich schon im vorigen Kapitel vorgestellt. Zur Klarstellung möchte ich zwei Fälle noch mal genauer beschreiben.

Ausgangssituation

Beide Postfächer sind On-Premises, d.h. die OnPremSharedMailbox, OnPremUserMailbox und die Rechte wurden vergeben mit

Add-ADpermission `
   -Identity OnPremSharedMailbox `
   -User OnPremUserMailbox `
   -ExtendedRights "Send As"
Der Benutzer wird in die Cloud verschoben

Das weiterhin lokal vorhandene Windows Konto hat auch weiterhin die Rechte "SendAs". Allerdings wird das Recht bei der Migration des Postfachs nicht in Exchange Online bei der Shared Mailbox addiert. Exchange Online prüft aber nun die Berechtigunge
Ergebnis

Der Benutzer in der Cloud kann das "SendAs"-Recht nicht ausüben
Lösung

Sie müssten dem Exchange Online Benutzer auch die "SendAs"-Rechte auf das Platzhalterobjekt für die OnPremShared Mailbox in der Cloud geben. Das geht auch mit

Add-RecipientPermission `
   -Identity <OnPremSharedMailboxID> `
   -Trustee <Migriertes Postfach> `
   -AccessRights "SendAs" `
   -Confirm:$false `
}

Sie können in der Cloud auf das Kontakt-Objekt der OnPremSharedMailbox Rechte vergeben. Dies wird nicht durch ADSync blockiert

Es kann natürlich noch den zweiten Fall geben:

Ausgangssituation

Beide Postfächer sind On-Premises, d.h. die OnPremSharedMailbox, OnPremUserMailbox und die Rechte wurden vergeben mit

Add-ADpermission `
   -Identity OnPremSharedMailbox `
   -User OnPremUserMailbox `
   -ExtendedRights "Send As"
Der SharedMailbox wird in die Cloud verschoben

In dem Fall bleibt das Benutzerpostfach samt Anmeldekonto im der lokalen Exchange-Umgebung aber das Postfach, in dessen Namen per "SendAs" gesendet werden soll, ist in der Cloud. Das AD-Recht bleibt erhalten.
Ergebnis

Der OnPremBenutzer kann das "SendAs"-Recht ausüben
Aber

Sie müssen in dem Fall noch nichts anpassen, aber wenn Sie die Mailbox selbst in die Cloud migrieren, dann könnte es sein, dass dann die CloudMailbox das SendAs-Recht nicht hat.

Dies ist das "Standard-Verhalten", wenn Sie nichts an der Konfiguration ändern. Das Problem gilt natürlich auch für Verteilergruppen, die zwar auf beiden Seiten vorhanden sind aber bei der Migration der SharedMailbox werden die Berechtigungen nicht angepasst.

ACLableSyncedObjectEnabled

Aber natürlich ist dieses Problem auch Microsoft aufgefallen. Allerdings hat Exchange 2007/2010 noch keine Lösung dafür gehabt und Selbst Exchange 2013/2016 haben erste durch ein CU-Update diese Funktion erhalten.

  • Exchange 2010 SP3 RU?
  • Exchange 2013 CU10
  • Exchange 2016 RTM
  • Aktueller ADSync (Eine Minimalversion habe ich nicht ermittelt)

Diese "Updates" sind schon sehr alt und aus Support-Gründen sollten sie immer das aktuellste oder vorherige RU/CU installiert haben. Damit ist es aber nicht getan, denn Sie müssen noch eine Konfiguration On-Premises vornehmen:

Set-OrganizationConfig `
   -ACLableSyncedObjectEnabled $True

Hier seht aber auch:

Anschließend werden alle Postfächer, die Sie zu Microsoft 365 oder Office 365 verschieben, ordnungsgemäß für die Unterstützung Delegierter Postfachberechtigungen konfiguriert. Wenn Postfächer vor dem Ausführen dieser Schritte nach Microsoft 365 oder Office 365 verschoben wurden, müssen Sie die ACLs für diese Postfächer manuell aktivieren
Quelle: https://docs.microsoft.com/de-de/exchange/hybrid-deployment/set-up-delegated-mailbox-permissions

Das erfolgt auch für Send on Behalf.

Send on Behalf: A mailbox on an On-Premises Exchange server can be granted the Send on Behalf permission to a Microsoft 365 or Office 365 mailbox, and vice versa. For example, a Microsoft 365 or Office 365 mailbox can be granted the Send on Behalf permission to an On-Premises shared mailbox. Users need to open the mailbox using the Outlook desktop client; cross-premises mailbox permissions aren't supported in Outlook on the web.
Quelle: https://docs.microsoft.com/en-us/exchange/permissions

Beides sind Berechtigungen, die im Feld "msexchMailboxSecurityDescriptor" stehen und damit von ADSync gelesen werden können. Damit sind Sie aber noch nicht fertig, denn ADSync prüft noch ein Feld ab, ehe es das "SendOnBehalf/Stellvertreter"-Recht repliziert. ADSync überträgt die Daten nur für "Remote"-Objekte, sie sich im lokalen Active Directory derart auszeichnen, dass das Feld "msExchRecipientDisplayType" den Wert -"1073741818" hat

Bei allen Objekte, die vorher verschoben wurden, hat das Feld einen anderen Wert. Daher müssen Sie einmal im lokalen Active Directory noch den Wert anpassen. Eine PowerShell macht das recht einfach:

Get-RemoteMailbox `
| ForEach { `
     Get-AdUser `
        -Identity $_.Guid `
     | Set-ADObject -Replace @{msExchRecipientDisplayType=-1073741818}`
}

SendAs und ADSync?

ADSync liest aktuell nicht die SendAs"-Rechte aus, die ja nicht im Feld "msexchMailboxSecurityDescriptor" sondern in der ACL des AD-Objekts selbst stehen. ADSync könnte das sicherlich auslesen aber er tut es nicht. Die Aussage von Microsoft ist da auch deutlich.

Send As: Lets a user send mail as though it appears to be coming from another user's mailbox. Azure AD Connect doesn't automatically synchronize Send As permission between On-Premises Exchange and Microsoft 365 or Office 365, so cross-premises Send As permissions aren't supported. However, Send As will work in most scenarios if you manually add the Send As permissions in both environments.
Quelle: https://docs.microsoft.com/en-us/exchange/permissions

Microsoft beschreibt auf der Seite nur die beiden PowerShell-Befehle, mit denen Sie die Rechts im lokalen Exchange bzw. Exchange Online setzen können:

# Eintragen des lokalen Anwender auf einer RemoteMailbox
Add-ADPermission `
   -Identity RemoteMailbox `
   -User ONPREM1 `
   -AccessRights ExtendedRight `
   -ExtendedRights "Send As"

# Eintragen eines Exchange Online Anwender auf eine lokale Mailbox
Add-RecipientPermission `
   -Identity OnPremMailbox `
   -Trustee CloudUserMailbox `
   -AccessRights SendAs

SendAs-Rechte kopieren

Damit ist natürlich klar, was nun kommt. Wenn die Exchange Migration die SendAs-Rechte nicht mitnimmt, dann sollte der Administrator diese Rechte möglichst per Skript übernehmen. Eine manuelle Pflege ist bei kleinen Umgebungen denkbar oder wenn eh "Aufräumen" angesagt ist. Allerdings artet das sehr schnell in "Arbeit" aus und ist fehleranfällig. Für den Export müssen wir zwei Commandlets miteinander verknüpfen:

  • Get-Mailbox
    Damit bekommen wir alle Postfächer aufgelistet
  • Get-ADPermission
    Damit lesen wir dann die Rechte des Postfach aus dem Active Directory aus

Ganz so einfach ist es natürlich nicht, denn die Umgebung kann durchaus Überraschungen enthalten. Mit Get-ADPermission bekommen wir alle AD-Rechte und müssen auf "SendAs" filtern. Zudem können auch andere Objekte, z.B. Verteilergruppen, berechtigt sein, die sich so in Exchange Online vielleicht nicht wiederfinden. Dann könnten Sie die Mitglieder der Gruppen, ggfls. sogar rekursiv, auflösen.

Mein Skript hier ist "einfach" gestrickt und besteht aus zwei Teilen.

  • Export der "SendAs"-Rechts aus dem lokalen Exchange in eine CSV-Datei
  • Setzen der Rechte in Exchange Online anhand der CSV-Datei

Beide Skripte arbeiten mit Mailadressen der Postfächer und berechtigten Objekte. Wer z.B. SendAs über eine Gruppe vergibt, die nicht Mailaktiviert ist, hat hier einen blinden Fleck. Ebenfalls erfassen die Skripte nicht ein SendAs als Public Folder oder Mailverteiler, sondern nur Postfächer. Es entfernt auch keine Rechte im Ziel, wenn diese in der Quelle nicht mehr vorhanden ist.

Es ist also kein kompletter "Sync" und Fehlerbehandlung u.a. gibt es auch nicht. Starten Sie die Skripte als Admin interaktiv und kontrollieren Sie, was passiert.

Genau genommen müssten sie das Skript sogar noch in die Gegenrichtung schreiben, wenn Administratoren auch in Exchange Online die "SendAs" Rechte vergeben. Zum Glück "merken" die Anwender sehr schnell, wenn Sie das Recht nicht haben und sie könnten es dann auch manuell nachtragen.

Der erste Schritt ist der Export per PowerShell in einer lokalen On-Premises Exchange Powershell.

Hybrid_Sendas_Export.ps1

Das Skript erzeugt im aktuellen Verzeichnis eine CSV-Datei, in der alle Postfächer und RemotePostfächer und die SendAs-Berechtigungen enthalten sind.

Hinweis: Die Auswertung kann sehr lange dauern, da nicht nur die Postfächer geladen, sondern auch die AD-Berechtigungen aufgellöst und das dazugehörige Postfach gefunden werden muss. Bei sehr großen Umgebungen wäre eine Hashtable sinnvoll, um Zeit zu sparen, wenn Benutzer in vielen Postfächern berechtigt sind.

Das Format selbst ist unspektakulär.

"MailboxEmail","MailboxName","SendAsUser","SendAsUserMail"
"user1@msxfaq.de","User1","User4","user4@msxfaq.de"
"user1@msxfaq.de","User1","User5","user5@msxfaq.de"
"user2@msxfaq.de","User2","User4","user4@msxfaq.de"
"user3@msxfaq.de","User3","User5","user5@msxfaq.de"

Diese Datei kann dann im zweiten Skript genutzt werden, um die Rechte in Exchange Online zu übertragen.

Das Skript ist deutlich kürzer und könnte genau genommen auch in einem Einzeiler verpackt werden. Sie müssen eine PowerShell starten und sich darin mit Exchange Online verbinden. Den Code dazu habe ich nicht auch noch in das Skript gepackt.

Und dann starten Sie das Skript, welches die beim Export angelegte CSV-Datei einliest und die Rechte stumpf addiert.

Hybrid_SendAs_Import.ps1

Natürlich kann es passieren, dass die Rechte schon vorhanden sind und das Skript dann eine Fehler/Warnung generiert. Das Skript hat aktuell keinen Code, um diese Fehler abzufangen und auszuwerten oder vorab die Rechte zu lesen und nur fehlende Berechtigungen zu addieren. Es kann auch keine Berechtigungen entfernen, die in der CSV-Datei nicht mehr vorhanden sind.

Das Skript ist absichtlich einfach gehalten und primäre zum Korrigieren von fehlenden Berechtigungen gedacht, die nicht bei der Migration oder dem Provisioning umgesetzt wurden.

Zukunft

Ich bin kein Hellseher aber mein Skript hat durchaus einige Einschränkungen, die eine "richtige" Lösung nicht haben sollte, z.B.

  • Langsam
    Der Export der "SendAs"-Rechte per PowerShell ist sehr langsam. mit ca. 1-2 Sek/Postfach skaliert dies nicht gut. Eine richtige Lösung sollte entweder eine andere API nutzen, Ergebnisse cachen oder gleich auf "Delta-Abfragen" gehen, d.h. nur die Objekte auswerten, die sich seit dem letzten Lauf geändert haben.
  • Bidirektional
    Sicher ist es ein Anfang die SendAs-recht von der On-Premises Installation in die Cloud zu portieren. Solche Rechte können aber auch in Exchange Online vergeben werden und müssten dann natürlich auch im lokalen Exchange Server nachgepflegt werden.
  • Lösch-Funktion
    Aktuell addiert das Skript nur Berechtigungen aber erkennt nicht, wenn ein SendAs-Recht entfernt wurde. Damit behält ein Benutzer in der Cloud das Recht, obwohl er es lokal schon nicht mehr hat. Um dies zu erkennen, müsste man Änderungen durch einen Vergleich mit einer früheren Kopie erkennen und umsetzen.

Ich erwarte nicht, dass die Migrations-Komponenten von Exchange (MRS) so eine Logik einbaut, zumal sie ja nur bei der Migration selbst aktiviert wird. Änderungen bei "SendAs" stehen aber in der ACL des AD-Objekt und nicht in einer Mailbox oder dem Feld msexchmailboxsecuritydescriptor.

Aber auch ADSync wird seine Probleme damit haben, wenn er nicht nur die LDAP-Felder sondern nun auch noch die ACLs des AD-Objekte lesen, auseinandernehmen und über das Metaverse in die Cloud übertragen muss. Auch die Gegenrichtung, d.h. düe Übertragungen von SendAs-Änderungen aus der Cloud in das lokale Exchange ist eine Herausforderung.

Aus diesen Gründen erwarte ich keine Erweiterung von ADSync sondern Microsoft dürfte darauf hoffen, dass es nicht viele Objekte betrifft, die dann ein Admin auch manuell pflegen kann und über kurz oder lang es eh immer weniger lokale Exchange Postfächer mehr gibt.

Weitere Links