Exchange AD Split Permissionsを後悔なく導入する

01.03.2026

メールボックスをすべてクラウドへ移行済みの組織でも、オンプレミスのExchangeサーバーは動き続けていることが多く、それはActive Directoryにとって過小評価されたセキュリティリスクでもあります。「AD Split Permissions」モデルは、攻撃者がドメイン全体の侵害に悪用しうる広範なADの特権をExchangeから取り除きます。これまで導入が進まなかった主な理由は、管理者に強いるプロセス変更でした。本記事では、まさにそのハードルをスマートに乗り越える方法を紹介します。失われたADのアクセス許可を関連するOUにだけ選択的に再付与するスクリプトを使えば、慣れ親しんだ運用をそのままに、セキュリティ上の効果を余さず得られます。

TLDR：欠点を取り除いたらどうなるか

Exchangeのユーザー、グループ、連絡先が置かれている場所で、ADとRBACのアクセス許可を直接再付与する方法を見つけました。管理者にもID管理システムにも変更は不要です。私の経験では、この摩擦こそが多くの企業にとって最大の障害でした。それでいて、ラテラルムーブメントとドメイン侵害に対するセキュリティ上の利点はそのまま残ります。

実現は3つのステップです。

AD分割アクセス許可モデルを実装する
失われたADのアクセス許可を、関連するOUに限定してExchangeサーバーに付与する
使えなくなったPowerShellコマンドレットを再度有効にするため、Exchange RBACを付与する

いずれもMicrosoftのガイダンス、AD ACL、またはExchange RBACの割り当てによって行います。

ウェビナー：Exchange AD Split Permissions without regrets. 手順を追った実装ガイド

なぜ今これが重要なのか

Exchange 2010 SP1で導入されて以来、この仕組みはほとんど見過ごされるか無視されてきました。しかし既定の共有アクセス許可モデルは、Active Directoryを乗っ取られる大きなセキュリティリスクです。ここ数年Exchangeがリモートからの攻撃で悪名高いことと合わせると、いま手を打つべき時期です。

問題の出発点は、ドメインのルートに付与され、ドメイン全体へ継承されていく特権にあります。

ユーザーとグループのアクセス許可の変更（実質的にフルアクセス）
グループメンバーの変更
ユーザーのパスワードリセット
ユーザーとグループの作成・削除

AdminSDHolderプロセス（属性admincount=1）で保護されるのは一部の高特権Tier 0ユーザーとグループだけであり、多くの環境には保護されていないユーザーやグループが残ります。それらはドメインやフォレストの侵害につながるか、少なくとも深刻な影響を招く可能性があります。

代表的な例

Password Hash Syncを使用している場合のEntra Connect Syncアカウント
既定のグループ
- Allowed RODC Password Replication GroupとEntra Connectアカウントの組み合わせ（実際のWindows RODCが存在する場合）
- さらに多くの経路を示すUntrustworthy Trust Builders: Account Operators Replicating Trust Attack (AORTA) - SpecterOpsも参照してください（Account Operatorsグループも同様の脅威です）
- Protected Usersを空にして保護を外し、攻撃経路を作る手口
保護されていないカスタムグループや管理・サービスアカウント
- GPOへの書き込みアクセス許可（ドメインコントローラーに適用されるもの）
- ADバックアップ、バックアップサーバー、PKIテンプレート、ハイパーバイザーなどへのアクセス管理

これら現在および将来の潜在的な経路をすべて後追いで封じ込めるのは非常に困難です。_ADMというカスタムOUであればACLの継承を無効化できますが、既定のオブジェクトの多くは既定のBuiltin OUやUsersコンテナーから移動できず、脆弱なまま残ります。

ルートから強力なアクセス許可を取り除くほうがはるかに良く、それはActive Directory分割アクセス許可モデルを実装することで実現できます。Configure Exchange Server for split permissions | Microsoft Learn

Microsoftも「…Active Directory分割アクセス許可の実装を推奨します」と述べています。Active Directory Hardening Series - Part 7 – Implementing Least Privilege | Microsoft Community Hub

しかし、なぜ誰もやらないのか

分割アクセス許可はExchange 2010 SP1まで利用できず、その頃には誰もが既定の状態を受け入れていました。登場後もセキュリティチームは導入を押し通せなかったように見えます。

さらに、ADで先にユーザーや配布リストを作成し、その後でExchangeから「メール有効化」するなど、管理プロセスとIDMプロセスの変更を強いるものでもありました。

Info: 次のコマンドレットは利用できなくなるか、動作しなくなります。Add-DistributionGroupMember, New-DistributionGroup, New-Mailbox, New-MailContact, New-MailUser, New-RemoteMailbox, Remove-DistributionGroup, Remove-DistributionGroupMember, Remove-Mailbox, Remove-MailContact, Remove-MailUser, Remove-RemoteMailbox, Update-DistributionGroupMember, Add-ADPermission, Remove-ADPermission

運用変更の例

New-Mailbox（ExchangeがADに書き込む）は次のようになります
- New-ADUser（adm.jdoeがADに書き込む）
- Enable-Mailbox
SendAs権限のためのAdd-ADPermissionは、Active Directoryユーザーとコンピューターのセキュリティタブから行う必要があり、標準の管理者には追加のADアクセス許可が必要になることも多くなります。

後悔しない方法を紹介します

免責事項：以下のリンクと記事を最後まで読んで理解し、まずテスト環境で実施し、ADのバックアップが最新であることと復旧手順が確立されていることを必ず確認してください。

現在の利用状況を監査する

まず、対象のコマンドレットのどれがどのOUで使われているかを確認してください。

$CsvPath = "C:\temp\SplitPermissionAdminAuditLog.csv"
$Cmdlets = "Add-ADPermission","Remove-ADPermission","New-DistributionGroup","Remove-DistributionGroup","Add-DistributionGroupMember","Update-DistributionGroupMember","Remove-DistributionGroupMember","New-Mailbox","Remove-Mailbox","New-RemoteMailbox","Remove-RemoteMailbox","New-MailUser","Remove-MailUser","New-MailContact","Remove-MailContact"
Search-AdminAuditLog -ResultSize 99000 -Cmdlets $Cmdlets | Select-Object RunDate,Caller,ObjectModified,CmdletName,@{Name='CmdletParameters';Expression={[string]::join(",", ($\_.CmdletParameters))}},succeeded,error | Export-Csv -Path $CsvPath -Delimiter ";" -Encoding Unicode -NoTypeInformation

呼び出し元とコマンドレットの簡易分析

$CSVs = Import-Csv -Path $CsvPath -Delimiter ";"
$CSVs | Group-Object Caller
$CSVs | Group-Object CmdletName

CSVを分析し、ADのアクセス許可がどこで必要になるかを把握してください。Exchange関連のグループを専用のOUにまとめておくと、さらに最適化できる場合があります。

分割アクセス許可モデルを有効にする

Configure Exchange Server for split permissions | Microsoft Learn に記載されたMicrosoftの手順**「Switch to Active Directory split permissions」**に従ってください。 （RBAC分割アクセス許可ではありません）

実質的には、**「Exchange Windows Permissions」**グループの危険なアクセス許可が削除され、あわせてExchangeがそのグループのメンバーから外されます。

Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /PrepareAD /ActiveDirectorySplitPermissions:true

Info: 元に戻すには /ActiveDirectorySplitPermissions:false を使うだけです

ADのアクセス許可を付与する

カスタムADグループを作成し、Exchangeサーバーをそのメンバーにします。

# adjust OU Path first!
New-ADGroup -Name "AD_Custom Exchange Split permissions replacement" -GroupCategory Security -GroupScope DomainLocal -Path "OU=Rights,OU=Groups,OU=T1,OU=_ADM,$((Get-ADDomain).DistinguishedName)" -Description "replaces the permissions lost by split permissions on relevant OUs"
Add-ADGroupMember "AD_Custom Exchange Split permissions replacement" -Members "Exchange Trusted Subsystem"
# reboot Exchange servers for permissions via group to work

ユースケースごとにADアクセス許可を簡単に委任できるスクリプトを作成しました。

これらのアクセス許可がないと、ExchangeサーバーはADから“INSUFF_ACCESS_RIGHTS”というエラーを受け取ります。

glueckkanjaのGitHubからAdd-ExchangeADSplitPermissionOnOU.ps1をダウンロードしてください

付与できるPermissionTypeは次のとおりです。

CreateUserAndContact
ユーザーと連絡先に対するCreate/delete、ResetPassword、WriteAllProperties
Exchangeコマンドレット: `New-Mailbox`, `New-RemoteMailbox`, `New-MailUser`, `New-MailContact` と対応する `Remove-*`

GroupManage
グループの作成・削除、メンバーの変更
Exchangeコマンドレット: `New-DistributionGroup`, `Remove-DistributionGroup`, `Add-DistributionGroupMember`, `Update-DistributionGroupMember`, `Remove-DistributionGroupMember`
その他: ユーザーが自分の所有するDistributionGroupをEAC経由で管理する

UserSendAs
ユーザーのADアクセス許可の変更
Exchangeコマンドレット: `Add-ADPermission`

GroupSendAs
グループのADアクセス許可の変更
Exchangeコマンドレット: `Add-ADPermission`

スクリプトの使い方

Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU <OU> -PermissionType <GroupManage|UserSendAs|GroupSendAs|CreateUserAndContact> -Trustee "AD_Custom Exchange Split permissions replacement"
# For example
Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU "OU=ExchangeGroups,OU=HQ,OU=Alderaan,$((Get-ADDomain).DistinguishedName)" -PermissionType GroupManage -Trustee "AD_Custom Exchange Split permissions replacement"
Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU "OU=ExchangeGroups,OU=HQ,OU=Alderaan,$((Get-ADDomain).DistinguishedName)" -PermissionType GroupSendAs -Trustee "AD_Custom Exchange Split permissions replacement"
Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU "OU=Users,OU=HQ,OU=Alderaan,$((Get-ADDomain).DistinguishedName)" -PermissionType UserSendAs -Trustee "AD_Custom Exchange Split permissions replacement"
Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU "OU=Users,OU=HQ,OU=Alderaan,$((Get-ADDomain).DistinguishedName)" -PermissionType CreateUserAndContact -Trustee "AD_Custom Exchange Split permissions replacement"

Exchange RBACを付与する

Add-DistributionGroupMemberとRemove-DistributionGroupMemberの各コマンドレットで-BypassSecurityGroupManagerCheckパラメーターを再度有効にします

New-RoleGroup -Name "SplitPermission Security Group Creation and Membership" -Roles "Security Group Creation and Membership" -Members "Organization Management","Recipient Management" -Description "Brings back -BypassSecurityGroupManagerCheck to Add-DistributionGroupMember, but also needs AD ACL for Exchange Server on target DLs"

Info: これを行わないと "-BypassSecurityGroupManagerCheck parameter is not available" または "You don't have sufficient permissions. This operation can only be performed by a manager of the group" というエラーになります。

New-Mailbox、New-RemoteMailbox、New-MailContact、Remove-... の各コマンドレットを必要なパラメーター付きで再度有効にします

New-RoleGroup -Name "SplitPermission Mail Recipient Creation" -Roles "Mail Recipient Creation" -Members "Organization Management","Recipient Management" -Description "Brings back New-Mailbox, New-RemoteMailbox, New-MailUser, New-MailContact and matching Remove-... cmdlets, but additionally Exchange needs AD ACL for Exchange Server on target OUs"

まとめ

このガイドが、Exchange経由のActive Directory侵害を防ぐという重要な一歩を、より多くの組織が踏み出す助けになれば幸いです。複数のお客様でExchange AD Split Permissionsモデルを実装してきましたが、これまで問題に遭遇したことはなく、導入もスムーズに進んでいます。

現在のオールオアナッシングの方式ではなく、OU単位でこの粒度を実現できるネイティブの仕組みをMicrosoftが提供してくれれば、広く採用されるようになるはずです。

ADのTier分離について一言。Exchangeサーバーへドメイン管理者やその他のTier 0アカウントでログオンしないでください。ExchangeサーバーはTier 1として扱い、できるだけ早くADのTier分離を実装してください。最初の一歩としては、PingCastleやPurple KnightでADのセキュリティ状況を評価し、コントロールパスの露出を洗い出すことをおすすめします。

MFA向けSMSの終わり

企業がいまフィッシング耐性のある、できるだけパスワードレスな認証方式へ移行すべき理由。

ClickFix。ユーザー自身がエクスプロイトになるとき、そしてそれを止める方法

ClickFixはユーザーを自分自身への攻撃者に変えます。偽のCAPTCHA、コピー＆ペースト、そして悪意あるコードがメモリ上で走り、ディスクには何も残りません。Microsoft Defenderがこの攻撃をどう検知するのか、検知はどこで限界に達するのか、そしてRunMRUハントと4つの防御レイヤーでその隙間をどう埋めるのかを解説します。

管理業務と日常業務を1台のPCで。Game Overです。

CIOにとってテナントが1つでは足りない理由と、2つ目がめったに検討されない理由。Managed Red Tenantは管理業務をオフィス環境からアーキテクチャとして分離し、Managed Dark Tenantは防御が破られてもなお組織が動き続けられるようにします。それが運用モデル、SOCのシグナル、そしてNISG 2026による証明義務にとって何を意味するのかを解説します。

4度のLeader。ISGドイツ調査2026のglueckkanja

ISG Provider Lens®調査2026は、ドイツにおいてglueckkanjaを4つのクアドラントでLeaderに位置づけました。Microsoft Productivity and Business Process ServicesとAzure Managed Servicesの、それぞれLarge MarketとMid Marketです。調査の名称はMicrosoft AI and Cloud Ecosystemに変わり、評価の尺度も移りました。AIとエージェントのワークロードを制御可能なかたちで運用できるかが問われています。

Rising StarからLeaderへ。ISGスイス調査2026のglueckkanja

ISG Provider Lens®調査2026は、スイスにおいてglueckkanjaをMicrosoft AI and Cloud Ecosystemクアドラントの、Azure Managed Services領域とMicrosoft Productivity and Business Process Services領域でLeaderに位置づけました。ベルンでの市場参入から2年、Rising Star選出から1年でのことです。

Outbreak。OpenAI／Hugging Faceの事案が示すこと、示さないこと

AIエージェントがテスト環境から脱出し、ゼロデイを見つけ、別の企業をハッキングする。映画の脚本のようですが、2026年7月に実際に起きました。冷静に位置づける時期です。少しの心理学、2人のセキュリティ専門家、そしてそれが自社の防御にとって何を意味するのかという問いとともに。

LeaderそしてRising Star。ISGサイバーセキュリティ調査2026のglueckkanja

ISG Provider Lens®調査 Cybersecurity 2026は、glueckkanjaをNext-Gen SOC/MDR Services（Midmarket）クアドラントのLeaderに選出しました。Next-Gen SOC/MDR Servicesの全体市場では、当社はRising Starです。ISGは当社の平均を上回る成長、Microsoftセキュリティに関する深い専門性、そしてドイツ国内から提供する24時間365日のSOCを評価しています。

The Holy Trinity：AIが実際に働くために本当に必要なもの

ある製造業の企業が、14,000あるSKUのうちどれが実際に利益を生んでいるのかを知りたいと考えました。答えは3つのシステムの中にありますが、それらは一度もデータを1件たりともやり取りしたことがありません。少し前までは、その答えを得るのに3つの部門、2週間、そして相当な善意が必要でした。2026年初頭からは、AIがこの問いに数分で答えられます。データを走査し、関連を結び、推奨を出す。ただし、アクセスできることが前提です。

契約書にサインしたあと：当社のオンボーディングはこう進みます

契約書にサインが済み、大きな一歩は終わりました。では、ここからどうなるのでしょうか。PreBoardingからチームでの最初の1週間まで、当社のオンボーディングの舞台裏をご案内します。

Microsoft Frontier Partner：当社もその一員です

最近、Microsoft AI Cloud Partner Programに新たな最高位の称号としてFrontier Partner Badgeが設けられました。Microsoftがこれを授与するのは、ワークプレイスからクラウドプラットフォーム、セキュリティ、そしてAIアプリケーションそのものに至るまで、Microsoftスタック全体でAIプロジェクトを確実に届けられると実績で示した、世界でもごく限られたパートナーだけです。DACH圏でこのグループに属するのは数社にすぎず、当社はそのうちの1社です。