Active Directory

Windows LAPSでWindowsのローカル管理者パスワードを管理！ この記事の内容 Windows LAPS（Local Administrator Password Solution）の概要と目的を解説します ローカル管理者パスワードを全端末で共通化することのセキュリティリスクを説明します LAPSがどのような仕組みでパスワードを自動管理・バックアップするかを紹介します 生パスワードをディレクトリに保存することへの懸念と、現実的な安全性について解説します まだ導入していない組織に向けて、導入の効果とおすすめの運用方法をご紹介します Windows LAPSとは Windows LAPSは、Windows端末上のローカル管理者アカウントのパスワードを自動的に管理・バックアップするための機能です。 対象となるのは以下のような端末です。 Microsoft Entra ID（旧Azure AD）に参加済みのデバイス Windows Server Active Directoryに参加済みのデバイス つまり、オンプレミスのActive Directory環境でも、クラウドのEntra ID環境でも利用できる仕組みとなっています。 LAPSはローカル管理者アカウントのパスワードを定期的に変更し、その情報をディレクトリ（ADまたはEntra ID）に安全に保存します。管理者は必要なときにパスワードを取得してログインできます。 なぜローカル管理者パスワードの管理が重要なのか 通常、組織で展開されるWindows端末には「Administrator」アカウントが存在します。多くの組織では、イメージ展開や自動セットアップの都合上、すべての端末で同じパスワードを設定してしまうケースがよく見られます。 しかしこの構成には大きなリスクがあります。 もし1台の端末が侵害されると、他の端末にも簡単に横展開（ラテラルムーブメント）されてしまいます 共通パスワードの漏洩によって、全端末が乗っ取られる可能性があります 本来は各端末ごとに異なるパスワードを設定すべきですが、手動で行うのは現実的ではありません。数百台・数千台規模の端末に個別設定を行うには膨大な工数がかかります。 そこで登場するのが Windows LAPS です。 Windows LAPSの仕組み LAPSを導入すると、各端末のローカル管理者パスワードが自動生成・定期更新され、以下のように安全に管理されます。 端末側で新しいパスワードを生成します そのパスワードをActive DirectoryまたはEntra IDに保存します 保存されたパスワードは管理者のみが取得可能です 保存先は、オンプレミスADのコンピューターアカウント属性拡張（スキーマ拡張）や、Entra ID上の安全なストレージ領域となります。このようにして、各端末のパスワードがすべて異なる状態を自動的に維持できます。 管理者は必要なときにLAPSの管理ツールやポータルを使って対象端末のパスワードを読み出し、ログインできます。 「生パスワードを保存する」ことへの懸念と現実的な安全性 LAPSでは実際に**生のパスワード（プレーンテキスト）**をディレクトリに保存します。「パスワードをハッシュ化せずに保存するなんて危険では？」と思うかもしれません。 確かに一般的なサービスやWebサイトでは、パスワードはハッシュ化して保存するのが常識です。しかしLAPSの場合、パスワードを後から管理者が取得してログインする必要があるため、ハッシュ化では目的を果たせません。 この設計にはリスクが伴いますが、以下の理由から現実的には問題ありません。 パスワードへのアクセス権は管理者（ドメイン管理者やEntra管理者）に限定されています もしその権限が侵害されている場合、すでに環境全体が乗っ取られている状態であるため、LAPSの情報が見られても被害の範囲は変わりません 適切な監査ログや権限昇格（Just-In-Timeアクセス）などの仕組みと併用することで、十分な安全性を保てます つまり、「共通パスワードを使い続けるリスク」よりも、LAPSを使って個別管理するほうが圧倒的に安全です。 導入の効果とおすすめの運用 LAPSを導入することで、以下のような効果を得られます。 各端末のローカル管理者パスワードを自動的に一意化できます 定期変更によってセキュリティを強化できます パスワードの取得・監査が容易になります ADまたはEntra IDへの統合管理が可能になります また、既存の「Administrator」アカウントを無効化し、別の管理者アカウントを運用する構成も推奨されています。 構成はグループポリシーやIntune（CSP）から設定可能で、特別な仕組みを導入しなくてもすぐに始められます。 まとめ Windows LAPSは、現実的で効果的なローカル管理者パスワード管理ソリューションです。組織内で共通パスワードを使い続けることの危険性を解消し、セキュリティを大幅に向上させることができます。 ...

【中編】ファイルサーバーのハイブリッド化とKerberos認証 ― シームレスSSOの仕組みを理解する この記事の内容 オンプレミスのActive DirectoryとEntra ID（旧Azure AD）における認証方式の違いを解説します シームレスSSOの仕組みと、KerberosチケットをクラウドSSO実現に活用する方法を紹介します Entra Connect SyncでシームレスSSOを有効化する具体的な構成手順を説明します グループポリシーによるブラウザのイントラネットゾーン設定方法を解説します klistコマンドを使った動作確認の方法を紹介します オンプレミスとクラウドの認証の違い オンプレミス環境では、Active Directory（AD）によってユーザー認証が行われます。ユーザーがWindowsにログインすると、**TGT（Ticket Granting Ticket）**と呼ばれるKerberosチケットを取得します。このチケットを使って、ファイルサーバーやデータベースなどの各種サービスへアクセスできます。 一方、クラウド側、例えば Microsoft 365（M365） や Dynamics 365 にアクセスする場合は、**Entra ID（旧Azure AD）**が認証基盤として機能します。通常の流れでは、ユーザーがWeb画面でIDとパスワードを入力し、多要素認証（MFA）を経てEntra IDからトークンを受け取り、そのトークンをもってクラウドサービスへアクセスします。 このように、オンプレミスは「Kerberosチケット」、クラウドは「トークンベース認証」という異なる仕組みを持っています。そこで登場するのが、両者を橋渡しする シームレスSSO です。 シームレスSSOとは ― Kerberosチケットでクラウドに入る仕組み シームレスSSOは、オンプレミスでログインしたユーザーが再度パスワードを入力することなく、クラウドサービスにアクセスできるようにする仕組みです。 その鍵を握るのが Kerberosチケットの再利用です。Entra IDがKerberosチケットを受け取れるよう設定すると、ユーザーはオンプレミスで既に取得しているTGTを利用してクラウド認証をスキップできます。 これを構成する際に使うのが Azure AD Connect（現在のEntra Connect Sync） です。 構成手順：Entra ConnectでシームレスSSOを有効化する 1. Entra Connect Syncの設定 Entra Connect Syncの設定画面で「ユーザーサインイン方法」を選択します。「パスワードハッシュ同期」と「シングルサインオンを有効化」を選びます。 2. ドメイン管理者の資格情報を入力 Active Directoryフォレスト内に新しいコンピューターアカウントが自動的に作成されます。 3. 作成されるアカウント：ADSSOACC このアカウントにはサービスプリンシパルネーム（SPN）が登録されます。SSOに関連するURLとして、以下のようなURLがSPNとして登録されます。 h h t t t t p p s s : : / / l a o a g d i g n . . w m i i n c d r o o w s s o . f n t e o t n . l n i x n . e n . e c t o m この設定により、Entra IDはKerberosチケットを正しく認識し、トークンを発行できるようになります。 ...

【後編】ファイルサーバーのハイブリッド化とKerberos認証 — Microsoft Entra ID時代の認証設計を考える この記事の内容 ハイブリッド環境におけるWindowsクライアントの3つの参加形態（オンプレミスAD参加・ハイブリッドジョイン・Entra参加）を解説します Azure FilesがオンプレミスADおよびMicrosoft Entra Kerberosの2種類のIDソースに対応していることを紹介します Microsoft Entra IDがKDCとして動作し、クラウド上でKerberosチケットを発行する「Microsoft Entra Kerberos」の仕組みを説明します クラウドオンリーユーザーがKerberos認証を利用できない現状の制約と、その背景にあるSIDの課題を整理します Entra Domain Servicesによる代替策や、クラウド信頼（Cloud Trust）の構成パターンも取り上げます はじめに 本記事はシリーズの後編です。前編では、ワークグループ環境とActive Directory（AD）環境の違い、Kerberos認証の基礎となるTGT（Ticket Granting Ticket）とサービスチケットの概念、そしてSSOの動作について解説しました。 後編では、Microsoft Entra IDがKerberos認証をどのように扱うかを中心に、クラウド上でのKerberos認証の最新動向と、ハイブリッド環境における認証設計のポイントを詳しく説明します。 前回までの復習：認証の仕組みとシームレスSSO オンプレミスADではチケットベースのSSOが可能ですが、クラウド側のEntra IDはトークンベースの認証を採用しています。両者の認証プロトコルが異なるため、両環境を橋渡しする仕組みとしてシームレスSSOが存在します。 シームレスSSOは、オンプレミスで取得したKerberosチケットをEntra IDに提示し、クラウド側からトークンを受け取ることで認証を継続するものです。この仕組みによって、ユーザーはオンプレミスとクラウドの両環境にわたって、シームレスな認証体験を得られるようになっています。 ハイブリッド環境におけるWindowsクライアントの参加形態 ハイブリッド化を考える上で、まずクライアント端末の参加形態を整理することが重要です。主に次の3つのパターンがあります。 オンプレミスADドメインにのみ参加しているクライアント ハイブリッドジョイン（Hybrid Join）しているクライアント クラウド側のEntra IDにのみ参加しているクライアント（Entra Join） ハイブリッドジョインでは、オンプレミスのコンピューターオブジェクトをEntra IDにも登録し、クラウド側から端末を信頼できるようにします。これにより、Entra IDが端末の状態を把握してアクセス制御を行えるようになります。 一方、最近のWindowsではオンプレミスADがなくても直接Entra IDに参加する**クラウド参加（Entra Join）**も可能です。これにより、オンプレミスとクラウドの両構成を柔軟に選択できるようになりました。 ファイルサーバーの構成パターン クライアントが多様化する一方で、ファイルサーバー側にも複数の構成があります。 従来型：オンプレミスADドメイン参加サーバー オンプレミスのADをIDソースとしてKerberos認証を利用する、長年にわたり安定して使われてきた一般的な構成です。 クラウド型：Azure Files Azure上でファイル共有を提供するサービスです。初期は「ストレージアカウントキー」や「SASトークン」によるシンプルな認証方式を採用しており、ユーザー単位の権限管理はできませんでした。 しかし現在のAzure Filesは、次の2つのIDソースに対応しています。 Active Directory Domain Services（オンプレミスAD） Microsoft Entra Kerberos（クラウド側のKerberos認証） このうち特に注目すべきは後者のMicrosoft Entra Kerberosです。Entra IDが自らKerberosチケットを発行・受け取ることにより、クラウドだけで認証を完結できる仕組みです。 AD DSをIDソースとするAzure Files認証 オンプレミスADを認証サーバーとして利用する場合、Azure Files側にSPN（Service Principal Name）を登録します。これにより、Azure FilesがオンプレミスのKerberosチケットを受け入れられるようになります。 ...

【前編】ファイルサーバーのハイブリッド化！認証の進化をパケットで確認！SMB・NTLM・Kerberos この記事の内容 ワークグループ環境でのSMB・NTLM認証の仕組みと課題を解説します Active Directory環境でKerberos認証がどのように動作するかを説明します パケットキャプチャを通じて、NTLMとKerberosの違いを具体的に確認します サービスプリンシパルネーム（SPN）の役割とCIFS・Hostの関係を説明します オンプレミスからクラウドへの認証進化の流れを整理します はじめに クラウド環境が普及した現在でも、Kerberos認証は多くの場面で利用されています。本記事では、身近なファイルサーバーを題材に、クラウドやオンプレミスの端末からファイルサーバーを利用する際、認証プロトコルがどのように進化してきたのかを解説します。シングルサインオンをはじめとした最新の認証手法やプロトコルの違いについても、パケットの観点から掘り下げていきます。 オンプレミスのActive Directory環境を利用しつつもクラウド活用を検討している方、ファイルサーバーの運用やクラウドストレージへの移行を考えている方、認証プロトコルの仕組みに興味がある方に特におすすめの内容です。 ワークグループ環境とNTLM認証 ワークグループ環境とは まずは認証の基礎から、ワークグループ環境について説明します。ワークグループ環境とは、Active Directoryなどの集中管理されたIDが存在しない、ご家庭や小規模事業でよく見られる構成です。たとえば、家電量販店で購入したWindows PC同士をそのまま使うと、この形態になります。 ローカルアカウントとファイル共有 各Windowsマシンにはローカルアカウントを作成できます。「コンピューターの管理」ツールの「ローカルユーザーとグループ」からユーザーを追加できます。共有フォルダーも作成可能で、Windowsクライアント自体がファイルサーバーとして機能します。 SMBとNTLM認証の仕組み この環境で他のPCの共有フォルダーへネットワーク越しにアクセスするには、SMB（Server Message Block）プロトコルとNTLM（NT LAN Manager）認証が利用されます。エクスプローラーで以下のように入力すると、「ネットワーク資格情報の入力」が求められます。 \ 1 0 . 1 . 1 . 4 ここで入力するユーザー名とパスワードはアクセス先サーバーのローカルアカウントです。サーバー側に該当ユーザーが存在しない場合は認証失敗、存在すればアクセスが可能です。 パケットレベルで見るNTLM認証 パケットキャプチャを行うと、以下の流れが確認できます。 TCP 445番ポートへの3ウェイハンドシェイク SMBプロトコルネゴシエート（バージョン交渉） NTLM認証の選択 SMB2プロトコルとNTLM認証のやり取りがパケット上で明示されており、認証の流れを視覚的に把握できます。 ワークグループ環境の課題 この方式では、ファイルサーバーごとに別々のローカルアカウント管理が必要となり、ユーザーは各サーバーで異なるIDとパスワードを覚える必要があります。すべてのサーバーで同じIDとパスワードを使う方法もありますが、セキュリティ上好ましくありません。 この「アカウント分散管理」はワークグループ運用の大きなデメリットです。現在ではほとんど利用されなくなりましたが、20年以上前には一般的な構成でした。 Active Directory環境とKerberos認証 Active Directoryの概要 ワークグループ環境の課題を解決するために登場したのが、Active Directory（AD）環境です。ADではドメインコントローラー（DC）がディレクトリデータベースを持ち、ユーザーやコンピューター、サービスを一元管理します。各マシンは「ドメイン参加」によりドメインと信頼関係を結びます。 Kerberos認証の導入 ファイルサーバーへのアクセス自体はSMBのままですが、認証方式はKerberosへと進化しました。KerberosはNTLMより遥かにセキュアで、複雑な仕組みを持っています。 Kerberos認証の流れ Kerberos認証は以下の3ステップで動作します。 ステップ1: TGTの取得 ユーザーがWindowsクライアントにログインすると、ドメインコントローラー（KDC: Key Distribution Center）からTGT（Ticket Granting Ticket）を受け取ります。 ...

仮想基盤上のActive Directory ドメインコントローラーの時刻同期を構成する — 企業でよくあるWindows/M365環境を構築してみるシリーズ Part8 この記事の内容 仮想環境（Hyper-V）上のActive Directory ドメインコントローラーで注意が必要な時刻同期の設定を解説します Hyper-Vの時刻同期統合サービスを無効化し、Windowsタイムサービス（w32tm）による正しい構成に切り替える手順を紹介します PDCエミュレーター（1台目のDC）を外部NTPサーバーと同期させる設定コマンドを紹介します 2台目以降のDCおよびメンバーサーバーはドメイン階層から自動的に時刻同期する構成の確認方法を説明します 設定を怠ると時刻ずれが発生し、Kerberos認証が失敗するなど深刻な障害につながるため、正しく構成されているか確認いただける内容です はじめに このシリーズでは、企業でよくあるWindows/M365環境を検証環境で再現しながら構築しています。前回まででActive Directoryを構築し、ユーザーを追加して同期を設定するところまで完了しました。 しかし、まだ1つ重要な設定が残っています。それが時刻同期の構成です。 Active Directoryにおいて時刻は非常に重要な要素です。特にKerberos認証では、ドメインコントローラーとクライアント間の時刻差が5分以内でなければ認証が失敗します。時刻がずれてしまうと認証エラーが発生し、ドメイン全体に影響が及ぶ深刻な障害となります。 仮想環境でのAD DCサポートについて かなり以前はドメインコントローラーを仮想環境で動作させることが推奨されない時代もありましたが、Windows Server 2012以降は仮想化環境での動作が正式にサポートされています。Server 2016以降はさらに改善が加えられています。 Microsoftの公式ドキュメント「Active Directory ドメイン サービス（AD DS）の安全な仮想化」でも、USNロールバックなどの問題が発生しないよう保護機能が導入されていることが説明されています。 仮想環境でのDCの時刻同期に関する重要な注意点 仮想環境でドメインコントローラーを運用する場合、多くの企業で時刻同期が推奨構成になっていないというケースが見受けられます。 Microsoftのドキュメントでは以下のように説明されています。 仮想環境で動作するドメインコントローラーに対してWindowsタイムサービスを正しく構成するには、ホストとゲスト（DC）間の時刻同期を無効化することが推奨されます Hyper-Vの場合、具体的にはHyper-V時刻同期プロバイダー（統合サービスの「時刻の同期」チェックボックス）をオフにします その上で、PDCエミュレーターが外部NTPサーバーと同期するよう構成します 2台目以降のDCやメンバーサーバーはドメインの階層構造に従って時刻を同期します 現在の時刻同期状態を確認する まず、現在の時刻同期がどのような状態になっているかを確認します。コマンドプロンプトを管理者として開き、以下のコマンドを実行します。 w32tm /query /status 設定変更前は、出力に VMICTimeProvider や VM IC Time Synchronization Provider と表示され、Hyper-Vの時刻同期機能と同期していることが確認できます。 Hyper-Vの時刻同期統合サービスを無効化する Hyper-Vマネージャーから、ドメインコントローラーの仮想マシンの設定を変更します。変更はVMをシャットダウンした状態で行います。 Hyper-Vマネージャーで対象VMを右クリックし、**「シャットダウン」**を選択します VMの**「設定」**を開きます 左メニューの**「統合サービス」**を選択します 「時刻の同期」チェックボックスをオフにします 「OK」をクリックして設定を保存します 複数のDCがある場合は、すべてのDCで同様の操作を行います。 起動・停止の順序について 複数のDCをシャットダウン・起動する場合、2台目以降のDCから停止し、1台目のDC（PDCエミュレーター）を最後にシャットダウンするとよいでしょう。起動時は逆に1台目のDCを最初に起動します。クラスターなどと同様に、マスターとなるサーバーを最後まで残し最初に起動することで、不要なトラブルを防ぐことができます。 PDCエミュレーターを外部NTPサーバーと同期させる DCを起動したら、フォレストルートのPDCエミュレーター（1台目のDC）に外部NTPサーバーとの同期を設定します。 以下のコマンドを実行します。ntp.nict.jp は国立研究開発法人情報通信研究機構（NICT）が提供する日本の標準時サーバーです。 w32tm /config /syncfromflags:manual /manualpeerlist:"ntp.nict.jp" /update 設定後、以下のコマンドで強制的に再同期します。 ...

ドメインコントローラーの正常性確認方法 — dcdiag と repadmin を使いこなす この記事の内容 Active Directory の管理者向けに、ドメインコントローラー（DC）の正常性確認手順を紹介します dcdiag /v コマンドで複数のテストを実行し、結果の正しい読み方を解説します 最終行の「合格」だけを見る落とし穴と、全テスト結果を確認する重要性を説明します repadmin /replsummary によるレプリケーション状態の確認方法を紹介します 複数 DC 環境での実行方法と、定期確認を習慣化する理由を解説します はじめに Active Directory を管理しているものの、「なんとなく動いているから大丈夫だろう」と感じていませんか？実際には気づかないところでエラーが発生していることは少なくありません。今回はドメインコントローラーの正常性を確認するための基本的なコマンドを紹介します。 今回の環境はドメインコントローラーが 2 台で構成されている環境を例に説明します。 dcdiag /v で論理テストを実行する コマンドプロンプトを起動し、以下のコマンドを実行します。 dcdiag /v このコマンドは、ドメインコントローラーに対して複数の論理テストを実行します。 結果の読み方に注意が必要 よくある誤解として、出力の最後の行だけを見て「合格したから問題なし」と判断してしまうパターンがあります。しかし、最後の行が示しているのは特定のテスト（コネクティビティテストなど）の結果に過ぎません。 出力は上から順に読み進めることが重要です。テストの内訳は以下のようなものが含まれます。 コネクティビティのテスト 認証（Authentication）のテスト イベントログのテスト DFSR（DFS レプリケーション）のテスト その他多数のテスト エラーの例 たとえば出力の途中に次のような結果が現れることがあります。 テ テ ス ス ト . ト . : 失 : 失 敗 敗 F し D し r ま F ま s し S し E た R た v E e v n e t n t このような場合、DFSR のレプリケーションに問題が発生していることがわかります。一見すると最後の合格表示に目が行きがちですが、途中のエラーが実際の問題を示していることがあります。 ...

【Q&A】Active Directory のデメリット この記事の内容 Active Directory（AD）を運用するにはサーバーのハードウェア・OS・技術知識が必要であり、それ自体がオーバーヘッドになる オンプレミス AD はフルクラウド化への移行を難しくする要因になりうる Azure AD Domain Services（マネージドサービス）を使うことで、サーバー管理の負担を軽減できる プリントサーバー・ファイルサーバーが残っていると、フルクラウド化のボトルネックになる Azure Files や Universal Print の活用により、これらのオンプレミス依存を解消できる可能性がある Active Directory のデメリットとは Active Directory（以下 AD）を使ったことがない方から「AD にデメリットはあるのか？」という疑問が寄せられました。メリットが多いとされている AD ですが、もちろんデメリットも存在します。この記事では、その観点を整理して解説します。 サーバーの用意・維持が必要 AD を動かすためには、まずサーバーが必要です。これは大きなデメリットのひとつです。 ハードウェア（物理サーバー）の用意が必要 OS のインストールと設定が必要 サーバーを稼働し続けるためのメンテナンスが継続的に必要 OS のバージョンアップも定期的に対応しなければならない このように、AD を正常に動かし続けるためには、相応の技術的な知識と運用コスト（オーバーヘッド）が発生します。 技術的な知識が求められる AD を構成・運用するには、ディレクトリサービスに関する技術知識が必要です。単にサーバーを用意するだけでなく、AD 自体の設計・設定・トラブルシューティングができる人材を確保・育成する必要があります。これが中小規模の組織では特に負担になることがあります。 マネージドサービスという選択肢 こうしたオーバーヘッドを避けるための選択肢として、Azure AD Domain Services（マネージドサービス） があります。サーバーレスなサービスとして AD の機能を利用できるため、ハードウェアや OS の管理が不要になります。 AWS や Google Cloud にも同様のマネージドサービスが存在しており、クラウドプロバイダーの活用が現実的な選択肢になっています。 一方、Windows の環境で Active Directory を中核として使い続ける場合は、やはりオンプレミスの AD が有効という考え方もあります。 フルクラウド化の障壁になりうる 現在クラウド移行を進めている組織にとって、オンプレミスの AD は「フルクラウド化」の妨げになるケースがあります。 ...

【Q&A】ADドメイン間のユーザー移行にCSVDEは使えません この記事の内容 ADドメイン間のユーザー移行にCSVDEコマンドを使おうとした際に発生するよくある誤解を解説します CSVDEが「使えない」理由と、何のためなら使えるかを整理します ドメイン移行で本当に重要なのはSIDヒストリーの引き継ぎであることを説明します ドメイン移行に適切なツール（ADMT）を紹介します 質問の内容 「ActiveDirectoryのユーザー移行について教えてください。Windows Server 2016環境にドメインのユーザーやグループを移行したいのですが、CSVDEコマンドを使ってインポートしようとするとエラーが発生します」 このような質問はよく寄せられます。まず結論からお伝えすると、ドメイン間のユーザー移行にCSVDEを使うのはそもそも適切ではありません。 CSVDEとは何か CSVDEは、ActiveDirectoryのオブジェクト（ユーザー、グループなど）をCSV形式でエクスポート・インポートするためのコマンドラインツールです。 csvde -f export.csv -r "(objectClass=user)" 同じドメイン内で同名のユーザーを大量作成したい場合や、テスト環境で本番環境と同じ構成のユーザーを素早く用意したい場合には有効です。たとえば「テスト環境に本番と同じユーザーを作りたい」といったシナリオであれば、CSVDEは十分に活用できます。 ドメイン移行にCSVDEが使えない理由 ドメイン間のユーザー移行においてCSVDEが使えない最大の理由は、SIDヒストリー（SID History）を引き継げないからです。 Windowsのアクセス権限は、ユーザー名ではなくSID（セキュリティ識別子）に紐付いています。ドメインが変わると新しいSIDが割り当てられるため、たとえ同じユーザー名でアカウントを作り直しても、移行前にアクセスできていたリソース（ファイルサーバー、共有フォルダなど）へのアクセス権限は引き継がれません。 CSVDEはあくまでADオブジェクトの属性をCSVで出し入れするツールであり、SIDヒストリーをきちんと移送する仕組みは備わっていません。 つまり、「ユーザーを移行した」はずなのに「リソースにアクセスできない」という問題が発生します。これが、ドメイン移行にCSVDEが適さない本質的な理由です。 ドメイン移行に適切なツール：ADMT ドメイン間のユーザー移行には、**ADMT（Active Directory Migration Tool）**を使用してください。 ADMTはMicrosoftが提供するドメイン移行専用ツールで、以下を適切に処理します。 ユーザー、グループ、コンピューターオブジェクトの移行 SIDヒストリーの引き継ぎ（移行後も旧ドメインのリソースにアクセス可能） パスワード移行（Password Export Server（PES）と組み合わせて使用） SIDヒストリーが引き継がれることで、移行後のユーザーは移行前と同様にファイルサーバーや各種リソースにアクセスし続けることができます。これがドメイン移行における最も重要なポイントです。 まとめ 用途 CSVDEの適否 同ドメイン内での一括ユーザー作成 ✅ 使用可 テスト環境への同名ユーザー作成 ✅ 使用可 ドメイン間のユーザー移行 ❌ 使用不可 ドメイン間のユーザー移行は、単純に「同じ名前のアカウントを作り直す」作業ではありません。SIDヒストリーを含めたアクセス権限の完全な引き継ぎが不可欠です。 そのためには、CSVDEではなく**ADMT（Active Directory Migration Tool）**を正しく学んで使用することが重要です。移行プロジェクトを始める前に、ADMTの仕組みとSIDヒストリーの概念をしっかり理解しておくことをお勧めします。