こちらは Enterprise Mobility + Security（EMS） Advent Calendar 2021 に参加しています。Japan EMS Users Groupもご覧になってください。
--
AzureADでSSOする構成したとあるクラウドアプリを、iOSモバイルアプリから利用する際の条件付きアクセスの構成でやられましたので、まとめてみました。
条件付きアクセスに設定を見直ししたらアプリにサインインできなくなりました。
サインインログに表示されているアプリケーションだけでなく、リソースとして表示されているエンタープライズアプリも確認しましょう、というお話です。
アプリという言葉がいろいろややこしいので、便宜上このようにしています。
- クラウドアプリ・・・サービス側。SaaS。
- モバイルアプリ・・・iPhoneにインストールしているアプリ
- エンタープライズアプリ・・・AzureADのエンタープライズアプリケーションに登録したアプリ
クラウドアプリ概要
とある国内ベンダーのクラウドアプリです。
ブラウザ利用もできますが、モバイルアプリで使うことを前提としている、とても便利なアプリです。アプリ構成ポリシーにも対応されていて、機能面も管理面にも素晴らしいエクスペリエンスを提供されていると思っています。
認証認可は、M365とシングルサインオンで構成しています。(SAMLではありません）
ちなみに、ブラウザの場合は、AADのログイン画面にリダイレクトされる挙動ですが、
iOSのモバイルアプリで利用する場合は Microsoft Authenticator アプリにリダイレクトされるという挙動です。
条件付きアクセスも構成しています。
SSOを構成する際、提供元のマニュアルに従って作成したところ、クラウドアプリ名ではなく、「スマートフォン用シングルサインオンアプリ」という名前でエンタープライズアプリに登録されていて、条件付きアクセスもこの名前のアプリを登録しています。
条件付きアクセスを見直ししようとした背景
このクラウドアプリとは直接関係ないのですが、SSOしているクラウドアプリや、Azure AD App Proxy で利用しているアプリが増えてきたので、条件付きアクセスの構成を見直しすることにしました。
これまではエンタープライズアプリに追加する都度、条件付きアクセスにアプリを追加していました。当然、アプリを追加するたびに、条件付きアクセスに追加しなければなりませんので手間ですし、抜け漏れなどのセキュリティ上の問題も発生します。
これを
- デフォルト設定ですべてのアプリを厳しめの条件付きアクセス（準拠済みデバイスかつ承認済みアプリのみ許可）で設定し、
- 一部のアプリのみを緩めの条件付きアクセス（準拠済みデバイスで許可）で設定する
という構成に変更することを計画しました。
やらかしたこと
Azure AD 管理センターで先ほどのクラウドアプリのログイン履歴を見たところ、冒頭の通り「スマートフォン用シングルサインオンアプリ」という名前でエンタープライズアプリに登録されていることを確認しています。
というわけで、先の計画の通りデフォルト設定を作成し、こちらのアプリは緩めの条件付きアクセスに追加したのですが、モバイルアプリから、このクラウドアプリにサインインできなくなりました（条件付きアクセスでブロックされた）
その原因は、「リソース」に表示されているエンタープライズアプリ
iOSのモバイルアプリからログインした場合は「スマートフォン用シングルサインオンアプリ」としてログが出ています。（先ほどの通り）
普段は利用しないのですが、PCでこのクラウドアプリをブラウザからサインインしたり、iOSのEdgeからサインインも試してみたところ、別名のアプリ（ブラウザ用シングルサインオンアプリ）としてログが出ています。
モバイルアプリ利用と、ブラウザ利用では、別のエンタープライズアプリとして登録されています。なので、意図した設定になっているはず！！なのに何故！？
スマートフォン用シングルサインオンアプリのサインインで失敗しているログの詳細を確認。条件付きアクセスの詳細を見ると、スマートフォン用シングルサインオンアプリだけでなく、ブラウザ用シングルサインオンアプリが記載されていることに気づきました。（この画像の、アプリケーションと、リソースの欄）
なぜこうなる？（アプリケーションとリソース）
- ブラウザ利用とモバイルアプリ利用で認証時の挙動が異なっている場合、AAD上には、ブラウザから利用する場合のアプリケーションと、モバイルアプリから利用するアプリケーションはそれぞれ別に登録される場合がある
- モバイルアプリから利用する場合、大本であるブラウザから利用する際のAADアプリ（今回だと、ブラウザ用シングルサインオンアプリ）をリソースとして参照する場合がある。
- 条件付きアクセスでは、AAD上のアプリケーションに加えて、リソースとして表示されているアプリも評価されてしまう
- リソースとして表示されているアプリも条件付きアクセスでブロックとして判定されると、アプリケーション側で認可されていてもブロックされる
このように考えるとつじつまが合います。（正しくない可能性もありますが）
まとめ
見直しする前の設定では、たまたまブラウザで利用するためのAAD上アプリに条件付きアクセスを割り当てていなかったため、結果的に使えていたのだと思います。（いろいろあって結果的に準拠済みデバイスでしか利用できない状態だったので、気付けていなかった）
これまでたまたまこの問題に遭遇しなかっただけなのかもしれませんが、「アプリケーションとリソース」を確認すべきという知見を得ることができました。
- モバイルアプリから利用させる場合は参照しているリソースを確認する
- リソースに別名のエンタープライズアプリが登録されている場合がある
- その場合は、アプリケーションとリソースに表示されるエンタープライズアプリの両方確認を条件付きアクセスに登録する
0 件のコメント:
コメントを投稿