アプリケーションプロキシを使ったアプリへのシングルサインオン (SSO) の Kerberos の制約付き委任

[アーティクル]
02/01/2024

統合 Windows 認証でセキュリティ保護されているアプリケーションプロキシを使って公開されているオンプレミスのアプリケーションにシングルサインオンを提供できます。これらのアプリケーションにアクセスするには Kerberos チケットが必要です。アプリケーションプロキシは、Kerberos の制約付き委任 (KCD) を使って、これらのアプリケーションをサポートします。

シングルサインオン (SSO) の詳細については、シングルサインオンの概要に関するページを参照してください。

統合 Windows 認証 (IWA) を使用してアプリケーションへのシングルサインオンができるようにするには、ユーザーの権限を借用できるように Active Directory でプライベートネットワークコネクタにアクセス許可を与えます。コネクタはこのアクセス許可を利用し、ユーザーの代理としてトークンを送受信します。

KCD を使ったシングルサインオンのしくみ

この図は、ユーザーが IWA を使用するオンプレミスアプリケーションにアクセスしようとしたときのフローを説明したものです。

Microsoft Entra 認証のフロー図

ユーザーは、オンプレミスのアプリケーションにアプリケーションプロキシをとおしてアクセスするための URL を入力します。
この要求がアプリケーションプロキシによって Microsoft Entra 認証サービスにリダイレクトされて、事前認証が行われます。この時点で、Microsoft Entra ID の認証および承認のポリシーのうち、該当するものが適用されます (たとえば多要素認証)。ユーザーの正当性が確認された場合、Microsoft Entra ID はトークンを作成し、ユーザーに送信します。
ユーザーは、このトークンをアプリケーションプロキシに渡します。
アプリケーションプロキシがこのトークンを検証し、ユーザープリンシパル名 (UPN) をトークンから取り出してから、コネクタが二重認証済みのセキュリティで保護されたチャネルを介して UPN とサービスプリンシパル名 (SPN) をプルします。
コネクタは、オンプレミス AD との KCD (Kerberos の制約付き委任) ネゴシエーションを実行します。このときに、ユーザーの代理でアプリケーションに対する Kerberos トークンを取得します。
Active Directory は、そのアプリケーション用の Kerberos トークンをコネクタに送信します。
コネクタは、AD から受信した Kerberos トークンを使用して、元の要求をアプリケーションサーバーに送信します。
アプリケーションからコネクタに応答が送信されます。この応答はその後、アプリケーションプロキシサービスに返され、最後にユーザーに返されます。

前提条件

IWA アプリケーションでのシングルサインオンに着手する前に、ご使用の環境が次の設定と構成に対応していることを確認してください。

対象のアプリ (SharePoint Web アプリなど) が統合 Windows 認証を使用するように設定されていること。詳細については、「Kerberos 認証のサポートを有効にする」を参照してください。SharePoint の場合は、「SharePoint 2013 で Kerberos 認証を計画する」を参照してください。
対象となるすべてのアプリにサービスプリンシパル名があること。
コネクタを実行するサーバーとアプリを実行するサーバーがドメインに参加し、かつ同じドメインまたは信頼する側のドメインに属していること。ドメインへの参加の詳細については、「コンピューターをドメインに参加させる」を参照してください。
Connector を実行しているサーバーに、ユーザーの TokenGroupsGlobalAndUniversal 属性を読み取るためのアクセス権があること。既定ではそのように設定されていますが、環境のセキュリティを強化する過程で変更されている可能性があります。コネクタサーバーを "Windows Authorization Access グループ" に追加すると、通常、この処理が行われます。

Active Directory を構成する

Active Directory の構成は、プライベートネットワークコネクタとアプリケーションサーバーが同じドメイン内にあるかどうかによって異なります。

同じドメインにあるコネクタとアプリケーションサーバー

Active Directory で、 [ツール]>[ユーザーとコンピューター] の順に移動します。
コネクタを実行しているサーバーを選択します。
右クリックし、 [プロパティ]>[委任] を選択します。
[指定されたサービスへの委任でのみこのコンピューターを信頼する] をクリックします。
[任意の認証プロトコルを使う] を選択します。
[このアカウントが委任された資格情報を提示できるサービス] の下で、アプリケーションサーバーの SPN ID の値を追加します。これで、プライベートネットワークコネクタは、AD において、リストで定義されたアプリケーションに対してユーザーの代理となることができるようになります。

異なるドメインにあるコネクタとアプリケーションサーバー

ドメイン間の KCD を使用するための前提条件の一覧については、「ドメイン間の Kerberos の制約付き委任」を参照してください。
Web アプリケーションのサービスアカウント (コンピューターまたは専用ドメインのユーザーアカウント) の principalsallowedtodelegateto プロパティを使用して、アプリケーションプロキシ (コネクタ) からの Kerberos 認証の委任を有効にします。アプリケーションサーバーは webserviceaccount のコンテキストで実行され、委任サーバーは connectorcomputeraccount です。 webserviceaccount のドメイン内の (Windows Server 2012 R2 以降を実行している) ドメインコントローラーで次のコマンドを実行します。両方のアカウントにフラット名 (UPN 以外) を使用します。

webserviceaccount がコンピューターアカウントの場合は、次のコマンドを使用します。
```
$connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com

Set-ADComputer -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector

Get-ADComputer webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
```
webserviceaccount がユーザーアカウントの場合は、次のコマンドを使用します。
```
$connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com

Set-ADUser -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector

Get-ADUser webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
```

Configure single sign-on

「アプリケーションプロキシを使用したアプリケーションの公開」で説明している手順に従って、アプリケーションを公開します。 事前認証方法として、必ず [Microsoft Entra ID] を選んでください。
アプリケーションがエンタープライズアプリケーションの一覧に表示されたら、アプリケーションを選択して [シングルサインオン] をクリックします。
シングルサインオンモードを [統合 Windows 認証] に設定します。
アプリケーションサーバーの [内部アプリケーション SPN] を入力します。この例では、公開されたアプリケーションの SPN は、http/www.contoso.com です。この SPN は、コネクタが委任された資格情報を提供できるサービスの一覧に入っている必要があります。
ユーザーの代わりに使うコネクタに委任されたログイン ID を選択します。詳細については、「さまざまなオンプレミス ID とクラウド ID の操作」を参照してください。

Windows 以外のアプリの SSO

Microsoft Entra アプリケーションプロキシの Kerberos 委任フローは、Microsoft Entra がクラウドでユーザーを認証すると開始されます。要求がオンプレミスに到着すると、Microsoft Entra プライベートネットワークコネクタは、ローカルの Active Directory とやり取りすることで、ユーザーに代わって Kerberos チケットを発行します。このプロセスは Kerberos の制約付き委任 (KCD) と呼ばれます。

次のフェーズで、要求がこの Kerberos チケットを使用してバックエンドアプリケーションに送信されます。

このような要求で Kerberos チケットを送信する方法を定義するメカニズムはいくつかあります。 Windows 以外のほとんどのサーバーでは、SPNEGO トークンの形式でそれを受け取ることが想定されています。このメカニズムは、Microsoft Entra アプリケーションプロキシでサポートされていますが、既定では無効になっています。 SPNEGO と標準の Kerberos トークンの両方ではなくいずれかに対してコネクタを構成することができます。

SPNEGO 用にコネクタマシンを構成する場合は、そのコネクタグループ内の他のすべてのコネクタも SPNEGO で構成されていることを確認してください。標準 Kerberos トークンを使用するアプリケーションは、SPNEGO 用に構成されていない他のコネクタを介してルーティングする必要があります。一部の Web アプリケーションでは、構成を変更せずに両方の形式を使用できます。

SPNEGO を有効にするには:

管理者として実行しているコマンドプロンプトを開きます。

コマンドプロンプトから、SPNEGO が必要なコネクタサーバーに対して次のコマンドを実行します。

REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft Entra private network connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1
net stop WAPCSvc & net start WAPCSvc

非 Windows アプリは通常、ドメインのメールアドレスの代わりに、ユーザー名または SAM アカウント名を使います。お使いのアプリケーションでこの状況が当てはまる場合、指定されたログイン ID フィールドを構成して、クラウド ID をアプリケーション ID に接続する必要があります。

さまざまなオンプレミス ID とクラウド ID の操作

アプリケーションプロキシは、ユーザーのクラウド ID とオンプレミス ID は完全に同じであるとみなします。しかし、環境によっては、企業ポリシーやアプリケーションの依存関係が原因で、サインインに代替 ID を使用する必要がある場合があります。このような場合でも、シングルサインオンに引き続き KCD を使用できます。アプリケーションごとに指定されたログイン ID を構成し、シングルサインオンを実行するときに使う ID を指定します。

この機能により、オンプレミス ID とクラウド ID が異なる多くの組織で、ユーザーに別のユーザー名とパスワードの入力を要求することなく、クラウドからオンプレミスのアプリに SSO させることができます。次のような組織が含まれます。

内部に複数のドメインがあり (joe@us.contoso.com、joe@eu.contoso.com)、クラウドに 1 つのドメインがある (joe@contoso.com)。
内部にルーティングできないドメイン名があり (joe@contoso.usa)、クラウドに法的なドメイン名がある。
内部でドメイン名を使用していない (joe)。
オンプレミスとクラウドで異なるエイリアスを使用している。たとえば、joe-johns@contoso.com と joej@contoso.com です。

アプリケーションプロキシを使用すると、Kerberos チケットの取得に使用する ID を選択できます。この設定は、アプリケーションごとに行います。これらのオプションの中には、電子メールアドレスの形式を受け入れないシステムに適したものもあれば、代替ログイン用に設計されたものもあります。

委任されたログイン ID パラメーターのスクリーンショット

委任されたログイン ID が使用されている場合、その値は組織内のすべてのドメインまたはフォレストで一意でないことがあります。異なる 2 つのコネクタグループを使用してこれらのアプリケーションを 2 回発行することで、この問題を回避できます。これは各アプリケーションのユーザーが異なり、そのコネクタを異なるドメインに参加させることができるためです。

オンプレミスの SAM アカウント名をログオン ID として使用する場合は、コネクタをホストするコンピューターを、ユーザーアカウントが存在するドメインに追加する必要があります。

ID が異なる場合の SSO の構成

Microsoft Entra Connect の設定を、メイン ID がメールアドレス (メール) になるように構成します。これはカスタマイズプロセスの一部として、同期設定の [ユーザープリンシパル名] フィールドを変更することで実行します。これらの設定は、ユーザーが Microsoft 365、Windows コンピューター、および Microsoft Entra ID を ID ストアとして使う他のアプリケーションにサインインする方法も決定します。
変更するアプリケーションの [アプリケーションの構成] 設定で、使用する [委任されたログイン ID] を選択します。
- ユーザープリンシパル名 (joe@contoso.com など)
- 代替ユーザープリンシパル名 (joed@contoso.local など)
- ユーザープリンシパル名のユーザー名部分 (joe など)
- 代替ユーザープリンシパル名のユーザー名部分 (joed など)
- オンプレミスのソフトウェアアセット管理アカウント名 (ドメインコントローラーの構成に依存)

ID が異なる場合の SSO のトラブルシューティング

SSO プロセスにエラーがある場合は、「トラブルシューティング」で説明するように、コネクタコンピューターのイベントログに表示されます。ただし、場合によっては、バックエンドアプリケーションが他のさまざまな HTTP 応答に応答している間に、要求が正常に送信されることがあります。このような場合のトラブルシューティングは、アプリケーションプロキシセッションのイベントログで、コネクタコンピューターのイベント番号 24029 を調べることから始める必要があります。委任のために使用されたユーザー ID は、イベント詳細の [ユーザー] フィールドに表示されます。セッションログを有効にするには、イベントビューアーで [表示] メニューの [分析およびデバッグログの表示] を選択します。

次の方法で共有

アプリケーションプロキシを使ったアプリへのシングルサインオン (SSO) の Kerberos の制約付き委任

KCD を使ったシングルサインオンのしくみ