[Azure AD B2B]アプリケーション管理者によるゲストユーザの招待

こんにちは、富士榮です。

Azure Active Directoryには無印（いわゆるAzure AD）の他に、

• 組織外のユーザ向けのAzure AD B2B
• コンシューマ向けのAzure AD B2C

と言われるオプションというか機能があります。

Azure AD B2CについてはTech Summitなどでお話しさせていただいたり、このブログでも取り上げてきたLINEやYahoo! JAPANなどのIDを使ったサービスへのログインの話ですが、今回はAzure AD B2Bの話です。

実はOffice365を使っている方は以前からAzure AD B2Bの機能を使っていました。いわゆる外部共有（招待）の機能の事です。

この機能を使うと組織のディレクトリ内に存在しない人を招待してゲストユーザとしてディレクトリへ登録し、組織のリソース（アプリケーションなど）へアクセスさせることが可能になります。

注意して使わないと危ないよ、という話は以前書かせていただいた通りですので、一読いただけるとよいと思います。

Office365管理者は要対応。外部共有により不要なアクセス権が付与される
http://idmlab.eidentity.jp/2017/01/office365.html

本日は、Office365ではないアプリケーションを外部ユーザへ共有したい、という場合のAzure AD B2Bの使い方を紹介したいと思います。

具体的には、

• 外部のコンサルや開発ベンダのアカウントをアプリケーションを使わせたい
• アプリケーションのSSOを構成するとAzure ADで全員を認証しないといけなくなってしまい、全ユーザがAzure AD上に登録されている必要がある
• 外部ユーザのID管理を管理者が行うのは面倒なので、責任範囲を明確にする意味でも当該のアプリケーションの管理者に権限委譲をしたい（Azure ADの管理者権限は渡さずに）

というようなケースを想定した使い方です。

早速やってみたいと思います。

◆必要なステップ

全体の流れとして、以下のステップで準備を行う必要があります。

1. [全体]招待するユーザを入れるためのセキュリティ・グループの作成
2. [全体]セルフサービスグループ管理の有効化
3. [アプリケーション単位]セルフサービスアクセス要求の有効化
4. [アプリケーション単位]セキュリティ・グループの割り当て

後は、アプリケーション管理者でアクセスパネルから外部ユーザを招待するとメールで招待が行き、外部ユーザがサインアップしてアプリケーションが使えるようになります。

◆設定してみる

では、早速やってみましょう。

１．[全体]招待するユーザを入れるためのセキュリティ・グループの作成

手動でメンバ管理を行うグループを作成します。

２．[全体]セルフサービスグループ管理の有効化

次に、ディレクトリのセルフサービス設定で、グループ管理を有効化します。（無効の場合は有効にします）

３．[アプリケーション単位]セルフサービスアクセス要求の有効化

次はゲストに使わせたいアプリケーションの設定で、セルフサービスアクセス要求と承認の設定を行います。ここで承認者として設定した人がアプリケーション管理者となり、ゲストを招待することが出来るようになります。

４．[アプリケーション単位]セキュリティ・グループの割り当て

後は、３で指定したグループをアプリケーションへ割り当てます。

これで準備は完了です。割とシンプルですね。

◆招待しゲストにアクセスさせる

では、早速動かしてみましょう。

まずは、アプリケーション管理者でアクセスパネル（https://myapps.microsoft.com）を開き、ゲストに使わせたいアプリケーションを選択して「アプリの管理」を開きます。

するとアプリケーションへユーザを追加することが出来るようになっているので、「＋」をクリックしてゲストを招待します。

外部ユーザのメールアドレスを入力すると招待メールの文面を入れる画面が自動的に出てきますので、何かメッセージを入れて招待を行います。

これで外部ユーザには招待メールが届きます。

「はじめに」というリンクをクリックするとサインアップ画面へ遷移します。

パスワード、表示名、国を指定してゲストユーザ登録を完了します。

メールへ確認コードが飛んでくるので確認画面で入力してアカウント確認を行います。

登録が完了すると登録したパスワードで認証が走り、アクセスパネルが表示され、アプリケーションが利用できるようになります。

今回は、アプリケーション管理者により外部ユーザをAzure AD上に招待することにより少なくとも認証は全員Azure ADを使う様に構成することが出来ました。このことで条件付きアクセスなど、アプリケーション利用ポリシーをAzure ADで一括で管理することが出来るので、セキュリティ面でも安心できると思います。

ちなみに、管理者によりゲストユーザを作成したり招待することも可能ですし、APIを使って一括で外部のディレクトリからユーザを引き込む、というようなことも可能です。（大規模なM&Aや業務提携などの場合はカスタムアプリケーションを作って自動同期をするように構成することが多いようです）

[AD FS]ログイン画面をAzure ADの新UIライクにカスタマイズする

こんにちは、富士榮です。

Azure Active Directoryのサインイン画面が新しいUIに変わったのに、AD FSはいつまでも昔のままというのは微妙だよね、ということでAD FSのログインUIをAzure ADに合わせるカスタムCSSが公開されています。

Using an Azure AD UX Web Theme in Active Directory Federation Services
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/azure-ux-web-theme-in-ad-fs

早速試した先人のblog
https://msfreaks.wordpress.com/2017/11/19/adfs-new-sign-in-experience-added/

このドキュメントに従いgithubよりCSSをダウンロードし、AD FSのカスタムテーマを設定してみたいと思います。（Windows Server 2016のAD FS用、とありますが、2012R2でもちゃんと動いています。他のバージョンは試してませんが）

まずは旧UIです。お馴染みですね。

ちなみに、bingの画像をとってきて自動的にログイン画面の背景に使う、というスクリプトが公開されているので、こちらを使っています。

Automated Bing Wallpaper for ADFS 3.0 Themes
https://gallery.technet.microsoft.com/Automated-Bing-Wallpaper-c34136eb

先の手順に従ってカスタムテーマを設定していきます。
まずは、DefaultテーマのExportを行います。ちなみにこの手順が先のサイトでは省略されているのですが、必ず必要なので実施をしてください。この手順を飛ばすとonLoad.jsがないので背景が設定されません。

Export-AdfsWebTheme -Name Default -DirectoryPath C:\Style\default

次に、カスタムテーマを作成します。
必要なCSSや画像がダウンロード済みなことを確認し、以下を実行します。

New-AdfsWebTheme -Name custom -StyleSheet @{path="c:\style\ThemeCenterBrand.css"} -Illustration @{path="C:\Style\bing.png"} -AdditionalFileResource @{Uri='/adfs/portal/script/onload.js';path="c:\style\default\script\onload.js"}

後は、テーマを有効化すればOKです。

Set-AdfsWebConfig -ActiveThemeName custom

こんな感じになります。

ロゴなんかも変えるとこんなこともできますね。
カークとラーズが隠れてしまってますが・・・

LINEログインとBotの自動リンク機能が一般公開

こんにちは、富士榮です。

先日のLINE Developer Dayで発表されたLINEログインとBotの自動リンク機能がいよいよ一般公開されました。
また、同時にBotとユーザの友だち関係が取得できるAPIも同時に公開されているため、従来Webhookでfollow/unfollowのイベントを取得して保存して状態を管理しておかなければならなかったのがリアルタイムに状態把握が出来るようになり、Bot開発者はとっても楽になりました。

LINEログインチャネルにボットをリンクできるようになりました
https://developers.line.me/ja/news/#link-your-bot-to-your-line-login-channel-2017-11-21

それぞれ動作イメージです。

◆LINEログインとBotの自動リンク

基本は以前紹介したエントリと変わりませんが、DeveloperコンソールからリンクするBotを自分で設定できるようになりました。

チャネル内にLINEログインとMessaging APIを作成、LINEログインのチャネル設定からリンクするBot（Messaging API）を設定します。

この設定をして、LINEログインをすると認可画面でBotを友だち追加する許可が表示されます。

尚、この機能を使うには、前提事項がありますので、注意が必要です。

• LINEログインのversion 2.1を使うこと
• アプリケーションタイプがWebであること
• 同一プロバイダ内にBotがあること

◆友だち関係の状態を取得する

もう一つが、最新の友だち関係の状態を取得するAPIです。
2つ方法があります。

• 認可コードを取得する際にCallback URLへcodeとともに返ってくる「friendship_status_changed」の値を見る（状態の変化の有無の確認）
• 状態取得用API（Social API）エンドポイントをGETする

2つ目のSocial APIエンドポイントへアクセスして状態確認をするのが一番任意のタイミングで確認できるので便利かも知れません。

Social API
https://api.line.me/friendship/v1/status

クエリ方法は単純でAuthronizationヘッダにaccess_tokenをつけてGETするだけです。
trueが返ってくれば友だち、falseだと友だちではないかBlockしている状態です。

さてさて、早速Azure AD B2Cとの連携モジュールを少し改修して便利にしていかなきゃ、と思います。

Firefoxの更新でSAML Tracerアドオンが利用不可に・・・

こんにちは、富士榮です。

Firefoxのバージョンが上がりましたね。スクリーンショットが撮れたりするのは良いんですが、SAML Tracerなどのアドオンが使えなくなってしまったのは全国3000万のSAMLerの皆さんには受け入れがたい事実です。

※2017/12/6続報。対応バージョンが出ました。一安心。
　http://idmlab.eidentity.jp/2017/12/firefoxsaml-tracer.html

仕方がないので別のアドオンを探してみると、SAML Message Decoderというモノがあったので早速入れてみます。

インストールすると、メニューバーにアドオンが追加されるので、早速SAMLを使っているサイトへアクセスします。
アイコンを右クリックするとExport messagesというメニューが出てくるので、ここをクリックしてトレースデータをExportするようです。
SAML Tracerのようにリアルタイムでトレースが見れないのが非常に残念です。

Exportしたファイルはjson形式で保存されるのでエディタなどで開くと確かにメッセージが表示されています。。。

決して見やすいとは言えないですね。。。
SAML Tracerのバージョンアップに期待しておきましょう。

Tech Summit で使った Azure AD B2C + LINE チュートリアル

こんにちは、富士榮です。

Tech Summitが終わりましたね。
私は先に告知させていただいた通り、Azure Active Directory B2C と LINE の連携の話をさせていただきました。

[告知] Tech Summit 2017で Azure AD B2C＋LINE、Yahoo! ID辺りの話をします
http://idmlab.eidentity.jp/2017/10/tech-summit-2017-azure-ad-b2clineyahoo.html


セッションの動画公開は行わない予定ですが、資料は来週以降に公開されるそうなので、その時はまたお知らせしますが、ここではセッション内でお見せしたデモ環境をご自身で作っていただくためのチュートリアルを紹介します。

Azure AD B2C + LINE連携 / チュートリアル
https://github.com/fujie/ts2017

置いてあるのは、
・手順：readme.md
・ポリシーテンプレート：policy_template_base.xml、policy_template_susi.xml
・テスト用アプリケーション：test.php
です。

基本的には手順に従って作業をしてもらえればとりあえずLINEでテストアプリケーションへログインできるようになりますので、一度試してみてください。

[Office365＋AD FS管理者向け] Azure ADのエンドポイント追加による可用性の向上

こんにちは、富士榮です。

Azure AD単体（要はクラウド認証）でOffice365を使っている人には関係ありませんが、AD FSやサードパーティのIdPを使ってOffice365やAzure AD連携されたアプリケーションを使っている人は、近々エンドポイント追加の作業が必要になりそうです。

公式アナウンス）New Azure Active Directory resilience features: action required
https://cloudblogs.microsoft.com/enterprisemobility/2017/10/27/new-azure-active-directory-resilience-features-action-required/

正式なアナウンスは追ってあるようですが、要するに可用性を向上するためにAzure ADのACS（Assertion Consumer Service）のエンドポイントが増えたので、AD FSとかサードパーティのIdPでOffice365やAzure ADを使っている人は対応してね、ということらしいです。
※ちなみに、Azure AD ConnectでAD FSを構成している人は自動的に構成が変更されるみたいです。

こちらが変更までのAD FSの構成です。

手動で追加する場合はPowerShellで一括で登録することもできますし、この画面で追加しても大丈夫です。
一括追加のスクリプトは以下の通りです。

$rp = Get-AdfsRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline
$endpoints = New-Object System.Collections.ArrayList
if ( $rp.AdditionalWSFedEndpoint ) { $rp.AdditionalWSFedEndpoint | %{$endpoints.add($_)} }
$endpoints.add("https://stamp2.login.microsoftonline.com/login.srf")
$endpoints.add("https://ccs.login.microsoftonline.com/ccs/login.srf")
$endpoints.add("https://ccs-sdf.login.microsoftonline.com/ccs/login.srf")
set-adfsrelyingpartytrust -targetname $rp.Name -AdditionalWSFedEndpoint $endpoints

結果、こんな感じになります。

尚、Azure ADと外部IdPを連携する際のsp-metadataを見るとまだ上記のエンドポイントは記載されていないのですが、今後は追加されてくるのかも知れませんね。

参考）Azure ADのsp-metadata
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml

11/30までにAzure AD管理者がやっておくべきこと：条件付きアクセスの設定移行

こんにちは、富士榮です。

いよいよ今月末（11月30日）でAzureクラシックポータル（旧ポータル）が廃止されます。

公式アナウンス）Marching into the future of the Azure AD admin experience: retiring the Azure AD classic portal
https://cloudblogs.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/

Azure ADの管理機能も「ほぼ」新ポータルへ移行されたのですが、旧ポータルでアプリケーション単位で設定をしてきた条件付きアクセスの設定が新ポータルの条件付きアクセスでは触れず、メンテナンスは新・旧でバラバラに行う必要がありました。

この状態で旧ポータルを廃止されるとかなり困ったことになるのですが、先日ようやくマイグレーションパス（というか緩和措置？）が発表されました。

公式アナウンス）This one is important: Time to migrate your v1.0 Conditional Access policies to v2.0!
https://cloudblogs.microsoft.com/enterprisemobility/2017/10/23/this-one-is-important-time-to-migrate-your-v1-0-conditional-access-policies-to-v2-0/

簡単に言うと、旧ポータルの条件付きアクセス（v1.0）を新ポータルの条件付きアクセス（v2.0）でも見えるようになる（だけ）の機能の発表です。

11月30日の廃止の1か月前のアナウンスというタイトな感じなので、早くやっておかないとハマりそうな感じ満載です。（しかもPreview機能という・・・このまま永遠にPreviewなんだと思いますが）

ということで、早速試してみます。

◆旧ポータルの状態の確認

まずは旧ポータルで現状を確認しましょう。アプリケーションの構成から条件付きアクセスの確認をすることが出来ます。そういえばネットワークの場所ベースとデバイスベースが独立したメニューになっていたんですね。この画面も見納めかと思うと画面ショットを撮りまくっておきたい気分になります。

◆新ポータルから旧ポリシーを確認する

既に皆さんの新ポータルから旧ポリシーが確認出来るようになっていますので、見てみましょう。Active Directoryを開き、条件付きアクセスを見ると、Classic Policies（Preview）というメニューが追加されています。

メニューを開くと、

• [アプリケーション名] MFA and location policy（場所ベースの場合）
• [アプリケーション名] Device policy（デバイスベースの場合）

という形でポリシーが見えるようになっています。

ポリシーを選択するとどのようなポリシーだったのか、内容の確認ができます。

では、早速移行してみます。

◆信頼済みIPリストの移行

まず、旧ポリシーでは信頼済みIPとして多要素認証の管理画面で指定したネットワークリスト（上限50個）しか指定できませんでした。
もちろん新ポータルでも多要素認証で指定したネットワークリストも使えますが、数の上限があるのと、一覧で書くしかないので使い勝手があまりよくありませんので、せっかくなのでこの機会にNamed Locationsを使いましょう。こちらを使えば、ネットワークに名前を付けることが出来るので、例えば事務所のロケーション毎にネットワークアドレス群に名前を付けて管理することが可能です。

もちろん、この画面からConfigure MFA trusted IPsをクリックすれば多要素認証のネットワークリストを確認・設定することが可能ですので、こちらから設定を移行しましょう。

新規Named Locationを追加するとネットワークに付ける名前、指定方法（IPレンジか、国や地域）、信頼済みIPとして扱うかどうか、実際のネットワークリストの指定を行うことが出来ます。ここへ多要素認証の信頼済みIPリストを移行しておきましょう。

◆ポリシーの移行（作り直し）

条件となるネットワークの移行が終わったら、旧ポリシーを参考に新ポリシーを作成します。
設定すべき項目は以下の通りです。

• ポリシー名 : 任意の名前
• 対象のユーザ・グループ : ポリシーの適用対象、除外対象ユーザ・グループの指定
• 対象のアプリケーション : ポリシーの適用対象、除外対象アプリケーションの指定
• 適用条件 : ポリシーの適用条件（ネットワーク、デバイス状態）
• アクセスコントロール : 条件にマッチした場合のアクションの指定（多要素認証の要求やアクセスのブロック）
• セッション : 現状はまだPreviewですが、一部のアプリケーション（SharePoint Online）における制限やCloud App Securityと連携したコントロールが出来ます。

まずは、適用対象のユーザとグループです。

よく使うポリシーとしてInclude（適用対象）に全員を入れておいて、Exclude（除外対象）に一部のグループを入れておいて一時的に多要素認証のデバイス（スマホなど）を忘れた人を救済する、というポリシーです。

次にアプリケーションです。
旧ポータルではアプリケーション単位にポリシーを作成する必要がありましたが、新ポータルでは全体に適用する共通ポリシーや一部の選択したアプリケーションへ適用するポリシーを作成することも可能になりましたので、この機会にポリシーの見直しをしても良いかも知れません。

次に適用条件です。
今回は移行元がネットワークの場所ベースの条件付きアクセスだったので、Locations設定でInclude（適用対象）をすべて、Exclude（除外対象）を信頼済みネットワークとして指定します。（ここでAll trusted locationsとすると多要素認証の信頼済みIPリストと、信頼済みとするにチェックを入れたNamed locationの両方のorをとったものが対象となります）

後はアクセスコントロールです。
条件にマッチした場合に多要素認証を要求する場合は、Grant accessにしてRequire multi-factor authenticationを指定しておけば大丈夫です。

最後に、ポリシーをEnableにして保存すれば適用が開始されます。

◆旧ポリシーを無効化し、動作確認を行う

ここで重要な注意点です。
新ポータルからは旧ポータルで作成したポリシーを無効にすることしかできません。失敗しても再度有効化しようとすると旧ポータルへアクセスして有効化しないといけません。
つまり、12月1日以降に新ポータルで無効化した旧ポリシーは二度と有効化することが出来ない、ということなのでリカバリーが出来る状態での動作確認は11月30日までしか出来ない、ということです。

しっかり計画を立てておきましょう。

新ポータルから旧ポリシーを無効化するには、先ほどのメニューより旧ポータルを選び、Disableをクリックするだけです。

後は動作確認として、適用条件に合致した・合致しない状態でアプリケーションへアクセスし、望んだ状態になるかどうか確認してください。

ということで、管理者の皆さんは急いでテスト～移行しておきましょう。