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は、現実的で効果的なローカル管理者パスワード管理ソリューションです。組織内で共通パスワードを使い続けることの危険性を解消し、セキュリティを大幅に向上させることができます。 ...

仮想基盤上の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 設定後、以下のコマンドで強制的に再同期します。 ...

Active Directoryへ2台目のドメインコントローラーを追加する この記事の内容 既存のActive Directory環境に2台目のドメインコントローラーを追加する手順を解説します Active Directoryサイトの概念と役割について説明します ドメインコントローラー昇格直後に発生するエラーの見方と対処法を紹介します dcdiag コマンドを使った診断の方法と注意点を解説します ドメインコントローラー追加後に絶対にやってはいけないことを説明します 前提環境 本記事では、すでに1台目のドメインコントローラー（DC01）が稼働しているWindows Server Active Directory環境に、2台目のサーバー（DC02）をドメインコントローラーに昇格させる手順を解説します。DC02はあらかじめドメインへのメンバーサーバーとして参加済みの状態からスタートします。 役割と機能の追加 DC02に対して、Active Directoryドメインサービス（AD DS）の役割を追加します。手順はDC01を構築した際と同様です。サーバーマネージャーから「役割と機能の追加」ウィザードを起動し、Active Directoryドメインサービスを選択してインストールします。 ドメインコントローラーへの昇格 AD DSのインストールが完了したら、ドメインコントローラーへの昇格ウィザードを起動します。ここで重要な選択肢があります。 ウィザードには以下の3つの選択肢が表示されます。 新しいフォレストを追加する 既存のフォレストに新しいドメインを追加する 既存のドメインにドメインコントローラーを追加する ← 今回はこちら すでにActive Directoryが存在する環境に2台目のドメインコントローラーを追加したい場合は、必ず「既存のドメインにドメインコントローラーを追加する」を選択してください。 操作を実行するための資格情報には、Domain Adminsなど最強権限を持つアカウントを使用します。 ドメインコントローラーオプションの設定 次の画面では、以下の項目を設定します。 ドメインネームシステム（DNS）サーバー: チェックを入れる グローバルカタログ（GC）: チェックを入れる ディレクトリサービス復元モード（DSRM）パスワード: 1台ごとに個別に設定が必要なため、このタイミングで入力する Active Directoryサイトについて ウィザードの途中でサイトを選択する画面が表示されます。ここでActive Directoryの「サイト」という概念を説明します。 サイトとは サイトとは、物理的なネットワークの場所を表す論理的な区画です。たとえば「東京オフィス」「大阪オフィス」のように複数のサイトを作成し、どのサブネットがどのサイトに属するかを定義できます。 サイトを使うメリット クライアントは自分が属するサイトを認識でき、そのサイト内にいるドメインコントローラーに優先的にログイン要求を送ります。これにより、地理的に近いドメインコントローラーへの自動ルーティングが実現します。 また、サイトが複数ある場合は、同じサイト内では頻繁にレプリケーションを行い、別サイトへのレプリケーションはまとめて夜間に行うなど、レプリケーショントポロジのコントロールが可能になります。 今回の環境 今回はサイトが1つだけ（Default-First-Site-Name）存在する構成のため、サブネットの定義は行わず、デフォルトのサイトをそのまま使用します。 レプリケーション元の指定 続いて、初期データをどのドメインコントローラーからレプリケートするかを指定する画面があります。現時点では1台しかないためどちらを選んでも結果は同じですが、複数台構成や複数サイト構成になった場合には、この設定がレプリケーション効率に影響します。 パスの確認とディスク設定 ADのデータベース、ログファイル、SYSVOLのパスを確認します。専用のドライブを用意しておくことが推奨されます。今回はウィザード内で新しいシンプルボリュームを作成してから設定を進めます。 設定が完了したらウィザードを完了させます。処理が終わると自動的に再起動されます。 昇格の確認 再起動後、サーバーマネージャーやActive Directoryサイトとサービスを確認します。 Active Directoryサイトとサービスを開くと、Default-First-Site-Name の中にDC02が追加されていることが確認できます Active Directoryユーザーとコンピューターを開くと、DC02がコンピューターのOUからドメインコントローラーのOUへ移動していることが確認できます これでDC02がドメインコントローラーとして認識されたことが確認できました。 dcdiag による診断 昇格直後に診断コマンドを実行してみましょう。 ...

Active Directoryへのドメイン参加 — 企業でよくあるWindows/M365環境を構築してみるシリーズ Part6 この記事の内容 既存のドメインコントローラー（DC01）の正常性確認方法（dcdiag / repadmin） 2台目のWindows Serverを追加してActive Directoryドメインへ参加させる手順 ドメイン参加時のDNS設定の重要性 Active Directoryユーザーとコンピューター（ADUC）でのオブジェクト確認 ドメインユーザーとローカルユーザーの違いと、ドメイン参加後のサインイン方法 はじめに 前回はドメインコントローラー（DC01）を1台構築しました。今回はそのDC01が正常に動作しているかを確認した上で、2台目のドメインコントローラー候補となるWindows Server（DC02）を追加し、Active Directoryドメインへ参加させるまでの手順を解説します。 次回はこのDC02をドメインコントローラーへ昇格させる手順を紹介予定です。 ドメインコントローラーの正常性確認 何か問題が発生したとき、「もともと壊れていたのか、追加したら壊れたのか」を切り分けることは非常に重要です。そのため、新しいサーバーを追加する前には必ず現状の正常性を確認しておきましょう。 dcdiag /v による確認 dcdiagコマンドを使うと、ドメインコントローラーに関する多数のテストを自動実行し、結果を一覧で表示してくれます。 dcdiag /v 実行するとたくさんの出力が流れますが、各テスト項目に対して「合格（passed）」や「失敗（failed）」が表示されます。以下のようなテストが実行されます。 接続性テスト（Connectivity） 広告テスト（Advertising） FRS/KCCイベントのテスト システムログの確認 DNS参照の確認 など多数 すべて合格であれば、ドメインコントローラーは正常に動作していると判断できます。暇があれば定期的に実行しておくことをおすすめします。 repadmin による複製状況の確認 2台以上のドメインコントローラーがある環境では、repadminコマンドで複製（レプリケーション）の状態も確認します。 repadmin /replsummary 1台構成の今は特に意味はありませんが、エラーが出ないことの確認として実行しておくと安心です。 2台目のWindows Serverの追加 DC01の正常性が確認できたので、次にDC02となる新しいWindows Serverを追加します。 仮想マシンの作成 手動でやる場合は「新規仮想マシン」として作成します。IaC（Infrastructure as Code）を使っている場合は、Ansibleなどのプレイブックを実行するだけで展開できます。 ansible-playbook create_vm.yml コードによる展開はサーバー追加が非常に手軽になるため、ぜひ活用してみてください。 DNSの設定（重要） DC02を作成する際、DNSサーバーのアドレスとして既存のDC01を指定することが非常に重要です。 D N S サ ー バ ー : < D C 0 1 の I P ア ド レ ス > ドメインに参加する際、WindowsはDNSを使ってドメイン名からドメインコントローラーを探します。既存のドメインコントローラー（DC01）がDNSサーバーを兼ねているため、DC02のDNS設定にDC01を指定しておかないと、後のドメイン参加処理が失敗します。 ...

Active Directory 構築解説 — 企業でよくあるWindows / M365環境を構築してみる Part5 この記事の内容 Active Directory ドメインサービス（AD DS）とは何か、なぜオンプレミス環境で必要なのかを解説します Windows Server へのAD DSロール追加から、ドメインコントローラーへの昇格までの手順を紹介します フォレスト・ドメイン・機能レベルなどの重要概念についても触れます ドライブ設計やDNSとの関係など、実運用で重要なポイントを解説します 冗長化（ドメインコントローラーを2台以上構成すること）の必要性についても説明します シリーズの概要と前提環境 このシリーズは、企業で一般的に使われているWindowsサーバーおよびMicrosoft 365環境を実際に構築しながら解説していくものです。冗長化なども考慮した「現場でそのまま使えるレベル」を目指しています。 Part4までで、物理サーバー（Lenovo ThinkSystem SE350）上にNested Hyper-Vを有効化した仮想マシンを作成し、Ansibleを使って仮想マシンの展開やネットワーク設定を自動化できる下準備が整いました。Part5からはいよいよ本題に入ります。 Active Directoryとは Active Directory（AD）は、主にWindowsサーバーやクライアントをまとめて管理するためのディレクトリサービスです。ユーザー、グループ、コンピューターなど、組織内のさまざまなリソースをディレクトリに登録し、一元管理することができます。 オンプレミスのWindows環境においては、Active Directoryはほぼ必須の存在です。ただし、その概念を完全に理解するには相応の学習が必要です。主要な学習項目だけでも相当な量があり、実際の現場管理者でなければ聞き慣れない用語が多く並びます。本シリーズでは「まず作って、動かしながら理解する」というアプローチで進めていきます。 また、Active Directoryにはいくつかの種類がありますが、今回はその基本となる**Active Directory ドメインサービス（AD DS）**を構築します。 Active Directoryの各サービスについて Windows Serverのロール一覧には、AD関連として以下のものが並んでいます。 サービス名 現在の推奨状況 Active Directory ドメインサービス（AD DS） 現在でも主力。オンプレミスでは必須 Active Directory フェデレーションサービス（AD FS） 非推奨。クラウド化が進み今から入れるべきではない Active Directory Rights Management Services（AD RMS） 非推奨。クラウド版への移行が進んでいる Active Directory ライトウェイトディレクトリサービス（AD LDS） 場合によっては使用する Active Directory 証明書サービス（AD CS） 現在でも利用する組織が多い AD FSとAD RMSは今から新規に構成することは推奨されません。今回はAD DSに集中します。 ...

ドメインコントローラーの正常性確認方法 — 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ヒストリーの概念をしっかり理解しておくことをお勧めします。

【Q&A】ドメイン参加時のコンピューターアカウントの重複 この記事の内容 Active Directory 環境でコンピューターを入れ替えた際に「コンピューターアカウントが重複している」というエラーが発生する原因を解説します ドメイン参加の権限を持つユーザーについて整理します 一般ドメインユーザーがドメイン参加できる台数制限（デフォルト10台）について説明します 組織がドメイン参加を管理するための一般的なパターンを紹介します コンピューターアカウントを事前作成して権限を付与するアプローチについて解説します 質問の内容 今回いただいた質問は次のような内容です。 Active Directory 環境に参加していた Windows 7 マシンを Windows 10 に新規で入れ替えた際、同じコンピューター名でドメインに再参加させようとしたところ、「コンピューターアカウントが重複しているため、削除してください」というエラーが発生した。なぜこのようなことが起きるのか？ この問題は Active Directory のドメイン参加の仕組みや権限まわりが絡んでくるため、少し複雑な話になります。 ドメイン参加の基本的な流れ Active Directory 環境では、Windows PC をドメインに参加させると、Active Directory 上に コンピューターアカウント が作成されます。DNS の参照やネットワーク疎通が確保された状態で、ユーザーが資格情報を使ってドメイン参加操作を行うと、このアカウントが作られる仕組みになっています。 ドメイン参加できるのは誰か ドメイン参加には 権限を持つユーザー が必要です。重要なのは、「ドメイン管理者（Domain Admin）でなくても、一般のドメインユーザーでもドメイン参加ができる」という点です。 Active Directory のデフォルトの動作として、一般ドメインユーザーは 最大10台まで ドメイン参加させることができます。11台目以降はエラーとなります。 この仕様はあまり知られていないことも多く、「一般ユーザーでもドメイン参加できるんですか？」と驚かれることもあります。 一般ユーザーによるドメイン参加のリスク 一般ユーザーでもドメイン参加できるということは、極端な話、自宅のパソコンを会社のネットワークにつないで、自分のドメインアカウントでドメイン参加してしまうことが可能 になります。 これは BYOD（Bring Your Own Device）を許可している組織であれば問題ありませんが、多くの組織ではセキュリティ上の理由からこれを禁止したいと考えています。 組織でよく使われる管理パターン パターン1：一般ユーザーのドメイン参加を禁止する 設定によって一般ユーザーのドメイン参加を禁止し、ドメイン管理者（または専用の作業用アカウント）だけがドメイン参加できる 状態にするパターンです。 PC のセットアップ・キッティング作業は管理者権限を持つ担当者が行い、エンドユーザーに代わってドメイン参加を実施します。一般ユーザーがドメイン参加しようとするとエラーになります。 パターン2：コンピューターアカウントを事前作成して権限を設定する Active Directory 上にあらかじめコンピューターアカウントを作成しておき、「このアカウントには〇〇さんがドメイン参加できる」という形で 特定のユーザーに参加権限を付与 するパターンです。 たとえばキッティング作業を外部委託する場合、作業者にドメイン管理者権限を渡すのは権限が強すぎます。そこで、作業専用アカウントを発行し、そのアカウントであれば特定のコンピューターアカウントに対してドメイン参加できるよう設定しておく、という運用が可能です。 今回のエラーの原因 冒頭の質問に戻ります。今回のエラー「コンピューターアカウントが重複しているため削除してください」が発生した原因は次のように考えられます。 ...