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
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
Antworten-
1 
- Mehr
Auf Facebook teilen
Auf Twitter teilen8 Antworten
- LÖSUNG goscho schreibt am 06.01.2021 um 10:46:33 Uhr
- LÖSUNG scar71 schreibt am 06.01.2021 um 13:17:28 Uhr
- LÖSUNG 147069 schreibt am 06.01.2021 um 12:17:45 Uhr
- LÖSUNG scar71 schreibt am 06.01.2021 um 12:50:29 Uhr
- LÖSUNG 147069 schreibt am 06.01.2021 um 12:58:33 Uhr
- LÖSUNG scar71 schreibt am 06.01.2021 um 13:19:38 Uhr
- LÖSUNG 147069 schreibt am 06.01.2021 um 13:22:43 Uhr
- LÖSUNG scar71 schreibt am 18.01.2021 um 11:43:27 Uhr
- LÖSUNG 147069 schreibt am 06.01.2021 um 13:22:43 Uhr
- LÖSUNG scar71 schreibt am 06.01.2021 um 13:19:38 Uhr
- LÖSUNG 147069 schreibt am 06.01.2021 um 12:58:33 Uhr
- LÖSUNG scar71 schreibt am 06.01.2021 um 12:50:29 Uhr
LÖSUNG 06.01.2021 um 10:46 Uhr
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?
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?
LÖSUNG 06.01.2021, aktualisiert um 12:19 Uhr
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 ...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.
$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} -ForceLÖSUNG 06.01.2021 um 12:50 Uhr
LÖSUNG 06.01.2021, aktualisiert um 13:10 Uhr
Ü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.
Configure impersonation
Den Service-Account sollte man aber gut absichern und beschränken sonst baut mach sich damit ein potentielles Einfallstor.
LÖSUNG 06.01.2021 um 13:17 Uhr
LÖSUNG 06.01.2021, aktualisiert um 13:21 Uhr
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.
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.
LÖSUNG 06.01.2021, aktualisiert um 13:23 Uhr
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.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?
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.Erstelle neuen RBAC, mit der Rolle Impersonation und weise dort dem user1 (Dienstuser, mit einem vernünftigen Passwort). Wie sehe der weitere Verlauf aus?
LÖSUNG 18.01.2021 um 11:43 Uhr
Hallo,
habe nun ApplicationImpersonation getestet, leider funktioniert es noch nicht.
Wenn ich die "send_As" Berechtigung manuell vergebe, klappt es.
Aktuelle Konstellation:
Leider erhalte ich die Meldung "550 5.7.60 SMTP; Client does not have permissions to send as this sender"
Wo ist der Fehler?
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" Wo ist der Fehler?
