皆さんこんにちは。国井です。
2015年を振り返るには少しだけ早いけど、私が今年、最も多く受けたご質問は間違くなく
「Azure Active DirectoryとActive Directoryは何が違うのか？」
です。
Active Directoryはオンプレミスのリソースに対する認証基盤、
Azure Active Directoryはクラウドのリソースに対する認証基盤なので、
用途が異なりますし、そこで求められる要件・機能も違うはずです。
だから私個人の考えでは、比較すること自体、ナンセンスだと思っています。
■ ■ ■
例えば、Active Directoryの「信頼関係」について考えてましょう。
オンプレミスのActive Directoryにおける、信頼関係とは、
同じ社内ネットワークでつながっている、複数のActive Directoryフォレスト(またはドメイン)を結びつけるものでした。これって、ざっくり言ってしまえば、信頼関係を結ぶドメインどうしの相互接続を「全許可」するものです。
だけど、これをクラウドに置き換えてみたら、どうでしょうか？
Azure Active Directory(Azure AD)の信頼関係って、オンプレミスのActive Directoryと全く同じ機能を必要とするでしょうか？
事実、Azure ADには「同じ社内ネットワーク」という考え方自体が存在しないですし、
これだけビジネスのスタイルが多様化している中で、2つの会社のディレクトリを相互に「全許可」するやり方だなんて、時代にマッチした実装ではないのでは？と思うのです。
ですので、Azure ADで他のディレクトリとの相互運用を考えるのであれば、
盲目的に「Active Directoryにあった信頼関係って、Azure ADではどうやって設定するの？」と考えるのではなく、
自社のAzure ADを使ってもらいたい外部のユーザーが誰か？
自社のAzure ADを経由してアクセスさせたいアプリは何か？
を再定義し、それに合わせて必要な設定をAzure ADに実装するべきなのです。
その辺りを意識した、Azure ADのおける信頼関係機能がAzure AD B2Bと呼ばれる機能です。
では、(前置きが長くなりましたが)実装方法を見てみましょう。
■ ■ ■
Azure AD B2Bを利用した信頼関係では、Active Directoryの信頼関係のように、2つのディレクトリ(ドメイン)全体を結びつけるのではなく、
外部のAzure ADユーザーと自社のドメインからアクセス可能なアプリケーションを
関連付ける形で設定します。
こうすることで、外部のユーザーに対して自社のAzure ADドメインを利用させるけど、その範囲は最小限に抑えることができます。
しかも、他のドメインにあるユーザーと同じ名前のユーザーを自分のドメインに作成するのと違って、自社に作られる外部ユーザーはあくまでも「ショートカット」に過ぎないので、
大元のユーザーが削除されればアプリケーションへのアクセス許可も失われます。
つまり、ID管理が一元化されるので、複数箇所に混在する退職者アカウントがいつまでも残り続けるリスクを避けることができるのです。
以上の概要を見てみると、Azure ADの信頼関係設定で必要なことは、
どのユーザーに対して、どのアプリケーションに対するアクセス許可を設定するか、定義することだということがわかりますね。
それを踏まえて設定をしていきますが、
設定はCSVファイルを使って行います。
CSVファイル自体の設定はMSさんのサイトでも紹介されておりますので、
■Azure Active Directory (Azure AD) の B2B コラボレーション
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-b2b-collaboration-overview/
を参考にしていただけるとよいと思います。
少しだけ補足すると、CSVファイルの形式で属性を指定するのですが、
以下の属性が必須の属性になります。
Email：招待されるユーザーの電子メールアドレス (Azure ADのユーザー名)
DisplayName：Azure AD に表示されるユーザーの表示名
InviteContactUsUrl：お問い合わせ先URL (後に登場する招待状メールで使われるそうなのですが、確認できませんでした。なので、ここでは適当なURLを指定します)
あと、以下の属性は必須ではないですが、今回は使う予定です。
InviteAppID：アクセスするアプリケーションのアプリケーションID
InviteAppResources：アクセスするアプリケーションのアプリケーションID
InviteGroupResources：招待されるユーザーが所属する自社Azure ADドメインのグループ (グループのオブジェクトIDで指定)
Language：招待状メールで使う言語 (jaと書けば日本語になります)
このうち、アプリケーションIDはAzure AD PowerShellから
Get-MsolServicePrincipal | fl DisplayName, AppPrincipalId
と書いて実行すれば、アプリケーションIDは次のように確認できます。
今回はOneDriveにアクセスできるようにしてみたいと思います。
それから、グループのオブジェクトIDですが、こちらもAzure AD PowerShellから
Get-MsolGroup
と書いて実行すれば、オブジェクトIDは次のように確認できます。
ここでは、Salesグループに招待されたユーザーが含まれるようにしてみたいと思います。
以上を踏まえて、以下のようなCSVファイルを作ってみました。
では始めましょう。
Azure管理ポータルから、Azure ADドメインのユーザーを作成し、
ユーザー種類として、パートナー会社のユーザーを選択し、前に作成したCSVファイルを指定します。
登録完了すると、結果はレポートで確認することもできます。
ここではレポートを後回しにして、先を急ぎましょう。
ユーザーを作成すると、招待されたユーザーにはメールが1通届きます。
リンクをクリックすると、Webページに飛ばされ、
承諾すると、アプリケーションパネルWebサイトに移動し、OneDriveが利用できるようになります。
アプリケーションパネルでちょっとトリッキーなのが、画面右上の部分で、
Azure ADのテナント名をクリックすると、ドロップダウンでテナント名一覧が表示され、
どのテナントを選択するかによって、利用可能なアプリケーション一覧が変わる点です。
今設定したOneDriveは、信頼関係のあるテナントをリストから選んでいる時だけ有効で、自分のテナントを選択してしまうと消えてしまうので注意が必要です。
一方、Azure管理ポータルでは追加したユーザーが参照できます。信頼関係のある、他のAzure ADドメインのユーザーは
<メールアドレス>#EXT#@<自社のドメイン名>という形式のユーザーになります。
利用するには少し慣れが必要だと思いますが、なかなか素敵な機能だと思いますよ。
お試しあれ。
