Exchange Split Permission - AD permissions and processes
7597
post-template-default,single,single-post,postid-7597,single-format-standard,bridge-core-3.3.1,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-30.8.1,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-7.9,vc_responsive

Exchange Split Permission – AD permissions and processes

If you deal with the topic of tiering, sooner or later you will come across the topic of Exchange. Exchange is known to have (too) extensive permissions in the Active Directory.

Even though Microsoft reduced the permissions in Shared Permission Mode via an update after the publication of Dirk-Jan’s research, the generally accepted solution remains the introduction of AD Split Permission Mode.

Microsoft makes some comments about this in their documentation (here and here) with the prominent warning:

At least the part with the security principles is exactly what you want to achieve, but the rest of the warning also discourages many from implementing AD Split Permission Mode.

Surprisingly, Microsoft does not provide specific instructions on how to manage the different mailboxes and Exchange objects in AD Split Permission Mode, and there are only a few on the web (e.g. here). Therefore, in this blog post we want to discuss what permissions are needed on the AD side and what a workflow might look like to create the objects.

We deliberately do not make a detailed proposal for the OU structure and concrete permissions delegation, because the processes in each company are different, e.g. in company A the Exchange team manages the members of the distribution lists, in company B this is done by the first level support. However, we recommend creating a separate OU for each object type at an appropriate point in the tiering structure to be able to delegate rights granularly.

Again, the disclaimer that we are not Exchange admins, so some of the nuances of Exchange administration may not be familiar to us.

The examples below are from an on-prem Exchange environment, but will work in a hybrid environment with minimal adjustments.

Exchange Objects

In the context of AD permissions, the lifecycles of the following (Exchange) objects are relevant:

    • User Mailbox
    • User Mailbox Delegations
    • Group mailboxes
    • Distribution listsResources Mailboxes
    • Mail Contacts

The lifecycle should be as automated as possible for all processes. Thus, the rights can be delegated to a Group Managed Service Account and the control can be done e.g. via CSV files.

In the following we only show examples for the creation, changes or decommissioning can be derived from this.

User Mailbox

The rights set for Exchange during installation in Split Permisson Mode are sufficient to add a mailbox to an existing user (Enable-Mailbox in the Exchange Management Shell).

The email addresses can be generated appropriately with an email address policy, e.g. to distinguish internal and external users.

User Mailbox Delegations

Send on behalf and Full Control

Send on behalf and Full Control can still be assigned via the Exchange Administration Center / Powershell.

Send as

To set up a Send as delegation, the permission must be set on the AD user object. This requires the following permission in AD:

These are far-reaching authorizations that can be exploited by an attacker (see here). Therefore, the automation mentioned is all the more important here.

The following authorization must be assigned for the send-as delegation:

The authorization assignment is not always effective immediately! See: Delays with Send As permissions, Quotas, Mailbox permissions in Exchange – rakhesh.com

The following script can serve as a basis for automation:

[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]

Group mailboxes

Again, the right to manage user accounts is needed, so the hint from above applies as well.

A group mailbox can be created and a user authorized with the following script (Exchange Management Shell):

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

$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]

In addition, the Send As authorization must be assigned using the script shown above (again, note possible delays).

When converting a user mailbox into a group mailbox, the following error message occurred in our test environment, but the mailbox was converted anyway:

Mailing lists

Distribution lists are mail activated AD groups. To be able to manage them, the right to manage groups must be delegated accordingly.

Then distribution lists can be created and populated as follows (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]

Resources Mailbox

A room or device mailbox is a user object in Active Directory. Consequently, the right to manage users is required again. One last time the reference to the appropriate protection.

A room mailbox can be created with the following script:

[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]

Contacts

Contacts are a separate object class in AD, therefore the right to manage contact objects must be delegated.

A contact can then be created with the following command:

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

[/code]

Summary

In summary, implementing Exchange AD split permissions is necessary and possible, but not easy or well documented. We hope that this blog article has helped to explain the topic and assist you with the implementation.

 

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

  • In this article, we give you a closer look at the importance of Microsoft Tiering for your IT security. We have looked at the underlying issues and the critical areas and systems that need to be protected to prevent total loss ...

  • This year we will be represented for the first time together with our partner FB Pro GmbH with a stand and a specialist lecture at one of the most important IT security trade fairs in Europe: it-sa 2024 in Nuremberg...

  • A new version of LAPS - Windows LAPS - has been available for some time now. In this article, we will look at the new features and discuss whether it makes sense to migrate to the new version....