【前編】ファイルサーバーのハイブリッド化！認証の進化をパケットで確認！SMB・NTLM・Kerberos

この記事の内容

• ワークグループ環境でのSMB・NTLM認証の仕組みと課題を解説します
• Active Directory環境でKerberos認証がどのように動作するかを説明します
• パケットキャプチャを通じて、NTLMとKerberosの違いを具体的に確認します
• サービスプリンシパルネーム（SPN）の役割とCIFS・Hostの関係を説明します
• オンプレミスからクラウドへの認証進化の流れを整理します

はじめに

クラウド環境が普及した現在でも、Kerberos認証は多くの場面で利用されています。本記事では、身近なファイルサーバーを題材に、クラウドやオンプレミスの端末からファイルサーバーを利用する際、認証プロトコルがどのように進化してきたのかを解説します。シングルサインオンをはじめとした最新の認証手法やプロトコルの違いについても、パケットの観点から掘り下げていきます。

オンプレミスのActive Directory環境を利用しつつもクラウド活用を検討している方、ファイルサーバーの運用やクラウドストレージへの移行を考えている方、認証プロトコルの仕組みに興味がある方に特におすすめの内容です。

ワークグループ環境とNTLM認証

ワークグループ環境とは

まずは認証の基礎から、ワークグループ環境について説明します。ワークグループ環境とは、Active Directoryなどの集中管理されたIDが存在しない、ご家庭や小規模事業でよく見られる構成です。たとえば、家電量販店で購入したWindows PC同士をそのまま使うと、この形態になります。

ローカルアカウントとファイル共有

各Windowsマシンにはローカルアカウントを作成できます。「コンピューターの管理」ツールの「ローカルユーザーとグループ」からユーザーを追加できます。共有フォルダーも作成可能で、Windowsクライアント自体がファイルサーバーとして機能します。

SMBとNTLM認証の仕組み

この環境で他のPCの共有フォルダーへネットワーク越しにアクセスするには、SMB（Server Message Block）プロトコルとNTLM（NT LAN Manager）認証が利用されます。エクスプローラーで以下のように入力すると、「ネットワーク資格情報の入力」が求められます。

ここで入力するユーザー名とパスワードはアクセス先サーバーのローカルアカウントです。サーバー側に該当ユーザーが存在しない場合は認証失敗、存在すればアクセスが可能です。

パケットレベルで見るNTLM認証

パケットキャプチャを行うと、以下の流れが確認できます。

1. TCP 445番ポートへの3ウェイハンドシェイク
2. SMBプロトコルネゴシエート（バージョン交渉）
3. NTLM認証の選択

SMB2プロトコルとNTLM認証のやり取りがパケット上で明示されており、認証の流れを視覚的に把握できます。

ワークグループ環境の課題

この方式では、ファイルサーバーごとに別々のローカルアカウント管理が必要となり、ユーザーは各サーバーで異なるIDとパスワードを覚える必要があります。すべてのサーバーで同じIDとパスワードを使う方法もありますが、セキュリティ上好ましくありません。

この「アカウント分散管理」はワークグループ運用の大きなデメリットです。現在ではほとんど利用されなくなりましたが、20年以上前には一般的な構成でした。

Active Directory環境とKerberos認証

Active Directoryの概要

ワークグループ環境の課題を解決するために登場したのが、Active Directory（AD）環境です。ADではドメインコントローラー（DC）がディレクトリデータベースを持ち、ユーザーやコンピューター、サービスを一元管理します。各マシンは「ドメイン参加」によりドメインと信頼関係を結びます。

Kerberos認証の導入

ファイルサーバーへのアクセス自体はSMBのままですが、認証方式はKerberosへと進化しました。KerberosはNTLMより遥かにセキュアで、複雑な仕組みを持っています。

Kerberos認証の流れ

Kerberos認証は以下の3ステップで動作します。

ステップ1: TGTの取得

ユーザーがWindowsクライアントにログインすると、ドメインコントローラー（KDC: Key Distribution Center）からTGT（Ticket Granting Ticket）を受け取ります。

ステップ2: サービスチケットの要求

ファイルサーバー等のサービスにアクセスする場合、TGTを使ってドメインコントローラーにサービスチケット（TGS: Ticket Granting Service）を要求します。

ステップ3: サービスチケットの受領と提示

取得したサービスチケットをファイルサーバーに提示し、認証が完了した後にアクセスが許可されます。

パケットキャプチャで確認するKerberos認証

パケットレベルでは、NTLM認証時と同様にSMBのプロトコルネゴシエートが行われます。しかし認証部分では、以下のような記述が現れます。

• GSSAPI
• SPNEGO

これらの記述が確認できると、Kerberos認証が使われていることが分かります。NTLMとKerberos双方のパケットを比較することで、認証プロセスの違いを理解しやすくなります。

Kerberos認証の特徴とメリット

Kerberos認証は「認証」と「認可」が分離されている点が大きな特徴です。

NTLMではクライアントとサーバー間のみで認証と認可が完結していましたが、Kerberosでは第三者（ドメインコントローラー）が大きな役割を果たします。

AD環境下ではよりセキュアで一元的な認証管理が実現し、運用負荷も大きく軽減されます。ワークグループのNTLM認証からADのKerberos認証への進化は、ファイルサーバー運用の大きな転換点です。

サービスプリンシパルネーム（SPN）とKerberos認証の実際

SPNとは

Kerberos認証を正しく機能させるためには、対象コンピューターアカウントに「サービスプリンシパルネーム（SPN）」属性を設定しておく必要があります。SPNは以下の形式で、提供可能なサービスが登録されています。

通常、ドメイン参加やソフトウェアのセットアップ時に自動登録されます。

SPNとCIFS・Hostの関係

SPNの中で「CIFS/サーバ名」が存在しない場合でも、「Host/サーバ名」があればCIFSサービスとして認識されます。これはSPNマッピング属性によるもので、ADSI Editなどのツールで確認できます。

多くの場合、「Host」名が複数登録されており、「Host」として登録されていれば他のサービスにも対応可能です。

まとめ

本記事では、ファイルサーバーへのアクセスを通じて、認証プロトコルの進化を解説しました。

• ワークグループ環境では、SMBプロトコルとNTLM認証が使われますが、サーバーごとに個別のローカルアカウント管理が必要となり、運用負荷やセキュリティ上の課題があります。
• Active Directory環境では、Kerberos認証が導入され、一元的な認証管理とシングルサインオンが実現します。
• Kerberos認証は「TGTの取得」「サービスチケットの要求」「サービスチケットの提示」という3ステップで動作し、NTLMと比較して遥かにセキュアな設計になっています。
• パケットキャプチャを活用することで、NTLM認証とKerberos認証の違いを具体的に確認できます。
• **SPN（サービスプリンシパルネーム）**はKerberos認証を正しく機能させるための重要な要素であり、通常はドメイン参加時に自動登録されます。

後編では、クラウド環境との連携やハイブリッド構成における認証の仕組みについて、さらに詳しく解説する予定です。