1. SIDClonerについて

1. SIDClonerとは

SIDClonerというツールですが、みなさんご存じでしょうか？
ものすごく簡単にいうと、Windows Active Directoryオブジェクトの「SID」を移行するツール、というものです。一般論としてSIDはオブジェクトの識別子として「一意」であり、複製はできません。ですがActive Directoryオブジェクトを移行（他のドメインに移す）際に、移行元のSIDを一緒に保持していると、便利なことがあります。

2. sIDHistoryとは

たとえばユーザーAが「A」というSIDを持っていて、他のドメインに移行した場合、SIDそのものはかならず「B」という別のものに変わってしまいます（これは仕様上変えられません）。そこにsIDHistoryというLDAP属性に「A」のSIDをそのまま記載して移行すると、移行先で「B」と「A」の2つのSIDを保持しているようにみえる、というのがsIDHistoryの仕組みです。イメージとしては、以下のようになっています。

Figure 1 : sIDHistoryの利用イメージ

上記では移行したユーザーが「B」SIDなのに「A」SIDとも認識されるので、ファイルサーバーのACL（アクセス許可リスト）のSIDを変えることなく、アクセスできる、こういう意味になります。図にある「要信頼」というのはWindows信頼関係が必要、という意味です。同じドメインであれば、信頼関係は不要です。

3. sIDHistoryはどこで使われる？

sIDHistoryはADMT(Active Directory Migration Tool)という、ドメイン移行用のツールで利用されます。現在はサポート上の制約があるため、気軽に使えるツールとは言えませんが、ご興味の向きはADMT のサポート ポリシーと既知の問題 - Windows Server | Microsoft Learnなどをご覧くださればと思います。
それ以外の意外な利用法ですが、MSクラウドであるAzure AD Domain Services (ADD DS)でも、地味に活用されています。オンプレミス環境をAAD DSに移行した場合、sIDHistoryに「オンプレミス時代のSID」を保持しているため、AAD DSにドメイン参加したリソースが、透過的にHybridでの認可ができる、そういう意味になります。Azure AD Domain Services の同期のしくみ | Microsoft Learnに記載がありますので、確認くださるとよいでしょう。

4. sIDHistoryの問題点

便利なsIDHistoryですが、セキュリティ上の問題点があります。はっきりいえば「なりすまし」と同義になりますので、運用には十分気を付けなければなりません。実際に過去、セキュリティ問題として、Microsoft自身も言及しているのです。マイクロソフト セキュリティ情報 MS02-001 - 警告 | Microsoft Learnを確認くださるとよいでしょう。
対策としては、（信頼関係が存在する場合）SIDフィルタリングを実施する、不要なsIDHistoryは可及的速やかに削除する、の2点です。これはADMTの利用を前提としていて、移行後サーバー類のACLを（移行先アカウント・グループに）変換して「移行前のSIDは使わないようにする」が既定路線となるためです。こちらについての情報は Unsecure SID History attributes assessment - Microsoft Defender for Identity | Microsoft Learnが参考になるでしょう。

5. sIDClonerの立ち位置

sIDClonerは、Microsoftが提供するツールではありません。GitHub - GreyCorbel/SIDCloner: Demonstrates how to populate SID History on security principals migrated cross AD forest from PowerShell sessionを見ていただければ一目瞭然ですが、サードパーティが提供しています。そちらの説明には” Demonstrates how to populate SID History on security principals migrated cross AD forest from PowerShell session”とあり、実運用を前提としたツールではありません。

今回は検証目的のため取り上げましたが、実際に業務で利用したい、等のご要望は、Microsoftサポートにご確認くださるよう、お願いします。弊社では本ツールの利用保証・サポートに関するメニューはございませんので、あらかじめご了解ください。

以下、実際の検証結果を、掲載したいと思います。

2. SIDCloner検証結果について

1. 環境における最小要件

本件では、検証に成功した環境というベースだが、環境要件について、記載する。
なお本環境の背景情報については、Download Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains from Official Microsoft Download Center資料を参考に検証を行った。

1.1. ソフトウェア構成

2. 環境構築の詳細

環境構築については、以下のように実行した。あわせて確認ポイントを記載する。

2.1. Active Directoryの構成

2.2. sIDHistory移行用の設定

監査ポリシー設定後、移行元移行先ドメインコントローラーは「gpupdate /force」を実行のこと。ポリシーが反映しないため、なお、ドメインコントローラーから「制限ユーザーで」共有フォルダーにアクセスさせるため、「ローカルログオンの許可」ポリシーも修正してある（本来は不要）。

2.3. PowerShell 7/VC++再頒布パッケージのインストール

SIDClonerの実行環境として必要。

2.4. SIDClonerのインストールと利用

SIDCloner自体をインストールする。インターネット接続環境が前提。

次にSIDClonerで実際にsIDHistoryを構成する。

Copy-sidの実行結果が「OK」となっていれば問題はない。その後移行先の各オブジェクトの[属性エディター]でsIDHistoryが存在していることを確認できた。ちなみにCopy-sidの構文は以下の通り。

2.5. ファイルサーバーのドメイン移行

ファイルサーバーの所属ドメインを移行先に移動する。ACL等は一切変更しない。

再起動後に、共有フォルダーのプロパティで「共有アクセス許可」「NTFSアクセス許可」を確認すると、移行先グループに設定されている。

2.6. 移行元ドメインの閉塞

移行元ドメインの影響を避けるため、移行元ドメインコントローラーをシャットダウンする。必要があれば、移行先ドメインの環境も再起動するとよい。

2.7. 最終結果の確認

SID移行したユーザーでファイルサーバーにアクセスすると、その権限でアクセスが可能だった。

2.8. sIDHistoryを取り除いた際の挙動

sIDHistoryの機能が本当に影響を与えているのか、について、以下の方法で確認を行った。

上記作業後に、該当アカウントのsIDHistoryが削除されているのが、確認できた。同様に共有フォルダーにアクセスさせたが、アクセス拒否が確認できた。また共有フォルダーのプロパティで「共有アクセス許可」「NTFSアクセス許可」を再確認すると、移行先グループに設定されていた箇所が、未解決のSID（=移行元のSID）として表示された。

ここから、sIDHistory機能でアカウントが認識される、以上の動作（付け替えが発生した等）は起こっていないことを、確認することができた。