※本記事は、Paul Toalによる”Troubleshooting User Access in Identity Cloud Service when using AD Bridge“を翻訳したものです。
June 10, 2020
これまで、Oracle Identity Cloud Service（Oracle IDCS）でActive Directory（AD）Bridgeを使用してユーザーとグループをOracle IDCSに同期する方法について詳しく説明してきました。たとえば、こちらの記事ではADユーザーのサブセットの同期について語っています。
注：Oracle IDCSはAzureも完全にサポートしています。このシナリオではAD Bridgeは使用されず、業界のオープン標準であるSCIMインタフェースがAzureとOracle IDCSの間で使用されます。一方、ADはSCIMをサポートしていないため、AD Bridgeが使用されます。
AD（またはAzure AD）からOracle IDCSへのユーザーの同期はよくある要件であり、一般的には、ADからADFS経由でOracle IDCSへのシングル・サインオン（SSO）を可能にするために、フェデレーションと共に使用されます。AD Bridgeのセットアップは、Oracle IDCSとADFSの間にフェデレーションをセットアップするのと同様に、非常に簡単です。以下の図に示すとおり、単純な2段階のプロセスで構成できます。これらについては、こちらとこちらのチュートリアルで説明しています。
先日、あるお客様から相談を受けました。そのお客様のシナリオでは、上記のデプロイメントで（ただし、ADFSではなくAzureがアイデンティティ・プロバイダである）、さらにE-Business Suite（EBS）をOracle IDCSと統合して、AzureからEBSまで全体的なSSOを実現しています。正常な状態であれば、ユーザー・フローはシームレスです。ユーザーは認証済みユーザーとしてEBSに戻るまで、AzureについてもOracle IDCSについても知ることはありません（この2つの間で透過的に移動させられるため）。しかし、一部のユーザーで、このフローの途中にエラーが発生する問題がある、ということでした。そのお客様からは、この問題のトラブルシューティングを依頼されました。
私はお客様と一緒にいくつかの共通の手順を実行し、すぐにその問題を特定しました。ここでは、同じような問題を抱えている方やOracle IDCSのトラブルシューティングの構造化手法を知りたい方のために、このトラブルシューティングのプロセスを共有したいと思います。
それでは、問題の説明から始めましょう。私の環境にこの問題の状況を再現し、テスト・ユーザーとしてukuser2@emeacp.comを使用することにします。このユーザーには以下の画面が表示されます。
先ほど説明したとおり、ユーザーにはAzure/ADFS、Oracle IDCSのいずれの画面も表示されるべきではありません。シームレスでなければならず、今の状態には問題があります。この問題を特定するために私がとった手順を詳しく見ていきましょう。
ステップ1 – ログイン失敗レポート
まず、明らかに調査すべき場所はログイン失敗レポートです。ここで、ログインに失敗したユーザーが、失敗したログインおよび考えられる理由とともに記録されているかを確認します。Oracle IDCS管理コンソールで、次の場所に移動します。
「Reports」→「Unsuccessful Login Attempts」
これを見る限り、ユーザーukuser2@emeacp.comに関する情報は何もありません。
ステップ2 – ユーザーが存在するか
上記のレポートにはログインに失敗したユーザーが表示されなかったため、Oracle IDCSがそのユーザーについて知らないのではないかと私は考えました。そのため、次のステップとして、このユーザーが実際にOracle IDCSに存在するかを確認します。同じ管理コンソール内で、「Users」に移動し、このユーザーを検索します。
ややこしいことになってきました。認証を試みたユーザーはOracle IDCSに存在しません。このことは、認証できなかった理由の説明にはなりますが、なぜユーザーが存在しないのかという新たな疑問が生まれました。ADユーザーがAD Bridgeと同期されていることは分かっていますので、AD Bridgeの構成が正しくないのかもしれません。フィルタによって、必要なユーザーのオブジェクトが除外されているのかもしれません。
ステップ3 – AD Bridgeの構成
そのため、次に調査する領域はAD Bridgeの構成ということになります。私の環境では、AD構造は以下のようにかなり分かりやすくなっています。
AD Bridgeの構成はOracle IDCS管理コンソール内で実行するため、このコンソールの以下の場所が次の調査対象です。
「Settings」→「Directory Integrations」
以下のように、AD Bridgeは正しく構成され、動作しています。
次にフィルタを確認する必要があります。上のエントリをクリックして、その構成に移動します。
ここでは、UKとFranceのOUを選択しており、特定のユーザーを除外する可能性のある固有のフィルタは存在しないことが分かります。また、Global OUの下ですべてのグループを同期しています。いずれのケースでも、ネストされたOUがある場合に備え、「Include Hierarchy」をチェックしています。
ここまでの話をまとめましょう。ユーザーukuser2は、UK OU内のAD内に存在しています。AD BridgeはそのOUを同期するように構成されていますが、ukuser2はOracle IDCSにインポートされていません。
では、ユーザーのADレコードに問題があるのでしょうか。
ステップ4 – AD Bridgeのログ
AD Bridgeのスコープは正しいのに、必要なユーザー・レコードがOracle IDCSに同期されていないことを確認しましたので、調査の範囲をAD Bridgeに広げる必要があります。AD Bridgeは、ユーザー・アカウントを取得するためにADと相互作用するコンポーネントであるからです。
AD Bridgeを実行しているWindowsサーバーに接続して、以下のAD Bridge UIを起動します。
C:\Program Files\Oracle\IDBridge\IDBridgeUI.exe
AD Bridgeが実行中であることが確認できます。
ログを確認して、問題を特定しましょう。「
」をクリックすると、AD Bridgeのログ・ファイルが保存されたフォルダに移動できます。
メモ帳（またはお好きなエディタ）でIDBridge.logを開きます。このログ・ファイルには多数の行が含まれているため、最初に問題を探すための簡単な方法として、ファイルの最後までスクロールしてから上方向に「Error」を検索します。
問題がヒットしました。ログ・ファイルは以下のように表示されています。
ERROR IDBridge – Failed to create/update User ‘CN=UK User2,OU=UK,OU=Europe,OU=Global,DC=emeacp,DC=com’ with error code 400.
Error message: error.identity.user.invalidPhoneValFormat : The format of the phone number (+44) 078 123 4544 you entered is invalid. Make sure that the format is compliant with national and international standards.
ukuser2のADレコードを調査すると、確かに無効な電話番号になっています。
丸括弧を削除して、正しい形式に修正しましょう。
次の同期のスケジュール実行まで待つことも、即時同期を実行することもできます。ここでは、私が待ちきれないので即時同期を実行することにします。Oracle IDCS管理コンソールのAD Bridge構成画面が開いたままですので、その画面で「 
」ボタンをクリックします。
前回の同期以降の変更のみを反映するため、「Incremental Import」を選択します。
さらに、この同じAD Bridge構成画面のImportタブからジョブを監視します。少し時間が経つと、1つのユーザー・レコードがインポートされたことを確認できます。
Usersのクイック検索によって、ukuser2がOracle IDCSにインポートされたことが分かります。これで、サインインの問題は解消されました。このユーザーはEBSに問題なくサインインできるようになりました。
このように電話番号の形式が無効であるというケース以外にも、たとえば以下のように、必須の属性が不足しているという問題が起きる可能性もあります。
ERROR IDBridge – Failed to create/update User ‘CN=UK User3,OU=UK,OU=Europe,OU=Global,DC=emeacp,DC=com’ with error code 400.
Error message: error.identity.user.primaryEmailNotSpecified : The primary email must be specified.
しかし、いずれの場合も、AD Bridgeログ・ファイルのエラーを確認することで、正しい方向に進むことができます。先ほどのお客様の例では、電話番号に問題があってそれを修正した後、さらに別のユーザーでいくつかの属性が不足していることがログで判明し、存在しないユーザー約6人分のOracle IDCSへの同期が開始されました。
その他のトラブルシューティング
この記事を書いている以上、Oracle IDCSの問題のトラブルシューティングに便利なツールであるDiagnosticログを紹介しないわけにはいきません。
もう1つ簡単な例を見てみましょう。同じ環境を使用して、franceuser1@emeacp.comというユーザー名でログインしようとすると、ukuser2のときと同じエラー画面が表示されました。前述のすべてのチェック項目を確認し、このユーザーはOracle IDCS内に存在しています。
そのため今回は、ユーザーが明らかにOracle IDCSに存在し、ADFSからのSAMLアサーションによって情報を送信されているはずなのにOracle IDCSで認証できない理由を把握する必要があります。このようなケースでDiagnosticのログが役に立ちます。
Diagnosticsを使用するには、有効化する必要があります。Oracle IDCS管理コンソールで、以下の項目を選択します。
「Settings」→「Diagnostics」
各項目の説明のとおり、いずれかの診断を有効化すると、診断がその時点から15分間有効になり、問題を再現できるようになります。有効化する診断のレベルについてはユーザーが指定します。私は通常は「Service View」を有効化します。最も多くのデータを取得して、結果のCSVファイルを簡単にフィルタリングできるからです。
レベルを選択して「
」ボタンで保存したら、すぐに問題の再現に取り掛かってください。この例では、franceuser1での再ログインを試みました。テストの実行後、以下の場所から診断用の出力ファイルをダウンロードします。
「Reports」→「Diagnostic Data」
ここでは「15 minutes」の間隔と「Service View」を選択してください。これでCSVがローカルのデスクトップにダウンロードされます。このファイルを開いて、問題の調査を始めましょう。私のシナリオでは、ADFSから送り返されるSAMLアサーションに問題があることがかなり早い段階で明らかになりました。この問題は以下のログで特定されています。
すぐにテスト用のブラウザに戻り、テストを再実行することで、Web DeveloperツールでADFSからのSAMLレスポンスを記録できました。このレスポンス内に以下の記述が確認できます。
この例では、問題はADFS側にあるようです。ADFSで調査を行ったところ、私の環境内のフランスのユーザーがOracle IDCSへのフェデレーションを許可されていないようでした。これは、ADFS Access Control Policyに定義されています。そのため、ADFSは上記のとおりRequestDeniedステータス・コードを送り返しています。
この記事が、Oracle IDCSのトラブルシューティングの際に実行すべき論理的手順を理解するためのお役に立てば幸いです。