Exchange Split Permission – AD Berechtigungen und Prozesse
7596
post-template-default,single,single-post,postid-7596,single-format-standard,bridge-core-3.1.4,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-30.3,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-7.5,vc_responsive

Exchange Split Permission – AD Berechtigungen und Prozesse

Wenn man sich mit dem Thema Tiering befasst, stößt man früher oder später auf das Thema Exchange. Exchange ist bekannt dafür (zu) weitreichende Berechtigungen im Active Directory zu haben.

Auch wenn Microsoft nach Veröffentlichung des Researchs von Dirk-Jan die Berechtigungen im Shared Permission Mode über ein Update reduziert hat bleibt die allgemein anerkannte Lösung die Einführung des AD Split Permission Mode.

Microsoft macht dazu einige Ausführungen in ihrer Dokumentation (hier und hier) mit der prominenten Warnung:

Zumindest der Teil mit den Security Principals ist ja genau das, was man erreichen will, allerdings schreckt der Rest der Warnung auch viele ab den AD Split Permission Mode einzuführen.

Erstaunlicherweise findet man bei Microsoft keine und im Internet nur wenige (z.B. hier) konkrete Anleitungen, wie man die verschiedenen Postfächer und Exchange Objekte im AD Split Permission Mode verwalten kann. Daher möchten wir in diesem Blogpost darauf eingehen welche Berechtigungen AD seitig notwendig sind und wie ein Workflow aussehen kann die Objekte anzulegen.

Wir machen bewusst keinen detaillierten Vorschlag zur OU-Struktur und konkreten Rechtedelegation, da die Prozesse in jeder Firma unterschiedlich sind z.B. verwaltet in Firma A das Exchange Team die Mitglieder von Verteilerlisten, in Firma B macht das der First Level Support. Wir empfehlen jedoch für jeden Objekttyp an geeigneter Stelle in der Tiering Struktur eine eigene OU anzulegen, um die Rechte granular delegieren zu können.

An dieser Stelle nochmal der Disclaimer, dass wir keine Exchange Admins sind und uns daher einige der feineren Punkte rund um die Exchange Administration nicht vertraut sein könnten.

Die nachfolgenden Beispiele sind von einer Exchange on-prem Umgebung, funktionieren aber mit minimalen Anpassungen auch in einer Hybrid Umgebung.

Exchange Objekte

Im Kontext der AD-Berechtigungen sind die Lebenszyklen der folgenden (Exchange) Objekte relevant:

    • Benutzer Mailbox
    • Benutzer Mailbox Delegations
    • Gruppenpostfächer
    • Verteilerlisten
    • Ressourcen Postfächer
    • Mail Kontakte

Für alle Prozesse gilt, dass der Lifecycle möglichst automatisiert sein sollte. So können die Rechte einem Group Managed Service Account delegiert werden und die Steuerung kann z.B. über CSV Dateien erfolgen.

Nachfolgend zeigen wir nur Beispiele für die Anlage, Änderungen oder Dekommissionierungen können davon abgeleitet werden.

Benutzer-Mailbox

Die bei der Installation im Split Permisson Mode gesetzten Rechte für Exchange sind ausreichend, um einem bestehenden Benutzer eine Mailbox hinzuzufügen (Enable-Mailbox in der Exchange Management Shell).

Die Email-Adressen können mit einer E-Mail-Adressen-Policy passend generiert werden um z.B. interne und externe Benutzer zu unterscheiden.

Benutzer-Mailbox-Delegations

Send on behalf und Full Control

Send on behalf und Full Control können weiterhin über das Exchange Administration Center / Powershell vergeben werden.

Send as

Um eine Send-as Delegation einzurichten, muss die Berechtigung auf dem AD-User-Objekt gesetzt werden. Dazu ist folgendes Recht im AD notwendig:

Hierbei handelt es sich um weitreichende Berechtigungen, die von einem Angreifer ausgenutzt werden können (siehe hier). Daher ist hier die angesprochene Automatisierung umso wichtiger.

Folgende Berechtigung muss für die Send-as Delegation vergeben werden:

Die Berechtigungsvergabe ist nicht immer sofort wirksam! Siehe: Delays with Send As permissions, Quotas, Mailbox permissions in Exchange – rakhesh.com

Folgendes Skript kann für die Automatisierung als Basis dienen:

[code language=”powershell”]
# Add-ADExtendedUserRight.ps1

<#
.SYNOPSIS
   Adds extended user rights to an Active Directory user account.
.PARAMETER Identity
    Specifies an Active Directory user object by providing one of the following property values:
    * DistinguishedName
    * GUID
    * SID
    * SamAccountName
.PARAMETER User
    Specifies the user who gets the permissions on the Active Directory user account.
.PARAMETER ExtendedUserRight
    Specifies the extended user right that will be added to the Active Directory user account. Currently, the following extended user rights are supported:
    * Send-As
    * Send-To
.EXAMPLE
    Add-ADExtendedUserRight.ps1 -Identity max.mustermann -Trustee erika.mustermann -ExtendedUserRight 'Send-As'
    Adds the extended user right "Send-As" for erika.mustermann to the user account max.mustermann.
.EXAMPLE
    Get-ADUser -Filter "Surname -eq 'Mustermann'"| Add-ADExtendedUserRight.ps1 -Trustee erika.mustermann -ExtendedUserRight 'Send-As'
    Adds the extended user right "Send-As" for erika.mustermann to all user accounts with surname "Mustermann".
#>

#Requires -Version 4.0
#Requires -Modules ActiveDirectory

[CmdletBinding(SupportsShouldProcess=$true)]
Param
(
    [Parameter(Mandatory=$true,
               ValueFromPipeline=$true,
               Position=0)]
    [Microsoft.ActiveDirectory.Management.ADUser]$Identity,

    [Parameter(Mandatory=$true)]
    [Microsoft.ActiveDirectory.Management.ADUser]$Trustee,

    [Parameter(Mandatory=$true)]
    [ValidateSet('Send-As','Send-To')]
    [string]$ExtendedUserRight
)

Begin
{
    Set-StrictMode -Version Latest

    # https://learn.microsoft.com/en-us/windows/win32/adschema/extended-rights
    $ExtendedRights = @(
        [PSCustomObject]@{CN = 'Send-As'; GUID = 'ab721a54-1e2f-11d0-9819-00aa0040529b'}  
        [PSCustomObject]@{CN = 'Send-To'; GUID = 'ab721a55-1e2f-11d0-9819-00aa0040529b'}  
    )

    $Domain = Get-ADDomain
    $Account = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList $Trustee
    try {
        $UserSID = $Account.Translate([Security.Principal.SecurityIdentifier]).Value
    }
    catch {
        Write-Error "Cannot find an object with identity: '$Trustee' under: '$($Domain.DistinguishedName)'."
        break
    }

    $ExtendedUserRightGuid = $ExtendedRights | Where-Object {$_.CN -eq $ExtendedUserRight } | Select-Object -ExpandProperty GUID
    $Arguments = $Account, [System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight, [System.Security.AccessControl.AccessControlType]::Allow, $ExtendedUserRightGuid, [System.DirectoryServices.ActiveDirectorySecurityInheritance]::None
    $NewRule = New-Object -TypeName 'System.DirectoryServices.ActiveDirectoryAccessRule' -ArgumentList $Arguments
}

Process
{
    try {
        $AdUser = Get-ADUser -Identity $Identity
        $Acl = Get-Acl -Path "AD:$($AdUser.DistinguishedName)"
        $Acl.AddAccessRule($NewRule)
        Set-Acl -Path "AD:$($AdUser.DistinguishedName)" -AclObject $Acl
    }
    catch {
        Write-Error $_
    }
}

End
{
}

[/code]

Gruppenpostfächer

Auch hier wird wieder das Recht benötigt User Accounts zu managen, somit gilt der Hinweis von oben ebenso.

Ein Gruppenpostfach kann mit folgendem Skript angelegt und ein User berechtigt werden (Exchange Management Shell):

[code language=”powershell”]
$GPF = "Gruppenpostfach1"
$CharCount = ($GPF | measure -Character).characters
If ($CharCount -gt 20) {
$SAMAcName = $GPF.SubString(0,20)
}
Else {
$SAMAcName = $GPF
}
New-ADUser -Name $GPF -path "OU=zz_Gruppenpostfächer,DC=exchange,DC=local" -Surname $GPF -UserPrincipalName ($GPF + "@exchange") -SamAccountName $SAMAcName -ChangePasswordAtLogon $true -DisplayName $GPF -Description "Gruppenpostfach"
Enable-Mailbox -Identity $GPF
Set-Mailbox -Identity $GPF -Type Shared
Add-MailboxPermission -Identity $GPF -User test_user2 -AccessRights FullAccess

[/code]

Zusätzlich muss noch mit dem oben gezeigten Skript die Send As Berechtigung vergeben werden (auch hier wieder mögliche Delays beachten).

Beim Umwandeln von einer Benutzer Mailbox in ein Gruppenpostfach trat bei uns in der Testumgebung folgende Fehlermeldung auf, die Mailbox wurde aber trotzdem umgewandelt:

Verteilerlisten

Verteilerlisten sind Mail aktivierte AD-Gruppen. Um Sie verwalten zu können muss entsprechend das Recht Gruppen verwalten zu dürfen delegiert werden.

Anschließend können Verteilerlisten wie folgt erstellt und befüllt werden (Exchange Management Shell):

[code language=”powershell”]
New-ADGroup -Name "Verteilerliste1" -Path "OU=zz_Verteilerlisten,DC=exchange,DC=local" -GroupScope Universal
Enable-DistributionGroup -Identity verteilerliste1
Add-ADGroupMember -Identity "verteilerliste1" -Members test_user1

[/code]

Ressoucen Mailbox

Eine Raum- oder Gerätemailbox ist ein User Objekt im Active Directory. Folglich wird wieder das Recht Benutzer zu verwalten benötigt. Ein letztes Mal der Hinweis auf die entsprechende Absicherung.

Eine Raummailbox kann mit folgendem Skript angelegt werden:

[code language=”powershell”]
$RMBX = "Raum2"
$CharCount = ($RMBX | measure -Character).characters
If ($CharCount -gt 20) {
$SAMAcName = $RMBX.SubString(0,20)
}
Else {
$SAMAcName = $RMBX
}
New-ADUser -Name $RMBX -path "OU=zz_Ressourcen,DC=exchange,DC=local" -Surname $RMBX -UserPrincipalName ($RMBX + "@exchange") -SamAccountName $SAMAcName -ChangePasswordAtLogon $true -DisplayName $RMBX -Description "Raum"
Enable-Mailbox -Identity $RMBX
Set-Mailbox -Identity $RMBX -Type Room

[/code]

Kontakte

Bei Kontakten handelt es sich um eine eigene Objektklasse im AD, daher muss das Recht Kontakt Objekte zu verwalten delegiert werden.

Mit folgendem Befehl kann dann ein Kontakt angelegt werden:

[code language=”powershell”]
New-ADObject -Type Contact -Name Kontakt1 -OtherAttributes @{'mail'="Kontakt1@mail.de"} -Path "OU=zz_Kontakte,DC=exchange,DC=local"

[/code]

Zusammenfassung

Zusammenfassend kann man sagen, dass die Einführung von Exchange AD Split Permissions notwendig und möglich, wenn auch nicht einfach oder gut dokumentiert ist. Wir hoffen wir konnten mit diesem Blogartikel helfen das Thema zu erläutern und euch bei der Einführung zu helfen.

Klicken Sie auf den unteren Button, um den Inhalt von www.linkedin.com zu laden.

Inhalt laden

Klicken Sie auf den unteren Button, um den Inhalt von www.linkedin.com zu laden.

Inhalt laden

Klicken Sie auf den unteren Button, um den Inhalt von www.linkedin.com zu laden.

Inhalt laden

Klicken Sie auf den unteren Button, um den Inhalt von www.linkedin.com zu laden.

Inhalt laden

 

Sieh dir diesen Beitrag auf Instagram an

 

Ein Beitrag geteilt von TEAL Technology Consulting (@tealconsulting)

 

Sieh dir diesen Beitrag auf Instagram an

 

Ein Beitrag geteilt von TEAL Technology Consulting (@tealconsulting)

LATEST POSTS

  • Heute möchten wir hinter die Kulissen unseres Security Assessments blicken, doch was ist das überhaupt? Kurz zusammengefasst, wir versetzen Sie in die Lage, bewusste Entscheidungen zu treffen und Ihre nächsten Schritte...

  • Gemeinsam mit einem unserer Partner FB Pro werden wir an Stand 58 in der Eilenriedehalle im Hannover Congress Centrum zu finden sein. Unser Schwerpunkt liegt dabei auf einem zentralen Thema, das in der Cybersicherheits-Welt von entscheidender ...

  • Seit 2021 bieten wir für unsere Kunden nicht nur die reine Beratung im IT-Security Bereich, sondern darüber hinaus auch den vollumfassenden Managed Service unserer Produkte an. Allem voran haben wir uns auf das Thema ...