AD Bridge使用時のIdentity Cloud Serviceでのユーザーアクセスのトラブルシューティング (2020/06/10)

https://blogs.oracle.com/cloudsecurity/troubleshooting-user-access-in-identity-cloud-service-when-using-ad-bridge
投稿者：Paul Toal | Distinguished Solution Engineer - Cyber Security

以前の記事では、Oracle Identity Cloud Service (IDCS) が
Active Directory (AD) ブリッジを使用して IDCS にユーザーとグループを同期させる方法について詳しく説明しました。
たとえば、この記事では、ADユーザーのサブセットを同期する方法について説明します。

IDCSはAzureも完全にサポートしていることに注意してください。
そのシナリオでは、ADブリッジは使用されず、代わりに業界標準のオープンスタンダードのSCIMインターフェースがAzureとIDCSの間で使用されます。
ADはSCIMをサポートしていないので、ADブリッジが使用されます。

AD（またはAzure AD）からIDCSにユーザーを同期することは、
一般的な要件であり、ADFSを介してADからIDCSへのシングルサインオン（SSO）を可能にするために、
一般的にフェデレーションと一緒に使用されます。ADブリッジのセットアップは、
IDCSとADFS間のフェデレーションのセットアップと同様に、本当に簡単です。
下の図に示すように、設定するのは簡単な2段階のプロセスで、こことここのチュートリアルで説明されています。

最近、ある顧客が問題を抱えて私に連絡してきた。彼らのシナリオでは、
上記の展開（ただし、AzureはIDプロバイダであり、ADFSではない）で、
E-Business Suite (EBS)もIDCSと統合されており、AzureからEBSに至るまでSSOを可能にしています。
通常の状況では、ユーザーの流れはシームレスです。
ユーザーは、認証されたユーザーとしてEBSに戻される前に、AzureとIDCSの間を透過的にバウンドするので、AzureとIDCSのどちらも見ていません。
しかし、このフロー中にエラーが発生する一部のユーザーに問題がありました。
彼らは、問題をトラブルシューティングするために私の助けを求めてきました。

私は彼らといくつかの一般的なステップを経て、すぐに問題を特定しました。
同じような問題を抱えている場合や、IDCS をトラブルシューティングするための構造化されたアプローチが必要な場合に備えて、
私のトラブルシューティング・プロセスを共有することが役立つかもしれないと考えました。

問題から始めましょう。私の環境で問題を複製し、ukuser2@emeacp.com をテストユーザーとして使用しています。
このユーザーには以下のような画面が表示されています。

さて、前に言ったことを思い出してみると、ユーザーはAzure/ADFSやIDCSの画面を見るべきではありません。
それは彼らのためにシームレスでなければなりません。
これで、問題があることがわかりました。問題を特定するために私が取った手順を調べてみましょう。

ステップ1 - ログインレポートの失敗

最初に見るべき明白な場所は、失敗したログインレポートで、失敗したログインで失敗したユーザーが表示されているかどうか、
また、潜在的な理由があるかどうかを確認するための失敗したログインレポートです。
IDCS管理者コンソール内で以下に移動します。

レポート -> ログイン失敗の試み

うーん、私のユーザーは何もありません: ukuser2@emeacp.com。

ステップ2 - ユーザーは存在しますか?

上記のレポートには失敗したユーザーが表示されていなかったので、IDCSはユーザーについて知らないことを示唆しています。
そこで、次のステップでは、ユーザーが実際にIDCSに存在するかどうかを確認します。
まだ管理者コンソール内のユーザーに移動し、ユーザーを検索します。

筋書きが濃くなってきた! 認証しようとしているユーザはIDCSには存在しません。
それは彼らが認証できない理由を説明するでしょうが、なぜ彼らが存在しないのかという疑問にもつながります。
ADユーザーがADブリッジと同期されていることを知っているので、おそらくADブリッジの設定が正しくないのでしょう。
おそらくそのフィルタには、私のユーザーに必要なオブジェクトが含まれていないのでしょう。

ステップ3 - ADブリッジの設定

そこで、私の次の調査分野は、ADブリッジの構成です。
私の環境では、以下に示すように、私のADの構成はかなり単純です。

ADブリッジの設定はIDCS Admin Console内で行われます。

Settings -> Directory Integrations

私のADブリッジが設定され、正常に動作していることがわかります。

次にフィルターを見てみましょう。
上のエントリをクリックすると設定画面に入ります。

ここでは、英国とフランスのOUが選択されていて、特定のユーザーを除外するような特定のフィルタがないことがわかります。
また、グローバルOUの下にあるすべてのグループを同期しています。
どちらの場合も、入れ子になったOUがある場合に備えて、[階層を含める]にチェックを入れています。

現在の状況を確認してみましょう。
私のユーザーである ukuser2 は、UK OU の AD 内に存在しています。
ADブリッジはそのOUを同期するように設定されていますが、ukuser2はIDCSにインポートされていません。

ユーザーのADレコードに問題があるのでしょうか？

ステップ4 - ADブリッジログ

AD Bridgeが正しいスコープを持っているにも関わらず、
必要なユーザーレコードがIDCSに同期されていないことがわかるので、AD Bridge自体に調査を広げる必要があります。

AD Bridgeを実行しているWindowsサーバーに接続して、AD Bridge UIを起動します。

C:I:Grogram FilesOracleOracle\IDBridgeIDBridgeIDBridgeUI.exe

ADブリッジが稼働していることがわかります。

ログを見て、何か問題がないか確認してみましょう。
クリックすると、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.identity.user.invalidPhoneValFormat . 入力した電話番号（+44）078 123 4544の形式が無効です。フォーマットが国内および国際規格に準拠していることを確認してください。

ukuser2のADレコードを調べると、確かに無効な電話番号が表示されています。

括弧を外して修正しましょう。

さて、次の予定された同期を待つか、即時同期を強制するかのどちらかです。
私の場合、せっかちなので即時同期を強制します。
まだIDCS Admin ConsoleのAD Bridge設定画面内で、私はボタンをクリックします。

インクリメンタルインポートを選択して、最後に同期した時からの変更だけを取り込むようにしています。

そして、同じAD Bridgeの設定画面のImportタブからジョブを監視してみます。
しばらくすると、1ユーザレコードがインポートされたことがわかります。

Usersを素早く検索すると、ukuser2がIDCSにインポートされ、サインインの問題が解消されたことが確認できます。
これでEBSにサインインできるようになりました。

無効な電話番号のフォーマットであるとは限りません。
例えば、以下のように、必須属性が欠落している可能性があります。

ERROR IDBridge - User 'CN=UK User3,OU=UK,OU=Europe,OU=Global,DC=emeacp,DC=com' の作成/更新に失敗しました。

エラーメッセージ：error.identity.user.primaryEmailNotSpecified : プライマリ電子メールを指定する必要があります。

しかし、どちらの場合もAD Bridgeのログファイルのエラーが正しい方向を示してくれます。
私の最近の顧客のケースでは、電話番号が彼らの問題であり、
それを修正し、ログから識別された他のユーザーの他のいくつかの欠落した属性を修正した後、
彼らの半ダースかそこらの欠落したユーザーがIDCSに同期を開始しました。

その他のトラブルシューティング

ここにいる間に、IDCS の問題をトラブルシューティングするための本当に便利なツール、
診断ログについて言及しないのはもったいないでしょう。

もう一つ、簡単な例を挙げてみましょう。
同じ環境で franceuser1@emeacp.com でログインしようとしていますが、ukuser2 と同じエラー画面が表示されます。
上記のチェックを全て行い、IDCSにユーザーが存在することを確認しました。

そこで今回は、IDCS がユーザーが明らかに存在する場合にユーザーを認証できない理由を理解する必要があり、
したがって ADFS から SAML アサーションを使用している必要がある。
ここでDiagnostic loggingが役に立つ。

Diagnostics を使用するには、Diagnostics を有効にする必要がある。
IDCS管理者コンソールで、以下のように選択する。

「Settings」→「Diagnostics」を選択する。

説明にあるように、いずれかの診断を有効にすると、次の15分間は有効になり、問題を再現できるようになります。
それはあなたが有効にする診断のレベルまでです。
私は通常、データのほとんどの量を取得し、結果のCSVファイルをフィルタリングするのは簡単ですので、サービスビューを有効にします。

レベルを選択し、ボタンを使用して保存すると、問題を再現することができます。
私の場合は、franceuser1で再ログインを試みました。
テストが完了したら、診断出力をダウンロードします。

レポート -> 診断データ

15分の時間範囲とサービスビューが選択されていることを確認してください。
これでCSVがローカルデスクトップにダウンロードされます。
ファイルを開くと、問題を探し始めることができる。
私のシナリオでは、ADFS から送信された SAML アサーションに問題があったことがかなり早く明らかになり、ログにこれがあることがわかる。

テストブラウザに戻って、テストを再実行して、
Web Developer ツールが ADFS から SAML レスポンスをキャプチャできるようにしたところ、レスポンスの中にこのようなものが表示されました。

この場合、問題はADFS側にあるようです。
ADFS内で調査した結果、私の環境内のフランスのユーザーは、
ADFSアクセス制御ポリシーで定義されているように、IDCSにフェデレートすることが許可されていないようです。

これがIDCSのトラブルシューティングの際に、論理的な一連のステップを理解するのに役立つ読み物になっていることを願っています。