2016年9月30日金曜日

[Azure AD/Office365]管理者は要注意。ディレクトリ同期に関する仕様変更

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

Azure AD Connectを使ってオンプレミスのActive DirectoryからAzure ADへオブジェクトを同期する構成でAzure ADやOffice 365を運用している方にとって非常に大きなインパクトのある動作変更が予定されています。

これまでディレクトリ同期を行う際、しばしば問題になってきたのが、
①複数ドメインからの同期時のオブジェクト重複
②同期元ドメインでの識別子の変更時のクラウド側への反映
です。(もちろん他にもありますが)

これまでは①のオブジェクト重複が発生した際はディレクトリ同期エラーが発生し、対象オブジェクトの同期はスキップされてきました。


同じく②について、特定の条件(Office365を使っている、など)のユーザについてはオンプレミスのuserPrincipalNameを変更してもAzure AD/Office365上のユーザのuserPrincipalName(ログインID)は変更されませんでした。

それぞれの動作の詳細は後述しますが、この動作の制御パラメータの初期値が変更になっています。

◆変更点

2016年8月24日以降に新規に作成されたAzure ADディレクトリでは、①のオブジェクト重複に関するエラーを回避するロジックが走るようになっています。また、既存のディレクトリについても今後強制的に設定の変更が行われ、従来とは異なる挙動をすることになるので一部運用方法の変更が必要な場合があります。

同じく②についてもオンプレミスのuserPrincipalNameの変更がAzure AD/Office365へ反映されるように変更されています。
※ちなみに②については8/24以前にすでに変わっていた可能性があります。①のアナウンスを見て環境を比較していて気が付いたので。
※②は2015年6月~だったそうです。MVP渡辺元気さんに教えてもらいました!
 参考URL)
 http://answers.microsoft.com/ja-jp/msoffice/forum/msoffice_o365admin-mso_dirservices/%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88/8b7857a5-1afd-4532-84fa-4cc70253622d?auth=1

ディレクトリ同期機能2016年8月24日までに作成したディレクトリ2016年8月24日以降に作成したディレクトリ
重複属性の回復性FALSETRUE
userPrincipalNameの更新の同期FALSETRUE


ちなみに現在の設定がどのようになっているかはConnect-MsolServiceで接続した後で、Get-MsolDirSyncFeaturesで確認することが出来ます。

以下の図は8/24より前に作成したディレクトリ同期の機能の状態です。


こちらは8/24以降に作成したディレクトリ同期の機能の状態です。



良い機会なので、それぞれの機能について簡単に解説をしつつ、動きの違いを見ていきたいと思います。


◆重複属性の回復性

まずは、オブジェクトの重複回避機能です。Azure AD/Office365ではuserPrincipalNameおよびProxyAddressが複数のオブジェクトで重複することを許可していません。

しかし、例えばuserPrincipalNameをオンプレミスのADのuserPrincipalName属性以外の属性(例えばメールアドレスなど)を使ってディレクトリ同期を構成する場合、複数のユーザが同一のuserPrincipalNameを持ってしまうことがあります。
※現状はAlternative LoginIdや別の属性をAzure ADのuserPrincipalNameにマッピングしている構成では重複回避の機能は動作しないので、これまで通りエラーではねられます。ただ、ADでユーザを削除して、Azure ADのゴミ箱からユーザが削除される前に再作成、同期するなど、AD上のuserPrincipalName属性が重複するケース、またuserPrincipalNameが他のユーザのProxyAddressと重複するケースなどが該当します。

従来は先にあげた様にエラーが発生して該当するオブジェクトが同期されることはありませんでしたが、同期パラメータを変更することでオブジェクト同期を検知した時の動作を制御することが出来ます。

該当するパラメータは、
・DuplicateUPNResiliency
・DuplicateProxyAddressResiliency
の2つで、それぞれuserPrincipalNameの重複とProxyAddressの重複に対する動作を制御します。

例えば、DuplicateUPNResiliencyをtrueに設定すると重複するuserPrincipalNameを持つユーザを検知すると、
 ユーザ名+ランダムの4桁の数字@デフォルトドメイン名
というuserPrincipalNameが自動的に割り当てられます。


一応同期エラーのメールが飛んでくるので重複が発生したことはわかりますが、従来とは対応方法が変わるので要注意です。


尚、Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflictでエラーが起きているオブジェクト一覧を取得することも可能なので、メールだと気が付かない場合や自動的にアクションをしたい場合はスクリプト化をすることも可能です。


ちなみに、この重複回復機能は一旦trueに設定してもfalseに戻すことも現状(2016/09/30時点)は可能ですが、今後は戻すことはできなくなります。また、現在falseに設定されているディレクトリについて、強制的にtrueに設定変更がされるようなので、今のうちに運用への影響を洗い出して対応しておく必要があります。



◆userPrincipalNameの更新の同期

このパラメータは、オンプレミスのADのuserPrincipalName属性が変更された場合に、Azure AD側に変更を同期するかどうかを制御するものでした。

従来(SynchronizeUpnForManagedUsersがfalse)は以下の条件を満たさない限り、オンプレミスのADでuserPrincipalNameを更新してもAzure ADへ変更は同期されませんでした。

・ユーザが管理対象ユーザ(非フェデレーションユーザ)である
・ユーザにライセンス(Office365など)が割り当てられていない
 ※EMSなどAzure AD系ライセンスだけなら変更は同期される


同期ログを見ると更新がかかったように見えます。


しかし、Office365のライセンスが割り当てられているとuserPrincipalNameは変更されません。


しかし、新しく作成したディレクトリでは初期値がtrueなので、ライセンスの割り当て状況などにかかわらずオンプレミスのuserPrincipalNameの変更がAzure ADへも反映されます。つまり、従来は移行などの都合でオンプレミスのADのuserPrincipalNameを変更してもユーザがOffie365へのログインに使うIDへ影響はありませんでしたが、新しいディレクトリを使っているとログインIDが変更されます。

ちなみに旧UPNはエイリアスとして残ります。


尚、このパラメータは一度trueに設定すると二度とfalseへ戻せないので要注意です。
つまり、古いディレクトリを使っていてfalseを前提とした運用をしている場合は絶対にtrueに設定をしてはいけません。
(現在はまだアナウンスがありませんが、先の重複回避のパラメータと同様に、どこかのタイミングで強制的にtrueに変更されることも想像できます。今のうちにtrueになってもいいように運用を見直しておくべきかもしれません)


以下、参考ページです。頻繁にアップデートされるので更新情報に注意しておく必要があります。

Azure AD Connect 同期サービスの機能
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-aadconnectsyncservice-features/

ID 同期と重複属性の回復性
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-aadconnectsyncservice-duplicate-attribute-resiliency/


2016年9月28日水曜日

Windows Server 2016のリリースとハイブリッドID基盤

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

アトランタで開催中のIgniteのタイミングに合わせてWindows Server 2016が正式にリリースされました。

 公式ブログでのアナウンス
 https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016/

9月28日現在、評価版のダウンロードが先行して可能になっていますが、正式版の提供は10月に入ってからの様ですね。

と、いうことでとりあえず評価版をダウンロードしてセットアップし、ハイブリッドID基盤の構成を確認してみました。

以前Windows Server 2012R2のドメインコントローラとAzure AD、Windows 10を使って構成した構成ですね。

 [Windows 10/Azure AD]ハイブリッド環境におけるドメイン参加とシングルサインオン①
 http://idmlab.eidentity.jp/2016/01/windows-10azure-ad.html


結論から言うと特に変化点はありません。

以下のシナリオでいわゆるDesktop SSO(PCへのサインイン~ブラウザアプリケーションへのサインインがシームレスに行える)が実現できます。

- Windows 10へのサインインはPINで行われる
- ファイル共有へは従来通りKerberosで認証が行われる
- AD FSに関連づけられたアプリケーションへもKerberosで認証が行われる
- Azure ADに関連づけられたアプリケーションへはMicrosoft Passportで認証が行われる

軽く動画を撮ってみました。



ちなみに、このシナリオの中で1点Technical Preview 5のころのAD FSと異なるところは、ブラウザにEdgeを使ってもAD FSへのWindows統合認証ができるようになっているところです。

単純にWIASupportedUserAgentsにEdgeなどがデフォルトで追加されているだけですけどね。

PS C:\Users\Administrator> $a = (Get-AdfsProperties).WIASupportedUserAgents
PS C:\Users\Administrator> $a
MSAuthHost/1.0/In-Domain
MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Trident/7.0
MSIPC
Windows Rights Management Client
MS_WorkFoldersClient
=~Windows\s*NT.*Edge

そして、Technical Previewから変わらずに残念だったのが、AD FSの認証方式にMicrosoft Passportが選択できるにも関わらず、ブラウザアプリケーションでのSSOシナリオでは相変わらず使えないところです。

ここは別途、もう少し詳しく状況を解説したいと思いますので、とりあえずPINでログインしてもAD FSに関連づけられたアプリケーションへはMicrosoft Passport認証ではなく、Windows統合認証でSSOするしか現状は無い、ということだけ覚えておいてください。



設定関係も簡単に動画に撮っています。



そのうちもう少し細かく解説を加えて、Channel 9の別館の方にもアップしたいと思います。


2016年9月27日火曜日

[MIM]Microsoft Identity Manager 2016 SP1がリリースされました

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

2016年に入ってから細かくPreviewビルドが公開されてきたMicrosoft Identity Manager 2016(MIM)ですが、ついにService Pack 1がRTMとなりました。

これまでのリリースの履歴。3月、4月、6月にPreview版が出ていました。
 [MIM]June CTPで遂にExchange Onlineをサポート
 http://idmlab.eidentity.jp/2016/06/mimjune-ctpexchange-online.html

 [MIM]Microsoft Identity Manager April 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/04/mimmicrosoft-identity-manager-april.html

 [MIM]Microsoft Identity Manager March 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/03/mimmicrosoft-identity-manager-march.html


ConnectサイトやMSDNには先行して公開されていましたが、Igniteに合わせてリリースノートを含め正式に公開されました。ざっくり触った感じでは、これまでのPreview版の総まとめになっており、目玉は以下の点くらいです。(あとはPAMフォレストの構成とかコマンドレットの追加などです)
  • ワークフロー用のメールボックスにExchange Onlineのサポート
  • Chrome/Firefoxのサポート
  • 新バージョンのOS、SQL Server、SharePointのサポート

リリースノートはこちら
https://docs.microsoft.com/en-us/microsoft-identity-manager/understand-explore/microsoft-identity-manager-2016-sp1-release-notes

取り敢えずインストールして動作を見てみました。

バージョン表記は「4.4.1237.0」となっています。
しかし相変わらずForefront Identity Manager 2010 R2のままなんですね・・・
<Synchronization Service>


<Portal>



インストール中のメールボックス指定。Exchange Onlineが選択できるようになっています。



Chromeでのアクセス。Webページダイアログが以前とは変わっており、IE以外でも使えるようになっています。


Firefoxだと若干怪しいです。




後は色々とバグフィックスなどはありますが、その辺りはリリースノートを参照ということで。

2016年9月22日木曜日

[MSA]同一メールアドレスでマイクロソフトアカウントとAzure ADアカウントを利用するリスク

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

先日、職場または学校のアカウント(Azure Active Directory/Office365で管理されているアドレス)で新規にマイクロソフトアカウントをサインアップすることが出来なくなった、という話を紹介しました。

[MSA]職場または学校のアカウントで新規サインアップが不可に
http://idmlab.eidentity.jp/2016/09/msa.html


MPNやXBoxの開発関係など、まだAzure ADでのサインインをサポートしていないマイクロソフトのサービスが存在しているにも関わらず上記のような制限をかけたことについて、乱暴で性急な対応だ!という声も各国から上がっていますが、今回は逆にこれまでの様に複数のアカウントで識別子が共通になってしまっている状態だと何が起きえるのか?について考えてみたいと思います。


◆マイクロソフトアカウントでもAzure ADアカウントの両方でアクセスできるサービスを用意する

一番手っ取り早い方法として、Azure ADのOpenID Connectのv2 エンドポイントを使ったアプリケーションを開発してみます。

詳細は省くのとかなり手抜きなコードなので色々とツッコミどころはありますが、こんなコードを書きました。




◆アクセスする

v2 エンドポイントを使ったアプリケーションにアクセスし、ログインID(メールアドレス)を入力すると、ログイン用のIDをマイクロソフトアカウントとAzure ADアカウントから選択する画面が出てきます。



◆Azure ADのアカウントでログインする

まずは、Azure ADのアカウントでログインします。

職場または学校アカウントを選択すると、Azure ADのログイン画面へ遷移します。


結果、Azure ADからユーザ名をはじめとするID情報が取得できます。(id_tokenをほどいているだけですが)

preferred_usernameにログインIDが入っていることがわかります。


◆マイクロソフトアカウントでログインする

次にマイクロソフトアカウントでログインしてみます。
先ほどのID選択画面で個人のアカウントを選択すると、マイクロソフトアカウントのログイン画面へ遷移します。


結果、同じくID情報が取得できます。

同じくpreferred_usernameにログインIDが入ってきています。



◆何を注意すべきなのか?

上記の例では、どちらのアイデンティティ・プロバイダでログインしても同じ値がpreferred_usernameに入ってきてしまっています。この状態でユーザをpreferred_usernameで識別してしまうと便利な反面、セキュリティ面で問題があると言えます。個人でID登録できるマイクロソフトアカウントと管理者が登録・管理を行うAzure ADではIDの管理レベルが全く異なるからです。

上記のようなアプリケーションはB2BやB2Cのシナリオではそれほど珍しいものではありません。
アプリケーションが内部で自社のドメインのユーザからのアクセスならば管理メニューを出して、それ以外なら一般向けのメニューしか出さない、というようなロジックを書くこともあるためです。

通常は、自社ドメインのユーザは退職したら削除または無効化されログインできなくなるので、一見セキュリティ上問題はないように思われますが、退職前に自社ドメインのメールアドレスでマイクロソフトアカウントを作ってしまっていた場合、退職後も継続して管理メニューにアクセスできてしまうことになります。


今後は、マイクロソフトが新規にAzure ADやOffice365で使っているドメインのアカウントでマイクロソフトアカウントを作成することを禁止したので、すでにAzure ADやOffice365にドメインを追加している場合は、問題は減っていくとは思います。

ただ、
・現時点でAzure ADやOffice365に自社ドメインを追加していない
・すでに自社ドメインのアドレスでマイクロソフトアカウントを登録してしまっているユーザがいる
といった場合も多々あるはずなので、少なくとも「いくら信頼しているアイデンティティ・プロバイダとは言え、識別子だけで認可をすべきではない」ということを十分に認識してサービスの開発を行うべきだと言えるでしょう。

ちなみに、以前発生したOffice365のSAML SPの脆弱性も本質的には同じような問題に起因していましたね。

参考)
 Office365のSAML脆弱性に見るマルチテナントSP実装時の注意点
 http://idmlab.eidentity.jp/2016/05/office365samlsp.html





2016年9月21日水曜日

[告知]ID Management Conference 2016で登壇します

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

先週末のID & IT Management Conference 2016に続き、10月初旬に東京と大阪でID Management Conference 2016が開催されます。

今年のID & IT Management Conference 2016では私はタイムテーブルに載らない裏トラックで新入社員~IDやセキュリティに関連する部門へ配属されて2~3年以内の方向けのセキュリティ・ID教育を担当しました。(完全招待性だったので、告知もしませんでした)



認証とID管理を新入社員向けに45分で解説するというのは中々のハードルでしたが、良い経験になりました。しかし、ID業界の老朽化や後継者問題が取り沙汰される昨今、非常に良い取り組みだと思いましたので、来年以降もこの取り組みは続けていきたいですね。



というわけで今年も無事にID & IT Management Conferenceは終了したのですが、早速次です。

次は、10月初旬に東京、大阪で開催されるID Management Conference 2016です。



以下、開催概要です。
今回、OpenIDファウンデーション・ジャパンでID連携・ID管理に関する解説をさせていただきます。東京はOpenIDファウンデーション・ジャパンの理事の林さん、大阪はEnterprise Identity Working Groupとして私が担当します。

イベント名:ID Management Conference 2016
イベントURL:
 http://www.f2ff.jp/idm/2016/

<大阪会場:富士榮>
日時:10月4日(火) ※セッションは17:05~17:45
場所:グランフロント大阪、ナレッジキャピタル・カンファレンスルーム
タイトル:エンタープライズにおける次世代ID連携標準
セッション内容:
 エンタープライズ企業においてもクラウド・サービスやモバイルデバイスの利活用に伴い、ネットワーク境界を超えてセキュアにID情報を連携する「ID連携」の重要性は増大しています。本セッションでは、OpenIDファウンデーション・ジャパンのEnterprise Identity Working Groupでの最新の成果物である「OpenID ConnectとSCIMのエンタープライズ利用と実装ガイドライン」を元に、企業におけるID連携の使いどころ、次世代のID管理/認証システムが対応すべきID連携標準技術について解説します。

<東京会場:林さん>
日時:10月5日(水) ※セッションは17:20~18:00
場所:KITTE、JPタワーホール&カンファレンス
タイトル:次世代ID連携標準によるAPIエコノミーの実現
セッション内容:
 パスワードによる認証が事実上有効性を失った今、認証の世界は大きく変わろうとしています。FacebookやGoogleを始めとしたソーシャルログインなどが台頭する中、ID連携への注目が高まると同時に、アイデンティティそして認証・認可の領域では、データ駆動社会の動きと共に様々な新しい動きもあり、制度や国際的な流れを踏まえて、APIを中心とした大きな動きが出てきています。本セッションでは、アイデンティティ分野の現在の状況と、技術的な動向、標準化の現状などを踏まえつつ、次世代のID管理/認証システムが対応すべきID連携標準技術について解説します。



開催まで約2週間ですが、ぜひ事前登録の上、ご来場ください。

2016年9月20日火曜日

[MSA]職場または学校のアカウントで新規サインアップが不可に

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

ID & IT Management Conference 2016の準備などで多忙だったので、色々とスルーしていた間にあった重要な発表を少しづつキャッチアップしていきたいと思います。

以下が9月上旬~中旬で発表された割と重要な発表です。(私基準です)

  1. マイクロソフトアカウント(MSA)へ職場または学校のアカウントで新規サインアップ不可に
  2. Azure Active Directory Premium P2の提供開始
  3. 新ポータルでAzure Active Directoryの管理が可能に
  4. MicrosoftとPing Identityの提携によるレガシーアプリへのSSO拡大
  5. Azure AD Connect 1.1.281.0のリリース


取り敢えず今回は1の「マイクロソフトアカウント(MSA)へ職場または学校のアカウントで新規サインアップ不可に」をお届けします。

9月15日に公式アナウンスが出てきました。(割と突然だったので私もびっくりしました)

 Cleaning up the #AzureAD and Microsoft account overlap
 https://blogs.technet.microsoft.com/enterprisemobility/2016/09/15/cleaning-up-the-azure-ad-and-microsoft-account-overlap/


早速内容を見ていきます。

◆これまでの課題

マイクロソフトのサービスを利用するには、職場また学校のアカウント、つまりOffice365やAzure Active Directory(Azure AD)で管理されているアカウント、もしくはマイクロソフトアカウント(従来のLive ID。MSA)を使ってログインする必要があります。

ただし、マイクロソフトアカウントはlive.comやoutlook.comなどマイクロソフトが用意しているドメイン以外に既存のメールアドレスを使ってサインアップすることも可能でした。


ここでOffice365やAzure ADのアカウントを使ってサインアップすると同じユーザ名のアカウントが職場または学校のアカウントおよびマイクロソフトアカウントの両方に出来上がることになり、マイクロソフトの提供するサービスへログインする際に以下のようなアカウント選択画面が表示されてしまいました。



これは一般利用者にとってわかりにくく、しばしば混乱を招いてきました。


◆今回のマイクロソフトによる対策のポイント

かなり乱暴な対策ではありますが、すでにOffice365やAzure ADで管理されているドメインのメールアドレスを使って、新規にマイクロソフトアカウントへサインアップすることが出来なくなりました。

これで新規ユーザは同じユーザ名でOffice365/Azure ADとマイクロソフトアカウントの両方にIDが作成されることは無くなりますので、ID選択画面が表示されることは無くなります。


では、既に作成済みのアカウントや、後からOffice365/Azure ADにドメイン追加されたアカウントの場合はどうなるんでしょうか?

結論、既存のマイクロソフトアカウントのIDを変更する、というのが答えです。


◆既存のマイクロソフトアカウントのIDを変更する

注意点を含む詳細はこちらのページで解説されていますので、確認して対応してください。

基本は既存のアカウントに新しいメールアドレスをエイリアスとして追加、プライマリ側と入れ替えた後、Office365/Azure ADと重複しているメールアドレスを削除するという方法です。


◆影響があるサービスがあるので注意

公式ページにも記載がありますが、職場のメールアドレスでサインアップしたマイクロソフトアカウントでないと利用できないマイクロソフトのサービスが一部あるので、職場のメールアドレスがOffice365/Azure ADで利用しているドメインと一致している環境においては、マイクロソフトアカウントのメールアドレスを切り替えるとそれらのサービスが使えなくなります。(新規にはサインアップすらできないので、当該環境において新規ユーザはそれらのサービスを使うことは出来なくなっています)

例えば、
・Windows Dev Center
・Microsoft Partner Network
などに影響があるようです。

また、既存のアカウントのメールアドレスを変更することによりデバイスのリセットなどをする必要がある場合もあるので、こちらも要注意です。

例えば、
・Windows Phone 8を使っている場合はデバイスのリセットが必要になります
・一部XBox開発ツールを使っている場合は別のIDになってしまいますので、実質アカウント作成し直しとなります
などが大きな影響といえます。


◆まとめ

MSALやv2エンドポイントなどAzure ADアカウントとマイクロソフトアカウントのコンバージが進む一方で、IDの重複問題が長年の懸案事項となっていたので、今回の対策は長い目で見れば非常に有益なことだと思います。
そもそも同じ識別子を持つ複数のIdPで同じサービスが利用できてしまうというのは、保証レベルの面などセキュリティ的にも重大な問題でした。例えば、個人の自己申告でサインアップできてしまうマイクロソフトアカウントを在職中に作成、退職後も継続的に利用しているケースにおいて、いくらAzure AD側で退職アカウントを削除したとしても、MSALを使ったコンバージ・アプリケーションへ職場のメールアドレスを使ったサインインが継続的に可能になってしまう、という課題です。

他方でMPNなど重要なサービスが職場メールアドレスのMSAでしかアクセスできないなど、過渡期に解決すべき課題もあるので、若干性急な気もした今回の対策ですが、早期に各サービス側での対応をすすめ、一日も早く綺麗な姿でサービスを提供できるようになってもらいたいものです。