メールアドレスでのAzure ADサインイン

皆さんこんにちは。国井です。

今日はメールアドレスでAzure ADにサインインする話です。
メールアドレスでAzure ADにサインインするといえば、代替ログインIDが有名かと思います。

AAD Connectによる代替ID設定
皆さんこんにちは。国井です。 以前、当ブログでAlternate Login ID(代替ID/代替ログインID)という方法を利用して、...

Azure AD Connectは
オンプレミスADユーザーのUPNとAzure ADユーザーのUPNをマッピングする同期を行いますが、
代替ログインIDでは
オンプレミスADユーザーのmail属性とAzure ADユーザーのUPNをマッピングする同期を行います。(mail属性以外でも同期は可能)

これが一番大きな違いでした。
しかし、代替ログインIDを使うとハイブリッドAzure AD参加が利用できないなどの問題があり、あまりお勧めできる構成ではありません。
そこで、こうした問題を解決するために最近、Azure AD Connectで代替ログインIDを設定しないでメールアドレスによるサインインができるような機能がプレビューで登場しました。

今までの代替ログインIDとの違いは
代替ログインIDはオンプレミスADユーザーのmail属性とAzure ADユーザーのUPNをマッピングするのに対して、

image

メールアドレスでのサインインは、サインイン時のユーザー名にAzure ADのメールアドレスを使うので、Azure ADのメールアドレスさえ、ちゃんとしたアドレスになっていれば、
Azure AD Connectで同期されてくるUPNはどんな構成になっていてもいいのです。

image

■ ■ ■

実現の仕組みですが、とても簡単でAzure ADディレクトリでHomeRealmDiscoveryの設定を変えてあげるだけです。
HomeRealmDiscoveryとは、ざっくり言うとサインインを行うときに、どこのIdPでサインインするかを定義したものです。例えば、Azure ADではサインイン画面をつかさどるサーバー(下図のcommon部分)でユーザー名/パスワード(資格情報)の入力を受け付けると、UPNサフィックス(ドメイン名)部分を見て、その資格情報による認証を行うAzure ADディレクトリを決定します。
image

このとき、UPNサフィックス部分がレルム(Realm)、レルムの情報に基づいてどこのAzure ADディレクトリに行けばいいの?を見つけるプロセスがHomeRealmDiscoveryというわけです。(※ADFSとお友達の方には馴染みの深い機能ですよね)

このHomeRealmDiscoveryを設定変更し、UPNサフィックスではなく、メールアドレスのサフィックスを参照してHomeRealmDiscoveryプロセスを行いましょう
というのがメールアドレスでのAzure ADサインインの機能なのだと思います。

実際に設定してみる

Azure AD PowerShellのPreview版をインストールし、Connect-AzureADで接続したのち、
こちらのコマンドレットを実行します。

New-AzureADPolicy -Definition @('{"HomeRealmDiscoveryPolicy" :{"AlternateIdLogin":{"Enabled": true}}}') `
     -DisplayName "BasicAutoAccelerationPolicy" `
     -IsOrganizationDefault $true `
     -Type "HomeRealmDiscoveryPolicy"

完了したら、後はカスタムドメイン名として登録されたドメイン名を持つメールアドレスをActive Directoryで設定し、Azure ADへ同期します。
ここではtr930.adfs.jpというカスタムドメイン名をあらかじめ設定していますので、メールアドレスもご覧のように設定してみました。

image

そして、https://myapplications.microsoft.com/ にアクセスし、
サインイン画面で電子メールアドレスを入力してみると、

image

image

image

メールアドレスでサインインできました。

ツッコミどころ満載な検証をしてみる

この機能をマイクロソフトが提供すると聞いて、私が最初に思ったことはメールアドレスという必ずしも一意ではない名前をユーザー名として使って大丈夫なの?です。そこで、思いつきそうなパターンでサインインを試してみました。

proxyAddresses属性でサインインできる?

mail属性でなくてもOKでした。(ただしproxyAddresses属性を利用する場合はmail属性はカラにしておく必要があるようです)
ちなみにproxyAddresses属性で、SMTP:とsmtp:のメールアドレスを2つ入れた場合、どちらのメールアドレスでもサインインできます。

カスタムドメイン名の登録のないドメイン名を使う

これはダメでした。メールアドレスには明確にカスタムドメイン名が含まれている必要があります。

Azure ADユーザーのUPNとオンプレミスADユーザーのメールアドレスが同じ場合

言葉にするとわかりにくいけど、こういう構成です。

image

サインインの名前で競合が発生する場合、オンプレミスADのユーザーを優先します。
つまり、Azure ADに作られた同じ名前のユーザーはもう二度とサインインできなくなりました。(怖!というかソフトマッチ的な機能はないのか..)

Azure ADユーザーのUPNとオンプレミスADユーザーのメールアドレスが同じ場合(2)

前のパターンと一緒ですが、今度はAzure ADに直接作られたユーザーがOffice 365のライセンスを持っている場合です。

image

オンプレミスADユーザーが同期されることによって、Azure ADユーザーが使えなくなるというのなら、Office 365ライセンスが割り当てられたユーザーのメールアドレスは闇に消えるのか?と思って検証してみました。
結果は、オンプレミスADユーザーにAzure ADユーザーが持っている Office 365 ライセンスは移管され、マージされます。
つまり、Azure ADユーザーは使えなくなるけど、Office 365のライセンスはオンプレミスADユーザーのアカウントを通じて引き続き利用可能ということです。

メールアドレスが同じオンプレミスADユーザーを作成した場合

ふたりのADユーザーで同じメールアドレスにした場合、片方のユーザーだけAzure ADに同期され、残ったユーザーは同期エラーでAzure ADにユーザーが作られることはありませんでした。でも、どういう理屈なんだろ?
もう疲れてAzure AD Connectのログを見る気力もなかったので、これは改めて確認してみます。

  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください