Azure ADの「クロステナントのアクセス設定」（中編）
はじめに
下記の記事で「クロステナントのアクセス設定」について概要を確認しました。
また、「ゲスト招待は特定のAzureADテナント間のみに限りたい」という用途において、クロステナントのアクセス設定を施し、挙動を確認しました。
期待の制御ができることが確認できましたが、ちゃんと継続的に守れているのか、誰がどうアクセスしてて、それが許可/拒否されているかを見ていかないと安心することはできません。
そこで今回は「そのアクセスがどのように記録されているか」を見てみます。
（MFAの制御について検証する、と予告してましたが、先にこちらを…）
環境
前回検証した環境の再掲ですが、以下のような環境を考えてみます。
Directory Aに関連するサインインイベントで、アクセスが許可／拒否されるときにどのようにログが記録されるか見ていきます。
検証
アウトバウンド許可（User A ⇒ Direcory Bへのゲストアクセス）
以下のように記録されます。
UserAが、DirectoryBに対してゲストユーザーとしてアクセスし、成功した旨が記録されています。
インバウンド許可（User B ⇒ Directory Aへのゲストアクセス）
以下のように記録されます。
UserBが、DirecotyAに対してゲストユーザーとしてアクセスし、成功した旨が記録されています。
アウトバウンド拒否（User A ⇒ Direcotry Cへのゲストアクセス）
以下のように記録されます
UserAが、DirectoryCに対してゲストユーザーとしてアクセスし、失敗した旨が記録されています。
またエラーの理由としては
The user's administrator has set an outbound access policy that does not allow access to the resource tenant.
とあり、アウトバウンドアクセスポリシーによって禁止されているためと言うことが分かります。
また認証の要件が「単一要素認証」と表示されています。どうやら、MFAでの認証が要求される前に弾かれているようです。
インバウンド拒否（User C ⇒ Direcotry Aへのゲストアクセス）
以下のように記録されます。
UserCが、DirectoryAに対してゲストユーザーとしてアクセスし、失敗した旨が記録されています。
エラーの理由、追加の詳細の記述が先ほどのパターンと少し違い
The resource tenant's cross-tenant access policy does not allow this user to access this tenant.
This block occurred due to the resource tenant's cross-tenant access policy. Contact that tenant's administrator to ensure that these users are allowed access.
と表示されます。基本的に言っていることは同じですが、少し親切になっていますね。
なお、このパターンも「単一要素認証」と表示されました。
2つ目のパターンでUserBに対しては多要素認証が求められたのですが、やはりUserCが拒否されるときはMFAによる認証よりも手前だということが分かります。
おわりに
以上のとおり、DirectoryAに関する4種類のアクセスパターンのサインインログを見てきました。
よっぽどトラブらない限りココまで見ることは無いと思いますが、特に拒否されるときはどのように記録されるか覚えておくと役に立つこともあると思います。
「クロステナントのアクセス設定」は安心・安全にAzureを使うための1手段として有効だと思いますので、ぜひ使いこなしましょう。
さて、次回こそMFAの制御について書きたいと思います…
Discussion