Active Directory 基礎｜AD DS の仕組みと Server 2025 の変更点

はじめに

Windows Server を扱う上で、理解が欠かせない機能が Active Directory（AD）です。企業の社内ネットワークにおいて、ユーザーの ID やパスワード、コンピューターのアクセス権限などを一元管理する、Windows 環境におけるユーザー・デバイス管理の中核機能です。

Active Directory は単一の機能ではなく、5 つのサービス から構成されています。ただし、現場で単に「Active Directory」と言った場合、その多くは中心的な機能である Active Directory ドメインサービス（AD DS） を指しています。

本記事では、AD を構成する 5 つのサービスの概要と、その中心となる AD DS の仕組み（LDAP・Kerberos・DNS）について解説します。さらに、Windows Server 2025 で導入された機能アップデートや、2026 年に強制適用される RC4 暗号の非推奨化など、運用に直結する最新情報 にも触れます。

Active Directory を構成する「5 つのサービス」

Active Directory は、役割の異なる以下の 5 つのサービス群から構成されています。各サービスには 2026 年時点での運用上の注意点も併記します。

AD DS の仕組み（機能とプロトコル）

AD DS が正常に動作するために欠かせない、3 つの主要な機能・プロトコルについて解説します。

LDAP（情報の保管庫）

LDAP（Lightweight Directory Access Protocol） は、AD のデータベースにアクセスするための標準的なプロトコルです。AD 内のユーザーやコンピューターの情報は、ファイルシステムのような 階層構造（ツリー構造） で管理されています。この構造全体を DIT（Directory Information Tree） と呼びます。

LDAP の通信ポートは以下の 2 種類が標準的に使用されます。

• LDAP（平文）: TCP 389
• LDAPS（SSL/TLS 暗号化）: TCP 636

例えば、example.com というドメインの中に、SE 部門、NETWORK チームがあり、そこに user01 が所属している場合、住所（DN: Distinguished Name）は以下のように表現されます。

CN=user01,OU=NETWORK,OU=SE,DC=example,DC=com

参考: Active Directory の最大の制限（Microsoft Learn）
“Active Directory uses an Extensible Storage Engine (ESE) database since its introduction in Windows 2000 that uses an 8k database page size.”
（Active Directory は Windows 2000 での導入以来、8K ページサイズの ESE データベースを使用してきました）
https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025

認証（Kerberos / ケルベロス）

AD ドメイン環境での標準的な認証方式には、Kerberos（ケルベロス）認証 が採用されています。これは、パスワードそのものをネットワークに流すのではなく、「チケット（通行手形）」 を使って安全に認証を行う仕組みです。

Kerberos 認証の流れ

【重要】2026 年に予定されている RC4 暗号の非推奨化

Kerberos の暗号化方式として長年利用されてきた RC4（Rivest Cipher 4） は、Kerberoasting 攻撃などへの脆弱性が指摘されており、Microsoft は段階的な廃止を進めています。

参考: Detect and Remediate RC4 Usage in Kerberos（Microsoft Learn）
“Starting with Windows Server 2025, domain controllers don’t issue RC4 Ticket Granting Tickets.”
（Windows Server 2025 以降、ドメインコントローラーは RC4 形式の TGT を発行しません）
https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos

サードパーティ製の NAS、レガシーアプリケーション、古いプリンタなどが RC4 にのみ依存している場合、2026 年 4 月以降に認証エラーが発生する可能性があります。事前に環境内の RC4 使用状況を監査し、AES-SHA1 への移行を進めておくことを推奨します。

NTLM の段階的な廃止

AD DS の認証では、Kerberos が利用できない場面で NTLM がフォールバック認証として動作してきました。しかし、NTLM はリレー攻撃や Pass-the-Hash 攻撃に脆弱なため、Microsoft は段階的な無効化を進めています。

• NTLMv1: Windows Server 2025 / Windows 11 24H2 で 完全に削除済み
• NTLMv2: 将来の Windows Server LTSC リリースで既定で無効化予定（既存環境では引き続き動作）

参考: Advancing Windows security: Disabling NTLM by default（Microsoft Tech Community）
“In the next major Windows Server release and associated Windows client releases: Network NTLM will be disabled by default.”
（次期メジャーリリースでは、ネットワーク NTLM が既定で無効化されます）
https://techcommunity.microsoft.com/blog/windows-itpro-blog/advancing-windows-security-disabling-ntlm-by-default/4489526

DNS（名前解決と場所の特定）

「AD と DNS は一心同体」と言われるほど、DNS は重要な役割を持ちます。AD の DNS には大きく 2 つの役割があります。

名前解決

ドメインに参加しているコンピューターの IP アドレスとホスト名を自動的に登録・管理します。

DC の場所特定（重要）

クライアント PC がログオンする際、「ドメインコントローラーはどこにいるか」を探すために DNS を使います。この時参照されるのが SRV レコード（サービス リソース レコード） です。

「ログオンが遅い」「AD に繋がらない」というトラブルが発生した場合、DNS の SRV レコードが正しく登録されているかを確認することが解決の早道です。

コマンドプロンプトでの SRV レコード確認

C:\Users\Administrator> nslookup
> set type=srv
> _ldap._tcp.dc._msdcs.example2.com
サーバー:  localhost
Address:  127.0.0.1

権限のない回答:
_ldap._tcp.dc._msdcs.example2.com       SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ad03.example2.com

ad03.example2.com       internet address = 192.168.1.133

PowerShell での SRV レコード確認（推奨）

Windows Server 2016 以降では、PowerShell の Resolve-DnsName コマンドレットでより柔軟な確認が可能です。

PS C:\> Resolve-DnsName -Type SRV -Name _ldap._tcp.dc._msdcs.example2.com

Name                                    Type   TTL   Section    NameTarget
----                                    ----   ---   -------    ----------
_ldap._tcp.dc._msdcs.example2.com       SRV    600   Answer     ad03.example2.com

参考: Windows および Windows Server のドメインネームシステム（Microsoft Learn）
“DNS は Active Directory Domain Services (AD DS) に不可欠であり、認証、更新、検索などの操作のドメインコントローラーの場所メカニズムとして機能します。”
https://learn.microsoft.com/ja-jp/windows-server/networking/dns/dns-overview

AD DS の適用範囲（論理構造）

Active Directory は、管理のしやすさやセキュリティ要件に応じて、以下の 4 つの階層構造で管理されます。

ドメイン（Domain）

Active Directory の 基本単位 です。ドメインに参加したユーザーやコンピューターは、そのドメイン内のリソース（ファイルサーバーやプリンターなど）に対して、認証を経てアクセスできるようになります。

管理者（Domain Admins）はドメイン全体に対して強力な権限を持ちます。

OU（組織単位 / Organizational Unit）

ドメインの中をさらに細かく区切るための、フォルダのような管理単位です。例えば「営業部」「総務部」といった部署ごとに OU を作成し、そこにユーザーや PC を格納します。

この仕組みの最大のメリットは、OU ごとに異なるグループポリシー（GPO）を適用できる点 です（例: 営業部 OU は USB メモリ使用禁止、など）。

ドメインツリー（Domain Tree）

1 つのドメインの下に、名前空間を共有する別のドメイン（子ドメイン）を追加した構成です。これを 親子関係 と呼びます。

• 親ドメイン: example.com
• 子ドメイン: a.example.com（親の名前を引き継ぐ）

親子関係にあるドメイン同士は、自動的に 双方向の信頼関係 が結ばれ、お互いのリソースにアクセス可能になります。

フォレスト（Forest）

Active Directory における 最大の管理単位 です。1 つ以上の「ドメインツリー（木）」が集まって「フォレスト（森）」を形成します。

フォレスト内のドメイン同士は、名前空間（例: example.com と test.local）が違っても、互いに信頼関係を結んで連携できます。

• シングル・フォレスト: すべてのドメインを 1 つのフォレスト内で管理する構成。管理が容易で、一般的に採用されます。
• マルチ・フォレスト: セキュリティ境界を完全に分けたい場合などに、複数のフォレストに分ける構成。

信頼関係（Trust）とは

異なるドメイン間で、ユーザーがリソース（ファイルサーバーなど）を利用できるようにするための契約を 信頼関係 と呼びます。信頼関係には、大きく分けて 方向 と 推移性 という 2 つの重要な概念があります。

方向（片方向・双方向）

「どちらのドメインのユーザーが、どちらのドメインにアクセスできるか」を定義します。

双方向の信頼

お互いのドメインのユーザーが、お互いのリソースにアクセス可能。フォレスト内のドメイン間（親子など）は、既定でこの「双方向」が結ばれます。

片方向の信頼

一方通行のアクセス。例えば「A ドメインが B ドメインを信頼する」と設定した場合、B ドメインのユーザーが A ドメインにアクセスできる ようになります（信頼した側 A は扉を開け、信頼された側 B が入ってくるイメージ）

推移性（推移性あり・なし）

信頼関係が、その先のドメインにも波及するかどうかの性質です。

推移性あり

A が B を信頼し、B が C を信頼している場合、A と C も自動的に信頼関係が成立します。フォレスト内のドメインツリー間は、基本的にこの推移性を持ちます。

非推移性

信頼関係はその 2 つのドメイン間だけで有効で、その先には波及しません。外部の別フォレストと手動で信頼を結ぶ場合などは、セキュリティのため非推移性とすることが多いです。

Windows Server 2025 での AD DS 主要アップデート

Active Directory Domain Services は、機能レベルが Windows Server 2016 を最後に長らくアップデートされていませんでしたが、2024 年 11 月にリリースされた Windows Server 2025 で約 8 年ぶりに大幅な機能強化 が行われました。現場のエンジニアが押さえておきたい主要なアップデートを紹介します。

新しい機能レベル（DomainLevel 10 / ForestLevel 10）

Windows Server 2025 では、新しいドメイン・フォレスト機能レベル（内部バージョン 10）が導入されました。Server 2019 / 2022 では機能レベルが据え置きとなっていたため、これは Server 2016 以来のメジャーアップデートとなります。

参考: What’s new in Windows Server 2025（Microsoft Learn）
“The new functional level maps to the value of DomainLevel 10 and ForestLevel 10 for unattended installations.”
（新しい機能レベルは、無人インストール時の DomainLevel 10 および ForestLevel 10 に対応します）
https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025

新機能レベルの恩恵を受けるには、フォレスト内のすべての DC が Windows Server 2025 で稼働している必要があります。

32K データベースページサイズ（オプション機能）

AD DS のデータベースエンジン（ESE: Extensible Storage Engine）は、Windows 2000 の登場以来、長らく 8K ページサイズ を採用してきました。これにより、AD オブジェクト 1 件あたり 8K バイトを超えられないという制約が存在していました。

Windows Server 2025 では、新たに 32K ページサイズ がオプション機能として導入され、複数値属性が約 3,200 件まで格納可能になるなど、大規模環境でのスケーラビリティが大幅に向上しました。

ただし、有効化にあたっては以下の制約に注意が必要です。

• フォレスト内のすべての DC が Windows Server 2025 の新規インストール であること（インプレースアップグレードした DC では不可）
• フォレスト・ドメイン機能レベルが Windows Server 2025（レベル 10）であること
• PowerShell の Enable-ADOptionalFeature で明示的に有効化が必要
• 有効化後は元の 8K ページサイズに戻せない（不可逆）
• 既存のバックアップソフトが 32K ページ形式に対応しているかを事前検証する必要あり

delegated Managed Service Account（dMSA）

サービスアカウントは、長年「パスワードが古いまま放置される」「強度が不足している」といった問題を抱えてきました。Windows Server 2025 で導入された dMSA（delegated Managed Service Account） は、これらの問題を解消する新しいタイプのサービスアカウントです。

dMSA の主な特徴は以下のとおりです。

• 認証情報は Credential Guard によってマシンに紐付けられ、メモリから盗み出すことが困難
• パスワードは Kerberos の Key Distribution Center（KDC）によって自動でローテーション
• 既存のサービスアカウントから dMSA への移行をサポートし、移行後は元のサービスアカウントが自動的に無効化される

Kerberos の暗号化アルゴリズム強化

Windows Server 2025 の DC では、Kerberos の暗号化に関する以下の強化が行われています。

PKINIT の暗号アジリティ対応

ハードコードされていたアルゴリズムを排除し、より新しいアルゴリズムをサポート可能に。

DES（Data Encryption Standard）の完全削除

レガシーな弱い暗号化方式が削除されました。

RC4 TGT の発行停止

Server 2025 の DC は RC4 形式の TGT を発行しません。

レプリケーション優先度ブースト

これまで AD DS のレプリケーション順序はシステムが自動計算していましたが、Windows Server 2025 では管理者が 特定のレプリケーションパートナーや命名コンテキストに対して優先度を引き上げる ことが可能になりました。緊急性の高い変更を特定の DC に優先的に伝搬したい場面で有用です。

コンピューターアカウントの既定パスワード強化

Windows Server 2025 の DC では、コンピューターアカウントの既定パスワードが アカウント名そのもの（脆弱な既定値）に設定されることをブロック するようになりました。代わりに、ランダムに生成された強固なパスワードが既定で使用されます。

AD DS の制約事項と設計時の注意点

AD DS の設計・運用において、見落としやすい制約事項やハマりポイントを整理します。これらを事前に押さえておくことで、構築後の手戻りや障害を防止できます。

機能レベルの昇格は不可逆

ドメイン機能レベル・フォレスト機能レベルの昇格は、原則として 元のレベルに戻せません。古い OS バージョンの DC を将来的に追加する可能性がある場合は、機能レベルの昇格を慎重に判断することを推奨します。

なお、Windows Server 2025 では、Active Directory ごみ箱（AD Recycle Bin）が有効化されている場合に限り、フォレスト機能レベルを 1 段階下げる操作がサポートされる例外もあります。

32K データベースページサイズの有効化も不可逆

前述のとおり、Windows Server 2025 で導入された 32K ページサイズの有効化は 不可逆な操作 です。バックアップ・リストア戦略への影響も含めて、検証環境で十分に確認したうえで本番適用することを推奨します。

DC のマルチホーム構成は非推奨

ドメインコントローラーで 複数の NIC を持つ、または 1 つの NIC に複数の IP アドレスを割り当てる構成（マルチホーム構成） は、Microsoft によって非推奨とされています。

参考: ドメインコントローラーの構築時に言われないと気付かないこと（Microsoft Japan Windows Technology Support Blog）
“マルチホーム（複数の NIC もしくは 1 つの NIC に複数の IP アドレス）構成について、構成そのものについてサポートはしておりますが、弊社としては現在も（特別な要件がない限り）マルチホーム構成は非推奨となります。”
https://jpwinsup.github.io/blog/2023/10/23/ActiveDirectory/Authentication/design-consideration/

マルチホーム構成のまま運用した結果、レプリケーション失敗などのトラブルにつながるケースが報告されています。

LDAP / DNS のロードバランサー利用は非サポート

AD DS は クライアント側で負荷分散される設計 を前提としているため、LDAP・LDAPS・DNS などの通信前段にロードバランサーを配置する構成は、Microsoft の正式サポート対象外です。可用性を確保したい場合は、複数の DC を立て、クライアントが DC Locator プロセスで自動的に DC を選択する標準的な仕組みを利用する設計が推奨されます。

DNS 設定のベストプラクティス

ドメインコントローラーの DNS 設定では、以下のポイントを押さえておくことを推奨します。

• 自分自身のみを優先 DNS に指定すると、初期同期時に DNS アイランド 問題が発生する可能性がある
• 複数 DC 環境では、別の DC を優先 DNS に指定し、自分自身を代替 DNS に設定する構成が一般的
• Azure 上に DC を構築する場合は、OS 側 NIC を「動的」、Azure NIC または仮想ネットワーク側で「カスタム DNS」を指定する方式が推奨される

参考: ドメインネームシステム（DNS）クライアント設定の推奨事項（Microsoft Learn）
https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings

Windows Internal Database（WID）の非推奨

AD FS や AD RMS の構成データベースとして利用されてきた Windows Internal Database（WID） は、Windows Server 2025 で非推奨となり、将来のバージョンで削除される予定です。新規構築時は、SQL Server 版での構築を検討することを推奨します。

TLS 1.0 / 1.1 の既定無効化

Windows Server 2025 では、TLS 1.0 / 1.1 が既定で無効化 されています。AD と連携するレガシーアプリケーションが TLS 1.0 / 1.1 にのみ対応している場合、認証エラーが発生する可能性があるため、事前の互換性確認を推奨します。

AD DS のトラブルシューティングの基本

「ドメインに参加できない」「ログオンが遅い」「グループポリシーが適用されない」といったトラブルが発生したとき、最初に確認すべき基本的な切り分けポイントを紹介します。

確認①: DNS の SRV レコード

AD DS のトラブルの多くは DNS 起因です。クライアントは DC を見つけるために DNS の SRV レコードを参照するため、SRV レコードが正しく登録されているかをまず確認することを推奨します。

主要な SRV レコードの一覧

PowerShell での確認例

PS C:\> Resolve-DnsName -Type SRV -Name _ldap._tcp.dc._msdcs.example.com
PS C:\> Resolve-DnsName -Type SRV -Name _kerberos._tcp.dc._msdcs.example.com

確認②: DC への到達性（nltest）

クライアントがどの DC を参照しているか、また DC が応答しているかを確認するには、nltest コマンドが便利です。

C:\> nltest /dsgetdc:example.com
           DC: \\ad01.example.com
      Address: \\192.168.1.10
     Dom Guid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
     Dom Name: example.com
  Forest Name: example.com
 Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
        Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC ...

確認③: レプリケーション状態（repadmin）

複数 DC 環境では、レプリケーションの停滞がトラブルの原因となるケースがあります。repadmin /replsummary コマンドで、フォレスト全体のレプリケーション状態を一覧表示できます。

C:\> repadmin /replsummary

Source DSA          largest delta    fails/total %%  error
 AD01                   05m:23s        0 /   5    0
 AD02                   12m:10s        0 /   5    0

Destination DSA     largest delta    fails/total %%  error
 AD01                   05m:23s        0 /   5    0
 AD02                   12m:10s        0 /   5    0

fails/total のカラムでエラーが発生している場合、repadmin /showrepl でより詳細な情報を確認することを推奨します。

参考: グループポリシーの適用に関するトラブルシューティングのガイダンス（Microsoft Learn）
“タイムアウト問題を解決するには、nslookup ツールを使用して、_ldap._tcp.<domain-dns-name> レコードが登録されており、正しいサーバーを指していることを確認します。”
https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/group-policy/applying-group-policy-troubleshooting-guidance

確認④: Kerberos イベントログ（2026 年以降）

2026 年 1 月以降、RC4 暗号の非推奨化に伴い、Kerberos 関連の新しい監査イベントがドメインコントローラーに記録されるようになりました。RC4 関連の認証エラーをトラブルシューティングする際は、以下のイベント ID を確認することを推奨します。

GitHub の microsoft/Kerberos-Crypto リポジトリで公開されている List-AccountKeys.ps1 や Get-KerbEncryptionUsage.ps1 といった PowerShell スクリプトを使うと、環境内の RC4 依存アカウントを効率的に特定できます。

【コラム】Azure AD（Entra ID）との違い

最近よく聞く「Azure AD（現在は Microsoft Entra ID に名称変更）」と、本記事で解説した「Active Directory（AD DS）」は、名前は似ていますが 全くの別物 です。

「Entra ID は、クラウド上に作った AD サーバーのことではないか」というのは、よくある誤解の一つです。

プロトコルが違う

オンプレミスの AD DS は Kerberos や LDAP を使って、社内のサーバーや PC を厳密に管理することに特化しています。一方、Entra ID は HTTPS（Web の通信）ベースのプロトコル（OIDC、SAML など） を使い、インターネット上のクラウドサービス（Microsoft 365、Box、Salesforce など）への認証に最適化されています。

ハイブリッド構成が現在の主流

現在は、社内の PC 管理は AD DS で行い、Microsoft 365 などの利用には Entra ID を使う ハイブリッド構成（Microsoft Entra Connect Sync で同期） が一般的です。「どちらかを選ぶ」のではなく、「適材適所で両方使う」のが現代の ID 管理の主流と言えます。

【運用注意】Microsoft Entra Connect Sync のバージョンアップ期限
Microsoft は、Entra Connect Sync について 2026 年 9 月 30 日までにバージョン 2.5.79.0 以上へのアップグレード を必須としています。期限までに対応しない場合、すべての同期サービスが停止します。
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/harden-update-ad-fs-pingfederate

まとめ

本記事では、Active Directory の全体像と、中心となる AD DS の仕組み、および 2026 年時点での運用上の注意点について解説しました。

• 5 つのサービス: 主役は AD DS、その他は証明書・SSO・情報保護などの専門サービス。AD FS / AD RMS は Entra ID / Purview への移行が推奨される方向にある。
• 3 大要素: データベースの LDAP（TCP 389 / 636）、認証の Kerberos、場所特定の DNS
• 構造: ドメイン ＜ ツリー ＜ フォレスト という包含関係。OU でグループポリシーを柔軟に適用できる。
• 信頼関係: 方向（片方向・双方向）と推移性によってアクセス可否が決まる。
• Server 2025: 機能レベル 10、32K ページサイズ、dMSA など約 8 年ぶりの大型アップデート
• 2026 年の重要変更: RC4 暗号の非推奨化（4 月強制）、NTLMv1 削除済み、Entra Connect Sync の期限（9 月 30 日）
• トラブル時の基本確認: DNS SRV レコード → DC 到達性（nltest）→ レプリケーション（repadmin）の順で切り分ける。

以上、最後までお読みいただきありがとうございました。