15 May 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
Sieh dir diesen Beitrag auf Instagram an
LATEST POSTS
-
Data security with tiering – protection at every level
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 ...
16 October, 2024 -
it-sa 2024: Visit us in Nuremberg!
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...
15 August, 2024 -
Windows LAPS: What can the “new” LAPS do and should I use it?
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....
15 July, 2024