大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第3回 クライアントとサーバーのドメイン参加

こんにちは！ 第2回では、ADの名前とドメイン コントローラー、DNSの構成を整理しました。今回は、PCやサーバーをそのドメインへ参加させる仕組みを見ていきます。

ユーザーのアカウントを作ることと、端末をドメインに参加させることは別の作業です。参加前の条件、実際の手順、参加後の確認をつなげて考えましょう。

対象はオンプレミスAD DSへの参加です。漫画は概念を説明する架空の会話であり、実際の障害事例や試験結果ではありません。

連載の構成

• 第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎
• 第2章：ドメイン環境の構築 - 検証環境の構築手順
• 【★今回です★】第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順
• 第4章：プロキシサーバーと統合Windows認証
• 第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法
• 第6章：トラブルシューティング - よくある問題と解決方法
• 第7章：セキュリティとベストプラクティス - 本番環境での考慮事項
• 第8章：実践的な構成例 - AIセキュリティツールとの統合事例

3.1 ドメイン参加の基本

3.1.1 Windowsへのログオンとサービスへの認証

Windowsへドメインユーザーとしてログオンするには、ユーザーだけでなくPC側の参加も必要です。

AD DSへの参加によって、端末をコンピューターアカウントとして登録し、ドメインとの通信に使う認証情報を構成します。ネットワークへ接続しただけで、この登録が済むわけではありません。

未参加のPCでも、サービス側の構成によってはドメインの資格情報を明示して認証できます。「ドメインに参加していない端末からの認証は、すべて拒否される」という説明は正しくありません。

反対に、参加済みのPCでも、どの利用者も無条件にログオンできるわけではありません。アカウントの無効化やログオン権限など、別の制御も働きます。

DCに接続できないときのキャッシュログオンは、そのPCへ入るための仕組みです。オンラインのサーバーへ接続できることや、新しいKerberosチケットを取得できることまで保証しません。

3.1.2 人と端末は別のアカウントで管理する

コンピューターアカウントは、端末自身を識別するためのものです。

ユーザーアカウントが人を表すのに対し、コンピューターアカウントはPCやメンバーサーバーを表します。たとえば端末名が PC-101 なら、コンピューターの sAMAccountName は通常 PC-101$ です。

管理ツールの表示名と、この属性の値は区別します。Active Directory ユーザーとコンピューターの一覧に、必ず末尾の $ が表示されるわけではありません。

コンピューターアカウントは、端末が安全であることを無条件に証明するものではありません。参加後も、更新、端末保護、アクセス制御をそれぞれ運用します。

3.1.3 ローカルの管理権限とADの権限を分ける

参加するPCを変更する権限と、ADのアカウントを作成・再利用する権限は別です。

通常のオンライン参加では、PC側で管理者として作業し、AD側では必要な参加権限を持つ資格情報を使います。Domain AdminsやAccount Operatorsへの所属を、作業担当者へ一律に配る必要はありません。

一般ユーザーでも、ドメインの設定によって参加が認められる場合があります。したがって「一般ユーザーは絶対に参加できない」ではなく、対象OUへの委任と、既存の参加権限・台数制限を確認します。

既存アカウントの再利用には、Windowsのドメイン参加強化による所有者の検査もあります。必要な権限と信頼条件を満たすよう構成し、失敗したからといって保護を無効化したり、アカウントを即座に削除したりしません。

3.2 ドメイン参加の手順

3.2.1 Windows PCを参加させる

参加前に、OSの対応、DNS、通信、時刻、権限を確認します。

Windows 11のProやEnterpriseなど、AD DSへの参加に対応したエディションを使います。Homeは対象外です。端末にはADの名前を解決できるDNSを設定し、DCへ必要な通信が届くようにします。

1. 1コンピューター名、参加先のDNSドメイン名、配置するOUを決める。既存の同名端末と重複しないことを確認する。
2. 2ローカルの管理者権限で「システムのプロパティ」の「コンピューター名」を開き、「変更」から「ドメイン」を選ぶ。
3. 3参加先の名前を入力し、必要なAD権限を持つ資格情報で認証する。
4. 4参加結果を確認して再起動する。ドメインユーザーでログオンし、所属と利用するサービスを確認する。

GUIの参加操作では配置先OUを直接指定しません。目的のOUに配置する場合は、事前にコンピューターアカウントを用意するか、参加後に適切な権限で移動します。PowerShellでは以下のように OUPath を指定できます。事前作成済みアカウントには、再利用の権限と所有者の検査が適用されます。

設定アプリから行う場合は、「職場または学校にアクセスする」の接続画面で、ローカルActive Directoryドメインへの参加を選びます。Microsoft Entraへの参加や職場アカウントの追加とは区別してください。

次は、管理者として開いたWindows PowerShell 5.1で使う例です。corp.example.com、端末名、OUは説明用で、OUは先に存在し、参加用アカウントへ必要な権限を委任してある前提です。

$joinParams = @{
    DomainName = 'corp.example.com'
    NewName = 'PC-101'
    OUPath = 'OU=Workstations,DC=corp,DC=example,DC=com'
    Credential = Get-Credential
    PassThru = $true
    Verbose = $true
}
Add-Computer @joinParams

この例は自動再起動を付けていません。処理が成功したことを確認し、保存していない作業を閉じてから再起動します。資格情報は対話入力し、スクリプトへパスワードを埋め込みません。

3.2.2 メンバーサーバーとDCへの昇格を区別する

Windows Serverをドメインへ参加させても、それだけでDCにはなりません。

ファイル、Web、データベースなどを提供するメンバーサーバーは、ドメインの一員として動きます。DCになるには、AD DSの役割の導入とDCへの昇格が別に必要です。

1. 1サーバーマネージャーで「ローカルサーバー」を開き、ワークグループまたはドメイン名のリンクを選ぶ。
2. 2「コンピューター名」の「変更」から参加先ドメインを指定する。
3. 3資格情報を入力し、結果を確認して再起動する。

参加の時期は、サービスアカウントやインストール先アプリの要件から決めます。「どのアプリも必ず参加前に入れてはいけない」という共通ルールではありません。

サーバーのIPアドレスや名前を安定して管理し、DNS登録、起動時の依存、再起動の影響も確認します。ドメイン参加の成功と、アプリが正しく認証できることは別に試します。

3.2.3 Linuxでは用途とIDの対応付けを先に決める

Linuxへのログイン統合と、SambaでのSMB共有提供を分けて設計します。

ログイン統合ではSSSDを使う方式などがあります。SambaのメンバーサーバーではWinbindを使い、ADのSIDをLinuxのUID/GIDへ対応付けます。

以下は単一ドメインを対象とするUbuntuのWinbind構成の例です。まずAD用DNSと時刻、ホスト名を確認し、必要なパッケージを用意します。

sudo apt update
sudo apt install samba winbind libnss-winbind libpam-winbind krb5-user

/etc/samba/smb.conf の [global] で、参加先とID変換方式を指定します。次の範囲は説明用で、既存のローカルUID/GIDや別ドメインと重ならず、運用に必要な広さがあるかを確認してから使います。

[global]
    security = ads
    realm = CORP.EXAMPLE.COM
    workgroup = CORP
    idmap config * : backend = tdb
    idmap config * : range = 100000-199999
    idmap config CORP : backend = rid
    idmap config CORP : range = 1000000-1999999
    winbind use default domain = no
    winbind enum users = no
    winbind enum groups = no
    winbind refresh tickets = yes
    kerberos method = secrets and keytab

設定を保存したら、構文、参加、信頼関係、利用者の名前解決を順に確認します。join_domain と user は、それぞれ必要な権限を持つ参加用アカウントと、既存の検証用ユーザーに置き換えます。

testparm -s
sudo net ads join -U 'CORP\join_domain'
sudo systemctl restart winbind
sudo net ads testjoin
sudo wbinfo -t
id 'CORP\user'

SMB共有には、共有の定義とファイルの権限も必要です。id がユーザーを見つけたことだけでは、共有やSSHへログインできることの証明にはなりません。

OSへのログインも許可する場合は、NSS/PAM、ログインシェル、ホームディレクトリ、許可するユーザーやグループを確認します。Ubuntu 24.04 LTS以降と旧版ではNSS設定の自動化にも違いがあるため、既存の passwd・group 行を丸ごと置き換えず確認してください。

ID変換方式や範囲を運用途中で変えると、保存済みファイルの所有者との対応に影響します。複数ドメインや複数Linux機で使う場合は、最初に一貫した対応付けを設計します。

3.2.4 エラーは名前解決・通信・権限の順に絞る

メッセージだけで原因を断定せず、参加処理のログを一緒に読みます。

Windowsの参加ログは %windir%\debug\NetSetup.log にあります。失敗した時刻、エラーコード、接続先DCを控え、DNS、通信、資格情報、既存アカウントの再利用を順に確認します。

ipconfig /all
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com
nltest /dsgetdc:corp.example.com
Test-NetConnection -ComputerName dc01.corp.example.com -Port 445
w32tm /query /status
w32tm /stripchart /computer:dc01.corp.example.com /samples:5 /dataonly

TCP 445だけが通っても、参加に必要な通信がすべて通ったとはいえません。UDPや動的RPCポートも含め、Microsoftの要件と対象OSの構成を照合します。pingの応答がないことだけでも、AD通信の可否は決まりません。

同名アカウントがある場合は、実際に使われている端末か、再利用すべきアカウントかを確認します。安全上の検査で再利用が拒否された場合も、アカウントを消す前に所有者と委任を調べます。

3.3 参加後の信頼関係とポリシー

3.3.1 セキュアチャネルを確認する

端末とADの機械アカウント情報が一致していることが、信頼関係の土台です。

Netlogonのセキュアチャネルは、ドメインメンバーとDCの認証された通信に使われます。これは、端末のすべての通信を暗号化するVPNという意味ではありません。

メンバーPCやメンバーサーバーでは、管理者として開いたWindows PowerShellで次の確認を行えます。DC自身にこのコマンドを使うと誤ったエラーになることがあるため、対象を区別します。

Test-ComputerSecureChannel -Verbose

True は、テストしたセキュアチャネルが正常だったことを示します。False の場合は、まずDNSや接続、アカウントの状態を確認し、復元や同名端末による秘密情報の不一致がないか調べます。

通信が正常で、修復が必要だと判断できたメンバー端末では、必要な権限を持つ資格情報を指定して修復を試せます。処理後は再テストし、ユーザーのログオンやサービス利用も確認します。

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
Test-ComputerSecureChannel -Verbose

再参加は、原因と影響を確認したうえで選ぶ対応の一つです。最初からワークグループへ戻す手順だけを案内すると、復旧に使うローカルアカウントやアプリへの影響を見落とします。

3.3.2 機械アカウントのパスワードは端末が更新する

通常、機械アカウントのパスワードを人が定期的に入力し直す必要はありません。

Windowsのドメインメンバーは、既定では30日ごとに変更を要求します。これは端末側の更新間隔であり、人のパスワードの期限と同じ意味で扱うものではありません。

信頼関係の障害では、復元によって片側の情報が古くなった場合や、ADの複製の問題などを確認します。長く停止していたという事実だけで、パスワードの不一致が原因だとは断定しません。

通常の運用で自動変更を無効にすることは避けます。仮想マシンの複製や復元も、同じコンピューターアカウントを複数の実体で使い回さない手順にします。

現在の値を調べる場合、次の読み取りコマンドでNetlogonの設定を確認できます。値が明示されていない場合もあるため、適用されたポリシーと既定値を合わせて読みます。

reg query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3.3.3 GPOの対象と適用結果を確かめる

GPOは、作成しただけで全PCへ届くものではありません。

サイト、ドメイン、OUへのリンクと、セキュリティフィルターやWMIフィルターなどで適用対象が決まります。基本の処理順はローカル、サイト、ドメイン、親OUから子OUですが、強制や継承のブロックなども考慮します。

更新と結果確認は別の操作です。次は更新を要求してから、適用されたGPOの要約と、現在のユーザーの一時フォルダーへのHTMLレポートを出す例です。

gpupdate /force
gpresult /r
$reportPath = Join-Path $env:TEMP ("gpreport-{0}.html" -f (Get-Date -Format "yyyyMMdd-HHmmss"))
gpresult /h $reportPath

コンピューター側の情報を見る場合は、必要な管理者権限で実行します。レポートの対象ユーザーも確認し、別の管理者として起動した結果を、利用者本人の結果と取り違えないようにします。

反映されない場合は、対象OU、リンク、フィルター、DC間の複製、処理に必要な再ログオンや再起動を確認します。イベントビューアーの Microsoft-Windows-GroupPolicy/Operational も調べます。

まとめ

ドメイン参加では、人のアカウントと端末のアカウント、ローカルの管理権限とADの権限を分けて考えます。参加後も、ログオン、セキュアチャネル、必要なサービス、GPOの適用結果まで確認しましょう。

Linuxでは用途とIDの対応付けを先に決めます。障害時には、架空の成功ログに当てはめず、自分の端末で得たログと名前解決・通信の結果から原因を絞ることが大切です。

次回予告

第4回では、プロキシサーバーと統合Windows認証を扱います。ADへの参加が、ブラウザやアプリの認証とどのようにつながるかを見ていきます。

それでは、また次回、お会いしましょう！