【後編】ファイルサーバーのハイブリッド化とKerberos認証 — Microsoft Entra ID時代の認証設計を考える

この記事の内容

ハイブリッド環境におけるWindowsクライアントの3つの参加形態（オンプレミスAD参加・ハイブリッドジョイン・Entra参加）を解説します
Azure FilesがオンプレミスADおよびMicrosoft Entra Kerberosの2種類のIDソースに対応していることを紹介します
Microsoft Entra IDがKDCとして動作し、クラウド上でKerberosチケットを発行する「Microsoft Entra Kerberos」の仕組みを説明します
クラウドオンリーユーザーがKerberos認証を利用できない現状の制約と、その背景にあるSIDの課題を整理します
Entra Domain Servicesによる代替策や、クラウド信頼（Cloud Trust）の構成パターンも取り上げます

はじめに

本記事はシリーズの後編です。前編では、ワークグループ環境とActive Directory（AD）環境の違い、Kerberos認証の基礎となるTGT（Ticket Granting Ticket）とサービスチケットの概念、そしてSSOの動作について解説しました。

後編では、Microsoft Entra IDがKerberos認証をどのように扱うかを中心に、クラウド上でのKerberos認証の最新動向と、ハイブリッド環境における認証設計のポイントを詳しく説明します。

前回までの復習：認証の仕組みとシームレスSSO

オンプレミスADではチケットベースのSSOが可能ですが、クラウド側のEntra IDはトークンベースの認証を採用しています。両者の認証プロトコルが異なるため、両環境を橋渡しする仕組みとしてシームレスSSOが存在します。

シームレスSSOは、オンプレミスで取得したKerberosチケットをEntra IDに提示し、クラウド側からトークンを受け取ることで認証を継続するものです。この仕組みによって、ユーザーはオンプレミスとクラウドの両環境にわたって、シームレスな認証体験を得られるようになっています。

ハイブリッド環境におけるWindowsクライアントの参加形態

ハイブリッド化を考える上で、まずクライアント端末の参加形態を整理することが重要です。主に次の3つのパターンがあります。

オンプレミスADドメインにのみ参加しているクライアント
ハイブリッドジョイン（Hybrid Join）しているクライアント
クラウド側のEntra IDにのみ参加しているクライアント（Entra Join）

ハイブリッドジョインでは、オンプレミスのコンピューターオブジェクトをEntra IDにも登録し、クラウド側から端末を信頼できるようにします。これにより、Entra IDが端末の状態を把握してアクセス制御を行えるようになります。

一方、最近のWindowsではオンプレミスADがなくても直接Entra IDに参加する**クラウド参加（Entra Join）**も可能です。これにより、オンプレミスとクラウドの両構成を柔軟に選択できるようになりました。

ファイルサーバーの構成パターン

クライアントが多様化する一方で、ファイルサーバー側にも複数の構成があります。

従来型：オンプレミスADドメイン参加サーバー

オンプレミスのADをIDソースとしてKerberos認証を利用する、長年にわたり安定して使われてきた一般的な構成です。

クラウド型：Azure Files

Azure上でファイル共有を提供するサービスです。初期は「ストレージアカウントキー」や「SASトークン」によるシンプルな認証方式を採用しており、ユーザー単位の権限管理はできませんでした。

しかし現在のAzure Filesは、次の2つのIDソースに対応しています。

Active Directory Domain Services（オンプレミスAD）
Microsoft Entra Kerberos（クラウド側のKerberos認証）

このうち特に注目すべきは後者のMicrosoft Entra Kerberosです。Entra IDが自らKerberosチケットを発行・受け取ることにより、クラウドだけで認証を完結できる仕組みです。

AD DSをIDソースとするAzure Files認証

オンプレミスADを認証サーバーとして利用する場合、Azure Files側にSPN（Service Principal Name）を登録します。これにより、Azure FilesがオンプレミスのKerberosチケットを受け入れられるようになります。

この構成ではNTLMではなくKerberosのみに対応しており、チケット内のSID（セキュリティ識別子）を用いてNTFS権限を照合します。ユーザー単位のアクセス制御が可能ですが、SIDの名前解決にはドメインコントローラーとの通信が必要なため、クラウドだけでは完結しないという制約があります。

Entra IDによるKerberos認証（Microsoft Entra Kerberos）

Microsoft Entra Kerberosでは、Entra IDがKDC（Key Distribution Center）として動作し、クラウド上でTGTやサービスチケットを発行します。

ハイブリッド参加またはEntra参加している端末は、Entra ID上にコンピューターアカウントを持ち、そこから直接チケットを取得できます。これにより、オンプレミスADがなくてもKerberos認証が可能になります。

この構成では、ストレージアカウントに対応する**エンタープライズアプリケーション（サービスプリンシパル）**を登録し、SPNを設定する必要があります。これはオンプレミスのコンピューターオブジェクトに相当するもので、クラウド版ADの仕組みを再現する形になっています。

チケットの発行元を切り替える仕組み

Windowsは、URLやレルム（realm）ごとに「どのKDCからチケットを取得するか」を制御できます。これにより、次のようなハイブリッド構成が実現可能です。

特定のアドレス（Azure Files）へのアクセスではEntra IDからチケットを取得する
その他のリソースへのアクセスではオンプレミスADからチケットを取得する

つまり、チケットの発行元そのものをハイブリッド化できるわけです。この柔軟な制御により、段階的な移行や混在環境の運用が現実的になります。

ハイブリッドIDユーザーとSIDの課題

現状、Kerberos認証でクラウド側のファイル共有へアクセスできるのはハイブリッドIDユーザーのみです。クラウドオンリーのユーザーはSIDを持たないため、SMBアクセス時に権限判断ができません。

SIDはオンプレミスADで管理されているため、完全なクラウドネイティブ認証方式とは整合しません。Kerberos認証自体はクラウドで発行できても、SMBの基盤設計がSIDベースのままであることが、この制約の根本的な原因です。

Entra Domain Servicesによる代替策

オンプレミスADを使わずにKerberos認証を維持したい場合、Entra Domain Servicesを導入する選択肢があります。

Entra Domain Servicesは、Entra環境内にマネージドADドメインを構築するサービスです。SIDを持つユーザーが存在するためKerberos認証が可能であり、クラウド上でADを隠蔽的に運用できる理想的な形として位置づけられます。オンプレミスADの管理負荷をなくしながら、既存のKerberos認証ベースのファイル共有を継続したいケースに有効な選択肢です。

クラウド信頼（Cloud Trust）の仕組み

オンプレミスAD参加クライアントがAzure Filesへアクセスする場合、TGTはオンプレミスADから取得し、サービスチケットはEntra IDから受け取るという構成が可能です。

この**クラウド信頼（Cloud Trust）**の仕組みを利用することで、既存のオンプレミスAD環境を維持しながら、クラウド上のファイル共有へもKerberos認証でアクセスできるようになります。移行の過渡期における現実的な構成として、ハイブリッド環境の設計時に検討する価値があります。

まとめ

本記事では、ファイルサーバーのハイブリッド化に伴うKerberos認証の設計ポイントを解説しました。

クライアントの参加形態（オンプレミスAD・ハイブリッドジョイン・Entra参加）によって、認証の経路が異なります
Azure FilesはオンプレミスADとMicrosoft Entra Kerberosの両方をIDソースとしてサポートしており、用途に応じて選択できます
Microsoft Entra KerberosではEntra IDがKDCとして機能し、クラウド上でKerberosチケットを発行できます
現状、クラウドオンリーユーザーはSIDを持たないためSMBアクセスに制約があり、ハイブリッドIDユーザーが前提となっています
Entra Domain ServicesやCloud Trustを活用することで、オンプレミスADを必要としない、あるいは段階的に移行するための柔軟な設計が可能です

Microsoft Entra IDを中心としたクラウドネイティブなID管理への移行が進む中、Kerberos認証との整合性をどう確保するかは、ハイブリッド環境を持つ多くの組織にとって重要な設計課題です。認証プロトコルの違いとSIDの制約を正しく理解した上で、自社環境に合った構成を選択することが求められます。