ラベル Office365 の投稿を表示しています。 すべての投稿を表示
ラベル Office365 の投稿を表示しています。 すべての投稿を表示

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の多要素認証はちゃんとリカバリできたので、楽にはなりました。
皆さんも使ってみましょう。

2018年1月18日木曜日

[告知]統合認証シンポジウム@佐賀大学で大学におけるSNSの活用について話します

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

昨年に引き続き今年も佐賀大学で開催される統合認証シンポジウムに登壇させていただくことになりました。

第11回統合認証シンポジウム
https://www.cc.saga-u.ac.jp/ias/#gsc.tab=0

日時:2018年3月1日(木)13:30~17:30
場所:佐賀大学教養教育大講義室


思えばLINEとAzure AD B2Cを組み合わせて学生や保護者などへのリーチャビリティの高いコミュニケーション基盤とそれを支えるID基盤のアイデアは昨年度の統合認証シンポジウムの後の宴会の場で産まれたものでした。最初は半分酔っ払いの思いつきでしたが、色々やってみると応用の範囲が思いのほか広くビジネスになってしまうのが面白いところです。

と、言うことで昨年度はエンタープライズID管理のトレンドの話をしましたが、今年は大学におけるSNS IDの活用についてお話しします。
他にも著名な先生方が大学における業務改善のお話しをしてくださったり、お馴染み日本マイクロソフトの中田さんがOffice365の多要素認証についてお話ししてくださるそうですので、大学だけでなく一般企業においても有益な内容になると思います。

既に申込みも始まっていますので、是非お申込みください。

2017年11月8日水曜日

[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

2017年9月7日木曜日

[リリース]LINE/Yahoo! IDを使ってOffice365へのログインを便利にする

こんにちは、富士榮@北海道です。

たまにはお仕事の話です。

本日、Azure AD B2CとLINE、Yahoo! JAPAN IDを連携させるソリューションを雇用主よりプレス発表しました。

SNSアカウントを活用するシステムの構築サービスを開始
http://www.ctc-g.co.jp/news/press/20170906a.html

Impressさん、日経電子版などのメディアに取り上げていただけました。

IT Leaders
 http://it.impressbm.co.jp/articles/-/14950
日経電子版
 https://www.nikkei.com/article/DGXLRSP456311_W7A900C1000000/
クラウドWatch
 http://cloud.watch.impress.co.jp/docs/news/1079437.html

本日北海道大学で開催されたCloud Week 2017で、本件に関する講演を行いデモを含めお披露目をさせていただきました。



簡単に内容を説明すると、Azure AD B2Cをカスタマイズし、
・LINEやYahoo! JAPAN IDなどの日本でメジャーなIdPへの対応
・Office365やG SuiteなどSAMLアプリケーションへの対応
・Microsoft Graphを利用し、Office365に届く重要なメールをLINEへも通知
・個別、一斉でのSNSへのメッセージ配信
というような仕組みをくみ上げたサービスとなっています。



こんな感じです。

動いている姿は以下です。


こんな流れです。
1.LINEで友達になる
2.LINEメニューから組織の払い出したID/PWDでOffice365へログインする
3.LINE IDと紐づけを行う
4.重要なメールはLINEへも通知する様に設定する
5.LINE IDでOffice365へシングルサインオンする
6.Office365へ重要なメールが届くとLINEのタイムラインへも通知される


他にも、公衆無線Wifiへのユーザ登録の簡素化などにも使えます。WeChatなどの中国のSNSにも対応しているので観光客向けのサービスとして無線LANを提供するようなケースを想定しています。


公衆無線Wifiを使った不正行為やいたずらが増えてきているらしいので、サービスレベルの向上(登録の簡素化)と利用者への到達性、証跡の確保の両立をしたい場合などはうまく使ってもらえると思います。

追記)
Cloud Week 2017で使った資料を公開したので、張り付けておきます。



尚、今後は以下のイベントで詳細を説明していきますので、是非ご参加ください。
・9/15 Japan Identity & Cloud Summit 2017
 https://nosurrender.jp/jics2017/
・10/13 CTCフォーラム 2017
 https://www.event-site.info/ctcforum2017/
・11/08 Tech Summit 2017
 https://www.microsoft.com/ja-jp/events/techsummit/2017/
・12/13 AXIES年次総会
 URL未定

また、個別に仕組みが知りたい、という方はぜひご連絡ください!
(標準のAzure AD B2Cでは出来ないことを独自拡張でかなりカバーしているので)

2017年6月30日金曜日

[Office365]Azure AD Connectの脆弱性?と最新版へ更新後の運用上の変化点

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

先日、Azure AD Connectに関するセキュリティ・アドバイザリが発表され、脆弱性対応版として最新版がリリースされました。
脆弱性対応のためとはいえ、一部ヘルプデスク運用が変わってくるので、Office365やAzure ADの管理者の方は十分に注意して運用マニュアルの修正などを行う必要があります。

 セキュリティ・アドバイザリ 4033453
  Azure AD Connect の脆弱性により特権が昇格される
  https://technet.microsoft.com/ja-jp/library/security/4033453

 最新ビルド(1.1.553.0)
  https://www.microsoft.com/en-us/download/details.aspx?id=47594

しかし、発表された内容を見ていると、どちらかというと脆弱性というよりも単に不適切な運用をしているだけじゃ、、、という話なので内容を解説してみたいと思います。

また、アドバイザリの中では対応策として、最新ビルドにバージョンアップすることが推奨されていますが、単にバージョンアップしただけでは環境によっては不具合が出ることもあるので、その辺りも解説しておきます。

最後に、Azure AD Connectの話としてアドバイザリが出ていますが、構成によってはFIM(Forefront Identity Manager)/MIM(Microsoft Identity Manager)にも当てはまる内容なので、FIM/MIMを使っている場合の構成の見直しポイントも簡単に。

◆脆弱性?の概要

簡単に言うと、パスワード書き戻しが有効になっているテナントにおいて、同期元のローカルActive Directory上で管理者権限を持っているユーザのパスワードをAzure ADやOffice 365上でリセットすると当然の事ながらローカルActive Directory上の管理者権限を持ったユーザのパスワードもリセットされてしまうので、悪意のあるAzure AD管理者がクラウド上でパスワードリセットを行うことによりローカルActive Directoryの管理者権限の奪取が可能になってしまう、という話です。

色々と前提があるので整理をしておきましょう。

  • 環境
    • パスワード書き戻しが有効になっていること
    • 管理者権限のあるユーザをAzure ADへ同期していること
    • 同期を実行しているユーザに特権ユーザに対するパスワードリセットの権限を付与していること(以下が典型的なケースです)
      • Domain AdminsやEnterprise Adminsのメンバにしている
      • 同期対象のOUの管理権限を同期ユーザへ委譲し、AdminSDHolderコンテナにパスワードリセット権限を付与している
  • 脆弱性利用者
    • 悪意のある管理者。オンプレミスのリソース(AD配下)へアクセスが可能なこと

※AdminSDHolerの話は国井さんのブログ記事を参照してください。
 

こうやって見ていくと当たり前すぎて、製品の不具合というより構成の問題という気がしてきます。
基本的に同期対象となっているOUに管理者権限を持ったユーザが存在するのは、、、ということです。同期してOffice365にログインするユーザなのであれば、恒常的にローカルActive Directoryの管理者権限を与える必要もないはずですし。

◆実際どうなるのか?

では、管理者権限を持ったローカルActive Directory上のユーザをAzure Active Directoryへ同期させてみて、パスワード・リセットをしてみます。

まずは、同期されたユーザ自身によるパスワード変更のパターンです。
アクセスパネルのプロフィール変更画面よりパスワードを変更します。

当然ですが、パスワードがオンプレミスに書き戻され、新しいパスワードでログインできるようになります。(試しにリモートデスクトップしてみるとちゃんとログインできます。当たり前ですが)


次に、SSPR(セルフ・サービス・パスワード・リセット)のシナリオを見てみます。いわゆる秘密の質問や認証用電話・メールなどを使ってパスワードを忘れた際に回復する、というシナリオです。
ログイン画面からパスワード忘れの場合のリンクをクリックすると回復画面に遷移するので、CAPTCHAを入力します。

秘密の質問への回答をします。


無事にパスワードがリセットされ、ローカルActive Directoryへパスワードが書き戻されます。

悪意のあるユーザが秘密の質問を推測してしまうケースは結構あるそうなので、第3者によってパスワードのリセットがされ、ローカル管理者の権限が奪取される、ということもあり得ますね。


最後に、管理者によるリセットです。
Azure AD Portalからユーザを選んでパスワードをリセットするやつですね。

これも管理者がリセットを行い、一時パスワードが割り当てられた段階でローカルActive Directoryのパスワードも変更されるので、一時パスワードでローカルリソースへアクセスできてしまいます。

そう、パスワード書き戻しの機能を普通に使っているだけです。
単に対象となっているユーザの中に管理者権限を持っているユーザが存在しただけです。

これが脆弱性なのか、と・・・。


◆Azure AD Connectのバージョンアップと注意点

どのみち、今後のバージョンのAzure AD Connectにはこの改修が入ってしまうので、仕方がないので対応版である1.1.553.0へバージョンアップします。

バージョンアップによる具体的な変更内容は、アドバイザリのサイトにもあるように以下の2点です。

  • 対象ユーザのadminCount属性の値を見てNullもしくは0なら一般ユーザとみなし、パスワード書き戻しを許可する
  • 対象ユーザが特権ユーザだった場合、パスワードリセットを要求したAzure ADユーザが、対象ユーザと同じユーザだった場合は書き戻す(メタバース上で要求したユーザと対象ユーザの関係を確認する)
    • この部分が原文・翻訳ともにものすごくわかりにくいです。
      • 日本語「要求したユーザーが対象のオンプレミス AD アカウントのオーナーであるかどうかを検証します。それは、対象のオンプレミス AD アカウントと、要求したユーザーの Azure AD アカウントの関係をメタバースで確認します。要求したユーザーがオーナーの場合、Azure AD Connect はパスワード ライトバック要求を許可します。そうではない場合、要求は拒否されます」
      • 原文「it then validates whether the requesting user is the owner of the target on-premises AD account. It does so by checking the relationship between the target on-premises AD account and the Azure AD account of the requesting user in its Metaverse. If the requesting user is indeed the owner, Azure AD Connect permits the Password writeback request. Otherwise, the request is rejected」
    • このオーナー(is the owner)というのが何を指すのか、が全く分からず、ローカルAD上のOUや対象ユーザのセキュリティ構成でオブジェクトのオーナーにしてみたり、と色々とやったのですが、結局オーナー=自身のアカウント、というオチだと思います。#違ったらご指摘ください。


早速バージョンアップを行います。


無事に1.1.553.0になりました。


この状態でユーザ自身でのパスワード変更をAzure AD側で行います。


ここは問題なく変更、書き戻しされます。

同様に自身によるパスワード・リマインドでも問題なく変更、書き戻しされます。

次に管理者によるリセットです。
見事に失敗します。

この時、イベントログには特権ユーザに対するパスワードリセットが拒否された旨、記録されます。
このAdminUpnとうのがリセットを要求した管理者ユーザ、そのあとのUserPrincipalNameが対象のユーザでこの2つのUPNが合致しないとリセット・書き戻しは行われません。


ちなみに、対象ユーザが一般ユーザの場合は従来通り問題なく管理者によるパスワード・リセットを行うことが可能です。

つまり、今後は運用を行う上で、ローカルActive Directory上で管理者権限を持っているユーザについては自分自身でしかパスワード・リセットが出来ない、ということになりますので、従来のヘルプデスク等の運用を変えなければなりません。
この点が最大の注意点です。


◆最後に。FIM/MIMユーザへ

今回「脆弱性」として取り上げられた仕組みは基本的にFIM/MIMにおいても同じですので、管理者権限を持つアカウントのパスワードを、悪意のある別の管理者がリセットすることが出来ます。これを製品の脆弱性や不具合と呼ぶのは微妙ですが、FIM/MIMにおいては今回Azure AD Connectが行った対応は入っていませんので、管理者権限を持つユーザについては自分自身でしかパスワードを更新できない様にMPRを工夫する、などの対応が必要となります。


2017年4月5日水曜日

Office365管理者は要対応)UPNとProxyAddress重複オプションの強制変更がいよいよ開始

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

以前紹介したAzure AD Connectでのディレクトリ同期時にUPNやProxyAddressが重複しないように自動的にサフィックスをつけてくれるオプションがいよいよ全テナントで強制的に有効になるようです。

 以前の紹介記事
 [Azure AD/Office365]管理者は要注意。ディレクトリ同期に関する仕様変更
 http://idmlab.eidentity.jp/2016/09/azure-adoffice365.html

簡単に内容をリマインドしておくと、複数のオンプレミスADから単一のAzure ADディレクトリへ同期したり、オンプレミスのUPN以外の属性(例えばメール属性)をAzure ADのUPNにマッピングするなど属性のユニーク性が担保されない環境で運用を行う際、ディレクトリ同期時にAzure AD側でUPNを自動的に「ユーザ名+4桁のランダム数値@デフォルトドメイン名」という様に変更する、というオプションが追加されました。
(UPN版とProxyAddress版の2つのオプションがあります)

このオプションが有効だとディレクトリ同期時の重複エラーを抑制することはできますが、勝手にUPNが書き換わってしまうのでオンプレミスのディレクトリの状態によっては若干困ることがあるので、昨年発表された段階では強制的に有効化されることはなく、しばらくは猶予期間が作られました。

しかし、この4月から遂に強制変更が開始されるようです。

4月1日前後に以下のメールが管理者宛てに来た場合は、メールに記載の日程から強制的に有効化されます。私のテナントの場合は4/19から強制有効化されるようです。
(以外と急でした・・・)

タイトル:New Identity Synchronization Feature Being Enabled - Duplicate Attribute Resiliency
差出人:MSOnlineServicesTeam@microsoftonline.com




急ぎ、自社のディレクトリ構成を確認してUPNが急に変わった~~~というようなパニックに陥らないように準備しておきましょう。




2017年3月7日火曜日

[続報]Office365管理者は要対応。外部共有により不要なアクセス権が付与される

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

先日のポストでOffice365の外部共有を有効にした場合に意図しないアクセス権限がゲストユーザに付与されてしまう、という注意喚起をさせていただきました。

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


ポスト後も米国マイクロソフトの開発チームへフィードバックをしていたのですが、他の国でも同じ意見の管理者・技術者の方も多く、Azure Portalのディレクトリ構成情報へのアクセスに関するセキュリティ設定が追加されました。

このことにより、前回紹介した条件付きアクセスを使いAzure Portalへのゲストユーザのアクセスを拒否する対策(Azure AD Premium P1ライセンスが必要)を行う必要がなくなりました。

ただ、アクセスパネル経由のアクセスでディレクトリを切り替えることによりAll Usersへ割り当てられたアプリケーションが見えてしまったり、認可設定が不適切なアプリケーションへのアクセスを防ぐことはできないので、こちらは引き続き対応が必要です。


では、早速Azure Portalでディレクトリ構成情報へのゲスト・アクセスを防ぐ方法を紹介します。ちなみに今回さらに新たな設定項目が追加されており、自ディレクトリ内のユーザでも非管理者によるアクセスを防ぐことも可能になっています。

◆ゲストユーザによるディレクトリ構成情報へのアクセスを防止する

まずはゲストユーザがディレクトリ構成情報へのアクセスを防止するための設定です。

管理者がAzure Portalへアクセスし、Active Directoryを開き、[ユーザー設定]を開くと、外部ユーザの設定の中に「ゲストのアクセス許可を制限する」という設定項目が追加されています。デフォルトで[はい]が設定されており、既定でアクセス制限が有効な状態となっています。


同様に管理ポータルの設定に「Azure AD管理ポータルへのアクセスを制限する」という項目も追加されており、こちらの設定では非管理者ユーザが自ディレクトリであってもディレクトリ構成情報へアクセスすることを防ぎます。(こちらの初期値は[いいえ]なので必要であれば設定変更を行います)こちらは後述します。


前回のポストをした際は初期状態ではゲストユーザがAzure Portal経由でディレクトリ構成情報(ドメイン情報など)へアクセスできましたが、現在は初期状態でアクセス制限がかかっているため、同じようにアクセスすると以下の様なエラーが表示されてディレクトリ構成情報を開くことが出来ません。(Azure Portalまでは開きます。Active Directoryメニューを開くとこの状態になります)


前回紹介した条件付きアクセス機能を使ってAzure Portal自体へのアクセス拒否をした場合は以下のように認証後すぐにエラーが出るので若干動作が異なります。


◆非管理者ユーザによるディレクトリ構成情報へアクセスを防止する

次は、非管理者ユーザがディレクトリ構成情報へアクセスできないように設定を行います。先に書いた通り、今度は管理ポータルの項目の「Azure AD管理ポータルへのアクセスを制限する」を[はい]に設定します。


この状態で非管理者でAzure Portalへアクセス、Active Directoryを開くと先のゲストユーザによるアクセスの際と同様に以下のエラーが表示されアクセスがブロックされます。



◆とりあえずは安心?

これで一応最低限のLeast Privilegeの法則は守られてきていますが、冒頭にも述べた通り、アクセスパネル(https://myapps.microsoft.com)へのアクセスによりAll Usersに割り当てられたアプリケーションは見えてしまい、かつ認可設定が不十分だと使えてしまうので、こちらは引き続き注意をして行く必要があります。

日々設定項目が進化していくAzure ADですが、項目が増えていき複雑性が増していくことにより、自社にとって最適な設定が変化していくことにもなりますので、管理者の方は継続的にフォローアップをしていく必要がありそうです。


◆最後に告知

前回のポストや本ポストに記載したOffice365やAzure AD管理者が考えるべきセキュリティ設定について、3/11に開催されるOffice365勉強会でお話しします。

 案内・告知
 Japan Office365 User Groupのページ
 http://jpo365ug.com/o365-meeting/meeting-18/

今週末の開催となり、既にキャンセル待ちの状態ですがよろしければどうぞ。

2017年2月3日金曜日

[Azure AD/Office365]自社のテナント以外のOffice365やアプリケーションへのアクセスを制限する

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

Office365など、Azure Active Directory(Azure AD)をID基盤として利用しているアプリケーションの良さはインターネット上に認証基盤があることにより、インターネット上のどこからでもセキュアかつ確実にアプリケーションを利用することが出来る、という点です。
(現実にAzure ADと同じレベルの可用性、堅牢性を持つ認証基盤を自前で構築しようとすると莫大な手間と費用が掛かります)


しかし、その反面で、例えば自前や他社のOffice365へのアクセスも出来てしまうことになるので、OneDriveやSharePoint、Exchangeへアクセスして自由に情報を書き込んだりメールを送信したりできてしまい、意図しない情報漏えいにつながってしまう可能性があります。

これまでIT管理者はURLフィルタ製品などを使って例えば、outook.comへの社内からのアクセスを遮断する、というような対策をしてきましたが、この対策だと自社もOffice365を使ってoutlook.comへアクセスをさせたい、という場合にURLフィルタによるドメイン名判別では対策出来ないため、結果として制限を緩めざるを得ない、という状況に陥ります。

そこでAzure ADで新たにリリースされたのが「テナントへのアクセス制限」機能です。

この機能を使うと特定のAzure ADテナントでしか認証が出来なくなるので、他社や自前のOffice365へのアクセスはNG、自社のOffice365へはアクセス可能、という状態を作り出すことが出来ます。

 公式Blogのアナウンス
  New enhanced access controls in Azure AD: Tenant Restrictions is now Generally Available!
  https://blogs.technet.microsoft.com/enterprisemobility/2017/01/31/new-enhanced-access-controls-in-azure-ad-tenant-restrictions-is-now-generally-available/

 関連ドキュメント
  Use Tenant Restrictions to manage access to SaaS cloud applications
  https://docs.microsoft.com/en-us/azure/active-directory/active-directory-tenant-restrictions


動作の仕組みは非常に単純です。

自社のProxyサーバ等でhttpヘッダに「Restrict-Access-To-Tenants」をセットし、テナント名を値として設定してあげるだけです。

動作概要図:公式Blogより


◆動作イメージ

早速試してみます。

手元にあったsquidを使って構成しようかと思いましたが、面倒なのでChromeのExtension「modHeader」を入れてみました。(fiddlerでもよかったんですが)



これを使うと自由にHTTPヘッダを追加することが出来るようになるので、先ほどの「Restrict-Access-To-Tenants」を追加してみます。
こんな感じで設定すると、pharaoh.onmicrosoft.comにしかアクセスできなくなります。(複数のディレクトリへのアクセスをさせたい場合はカンマ区切りでテナント名を複数記述可能です)


この状態でヘッダがどうなっているかサーバ側でリクエストを見てみます。単純なCGIを使いました。


ちゃんとヘッダが設定されていることがわかります。


この状態で別のテナントへアクセスしてみます。

まず、Access Panelへアクセスしてみます。


別のテナントのユーザでサインインした段階でエラーが表示され、アプリケーションへアクセスが出来ないことがわかります。

同じく、Office365ポータルです。


こちらも同じです。


情報漏えいを防ぎつつ、自社でもOffice365を使いたい企業・組織ではこの機能を上手く使って行けるといいですね。







2017年1月10日火曜日

Office365管理者は要対応。外部共有により不要なアクセス権が付与される

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

OneDrive for Business上のコンテンツやSharePoint Onlineのチームサイトを他組織のユーザと共有をするB2Bシナリオで利用している企業・組織が増えている中、Office365(およびそのID基盤であるAzure AD)の構造上の問題により、意図しないアクセス権を外部ユーザへ付与してしまう場合があるので、注意喚起の意味で本エントリを書きます。

[3/7 Update]
一部修正が行われ、ポータルからのディレクトリ構成情報へのアクセスがデフォルトでブロックされるようになりました。
詳しくはこちらをご覧ください。
 http://idmlab.eidentity.jp/2017/03/office365.html

現在、この課題については米国マイクロソフトのAzure AD開発チームへエスカレーションしており早期の改善を求めていますが、場合によっては長期化する可能性もあるため、自組織でOffice365を管理しており、外部ユーザとのコンテンツ共有をエンドユーザへ開放している管理者は一読の上、対応を行うことをお勧めします。
(いわゆる製品やサービスの脆弱性の類ではないため)


◆課題の概要

OneDrive for Business上のコンテンツ共有やSharePoint Onlineのチームサイトへの招待を受けた外部ユーザは、共有されたコンテンツ以外にも、「Azure AD上ですべてのユーザに対して割り当てを行われたアプリケーションや、Azure Portalを経由したディレクトリ情報へのアクセスが許可されてしまいます。かつ、事前に共有した本人および管理者がこのことに気が付くことはほぼ不可能です(どこにもそのような記述はないため)」。

これは招待されたユーザが自組織でOffice365やAzure ADを使っておらず個人でマイクロソフトアカウントを使っている場合においても発生します。


◆実際の動き

実際にどのような動きになるのか、動画を撮っていますので、まずはこちらをご覧ください。
わかりにくいですが、以下が環境です。

<組織「eIdentity」:招待する側>
・Office365を運用しています
・一般ユーザ「test001@ems.adfs20.net」でOneDrive for Businessで外部ユーザ「test001@gapps21.adfs20.net」に対してコンテンツを共有します
・Azure AD上で「ts2016」というアプリケーションをAll Usersグループに対して公開しています

<組織「InternetWeek」:招待される側>
・Office365は使っていませんが、Azure ADを利用しています
 (マイクロソフトアカウントの場合も同じ動きになります)
・「test001@gapps21.adfs20.net」という一般ユーザが所属しています




単純にeIdentityテナントのユーザでOneDrive for Businessでフォルダを共有しただけなのに、共有前はInternetWeekテナントのユーザがアクセス出来なかったts2016アプリへアクセスが出来てしまい、かつAzure Portal経由でeIdentityディレクトリの構成情報(ドメイン一覧)が参照できてしまっています。
※アプリケーションのURLを知らなくてもアクセスパネル(https://myapps.microsoft.comへアクセスすると利用できるアプリケーション一覧が表示されてしまいます。
※SharePoint Onlineのチームサイトへの招待の場合は、アプリケーションアクセスは出来ませんが、Azure Portal経由でのディレクトリ情報の参照は可能な状態になります。
(「All Usersグループ」へ自動追加されないため)


ディレクトリ上(ドメイン一覧)の参照


アプリケーションへのアクセス

上記のスクリーンショットはいずれもゲストユーザによりアクセスした状態で撮っています。


管理者としては、特定のコンテンツのみの共有なら、、という気持ちで許可した外部共有がこのような形で他の情報へのアクセスへ影響を与えるということは意図していないことが多いと思われるため、非常に大きな問題となる可能性があります。


◆なぜ発生するのか

OneDrive for BusinessやSharePoint Onlineで外部ユーザを招待すると、招待されたユーザが招待したOffice365側のAzure AD上にゲストユーザとして登録されます。
これはAzure AD B2Bで外部ユーザを招待するのと同じ動作であり、Office365が内部的にAzure AD B2Bの機能を利用しているために発生しています。

そして現状では、ゲストとして登録されたユーザは、
1.ディレクトリへのサインイン(認証)
2.ディレクトリ上の自プロファイルへのアクセス
に加えて、
3.ディレクトリ構成情報へのアクセス(少なくともドメイン一覧の参照)
4.(場合により)All Usersグループへの自動登録
が行われてしまいます。

1、2については本来のゲストユーザとしてアクセスを行うために最低限必要な機能なので、仕方がありませんが、問題は3、4です。


◆Office365/Azure ADの内部構造の課題

ここまで見てきたとおり、Azure ADにゲストとして登録された外部ユーザが想定以上に権限を持ってしまっていることが根本的な課題です。
少なくとも、
・自プロファイル以外のディレクトリ情報へのアクセス
・ディレクトリに登録されたアプリケーションへのアクセス
はデフォルトでは禁止されるべきでしょう。

早々にマイクロソフトが対応してくれることを望みます。


◆推奨される対応

このような状況なので管理者が出来ることと出来ないことがあるのですが、少なくとも以下の対応をしておくべきでしょう。

1.ゲストユーザが自ディレクトリ上に存在するかどうかの確認

まず、自ディレクトリ上にゲストユーザが存在しているかどうかは定期的に確認をしておくべきでしょう。
以下のAzure Active DirectoryのPowerShellを使い、以下のコマンドレットを実行することでゲストの存在を確認できます。
Get-MsolUser | Where-Object { $_.userType -eq 'Guest' }



2.All Usersではなく、自ディレクトリ上の本来のメンバだけが含まれるグループの作成

動的メンバシップグループをカスタムで作成し、userType=Memberのユーザだけが所属する様に構成することで自ディレクトリ上で作成されたユーザのみが含まれるグループを作成することが可能です。


逆にuserType=Guestだけが含まれるグループを作成するとゲストだけが含まれるグループを作成することが出来ます。



3.All Usersグループへ割り当てられているアプリケーションの割り当て変更

All Usersグループへのアプリケーション割り当ては非常に便利なので使ってしまいがちなのですが、ここは先の2で作成したメンバだけが所属しているグループへの付け替えを検討しましょう。

こうしておけば、Azure ADからプロビジョニングを行っているアプリケーションであっても、ゲストユーザはプロビジョニングされませんし、アクセスパネル(https://myapps.microsoft.com)にもアプリケーションは出てきませんので安心です。

<変更前>

<変更後>



4.アプリケーション側でしっかり認可を行う

この問題は最終的にはアプリケーションの作りに依存するので、認証されただけでは利用できないようにアプリケーションを構成する(きちんと認可する)ことが最も大切です。

例えば、今回の動画の中でアクセスしている「ts2016」というアプリケーションはディレクトリ上にユーザが存在していれば使える、という簡易な実装にしてしまっているためゲストであっても使えてしまいます。

しかし、アプリケーション側の実装で、認証されてアクセスしてきたユーザへのアクセス制御を他の属性(所属など)を用いてしっかりと管理を行うことで、少なくとも重要なデータへのアクセスを防ぐことが出来ます。

5.ポータルへのアクセスを禁止する(要注意:影響度大)

設定を間違えると管理者でさえ管理ポータルへアクセスできなくなったり、他のAPIを使うアプリケーションへのアクセスが一切できなくなるので、この設定を行う場合は十分にテストを行った上で慎重に実施してください。著者は一切責任をとれません。

かなり強引なやり方ですが、条件付きアクセスを利用してゲストユーザからWindows Azure Service Management APIへのアクセスをブロックしてしまえば管理ポータルへのアクセスが出来なくなります。

以下の条件付きアクセスポリシーを作成します。
・Users and groups:All Guests(先ほど作成したゲストだけのグループ)
・Cloud apps:Windows Azure Service Management API
・Grant:Block access
・Enable policy:On






このポリシーを有効にすると、管理ポータルへアクセスしようとするとアクセスがブロックされます。

ディレクトリを切り替えようとすると、

アクセスがブロックされます。

◆今後の対応

現状、この動作はサービスの仕様の問題であり、いわゆるバグ等の不具合には該当しないためサービスのエンハンス要求を挙げている状態です。

この状態で出来ることは管理者の自衛が中心となりますので、動作および自テナントの状態をよく理解して運用をしていってください。

今後、動作に変更などあれば本ブログでも更新情報を発信していきたいと思います。