2018年6月16日土曜日

[Azure AD/パスワード保護] NGワードの登録、オンプレADへのポリシー適用

(6/20 更新:モジュールのダウンロードが復活したのでリンクを張りました)
こんにちは、富士榮です。

現状のAzure Active Directory(Azure AD)におけるクラウド・ユーザのパスワード・ポリシーは有効期限と期限切れ通知に関する設定の2点だけしかカスタマイズすることが出来ません。(しかも、Office365のポータルもしくはPowershellコマンドレットで変更するしか方法がありません)

基本的な考え方として、単純なパスワードや漏えいの恐れのあるパスワードや使いまわされているパスワードなどはAzure ADが自動的にブロックしてくれているので、オンプレミスのADに比べてかなり強力な保護が実装されており、そのまま任せておくのがベターというポリシーに基づいているものと思われます。

※Azure AD Connectで同期をしているユーザはオンプレミスのActive Directoryのパスワードポリシーに準拠しますので、グループポリシーで複雑性要件をカスタマイズすることが可能です。
※ちなみにAzure AD B2Cでは複雑性ポリシーなどをカスタマイズすることが可能です。

参考)Azure Active Directory のパスワード ポリシーと制限
https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/concept-sspr-policy


しかし、一方でせっかくAzure ADが強力なパスワード保護機能を持っているので、この機能をオンプレミスにも適用したり、更にNGワードを追加したり(例えば会社名など組織内では一般的な用語など)することで全体としてパスワード保護を強化したくもなってきます。(オンプレとクラウドでポリシーがバラバラになることで利用者の混乱を招く可能性も大きいと思いますし)

今回Preview公開されたAzure ADのパスワード保護機能では、以下の機能が実装されています。

  • ロックアウトまでのログイン試行回数の設定
  • ロックアウトが自動的に解除されるまでの時間(秒数)
  • 利用できない文字列の設定
  • オンプレミスADへのポリシーの適用

(2018/06/16時点)
ちなみに昨晩まではオンプレミスADへのポリシー適用に使うためのエージェントモジュールのダウンロードが出来たんですが、本日はリンクが切れています。
おそらく何らかの不具合がありモジュールを引っ込めたと思うので、再公開を待ちましょう。

ということで、オンプレミスADへのポリシー適用については試せていませんので、他の機能を紹介していきます。
6/20更新)以下のページからダウンロードができるようになりました。
 https://www.microsoft.com/en-ie/download/details.aspx?id=57071
オンプレミスADへのポリシー統合に関するドキュメントも合わせて公開されています。
 https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad-on-premises

手順は確認したら別途紹介したいと思います。

◆パスワード保護設定

Azure PortalよりActive Directoryを開くと[Authentication Methods]というメニューが表示されていますので開くと、[Password Protection(Preview)]という設定項目が出てきます。


この画面で先に紹介したロックアウト関連、NGワード登録、オンプレADへの適用に関する設定を行います。
ちなみにオンプレADへの適用についてはAzure ADのライセンス適用状況によってはグレーアウトされます。(おそらくPremium P1かP2のどちらかが必要そう。確認中)
6/20)ドキュメントを見るとやはりAzure AD Premiumが必要とのことです。

◆ロックアウトポリシーを変更する

まずはロックアウトされるまでの認証失敗回数を変更してみます。初期値は10ですので、既に上記の画面ショットでは2回に変更してあります。
つまり、上記の画面の設定だと、2回パスワードを間違えると60秒間ロックされます。

というわけで2回間違えるとこんなメッセージが表示されます。




◆NGワードの登録

Custom banned password listという項目に最大1000個までNGワードを登録できます。
ちなみに、大文字・小文字の判別は無く、oと0、aと@などの代替文字の読み替えも自動的にやってくれます。


ちなみに今回は試しに「hogehage」というNGワードを登録しておき、「H0geh@ge」というパスワードを設定しようとすると以下のように弾かれました。

何度も使っている訳ではないので、メッセージは微妙ですが実際に設定が出来なくなりました。中々便利です。

後はオンプレADへこれらのポリシーを含むAzure ADのパスワード保護が適用できるとかなり便利になると思うので、ダウンロードが回復したら試してみようと思います。

2018年5月25日金曜日

[Azure AD B2C]VS Code Extensionでカスタムポリシーを簡単編集

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

de:codeのセッションの中で軽く紹介したんですが、資料にURLなど載せていなかったので紹介しておきます。

カスタムポリシーってポータルからダウンロードして、XMLファイルをゴリゴリ編集して再度アップロードして、、という作業を経て構成するので中々とっつきにくい、と思って敬遠している方へ朗報です。

Visual Studio Code用のAzure AD B2C用のExtension(ベータ版)が公開されています。

Azure AD B2C Tools
https://marketplace.visualstudio.com/items?itemName=AzureADB2CTools.aadb2c


主な機能と出来ることは以下の通りです。

  • カスタムポリシーエクスプローラー
    • ポリシー内の各エレメント一覧を参照、ジャンプ
  • アイテムの定義の参照
    • Shift+F12を押すことでアイテムの定義箇所へジャンプ
  • XMLエレメントの追加
    • ClaimとかTechnicalProfileなどのエレメントを追加
  • ヘルプと関連情報の表示
    • 関連するドキュメントの表示
  • XMLスキーマの簡易ヘルプ
    • XMLタグにマウスオーバーすると説明がポップアップ


こんな感じです。



かなり生産性が上がると思うので、カスタムポリシーを書く方は是非!

2018年5月18日金曜日

[Azure AD] Azure AD ConnectでPingFederateとのSSO構成が可能に!

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

ちょうど1年近く前に正式リリースされたAzure AD Web Application ProxyとPingIdentityのPingAccess連携の話に引き続き、今度はAzure AD Connectを経由したPingFederateの構成が発表されました。(現状Public Previewです)

 [Azure AD] PingAccess連携が正式リリース
 https://idmlab.eidentity.jp/2017/06/azure-ad-pingaccess.html

対応したのは最新バージョンのAzure AD Connect(1.1.819.0)からです。

Office365、Azure ADとのID連携先としてPingFederateは早い段階から認定されていましたが、より深くインテグレーションされてきました。

関連ドキュメントはこの辺りから。



簡単に言うと、自動的にやってくれることは、

  • PingFederate側に何を設定すれば良いかを教えてくれる(Azure ADのEntityIDとかエンドポイントのURIとか)
  • Azure AD側のFederationの構成してくれる

ということです。

今、手元にPingFederateの環境がないので、インストーラの途中までですが、こんな感じで設定を行います。

User sign-inの設定で「Federation with PingFederate」が選択できるようになっています。

連携するAzure ADのドメインを選択します。

Federationの設定を行うところでは、PingFederateに何を設定するかExportしてくれるのと、PingFederateのURLを指定します。

ちなみにExportした構成情報は結構丁寧にPingFederateに何を設定したらいいのか記載されています。


まぁ正直、手動で構成するのもそれほど手間ではないのですが、最初から選択肢として組み込まれてくるとグッときますね。
皆さんも自宅に転がっているPingFederateを使って是非試してみてください。

2018年5月12日土曜日

[FIDO]Firefox 60の正式版がリリースされたのでWebAuthnを試してみる

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

先月WebAuthnがW3Cの勧告候補になってブラウザ各社が対応を表明したり、Windows 10 April Update 2018からWindows HelloでFIDO2 Security Keyが使えるようになったり(まだTAPなど一部ユーザにしか提供されていませんが)と、にわかにFIDO周りがにぎやかになってきました。

ということでWebAuthnに対応したFirefox 60.0が正式にリリースされたので手元のYubikeyで試してみます。
左から、Security Key By Yubico、Yubikey 4、Yubikey NEOです。
なんだか増殖してます。
Yubikeyの各エディション毎の比較は以下のページから。
https://www.yubico.com/products/yubikey-hardware/compare-yubikeys/


まずは、Firefoxのバージョンを確認しましょう。


ちゃんと更新されてます。

次にWebAuthnがちゃんと有効になっているか確認します。about:configを開きwebauthn関係の設定を検索し、「security.webauth.webauthn」がTrueであることを確認します。

これも大丈夫です。


ということで、テストしてみます。
今回テストに使ったのは、
https://webauthn.io/
https://webauthn.bin.coffee/
の2つのサイトです。

まずはhttps://webauthn.io/です。

ユーザ名を入れて、Register a User/Credentialをクリックします。

セキュリティ・トークンを求められるので、Yubikeyを差し込んでタップします。

登録とログインが成功しました!
ちなみにFIDO2にも対応しているSecurity Key by Yubico(青い奴)とYubikey 4はうまく動きますが、一番古いYubikey NEOだとダメでした。


同じように、https://webauthn.bin.coffee/でも試してみます。

Create Credentialをクリックすると同じようにキーを求められるので、Yubikeyを差し込んでタップします。

こちらも無事に登録が出来ました。


あくまでテストツールでブラウザの対応を確認しただけなので、面白味には欠けますが、これで実際にWebAuthnに対応したWebアプリケーションを作る環境はそろったことになるので、パスワードレスのWebサイトが登場してくるのも近いかもしれません。楽しみですね。

2018年5月8日火曜日

[Azure AD] Build 2018( #msbuild )に合わせてAzure AD PIMとTerm of UseがGA

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

事前にアナウンスが合った通り、昨日より開催されているBuild 2018に合わせてAzure AD関係の以下の機能が一般リリース(GA)されました。


  • Privileged Identity Management(PIM)
  • Conditional Access - Term of Use(ToU)


公式Blogでのアナウンス
https://cloudblogs.microsoft.com/enterprisemobility/2018/04/17/password-less-sign-in-to-windows-10-azure-ad-using-fido2-is-coming-soon-plus-other-cool-news/
※主題はFIDO2の話ですが、しれっとBuildでGAされるよ!という話が書いてあります。


PIMはいわゆる特権管理ですね。Azure AD上の特権を承認を得て一時的に取得するための機能で、Azure AD Premium P2で使えます。


ToUは条件付きアクセスの条件の一つとして設定ができるもので、使用条件に同意をしないとアプリケーションを使わせない、というような条件を設定することが可能です。

こちらは以前、Azure AD B2Bのゲストユーザへの同意を求める、というシナリオで紹介しましたね。
https://idmlab.eidentity.jp/2017/12/azure-ad-b2bterms-of-use.html



他にもIdentity関連のセッションが色々と用意されているようなので、期間中に良い情報が出てくれば紹介したいと思います。

2018年5月7日月曜日

[Azure AD B2C]カスタムドメインのサポートがPublic Preview

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

Azure AD B2Cの各種エンドポイントってxxx.microsoftonline.comなので、Azure ADを使ってるってモロにわかってしまいます。

企業内で利用するシナリオだとそれほど問題にならないかも知れませんが、B2Cシナリオでは外部へのプロモーションに使ったりするので問題になることもしばしばあります。また、同様にB2Cシナリオではログイン画面のカスタマイズを行う前提になると思うので、ドメイン名の問題でJavaScriptを仕込めない、などの機能面での不具合も出てきます。

そこで、しばらく前からPrivate Previewが行われていたカスタムドメインよるJavaScriptのサポートがようやくPublic Previewとして公開されたので紹介します。
※JavaScriptサポートはまだみたいです。想定外の動きをすることもありますが問い合わせとかはしないようにしましょう。(5/21追記)

詳細ドキュメントはこちらです。
 https://docs.microsoft.com/en-us/azure/active-directory-b2c/b2clogin


尚、最初にお伝えしておきますが、本当に好きなドメイン名でログイン画面を構成することが出来るようになるわけではありません。microsoftonline.comの代わりにb2clogin.comという別のドメインが用意され、そのドメイン上のログイン画面ではJavaScriptが使える、というだけです。

カスタムドメインを使う時のURLのルールはこのように変わります。
<従来>
https://login.microsoftonline.com/{テナント名}.onmicrosoft.com
<カスタム>
https://{テナント名}.b2clogin.com/{テナント名}.onmicrosoft.com


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

◆カスタムUIの準備

まずはログイン画面をカスタマイズしてJavaScriptを仕込んでみます。
最初にHTMLを作成して、blobにアップします。

次に、カスタムポリシーで(もしくは管理画面から)、UI定義で作成したHTMLを使う様に設定します。


後は、サインインポリシーやアプリケーションの定義などは必要ですが、この辺りは割愛します。

◆まずは通常通り呼び出してみる

今回はASP.NET CoreのMVCアプリを作ってAzure AD B2Cを使って認証する様に構成します。
通常はこんな感じで認証の設定を入れるとノンコーディングでAzure AD B2Cを使って認証できるようになります。


アプリケーションを起動し、SignInをしてみるとAzure AD B2Cのログイン画面が表示されます。

ここで、先にアップロードしたHTMLに合った通り、ボタンを押すとAlertが出るはずなんですが、通常のドメインで構成されているのでボタンは全く反応しません。
(もちろんログインは出来ます)

◆カスタムドメインを使う

ようやくカスタムドメインの出番です。
先のアプリケーションのappsettings.jsonを開き、Instanceの行を直接編集します。
元はlogin.microsoftonline.com/tfpだった部分をxxx.b2clogin.comへ変えます。


これだけです。
早速実行してみると、先ほどと同じログイン画面は出ますが、ドメイン名がb2clogin.comになっており、JavaScriptが実行できるようになっています。



これで色々とカスタマイズは出来るようになるので、自由度は各段に増します。
(本当は独自ドメインが使えると良いんですが・・・)

ちょっと応用で、Puzzle CAPTHAのCAPYを組み込んでみました。
この辺りも全部JavaScriptが前提となるので、従来は実現できなかった構成です。



UIのカスタマイズを含む、IdentityExperienceFrameworkの使い方については今月22日~23日のde:codeでチョークトークで解説させていただく予定です。是非こちらもお越しください。(私の出番は23日の最終セッションです)

 AD20
 実践から学ぶ!SNS ID を企業認証基盤で活用するには?
 https://www.microsoft.com/ja-jp/events/decode/2018/sessions.aspx#AD20





2018年4月28日土曜日

Microsoft Authenticatorアプリが設定のバックアップ・リカバリをサポート、しかし・・・

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

みなさん、多要素認証してますか?
アイデンティティは不正利用されている、という前提で運用しないといけない世の中になってきているので、IDとパスワードが盗難されても不正にログインされない様に多要素認証を有効にするのは大人のマナーです。もしくは、少なくともログイン・アラート(知らないログインがあったら通知してくれる機能)が使える認証システムを使う、くらいはいしないとダメな世の中です。
そういえば昨年のde:codeでもこんな話をしてました。

結局、ID盗難って本人が気が付きにくいところが一番の問題なんですよね。


と、言うことでMicrosoftもAuthenticatorアプリをiOS/Android/Windows Mobile向けに提供しており、私もAzure ADアカウント、Microsoftアカウントに加えてGoogleやFacebook、Amazonなどのアカウントの多要素認証をこのアプリでやっています。

が、機種変更などでアプリを再インストールすることになると実は非常に面倒です。全ての多要素認証設定を再度1からやり直さないといけないので、このアプリがないとログインできないような状態になってしまっているサービスがあると詰みます。

そこで登場したのが、ずっとリクエストが上がっていた多要素認証設定のバックアップとリカバリ機能です。

公式Blogでのアナウンス
 Microsoft Authenticator Account Backup and Recovery: Coming soon to an iOS device near you!
 https://cloudblogs.microsoft.com/enterprisemobility/2018/04/24/microsoft-authenticator-account-backup-and-recovery-coming-soon-to-an-ios-device-near-you/


機能を有効化するためには以下の条件を満たす必要があります。
・iOS版であること(残念ながらまだAndroid版では使えません)
・Authenticatorアプリのバージョンが5.7.0以降であること
・Microsoftアカウント(個人アカウント)があること


早速使ってみましょう。
と、その前に本ポストのタイトルに書いた「しかし・・・」の部分が気になりますよね?そう、実は組織アカウント(Azure AD/Office365)の多要素認証はリカバリできないんです。結局は再度QRコードの読み込みから開始なので、管理者にリセットしてもらう必要があります。
また、多要素認証設定済みのMicrosoftアカウントで設定をバックアップすると、リカバリ時に当該のMicrosoftアカウントでログインを求められますが、当然そのMicrosoftアカウントの多要素認証は今からリカバリしたい設定の中に入っているので、アプリで多要素認証は出来ません。他の方法(メールとかSMSでの回復)を設定していないとこれも詰みます・・・


こんな罠だらけの新Authenticatorですが、Googleなどの他の多要素認証はちゃんとリカバリしてくれる(はず)なので一応便利です。(Googleしか試してないのでAmazonとかFacebookが大丈夫かどうかは知りません)


とは言え、気を取り直して試してみます。
アプリを起動して、設定メニューを開くと「バックアップ」という項目が増えています。

おもむろに自動バックアップをONにするとMicrosoftアカウントが求められます。
この画面だけを見るとバックアップはOneDriveとかに保存されるのかな?と思うんですが、アプリを英語モードで起動すると実はこの画面の前にiCloudに保存する、というメッセージが出てきます。
これを見るとバックアップはiCloudにされ、リカバリする時にMicrosoftアカウントで認証することで保険をかけてる、ということなんだと思います。

Microsoftアカウントを追加すると回復アカウントとして表示されます。

後は、おもむろにアプリを消して再インストールしてみます。
まっさらの状態で起動してくるので、「回復の開始」からリカバリをしてみます。

回復に使うMicrosoftアカウントを選択し、ログインしましょう。
ここではアプリ内ブラウザが前に設定した時のMicrosoftアカウントを覚えてくれていたので選択するところから始まっていますが、機種変更などの場合はアカウントを追加するところからスタートですね。
と、ここで先ほど書いた通りのハマりポイントその1です。
このMicrosoftアカウントに多要素認証の設定をしていたので、ログイン時に多要素認証を要求されます。
運良く、実験した時は別のデバイスで多要素認証する様に構成していたので、難を逃れました。


しかし、別のデバイスで認証する構成にしていたが故に不思議なことが起きてしまいます。発生した現象は後述するとして先に進めましょう。

アカウントの回復完了、と表示されるのですが「セキュリティ上の理由から、一部のアカウントで追加の検証が必要です」と出て、Azure ADのアカウントに!マークがついています。

これが先ほど書いた微妙な点です。
Azure AD/Office365のアカウント(組織アカウント)のリカバリは出来ないんです。
回復するには再度QRコードをスキャンする必要があるので、別の方法で何とかログインするか管理者に多要素認証設定をリセットしてもらうしかありません・・・

今回は管理者でリセットしました。Azure ADのポータルからMFA設定を開いてユーザを検索、Manage user settingsを開きます。

再度ユーザが多要素認証設定を設定する様に要求します。

これで再設定をすると一応リカバリされます。
ちゃんとAzure ADアプリへの多要素認証ログインもできました。もちろんGoogleについてはGoogle側で何のリカバリ処理も必要なく、ちゃんと多要素認証ログインできます。


ちょっとおかしなことになってますよね?
気が付いた方いますか?




そうです、リカバリした端末側の多要素認証設定に、リカバリに使ったMicrosoftアカウントのエントリが勝手にできています。
私は別の端末でこのMicrosoftアカウントの多要素認証をしていますので、2つの端末に同じMicrosoftアカウントの多要素認証エントリが存在している状態になります。

試しに、このMicrosoftアカウントでサービスにログインしてみます。

すると、なんと2つの端末に通知が来ます・・・


はい、バグだと思います。
(と思いましたが、Microsoftアカウントの場合は複数の端末で多要素認証をさせることができるので、こういう仕様なんだと思います)

ちなみに、どちらで承認してもちゃんとログインできます。

うーむ・・・



と、若干微妙な感じではありますが、少なくともGoogleの多要素認証はちゃんとリカバリできたので、楽にはなりました。
皆さんも使ってみましょう。