仕組みや設定を学んだ後に出てくるのが、この問いです。時刻同期の設計にも、正解は1つではありません。拠点の数、インターネットの出口、クラウドの有無、求められる精度……どの要件を重く見るかで、選ぶ案が変わります。

連載の最終回となる第11回では、第1回〜第10回の知識を使って、4つの設計演習に取り組みます。答えを覚えるのではなく、要件から案を選ぶ筋道を身に付けましょう。

演習の進め方

• 各問は「問題 → 解答例 → 解説」の順に進みます
• まず5分考え、選ぶ案と、その理由を書き出します。可能なら、chronyc・w32tmで確かめる手順も書きます
• 最初にすべきことは、要件と現状の確認です。問題文に書かれていない条件（予算、体制、将来の拡張）は、どう仮定したかを明記します

案が分かれたら、重く見た要件の違いを比べてみてください。

問1 拠点が3つある会社の時刻同期の階層を設計する

• 状況：従業員500名の会社で、本社（東京）・大阪支社・福岡営業所を閉域網でつないでいる。インターネットの出口は本社だけ
• 機器：本社にDC 2台（うち1台がフォレストルートのPDCエミュレーター、VM）、Linuxサーバー20台、vSphere（ESXi 4台とvCenter）。大阪にDC 1台とLinuxサーバー5台。福岡はサーバーなし。各拠点にルーター・L3スイッチ・複合機、本社にファイアウォール
• 現状：参照先がばらばら。PDCはtime.windows.com、LinuxはOSの既定のプール、ネットワーク機器の一部は停止の方針が出ている福岡大学の公開NTPのまま、複合機は未設定
• 要件：全社の時刻を数十ミリ秒以内でそろえ、インターネットの出口が止まっても社内の時刻はそろったままにする。出口のファイアウォールでNTPを通すサーバーは最小限にする

考えるポイント：外部の時刻源の選び方と数、社内のNTPサーバーの台数と置き場所、PDCエミュレーターとの関係、機器の参照先。

問1 解答例

案Bが基本で、出口の障害でもUTCを保ちたい、または精度を示す必要がある場合に案Cを選びます。どの案でも、ADの時刻の元はPDCエミュレーター1台だけにし、ほかのDCに個別の参照先を設定しません（第5回）。

問1 解説：時刻の階層

外部を4つ以上にするのは、1つが誤っても多数決で外せるようにするためです（RFC 8633。第3回・第7回）。実際にNICTの公開NTPも、2026年9月9日に誤った時刻を10分あまり配信しました。ネットワーク機器やLinuxを、DCではなく社内NTPに向けると、ADの更新作業やDCの再起動の影響を受けずに済みます。

問2 オンプレとAWSのログの時刻をそろえる

• 状況：受注システムのWeb・APサーバーはAWSの東京リージョン（EC2のLinux）、DBと基幹システムとの連携はオンプレの本社にあり、Direct Connectで接続している
• 現状①：EC2はAL2023の既定（Amazon Time Sync Serviceの169.254.169.123）に、担当者がpool.ntp.orgと社内NTPを追加した台と、していない台が混在している
• 現状②：オンプレのLinuxは社内NTP（NICTなどを参照）に合わせている。ログはEC2がUTC、オンプレがJSTで、年やミリ秒がない形式もある
• 要件：障害のとき、両方のログを1つの時系列に並べ、1件の注文の流れを追えるようにする（目安は10ミリ秒以内）。どの時刻源を使っていたかも後から示せるようにする

考えるポイント：EC2とオンプレがそれぞれ何を参照するか、リープスメアの混在、ログの時刻の記録形式。

問2 解答例と解説

2026-09-26T01:23:45.678Z web01 order=A1234 accepted            # EC2（UTC）
2026-09-26T10:23:45.702+09:00 db01 order=A1234 committed       # オンプレ（JST、オフセット付き）
Sep 26 10:23:45 db02 app: order=A1234 shipped                  # 年・ミリ秒・タイムゾーンがない（避ける）

案Bが有力です。AWSも、うるう秒のときにスメアありとなしを同じ設定に混ぜないよう勧めています（第7回）。うるう秒は2026年12月末も挿入されず（IERS Bulletin C 72）、2027年5月20日から連続したUTCに移ることが決まっています（第2回）。EC2の設定を統一し、chronyc sourcesを定期的に記録して、使っていた時刻源を示せるようにします。

時刻源は場所ごとに1系統。両側をつなぐのは時刻源ではなく、UTCで書いたログです。

問3 「ときどきKerberos認証に失敗し、ログの時刻もずれている」

• 状況：月曜の朝から「ファイルサーバーfs01に時々つながらず、資格情報を求められる」「業務アプリapp01のログインが時々失敗する」と報告が続いている
• 記録：DCのセキュリティログに4771（失敗コード0x25）が散発している。ログの収集基盤で見ると、fs01とapp01のログだけ時刻が数分ずれ、ときどき巻き戻っている
• 構成：DCは2台（物理1台、VM 1台）。fs01（Windows Server）とapp01（Linux、SSSDでAD認証）はvSphereのVMで、古いテンプレートから作った。先週末にESXiホストesx04を追加し、fs01とapp01をesx04へ移した
• 同じ週末に、サーバーのセグメントのファイアウォールのルールも更新している

考えるポイント：どの順に何を確かめるか、考えられる原因、直し方と再発の防止。

問3 解答例と解説

PS> w32tm /stripchart /computer:dc01.corp.example.jp /samples:4 /dataonly
10:02:11, +00.0012034s
10:02:13, -359.8420961s                         # fs01 が約6分進んだ
PS> & "C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe" timesync status
Enabled
$ journalctl -u chronyd | grep 'time jump'          # app01
... Forward time jump detected!

案Cです。w32timeの参照先はDCで、通信もできています（ファイアウォールではない）。それでも時刻が跳ぶのは、古いテンプレートで有効なVMware Toolsの定期同期が、NTPが未設定で約6分進んだesx04の時刻を押し付けているためです（第6回・第10回の二重の同期）。

esx04に社内NTPを設定し、定期同期を無効にして、テンプレートも直します。ゲストの中から外へ調べると、揺れの原因はゲストの外、ホストの時計にありました。同じ週末のファイアウォールの変更は、疑わしく見えても、同期の状態を確かめれば外せます。

問4 監査の要件で、UTCから1ms以内にそろえる

• 状況：取引を記録するシステムで、監査の要件として「記録サーバーの時刻をUTCから1ms以内に保ち、それを示す記録を1年間保管する」ことが求められた
• 構成：オンプレのデータセンターに、受付用のLinuxサーバー6台（物理）と、記録用のWindows Server 2025が2台（vSphereのVM）。分析基盤はAWSのEC2（Linux、M7i）
• 現状：社内NTP（chrony、VM）が、インターネット経由で公開NTPを参照している。記録サーバーでw32tm /query /statusを見ると、Root Delayが約20ms、Root Dispersionが約3ms
• 予算：時刻の専用機器とネットワーク機器の更新は、必要なら認められる

考えるポイント：今の構成で1msを示せるか、NTPとPTPの使い分け、Windowsの高精度時刻の条件、クラウドのPTPハードウェアクロック、監視と証跡。

問4 解答例

案Bが有力で、測定で余裕が確かめられれば案Cでも要件を満たせます。

案Aが駄目な理由は、第4回（Linuxの時刻同期）の誤差の上限の式で分かります。Root delayが20msあると、それだけで上限は10ms以上になり、1msは示せません。時刻源をデータセンターの中に置くことが出発点です。

Windowsで1msを狙うには、時刻源までの遅延0.1ms未満、stratum 5以内、4ホップ以内、CPU使用率の1日平均80%以下（VMはホストも）がMicrosoftの条件です（第5回）。EC2のWindowsはPTPハードウェアクロックを使えず、NTPで受けます（第9回）。

問4 解説：精度の示し方（監視と証跡）

1msの根拠は、ずれの値だけでなく「誤差の上限」と、UTCまでたどれる時刻源の連鎖（トレーサビリティー）で示します。Microsoftも、w32timeのログ・イベントログ・パフォーマンスカウンターを保管して後から示す方法を案内しています。GNSSは妨害や受信断もあるため、時刻サーバーは2台とし、互いに比べます（第7回）。

記録が途切れた期間は、1msを示せない期間になることも、忘れないようにしましょう。

振り返り

全11回を通じて、持ち帰ってほしいことは3つです。

1. 時刻はUTCを基準に、独立した4つ以上の時刻源から、1本の階層でそろえる。外部は社内NTPだけが参照し、リープスメアの有無を混ぜず、ログはUTCで記録する
2. 時計を動かす仕組みは1台に1つ。chrony・w32timeと仮想化のツールによる二重の同期を避け、大きなずれのstepは業務への影響を考えて行う
3. 同期の状態は数値で読み、監視して示す。届くか → 使われるか → 誰が時計を動かしたか、の順に確かめる

まずは自分のサーバーでchronyc sources -v（Windowsはw32tm /query /status）を実行し、どの時刻源に合わせているかを確かめてみてください。困ったときに戻る場所は、第10回の「連載の早見表」にまとめています。時刻に深く関わる証明書とDNSは、連載「証明書入門」「DNS入門」もあわせてどうぞ。

参考資料

この回の内容に対応する公式の文書・標準です（2026年11月に確認）。仕様・既定値・利用条件は変わることがあるので、使う前に最新の内容を確かめてください。

• EC2 インスタンス上の正確なクロックと時刻の同期（Amazon EC2 ユーザーガイド）：問2（オンプレとAWSのログ）の Amazon Time Sync Service
• コンピューターの時計の同期の最大許容範囲（Maximum tolerance for computer clock synchronization。Microsoft Learn）：問3（Kerberos 認証の失敗）の許容範囲
• 4771(F) Kerberos pre-authentication failed.（Microsoft Learn）：問3（Kerberos 認証の失敗）のイベント 4771
• Windows で高い精度を得るためのシステムの構成（Microsoft Learn）：問4（UTCから1ms以内）の Windows の高精度の時刻
• chrony.conf(5)（chrony 4.9）：問4（UTCから1ms以内）の chrony のハードウェアタイムスタンプ
• 公開NTPサービス（NICT 日本標準時グループ）：問1（3拠点の階層）の外部の時刻源
• IERS Bulletin C（最新版。うるう秒の発表）：うるう秒の発表

まとめ

• 設計は要件と現状の確認から。書かれていない条件は仮定を明記する
• 問1：外へ出るのは社内NTPだけ。ADの元はPDCエミュレーター1台。出口の障害でもUTCを保つならGNSS
• 問2：時刻源は場所ごとに1系統、スメアを混ぜない。つなぐのはUTCで書いたログ
• 問3：共通点から、同期の状態 → 誰が時計を動かしたか → ホストの順に。許容範囲を広げるのは対症療法
• 問4：1msは時刻源を近くに置き、誤差の上限と記録で示す。記録が途切れた期間は示せない

「NTP入門」全11回、最後までお読みいただき、ありがとうございました。

連載「NTP入門」全11回

全回の目次と、読む順番・目的別の読み方は、NTP入門の入口のページにまとめています。

1. なぜ時刻同期が必要か
2. 時刻の基礎知識
3. NTPの仕組み
4. Linuxの時刻同期（chrony）
5. Windowsの時刻同期
6. ネットワーク機器・仮想基盤
7. 設計と推奨構成
8. NTPのセキュリティ
9. PTPと高精度同期
10. 時刻同期のトラブルシュート
11. 時刻同期の設計演習（この記事）

Windowsの時刻同期は、ADドメインの階層に沿って自動で流れます。便利な反面、頂点の1台の設定を忘れると、ドメイン全体がずれていきます。

第4回ではLinuxのchronyを見ました。第5回では、Windows Time サービス（W32Time）と、ADドメインの時刻の階層、w32tmでの確かめ方を扱います。

Windows Time サービス（W32Time）の役割と精度

Windowsの時刻同期は、Windows Time サービス（W32Time）が担います。NTPのクライアントとサーバーの両方の機能を持ち、UDP 123で通信します。

• もともとKerberos認証の許容範囲（既定で5分）（連載「Kerberos入門」第4回）に時刻を収める目的で作られたため、既定の設定は「Kerberosに足りる程度にゆるく合わせる」もの
• 2012 R2以前はそれ以上の精度をサポートしないが、Windows Server 2016とWindows 10（1607）以降は、条件を満たせば1秒、50ms、1msの精度をサポートする
• ドメインのメンバーはドメインコントローラー（DC）からMS-SNTPという認証付きの方式で時刻を受け取り、ドメインに参加していない端末は既定でtime.windows.comと同期する

受け取るのも配るのも同じサービスで、精度は設定で上げるのです。

ADドメインの時刻の階層

ADドメインでは、時刻の流れ（階層）が自動で決まります。

• クライアントとメンバーサーバーは、認証を受けたDC（原則として同じサイトのDC）を時刻源にする
• DCは、そのドメインのPDCエミュレーター（FSMOの役割の1つ。連載「Active Directory入門」第4回）や親ドメインのDCを時刻源にし、子ドメインのPDCエミュレーターは親ドメインのDCを参照する
• たどっていくと、最上位はフォレストルートドメインのPDCエミュレーター。この1台だけは上位のDCが無いため、外部の信頼できる時刻源（社内のNTPサーバーなど）と同期するよう手動で設定する

設定を忘れると、PDCエミュレーターは自分の内蔵時計（Local CMOS Clock）を基準にし、フォレスト全体が少しずつずれていきます。冒頭の「DCを入れ替えたらずれ始めた」は、このパターンです。階層に従うこの方式をNT5DSと呼び、ドメインのメンバーの既定です。

同期の種類（Type）と既定値の違い

NtpServerのサーバー名の後ろのフラグは、0x1がSpecialPollIntervalの間隔で問い合わせる、0x2が予備（UseAsFallbackOnly）、0x4がsymmetric active、0x8がクライアントモードです。外部のNTPサーバーには0x8を付けるのが一般的です。

ずれの大きさと直し方

• MaxAllowedPhaseOffset以下のずれはslewで少しずつ、超えるずれはstepで一気に合わせる
• MaxPos／MaxNegPhaseCorrectionを超えるずれは直さず、イベントを記録するだけ。スナップショットの復元やRTCの電池切れで大きくずれたDCは、自動では戻らない（手順は第10回）

フォレストルートのPDCエミュレーターを設定する

PS> (Get-ADDomain -Identity (Get-ADForest).RootDomain).PDCEmulator
DC01.corp.example.jp
PS> w32tm /config /manualpeerlist:"ntp1.corp.example.jp,0x8 ntp2.corp.example.jp,0x8 ntp3.corp.example.jp,0x8" /syncfromflags:manual /reliable:yes /update
PS> net stop w32time; net start w32time
PS> w32tm /resync /rediscover
PS> w32tm /query /source
ntp1.corp.example.jp,0x8

• まず、PDCエミュレーターを持つDCを確かめる（netdom query fsmoでもよい）。設定するのはこの1台だけ
• /manualpeerlist：外部の時刻源。空白で区切り、全体を引用符で囲む。3台以上を指定する（2台なら片方に0x2を付けて予備にする。第3回）
• /syncfromflags:manual：TypeをNTPにし、階層ではなくリストのサーバーに従わせる
• /reliable:yes：「信頼できる時刻源」としてドメインに知らせる（DCでだけ意味がある）
• /update：設定をサービスに知らせる。確実に反映するため、サービスを再起動して/resync /rediscoverで同期し直す
• 外部へUDP 123で出られることを確かめる。Test-NetConnectionはUDPを試せないため、w32tm /stripchartを使う

状態を確かめる

w32tm /query /status

PS> w32tm /query /status
閏インジケーター: 0 (警告なし)
階層: 3 (二次参照 - (S)NTP で同期)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0031250s
ルート分散: 0.0412345s
参照 ID: 0xC0000210 (ソース IP:  192.0.2.16)
最終正常同期時刻: 2026/09/26 16:10:12
ソース: DC01.corp.example.jp
ポーリング間隔: 10 (1024s)

出力例はメンバーサーバーのもので、日本語版の Windows の表示です（Windows Server 2016 と Windows 11 で確かめた形。値は例）。英語版では項目名が英語になります。Linuxのchronyc tracking（第4回）に当たるコマンドです。

冒頭の「Local CMOS Clockと出た」は、外部と同期していないという意味です。フォレストルートのPDCエミュレーターなら設定漏れ、それ以外のDCやメンバーなら階層が途切れています。

/source・/peers・/configuration

PS> w32tm /query /peers
ピア数: 3

ピア: ntp1.corp.example.jp,0x8
状態: アクティブ
残り時間: 41.2345678s
モード: 3 (クライアント)
階層: 2 (二次参照 - (S)NTP で同期)
ピアポーリング間隔: 6 (64s)
ホストポーリング間隔: 6 (64s)
（以下、ntp2・ntp3 が続く。抜粋）

• /source：今の同期先だけを1行で表示する。スクリプトでの確認に便利
• /peers：時刻源の候補と状態の一覧。状態が「保留中」（Pending）のまま、階層が0 (未指定) のままなら応答が届いていない。Linuxのchronyc sourcesに当たる
• /configuration：実際に効いている設定と、その出どころを表示する。値の後ろの(ローカル)（英語版は(Local)）はレジストリ、グループポリシーから来た値は別の表記（英語版は(Policy)）になる
• /sourceと/configurationは、Windows 11では管理者として実行しないと「アクセスが拒否されました。 (0x80070005)」になる（/status・/peersは一般ユーザーでも見られる）
• /verboseで詳しい情報、/computer:DC02で他のコンピューターの状態を調べられる（管理者の権限が必要）
• ドメイン全体はw32tm /monitor /domain:corp.example.jpで、DCごとのずれを一覧できる

w32tm /stripchartと/resync

PS> w32tm /stripchart /computer:ntp1.corp.example.jp /samples:5 /dataonly
ntp1.corp.example.jp [192.0.2.123:123] を追跡中。
5 サンプルを収集中。
現在の時刻は 2026/09/26 16:20:01 です。
16:20:01, +00.0012345s
16:20:03, +00.0011872s
16:20:05, +00.0012011s
16:20:07, +00.0011930s
16:20:09, +00.0012104s
PS> w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

• /stripchartは、相手との時刻の差を測るだけで、自分の時計は変えない。相手にUDP 123が届くかの確認にも使える（届かなければ応答が無い旨のエラーになる）
• /resyncは、蓄積した統計を捨ててすぐに同期し直す。/rediscoverは時刻源の検出からやり直し、/nowaitは完了を待たずに戻る
• 「The computer did not resync because no time data was available.」と出たら、時刻源に届いていない。設定と通信を確認する
• /resyncの後の直し方はMaxAllowedPhaseOffsetで決まり、それを超えるずれは一気に合わせ、それ以下はゆっくり合わせる。Linuxのchronyc makestepのように必ず飛ばすわけではない。出力例は日本語版の表示（英語版は「Sending resync command to local computer」「The command completed successfully.」）

高精度の時刻同期（Windows Server 2016以降）

• 経路上のすべてのWindows（上位の時刻サーバー、Hyper-Vホストを含む）が、Windows Server 2016／Windows 10以降であること。W32Timeの開始の種類は「自動」
• レジストリ（W32Time\Config）：MinPollInterval=6、MaxPollInterval=6、UpdateInterval=100、FrequencyCorrectRate=2、UtilizeSslTimeData=0。NtpClientのSpecialPollInterval=64
• 反映はw32tm /config /updateとサービスの再起動（UtilizeSslTimeDataはOSの再起動が必要）
• 最上位に正確で安定したstratum 1（GPS受信機付きのNTPサーバーなど）を置く。遠くの公開NTPサーバーでは1msは狙えない

Microsoft Learnは、米国FINRAの50ms、EUのMiFID IIの1msを要件の例に挙げています（第1回）。遅延はw32tm /stripchart /computer:… /rdtsc /samples:450のRoundtripDelayから求めます。Kerberosのためだけなら、既定のままで十分です。NTPとPTPの比較は第9回、設計は第11回の問4で扱います。

グループポリシーでの設定とワークグループの端末

• 場所は、コンピューターの構成 > 管理用テンプレート > システム > Windows タイム サービス（> タイム プロバイダー）。「Windows NTP クライアントを構成する」でTypeとNtpServerを指定する
• PDCエミュレーター用のGPOをフォレストルートドメインのDomain Controllers OUにリンクし、WMIフィルターSELECT * FROM Win32_ComputerSystem WHERE DomainRole = 5でPDCエミュレーターだけに当てると、役割を移しても設定が付いていく
• 「グローバル構成設定」を有効にすると、画面で変えていない値もGPOの既定値で上書きされる（例：MaxPos／MaxNegPhaseCorrectionが172,800秒になる）。必要なポリシーだけを有効にする
• GPOで配った値はw32tm /query /configurationで(Policy)と表示される。レジストリを直接直しても、GPOの値が優先される

ワークグループの端末は既定でtime.windows.comと同期し、間隔も長めです。社内にNTPサーバーがあれば、w32tm /config /manualpeerlist:"ntp1.corp.example.jp,0x8" /syncfromflags:manual /updateで向け直します。15時間を超えるずれは、自動では直りません。

仮想マシンのDCと、PDCエミュレーターを移したとき

• Hyper-V：DCのVMは、統合サービスの「時刻の同期」を外し、ドメインの階層に従わせる（Microsoftの推奨）。ゲストのレジストリVMICTimeProviderのEnabled=0で、ホストからの時刻だけを使わない方法もある
• VMware：VMware Toolsの周期的な同期は既定で無効。ただし起動・再開・vMotion・スナップショット時の一回限りの同期は有効なので、ESXiホストの時刻を正しく保つ（第6回）
• DCのVMがホストの時刻に従い、ホストがドメインから時刻を受け取る構成は循環する。どちらか一方を断つ

DC の VM 2台が同じホストに載らないよう、DRS のアンチアフィニティルール（仮想マシンの分割）で別々のホストに分ける手順は、過去の記事「VMware vSphere – vSphere DRS 設定 (アフィニティとアンチアフィニティ)」で紹介しています。

PDCエミュレーターを移したら

PS> netdom query fsmo
PS> w32tm /config /syncfromflags:domhier /reliable:no /update
PS> net stop w32time; net start w32time
PS> w32tm /query /source

新しいPDCエミュレーターには、前の節の「外部の時刻源」の設定を行い、古い方は上のコマンドで階層に戻します（WMIフィルターのGPOなら自動）。時刻の設定は役割に付いてきません。新旧の2台とも直すのを忘れないでください。

参考資料

この回の内容に対応する公式の文書・標準です（2026年11月に確認）。仕様・既定値・利用条件は変わることがあるので、使う前に最新の内容を確かめてください。

• Windows タイム サービスのしくみ（Microsoft Learn）：「W32Time」「ADドメインの時刻の階層」
• Windows タイム サービス ツールと設定（Microsoft Learn）：「フォレストルートのPDCエミュレーターを設定する」「状態を確かめる」の w32tm の各コマンドとレジストリ
• w32tm /resync コマンドが失敗し、”時刻データが利用できなかったため、コンピューターが再同期されませんでした”（Microsoft Learn）：「w32tm /stripchartと/resync」の no time data was available
• 膨大な時間オフセットに対して W32Time を構成する（Microsoft Learn）：「ずれの大きさと直し方」
• Windows で高い精度を得るためのシステムの構成（Microsoft Learn）：「高精度の時刻同期」
• 高精度時間のサポート限界（Microsoft Learn）：「高精度の時刻同期」のサポートの範囲
• Windows Server 2016 の時間精度の向上（Microsoft Learn）：「高精度の時刻同期」の Windows Server 2016 の改善
• Hyper-V によるドメイン コントローラーの仮想化（Microsoft Learn）：「仮想マシンのDCと、PDCエミュレーターを移したとき」

考えてみよう

1. 自分のPCでw32tm /query /sourceを実行してください。どのDC（またはtime.windows.com）から時刻を受け取っていますか。そのDCは、さらにどこから受け取っていますか。
2. フォレストルートのPDCエミュレーターを別のDCに移す作業の手順書に、時刻の設定として何を書き加えますか。
3. 「ときどきKerberos認証に失敗する」と言われたとき、どのコマンドで何を確かめますか。仮想マシンのDCであれば、ほかに何を確かめますか。

ヒント：この記事の階層の図、PDCエミュレーターの設定と移したときの手順、/query /statusのSource・Stratum・Last Successful Sync Timeが手がかりです。

まとめ

• W32TimeはNTPのクライアント兼サーバー。既定はKerberosの5分に足りる精度
• ADでは時刻が階層（NT5DS）で流れ、頂点はフォレストルートのPDCエミュレーター
• 頂点の1台だけ/manualpeerlist … /syncfromflags:manual /reliable:yesで外部の時刻源を3台以上
• Local CMOS Clockは外部と同期していない合図
• MaxPos／MaxNegPhaseCorrectionを超えるずれは直さない
• 高精度（1ms）は2016以降＋条件つき。Kerberosだけなら既定で十分
• PDCエミュレーターを移したら新旧2台とも時刻の設定を直す（WMIフィルターのGPOなら自動）

次回は、ネットワーク機器やESXi・vCenterなど、サーバー以外の機器の時刻同期を扱います。

連載「NTP入門」全11回

全回の目次と、読む順番・目的別の読み方は、NTP入門の入口のページにまとめています。

1. なぜ時刻同期が必要か
2. 時刻の基礎知識
3. NTPの仕組み
4. Linuxの時刻同期（chrony）
5. Windowsの時刻同期（この記事）
6. ネットワーク機器・仮想基盤
7. 設計と推奨構成
8. NTPのセキュリティ
9. PTPと高精度同期
10. 時刻同期のトラブルシュート
11. 時刻同期の設計演習

連載もいよいよ最終回です。第1回から第11回まで、DNSの仕組み・運用・調べ方・守り方・クラウドでの使い方・トラブルシュートを見てきました。最終回は、それらを実際の場面で使うための設計演習です。

5つの問題を用意しました。どれも現場で本当によく出会う状況をもとにしています。解答例を見る前に、ぜひ一度自分で考えてみてください。

▶ この回の内容は、YouTube の動画（約14分）でも見られます（記事の最後にも埋め込んであります）。

演習の進め方

1. 問題を読む：要件に線を引き、書かれていない条件は仮定する
2. 5分考える：選ぶ案と、その理由を書き出す。可能なら、実際にdigで確かめる手順も書く
3. 比べる：同僚やチームで共有できるなら、ほかの人の案と比べる
4. 解答例と解説を読む：決め手になった要件を確認する

正解は1つではありません。どの要件を重く見たかで、選ぶ案が変わります。最初にすべきことは、要件と現状の確認です。問題文に書かれていない条件（体制、予算、将来の拡張）は、どう仮定したかを明記しましょう。答えを合わせるより、決め手になった要件を言えるようにすることが大切です。

問1 社内の新しいADドメイン名を決める

• 状況：従業員300名の会社で、ADのフォレストを新しく作ります。既存のADはなく、Microsoft 365（Entra ID）と連携する予定です
• 現状：自社はexample.co.jpを登録済みで、Webとメールに使っています（権威DNSは外部のDNSサービス）
• 候補：① corp.local　② corp.internal　③ ad.example.co.jp
• 環境：社内にはWindowsのほかにMacとLinuxサーバーがあり、社内のWebサイトにはTLSの証明書を使いたいと考えています

考えるポイント：端末の名前解決の経路、証明書の発行、クラウドとの連携、将来（合併や社名変更）への備え

問1 解答例と解説

決め手は、クラウドとの連携、Mac・Linuxの混在、証明書の3つです。これらをすべて満たす案Cが有力です。案Bは、外部と完全に切り離した閉じた環境で、社内CAを運用できる場合の選択肢になります。

ADのドメイン名は後から変えるのが非常に難しいため、最初に決め切ります（第2回）。所有するドメインのサブドメインなら、衝突も証明書も連携も片付きます。

問2 Webサイトを別のサーバーへ移設する

• 状況：会社のWebサイト（example.jpとwww.example.jp）を、オンプレのサーバー（198.51.100.10）から、クラウドの新しい環境（203.0.113.20）へ移設します
• 現状：AレコードのTTLは86400秒（1日）です。権威DNSは自社で管理しています（プライマリ1台、セカンダリ1台）
• 要件：停止時間はできるだけ短くし、切り替えは来週土曜の夜に行います。問題があればすぐに元へ戻せるようにします
• 追加：新しい環境ではstatic.example.jpという名前も使い始めます。まだレコードはありませんが、テストのために何人かが引いてみたようです

考えるポイント：TTLをいつ・いくつに下げるか、旧サーバーをいつまで残すか、新しい名前の準備、切り戻しの方法

問2 解答例

基本は案Bで、停止を許されないサイトでは案Cを加えます。クラウドのDNSを使っている場合は、加重ルーティングで少しずつ新環境へ移す方法もあります（第10回）。どの案でも、static.example.jpのレコードは先に作っておきます。

問2 解説：移設のタイムライン

最大の落とし穴は、TTLを下げる作業自体も、旧TTLの時間が経つまで効かない点です（第7回）。「前日にTTLを下げたから大丈夫」ではありません。

static.example.jpについては、テストで引いた人のキャッシュに「存在しない」が残っています。ネガティブキャッシュはSOAのTTLとMINIMUMの小さい方の時間だけ残るので、早めにレコードを作っておきます（第3回）。

なお、DNSサービスそのもの（NS）を移す場合は、親ゾーンのNSのTTLも考え、新旧のゾーンを同じ内容で並行稼働させます。

問3 オンプレとAWSの相互名前解決

• 状況：オンプレのADドメインcorp.example.jp（DC兼DNSが2台）と、AWSの東京リージョンをDirect ConnectとVPNで接続しています。AWSには共有サービス用のアカウントが1つ、業務用のアカウントが3つあり、それぞれVPCを持っています
• 要件①：オンプレの端末から、AWSの社内システム（*.aws.corp.example.jp、プライベートホストゾーン）を引けること
• 要件②：EC2（Windows）をADに参加させるため、VPCからcorp.example.jpを引けること
• 要件③：DNSのために運用するサーバーは増やしたくない。業務用のアカウントは今後も増える予定です

考えるポイント：どの部品をどのアカウントに置くか、ルールをどう配るか、ループと冗長をどう防ぐか

問3 解答例

要件③から案Aが有力です。案CはDNSの方式というよりADの冗長の考え方で、案Aと組み合わせることもできます。

問3 解説

決め手は「DNSのサーバーを増やさない」「アカウントが増え続ける」という要件です。案Aでは、エンドポイントを共有サービス用アカウントに集め、転送ルールを他のアカウントへ共有します。ルールを関連付けるVPCどうしが、ネットワークでつながっている必要はありません。

注意点は3つです。

1. ループ：オンプレはaws.corp.example.jpをAWSへ、AWSはcorp.example.jpをオンプレへ、と向きを一方通行にする
2. 優先順位：同じ名前なら転送ルールがプライベートホストゾーンに勝つため、AWS側はサブドメインに分ける。ただし corp.example.jp の転送ルールは既定でサブドメインにも効くので、aws.corp.example.jp はシステムルールで転送の対象から外しておくと確実です（第10回の「Resolverエンドポイントと転送ルール」の節のシステムルール。このブログの連載「AWSネットワーク設計入門」第19回の問5でも扱います）
3. 冗長：エンドポイントは2つ以上のAZに置き、オンプレのDNSも2台とも転送先に登録し、回線ごとに片方を止めて試験する

NSレコードの委任（委任ルール）による連携も選べます（第10回）。つなぐ前に、名前ごとの向きと冗長の組を表にしておくと、設計の抜けが見つけやすくなります。

VPC の DNS（Resolver のエンドポイント・プライベートホストゾーン）と Direct Connect・VPN は連載「クラウド入門」第7回、EC2 を AD に参加させるときの AWS Directory Service はクラウド入門 第8回で、AWS の側から説明しています。

問4 「一部の利用者だけサイトが開けない」

• 状況：月曜の朝、ヘルプデスクに「取引先のポータルportal.example.comが開けない」と連絡が5件ありました。ブラウザーには「サーバーのIPアドレスが見つかりませんでした」と表示されます
• 報告者：本社の3名と、在宅勤務でVPNを使っている2名です。大阪拠点の人と、スマホの回線では開けます
• 社内の構成：本社にキャッシュDNS（BIND）が2台、大阪拠点に1台あり、どちらも社外の名前はルートから自分で解決しています。VPNの利用者は本社のキャッシュDNSを使います
• 取引先からは、先週末に「DNSサービスを移行した」と案内がありました

考えるポイント：どの順に何を確かめるか、考えられる原因は何か、取引先に何を伝えるか

問4 解答例と解説

答えは案Bです。第11回の「一部の人だけ引けない」の典型例ですね。

1. 報告の共通点：本社のキャッシュDNSを使う人だけ（VPNの2名も本社のDNSを使う）
2. dig @本社DNSとdig @大阪DNSを比べる（SERVFAILとNOERROR）
3. EDEと+cdを確認する
4. dig +traceとdig @各NS +norecで取引先のNSを確認する

• EDE 22（No Reachable Authority）なら、本社だけが旧サービスのNSをキャッシュし、旧サービスがもう答えていない可能性が高い。rndc flushtree example.comで該当部分だけ消す
• EDE 9（DNSKEY Missing）なら、DSの更新漏れ。取引先にDSの修正を依頼する（第9回）

案Cの「全部消して再起動」は、直ることもありますが、原因の証拠も消えてしまいます。証拠を残したまま、原因の場所を1段ずつ絞りましょう。

問5 自社ドメインのメールとWebのDNS設定を見直す

• 状況：自社ドメインexample.jpのDNS設定を、数年ぶりに見直すことになりました。担当者は何度も交代しています
• メール：SPFにinclude:が12個並んでいます。DKIMの署名は一部の送信サービスだけです。DMARCはp=noneのままで、レポートの送り先は退職者のアドレスです
• Web：CAAレコードはありません。campaign2019.example.jpなど、終了したキャンペーンのCNAMEが、クラウドのサービスを指したまま残っています
• ドメイン：更新の支払いは前任者の名義のクレジットカードで、期限の通知メールも前任者のアドレスに届きます

考えるポイント：何から手を付けるか（リスクの大きい順）、メールを止めずに認証を強める手順、今後の管理のしかた

問5 解答例

案Bが有力です。ドメインの失効とCNAMEの乗っ取りは、Webもメールも会社の信用も一度に失うため、最初に対処します。メールの認証は、止めてはいけない正規の送信を先に把握してから強めます。取り返せないものを先に直し、メールは送信元を把握してから強める、という順番です。

問5 解説：見直しのチェックリスト

レコードの書き方は第5回・第6回、テイクオーバーとドメインの失効は第9回で扱いました。この見直しは、大手のメール事業者の送信者ガイドライン（2024年〜）への対応にもなります。

DMARCの集計レポートで送信元を棚卸しする方法は連載「メール入門」第6回で、p=noneからp=rejectへ半年で進める演習は同連載の第12回（問2）で扱っています。

連載を終えて

5つの問題、いかがでしたか。どの問題も、答えを知っているかどうかより、「どの要件が決め手か」「いま、どのDNSに、何を聞いているか」を言えるかどうかが大事でした。

12回にわたって、DNSの仕組みから調べ方・守り方・クラウドでの使い方までを見てきました。DNSは普段は意識されない存在ですが、止まったり誤った答えを返したりすると、あらゆる通信が入口で止まります。この連載が、「DNSがおかしいみたいです」と言われたときに、落ち着いて切り分けるための手がかりになればうれしいです。

まずは自分の端末でdig +traceを実行して、毎日使っている名前の委任をたどってみてください。きっと、これまでとは違う景色が見えるはずです。

同じ形の設計演習は、DNSと関わりの深いメールと証明書にもあります。続けて取り組むなら、上で紹介したメール入門の第12回と、連載「証明書入門」第11回（証明書の設計演習）をどうぞ。

最後まで読んでいただき、ありがとうございました。

更新履歴

• 2026年10月24日：「問3 オンプレとAWSの相互名前解決」の解説に、サブドメインをシステムルールで転送の対象から外す点を追記しました

動画で見る

この回の内容を、YouTube の動画（約14分）でも解説しています。

連載の全回は、YouTube の再生リスト「DNS入門」にまとめています。

連載「DNS入門」全12回

全回の目次と、読む順番・目的別の読み方は、DNS入門の入口のページにまとめています。

1. DNSとは？名前解決の全体像と3つの登場人物
2. ドメイン名の階層と委任
3. 名前解決の流れ
4. DNSメッセージとトランスポート
5. リソースレコード 前編
6. リソースレコード 後編
7. 権威DNSサーバーの運用
8. コマンドで調べる
9. DNSのセキュリティ
10. クラウド・社内環境のDNS
11. DNSトラブルシュート
12. DNS設計演習（この記事）

クラウドやコンテナの環境では、DNSの部品が見えにくいところに組み込まれています。仕組みを知らないと、どこで名前が解決されているのかさえ分からず、切り分けに時間がかかります。

でも、安心してください。部品の名前が変わっても、中身は第3回までに見た「キャッシュDNS・権威DNS・条件付きフォワーディング」そのものです。第10回では、Route 53を中心としたAWSのDNS、オンプレとのハイブリッド名前解決、Azureとの対応、そしてAD統合DNS、Kubernetes、vSphereでのDNSを見ていきます。

▶ この回の内容は、YouTube の動画（約14分）でも見られます（記事の最後にも埋め込んであります）。

Route 53の全体像とホストゾーン

Route 53はAWSのDNSサービスで、3つの役割を持ちます。

1. ホストゾーン：権威DNSサーバー
2. ドメイン名の登録：レジストラー
3. VPC Resolver：VPCの中で使うフルサービスリゾルバー

ホストゾーンには2種類あります。

• パブリックホストゾーン：インターネットに公開するゾーン。作成すると4台のネームサーバー（awsdnsのcom・net・org・co.uk）が割り当てられる。レジストラーでこの4台をNSとして登録して、初めて委任が完成する（第2回）
• プライベートホストゾーン：関連付けたVPCの中からだけ引けるゾーン

同じ名前のパブリックとプライベートを作ると、VPCの内と外で違う答えを返すスプリットホライズン（第7回、連載「クラウド入門」第7回）になります。1つのサービスに、役割の違う3つのDNSの機能が入っている、と整理しておくと混乱しません。

エイリアス・ルーティングポリシー・ヘルスチェック

ここで押さえたいのは、どれも「権威DNSが返す答えを変える」仕組みだという点です。すでに答えを持っているキャッシュDNSや端末には、TTLが切れるまで効きません（第3回）。答えを変えるのはRoute 53、古い答えを覚えているのはキャッシュDNSです。ルーティングポリシーの一覧は、連載「クラウド入門」第7回を参照してください。

また、レイテンシーや地理的位置のルーティングは「問い合わせ元」で判定するので、社内のフォワーダー経由だと、その出口の場所で判定される点にも注意しましょう。大阪の社員でも、東京のDMZから問い合わせていれば「東京」と判定されます。

VPCのDNS（Route 53 VPC Resolver）

VPCのEC2は、DHCPオプションセットのAmazonProvidedDNSにより、AWSのフルサービスリゾルバーRoute 53 VPC Resolver（2025年にRoute 53 Resolverから改称）を使います。宛先はCIDRの先頭＋2（10.0.0.0/16なら10.0.0.2）か169.254.169.253です。

• VPCの属性enableDnsSupportとenableDnsHostnamesの両方を有効にしないと、プライベートホストゾーンが使えない
• 名前に最も具体的に一致する転送ルールかプライベートホストゾーンが使われ、同じ名前なら転送ルールが優先
• 一致したゾーンに無い名前は、インターネットに聞かずNXDOMAINになる
• ENIごとに毎秒1024パケットの上限がある（連載「クラウド入門」第7回）

3つ目は、はまりやすいポイントです。たとえばexample.jpのプライベートホストゾーンを作ると、そこに登録していないwww.example.jpは、インターネットに公開されていてもNXDOMAINになります。

Resolverエンドポイントと転送ルール

オンプレとVPCの間で名前を引き合うための部品です。

エンドポイントのIP 1つで、UDPの問い合わせを毎秒最大1万件ほど処理できます（応答の大きさや転送先の遅さで下がります）。料金はIPの数と問い合わせ数で決まります。

新しい部品に見えますが、転送ルールの考え方は、第3回の条件付きフォワーディングそのものです。

クエリーログ・DNS Firewall・Global Resolver

• クエリーログ：VPCからVPC Resolverへの問い合わせ、エンドポイントを通る問い合わせ、DNS Firewallの判定を記録する。送り先はCloudWatch Logs・S3・Firehose。「どのインスタンスが、いつ、何を引いたか」が、障害調査とセキュリティ調査の手がかりになる。ただし、端末やOSのキャッシュで答えた問い合わせと、1024ppsの上限で捨てられた問い合わせはログに残らない
• DNS Firewall：VPCから出ていく問い合わせを、ドメインリストで許可（ALLOW）・遮断（BLOCK）・警告（ALERT）する。遮断したときはNODATA・NXDOMAIN・OVERRIDE（CNAMEで差し替え）のどれで答えるかを選べる。AWSが管理するドメインリスト（マルウェアなど）と、DNS Firewall Advanced（DNSトンネリングやDGAの検知）がある。第9回（DNSのセキュリティ）の保護的DNS・RPZのクラウド版
• Route 53 Global Resolver（2026年3月に一般提供）：オンプレや在宅の端末から、エニーキャストでプライベートホストゾーンとインターネットの名前を引けるリゾルバー。フィルタリングとログも一か所にまとめられる

DNS Firewallは名前だけで判定します。IPアドレスを直接指定した通信や、DoHで外部へ出る通信は止められません。最初はALERTで影響を確かめてからBLOCKにしましょう。

オンプレとのハイブリッド名前解決

では、冒頭の「EC2からオンプレの名前が引けない」を、どう設計すればよいのでしょうか。オンプレとAWSの間では、両方向の条件付きフォワーダーで名前を引き合います。

• オンプレ → AWS：オンプレの端末がapp.aws.corp.example.jpを引くと、社内のDNSはVPNやDirect Connect越しにインバウンドエンドポイントへ転送し、プライベートホストゾーンの答えが返る
• AWS → オンプレ：EC2がdc01.corp.example.jpを引くと、転送ルールに従い、アウトバウンドエンドポイントからオンプレのDNSへ転送される

行きは②インバウンド、帰りは⑥アウトバウンドです。設計の要点は3つです。

1. AWS側をaws.corp.example.jpのようなサブドメインに分け、転送の条件を単純にする
2. 転送が同じVPCとオンプレを行き来するループを作らない
3. AZ・DNSサーバー・回線を2つ以上にする

Azureとの対応

Azureでも、名前は違っても部品の役割は1対1で対応しています。

Azureで多い障害は、プライベートエンドポイント用のprivatelink.*ゾーンを、オンプレのDNSから条件付き転送し忘れ、公開IPが返ってしまうものです。AWSのVPCエンドポイントでも同じことが起きます。「クラウドのストレージに、社内からだけインターネット経由でつながってしまう」ときは、まずここを疑いましょう。

AD統合DNS

社内環境の代表、Active DirectoryのDNSです。

• AD統合ゾーン：ゾーンのデータをADのデータベースに置き、ADのレプリケーションでDCに複製する。どのDCでも書き込めるマルチマスターで、第7回のプライマリ／セカンダリとゾーン転送とは仕組みが違う
• SRVレコード：DCのNetlogonが_ldap._tcp.dc._msdcs.<ドメイン>などを自動で登録し、クライアントはSRVでDCを探す（第6回）
• _msdcsゾーン：_msdcs.<フォレストルート>はフォレスト全体に複製される。子ドメインや別のDNSからDCを探すときにここが引けないと、ドメイン参加や認証が失敗する
• 動的更新：端末が自分のA・PTRを登録する。「セキュリティで保護された動的更新のみ」にすると、登録したコンピューターだけが自分のレコードを書き換えられる
• DCのDNS設定：DCの参照先は他のDCを先に、自分自身を後にする。社外の名前はフォワーダーでキャッシュDNSに集約する（第3回）

$ dig +short SRV _ldap._tcp.dc._msdcs.corp.example.jp
0 100 389 dc01.corp.example.jp.
0 100 389 dc02.corp.example.jp.

PS> Resolve-DnsName _ldap._tcp.dc._msdcs.corp.example.jp -Type SRV
PS> nltest /dsgetdc:corp.example.jp          # 実際に見つかる DC

スカベンジング

もう1つ、AD統合DNSで知っておきたいのがスカベンジング（古いレコードの自動削除）です。

既定は更新禁止7日＋更新7日で、14日更新がないと古いと判定されます。ゾーンとサーバーの両方で有効にしないと動かず、間隔を24時間未満にすると、生きている端末のレコードまで消えます。撤去したサーバーやDCのレコードが残り続けていたら、スカベンジングの設定を確認しましょう。

Windows Server の DNS での手順は、過去の記事で紹介しています。ゾーンの種類（AD 統合・プライマリ・セカンダリ・スタブ）を選んでゾーンを作る手順は「DNS (Domain Name System) – DNS ゾーンの作成」、サーバー全体でエージング・清掃を有効にする手順は「DNS (Domain Name System) – Windows DNS サーバーの設定・オプション」です。

KubernetesのDNS

冒頭の「Kubernetesに載せたら外部APIの呼び出しが遅くなった」の話です。

クラスターの中ではCoreDNSが、Serviceの名前に答える権威DNSと、外部の名前を引くキャッシュDNSを兼ねます。Serviceは<サービス名>.<名前空間>.svc.cluster.localで引けます。

Podの/etc/resolv.conf（既定のdnsPolicy: ClusterFirst、名前空間prodの例）は、次のようになっています。

nameserver 10.96.0.10
search prod.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

ndots:5の意味：ドットが5個未満の名前は、まずsearchのドメインを付けて試します。外部のapi.example.comを引くと、api.example.com.prod.svc.cluster.localなどの3つがNXDOMAINになってから本来の名前を引くため、AとAAAAで最大8回の問い合わせになります（ノードのsearchが加わるとさらに増えます）。

• 影響：CoreDNSと上流のDNSへの問い合わせが増え、名前解決が遅くなる。AWSではENIあたり1024ppsの上限に当たることもある
• 対策：外部の名前は末尾にドットを付けたFQDNで書く、PodのdnsConfigでndotsを下げる（例：2）、NodeLocal DNSCacheで各ノードにキャッシュを置く、CoreDNSのレプリカ数とキャッシュを調整する

第2回・第3回で見た「末尾のドット」と「searchドメイン」の話が、ここで効いてくるわけです。

vSphereなどの製品でDNSが重要な理由

最後に、インフラ製品とDNSの関係です。多くの製品にとって、DNSは構築の前提条件です。

代表例のvSphereでは、vCenter ServerをFQDNで構築するとき、正引き（A）と逆引き（PTR）の両方が登録され、一致していることが要件で、満たさないとデプロイや初回起動が失敗します。vCenterの名前は証明書やシングルサインオンに組み込まれるため、後から変えるのは大きな作業です。

ほかにも、次のような例があります。

• 送信元や宛先のドメインをDNSで解決できないと、vCenterのメール通知が送られない事象（Broadcom KB 321441）
• ESXiでNFS 4.1のKerberos認証を使うときに、KDCをSRVで引けるDNSが必要

Kerberosは名前で相手を確かめ、証明書も名前に対して発行されるため、同じことは多くの製品にいえます。名前は製品の中に焼き込まれるので、後で直すより、構築前に製品のDNS要件を確認し、AとPTRを先に登録しておきましょう。

考えてみよう

1. あなたのAWS（またはAzure）のVPCでは、EC2はどのDNSサーバーを参照していますか。オンプレの名前は、どの経路で引いていますか。
2. ADのDNSで、スカベンジングは有効になっていますか。撤去したサーバーやDCのレコードが残っていないか、確かめる方法を考えてください。
3. KubernetesのPodで、外部のAPIを毎秒100回呼ぶアプリがあります。ndotsとsearchによって、DNSの問い合わせは毎秒何件になりそうですか。

ヒント：1問目はDHCPオプションセットと転送ルール、2問目はタイムスタンプとnetlogon.dns、3問目はsearchの数とA/AAAAから考えてみてください。

まとめ

• Route 53は権威DNS・レジストラー・VPCのリゾルバーの3役。パブリックはNS 4台を親に登録して委任完成
• ルーティングポリシーは権威の答えを変えるだけ。キャッシュにはTTLが切れるまで効かない
• VPC Resolverは一致したゾーンに無い名前をNXDOMAINにする
• ハイブリッドは両方向の条件付きフォワーダー。AWS側はサブドメインに分ける
• AD統合DNSはマルチマスター。SRVと_msdcs、スカベンジングを押さえる
• Kubernetesはndots:5で外部の名前の問い合わせが増える。vSphereは正引きと逆引きの一致が前提

次回は、ここまでの知識を使って、DNSの障害を切り分ける手順をまとめます。

動画で見る

この回の内容を、YouTube の動画（約14分）でも解説しています。

連載の全回は、YouTube の再生リスト「DNS入門」にまとめています。

連載「DNS入門」全12回

全回の目次と、読む順番・目的別の読み方は、DNS入門の入口のページにまとめています。

1. DNSとは？名前解決の全体像と3つの登場人物
2. ドメイン名の階層と委任
3. 名前解決の流れ
4. DNSメッセージとトランスポート
5. リソースレコード 前編
6. リソースレコード 後編
7. 権威DNSサーバーの運用
8. コマンドで調べる
9. DNSのセキュリティ
10. クラウド・社内環境のDNS（この記事）
11. DNSトラブルシュート
12. DNS設計演習

今回は新しいプロファイルの保持の仕組みである FSLogix について解説を行います．

• Active Directory ドメインサービスに関するお話
  • Active Directory ドメインサービス – 概要
  • Active Directory ドメインサービス – Active Directory ドメインの構成 1台目
  • Active Directory ドメインサービス – Active Directory ドメインの構成 2台目
  • Active Directory ドメインサービス – 組織単位 (OU)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントの作成)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントプロパティ)
  • Active Directory ドメインサービス – アカウントの管理 (グループアカウントの作成・管理)
  • Active Directory ドメインサービス – グループポリシー (グループポリシー設定の前準備)
  • Active Directory ドメインサービス – クライアントのドメイン参加
  • Active Directory ドメインサービス – 一般ユーザーアカウントでのドメイン参加の制限
  • Active Directory ドメインサービス – グループポリシーの設定，適用 (パスワードポリシー)
  • Active Directory ドメインサービス – 移動ユーザープロファイルの構成と確認
  • Active Directory ドメインサービス – フォルダーリダイレクトの構成と確認
  • Active Directory ドメインサービス – FSLogix の構成と確認

• Active Directory ファイルサーバーに関するお話
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する 「SMBの解説」
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する「ファイルサーバーリソースマネージャーの導入」
  • Windows ファイルサーバー – DFS (Distributed File System/分散ファイルシステム) と DFSR (DFS Replication/DFS レプリケーション)
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する「共有の作成とアクセス権の設定」
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する「クォータの設定」
  • Windows ファイルサーバー – DFS 名前空間とDFS レプリケーションの構成

FSLogix とは

FSLogix とはプロファイル情報をファイルサーバーに持ち，複数台の端末を利用した際に設定情報を維持したまま利用ができるものです．これだけだと移動ユーザープロファイルと同じように聞こえますが，プロファイル情報の持ち方，アクセスの仕方が異なります．

FSLogix のプロファイル情報はファイルサーバーの中に仮想ハードディスクイメージが作成され，その仮想ハードディスクを端末でマウントを行いあたかもローカルディスクに対してアクセスする形式となります．

そのため，ログオン・ログオフ時のプロファイルのコピーや書き戻しは発生しません．必要なデータをそのまま読み書きするだけとなりますので移動ユーザープロファイルと比べて IO 負荷が軽減されます．

また，端末のローカルディスクへプロファイル情報のコピーを行わないことから，各端末に余分なプロファイルデータが蓄積されていくということもなくなります．

最もシンプルな FSLogix の構成はこのように，プロファイルデータおよびデスクトップやダウンロードなどもすべて仮想ハードディスクに保存する方式となります．

移動ユーザープロファイルとの違いはプロファイル情報の維持する範囲になります．移動ユーザープロファイルの場合，Local および LocalLow は対象に入りません．FSLogix はここも対象に入ります．
移動ユーザープロファイル+フォルダーリダイレクト と FSLogix のプロファイルの保持範囲の違いは以下イメージのとおりです．

Local および LocalLow には，Office アプリケーションの情報や IME 辞書のデータなどが保持されているため，移動ユーザープロファイル以上の利便性向上が図られます．

また，昨今の Office365 (Microsoft 365) のライセンス情報も Local の中に保持されるためライセンス認証状況を維持したい場合は FSLogix の利用が必須と考えられます．

デスクトップやダウンロードなどのデータは今まで通りフォルダーリダイレクトを利用することも可能です．
これは要件や運用に合わせて決定していけば大丈夫です．例えば，ファイルサーバー側で定期的にスナップショットをとるようにしており，ユーザーが誤ってデータを消去した．もしくは書き換えてしまった．などの際に過去のデータにアクセスできる手段を提供する．という場合は FSLogix とフォルダーリダイレクトを併用して提供する．という運用が考えられます．

FSLogix の構成

ファイルサーバー領域の作成

FSLogix はファイルサーバーにデータを保管しますので，共有を作成する必要があります．

作成の方法については以下の記事を参考にしてください．今回の共有名は「FSLogix」として以降解説していきます

• Windows ファイルサーバー – ファイルサーバーサービスを構成する「共有の作成とアクセス権の設定」
  • この記事を参考に「FSLogix」の共有を作成します
  • アクセス権はこの記事と同様で大丈夫です

• Windows ファイルサーバー – DFS 名前空間とDFS レプリケーションの構成
  • この記事を参考に「FSLogix」用の DFS 名前空間を作成してください
  • 名前空間は「Profiles」をそのまま利用頂く形式で大丈夫です．
    • \\<ドメイン名>\Profiles\FSLogix というパス名になるように設定してください
  • 冗長構成をとる為，DFS レプリケーションも合わせて構成をしてください

移動ユーザープロファイル，フォルダーリダイレクトの場合，ファイルサーバーリソースマネージャー (FSRM) でクォータの設定を行いましたが，FSLogix ではグループポリシー (GPO) で仮想ハードディスクサイズを指定するため，クォータの設定は不要です．

FSLogix アプリケーションのダウンロード

FSLogix は個別のアプリケーションソフトウェアとなっています．
「https://learn.microsoft.com/ja-jp/fslogix/how-to-install-fslogix」にアクセスして「直接ダウンロード」のセクションにある「こちら」をクリックしてアプリケーションをダウンロードしてください．

「FSLogix_Apps_xxx.zip」というファイルがダウンロードされますので zip ファイルを展開してください．

ドメインコントローラーへのグループポリシーテンプレートの配置

展開したフォルダー直下に「fslogix.admx」と「fslogix.adml」というファイルがあります．
この2つのファイルをどれかのドメインコントローラーのセントラルストアにコピーします．

「fslogix.admx」ファイルは「C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions」にコピーします．

「fslogix.adml」ファイルは「C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\en-US」にコピーします．

クライアントへの FSLogix エージェントのインストール

zip ファイルを展開した中に「Win32」および「x64」フォルダーがあります．クライアントの OS 種別に合わせてそのフォルダーの中の「FSLogixAppsSetup.exe」をクライアントにコピーしてください．

クライアントに管理者アカウントでログインし「FSLogixAppsSetup.exe」を実行してインストーラーを起動します．

インストーラーが起動したら「I agree to the license terms and conditions」にチェックを入れ「Install」をクリックします．

「ユーザーアカウント制御」の警告が表示されますので「はい」をクリックします．

インストールが進み「Setup Successful」と表示されたら「Close」をクリックしてインストーラーを終了します．

クライアントを再起動させます．

グループポリシーの構成

サーバーマネージャーの「ツール」をクリックし「グループポリシーの管理」をクリックします．

ツリーを展開し「グループポリシーオブジェクト」を表示，右クリックで「新規」をクリックします．

グループポリシーの名前を入力して「OK」をクリックします．今回は「FSLogix」という名前にしました．

作成したポリシーを選択，右クリックし「編集」をクリックします．

「コンピューターの構成」-「ポリシー」-「管理用テンプレート」-「FSLogix」-「Profile Containers」とツリーを辿っていきます．

VHD Locations

FSLogix 仮想ハードディスクを保存するファイルサーバーパスを定義するポリシーです．
VHD Locations をダブルクリックし「有効」を選択のうえファイルサーバーパスを入力します．
今回は先ほど作成している DFS パスの「\\lab.seichan.org\Profiles\FSLogix」を入力しています．

入力が終わったら「適用」をクリックし「OK」をクリックしてウィンドウを閉じます．

Size In MBs

FSLogix 仮想ハードディスクの最大サイズを設定するポリシーです．最小値は 500MB です．
10GB 以上を推奨します．今回は 10GB を設定しています．
「有効」をクリックし，サイズを入力後「適用」をクリックのうえ「OK」をクリックしてウィンドウを閉じます．

Delete Local Profile When VHD Should Apply

ローカルプロファイルがすでに存在する場合，削除するポリシーです．
利用中の端末の場合，この設定が有効でない場合 FSLogix に切替されません．

なお，この設定を有効にして FSLogix に切り替わった場合，新規のポリシーとして作成されますので，利用中での切り替えの場合は必要設定は別途移行を行う必要があります．

「有効」をクリックし「適用」をクリック，「OK」をクリックしてウィンドウを閉じます．

Enabled

FSLogix を有効にするかどうかを設定するポリシーです．
「有効」をクリックし，「適用」をクリック，「OK」をクリックしてウィンドウを閉じます．

続いて一段したのツリーのポリシー設定になります．
「コンピューターの構成」-「ポリシー」-「管理用テンプレート」-「FSLogix」-「Profile Containers」-「Container and Directory Naming」とツリーを辿っていきます．

Volume Type (VHD or VHDX)

仮想ハードディスクのタイプを設定します．VHDX が新しい仮想ディスクタイプですのでこちらを推奨します．大きな違いは最大容量とセクターサイズになります．

「有効」をクリックし，「VHDX」を選択のうえ「適用」をクリック，「OK」をクリックしてウィンドウを閉じます．

Flip Flop Profile Directory Name

FSLogix 仮想ハードディスクを作成，保存するフォルダー名の規則を変えるポリシーです．
このポリシーが未構成の場合は「SID_ユーザー名」となります．有効にすることで「ユーザー名_SID」という形式になり，管理が容易になります．

「有効」をクリックし，「適用」をクリックし「OK」をクリックしてウィンドウを閉じます．

その他にも設定項目は多岐にわたりますが，最低限は以上となります．
設定項目と説明はどこかで纏められればいいなぁ… と考えています．
(期待はしないでください)

グループポリシーのリンク

作成したポリシーをリンクします．FSLogix の設定はコンピューターですので，コンピューターが格納されている OU に対してリンクする必要があります．
今回は「Computer」OU に適用を行います．

適用したい OU を選択，右クリックし「既存の GPO のリンク」をクリックします．

作成したポリシーを選択して「OK」をクリックします．

なお，移動ユーザープロファイルとバッティングしますので，移動ユーザープロファイルはリンクの無効もしくは削除を実施します．今回は削除を実施しています．
OU からリンクを削除したいポリシーを選択，右クリックで「削除」をクリックします．

確認が促されますので「OK」をクリックして削除を完了します．

以上で FSLogix を利用するための設定は完了です．

FSLogix の動作確認

では実際に動作の確認を行ってみましょう．
クライアント OS にログオンを行います．

既にローカルプロファイルが存在していた場合でも，今回の設定では新しくプロファイルが作成されます．

フォルダーリダイレクトでリダイレクトを行っている箇所は継続してフォルダーリダイレクトが利用されます．デスクトップに表示されているフォルダーがリダイレクトが継続利用できていることを示しています．

FSLogix のマウントを確認する

クライアントがどのように FSLogix 領域を利用しているのかを確認してみましょう．
VHD/VHDX をマウントしていることを「コンピューターの管理」より確認することができます．
なお「ディスクの管理」は管理者権限が必要です．

「コンピューターの管理」を右クリックし「管理者として実行」をクリックします．

「記憶域」-「ディスクの管理」を表示すると，Profile_<ユーザー名>としてディスクがマウントされていることが確認できます．

C:\Users 以下を確認してみます．seichan でログオンしています．
「local_seichan」がこの端末にのみ保持される情報 (FSLogix の範囲外になっているもの)，「seichan」が FSLogix の領域 (実体は VHD/VHDX ファイルの中) になります．

サーバー側で確認する

ファイルサーバーをみるとこのようにデータが作成されます．
FSLogix で指定したフォルダーにユーザー毎にフォルダーが作成されます．

フォルダーの中をみると VHDX ファイルとメタデータファイル (拡張子 metadata) が確認できます．
メタデータファイルが存在している場合，この VHDX ファイルは利用中 (ユーザーがログオン中) になります．

サーバーでマウントしてデータを確認する

VHD/VHDX ファイルは Windows Server でマウントすることができます．
実際にマウントを行って中を確認してみます．

マウントしたい VHD/VHDX ファイルを選択，右クリックし「マウント」をクリックします．

ファイルを開くか確認される場合があります．その場合は「開く」をクリックします．

マウントができなかった旨が表示される場合があります．これは正常です．次の「コンピューターの管理」で対処することで中身を確認できるようになります．

サーバーマネージャーの「ツール」-「コンピューターの管理」をクリックします．

「記憶域」-「ディスクの管理」を開き，マウントした VHD/VHDX ディスクを右クリックして「ドライブ文字とパスの変更」をクリックします．

「追加」をクリックします．

ドライブ文字を割り当てるもしくは，マウントするパスを指定します．今回は「F:」ドライブを割り当てます．
割り当てたいドライブレターもしくはパスを選択して「OK」をクリックします．

マウントした場所へアクセスすると中身の確認ができます．

この確認を行った後はディスクの切断を行わないと利用者がログオンできない (できても初期プロファイルになってしまう) 為，リストアを行いたいなどのトラブル時のみにしまよう．

以上，FSLogix の説明を終わります．
新しいユーザープロファイルの持ち方としてぜひ FSLogix を活用しましょう．

• Active Directory ドメインサービスに関するお話
  • Active Directory ドメインサービス – 概要
  • Active Directory ドメインサービス – Active Directory ドメインの構成 1台目
  • Active Directory ドメインサービス – Active Directory ドメインの構成 2台目
  • Active Directory ドメインサービス – 組織単位 (OU)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントの作成)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントプロパティ)
  • Active Directory ドメインサービス – アカウントの管理 (グループアカウントの作成・管理)
  • Active Directory ドメインサービス – グループポリシー (グループポリシー設定の前準備)
  • Active Directory ドメインサービス – クライアントのドメイン参加
  • Active Directory ドメインサービス – 一般ユーザーアカウントでのドメイン参加の制限
  • Active Directory ドメインサービス – グループポリシーの設定，適用 (パスワードポリシー)
  • Active Directory ドメインサービス – 移動ユーザープロファイルの構成と確認
  • Active Directory ドメインサービス – フォルダーリダイレクトの構成と確認
  • Active Directory ドメインサービス – FSLogix の構成と確認

• Active Directory ファイルサーバーに関するお話
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する 「SMBの解説」
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する「ファイルサーバーリソースマネージャーの導入」
  • Windows ファイルサーバー – DFS (Distributed File System/分散ファイルシステム) と DFSR (DFS Replication/DFS レプリケーション)
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する「共有の作成とアクセス権の設定」
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する「クォータの設定」
  • Windows ファイルサーバー – DFS 名前空間とDFS レプリケーションの構成

フォルダーリダイレクトとは

フォルダーリダイレクトとは移動プロファイルと違い「デスクトップ」や「ドキュメント」のデータをローカルに保持せずに，直接ファイルサーバーを参照し，データをローカルに置かないで運用が可能になる技術です．

これによってログオン・ログオフ時のファイルサーバーからの読み出し，書き戻しが無くなります．
また，クライアント端末ローカルにデータを保持しないためクライアント側のディスク領域の節約にもつながります．

以下の例ですと「デスクトップ」などフォルダーリダイレクト対象にできるものは全部対象とした場合ですが，一部だけ対象にする，もしくは一部だけ除外する．ということも可能です．
(積極的にそのようにする理由はありませんが)

また，壁紙などのユーザーの設定情報はフォルダーリダイレクトの対象にはなりません．これは引き続き移動ユーザープロファイルを用いる必要があります．
従って，一般的に構成する方式は次のようなイメージになります．

ユーザーの設定情報は引き続き移動ユーザープロファイルを利用します．ログオン・ログオフ時はファイルサーバーからの読み出し，書き戻しが必要ではありますが，対象となるデータは大幅に減ります．

「デスクトップ」や「ダウンロード」は透過的にファイルサーバーアクセスするように構成されるため，ユーザーは意識する必要がありません．また，該当フォルダーのデータの編集の際にファイルサーバーアクセスが発生するため，ログオン・ログオフ時の負荷が大きく削減できます．

フォルダーリダイレクトの構成

ファイルサーバー領域の作成

フォルダーリダイレクトとしてファイルサーバーにデータを保管しますので，共有を作成する必要があります．
管理上，移動ユーザープロファイルとは別の場所に作成を行う事をお勧めします．

作成の方法については以下の記事を参考にしてください．今回の共有名は「FolderRedirect」として以降解説していきます

• Windows ファイルサーバー – ファイルサーバーサービスを構成する「共有の作成とアクセス権の設定」
  • この記事を参考に「FolderRedirect」の共有を作成します
  • アクセス権はこの記事と同様で大丈夫です

• Windows ファイルサーバー – ファイルサーバーサービスを構成する「クォータの設定」
  • この記事を参考に「FolderRedirect」に対してクォータを適用します
  • ユーザーデータが置かれる領域になりますので「10GB」など多少容量が大きい設定をお薦めします

• Windows ファイルサーバー – DFS 名前空間とDFS レプリケーションの構成
  • この記事を参考に「FolderRedirect」用の DFS 名前空間を作成してください
  • 名前空間は「Profiles」をそのまま利用頂く形式で大丈夫です．
    • \\<ドメイン名>\Profiles\FolderRedirect というパス名になるように設定してください
  • 冗長構成をとる為，DFS レプリケーションも合わせて構成をしてください

フォルダーリダイレクトの構成

サーバーマネージャーの「ツール」をクリックし「グループポリシーの管理」をクリックします．

ツリーを展開し「グループポリシーオブジェクト」を表示，右クリックで「新規」をクリックします．

グループポリシーの名前を入力して「OK」をクリックします．今回は「フォルダーリダイレクト」という名前にしました．

作成したポリシーを選択，右クリックし「編集」をクリックします．

「ユーザーの構成」-「ポリシー」-「Windowsの設定」-「フォルダーリダイレクト」とツリーを辿っていきます．
フォルダーリダイレクトのツリーを展開すると「AppData(Roaming)」や「デスクトップ」などの項目が確認できます．

AppData(Roaming) の構成

AppData(Roaming) を選択，右クリックして「プロパティ」をクリックします．

「ターゲット」タブの設定にて「基本 – 全員のフォルダーを同じ場所へリダイレクトする」を選択します．
対象フォルダーの場所は「ルートパスの下に各ユーザーのフォルダーを作成する」を選択し，ルートパスにファイルサーバーパスを入力します．
今回は「\\lab.seichan.org\Profiles\FolderRedirect」を入力します．この場合，次のようにリダイレクトフォルダーが作成されます．
「\\lab.seichan.org\Profiles\FolderRedirect\<ユーザー名>\Roaming」

「設定」タブをクリックし「ユーザーに AppData(Roaming) に対して排他的な権限を与える」のチェックを外します．
これにチェックがついたままですと，Administrator のアクセスができない状態となります．

設定が完了したら「適用」をクリックし「OK」で完了します．

「デスクトップ」およびその他の構成

AppData(Roaming) と同様の設定を行います．
フォルダーリダイレクトとして指定可能な項目は「デスクトップ」，「スタートメニュー」，「ドキュメント」，「Puctures」，「ミュージック」，「Videos」，「お気に入り」，「連絡先」，「ダウンロード」，「リンク」，「検索」，「保存されたゲーム」です．

移動ユーザープロファイルを構成している場合，ここでフォルダーリダイレクトを行わない場合は全て移動ユーザープロファイルの中に収められることになります．
ですので，全体的にフォルダーリダイレクトの対象として設定することが望ましいです．

グループポリシーのリンク

作成したポリシーをリンクします．フォルダーリダイレクトはユーザーポリシーですので，ユーザーが格納されている OU に対してリンクする必要があります．
今回は「User」OU に適用を行います．

適用したい OU を選択，右クリックし「既存の GPO のリンク」をクリックします．

作成したポリシーを選択して「OK」をクリックします．

リンクしたポリシーを選択し「設定」タブをクリックして設定状況を確認しておきます．

以上でフォルダーリダイレクトの設定が完了です．

フォルダーリダイレクト動作の確認

では実際に動作の確認を行ってみましょう．

ログイン後，すでにデスクトップに作成済みだったフォルダーのパスを確認してみます．
次のように，ローカルデスクトップではなく，ファイルサーバーに存在していることが確認できます．

ファイルサーバー上でもどのように見えているのか確認します．
このように，ファイルサーバー上にフォルダーがいることが確認できます．

この，元々ローカルにファイルがあったものがフォルダーリダイレクト先に移動されるのはグループポリシーでそのように設定を行ったからです．
フォルダーリダイレクトの「設定」タブ内の「○○の内容を新しい場所に移動する」のチェックがついていればこの動作になります．

フォルダーリダイレクト可能なものを全て対象にした場合，ファイルサーバーからみると次のように見えます．

以上で，移動ユーザープロファイル＋フォルダーリダイレクトの構成の説明を終わります．
最後になりますが，この方法は今までのやり方になっており，新しい方法として FSLogix を利用したプロファイルのモビリティが利用されます．次はその説明を行いたいと思います．

• Active Directory ドメインサービスに関するお話
  • Active Directory ドメインサービス – 概要
  • Active Directory ドメインサービス – Active Directory ドメインの構成 1台目
  • Active Directory ドメインサービス – Active Directory ドメインの構成 2台目
  • Active Directory ドメインサービス – 組織単位 (OU)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントの作成)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントプロパティ)
  • Active Directory ドメインサービス – アカウントの管理 (グループアカウントの作成・管理)
  • Active Directory ドメインサービス – グループポリシー (グループポリシー設定の前準備)
  • Active Directory ドメインサービス – クライアントのドメイン参加
  • Active Directory ドメインサービス – 一般ユーザーアカウントでのドメイン参加の制限
  • Active Directory ドメインサービス – グループポリシーの設定，適用 (パスワードポリシー)
  • Active Directory ドメインサービス – 移動ユーザープロファイルの構成と確認
  • Active Directory ドメインサービス – フォルダーリダイレクトの構成と確認
  • Active Directory ドメインサービス – FSLogix の構成と確認

• Active Directory ファイルサーバーに関するお話
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する 「SMBの解説」
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する「ファイルサーバーリソースマネージャーの導入」
  • Windows ファイルサーバー – DFS (Distributed File System/分散ファイルシステム) と DFSR (DFS Replication/DFS レプリケーション)
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する「共有の作成とアクセス権の設定」
  • Windows ファイルサーバー – ファイルサーバーサービスを構成する「クォータの設定」
  • Windows ファイルサーバー – DFS 名前空間とDFS レプリケーションの構成

ユーザープロファイルとは

ユーザープロファイルとは，Windows クライアントの中に保持されている各ユーザーの設定情報になります．
壁紙の設定であったり，タスクバーのカスタマイズ情報などの設定情報になります．
また，この中には「デスクトップ」や「ドキュメント」のフォルダーおよびデータも含まれます．

移動ユーザープロファイルとは

移動ユーザープロファイルは，ユーザーの設定情報をファイルサーバーに保存することで，設定情報のモビリティを確保する技術になります．
複数の端末を利用する際に同じ設定，同じデータ（ドキュメントやデスクトップの中のデータ）が利用できるようになります．

これによって会社や学校などで不特定の席・端末を利用しなければならない場合でも，常に自分の設定が維持され，保存しているデータが利用可能な状態で Windows を操作することが可能になります．

移動ユーザープロファイルはメリットだけではありません．以下にメリットとデメリットを記載します．

メリット

• 設定状態を維持できる
• ダウンロードやデスクトップなどのデータを他の端末で利用できる
• ファイルサーバーにデータが置かれるので，ファイルサーバーのバックアップを考えるだけで良くなる

デメリット

• ログオン/ログオフ時にファイルサーバーからダウンロード/アップロードを行うため待ちが発生する
  • 特にドキュメントやデスクトップに大量のデータがある場合に顕著になる
• 各 Windows クライアントにデータが残ったままとなる為，多数のユーザーが利用する場合ディスク領域を圧迫してトラブルになる場合がある

デメリット部分を解消する仕組みとして「フォルダーリダイレクト」という技術があります．これは次回説明を行います．
今回は全てを移動ユーザープロファイルにする場合の設定および動作を確認します．

移動ユーザープロファイルの設定

サーバーマネージャーの「ツール」をクリックし「グループポリシーの管理」をクリックします．

ツリーを展開し「グループポリシーオブジェクト」を表示，右クリックで「新規」をクリックします．

グループポリシーの名前を入力して「OK」をクリックします．今回は「移動ユーザープロファイル」という名前にしました．

作成したポリシーを選択，右クリックし「編集」をクリックします．

「コンピューターの構成」-「ポリシー」-「管理用テンプレート」-「システム」-「ユーザープロファイル」とツリーを辿っていきます．
「このコンピューターにログオンしているすべてのユーザーの移動プロファイルパスを設定する」を選択しダブルクリックします．

設定を「未構成」から「有効」に変更し，移動ユーザープロファイルを保存するファイルサーバーパスを入力します．
今回は前回作成した DFS の領域である「\\lab.seichan.org\Profiles\RoamingProfiles」を入力します．
ここで一つポイントがあり「%USERNAME%」を追加します．これは変数でログオンしたアカウントIDに置き換わります．例えば「seichan」がログオンしたら「%USERNAME%」は「seichan」になります．
正式なパスとしては「\\lab.seichan.org\Profiles\RoamingProfiles\%USERNAME%」のようにユーザー名の変数を含めて入力します．

パスの入力が終わったら「適用」をクリックしてその後「OK」をクリックします．

続いて「Administrators セキュリティグループを移動ユーザープロファイルに追加する」を選択，ダブルクリックして設定を開きます．
この設定を入れない場合，移動ユーザープロファイルは Administrators 権限を持つ管理者でもアクセスができなくなってしまいます．

設定を「未構成」から「有効」に変更して「適用」，「OK」をクリックします．

グループポリシー編集エディターを終了し，作成したポリシーをリンクさせます．今回は「Computers」OU にリンクを行います．
適用したい OU を選択，右クリックし「既存の GPO のリンク」をクリックします．

作成したポリシーを選択して「OK」をクリックします．

リンクしたポリシーを選択し「設定」タブをクリックして設定状況を確認しておきます．

以上で移動ユーザープロファイルの設定が完了です．

移動ユーザープロファイル動作の確認

では実際に動作の確認を行ってみましょう．

1台目でログオンしてファイルを作成する

まずは1台目のクライアントにログオンします．

今回はテストとしてデスクトップにフォルダーを作成して動作を確認します．

このまま1台目の OS からログオフ(サインアウト)を行います．
ログオフの際に，プロファイルデータやユーザーデータをファイルサーバーに書き戻しが行われます．「ドキュメント」や「ダウンロード」，「デスクトップ」に大量のデータがある場合ログオフに時間がかかります．

2台目でログオンして確認する．また，設定変更を行ってみる

2台目の OS にログオンします．ログオンが完了すると，1台目で作成していたフォルダーが表示されることが確認できます．
ログオンの際にファイルサーバーからデータの読み取りが行われます．ログオンの際も同様に「ドキュメント」などに大量のデータが多い場合，そのコピーに時間を要してログオンに時間がかかります．

2台目の OS にて Windows の設定変更を試してみます．背景を画像から単色に変えてみます．

2台目の OS からログオフ (サインアウト) します．

再度1台目で確認する

1台目の OS に再度ログオンしてみます．2台目で行った設定が引き継がれていることが確認できます．

ファイルサーバーでの見え方

ファイルサーバーから見ると，プロファイルデータはこのようにフォルダーとして存在します．

「seichan.v6」の中をみると「デスクトップ」や「ダウンロード」などのフォルダーがあることが確認できます．

以上，移動ユーザープロファイルの解説です．
実際は全てを移動ユーザープロファイルで行うことは少なく，フォルダーリダイレクトと共に利用される場合が多いです．

次回はフォルダーリダイレクトについては触れていきます．

• Active Directory ドメインサービスに関するお話
  • Active Directory ドメインサービス – 概要
  • Active Directory ドメインサービス – Active Directory ドメインの構成 1台目
  • Active Directory ドメインサービス – Active Directory ドメインの構成 2台目
  • Active Directory ドメインサービス – 組織単位 (OU)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントの作成)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントプロパティ)
  • Active Directory ドメインサービス – アカウントの管理 (グループアカウントの作成・管理)
  • Active Directory ドメインサービス – グループポリシー (グループポリシー設定の前準備)
  • Active Directory ドメインサービス – クライアントのドメイン参加
  • Active Directory ドメインサービス – 一般ユーザーアカウントでのドメイン参加の制限
  • Active Directory ドメインサービス – グループポリシーの設定，適用 (パスワードポリシー)
  • Active Directory ドメインサービス – 移動ユーザープロファイルの構成と確認
  • Active Directory ドメインサービス – フォルダーリダイレクトの構成と確認
  • Active Directory ドメインサービス – FSLogix の構成と確認

パスワードポリシー

パスワードポリシーですが，Active Directory ドメイン構成時に自動的に設定される「Default Domain Policy」で次のように定義されています．

• パスワードの長さ 7文字以上
• パスワードの変更禁止期間 1日
• パスワードの有効期間 42日
• パスワードの履歴を記録する 24個のパスワード
• パスワードは要求する複雑さを満たす 有効
• 暗号化を元に戻せる状態でパスワードを保存する 無効
• アカウントのロックアウトのしきい値 0 回の無効なログオン試行

新しいパスワードポリシーですが，NIST (National Institute of Standards and Technology/米国国立標準技術研究所) が提唱しており，これに準じる形で総務省や内閣セキュリティセンターもこのポリシーにしましょうと啓蒙している所です．
どのようなポリシーなのかというと次のとおりです．

実施すべきではない

• 大文字，小文字や特殊文字，桁を一定数必要とするパスワードの複雑さの要件を設定すること
• パスワードに有効期限を設定すること
• パスワードを思い出させるためのヒントを使用すること
• ユーザーの個人的な情報をセキュリティ質問で使用すること

実施すべき

• パスワードの長さ 8文字～64文字
• 文字のタイプ ASCII 以外も利用可能であれば使うこと
• Password1! とか qazwsx のような類推されるパスワードはブラックリストに設定すること
• 強固なパスワードチェッカーを用いること
• 連続で認証失敗した場合にアカウントをロックすること
• パスワードの入力でコピー & ペーストを認めること
• 二要素認証を利用すること

参考となるサイト，文章は次のサイトとなります．

• NIST Special Publication 800-63B
  • https://pages.nist.gov/800-63-3/sp800-63b.html
• NIST SP 800-63-3の概要と今回の改訂がもたらす影響
  • https://www.jipdec.or.jp/sp/library/report/20171127.html
• NISC インターネットの安全・安心ハンドブック
  • https://security-portal.nisc.go.jp/guidance/handbook.html

Active Directory ドメインサービスのグループポリシーだけでは記載全てのことをできる訳ではありませんが，これに少しでも近づけて行くことを考えてみます．
以下が近づけた結果となります．

• パスワードの長さ 8文字以上
• パスワードの変更禁止期間 0日
• パスワードの有効期間 0日
• パスワードの履歴を記録する 0個のパスワード
• パスワードは要求する複雑さを満たす 有効
• アカウントのロックアウトのしきい値 5 回の無効なログオン試行
• ロックアウト期間は 10 分

これをグループポリシーとして作成，適用を行っていきます．「Default Domain Policy」を編集してもよいのですが，個人的にはデフォルトポリシーは弄るのが好きでは無いため，別のポリシーを作成，リンクさせ，優先順位で有効になるように実施をします．

グループポリシーの作成とリンク

サーバーマネージャーの「ツール」をクリックし「グループポリシーの管理」をクリックします．

ツリーを展開し「グループポリシーオブジェクト」を選択，右クリックして「新規」をクリックします．

ポリシー名を入力するウィンドウが開きますので名前を入力します．スターター GPO は無しを選択して「OK」をクリックします．
今回の環境での名前は「lab.seichan.org Default Policy」とします．

ポリシーが作成されているので選択，右クリックし「編集」をクリックします．

選択したポリシーの編集画面が表示されます．今回はパスワード，アカウントに関する箇所なので「コンピューターの構成」-「ポリシー」-「Windowsの設定」-「セキュリティの設定」-「アカウントポリシー」以下の項目になりますので，ツリーを開いていきます．

パスワードポリシーの変更

パスワードポリシーとして長さや期間などを設定します．「パスワードのポリシー」をクリックします．右側に項目の一覧が表示されます．

「パスワードの長さ」をダブルクリックして開きます．開くと次のような画面になるので，チェックを入れて「8文字以上」として「適用」をクリック，その後「OK」をクリックします．

続いて「パスワードの変更禁止期間」を設定します．開くと次のような画面になるので，チェックを入れて「0日」として「適用」をクリックします．

提案された値の変更という画面が表示されますので「OK」をクリックし，改めて「適用」をクリック，その後「OK」をクリックします．

続いて「パスワードの有効期間」を設定します．開くと次のような画面になるので，チェックを入れて「0日」として「適用」をクリックします，その後「OK」をクリックします．

続いて「パスワードの履歴を保存する」を設定します．開くと次のような画面になるので，チェックを入れて「0回」として「適用」をクリックします，その後「OK」をクリックします．

最後に「複雑さの要件を満たす必要があるパスワード」についてですが，これは「Default Domain Policy」を引き継ぎますので設定は行いません．

ロックアウトの変更

アカウントロックアウトの設定を行います．「アカウントロックアウトのポリシー」をクリックします．右側に項目の一覧が表示されます．

「アカウントロックアウトのしきい値」をダブルクリックして開きます．開くと次のような画面になるので，チェックを入れて「5回」として「適用」をクリックします．

提案された値の変更という画面が表示されますので「OK」をクリックし，改めて「適用」をクリック，その後「OK」をクリックします．

ロックアウトカウンターのリセット，ロックアウト期間が提案で自動設定された値を採用できそうなので追加の修正は行いません．
管理者アカウントについてもロックアウト対象にされていますが，これについても修正は行いません．
(このあたりは実際の要件に応じて修正ください)

ポリシーのリンク

では，作成したポリシーをリンクさせていきます．まずは，編集したグループポリシーのウィンドウを閉じます．
続いて「グループポリシーの管理」画面でドメイン名を右クリックし「既存の GPO のリンク」をクリックします．

ポリシーの一覧が表示されますので，先ほど作成したポリシーを選択して「OK」をクリックします．

右側ウィンドウの「グループポリシーの継承」タブをクリックします．この場合，優先順位が「Default Domain Policy」が高い状態になっていますので，優先順位をする必要があります．

右側ウィンドウの「リンクされたグループポリシーオブジェクト」タブをクリックします．リンクの順序として「Default Domain Policy」と「作成したポリシー」が並んでいます．

「Default Domain Policy」のリンクの順序を下げるため「Default Domain Policy」をクリックして選択，その後「下矢印」アイコンをクリックします．

リンクする順番が変わって次のようになります．

改めて「グループポリシーの継承」タブをクリックして適用の順番を確認します．

以上でパスワードポリシーの修正，適用は完了です．実際に正しい動作になるのかを確認してみます．

ポリシーの動作確認

作成，リンクしたポリシーが正しく反映されているのかクライアントを操作して確認を行ってみます．

パスワードポリシーの変更確認

クライアントにログオンしている状態で「Ctrl+Alt+Delete」を押します．リモートデスクトップの場合は「Ctrl+Alt+End」に変えてください．次のような画面に変わりますので「パスワードの変更」をクリックします．

パスワード文字列が8文字未満の場合

パスワードは8文字以上と設定されている為，7文字のパスワードに変えてみます．
現在のパスワードおよび新しいパスワードを入力して「右矢印」をクリックします．

次のとおり，要件を満たさないというエラーが出て変更ができないことが確認できます．

アカウントロックアウトの確認

一度ログオフして，5回パスワードを間違ってみます．6回目にログオンしようとするとこのような画面が表示されます．

ドメインコントローラーにてアカウントの状態を確認します．
「サーバーマネージャー」の「ツール」をクリックし，「Active Directory ユーザーとコンピューター」をクリックします．

該当ユーザーアカウントを選択，右クリックで「プロパティ」をクリックします．

プロパティの「アカウント」タブをクリックすると，真ん中の所に「このアカウントは現在、この Active Directory ドメインコントローラーでロックアウトされています。」の表示があります．これが出ているとロックアウトされている状態となります．

今の設定だと，10分で自動解除されますが，ここにチェックを入れて「適用」をクリックすることで手動でのロック解除ができます．

以上でアカウントロックアウトになることの確認，ドメインコントローラー上での確認及び手動解除の説明を終わります．

文章量はそんなになかったのですが，画像込みで長くなってしまったので，一般ユーザーでのドメイン参加の制御については次回に回します．

• Active Directory ドメインサービスに関するお話
  • Active Directory ドメインサービス – 概要
  • Active Directory ドメインサービス – Active Directory ドメインの構成 1台目
  • Active Directory ドメインサービス – Active Directory ドメインの構成 2台目
  • Active Directory ドメインサービス – 組織単位 (OU)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントの作成)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントプロパティ)
  • Active Directory ドメインサービス – アカウントの管理 (グループアカウントの作成・管理)
  • Active Directory ドメインサービス – グループポリシー (グループポリシー設定の前準備)
  • Active Directory ドメインサービス – クライアントのドメイン参加
  • Active Directory ドメインサービス – 一般ユーザーアカウントでのドメイン参加の制限
  • Active Directory ドメインサービス – グループポリシーの設定，適用 (パスワードポリシー)
  • Active Directory ドメインサービス – 移動ユーザープロファイルの構成と確認
  • Active Directory ドメインサービス – フォルダーリダイレクトの構成と確認
  • Active Directory ドメインサービス – FSLogix の構成と確認

一般ユーザーアカウントでのドメイン参加制限

先に記載のとおり，一般ユーザーは10回ドメイン参加をさせることができます．これはどれが担っているのかをまずは確認してみましょう．

ADSIエディターで制限値を確認する

「Windows」アイコンをクリックし「検索」で「ADSI」と入力します．「ADSIエディター」が候補に表示されるのでこれをクリックします．

「ADSI エディター」が起動したら，左上の「ADSI エディター」を右クリックして「接続」をクリックします．

接続の設定でラジオボタンで「既定の名前付けコンテキストを選択または入力する」が選択されていることと，「既定の名前付けコンテキスト」が選択されていることを確認して「OK」をクリックします．

元の画面に戻り「既定の名前付けコンテキスト」が表示されている状態になりますので，このツリーを一段展開して＜ドメイン名＞を表示させます．

表示された＜ドメイン名＞を右クリックし「プロパティ」をクリックします．

プロパティで「属性エディター」タブが選択されていることを確認し，属性名「ms-DS-MachineAccountQuota」の値を確認します．
この値が 10 になっているので，一般ユーザーアカウントでも10回のドメイン参加が可能ということになります．

一般ユーザーアカウントのドメイン参加を制限する

制限するには，この値を変えるだけで完了となります．変更するとそのドメインに対して一般ユーザーアカウントでのドメイン参加は設定した回数に制限されます．

今回は値を「0」にして，ドメイン参加は管理者のみとする形に変更をしてみます．
「ms-DS-MachineAccountQuota」を選択している状態で「編集」をクリックします．

「整数の属性エディター」というウィンドウが開きますので，ここに数量を入れて「OK」をクリックします．
(今回は「0」を入れます)

前の画面に戻り，値が更新されていることを確認したら「適用」をクリック，その後「OK」をクリックしてウィンドウを閉じます．

以上で設定は完了となります．実際に一般ユーザーアカウントでのドメイン参加を試してみて設定が有効になっていることを確認しましょう．

一般ユーザーでドメイン参加ができないことを確認する

では，実際にドメインに参加を行います．

一般ユーザーアカウントでのドメイン参加を試行する

タスクバーの「Windows」アイコンを右クリックし「システム」をクリックします．

詳細情報の下部の「このPCの名前を変更 (詳細設定)」をクリックします．

「コンピューター名」タブの「変更」をクリックします．

「コンピューター名/ドメイン名の変更」で「ドメイン」を選択してドメイン名を入力し「OK」をクリックします．

ドメインアカウントのユーザー名，パスワードを入力します．ユーザー名は <ドメイン名>\<ユーザー名> の形式で入力します．

「最大数を超えています。」のエラーが表示されました。ですので確かに「ms-DS-MachineAccountQuota」の値を「0」にした結果が反映されていることが確認できます．
「OK」をクリックして元の画面に戻ります．

管理者アカウントでのドメイン参加を試行する

次は管理者アカウント情報を用いてドメイン参加を行います．「OK」をクリックして次へ進みます．

管理者アカウントの情報を入力して「OK」をクリックします．

ドメインへの参加が成功し「＜ドメイン名＞ドメインへようこそ。」が表示されます。
従って，管理者アカウントは「ms-DS-MachineAccountQuota」の値に影響されないことも確認ができました。
その後再起動が求められますので再起動まで行います。

再起動したらドメインアカウントでログオンを行います．

ログオンが完了したことをもって，ドメインの参加，ドメインアカウントでのログオンが完了となります．

以上で一般ユーザーアカウントによるドメイン参加が行える回数制限についての説明を終わります．この設定，結構見逃されやすく，話題にも上らないことが多い印象ですのでご注意ください．

次は移動ユーザープロファイルやフォルダーリダイレクトなどのクライアントのデータをファイルサーバーに持つ仕組みへ進みたいと思います．その前準備としてファイルサーバーに触れていきます．

• Active Directory ドメインサービスに関するお話
  • Active Directory ドメインサービス – 概要
  • Active Directory ドメインサービス – Active Directory ドメインの構成 1台目
  • Active Directory ドメインサービス – Active Directory ドメインの構成 2台目
  • Active Directory ドメインサービス – 組織単位 (OU)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントの作成)
  • Active Directory ドメインサービス – アカウントの管理 (ユーザーアカウントプロパティ)
  • Active Directory ドメインサービス – アカウントの管理 (グループアカウントの作成・管理)
  • Active Directory ドメインサービス – グループポリシー (グループポリシー設定の前準備)
  • Active Directory ドメインサービス – クライアントのドメイン参加
  • Active Directory ドメインサービス – 一般ユーザーアカウントでのドメイン参加の制限
  • Active Directory ドメインサービス – グループポリシーの設定，適用 (パスワードポリシー)
  • Active Directory ドメインサービス – 移動ユーザープロファイルの構成と確認
  • Active Directory ドメインサービス – フォルダーリダイレクトの構成と確認
  • Active Directory ドメインサービス – FSLogix の構成と確認

クライアントの Active Directory ドメイン参加

クライアントを Active Directory ドメインへ参加させるにあたってまずはネットワークの設定，状態確認を行います．

クライアントのネットワーク設定

ドメイン参加するにあたり，Active Directory ドメインコントローラーと通信ができないといけません．
通信ができる．は DNS でドメインコントローラーの名前解決ができること，ネットワーク的に疎通が取れることです．

まず，クライアント PC のネットワーク設定を確認します．
今回はまだ DHCP サーバーがありませんので，静的に設定を行います．

「ネットワーク」アイコンをクリックします．

「ネットワークとインターネットの設定」をクリックします．

「アダプターのオプションを変更する」をクリックします．

利用するネットワークアダプターを選択，右クリックで「プロパティ」をクリックします．

「インターネットプロトコルバージョン 4」を選択し「プロパティ」をクリックします．

IPアドレスを入力します．DNS サーバーは Active Directory ドメインコントローラーの2台を指定しています．
設定内容を確認して「OK」をクリックします．

以上で，クライアントのネットワーク設定，確認は完了です．

ドメインコントローラーとの通信確認

ドメイン参加前にドメインコントローラーと通信の確認を行います．

タスクバーの入力ボックスで「cmd」と入力し「コマンドプロンプト」をクリックします．

「nslookup -querytype=ns <AD ドメイン名>」を入力してドメインコントローラーの名前，IP アドレスが返ることを確認します．
また，「nslookup <AD ドメイン名>」を入力して IP アドレスが返ることを確認します．

以上で，AD との疎通確認 (DNS による名前解決) は完了です．

クライアントのドメインの参加

では，実際にドメインに参加を行います．
タスクバーの「Windows」アイコンを右クリックし「システム」をクリックします．

詳細情報の下部の「このPCの名前を変更 (詳細設定)」をクリックします．

「コンピューター名」タブの「変更」をクリックします．

「コンピューター名/ドメイン名の変更」で「ドメイン」を選択してドメイン名を入力し「OK」をクリックします．

ドメインアカウントのユーザー名，パスワードを入力します．ユーザー名は <ドメイン名>\<ユーザー名> の形式で入力します．
ここ，最後に説明しますが，本来は「ドメイン管理者アカウント」が期待される状態だと思いますが，あえて「一般ユーザーアカウント」を入力しています．

「<ドメイン名> へようこそ。」画面が表示されたら「OK」をクリックします．

再起動が必要というウィンドウが表示されますので「OK」をクリックします．

「このPCの名前を変更 (詳細設定)」に戻るので「閉じる」をクリックします．

再起動を促すウィンドウが表示されますので「今すぐ再起動する」をクリックします．

再起動したらドメインアカウントでログオンを行います．

ログオンが完了したことをもって，ドメインの参加，ドメインアカウントでのログオンが完了となります．

最後になりますが，あえて「一般ユーザーアカウント」で Active Directory ドメインへ参加しました．
デフォルトの状態ではユーザーあたり10台のコンピューターをドメイン参加させる事が可能です．
この状態を良しとするのであればこのまま運用してもいいのですが，多くの環境ではこれを許したくないと思います．(もしくは1台だけに制限させるなどはあり得るかと思います．)

次回，グループポリシーの設定を行っていくにあたり，まずこの点を制限をかけることを例に実施したいと思います．
合わせて，パスワードポリシーも今の世の中のガイドラインに従った設定にしたいと思います．