大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第1回 基本概念の理解
こんにちは！
今回から数回にわたり Active Directory について解説してまいります。
Active Directory（AD:アクティブディレクトリー）は、Microsoft が開発したディレクトリサービスであり、今日の大企業における IT インフラストラクチャーにおいて、もはやデファクトスタンダードと言っても過言ではない存在となっており、組織内のユーザー、コンピューター、その他のリソースを一元的に管理するための基盤として広く採用されています。
AIセキュリティの現実：単独では機能しない
ChatGPTやClaudeなどの生成AIが企業に急速に普及する中、「AIセキュリティ」という言葉が注目を集めています。情報漏洩の防止、不適切な利用の検知、コンプライアンスの確保など、企業が取り組むべき課題は山積みです。
しかし、ここで注意しなければいけない事実があります。それは、
AIセキュリティソリューションは、それ単体では企業環境で限定的な効果しか期待できない
ということです。
企業が直面する本質的な課題
AIセキュリティツールを導入する際、企業のIT部門から必ず問われる質問があります
- 「誰がこのAIを使ったのか、どうやって特定すればいいのか？」
- 「部署ごとに異なるセキュリティポリシーを適用できるか？」
- 「既存の監査ログシステムと統合できるか？」
- 「ユーザーに余計な認証負担をかけずに済むか？」
これらの要求に応えるには、企業がもつ既存のIT基盤との深い統合が不可欠です。
本記事が前提とする社内環境
今回は、
企業の標準業務PCがWindowsであり、さらにドメインコントロールされている一般的なエンタープライズ環境
を想定してこれらの疑問にこたえていきたいとおもいます。
多くの大企業では従業員が業務使用するPCはWindowsベース、さらにPCはセキュリティ要件（ポリシー）が中央管理されているのではないでしょうか。
こういった環境の場合、AIセキュリティソリューションは認証・認可の中核を担うActive Directory（AD）との連携は避けて通れません。
プロキシ認証が架け橋となる理由
古典的なDLPソリューションもふくめ、多くのAIセキュリティソリューションは、プロキシサーバーとして動作し、ユーザーとAIサービス間の通信を仲介します。この時、以下の流れで既存基盤との統合が実現されます
- 透過的な認証
統合 Windows 認証により、ユーザーは意識することなく認証される - ユーザー特定
ADから取得した情報で「誰が」を明確に記録 - ポリシー適用
ADのグループ情報に基づいて、適切なセキュリティルールを適用 - 監査証跡
企業のコンプライアンス要件を満たす詳細なログを生成
技術者に求められる知識の融合
AIセキュリティエンジニアには、AI技術の知識だけでなく、以下の基盤技術への深い理解が求められます
- Active Directory: 企業認証の仕組み、Kerberos/NTLM認証プロトコル
- プロキシ技術: HTTP認証、SSPIなどのWindows認証API
- ネットワーク: ドメイン環境でのルーティング、名前解決
- セキュリティ: 認証トークンの扱い、監査ログの設計
本連載の目的
本連載では、大企業のAIセキュリティを支える基盤技術について、実践的な知識を体系的に解説します。単なる理論ではなく、実際の企業環境で直面する課題と、その解決方法を具体的に示していきます。
AIセキュリティという新しい分野においても、結局は堅実な基盤技術の上に成り立つという原則は変わりません。この連載を通じて、AIセキュリティと既存IT基盤の統合方法について理解が深まれば幸いです。なお本シリーズでは、初心者にもわかりやすく Active Directory について理解できるよう、随所にロールプレイ方式の掛け合いをいれて楽しく学べるように工夫していますので、最後までおつきあいいただけますと幸いです！
連載の構成
【★今回です★】第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎
第2章：ドメイン環境の構築 - 検証環境の構築手順
第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順
第4章：プロキシサーバーと統合Windows認証
第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法
第6章：トラブルシューティング - よくある問題と解決方法
第7章：セキュリティとベストプラクティス - 本番環境での考慮事項
第8章：実践的な構成例 - AIセキュリティツールとの統合事例
第1章：基本概念の理解
1.1 Active Directory（AD）とは
1.1.1 ADの役割と機能
Active Directory（アクティブディレクトリ）は、Microsoft社が開発した、Windows環境における統合的な管理システムです。企業や組織において、コンピューターやユーザー、その他のリソースを一元的に管理するための仕組みとして広く利用されています。
ADを理解する最も簡単な方法は、会社の組織管理に例えることです。まず、ADがない世界を想像してみましょう。
【ADがない会社の朝】
田中：「おはようございます。経理システムにログインしたいんですが...」
IT担当：「あ、田中さんですね。えーっと、経理システムの田中さんのパスワードは...（紙をめくる）」
田中：「それから、ファイルサーバーにもアクセスしたいんですが」
IT担当：「ファイルサーバーは別のパスワードなんです。メモしますね...」
田中：「メールも使いたいんですが」
IT担当：「それも別で...（汗）」
このような状況では、システムごとに別々のID・パスワードが必要で、管理が煩雑になります。ADは、この問題を解決するために生まれました。
【ADがある会社の朝】
田中：「おはようございます」（PCにログイン）
PC：「ADさん、田中太郎さんがログインしようとしています」
AD：「確認しました。田中太郎さんは経理部の正社員ですね。認証OK」
PC：「ありがとうございます。田中さん、どうぞお使いください」
田中：（経理システム、ファイルサーバー、メール、すべて追加ログインなしで使える）
ADの主要な役割は、認証と承認です。認証とは「あなたは誰ですか？」という問いに答えることで、承認とは「あなたは何ができますか？」という問いに答えることです。
【認証と承認の違い】
田中：「経理部の共有フォルダを開きたい」
AD（認証）：「パスワードを確認...はい、あなたは確かに田中太郎さんですね」
AD（承認）：「田中太郎さんは経理部所属...経理部フォルダへのアクセスOKです」
山田：「経理部の共有フォルダを開きたい」
AD（認証）：「パスワードを確認...はい、あなたは確かに山田次郎さんですね」
AD（承認）：「山田次郎さんは営業部所属...申し訳ありませんが、経理部フォルダへのアクセス権限がありません」
ADが提供する機能は多岐にわたります。最も重要な機能の一つが、シングルサインオン（SSO）です。これは、一度ログインすれば、ネットワーク内の様々なリソースにアクセスする際に再度パスワードを入力する必要がないという機能です。
また、グループポリシー機能により、管理者は組織内のすべてのコンピューターに対して、統一的な設定を適用できます。
【グループポリシーの威力】
IT管理者：「全社員のPCで、10分間操作がなければ自動的にロックするように設定したい」
（ADなしの場合）
IT管理者：「1台目...設定完了。2台目...設定完了。3台目...（500台もあるのか...）」
（ADありの場合）
IT管理者：「ADのグループポリシーで設定...はい、完了」
AD：「了解しました。全500台に設定を配信します」
1.1.2 ADが管理するもの（ユーザー、コンピューター、グループ）
ADは、組織内の様々な要素を「オブジェクト」として管理します。これは、現実世界の会社組織をデジタルの世界に再現したようなものです。
まず、ユーザーオブジェクトについて見てみましょう。
【新入社員の入社日】
人事部：「4月1日付けで、山田花子さんが経理部に配属されます」
IT管理者：「分かりました。ADにユーザーを作成しますね」
IT管理者の作業：
- ログイン名：yamada_h
- 氏名：山田花子
- 所属：経理部
- メールアドレス：yamada_h@jp.qualiteg.com
- 初期パスワード：（設定）
山田：「初出社です。PCはどれを使えばいいですか？」
IT管理者：「どのPCでも大丈夫です。yamada_hでログインしてください」
山田：「え、どのPCでも？」
IT管理者：「はい、ADが山田さんの情報を管理しているので、会社のどのPCからでもログインできます」
次に、多くの人が誤解しやすいコンピューターオブジェクトについて説明します。ADは人だけでなく、コンピューター自体も管理対象として扱います。
【新しいPCが届いた日】
IT担当：「新しいPC が届きました。これをADに参加させないと...」
新人：「PCも参加が必要なんですか？人じゃないのに？」
IT担当：「そうなんです。こう考えてください」
（PCがADに参加していない場合）
山田：「このPCにログインしたい」
PC：「あなたは誰？私はADなんて知らないよ」
山田：「ADのyamada_hです」
PC：「AD？何それ？知らない人はログインさせません」
（PCがADに参加している場合）
山田：「このPCにログインしたい」
PC：「ちょっと待って、ADに確認しますね」
PC→AD：「yamada_hという人がログインしようとしています」
AD→PC：「確認しました。経理部の山田花子さんです。ログインOK」
PC：「どうぞお使いください」
グループオブジェクトは、ユーザーやコンピューターをまとめて管理するための仕組みです。
【グループ管理の効率性】
社長：「経理部全員が使える共有フォルダを作ってください」
（グループなしの場合）
IT管理者：「田中さんにアクセス権...山田さんにアクセス権...鈴木さんにアクセス権...」
翌日
人事：「経理部に新人の佐藤さんが配属されました」
IT管理者：「また個別に設定か...」
（グループありの場合）
IT管理者：「『経理部』グループにアクセス権を設定...完了」
翌日
人事：「経理部に新人の佐藤さんが配属されました」
IT管理者：「佐藤さんを『経理部』グループに追加...はい、完了。自動的に共有フォルダにアクセスできます」
これらのオブジェクトは階層構造で管理され、組織単位（OU：Organizational Unit）という容器に整理されます。
1.1.3 ドメインコントローラー（DC）の概念
ドメインコントローラー（DC）は、Active Directoryの中核となるサーバーです。DCを理解するには、会社の受付や守衛さんに例えると分かりやすいでしょう。
【DCの役割を受付に例えると】
（朝の出社時間）
田中：「おはようございます」（社員証をかざす）
DC（受付）：「社員証を確認...田中太郎さん、経理部の方ですね。どうぞお入りください」
山田：「おはようございます」（社員証をかざす）
DC（受付）：「社員証を確認...山田次郎さん、営業部の方ですね。どうぞお入りください」
見知らぬ人：「入れてください」
DC（受付）：「社員証を見せてください」
見知らぬ人：「持ってません」
DC（受付）：「申し訳ございませんが、入館できません」
実際のDCは、このような認証作業を1秒間に何百回も行います。そして、すべての社員（ユーザー）と、すべての会社のPC（コンピューター）の情報を記憶しています。
【DCのデータベース】
DC：「私のデータベースには以下の情報があります」
- 田中太郎：経理部、内線1234、メール tanaka@jp.qualiteg.com
- 山田次郎：営業部、内線5678、メール yamada@jp.qualiteg.com
- PC-001：経理部フロアのPC、田中さんがよく使う
- PC-002：営業部フロアのPC、山田さんがよく使う
...（以下、全社員と全PCの情報）
組織の規模に応じて、DCは1台から数十台まで配置されます。
【小規模オフィス（社員50名）】
社長：「うちは小さい会社だから、受付は1人で十分だよね」
IT管理者：「はい、DC も1台で十分です」
【大規模オフィス（社員5000名）】
社長：「これだけ社員がいると、受付1人じゃ大変だ」
IT管理者：「おっしゃる通りです。DCも複数台用意して、負荷を分散させます」
IT管理者：「東京本社にDC を2台、大阪支社に2台配置しましょう」
（実際の動作）
東京の田中：「ログインします」
東京DC1：「私が担当します。認証OK」
大阪の鈴木：「ログインします」
大阪DC1：「私が担当します。認証OK」
東京DC1：「ちょっと忙しいな...」
東京の佐藤：「ログインします」
東京DC2：「DC1が忙しそうなので、私が担当します。認証OK」
重要なのは、すべてのDCが同じ情報を共有していることです。これをレプリケーション（複製）と呼びます。
【DCのレプリケーション】
東京DC1：「新しいユーザー『新入社員A』を登録しました」
東京DC1→全DC：「みんな、この情報をコピーしてください」
東京DC2：「コピーしました」
大阪DC1：「コピーしました」
大阪DC2：「コピーしました」
結果：どのDCに聞いても、新入社員Aの情報が得られる
このように、ドメインコントローラーは24時間365日、組織のすべての認証を管理する、まさに組織の守護神のような存在なのです。
1.2 DNSとADの関係
1.2.1 なぜADにDNSが必須なのか
Active DirectoryとDNS（Domain Name System）の関係は、多くの初心者が混乱するポイントです。なぜADを使うのにDNSが必要なのでしょうか。これを理解するために、まず日常生活の例から始めましょう。
【電話をかけるとき】
太郎：「花子さんに電話したいな」
太郎：「でも電話番号知らない...」
太郎：「電話帳で調べよう。花子さんは...090-1234-5678か」
太郎：「もしもし、花子さん？」
【電話帳がなかったら】
太郎：「花子さんに電話したいけど、番号が分からない」
太郎：「どうしよう...電話できない」
DNSは、コンピューターネットワークにおける「電話帳」の役割を果たします。人間にとって覚えやすい名前（花子さん）を、コンピューターが理解できる番号（電話番号）に変換してくれるのです。
では、ADとDNSの関係を見てみましょう。
【PCがドメインにログインしようとするとき】
ユーザー：「jp.qualiteg.comドメインにログインしたい」
PC：「jp.qualiteg.comのドメインコントローラーはどこだろう？」
PC：「DNSに聞いてみよう」
PC→DNS：「jp.qualiteg.comのドメインコントローラーはどこですか？」
DNS：「それなら、192.168.1.10にいますよ」
PC：「ありがとう！」
PC→DC（192.168.1.10）：「ログインさせてください」
もしDNSがなかったら、どうなるでしょうか。
【DNSがない場合】
ユーザー：「jp.qualiteg.comドメインにログインしたい」
PC：「jp.qualiteg.com？それどこ？IPアドレスは？」
ユーザー：「知らない...」
PC：「IPアドレスが分からないと接続できません」
ユーザー：「じゃあ、ドメインコントローラーのIPアドレスを覚えておくよ。192.168.1.10」
PC：「それならOK」
翌日
IT管理者：「DCのIPアドレスを変更しました。新しいIPは192.168.1.20です」
ユーザー：「えっ！また覚え直し？」
このように、DNSがないと、すべてのユーザーがドメインコントローラーのIPアドレスを覚えておく必要があり、IPアドレスが変更されるたびに大混乱が起きてしまいます。
さらに重要なのは、ADは単純な名前解決以上の機能をDNSに要求することです。
【ADの高度な要求】
PC：「ログインしたいんだけど、最寄りのDCはどれ？」
DNS：「あなたは東京オフィスにいますね。東京DC1（192.168.1.10）か東京DC2（192.168.1.11）を使ってください」
別のPC：「大阪オフィスからログインしたい」
DNS：「それなら大阪DC1（192.168.2.10）か大阪DC2（192.168.2.11）が近いですよ」
1.2.2 AD統合DNSとは
AD統合DNSは、Active DirectoryとDNSを密接に連携させる仕組みです。これは、受付（DC）と案内係（DNS）が同じ情報を共有している状態と考えると分かりやすいでしょう。
【別々に管理している場合】
受付（DC）：「新入社員の田中さんが入社しました」
案内係（DNS）：「知らない。私の名簿には載ってない」
来客：「田中さんはどこにいますか？」
案内係（DNS）：「そんな人知りません」
受付（DC）：「いや、いるんだけど...」
【AD統合DNSの場合】
受付（DC）：「新入社員の田中さんが入社しました」
AD統合DNS：「自動的に名簿に追加しました。3階の経理部ですね」
来客：「田中さんはどこにいますか？」
AD統合DNS：「3階の経理部にいますよ」
AD統合DNSの最大の利点は、情報の自動同期です。
【新しいPCが追加されたとき】
IT管理者：「新しいPC『PC-101』をドメインに参加させよう」
AD：「PC-101を登録しました」
AD統合DNS：「自動的にPC-101のDNSレコードも作成しました」
（通常のDNSの場合）
IT管理者：「新しいPC『PC-101』をドメインに参加させよう」
AD：「PC-101を登録しました」
IT管理者：「次はDNSにも手動で登録しないと...」
DNS：「PC-101を登録しました」
IT管理者：「二度手間だな...」
また、AD統合DNSは、複数のドメインコントローラー間で自動的に情報を同期します。
【レプリケーションの様子】
東京DC：「新しいサーバー『FILE-SERVER-01』を登録しました」
東京DC内のDNS：「DNSレコードも作成しました」
（自動レプリケーション）
大阪DC：「東京から更新情報が来た。FILE-SERVER-01を登録」
大阪DC内のDNS：「こちらでもDNSレコードを作成」
結果：どのオフィスからでも、FILE-SERVER-01の名前解決ができる
1.2.3 SRVレコードの役割
SRVレコード（サービスレコード）は、ADとDNSの連携における重要な要素です。これは、「どのサービスがどこで提供されているか」を示す特殊なDNSレコードです。
通常のDNS解決と、SRVレコードを使った解決の違いを見てみましょう。
【通常のDNS解決】
利用者：「www.example.comのIPアドレスは？」
DNS：「203.0.113.1です」
利用者：「じゃあ、そこにアクセスしよう」
【SRVレコードを使った解決】
PC：「jp.qualiteg.comのドメインコントローラーはどこ？」
DNS：「ちょっと待って、サービスの種類は？」
PC：「LDAP（認証サービス）です」
DNS：「LDAPサービスなら、次の場所で提供されています：
- DC01.jp.qualiteg.com（優先度:0、重み:50）
- DC02.jp.qualiteg.com（優先度:0、重み:50）」
PC：「優先度が同じで重みが50:50...じゃあ、負荷分散でどちらか選ぼう」
SRVレコードがなぜ必要なのか、具体例で説明します。
【大企業のオフィス】
IT管理者：「うちの会社、いろんなサービスがあるんだよね」
- 認証サービス（LDAP）: DC01, DC02
- グローバルカタログ: DC01
- Kerberosサービス: DC01, DC02
- PDCエミュレーター: DC01のみ
新入社員：「ログインしたいです」
PC→DNS：「_ldap._tcp.jp.qualiteg.comのSRVレコードください」
DNS：「DC01とDC02、どちらでもいいですよ」
管理ツール：「PDCエミュレーターと通信したい」
ツール→DNS：「_ldap._tcp.pdc._msdcs.jp.qualiteg.comのSRVレコードください」
DNS：「それはDC01だけです」
実際のSRVレコードは、以下のような情報を含んでいます。
【SRVレコードの中身】
_ldap._tcp.jp.qualiteg.com. 600 IN SRV 0 100 389 dc01.jp.qualiteg.com.
解説：
- _ldap._tcp: LDAPサービス（TCP接続）
- jp.qualiteg.com: ドメイン名
- 600: TTL（キャッシュ時間）
- SRV: レコードタイプ
- 0: 優先度（小さいほど優先）
- 100: 重み（負荷分散の割合）
- 389: ポート番号
- dc01.jp.qualiteg.com: 実際のサーバー名
1.2.4 動的DNS更新の仕組み
動的DNS更新は、ADとDNSの連携において非常に便利な機能です。これは、コンピューターが自分の情報を自動的にDNSに登録・更新する仕組みです。
【動的更新がない時代】
月曜日
田中：「私のPC（PC-101）のIPアドレスは192.168.1.50です」
IT管理者：「DNSに手動で登録しますね...」
火曜日（DHCPでIPが変わった）
田中：「あれ、今日は192.168.1.75になってる」
同僚：「PC-101に接続したいんだけど、つながらない」
IT管理者：「あぁ、IPアドレスが変わったんですね。DNS更新します...」
水曜日（また変わった）
田中：「今日は192.168.1.60...」
IT管理者：「もう手動更新は無理！」
動的DNS更新があると、この問題が解決されます。
【動的更新がある現在】
月曜日 8:00
PC-101：「起動しました。DHCPからIP192.168.1.50をもらいました」
PC-101→DNS：「PC-101のIPは192.168.1.50で登録してください」
DNS：「登録しました」
火曜日 8:00
PC-101：「起動しました。今日はIP192.168.1.75をもらいました」
PC-101→DNS：「PC-101のIPを192.168.1.75に更新してください」
DNS：「更新しました」
同僚：「PC-101に接続したい」
DNS：「現在のIPは192.168.1.75です」
同僚：「つながった！」
セキュアな動的更新では、認証されたコンピューターのみが更新できます。
【セキュアな動的更新】
正規のPC-101：「私のIPを更新してください」
DNS：「あなたは本当にPC-101ですか？」
PC-101：「はい、これが私の認証情報です」（Kerberos認証）
DNS：「確認できました。更新を許可します」
悪意のあるPC：「私はPC-101です。IPを変更してください」
DNS：「認証情報を見せてください」
悪意のあるPC：「...持ってません」
DNS：「更新を拒否します」
動的更新は、特に以下のような状況で威力を発揮します。
【ノートPCの場合】
営業の山田：「今日は本社、明日は支社、明後日は在宅勤務...」
月曜（本社）
山田のPC：「本社ネットワークでIP 192.168.1.100をもらいました」
DNS：「yamada-noteのIPを192.168.1.100で登録」
火曜（支社）
山田のPC：「支社ネットワークでIP 192.168.2.200をもらいました」
DNS：「yamada-noteのIPを192.168.2.200に更新」
水曜（VPN接続）
山田のPC：「VPNでIP 10.0.0.50をもらいました」
DNS：「yamada-noteのIPを10.0.0.50に更新」
IT管理者：「山田さんがどこにいても、自動的にDNSが更新される。楽だな〜」
このように、動的DNS更新により、管理者の負担が大幅に軽減され、常に最新の名前解決情報が維持されるのです。
1.3 認証方式の種類と違い
1.3.1 Kerberos認証
Kerberos（ケルベロス）認証は、Active Directoryで使用される最も安全な認証方式です。名前の由来は、ギリシャ神話に登場する三つの頭を持つ番犬「ケルベロス」から来ています。なぜ三つの頭かというと、認証に関わる三者（クライアント、サーバー、認証サーバー）を表しているからです。
Kerberosの仕組みを、遊園地のフリーパスチケットに例えて説明しましょう。
【遊園地でのフリーパス】
来園者：「入園したいです」
チケット売り場：「身分証明書を見せてください」
来園者：「はい、これです」
チケット売り場：「確認しました。これがフリーパスです。今日一日、どのアトラクションでも乗れます」
（ジェットコースターにて）
来園者：「乗りたいです」（フリーパスを見せる）
係員：「フリーパスを確認...本物ですね。どうぞ」
（観覧車にて）
来園者：「乗りたいです」（フリーパスを見せる）
係員：「フリーパスを確認...本物ですね。どうぞ」
Kerberosも同じような仕組みです。
【Kerberos認証の流れ】
朝9:00
田中：「会社のシステムにログインしたい」
PC→KDC（チケット売り場）：「田中さんがログインしたいそうです」
KDC：「パスワードを確認...本人ですね。TGT（フリーパス）を発行します」
PC：「TGTを受け取りました」
9:30（ファイルサーバーにアクセス）
PC→KDC：「ファイルサーバー用のチケットください」（TGTを提示）
KDC：「TGTが本物ですね。ファイルサーバー用のサービスチケットをどうぞ」
PC→ファイルサーバー：「アクセスしたいです」（サービスチケットを提示）
ファイルサーバー：「チケットを確認...本物ですね。アクセスOK」
10:00（メールサーバーにアクセス）
PC→KDC：「メールサーバー用のチケットください」（TGTを提示）
KDC：「はい、メールサーバー用のサービスチケットです」
PC→メールサーバー：「メールを見たいです」（サービスチケットを提示）
メールサーバー：「チケット確認OK。どうぞ」
Kerberosの重要な特徴は、パスワードがネットワーク上を流れないことです。
【パスワードの扱い】
（危険な方法）
田中：「パスワードは123456です」
ネットワーク：「123456...123456...」（丸見え）
悪意のある人：「田中さんのパスワードは123456か...メモメモ」
（Kerberosの方法）
田中：「パスワードを入力」（PCローカルで処理）
PC：「パスワードを使って暗号化したデータを送ります」
ネットワーク：「#%&$@*...」（暗号化されていて読めない）
悪意のある人：「何これ？さっぱり分からない」
さらに、Kerberosのチケットには有効期限があります。
【チケットの有効期限】
朝9:00
KDC：「このTGTの有効期限は今日の18:00までです」
17:55
田中：「もう少し仕事したい」
PC：「TGTがもうすぐ期限切れです。更新しますか？」
田中：「はい」
PC→KDC：「TGTを更新してください」
KDC：「まだログイン中ですね。新しいTGTをどうぞ」
翌日
悪意のある人：「昨日盗んだ田中さんのTGTを使おう」
システム：「そのチケットは期限切れです。無効」
悪意のある人：「しまった！」
1.3.2 NTLM認証
NTLM（NT LAN Manager）認証は、Kerberosより古い認証方式ですが、現在でも後方互換性のために使用されています。NTLMは、チャレンジ＆レスポンス方式という仕組みを使います。
これを、秘密の合言葉を使った認証に例えてみましょう。
【映画の中の秘密基地】
訪問者：「入れてください」
見張り：「合言葉は？今日の合言葉は『山』」（チャレンジ）
訪問者：「『川』です」（レスポンス）
見張り：「正解。どうぞ」
重要：合言葉そのものは「山→川」だが、
実際の正解「川」は最初から決まっていた
NTLMの実際の流れは以下のようになります。
【NTLM認証】
田中：「ファイルサーバーにアクセスしたい」
ファイルサーバー：「あなたは誰？」
田中のPC：「田中です」
ファイルサーバー：「では、この乱数『ABC123』を田中さんのパスワードで暗号化してください」（チャレンジ）
田中のPC：「暗号化しました。結果は『XYZ789』です」（レスポンス）
ファイルサーバー→DC：「田中さんが『ABC123』を暗号化したら『XYZ789』になったけど、正しい？」
DC：「私も計算してみます...正しいです。本物の田中さんです」
ファイルサーバー：「アクセスを許可します」
NTLMとKerberosの大きな違いをまとめると以下のようになります。
【Kerberos】
田中：「朝一度認証したら、一日中どこでも使えるフリーパス」
各サーバー：「フリーパス（チケット）確認だけでOK」
DC：「朝以降は各サーバーが勝手に確認してくれる」
【NTLM】
田中：「ファイルサーバーにアクセス」
ファイルサーバー：「ちょっと待って、DCに確認します」
DC：「確認しました」
田中：「メールサーバーにアクセス」
メールサーバー：「ちょっと待って、DCに確認します」
DC：「また確認...」
田中：「プリントサーバーに...」
プリントサーバー：「ちょっと待って、DCに確認します」
DC：「また！？忙しい...」
NTLMが使われる状況には以下のようなケースがあります。
【IPアドレスでアクセスした場合】
田中：「\\192.168.1.50\shareにアクセスしたい」
PC：「IPアドレスか...Kerberosは名前が必要だから使えない」
PC：「NTLMで認証します」
【古いシステムの場合】
田中：「この10年前のシステムにログインしたい」
古いシステム：「Kerberos？なにそれ？NTLMしか知らない」
PC：「じゃあNTLMで...」
1.3.3 Basic認証
Basic認証は、最も単純で、最も危険な認証方式です。なぜ危険かというと、ユーザー名とパスワードをほぼそのまま送信するからです。
【Basic認証の危険性】
（現実世界で例えると）
田中：「金庫を開けたいです」
金庫番：「暗証番号は？」
田中：（大声で）「1234です！」
周りの人：「今、1234って言ったよね...メモメモ」
（Basic認証）
ブラウザ：「ユーザー名：tanaka、パスワード：Pass123」
Base64エンコード：「dGFuYWthOlBhc3MxMjM=」
ネットワーク：「dGFuYWthOlBhc3MxMjM=が流れています」
悪意のある人：「Base64デコードすると...tanaka:Pass123だ！」
Base64エンコードは暗号化ではありません。
【エンコードと暗号化の違い】
（エンコード = 文字の置き換え）
子供：「暗号ごっこしよう。あ→1、い→2、う→3」
子供：「『あいう』は『123』だよ」
大人：「すぐ解読できるね」
（本当の暗号化）
暗号の専門家：「特殊な鍵がないと絶対に解読できません」
それでもBasic認証が使われる理由があります。
【Basic認証が必要な場面】
IT管理者：「統合Windows認証を設定しました」
田中：「会社のPCからは自動ログインできて便利！」
（自宅にて）
田中：「自宅から会社のシステムにアクセスしたい」
私物PC：「統合Windows認証？そんなの知らない」
システム：「では、Basic認証でユーザー名とパスワードを入力してください」
田中：「tanaka / Pass123」
システム：「確認しました。アクセスOK」
Basic認証を少しでも安全に使う方法もあります。
【HTTPSとの組み合わせ】
（HTTP = 暗号化なし）
田中：「tanaka / Pass123」
ネットワーク：「tanaka / Pass123が丸見えで流れています」
悪意のある人：「ラッキー！」
（HTTPS = 暗号化あり）
田中：「tanaka / Pass123」
HTTPS：「通信全体を暗号化します」
ネットワーク：「%#@$&*...」（全部暗号化されている）
悪意のある人：「何も読めない...」
1.3.4 各認証方式の使い分けと優先順位
Active Directoryでは、状況に応じて適切な認証方式が自動的に選択されます。この選択プロセスを見てみましょう。
【認証方式の自動選択】
田中：「サーバーにアクセスしたい」
PC：「どの認証方式が使えるか確認します」
（パターン1：すべて使える環境）
PC：「server.jp.qualiteg.comにアクセス」
サーバー：「Kerberos、NTLM、Basic、全部使えます」
PC：「じゃあ一番安全なKerberosで」
（パターン2：Kerberosが使えない）
PC：「192.168.1.100にアクセス」（IPアドレス）
サーバー：「IPアドレスだとKerberosは無理。NTLMかBasicで」
PC：「じゃあNTLMで」
（パターン3：社外から）
田中：「自宅から会社のWebシステムに」
Webシステム：「ドメイン外からですね。Basicしか使えません」
PC：「仕方ない、Basicで...でもHTTPSだから安全」
実際の優先順位は以下のようになります。
【セキュリティレベル】
最高 ↑ Kerberos
│ 「防弾ガラスの中で会話するくらい安全」
│
│ NTLM
│ 「ドア越しに合言葉で確認するくらいの安全性」
│
最低 ↓ Basic
「大声で叫ぶくらい危険（HTTPSなしの場合）」
認証方式の使い分けの実例を見てみましょう。
【社内ネットワーク】
朝のログイン
田中：「おはようございます」
PC→DC：「Kerberosでログイン」
DC：「TGTを発行します。今日一日有効です」
ファイルサーバーアクセス
PC：「file-server.jp.qualiteg.comにアクセス」
→ Kerberos使用（最も安全）
古いNASへのアクセス
PC：「\\192.168.1.200\shareにアクセス」
→ NTLM使用（IPアドレスなのでKerberos不可）
【リモートワーク】
VPN接続後
田中：「VPNで社内ネットワークに接続完了」
PC：「社内と同じようにKerberos使えます」
Web経由のアクセス
田中：「https://webapp.jp.qualiteg.comにアクセス」
Webアプリ：「社外からですね。Basic認証でお願いします」
→ Basic認証（HTTPSで保護）
トラブルシューティングの際の確認ポイントは以下の通りです。
【認証がうまくいかない時】
ユーザー：「ログインできません！」
IT管理者：「どの認証方式を使ってるか確認しよう」
確認1：イベントログ
「Kerberos認証失敗 → NTLM認証成功」
IT管理者：「Kerberosが失敗してNTLMにフォールバックしてる」
確認2：よくある原因
- 時刻のずれ（5分以上）→ Kerberos失敗
- DNSの問題 → Kerberos失敗
- SPNの設定ミス → Kerberos失敗
- 古いOS/アプリ → そもそもKerberos非対応
対策：
IT管理者：「時刻同期を確認...5分以上ずれてる！」
IT管理者：「時刻を同期したらKerberosが使えるようになりました」
最後に、各認証方式の適材適所をまとめます。
【使い分けのベストプラクティス】
社内ネットワーク：
- 原則Kerberos（自動的に選択される）
- どうしてもダメならNTLM（自動フォールバック）
- Basic認証は無効化を推奨
DMZ/Web公開サービス：
- Kerberos/NTLMは使えない
- Basic + HTTPS（またはフォーム認証）
- 可能なら多要素認証を追加
レガシーシステム：
- NTLMしか使えないことが多い
- セグメント分離などで保護
- 段階的な移行計画を立てる
このように、それぞれの認証方式には特徴があり、状況に応じて適切に使い分けることが重要です。ADは可能な限り最も安全な方式を自動的に選択しようとしますが、環境や設定によっては意図しない方式が使われることもあるため、理解しておくことが大切です。
