次の方法で共有

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

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

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

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

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

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

Microsoft Entra 認証のフロー図

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

前提条件

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

  • 対象のアプリ (SharePoint Web アプリなど) が統合 Windows 認証を使用するように設定されていること。 詳細については、「Kerberos 認証のサポートを有効にする」を参照してください。SharePoint の場合は、「SharePoint 2013 で Kerberos 認証を計画する」を参照してください。
  • 対象となるすべてのアプリにサービス プリンシパル名があること。
  • コネクタを実行するサーバーとアプリを実行するサーバーがドメインに参加し、かつ同じドメインまたは信頼する側のドメインに属していること。 ドメインへの参加の詳細については、「 コンピューターをドメインに参加させる」を参照してください。
  • コネクタ サーバーがユーザーの TokenGroupsGlobalAndUniversal 属性を読み取ることができることを確認します。 セキュリティ強化によって、このアクセスが制限される場合があります。 Windows 承認アクセス グループにコネクタ サーバーを追加して、コネクタ サーバーを有効にします。

Active Directory を構成する

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

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

  1. Active Directory で、 [ツール]>[ユーザーとコンピューター] の順に移動します。

  2. コネクタを実行しているサーバーを選択します。

  3. 右クリックし、 [プロパティ]>[委任] を選択します。

  4. [指定されたサービスへの委任でのみこのコンピューターを信頼する] をクリックします。

  5. [任意の認証プロトコルを使う] を選択します。

  6. [このアカウントが委任された資格情報を提示できるサービス] の下で、アプリケーション サーバーの SPN ID の値を追加します。 この設定により、プライベート ネットワーク コネクタは、一覧で定義されているアプリケーションに対して AD のユーザーを偽装できます。

    Connector-SVR のプロパティ ウィンドウのスクリーン ショット

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

  1. ドメイン間の KCD を使用するための前提条件の一覧については、「 ドメイン間の Kerberos の制約付き委任」を参照してください。

  2. アプリケーション プロキシ (コネクタ) からの Kerberos 認証委任を有効にするには、Web アプリケーションのサービス アカウント (PrincipalsAllowedToDelegateTo) の webserviceaccount プロパティを使用します。 アプリケーション サーバーは 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

シングル サインオンの設定

  1. 「アプリケーション プロキシを使用したアプリケーションの公開」で説明している手順に従って、アプリケーションを公開します。 事前認証方法として、必ず [Microsoft Entra ID] を選んでください。

  2. アプリケーションがエンタープライズ アプリケーションの一覧に表示されたら、それを選択し、[ シングル サインオン] を選択します。

  3. シングル サインオン モードを [統合 Windows 認証] に設定します。

  4. アプリケーション サーバーの [内部アプリケーション SPN] を入力します。 この例では、公開されたアプリケーションの SPN は、http/www.contoso.com です。 SPN は、コネクタが委任された資格情報を提示できるサービスの一覧に含まれている必要があります。

  5. ユーザーの代わりに使うコネクタに委任されたログイン 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 を有効にするには:

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

  2. 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 を指定します。

この機能を使用すると、組織は、ユーザーが異なるユーザー名とパスワードを管理しなくても、クラウドからオンプレミスのアプリへの SSO を有効にすることができます。 一般的なシナリオは、次のとおりです。

  • 1 つのクラウド ドメイン (joe@us.contoso.com など) で複数の内部ドメイン (joe@eu.contoso.com、joe@contoso.comなど) を使用する。
  • クラウドで有効なドメイン名を使用しているときに、ルーティング不可能な内部ドメイン名 (たとえば、 joe@contoso.usa) を持つ。
  • 内部ドメイン名 (joe など) なしで動作します。
  • オンプレミスとクラウドのユーザーに異なるエイリアスを割り当てる (たとえば、 joe-johns@contoso.com と joej@contoso.com)。

アプリケーション プロキシでは、Kerberos チケットの取得に使用する ID を選択できます。 この設定はアプリケーションごとに構成され、nonemail 形式または代替サインイン方法を必要とするシステムをサポートします。

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

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

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

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

  1. Microsoft Entra Connect の設定を、メイン ID がメール アドレス (メール) になるように構成します。 構成は、同期設定の [ユーザー プリンシパル名 ] フィールドを変更することで、カスタマイズ プロセスの一環として行われます。 これらの設定は、ユーザーが Microsoft 365、Windows コンピューター、および Microsoft Entra ID を ID ストアとして使う他のアプリケーションにサインインする方法も決定します。
    ユーザーを識別するスクリーンショット - [ユーザー プリンシパル名] ドロップダウン リスト

  2. 変更するアプリケーションの [アプリケーションの構成] 設定で、使用する [委任されたログイン ID] を選択します。

    • ユーザー プリンシパル名 (joe@contoso.com など)
    • 代替ユーザー プリンシパル名 (joed@contoso.local など)
    • ユーザー プリンシパル名のユーザー名部分 (joe など)
    • 代替ユーザー プリンシパル名のユーザー名部分 (joed など)
    • オンプレミスのソフトウェア アセット管理アカウント名 (ドメイン コントローラーの構成に依存)

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

バックエンド アプリケーションが予期しない HTTP 応答で応答する場合は、コネクタ マシンのアプリケーション プロキシ セッション イベント サインインでイベント 24029 を確認してトラブルシューティングを開始します。 イベントの詳細の "user" フィールドには、委任に使用される ID が表示されます。 セッション ログを有効にするには、イベント ビューアーに移動し、[ 表示 ] メニューを開き、[ 分析ログとデバッグ ログの表示] を選択します。

次のステップ