06.01.2021

3760

Exchange - senden im Auftrag von

Hallo zusammen,

wünsche Euch allen ein frohes neues Jahr und einen erfolgreichen Start!

Ich habe eine Frage zur folgender Angelegenheit (Idee vorhanden, aber weiß nicht, ob es der beste Weg wäre)
Es handelt sich um einen Exchange Server 2016 mit aktuellster CU.

Ich habe eine Anwendung X. In dieser Anwendung trage ich die SMTP Einstellungen von einem AD-Benutzer ein (nennen wir den mal "user1", es existiert auch ein Benutzerpostfach dazu). Dieser "user1" soll im Auftrag von allen vorhandenen Benutzerpostfächer E-Mails senden dürfen.

Reicht es, wenn ich bei jedem Userpostfach diesen "user1" unter "senden im Auftrag von" hinzufüge? Oder gibt es einen besseren Weg? Das Problem sehe ich dabei (ja, ich könnte/müsste/würde Skripten), dass bei neuen Postfächern diese Regelung immer angewendet wird. Letztlich soll es für alle User-Postfächer gelten.

Für Ideen und Kritik bin ich offen.
Vielen Dank.
Gruß..scar

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 638194

Url: https://administrator.de/contentid/638194

Ausgedruckt am: 25.11.2024 um 08:11 Uhr

19 Kommentare

Neuester Kommentar

Moin @scar71

was soll es denn bringen, wenn dieser User im Auftrag der anderen senden darf?
Wenn du in der Software diesen Benutzer "User1" einträgst, wird sicherlich auch dieser Benutzer senden und nicht "User1 im Auftrag von Max Mustermann" oder wie macht das die Software?

Zitat von @scar71:
Das Problem sehe ich dabei (ja, ich könnte/müsste/würde Skripten), dass bei neuen Postfächern diese Regelung immer angewendet wird. Letztlich soll es für alle User-Postfächer gelten.

Och Problem ist das keins, dafür gäbe es z.B. die Powershell ...

$userDN = 'CN=Max Muster,CN=Users,DC=domain,DC=tld'  
Get-Mailbox -RecipientTypeDetails UserMailbox | ?{$_.GrantSendOnBehalfTo.DistinguishedName -notcontains $userDN -and $_.DistinguishedName -ne $userDN} | Set-Mailbox -GrantSendOnBehalfTo @{Add=$userDN} -Force

ja, wie erwähnt. Hätte/Könnte ich scripten, du hast es bereits serviert. Hätte ich mit meinen PS Skripten auch noch hingekriegt^^.
Jedoch, vielen lieben Dank für deine Mühe.

Überlicherweise macht man das bei solchen Applikationen die im Auftrag für alle User arbeiten mit einem Service-Account über RBAC zugewiesene "ApplicationImpersonation Rechte" am Exchange, der hat dann automatisch alle entsprechenden Rechte in allen oder spezifiziertem Scope, auch in denen die neu hinzukommen.
Configure impersonation
Den Service-Account sollte man aber gut absichern und beschränken sonst baut mach sich damit ein potentielles Einfallstor.

vielen Dank für das Feedback - das würde ich erstmal bei Seite tuen, mich interessiert es grundsätzlich, ob der beschriebene Weg für ein solches Vorhaben so OK ist?
Vielleicht gibt es noch eine andere Möglichkeit, welche ich noch nicht kenne.

Danke für das Keyword RBAC! Da war ich aktuell am einlesen - i.d.R. funktionieren Archivierungssysteme ebenso per Impersonation (korrigiere mich,wenn ich falsch liege).
Kannst du für mich zum Verständnis den techn. Ablauf kurz beschreiben, wie es aussehen würde?

Ich habe bereits eins angelegt, hat die Rolle ApplicationImpersonation und ist dem User1 bereits zugewiesen.

Zitat von @scar71:

Danke für das Keyword RBAC! Da war ich aktuell am einlesen - i.d.R. funktionieren Archivierungssysteme ebenso per Impersonation (korrigiere mich,wenn ich falsch liege).

Richtig.

Kannst du für mich zum Verständnis den techn. Ablauf kurz beschreiben, wie es aussehen würde?

Erstelle neuen RBAC, mit der Rolle Impersonation und weise dort dem user1 (Dienstuser, mit einem vernünftigen Passwort). Wie sehe der weitere Verlauf aus?

Das übliche Prozedere für solche Service-Accounts wie unter anderem das Einschränken der Nutzung des Accounts auf die Maschine welche die Applikation betreibt usw.

Hallo,
habe nun ApplicationImpersonation getestet, leider funktioniert es noch nicht.
Wenn ich die "send_As" Berechtigung manuell vergebe, klappt es.
Aktuelle Konstellation:

AD Security Group (universal) -> Mailsender (ist eine Mail-enabled AD Gruppe, das gleiche Spielchen auch schon mit einem Verteiler getestet)
Management Scope erstellt, welche sich auf die AD Gruppe bezieht

New-ManagementScope -Name "Scope_Mailabsender" -RecipientRestrictionFilter {MemberOfGroup -eq "CN=Mailsender,OU=X,OU=Y,DC=domainname,DC=local"}  

dann RoleAsignment durchgeführt

New-ManagementRoleAssignment -Name:"Role_Mailversand" -Role:ApplicationImpersonation -CustomRecipientWriteScope:"Scope_Mailabsender" -User:"username@domain.com"   

Leider erhalte ich die Meldung "550 5.7.60 SMTP; Client does not have permissions to send as this sender"

Wo ist der Fehler?

keiner ne Idee?

Wo ist der Fehler?

Der Fehler liegt darin das du auch per "Impersonation" am EX authentifizieren musst, also z.B. die entsprechenden EWS Methoden dafür nutzt.
http://blog.icewolf.ch/archive/2012/07/15/ews-managed-api-demo-imperson ...
Die Applikation meldet sich quasi per Impersonation an der jeweiligen Mailbox an und kann dann in diesem Kontext arbeiten ob nun versenden oder Daten aus der Mailbox abfragen, quasi alles was der jewelige User sonst nur selbst machen kann.

Gruß jokari

habe ich bereits erfolgreich mit https://testconnectivity.microsoft.com/tests/EwsAccess/input getestet.

Scheinbar funktioniert der Imperso Zugriff mit IMPERSUSER auf ZIELPOSTFACH@domain.com

mit dem Tool SMTP Diag Tool erhalte ich nach wie vor die Meldung: .
550 5.7.60 SMTP; Client does not have permissions to send as this sender
Error: SMTP protocol error. 550 5.7.60 SMTP; Client does not have permissions to send as this sender.
Failed to send messageForcing disconnection from SMTP server.)

Zitat von @scar71:

habe ich bereits erfolgreich mit https://testconnectivity.microsoft.com/tests/EwsAccess/input getestet.

Scheinbar funktioniert der Imperso Zugriff mit IMPERSUSER auf ZIELPOSTFACH@domain.com

Logisch das MS Tool nutzt ja intern auch Impersonation mittels Exchange Webservices-API.

mit dem Tool SMTP Diag Tool erhalte ich nach wie vor die Meldung: .
550 5.7.60 SMTP; Client does not have permissions to send as this sender
Error: SMTP protocol error. 550 5.7.60 SMTP; Client does not have permissions to send as this sender.
Failed to send messageForcing disconnection from SMTP server.)

Das ist ja auch völlig OK und normal! Du musst wie ich oben schon gesagt habe ein Tool nutzen (EWS) was auch Impersonation als Authentifzierungsschema nutzen kann und das kann normales SMTP nunmal nicht, mit normaler SMTP Auth brauchst du stattdessen explizit zugewiesene SendAs Berechtigungen ... Aber Mails senden geht mit EWS ja auch unproblematisch, Beispiele finden sich dazu massenhaft im Netz.

Du hast hier offensichtlich noch ein Verständnisproblem was Impersonation betrifft.

Hi,

habe die Sache von deinem Link getestet (http://blog.icewolf.ch/archive/2012/07/15/ews-managed-api-demo-imperson ..), jedoch erhalte ich folgenden Fehler:

Imported EWS Module
Connecting to EWS...
Using EWS URL
-->Impersonation to Mailbox: testmailbox@corp.com
Error in GetMailboxFolders Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert. ---> System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.
   bei System.Net.HttpWebRequest.GetResponse()
   bei Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.IEwsHttpWebRequest.GetResponse()
   bei Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
   bei Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
   bei Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
   bei Microsoft.Exchange.WebServices.Data.ExchangeService.FindFolders(FolderId parentFolderId, FolderView view)
   bei CallSite.Target(Closure , CallSite , Object , WellKnownFolderName , Object )
Finished

(401) Nicht autorisiert.

Der Fehler sagt es schon, du hast die Application-Impersonation für den der das Skript ausführt also noch nicht korrekt vorgenommen.

Hallo,

ich habe es wie folgt angelegt:

New-ManagementRoleAssignment -Name:"Mailsender" -Role:ApplicationImpersonation -User:"IMPERSOUSER@corp.com"

Wenn ich

Get-ManagementRoleAssignment -RoleAssignee IMPERSOUSER

eingebe, dann sehe ich den auch u.a. mit dem Role "ApplicationImpersonation". Ein Scope existiert nicht, sodass es für ALLE Mailboxen geht (ich wollte den Scope als Fehlerquelle ausschließen).
Habe es auch mit dem EWSEditor (https://github.com/dseph/EwsEditor) getestet, funktioniert ohne Probleme..

Habe es auch mit dem EWSEditor (https://github.com/dseph/EwsEditor) getestet, funktioniert ohne Probleme..

Wenn es im EWSEditor auch wirklich per Impersonation läuft, bleibt nur noch das du das Skript fehlerhaft angepasst hast.

Danke, du hast (wieder) recht gehabt. Hatte etwas verdreht, läuft nun. Somit kann ich davon ausgehen, dass meine Imperso Config funktioniert.

Funktioniert die Impersonation Rolle nur über die EWS Schnittstelle? ApplicationImpersonation wäre als Lösung am besten.