ファイルサーバーのハイブリッド化とKerberos認証

【中編】ファイルサーバーのハイブリッド化とKerberos認証 ― シームレスSSOの仕組みを理解する この記事の内容 オンプレミスのActive DirectoryとEntra ID（旧Azure AD）における認証方式の違いを解説します シームレスSSOの仕組みと、KerberosチケットをクラウドSSO実現に活用する方法を紹介します Entra Connect SyncでシームレスSSOを有効化する具体的な構成手順を説明します グループポリシーによるブラウザのイントラネットゾーン設定方法を解説します klistコマンドを使った動作確認の方法を紹介します オンプレミスとクラウドの認証の違い オンプレミス環境では、Active Directory（AD）によってユーザー認証が行われます。ユーザーがWindowsにログインすると、**TGT（Ticket Granting Ticket）**と呼ばれるKerberosチケットを取得します。このチケットを使って、ファイルサーバーやデータベースなどの各種サービスへアクセスできます。 一方、クラウド側、例えば Microsoft 365（M365） や Dynamics 365 にアクセスする場合は、**Entra ID（旧Azure AD）**が認証基盤として機能します。通常の流れでは、ユーザーがWeb画面でIDとパスワードを入力し、多要素認証（MFA）を経てEntra IDからトークンを受け取り、そのトークンをもってクラウドサービスへアクセスします。 このように、オンプレミスは「Kerberosチケット」、クラウドは「トークンベース認証」という異なる仕組みを持っています。そこで登場するのが、両者を橋渡しする シームレスSSO です。 シームレスSSOとは ― Kerberosチケットでクラウドに入る仕組み シームレスSSOは、オンプレミスでログインしたユーザーが再度パスワードを入力することなく、クラウドサービスにアクセスできるようにする仕組みです。 その鍵を握るのが Kerberosチケットの再利用です。Entra IDがKerberosチケットを受け取れるよう設定すると、ユーザーはオンプレミスで既に取得しているTGTを利用してクラウド認証をスキップできます。 これを構成する際に使うのが Azure AD Connect（現在のEntra Connect Sync） です。 構成手順：Entra ConnectでシームレスSSOを有効化する 1. Entra Connect Syncの設定 Entra Connect Syncの設定画面で「ユーザーサインイン方法」を選択します。「パスワードハッシュ同期」と「シングルサインオンを有効化」を選びます。 2. ドメイン管理者の資格情報を入力 Active Directoryフォレスト内に新しいコンピューターアカウントが自動的に作成されます。 3. 作成されるアカウント：ADSSOACC このアカウントにはサービスプリンシパルネーム（SPN）が登録されます。SSOに関連するURLとして、以下のようなURLがSPNとして登録されます。 h h t t t t p p s s : : / / l a o a g d i g n . . w m i i n c d r o o w s s o . f n t e o t n . l n i x n . e n . e c t o m この設定により、Entra IDはKerberosチケットを正しく認識し、トークンを発行できるようになります。 ...

【後編】ファイルサーバーのハイブリッド化と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チケットを受け入れられるようになります。 ...

【前編】ファイルサーバーのハイブリッド化！認証の進化をパケットで確認！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）認証が利用されます。エクスプローラーで以下のように入力すると、「ネットワーク資格情報の入力」が求められます。 \ 1 0 . 1 . 1 . 4 ここで入力するユーザー名とパスワードはアクセス先サーバーのローカルアカウントです。サーバー側に該当ユーザーが存在しない場合は認証失敗、存在すればアクセスが可能です。 パケットレベルで見るNTLM認証 パケットキャプチャを行うと、以下の流れが確認できます。 TCP 445番ポートへの3ウェイハンドシェイク SMBプロトコルネゴシエート（バージョン交渉） 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）を受け取ります。 ...