ADリプレースの勘所、教えます

IIJでは、Active Directory(AD)をクラウドでサービス提供しています。既存ADからの移行作業も含めてお客様と共に検討しながら対応する中で、よくこんな課題を耳にします。

  • クラウドに移行したいけどきちんと移行できるか不安
  • 移行作業に失敗すると影響が大きいので不安
  • 移行作業の流れがよくイメージできないので不安

ADは奥が深く、その影響範囲も大きなコンポーネントです。クラウドに移行する場合でも、オンプレミスでリプレースする場合でも、既存ADをリプレースするのには知識と経験が求められます。企業規模が大きくなるほどその影響範囲も大きく、失敗すると甚大な影響が出てしまうこともあります。AD移行の流れを理解しつつ、注意すべきポイントや対応方法などを事前にしっかりと確認した上で進めることが重要です。

本記事では、AD・WSUS(Windows Server Update Services)、ファイルサーバの導入案件でパートナーとして協業している株式会社ソフトクリエイトの村松様に、ADリプレースの勘所を聞きました。

株式会社ソフトクリエイト
技術本部 デジタルサービス統括部 マイクロソフトサービス部
マイクロソフトサービス第1G 技師長 村松 真氏
目次
  1. ADリプレースの基本的な流れ
  2. ポイント1:既存のADの設定は健全ですか?
  3. ポイント2:FSMOの移行について
  4. ポイント3.グループポリシーの見直し
  5. 番外編:WSUSについて
  6. クラウドサービスもぜひご検討ください!
事前チェックからご利用までの流れも掲載!
ADクラウド化のガイドブックをダウンロード(無料)

ADリプレースの基本的な流れ

一般的なADリプレースの流れは以下のとおりです。

【Active Directory】一般的なリプレース作業イメージ

この流れの中で、特に注意すべきポイントを一つずつなぞっていきます。

ポイント1:既存のADの設定は健全ですか?

リプレース前にチェックしたいのが、「そもそも既存のADの設定や構成が健全か?」という部分です。既存環境が健全でないと、リプレース作業が失敗したり、無理に移行するとADが壊れてしまうリスクがあります。健全性に問題がある例としては以下のケースが挙げられます。

  • ドメインコントローラ同士の同期が失敗している。
  • イベントログに大量のエラーが出ている。
  • インフラストラクチャマスターにゴミ情報が残っている(降格に失敗する)。
  • FSMOを保持するサーバーが作動していない。

そこで健全性を確認する方法として、以下の作業を行います。

  • ドメインコントローラの設定情報の収集
  • ドメイン設定情報の収集
  • スキーマ情報の収集
  • DCDiagコマンドによる同期状態の確認
  • イベントログの収集

以下のコマンドやツールを利用して情報を収集します。

  • “netdom /query fsmo”コマンド
  • Active Directoryドメインと信頼関係
  • Active Directoryサイトとサービス
  • DNS
  • regedit

それぞれの細かい操作方法については検索いただくと多くの情報があるため本コラムでは割愛し、収集した情報を確認するポイントをご紹介します。

No. 確認ポイント 詳細
1 ドメインレベル、フォレストレベルの確認 ドメインコントローラのOSとドメインレベルの差で有効なのは2バージョンまでなので、それ以上離れている(古い)場合は移行作業前にドメインレベルを変更
2 SYSVOL同期プロトコル Windows Server 2016以降のOSをドメインコントローラにする場合、同期プロトコルがFRSであれば事前にDFSRに変更
3 ドメインコントローラとしての標準以外の機能の有無 例えば証明機関になっている、ネットワークポリシーサーバーになっているなど。この場合はこれらの機能の移行も忘れずに考慮する
4 グローバルカタログの配置 通常シングルドメインでは、全ドメインコントローラがグローバルカタログを保持していることを確認
5 ドメインコントローラの名称確認 事前に確認していない名前があった場合は、過去に存在していて情報だけがゴミとして残っている場合がある。
“Active Directoryサイトとサービス”を確認するのが一般的
6 ネットワーク設定の確認 バックアップ用にActive Directoryのサービス用以外のネットワーク設定がある場合、移行後に対処が必要。
監視用などにバックエンドのネットワークにのみ接続したNICがあった場合、ドメインコントローラのリストをDNSが返す際に、このバックエンドのIPを返してしまうことがある(当然ユーザーからはそのIPに到達できない)
7 FSMOサーバの確認 役割ごとにサーバが分かれている場合は、理由を含めて移行後に適切に再配置する
8 サイト設定の確認 サイトにドメインコントローラの適切な配置が必要
9 共有設定がNETLOGON、SYSVOL以外に存在するか ファイルサーバ兼用の場合はファイル移行の検討が必要
10 ドメインの信頼関係 状況によっては再設定が必要
11 最終起動日 最終起動日が1年以上前である場合、必要な更新が行われていない可能性が高い。
コマンドプロンプトで“systeminfo”と打つとシステム起動時間が分かる
12 Infrastructure Masterのスキーマ 過去に強制降格などを行っていると、ここにゴミが残り、ドメインコントローラの降格ができなくなる
13 DNSのゾーンの確認 統合ゾーン以外の場合は個別に対処が必要
14 DNSのフォワーダ確認 ドメインコントローラの配置によっては、フォワーダを変更する
15 時刻同期先の確認 PDCエミュレータの役割を持ったドメインコントローラの場合は、再設定が必要
16 起動ログの確認 定期再起動のタスクが仕掛けられている場合がある
17 アプリケーションログと、システムログの確認 重大なエラーが継続して発生している場合、移行の障害になりうる

以上の項目をチェックいただくと良いと思います。

ちなみに、IIJの提供するADサービスの場合、この作業に該当するものとして健全性をチェックするスクリプトをご用意しています。事前にスクリプトで健全性を確認いただくことで、リプレース作業前にリスク分析が可能なサービス設計になっています。

事前チェックからご利用までの流れも掲載!
ADクラウド化のガイドブックをダウンロード(無料)

ポイント2:FSMOの移行について

ADにはIIJが提供しているようなクラウドサービスを利用する方法や、オンプレミスで構成する方法、あるいは両方をハイブリッドで利用する方法があります。その際、Flexible Single Master Operation(FSMO)をクラウド、またはオンプレミスどちらにするのか、その配置構成を検討することになります。
最近では、FSMOは重要な役割なので、安全のためにクラウド配置を望まれるケースが多くなっています。
なお、IIJの提供するADサービスではAD2台が標準提供となるため、FSMOをどちらかに移行してフルクラウドでADの冗長構成を組めるだけでなく、東西マルチリージョン(東に2台、西に2台)の合計4台構成で地理的冗長も組めます。

ポイント3:グループポリシーの見直し

ADをリプレースするタイミングで、グループポリシーも見直しましょう。グループポリシー見直しのポイントは、ポリシーオブジェクトの数のバランスです。
ここでは考え方をお伝えするとして、それぞれの細かい操作方法については検索いただくと多くの情報があるため本コラムでは割愛します。

オブジェクトの数が多すぎると割り当てが煩雑になり運用が難しくなりますし、反対に少なすぎると対象を分けることが難しくなります。ポリシーの数を最小限に抑えながら十分な使い分けをするには、ポリシーの適用範囲を上手にコントロールすることです。
そのためには、OU(組織)だけを使って範囲を指定するのではなく、セキュリティフィルターや、WMIフィルター、基本設定のターゲット機能などを上手く活用していきます。

考え方としては、OUは“クライアントPC”、“サーバ”、“従業員”、“退職者”、“システム”、“外部”のレベルで、クライアントPCは更にその下で拠点レベルなどで分けます。

従業員は事業部や職種など、ポリシーが大きく異なると思われる単位でおおざっぱに分けます。OUを細かく分けると、組織変更などの際に、管理者による変更作業が発生するため運用負荷が上がります。実際にポリシーの対象をさらに細かく分けたい場合(これらのメンバーはこの制限など)は、分けたい単位でセキュリティグループを作ります。そのメンバーに対象ユーザや対象コンピュータを加えた後、グループポリシーのセキュリティフィルターにそのグループを設定します(Authenticated Usersは消す)。

OS単位での設定(Windows 10のみ)など“PCの属性や状態”に依存したポリシー設定を行いたい場合にはWMIフィルターを作成します。WQLという記法で条件を記述すると、その条件に合った場合のみグループポリシーが適用されます。これはポリシー単位で条件を指定します。

さらに細かく、ある拠点の場合はこのレジストリ値を加えるといった制御を行いたい場合には“基本設定”のターゲッティング機能を使います。こちらはIPアドレスの範囲やOSバージョンなど様々な条件を複数組み合わせて指定できるほか、一つのポリシーで複数の設定を、優先順位を付けて指定など、きめ細かな制御が可能です。

select * from Win32_OperatingSystem where Caption = “Microsoft Windows 10 Pro”

ポリシーの内容としては、同じオブジェクトの中で、ユーザ設定とコンピュータ設定を混在させないことや、一つのオブジェクトにあまり設定を詰め込みすぎない方が変更が容易になります。

特にクラウドサービスを利用する場合、サービスによってはオンプレミスで設定したグループポリシーが、そのまま移行できないこともあるため注意が必要です。

ちなみに、IIJの提供するADサービスの場合、オンプレミス環境で設定していたものとまったく同じようにポリシー設定ができます。従ってポリシー設定は維持しつつ、ハードウェアやOSの運用負荷が削減されるため、最小限のリスクでより良いAD環境を整備できます。

番外編:WSUSについて

ADリプレースの際に同じく話題になるのがWSUSです。WSUSリプレースのポイントは、WSUS上のコンピュータや更新プログラム情報を、PowerShellを使って見える化することと、クライアント側のWindows Updateが持つ“配信の最適化”と呼ばれる負荷分散機能を活用してネットワーク負荷を最小限にしつつ、展開がスムーズに進むようにタイミングをコントロールすることです。

PowerShellのコマンドとしては、“Get-WSUSComputer”“Get-WSUSUpdate”などの出力をCSVに保存して、Microsoft Excelで参照して状態把握や進捗管理を行います。クライアント制御にはグループポリシーを活用して、WSUSグループの自動振り分けや、帯域制御、及び適用ポリシーをコントロールします。

IIJの場合は先にご紹介したADサービスのオプションとしてWSUSの機能も提供します。
クラウド側にWSUSが配置されるため、ネットワーク帯域を心配するお客様もいらっしゃいますが、ネットワーク帯域に負荷をかけないようにする機能もあるため、ぜひご検討ください。

クラウドサービスもぜひご検討ください!

以上、ADの見直し、リプレースの注意点・ポイントでした。ここまでご紹介したポイントを踏まえて、検討を進めていただければと思います。

そしてこの記事の中でもご紹介しましたが、IIJはADをクラウドサービスとして利用できるサービスを提供しています。IIJのサービスのメリットとして、

  • ハードウェアの運用、ライフサイクル管理が不要
  • OSレイヤもIIJが提供するため、Windows Updateやアンチウイルス対応などが不要
  • その上オンプレミスと同様の機能を提供

ということで、オンプレミスとクラウドサービス両方のメリットを提供できるサービスです。

せっかくリプレースを検討するならば、単純なハードウェアリプレースではなく、より運用負荷を軽減できるIIJのクラウドサービスを検討候補に入れてみてください!

その際、今回ご紹介したノウハウを豊富にお持ちのソフトクリエイト様による導入支援も可能なので、安心して任せていただけます。

事前チェックからご利用までの流れも掲載!ADクラウド化ガイドブックを差し上げます

「IIJディレクトリサービス ADクラウド化 」(PDF:25ページ)

事前チェックからご利用までの流れ、料金など、導入へのヒントを掲載!

「IIJ IDサービス ID連携+認証強化」(PDF:27ページ)

ADとの認証連携でSSOを実現。接続元IP制限や多要素認証にも対応!