SIDClonerでsIDHistoryを構成してみる

Microsoft

2023.02.22

     

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の利用イメージ
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. ソフトウェア構成
  • Windows Server 2019 OS Active Directory
    • Windows Server 2016ドメイン機能レベル(ADMT資料等で2003レベルでも問題ない理解)
    • Administratorパスワードは異なるもの
    • 信頼関係はなし
    • DNS条件付きフォワーダーで相手先ドメインコントローラーを指定
  • SIDCloner
    • PowerShell 7
    • Visual C++ 2015-2022再頒布可能パッケージ
  • Windows Server 2019 OS File Server
    • 移行元ドメインに参加、ファイル共有を作成

2. 環境構築の詳細

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

2.1. Active Directoryの構成
  • 移行元ドメイン名
    • old.msp.intellilink.co.jp
    • User00の作成
    • Group00の作成(user00がメンバー)
  • 移行先ドメイン名
    • new.msp.intellilink.co.jp
    • User00の作成
    • Group00の作成(user00がメンバー)
  • ファイルサーバー
    • Group00フルコントロールの共有アクセス許可
    • Group00フルコントロールのNTFSアクセス許可
  • 条件付きフォワーダー
    • 移行元にnew.msp.intellilink.co.jpを指定
    • 移行先にold.msp.intellilink.co.jpを指定
2.2. sIDHistory移行用の設定
  • 移行元移行用グループの作成
    • OLD$$$グループの作成(ドメインローカル)
  • 移行元監査ポリシーの設定
    • アカウント管理の監査(成功,失敗)
    • ディレクトリサービスのアクセスの監査(成功,失敗)
  • 移行先監査ポリシーの設定
    • アカウント管理の監査(成功,失敗)
    • ディレクトリサービスのアクセスの監査(成功,失敗)

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

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

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

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

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

  • PowerShell 7を起動し、以下コマンドレットを入力実行
  • Install-Module -Name SidCloner -AllowPrerelease

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

  • PowerShell 7から、以下コマンドレットを入力実行
  • Import-Module -name SIDCloner
  • $SCred=Get-Credential(移行元管理者資格を設定)
  • $TCred=Get-Credential(移行先管理者資格を設定)
  • Copy-Sid -SourceDomain old.msp.intellilink.co.jp -TargetDomain new.msp.intellilink.co.jp -SourceCredential $SCred -TargetCredential $TCred -SourcePrincipal user00 -TargetPrincipal user00
  • Copy-Sid -SourceDomain old.msp.intellilink.co.jp -TargetDomain new.msp.intellilink.co.jp -SourceCredential $SCred -TargetCredential $TCred -SourcePrincipal group00 -TargetPrincipal group00

Result

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

Copy-Sid -SourceDomain <移行元DNS名> -TargetDomain <移行先DNS名> -SourceCredential <移行元資格情報> -TargetCredential <移行先資格情報> -SourcePrincipal <移行元saMAccount名> -TargetPrincipal <移行先saMAccount名>

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

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

  • ファイルサーバー上で、以下ドメインに再参加
    • new.msp.intellilink.co.jp
  • 再起動後、IPv4の[参照先DNSサーバー]を変更
    • 移行先ドメインコントローラーIPアドレス

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

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

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

2.7. 最終結果の確認

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

  • 移行ユーザーでサインイン
    • NEW\user00
  • 共有フォルダーにアクセス
    • \\chaboldfs\Share
2.8. sIDHistoryを取り除いた際の挙動

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

  • PowerShell 5.1(一般的なPowerShell)で、sIDHistory情報の削除
  • Get-ADUser user00 -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}
  • Get-ADGroup group00 -properties sidhistory | foreach {Set-ADGroup $_ -remove @{sidhistory=$_.sidhistory.value}}

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

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

※文中の商品名、会社名、団体名は、各社の商標または登録商標です。

SIDClonerでsIDHistoryを構成してみる