次の方法で共有

Oracle E-Business Suite の SSO のための F5 の BIG-IP Easy Button を設定する

この記事では、F5 の BIG-IP Easy Button のガイド付き構成を通じて、Microsoft Entra ID を使用して Oracle Enterprise Business Suite (EBS) をセキュリティで保護する方法について説明します。

BIG-IP と Microsoft Entra ID の統合には、以下のように数多くの利点があります。

すべての利点については、F5 BIG-IP と Microsoft Entra の統合に関する記事と Microsoft Entra ID を使用したアプリケーション アクセスとシングル サインオンに関する記事を参照してください。

シナリオの説明

このシナリオでは、HTTP 認証ヘッダーを使用して保護されたコンテンツへのアクセスを管理する従来の Oracle EBS アプリケーションを説明します。

従来のアプリケーションには、Microsoft Entra ID との直接的な統合をサポートする最新のプロトコルがありません。 アプリケーションは最新化できますが、コストがかかり、慎重な計画が必要であり、潜在的なダウンタイムのリスクが生じます。 代わりに、プロトコル遷移によって従来のアプリケーションと最新の ID コントロール プレーンとの間のギャップを橋渡しするために、F5 BIG IP Application Delivery Controller (ADC) を使用します。

アプリの前に BIG-IP があると、Microsoft Entra の事前認証とヘッダー ベースの SSO によってサービスをオーバーレイできるようになるため、アプリケーションの全体的なセキュリティ体制が大幅に強化されます。

シナリオのアーキテクチャ

このシナリオの安全なハイブリッド アクセス ソリューションは、多階層の Oracle アーキテクチャを含むいくつかのコンポーネントで構成されています。

Oracle EBS アプリケーション: Microsoft Entra SHA によって保護される BIG-IP の公開済みサービス。

Microsoft Entra ID: Security Assertion Markup Language (SAML) ID プロバイダー (IdP)。ユーザーの資格情報の検証、条件付きアクセス (CA)、および BIG-IP に対する SAML ベースの SSO に責任があります。 SSO を介して、Microsoft Entra ID により、必要なセッション属性が BIG-IP に提供されます。

Oracle Internet Directory (OID): ユーザー データベースをホストします。 BIG-IP では、LDAP 経由で認可属性を確認します。

Oracle AccessGate: EBS アクセス cookie を発行する前に、OID サービスを使用してバック チャネルを介して認可属性を検証します

BIG-IP: アプリケーションに対するリバース プロキシおよび SAML サービス プロバイダー (SP)。Oracle アプリケーションへのヘッダーベースの SSO を実行する前に認証を SAML IdP に委任します。

このシナリオの SHA では、SP と IdP によって開始されたフローの両方がサポートされます。 次の図は、SP Initiated フローを示しています。

セキュア ハイブリッド アクセス - SP Initiated フロー

手順 説明
1 ユーザーがアプリケーション エンドポイント (BIG-IP) に接続する
2 BIG-IP APM アクセス ポリシーは、ユーザーを Microsoft Entra ID (SAML IdP) にリダイレクトする
3 Microsoft Entra ID によって、ユーザーの事前認証と、条件付きアクセス ポリシーの適用が行われる
4 ユーザーがリダイレクトされて BIG-IP (SAML SP) に戻され、発行された SAML トークンを使用して SSO が実行される
5 BIG IP によって、ユーザーの一意の ID (UID) 属性に対して LDAP クエリが実行される
6 BIG IP によって、返された UID 属性が、EBS セッション Cookie 要求の user_orclguid ヘッダーとして Oracle AccessGate に挿入される
7 Oracle AccessGate によって、Oracle Internet Directory (OID) サービスに対して UID が検証され、EBS アクセス Cookie が発行される
8 EBS ユーザー ヘッダーと Cookie がアプリケーションに送信され、ユーザーにペイロードが返される

前提条件

以前の BIG-IP エクスペリエンスは必要ありませんが、以下が必要です。

  • Microsoft Entra ID 無料サブスクリプション (またはそれ以上)

  • 既存の BIG-IP。または、Azure に BIG-IP Virtual Edition (VE) をデプロイします。

  • 次のいずれかの F5 BIG-IP ライセンス SKU

    • F5 BIG-IP® Best バンドル

    • F5 BIG-IP Access Policy Manager™ (APM) スタンドアロン ライセンス

    • 既存の BIG-IP F5 BIG-IP® Local Traffic Manager™ (LTM) に対する F5 BIG-IP Access Policy Manager™ (APM) アドオン ライセンス

    • 90 日間の BIG-IP 全機能試用版ライセンス。

  • ユーザー ID (オンプレミス ディレクトリから Microsoft Entra ID に同期、または Microsoft Entra ID 内で直接作成してオンプレミス ディレクトリに返したもの)

  • Microsoft Entra アプリケーション管理者のアクセス許可を持つアカウント

  • HTTPS でサービスを公開するための SSL Web 証明書 (または、テスト中に使用する既定の BIG-IP 証明書)

  • Oracle AccessGate と LDAP が有効な OID (Oracle Internet Database) を含む既存の Oracle EBS スイート

BIG-IP の構成方法

このシナリオで使用する BIG-IP は、テンプレートを使用した 2 つの方法や高度な構成を含め、さまざまな方法で構成できます。 この記事では、Easy ボタン テンプレートを提供する最新のガイド付き構成 16.1 について説明します。 Easy Button を使用すると、管理者は、Microsoft Entra ID と BIG-IP の間を行き来して SHA のためにサービスを有効にする必要がなくなります。 デプロイとポリシー管理は、APM のガイド付き構成ウィザードと Microsoft Graph との間で直接処理されます。 この充実した BIG-IP APM と Microsoft Entra ID の統合により、アプリケーションでは確実に ID フェデレーション、SSO、Microsoft Entra 条件付きアクセスを迅速かつ容易にサポートできるため、管理オーバーヘッドが軽減されます。

注

このガイド全体で参照されている文字列または値の例はすべて、実際の環境に合わせて置き換える必要があります。

Easy Button を登録する

クライアントまたはサービスから Microsoft Graph にアクセスするには、Microsoft ID プラットフォームによって信頼されている必要があります。

この最初の手順では、Graph への Easy Button アクセスを承認するために使用されるテナント アプリの登録を作成します。 これらのアクセス許可により、BIG-IP は、発行されたアプリケーションの SAML SP インスタンスと SAML IdP としての Microsoft Entra ID との間に信頼を確立するために必要な構成をプッシュできます。

  1. アプリケーションの管理者権限を持つアカウントを使用して、Azure portal にサインインします。

  2. 左側のナビゲーション ウィンドウから、Microsoft Entra ID サービスを選択します。

  3. [管理] で、[アプリの登録]>[新規登録] の順に選択します。

  4. F5 BIG-IP Easy Button など、アプリケーションの表示名を入力します。

  5. アプリケーションを使用できるユーザー >[Accounts in this organizational directory only] (この組織ディレクトリのアカウントのみ) を指定します。

  6. [登録] を選択して、初期のアプリ登録を完了します。

  7. [API* のアクセス許可*] に移動し、次の Microsoft Graph* のアプリケーション*のアクセス許可*を承認します：

    • Application.Read.All
    • Application.ReadWrite.All
    • Application.ReadWrite.OwnedBy
    • Directory.Read.All (ディレクトリのすべてを読む)
    • Group.Read.All
    • IdentityRiskyUser.Read.All（アイデンティティリスキーユーザー.リード.オール）
    • Policy.Read.All
    • ポリシー.読み取り書き込み.アプリケーション設定
    • Policy.ReadWrite.ConditionalAccess
    • User.Read.All

  8. 組織に管理者の同意を付与します

  9. [Certificates & Secrets](証明書とシークレット) に移動し、新しいクライアント シークレットを生成して、それをメモします

  10. [Overview](概要) に移動し、クライアント ID と テナント ID をメモします

Easy Button を構成する

APM* の [ガイド*付き構成*] を開始して、Easy Button テンプレート*を起動します。

  1. [アクセス] > [ガイド付き構成] > [Microsoft 統合] に移動し、[Microsoft Entra アプリケーション] を選択します。

  2. [次の手順に従ってソリューションを構成すると、必要なオブジェクトが作成されます] で、構成手順の一覧を確認し、[次へ] を選択します。

  3. [ガイド付き構成] で、アプリケーションの公開に必要な一連の手順に従います。

Configuration Properties

[構成のプロパティ] タブでは、BIG-IP アプリケーション構成と SSO オブジェクトが作成されます。 [Azure サービス アカウントの詳細] セクションは、アプリケーションとして、以前に Microsoft Entra テナントに登録したクライアントを表すものとします。 これらの設定*により、BIG-IP* の OAuth クライアント*では、通常は手動で構成する* SSO* プロパティと共に、SAML SP をテナント*に直接個別に登録できるようになります。 Easy Button により、公開*されて SHA が有効になっているすべての BIG-IP* サービス*に対してこの操作が行われます。

これらの一部はグローバル設定であるため、より多くのアプリケーションを公開するために再利用でき、デプロイの時間と労力をさらに削減するのに役立ちます。

  1. 管理者が Easy Button 構成を容易に区別できる一意の構成名を指定します

  2. [Single Sign-On (SSO) & HTTP Headers](シングル サインオン (SSO) と HTTP ヘッダー) を有効にします

  3. テナントに Easy Button クライアントを登録するときに記録したテナント ID、クライアント ID、およびクライアント シークレットを入力します。

  4. [Next] (次へ) を選択する前に、BIG-IP がテナントに正常に接続できることを確認してください。

    構成の一般プロパティとサービス アカウントのプロパティのスクリーンショット

サービス プロバイダー

サービス* プロバイダー*設定*では、SHA によって保護されるアプリケーション*の SAML SP インスタンス*のプロパティを定義します。

  1. ホストを入力します。 これは、セキュリティで保護されるアプリケーションのパブリック FQDN です

  2. エンティティ ID を入力します。 これは、トークンを要求する SAML SP を識別するために Microsoft Entra ID によって使用される識別子です

    [Service Provider]\(サービス プロバイダー\) 設定のスクリーンショット

    次に、オプションの [セキュリティ設定] で、発行された SAML アサーションを Microsoft Entra ID で暗号化する必要があるかどうかを指定します。 Microsoft Entra ID と BIG-IP APM の間でアサーションを暗号化すると、コンテンツ トークンが傍受されないこと、および個人や会社のデータが侵害されないことが保証されます。

  3. [アサーション解読秘密キー] の一覧から、[新規作成] を選択します

    Easy Button の構成のスクリーンショット - 新しいインポートの作成

  4. OK を選択します。 新しいタブで [Import SSL Certificate and Keys](SSL 証明書とキーのインポート) ダイアログが開きます

  5. PKCS 12 (IIS) を選択して、証明書と秘密キーをインポートします。 プロビジョニングが完了したら、ブラウザー タブを閉じて、メイン タブに戻ります。

    Easy Button の構成のスクリーンショット - 新しい証明書をインポートする

  6. [Enable Encrypted Assertion](暗号化アサーションを有効にする) をオンにします

  7. 暗号化を有効にした場合は、[Assertion Decryption Private Key](アサーション解読秘密キー) の一覧から証明書を選択します。 これは、Microsoft Entra アサーションを解読するために BIG-IP APM で使用される証明書の秘密キーです。

  8. 暗号化を有効にした場合は、[Assertion Decryption Certificate](アサーション解読証明書) の一覧から証明書を選択します。 これは、発行された SAML アサーションを暗号化するために BIG IP が Microsoft Entra ID にアップロードする証明書です。

    サービス プロバイダーの [Security Settings]\(セキュリティ設定) のスクリーンショット

マイクロソフト エントラ ID

このセクションでは、Microsoft Entra テナント内で新しい BIG-IP SAML アプリケーションを手動で構成するために通常使用するすべてのプロパティを定義します。 Easy Button には、Oracle PeopleSoft、Oracle E-business Suite、Oracle JD Edwards、SAP ERP、その他のアプリ用の汎用 SHA テンプレート用の定義済みアプリケーション テンプレートのセットが用意されています。

このシナリオでは、[Azure の構成] ページで、[Oracle E-Business Suite]>[追加] を選択します。

Azure の構成

[Azure の構成] ページで、次の手順を実行します。

  1. [構成プロパティ] で、BIG-IP が Microsoft Entra テナントに作成するアプリの表示名を入力し、MyApps ポータルに表示するアイコンを指定します。

  2. [Sign On URL](サインオン URL)(オプション) で、セキュリティで保護されている EBS アプリケーションのパブリック FQDN と、Oracle EBS ホームページの既定のパスを入力します

    [Azure Configuration]\(Azure の構成\) のスクリーンショット - 表示情報を追加する

  3. [署名キー] と [署名証明書] の横にある更新アイコンを選択して、先ほどインポートした証明書を見つけます

  4. [署名キーのパスフレーズ] に証明書のパスワードを入力します。

  5. [署名オプション] (省略可能) を有効にします。 これにより、BIG-IP は、Microsoft Entra ID によって署名されたトークンと要求のみを受け入れるようになります

    [Azure Configuration]\(Azure の構成\) のスクリーンショット - 署名証明書情報を追加する

  6. ユーザーとユーザー グループは、Microsoft Entra テナントから動的に照会され、アプリケーションへのアクセスを承認するために使用されます。 後でテストに使用できるユーザーまたはグループを追加します。それ以外の場合は、すべてのアクセスが拒否されます

    [Azure Configuration]\(Azure の構成\) のスクリーンショット - ユーザーとグループを追加する

ユーザー属性と要求

ユーザーが正常に認証されると、Microsoft Entra ID は、ユーザーを一意に識別する要求と属性の既定のセットを使用して SAML トークンを発行します。 [ユーザー属性と要求] タブには、新しいアプリケーションに対して発行する既定の要求が表示されます。 また、さらに多くの要求を構成することもできます。

[ユーザー属性と要求] のスクリーンショット

必要に応じて、追加のMicrosoft Entra 属性を含めることができますが、Oracle EBS シナリオでは既定の属性のみが必要です。

追加のユーザー属性

[追加のユーザー属性] タブでは、セッション拡張のために、他のディレクトリに格納されている属性を必要とする、さまざまな分散システムをサポートできます。 次に、LDAP ソースからフェッチされた属性を追加の SSO ヘッダーとして挿入して、ロール、パートナー ID などに基づいてアクセスをさらに制御できます。

  1. [Advanced Settings](詳細設定) オプションを有効にします

  2. [LDAP Attributes](LDAP 属性) チェック ボックスをオンにします

  3. [Choose Authentication Server](認証サーバーの選択) で [Create New](新規作成) を選択します

  4. 実際の設定に応じて、[Use pool](プールを使用) または [Direct](直接) サーバー接続モードを選択します。 これにより、ターゲット LDAP サービスの [Server Address](サーバーアドレス) が指定されます。 単一の LDAP サーバーを使用する場合は、[Direct](直接) を選択します。

  5. [Service Port](サービス ポート) に、3060 (既定値)、3161 (セキュア)、または Oracle LDAP サービスが動作するその他のポートを入力します

  6. 検索に使用するベース検索 DN (識別名) を入力します。 この検索 DN は、ディレクトリ全体でグループを検索するために使用されます。

  7. [Admin DN](管理者の DN)に、APM で LDAP クエリの認証に使用されるアカウントの正確な識別名を、パスワードと共に設定します

    [Additional User Attributes]\(追加のユーザー属性\) のスクリーンショット

  8. 既定のすべての [LDAP Schema Attributes](LDAP スキーマ属性) をそのまま使用します

    LDAP スキーマ属性のスクリーンショット

  9. [LDAP Query Properties](LDAP クエリのプロパティ) で、 [Search Dn](検索 Dn) にユーザー オブジェクトを検索する LDAP サーバーのベース ノードを設定します

  10. LDAP ディレクトリから返される必要があるユーザー オブジェクト属性の名前を追加します。 EBS の場合、既定値は orclguid です

    LDAP クエリ properties.png のスクリーンショット

条件付きアクセス ポリシー

条件付きアクセス ポリシーは、デバイス、アプリケーション、場所、リスクの兆候に基づいてアクセスを制御するために、Microsoft Entra の事前認証後に適用されます。

既定では、[ 使用可能なポリシー] ビューには、ユーザーベースのアクションを含まないすべての条件付きアクセス ポリシーが一覧表示されます。

[選択されたポリシー] ビューには、既定で、すべてのリソースをターゲットとするすべてのポリシーが表示されます。 これらのポリシーは、テナント レベルで適用されるため、選択を解除したり、[使用可能なポリシー] リストに移動したりすることはできません。

公開されているアプリケーションに適用するポリシーを選択するには:

  1. [Available Policies](使用可能なポリシー) リストで目的のポリシーを選択します

  2. 右矢印を選択して、これを [Selected Policies](選択されたポリシー) リストに移動します

    選択されたポリシーについては、[含める] または [除外する] オプションをオンにする必要があります。 両方のオプションをオンにすると、ポリシーは適用されません。

    条件付きアクセス ポリシーのスクリーンショット

注

ポリシーの一覧は、最初にこのタブに切り替えたときに 1 回だけ列挙されます。ウィザードから手動でテナントにクエリを実行するための更新ボタンが用意されていますが、このボタンはアプリケーションがデプロイされている場合にのみ表示されます。

仮想サーバーのプロパティ

仮想サーバーは BIG-IP データ プレーン オブジェクトであり、アプリケーションに対するクライアント要求をリッスンする仮想 IP アドレスで表されます。 受信したトラフィックは、ポリシーの結果と設定に従って送信される前に、仮想サーバーに関連付けられている APM プロファイルに対して処理および評価されます。

  1. 宛先アドレスを入力します。 これは、BIG-IP がクライアント トラフィックを受信するために使用できる任意の IPv4 または IPv6 アドレスです。 対応するレコードが DNS にも存在する必要があり、それによってクライアントでは、BIG-IP の公開済みアプリケーションの外部 URL を、アプリケーション自体ではなく、この IP に解決できるようになります。 テストでは、テスト PC の localhost DNS を使用しても問題ありません。

  2. [Service Port](サービス ポート) で、HTTPS 用に「443」と入力します

  3. [Enable Redirect Port](リダイレクト ポートを有効にする) をオンにし、リダイレクト ポートを入力します。 これにより、受信 HTTP クライアント トラフィックが HTTPS にリダイレクトされます

  4. クライアント* SSL* プロファイル*を使用すると、HTTPS* 用の仮想サーバー*が有効になり、クライアント*接続が TLS* で暗号化されるようになります。 前提条件の一部として作成したクライアント* SSL* プロファイル*を選択するか、テスト*する場合は既定値*のままにします

    仮想サーバーのスクリーンショット

プールのプロパティ

[Application Pool](アプリケーション プール) タブには、1 つまたは複数のアプリケーション サーバーを含むプールとして表される、BIG-IP の背後にあるサービスの詳細が表示されます。

  1. [Select a Pool](プールの選択) から選択します。 新しいプールを作成するか、既存のプールを選択します

  2. [Load Balancing Method](負荷分散方法) で、[Round Robin](ラウンド ロビン) を選択します

  3. [プール サーバー] では、既存のノードを選択するか、Oracle EBS アプリケーションをホストするサーバーの IP とポートを指定します。

    [Application Pool]\(アプリケーション プール\) のスクリーンショット

  4. [Access Gate Pool](アクセス ゲート プール) は、Oracle EBS で SSO 認証済みユーザーを Oracle E-Business Suite セッションにマッピングするために使用するサーバーを指定します。 アプリケーションをホストする Oracle アプリケーション サーバーの IP およびポートで [Pool Servers](プール サーバー) を更新します

    AccessGate プールのスクリーンショット

シングル サインオン & HTTP ヘッダー

Easy Button ウィザードでは、公開されたアプリケーションに対する SSO 用に、Kerberos、OAuth Bearer、HTTP Authorization ヘッダーがサポートされています。 Oracle EBS アプリケーションではヘッダーが要求されるため、 [HTTP Headers](HTTP ヘッダー) を有効にし、次のプロパティを入力します。

  • ヘッダー操作: 置換

  • ヘッダー名: USER_NAME

  • ヘッダー値: %{session.sso.token.last.username}

  • ヘッダー操作: 置換

  • ヘッダー名: USER_ORCLGUID

  • ヘッダー値: %{session.ldap.last.attr.orclguid}

    SSO と HTTP ヘッダーのスクリーンショット

注

中かっこ内で定義されている APM セッション変数は、大文字と小文字が区別されます。 たとえば、Microsoft Entra の属性名が orclguid として定義されている場合に「OrclGUID」と入力すると、属性マッピング エラーが発生します

セッションの管理

BIG-IP のセッション管理の設定は、ユーザー セッションが終了されるか続行が許可される条件、ユーザーと IP アドレスの制限、および対応するユーザー情報を定義するために使用されます。 これらの設定の詳細については、F5 のドキュメントを参照してください。

しかし、ユーザーがサインオフするときに IdP、BIG-IP、およびユーザー エージェント間のすべてのセッションが確実に終了されるようにする、シングル ログアウト (SLO) 機能についての説明はここにはありません。 Easy Button によって SAML アプリケーションが Microsoft Entra テナントでインスタンス化されると、ログアウト URL にも、APM の SLO エンドポイントが設定されます。 このように、Microsoft Entra マイ アプリ ポータルからの IdP Initiated サインアウトでは、BIG-IP とクライアント間のセッションも終了します。

これに加え、テナントから公開済みアプリケーションの SAML フェデレーション メタデータもインポートされて、APM に Microsoft Entra ID の SAML ログアウト エンドポイントが提供されます。 これにより、SP Initiated サインアウトでクライアントと Microsoft Entra ID との間のセッションが確実に終了するようになります。 しかし、これを真に効果的に行うには、APM で、ユーザーがいつアプリケーションからサインアウトしたのかを正確に知る必要があります。

BIG-IP Web トップ ポータルを使用して公開済みアプリケーションにアクセスする場合は、そこからのサインアウトが APM によって処理され、Microsoft Entra サインアウト エンドポイントも呼び出されます。 しかし、BIG-IP Web トップ ポータルが使用されていないために、サインアウトするようにユーザーが APM に指示する方法がないシナリオについて考えてみます。ユーザーがアプリケーション自体からサインアウトした場合でも、BIG-IP では技術的にはこれが認識されません。 このため、SP によって開始されるサインアウトでは、セッションが不要になったときに確実に安全に終了されるように、慎重に検討する必要があります。 これを実現する 1 つの方法は、SLO 関数をアプリケーションのサインアウト ボタンに追加して、クライアントを Microsoft Entra SAML または BIG-IP サインアウト エンドポイントにリダイレクトできるようにすることです。 テナントの SAML サインアウト エンドポイントの URL については、[アプリの登録] > [エンドポイント] で確認できます。

アプリに変更を加えることができない場合は、BIG-IP でアプリケーションのサインアウト呼び出しをリッスンし、要求を検出したら SLO をトリガーすることを検討してください。 これを実現するための BIG-IP iRules の使用については、Oracle PeopleSoft SLO ガイダンスを参照してください。 これを実現するための BIG-IP iRules の使用の詳細については、F5 のナレッジ記事「URI 参照ファイル名に基づく自動セッション終了 (ログアウト) の構成」および「ログアウト URI インクルード オプションの概要」を参照してください。

まとめ

この最後の手順では、構成の内容を示します。 [デプロイ] を選択してすべての設定をコミットし、エンタープライズ アプリケーションのテナント リストにアプリケーションが存在することを確認します。

関連コンテンツ

ブラウザーから Oracle EBS アプリケーションの外部 URL に接続するか、Microsoft MyApps ポータルでアプリケーションのアイコンを選択します。 Microsoft Entra ID に対する認証が完了すると、アプリケーションの BIG-IP 仮想サーバーにリダイレクトされ、SSO を使用して自動的にサインインされます。

このパターンを使用する組織では、セキュリティを強化するため、アプリケーションへのすべての直接アクセスをブロックすることで、BIG-IP 経由の厳密なパスを強制することもできます。

詳細なデプロイ

ガイド付き構成テンプレートには、より具体的な要件を実現するための柔軟性が足りない場合があります。 そうしたシナリオの場合は、ヘッダーベースの SSO の詳細構成に関するページを参照してください。 また、BIG-IP には、ガイド付き構成の厳格な管理モードを無効にするオプションが用意されています。 これにより、ウィザード ベースのテンプレートを使用して構成の大部分を自動化する場合でも、構成を手動で調整できるようになります。

[アクセス] > [ガイド付き構成] の順に移動して、アプリケーションの構成の行の右端にある小さな南京錠アイコンを選択します。

Easy Button の構成のスクリーンショット - 厳密な管理

その時点で、ウィザード UI を使用した変更はできなくなりますが、アプリケーションの発行済みインスタンスに関連付けられているすべての BIG-IP オブジェクトは、直接管理のためにロック解除されます。

注

厳格なモードを再度有効にして構成をデプロイすると、ガイド付き構成の UI 外部で実行した設定はすべて上書きされるため、運用サービスに対しては、詳細構成の方式をお勧めします。

トラブルシューティング

さまざまな要因により、SHA によって保護されたアプリケーションにアクセスできない場合があります。 BIG-IP のログは、接続、SSO、ポリシー違反、正しく構成されていない変数マッピングなど、あらゆる種類の問題をすばやく区別するのに役立つ可能性があります。 ログの詳細レベルを上げることでトラブルシューティングを開始します。

  1. [Access Policy](アクセス ポリシー) > [Overview](概要) > [Event Logs](イベント ログ) > [Settings](設定) に移動します

  2. 公開されたアプリケーションの行を選択し、[Edit](編集) > [Access System Logs](システム ログへのアクセス) を選択します

  3. SSO の一覧から [Debug](デバッグ) を選択して、[OK] を選択します

問題を再現してからログを検査しますが、詳細モードでは大量のデータが生成されるため、終了したら忘れずに、これを元に戻してください。

Microsoft Entra 事前認証が成功した直後に、BIG-IP ブランドのエラーが表示される場合は、Microsoft Entra から BIG-IP への SSO に関連する問題が発生している可能性があります。

  1. [Access](アクセス) > [Overview](概要) > [Access reports](レポートへのアクセス) に移動します。

  2. 過去 1 時間のレポートを実行して、ログに手がかりがないかどうかを確認します。 セッションに対する [セッションの表示] 変数リンクも、APM が Microsoft Entra ID から予想される要求を受信しているかどうかを把握するのに役立ちます。

BIG-IP のエラー ページが表示されない場合、問題は、バックエンド要求や、BIG-IP からアプリケーションへの SSO に関係している可能性が高くなります。

  1. その場合は、[アクセス ポリシー] > [概要] > [アクティブ セッション] の順に進み、アクティブ セッションのリンクを選択します

  2. この場所にある [View Variables] (変数の表示) リンクも、SSO の問題、特に BIG-IP APM で Microsoft Entra ID または別のソースから適切な属性を取得できない場合に、根本的な原因を特定するのに役立つことがあります。

詳細については、BIG-IP APM 変数の割り当ての例と F5 BIG-IP セッション変数リファレンスを参照してください。

Bash シェルから次のコマンドを実行すると、LDAP クエリに使用される APM サービス アカウントを検証し、ユーザー オブジェクトを正常に認証および照会できます。

ldapsearch -xLLL -H 'ldap://192.168.0.58' -b "CN=oraclef5,dc=contoso,dc=lds" -s sub -D "CN=f5-apm,CN=partners,DC=contoso,DC=lds" -w 'P@55w0rd!' "(cn=testuser)"

詳細については、F5 のナレッジ記事「Active Directory の LDAP リモート認証の構成」を参照してください。 また、この LDAP クエリに関する F5 のナレッジ記事には、LDAP 関連の問題の診断に役立つ優れた BIG-IP 参照テーブルもあります。