【第2回】Windows Server 2025におけるADDS構築とLinuxからのLDAP/Kerberos連携完全ガイド

前回の第1回では、M365ハイブリッド認証アーキテクチャの全体像と、LVSを用いたADFS/WAPの超高可用性負荷分散について解説しました。ゼロトラスト時代において、すべての認証の源泉（Source of Truth）となるディレクトリサービスの重要性は増すばかりです。

連載第2回となる今回は、認証基盤のコアとなる「ADDS（Active Directory Domain Services）」を、最新のWindows Server 2025 Standardを用いて構築する手順を、インフラエンジニアの視点からIaC（Infrastructure as Code）を意識したPowerShellベースで解説します。さらに、構築したADDSに対して、普段我々が運用しているLinuxサーバー（Ubuntu/RHEL）からLDAPおよびKerberosプロトコルを用いてセキュアに連携（ドメイン参加）させる、現場で必須となるエンタープライズ実装手法を深く掘り下げていきます。

---

1. ADDS（Active Directory）の役割とWindows Server 2025の進化

Active Directory Domain Services (ADDS) は、単なるユーザーアカウントのデータベースではありません。DNS（ドメインネームシステム）と密接に統合され、ネットワーク上のすべてのオブジェクト（ユーザー、グループ、コンピューター、ポリシー）を階層的に管理する、エンタープライズITの「心臓部」です。後段で構築するADFS（フェデレーションサーバー）も、Entra ID Connectも、すべてはこのADDSのデータベース（NTDS.DIT）を正として動作します。

Windows Server 2025におけるセキュリティ強化とレガシーの排除

我々LinuxエンジニアがWindows Server 2025でADDSを扱う際、最も注意すべきなのは「レガシープロトコルの徹底的な排除」です。これまでのOSアップグレードとは異なり、2025ではゼロトラストアーキテクチャを見据えた強固なデフォルト設定が適用されています。

• TLS 1.3のデフォルト化： LDAPS（LDAP over SSL）通信において、TLS 1.3がデフォルトで有効化されています。古いLinuxディストリビューション（OpenSSL 1.1.0以前）からの連携ではハンドシェイクエラーが発生する可能性があります。
• RC4およびDESの完全排除： Kerberos認証における古い暗号化スイート（RC4-HMAC等）がデフォルトで無効化されています。現在サポートされるのはAES128およびAES256のみです。Linux側の krb5.conf の設定に注意が必要です。
• NTLMの非推奨化： 長年使われてきたNTLM認証が公式に非推奨となりました。今後はKerberos認証への完全移行が求められます。

2. PowerShellを用いたADDSドメインコントローラー構築手順

サーバーマネージャーのGUIから構築することも可能ですが、手順の再現性（IaC）や構成管理を考慮すると、プロの現場では必ずPowerShellを使用します。以下は、Windows Server 2025に新規フォレスト（ドメイン名：linuxkoubou.local）を構築するための完全なスクリプトです。

前提条件の設定（IPアドレスとホスト名）

ADDSはDNSに強く依存するため、固定IPアドレスの設定と、自身をプライマリDNSサーバーとして参照する設定が不可欠です。管理者権限のPowerShellで実行します。

# 1. コンピューター名の変更
Rename-Computer -NewName "DC01" -Force -Restart

# (再起動後)
# 2. 固定IPアドレスとDNS設定 (インターフェース名は環境に合わせて変更 'Ethernet' など)
$netAdapter = Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetIPAddress -InterfaceAlias $netAdapter.Name -IPAddress 10.0.10.11 -PrefixLength 24 -DefaultGateway 10.0.10.254
Set-DnsClientServerAddress -InterfaceAlias $netAdapter.Name -ServerAddresses ("10.0.10.11", "127.0.0.1")

ADDSロールのインストールとフォレストの構築

必要な役割（Role）をインストールし、その後ドメインコントローラー（DC）に昇格させます。

# 3. ADDSとDNSサーバーの役割、および管理ツールをインストール
Install-WindowsFeature -Name AD-Domain-Services, DNS -IncludeManagementTools

# 4. 新規フォレストの構築（DC昇格）
# SafeModeAdministratorPassword はディレクトリサービス復元モード (DSRM) 用のパスワードです。
$password = ConvertTo-SecureString "StrongP@ssw0rd!" -AsPlainText -Force
Install-ADDSForest `
    -CreateDnsDelegation:$false `
    -DatabasePath "C:\Windows\NTDS" `
    -DomainMode "WinThreshold" `
    -DomainName "linuxkoubou.local" `
    -DomainNetbiosName "LINUXKOUBOU" `
    -ForestMode "WinThreshold" `
    -InstallDns:$true `
    -LogPath "C:\Windows\NTDS" `
    -NoRebootOnCompletion:$false `
    -SysvolPath "C:\Windows\SYSVOL" `
    -SafeModeAdministratorPassword $password `
    -Force:$true

コマンド実行後、サーバーが自動的に再起動され、ドメインコントローラーとしての動作が開始されます。これで、M365ハイブリッド認証のベースとなるIdPの土台が完成しました。

3. Linuxエンジニアが理解すべきLDAPとKerberosの仕組み

Windows側でADが立ち上がったら、次はLinuxからの連携です。しかし、いきなりコマンドを叩く前に、LinuxエンジニアとしてADが喋る2つのコアプロトコルをネットワークレベルで理解しておく必要があります。この理解がないと、障害時のトラブルシューティングができません。

LDAP (Lightweight Directory Access Protocol) – TCP 389 / 636

LDAPは「ディレクトリ（名簿）を検索・更新するためのプロトコル」です。ADDS内では、ユーザーやグループがツリー構造で格納されています。
LinuxからADにユーザー情報を問い合わせる際、以下のような「識別名 (DN: Distinguished Name)」を使用します。

• ベースDN (Base DN): 検索の起点。DC=linuxkoubou,DC=local
• ユーザーDN: 特定のユーザー。CN=kou-kun,OU=Engineers,DC=linuxkoubou,DC=local

LDAPの標準ポートはTCP 389（平文）ですが、パスワード情報を扱うため、エンタープライズ環境では必ずTLSで暗号化されたLDAPS（TCP 636）を使用する設計にすべきです。

Kerberos – TCP/UDP 88

Kerberosは「ネットワーク認証プロトコル」であり、「チケット」という概念を用いてSSO（シングルサインオン）を実現します。ADDS（ドメインコントローラー）は、Kerberosプロトコルにおいて「KDC (Key Distribution Center)」の役割を果たします。

1. LinuxクライアントはKDC(AD)に対して認証を要求し、成功するとTGT (Ticket Granting Ticket：チケット発行チケット) を取得します。
2. 次に特定のサービス（例えばファイルサーバーやADFS）にアクセスしたい場合、TGTを提示してTGS (Ticket Granting Service) チケットを取得します。
3. 取得したTGSチケットを使って、目的のサービスにアクセスします。

重要なのは、Kerberos認証はパスワードをネットワーク上に一切流さないという点です。また、「時刻同期」が極めて厳格であり、ADDSとLinuxクライアント間で時刻が「5分以上」ずれていると、リプレイ攻撃と見なされ認証が即座に拒否されます（Clock Skew Error）。

4. Linux（Ubuntu/RHEL）からADDSへのセキュアな参加と連携

ここからがいよいよLinuxエンジニアの腕の見せ所です。かつては winbind や nslcd を複雑に設定していましたが、現在では realmd と SSSD (System Security Services Daemon) の組み合わせがデファクトスタンダードです。

以下の手順は、Ubuntu 22.04 LTS または RHEL 9 (AlmaLinux 9等) を前提としています。

ステップ1：必須パッケージのインストールと名前解決

まず、連携に必要なパッケージ群をインストールします。また、ADDSのDNS機能を利用できるよう、Linux側の参照DNS（resolv.conf等）をADのIPアドレス（10.0.10.11）に向けます。

# Ubuntu系の場合
sudo apt update
sudo apt install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin krb5-user

# RHEL系 (AlmaLinux/RockyLinux) の場合
sudo dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools krb5-workstation

ステップ2：ドメインのディスカバリと参加 (Realm Join)

realmd を使用すると、DNSのSRVレコード（_ldap._tcp.dc._msdcs.linuxkoubou.local）を自動で検索し、必要な設定（sssd.conf, krb5.conf, PAM設定など）を全て自動生成してくれます。

# 1. ドメインの検出テスト
realm discover linuxkoubou.local

# 2. ドメインへの参加（ADのドメイン管理者権限が必要です）
sudo realm join --user=Administrator linuxkoubou.local

パスワードを入力し、プロンプトが戻ってくれば参加完了です。これでAD側にLinuxマシンのコンピューターオブジェクトが自動生成されています。

ステップ3：SSSDのプロフェッショナルなチューニング

realm join が自動生成した /etc/sssd/sssd.conf は動きますが、エンタープライズの現場ではこれだけでは不十分です。M365認証のバックエンドとして動作させるため、パフォーマンスと使い勝手を向上させるチューニングを行います。

# /etc/sssd/sssd.conf の編集
[sssd]
domains = linuxkoubou.local
config_file_version = 2
services = nss, pam

[domain/linuxkoubou.local]
ad_domain = linuxkoubou.local
krb5_realm = LINUXKOUBOU.LOCAL
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True

# --- プロの追加チューニング ---
# 1. ドメイン名を省略してログイン可能にする（user@linuxkoubou.local ではなく user でOK）
use_fully_qualified_names = False

# 2. AD側のホームディレクトリ属性を無視し、Linuxのローカルに作成する
fallback_homedir = /home/%u

# 3. LDAPのタイムアウトと検索制限の最適化（巨大なADツリーでの遅延防止）
ldap_search_timeout = 15
ldap_network_timeout = 10

# 4. (必須) ADのユーザー一覧取得（getent passwd）を無効化し、負荷を抑える
enumerate = False

設定を保存後、権限を厳格にし、サービスを再起動します。

sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl restart sssd
sudo systemctl enable sssd

これで、id kou-kun や getent passwd kou-kun コマンドを叩くことで、LinuxからAD上のユーザー情報を透過的に引けるようになります。SSHログインもADのパスワードで可能です。

5. よくある連携トラブルとパケットレベルの切り分け手法

ADDSとLinuxの連携において、障害の9割は以下の3つのどれかに起因します。プロのエンジニアが現場で行う切り分けコマンドを紹介します。

1. DNSのSRVレコード解決失敗

realm discover が失敗する場合、Linux側がADの「どこにLDAP/Kerberosサービスがあるか」をDNSから引けていないことが原因です。AD環境では、特殊なSRVレコードを使用します。dig コマンドでADのKDCが正しく引けるか確認します。

# DNS SRVレコードの確認 (KDC)
dig -t SRV _kerberos._tcp.linuxkoubou.local

# DNS SRVレコードの確認 (LDAP)
dig -t SRV _ldap._tcp.linuxkoubou.local

ここで ANSWER SECTION に ADDSサーバー（DC01.linuxkoubou.local）が返ってこない場合、Linuxの参照DNS（/etc/resolv.conf や systemd-resolved）の設定ミスです。

2. 時刻同期（NTP）のズレによるKerberos認証拒否

前述の通り、Kerberosは5分以上の時刻ズレを許容しません。参加時に「Clock skew too great」というエラーが出た場合は、Linuxの chronyd または systemd-timesyncd の同期先（NTPサーバー）を、ADDSドメインコントローラー自身に向けるのがベストプラクティスです。

# /etc/chrony/chrony.conf (Ubuntuの場合)
# ADDSをNTPサーバーとして指定
server 10.0.10.11 iburst

3. Kerberosの暗号化スイート不一致

Windows Server 2025の強固なセキュリティにより、古い暗号化方式（RC4）が拒否されることがあります。Linux側で kinit コマンドを用いて、手動でKerberosチケット（TGT）を取得するテストを行います。エラーが出る場合、/etc/krb5.conf の暗号化設定を疑います。

# 手動でKerberos TGTを取得するテスト
kinit Administrator@LINUXKOUBOU.LOCAL
# （パスワード入力）

# 取得したチケットの確認（暗号化方式が aes256-cts-hmac-sha1-96 などになっているか確認）
klist

どうしても通信の問題が解決しない場合は、Linuxの伝家の宝刀 tcpdump でパケットを覗き見ます。Kerberos（ポート88）とLDAP（ポート389）の通信フローをキャプチャし、Wiresharkで解析することで、TLSハンドシェイクの失敗やTCPリセット（RST）の有無を一発で特定できます。

# KerberosとLDAPのトラフィックをキャプチャしてファイルに出力
sudo tcpdump -n -i eth0 port 88 or port 389 -w ad_auth_trouble.pcap

6. 第2回の総まとめと次回予告

本記事では、M365認証の根幹となる「ADDS」の構築と、Linuxからのシームレスな統合について解説しました。

• Windows Server 2025の要件： NTLMの非推奨化やRC4の排除など、モダンな暗号化要件（TLS 1.3 / AES）に合わせた構成が必要。
• IaCの活用： GUIではなく、PowerShellスクリプトを用いて再現性のあるドメインコントローラー構築を行う。
• Linuxからの統合（SSSD）： realmd と SSSD を利用することで、LinuxサーバーからADDSのLDAP/Kerberosに対して、あたかもローカルユーザーであるかのようにセキュアに認証を統合できる。
• トラブルシューティングの基本： DNS（SRVレコード）、NTP（時刻同期）、Kerberosパケット（tcpdump）の3点が、異種OS間の認証連携を制する鍵となる。

これで、M365ハイブリッド認証の「アイデンティティの源泉（ADDS）」と、その周辺のインフラ環境が整いました。
次回の【第3回】では、このADDSとクラウド（Entra ID）をフェデレーション（信頼関係）で結びつけるための最重要コンポーネント、ADFS（Active Directory Federation Services）とWAP（Web Application Proxy）の構築設計に踏み込みます。WIDとSQL Serverの使い分けなど、エンタープライズ特有のベストプラクティスを解説しますので、お見逃しなく！