こんにちは、富士榮です。
4年ぶりの開催となる、OpenID Summitが来月開催されます。
海外勢は米国OpenID FoundationやPing Identity、Microsoftから大御所が、もちろん日本国内からも総務省、経済産業省といったGovernment系をはじめ、アイデンティティ関係やPKI関係の各種重鎮が終結する超豪華イベントです。
公式サイト:参加登録はこちらから。
https://openid.or.jp/summit/2015/index.html
私も末席ながらエンタープライズ領域でのフェデレーション活用やIDaaSの可能性についてAzure Active Directory(Azure AD)を例にお話しさせていただきますが、個人的に注目しているセッションは、Microsoft CorporationのAnthony NadalinによるFIDO 2.0のセッションです。
FIDO 2.0といえばWindows 10のAzure AD Joinで使われているMicrosoft Passportの核となるテクノロジです。
私も過去に何度かこのブログでポストしたり、idconなどでお話しさせていただいたことがあるテーマですが、実際にMicrosoftで技術の標準化を進めているAnthony NadalinからFIDO 2.0の話が聞けるのは非常に貴重な機会になると思います。
参考)
[FIDO/Windows10]idcon vol.20(別名fidcon)が開催されました
http://idmlab.eidentity.jp/2015/05/fidowindows10idcon-vol20fidcon.html
[Windows10]デバイス&サービス間のシングルサインオンの仕組み
http://idmlab.eidentity.jp/2015/05/windows10.html
[Windows10/AAD]クラウド・ドメイン参加を試す
http://idmlab.eidentity.jp/2015/02/windows10aad.html
参加費用も無料ですし、ぜひご参加ください。
2015年10月19日月曜日
[AzureAD]Azure AD Domain Servicesを使って既存サービスをクラウド上へ移行する際の注意事項
こんにちは、富士榮です。
先日パブリック・プレビューが公開されたAzure Active Directory Domain Services(Azure AD DS/AADDS)を使うことでオンプレミスのActive Directoryが提供してきたドメイン・サービス(ドメイン参加やグループポリシーなど)を、同一Azure VNET上のマシンに対して提供することが可能になりました。
公式blogでのアナウンス
Azure AD Domain Services is now in Public Preview ? Use Azure AD as a cloud domain controller!
http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx
尚、基本的なセットアップ方法や簡単な注意点についてはMicrosoft Regional Directorの亀渕さんが紹介しているので、そちらを参考にしてください。
ブチザッキ
Azure Active Directory Domain Services (Public Preview)
https://buchizo.wordpress.com/2015/10/15/azure-active-directory-domain-services-public-preview/
公式ドキュメントや亀渕さんのblogにも書かれているとおり、AADDSで提供されているドメインサービスには一部制限があります。
・サイトの構成やマルチフォレスト・マルチドメインなどのドメイン構成自体のカスタマイズはできない
・グループポリシーはビルトインのもののみで、カスタマイズができない
・直接ユーザやグループをMMCで管理できない
・管理者(ドメイン参加権限くらいしかない)はAAD DS Administratorsグループに入る
などなどです。
オンプレミスの既存サービスをクラウドへ持って行こうとすると、これらの制限によって少々困ることが出てくるので移行計画を立てる際は注意が必要です。
私が試していて特に困った点は「Domain Admins」権限をユーザに付与できない、という点です。
既存アプリケーションの中にはActive Directory上のオブジェクトを参照・更新するものもあり、それらのアプリケーションは多くの場合Domain Admins権限を要求します。
(アプリケーションの作りの問題ではありますが・・・)
ちなみにAzure AD DSのDomain Adminsにはdcaasadminというユーザが固定でメンバ登録されていますが、このユーザのパスワードがわからないので、なんともなりません。
もちろんこのユーザのパスワードを更新することはできないようになっていますし、Azure AD側への同期もされていません。
以下、Domain Admins権限を求める例です。
1.メンバサーバへのリモート・デスクトップ・ログイン
これは回避策がありますが、サーバをAzure仮想マシンで構築し、Azure AD DSへ参加させた後、サーバへリモート・デスクトップでAzure AD DS上のユーザでログインしようとしても拒否されてしまいます。
これはメンバサーバへのリモート・デスクトップ接続が初期状態でビルトインのAdministratorsのみに許可されているためです。Domain Adminsはドメインに参加した時点でビルトインAdministratorsグループに登録されるため、オンプレミス環境ではDomain Adminsのメンバでサーバを管理すれば特に困ることはありませんでした。
ところが、Azure AD DSでは先述の通り、Domain Adminsは使えないので、まずはローカル・アカウントでログインし、コンピュータの管理からローカルのAdministratorsにリモート・デスクトップ接続したいユーザもしくはグループを追加する必要があります。
2.Domain Admins権限を要求するアプリケーションを導入する
これは現状どうしようもありません。アプリケーションが固定でDomain Admins権限を要求してくるので、なんともなりません。
例えば、Active Directory Federation Services(AD FS)などマイクロソフトのサービスはこの時点でほぼ全滅です。(この辺りはAzure ADを使えってことなんでしょうけど)
今後正式版がリリースされるまでにうまく回避策が出てくるといいですねぇ。。
先日パブリック・プレビューが公開されたAzure Active Directory Domain Services(Azure AD DS/AADDS)を使うことでオンプレミスのActive Directoryが提供してきたドメイン・サービス(ドメイン参加やグループポリシーなど)を、同一Azure VNET上のマシンに対して提供することが可能になりました。
公式blogでのアナウンス
Azure AD Domain Services is now in Public Preview ? Use Azure AD as a cloud domain controller!
http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx
尚、基本的なセットアップ方法や簡単な注意点についてはMicrosoft Regional Directorの亀渕さんが紹介しているので、そちらを参考にしてください。
ブチザッキ
Azure Active Directory Domain Services (Public Preview)
https://buchizo.wordpress.com/2015/10/15/azure-active-directory-domain-services-public-preview/
公式ドキュメントや亀渕さんのblogにも書かれているとおり、AADDSで提供されているドメインサービスには一部制限があります。
・サイトの構成やマルチフォレスト・マルチドメインなどのドメイン構成自体のカスタマイズはできない
・グループポリシーはビルトインのもののみで、カスタマイズができない
・直接ユーザやグループをMMCで管理できない
・管理者(ドメイン参加権限くらいしかない)はAAD DS Administratorsグループに入る
などなどです。
オンプレミスの既存サービスをクラウドへ持って行こうとすると、これらの制限によって少々困ることが出てくるので移行計画を立てる際は注意が必要です。
私が試していて特に困った点は「Domain Admins」権限をユーザに付与できない、という点です。
既存アプリケーションの中にはActive Directory上のオブジェクトを参照・更新するものもあり、それらのアプリケーションは多くの場合Domain Admins権限を要求します。
(アプリケーションの作りの問題ではありますが・・・)
ちなみにAzure AD DSのDomain Adminsにはdcaasadminというユーザが固定でメンバ登録されていますが、このユーザのパスワードがわからないので、なんともなりません。
もちろんこのユーザのパスワードを更新することはできないようになっていますし、Azure AD側への同期もされていません。
以下、Domain Admins権限を求める例です。
1.メンバサーバへのリモート・デスクトップ・ログイン
これは回避策がありますが、サーバをAzure仮想マシンで構築し、Azure AD DSへ参加させた後、サーバへリモート・デスクトップでAzure AD DS上のユーザでログインしようとしても拒否されてしまいます。
これはメンバサーバへのリモート・デスクトップ接続が初期状態でビルトインのAdministratorsのみに許可されているためです。Domain Adminsはドメインに参加した時点でビルトインAdministratorsグループに登録されるため、オンプレミス環境ではDomain Adminsのメンバでサーバを管理すれば特に困ることはありませんでした。
ところが、Azure AD DSでは先述の通り、Domain Adminsは使えないので、まずはローカル・アカウントでログインし、コンピュータの管理からローカルのAdministratorsにリモート・デスクトップ接続したいユーザもしくはグループを追加する必要があります。
2.Domain Admins権限を要求するアプリケーションを導入する
これは現状どうしようもありません。アプリケーションが固定でDomain Admins権限を要求してくるので、なんともなりません。
例えば、Active Directory Federation Services(AD FS)などマイクロソフトのサービスはこの時点でほぼ全滅です。(この辺りはAzure ADを使えってことなんでしょうけど)
今後正式版がリリースされるまでにうまく回避策が出てくるといいですねぇ。。
2015年10月12日月曜日
[MIM]同期方法(ポリシーベース、Scope Filterベース)を比較する
こんにちは、富士榮です。
Microsoft Identity Manager 2016(MIM)を使って外部システムへIDをプロビジョニングするためには2つの方法があります。(コードベースを合わせると正確には3つですが、ここでは開発を伴う方法は除外して考えます)
◆2つの同期方式
①ポリシーベースのプロビジョニング
一つ目は、Forefront Identity Manager 2010から実装された管理ポリシールール(Management Policy Rule / MPR)、セット(SET)、アクションワークフロー(Action Workflow / WF)、送信同期規則(Outbound Synchronization Rule / OSR)を組み合わせて行う方法です。
ざっくり説明すると、
・一定の条件に当てはまるリソース(ユーザなど)を
・同期規則に割り当てる
ことによって外部システムへプロビジョニングを行います。
この条件をSET、外部システムとの同期するためのルール(属性マッピングなど)をOSR、同期規則へ割り当てるアクションの定義をWF、全体をまとめてMPR、と呼びます。
内部的には、以下の処理が行われます。
キモはリソースがMetaverseに同期されたタイミングでリソースのERE属性が参照しているEREを見て適用するOSRを設定する、という部分です。(処理7の部分)
②Scope Filterベース
こちらはForefront Identity Manager 2010 R2から実装された少しシンプルな同期方法です。
OSRを適用するための条件(Scope Filter)を定義しておくことにより、Metaverseにリソースが同期された段階で条件にマッチすると即OSRが適用され、対象の外部システム向けのCSへリソースが同期されます。
ポリシーベースの同期ではEREオブジェクトがリソースとOSRの間を取り持っていたのに対して、とりあえずMetaverse上のすべてのリソースに対してScope Filterへの適合を確認する、という点で非常にシンプルです。
◆同期方式の機能面での比較
最大の違いは、デプロビジョニング(外部システムからリソースを削除する)ができるか、できないか、です。
ポリシーベースではSET条件に当てはまらなくなった場合に何を行うか?についても定義ができるので、デプロビジョニングするためのWFを作成し、MPRを定義しておけば外部システムからリソースを削除する、などの細かい制御を行うことが可能です。
ざっくりまとめると以下のような比較になります。
◆同期方式を性能面で比較
これは圧倒的に差があります。
ポリシーベースだと一旦FIM Serviceにリソースが入ってからでないとリソース割り当ての判断ができないため、処理的にはかなりのオーバーヘッドとなります。また、リソースとは別にERE自体がオブジェクトとして生成され、Metaverse上へ同期されるため、オブジェクト数が外部システムの数分増えていくため、データベースの性能を圧迫します。
一方でScope FilterベースだとリソースがMetaverse上に同期された段階でScope Filterが評価され、適用されるOSRの判断が行われるので無駄がありません。
実際の性能測定をすると以下のような結果となります。
ADにユーザがプロビジョニングされて使えるようになるまで、という条件ですが10,000ユーザで1時間以上の差がついています。
属性条件
・Macbook Air上のVMware Workstationで計測
・ホストスペック
OS : Windows 10 Pro x64
CPU : Core i7-4650U 2.3GHz
メモリ : 8GB
ディスク : SSD
VM : VMware Workstation 10
・ゲストスペック
OS : Windows Server 2012 R2
CPU : 1vCPU(2core)
メモリ : 4GB
・ミドルウェア(すべて1台に同居)
SQL Server 2014 Standard SP1
SharePoint Foundation 2013 SP1
Active Directory Domain Service
Microsoft Identity Manager 2016
- Synchronization Service
- MIM Service
- MIM Portal
・同期条件
入力(HR相当):CSVファイル
出力:ADDS
ユーザ件数:10,000
同期属性:
- Account Name
- Display Name
- First Name
- Last Name
- Department
同期条件:Department属性値がEIDENTITYとなっていること
◆どちらの方式を使うべきなのか
ケースバイケースなので、なんとも言えませんが例えばActive Directoryなど、ほぼ全員がプロビジョニングされてデプロビジョニングすることがない(無効化はするが実削除はしない)ようなケースであればScope Filterベースがあっていると思います。
今回のテスト環境は非常にプアな環境だったこともあり、データベースでロックが発生してしまい10,000ユーザをポリシーベースで同期しようとしただけでエラーが発生してしまったりしていることもあり、まずはScope Filterベースで設計できないかどうかを検討した上で、どうしても問題がある場合に限ってポリシーベースを使うというのが良いのかもしれません。
Microsoft Identity Manager 2016(MIM)を使って外部システムへIDをプロビジョニングするためには2つの方法があります。(コードベースを合わせると正確には3つですが、ここでは開発を伴う方法は除外して考えます)
◆2つの同期方式
①ポリシーベースのプロビジョニング
一つ目は、Forefront Identity Manager 2010から実装された管理ポリシールール(Management Policy Rule / MPR)、セット(SET)、アクションワークフロー(Action Workflow / WF)、送信同期規則(Outbound Synchronization Rule / OSR)を組み合わせて行う方法です。
ざっくり説明すると、
・一定の条件に当てはまるリソース(ユーザなど)を
・同期規則に割り当てる
ことによって外部システムへプロビジョニングを行います。
この条件をSET、外部システムとの同期するためのルール(属性マッピングなど)をOSR、同期規則へ割り当てるアクションの定義をWF、全体をまとめてMPR、と呼びます。
内部的には、以下の処理が行われます。
- 人事などからリソースがFIM(CS)へインポートされる
- Metaverseへ同期されるタイミングでISRによりFIM ServiceのCSへ同期される
- FIM ServiceへExportされる
- リソースがSETの条件に当てはまるかどうか評価される
- FIM Service上でリソース毎にExpected Rules Entry(ERE)が生成され、リソースに参照型の属性としてEREが割り当てられる
- FIM Service上のリソースとEREがImportされ、Metaverseに同期される
- EREによりMetaverse上のリソースとOSRが紐づけられて外部システム用のConnector Spaceへ同期される
- 外部システム用のMAでExportを行うことで外部システム上にプロビジョニングされる
キモはリソースがMetaverseに同期されたタイミングでリソースのERE属性が参照しているEREを見て適用するOSRを設定する、という部分です。(処理7の部分)
②Scope Filterベース
こちらはForefront Identity Manager 2010 R2から実装された少しシンプルな同期方法です。
OSRを適用するための条件(Scope Filter)を定義しておくことにより、Metaverseにリソースが同期された段階で条件にマッチすると即OSRが適用され、対象の外部システム向けのCSへリソースが同期されます。
ポリシーベースの同期ではEREオブジェクトがリソースとOSRの間を取り持っていたのに対して、とりあえずMetaverse上のすべてのリソースに対してScope Filterへの適合を確認する、という点で非常にシンプルです。
◆同期方式の機能面での比較
最大の違いは、デプロビジョニング(外部システムからリソースを削除する)ができるか、できないか、です。
ポリシーベースではSET条件に当てはまらなくなった場合に何を行うか?についても定義ができるので、デプロビジョニングするためのWFを作成し、MPRを定義しておけば外部システムからリソースを削除する、などの細かい制御を行うことが可能です。
ざっくりまとめると以下のような比較になります。
比較項目 | ポリシーベース | Scope Filterベース |
---|---|---|
プロビジョニング条件判断 | MPR、SET、WFの組み合わせにより適用するOSRを決定する | OSR自体に設定された条件(Scope Filter)に合致するすべてのMetaverse上のリソースにOSRを適用する |
複雑な条件の設定 | 可能 (SETの条件はかなり柔軟、かつ手動でメンバ追加を行うことも可能) | 不可能 (基本はリソースの属性の値による判断で、複数の条件を設定する場合はすべてAND条件となる) |
FIM Service上へのリソースの同期の要否 | 必要 | 不要 |
生成されるオブジェクトの数 | 多い(EREオブジェクトが必要) | 少ない |
デプロビジョニング | 可能 (デプロビジョニング用のMPRとWFを定義することで外部システムからリソースを削除できる) | 不可能 (Scope Filterに合致しなくなったリソースに関しては同期されなくなるだけで外部システムからリソースは消えない) |
管理面 | FIM Portal上のユーザに対して適用する予定のルール(ERE)と実際に適用されたルール(DRE)が割り当てられるので、トラブルシュートが楽 | FIM Portal上で対象ユーザにどの同期規則が適用されているのかの判断がしづらい(FIM Serviceへユーザを同期しないことも可能になってしまうため。FIM Serviceへ同期されたユーザについてはDREを設定することで状態確認は可能) |
◆同期方式を性能面で比較
これは圧倒的に差があります。
ポリシーベースだと一旦FIM Serviceにリソースが入ってからでないとリソース割り当ての判断ができないため、処理的にはかなりのオーバーヘッドとなります。また、リソースとは別にERE自体がオブジェクトとして生成され、Metaverse上へ同期されるため、オブジェクト数が外部システムの数分増えていくため、データベースの性能を圧迫します。
一方でScope FilterベースだとリソースがMetaverse上に同期された段階でScope Filterが評価され、適用されるOSRの判断が行われるので無駄がありません。
実際の性能測定をすると以下のような結果となります。
ADにユーザがプロビジョニングされて使えるようになるまで、という条件ですが10,000ユーザで1時間以上の差がついています。
属性条件
・Macbook Air上のVMware Workstationで計測
・ホストスペック
OS : Windows 10 Pro x64
CPU : Core i7-4650U 2.3GHz
メモリ : 8GB
ディスク : SSD
VM : VMware Workstation 10
・ゲストスペック
OS : Windows Server 2012 R2
CPU : 1vCPU(2core)
メモリ : 4GB
・ミドルウェア(すべて1台に同居)
SQL Server 2014 Standard SP1
SharePoint Foundation 2013 SP1
Active Directory Domain Service
Microsoft Identity Manager 2016
- Synchronization Service
- MIM Service
- MIM Portal
・同期条件
入力(HR相当):CSVファイル
出力:ADDS
ユーザ件数:10,000
同期属性:
- Account Name
- Display Name
- First Name
- Last Name
- Department
同期条件:Department属性値がEIDENTITYとなっていること
◆どちらの方式を使うべきなのか
ケースバイケースなので、なんとも言えませんが例えばActive Directoryなど、ほぼ全員がプロビジョニングされてデプロビジョニングすることがない(無効化はするが実削除はしない)ようなケースであればScope Filterベースがあっていると思います。
今回のテスト環境は非常にプアな環境だったこともあり、データベースでロックが発生してしまい10,000ユーザをポリシーベースで同期しようとしただけでエラーが発生してしまったりしていることもあり、まずはScope Filterベースで設計できないかどうかを検討した上で、どうしても問題がある場合に限ってポリシーベースを使うというのが良いのかもしれません。
2015年10月10日土曜日
[MIM]同一サーバにMIM Service/PortalとSynchronization Serviceを同居する際の注意点
こんにちは、富士榮です。
本番環境ではMicrosoft Identity Manager(MIM)Synchronization ServiceとMIM Service/Portalは分離すると思うので、あまり問題になることはありませんが、開発や検証環境では一台のサーバ上に環境を作ることも多いと思います。
しかし、本番環境になるべく近い構成にするためにMIM Service/PortalのベースとしてStandard/Enterprise EditionのSharePointをインストールすると、同梱されているUser Profile Service(実体はFIM Synchronization Service)がインストールされてしまいます。
このことにより、MIM Synchronization Serviceの構成が壊れてしまうので、検証環境等でMIM Synchronization ServiceとMIM Service/Portal(およびベースとなるSharePoint)を同一のサーバにインストールする場合は注意が必要です。
(SharePoint FoundationにはUser Profile Serviceが入っていないので問題は起きません)
Microsoft Identity Manager 2016 のポータル
早速見ていきましょう。
◆発生条件
・MIM Synchronization ServiceとMIM Service/Portalを一台のサーバに同居する
・Standard/EnterpriseエディションのSharePointを利用する
◆発生する不具合
・MIM Synchronization Serviceをインストールした後でSharePointをインストールするとSynchronization Service Managerが起動しなくなる。
・サービス実行ファイルのパスがSharePoint側のFIM Synchronization Serviceになってしまう
・サービス実行アカウントが「\」となってしまう
・サービス起動設定が無効化となってしまう
・アカウントをSynchronization Service用に設定しなおしてもAccess Deniedエラーが出てサービスが起動しない
◆対策
結局のところ、サービスの設定のパス関係がすべて置き換わってしまっているので修正をする必要があります。
レジストリをガンガン触りますので、基本自己責任です。
①レジストリのサービス関連ファイルのパス修正
対象キー①
HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationServive\ImagePath
修正前)
"C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\Bin\miiserver.exe"
修正後)
"C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe"
対象キー②
HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationServive\Parameters\Path
修正前)
C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\
修正後)
C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\
※その他、Management Agent関連のパスも修正が必要になる場合もあります。
②サービス実行ユーザの修正
「\」となっているのでSynchronization Service実行ユーザに変更する
③パーミッションの変更
上記①、②でサービス自体の修正は終わりなのですが、どうやらPeopleILMなどSharePoint側の設定で消えないものがあるらしく、Synchronization Service起動ユーザにSharePoint側のSynchronization Serviceのパスへの読み取り・実行権限を与える必要があります。
C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\
一応ここまでで使えるようになります。
◆他の解決方法
インストールする順番をSharePoint⇒MIM Synchronization Serviceの順にすることでSharePoint側の設定を逆にMIMが上書きするのでレジストリの修正は不要になります。
が、やはりPeopleILM関係の問題は出るので、上記③の権限付与は必要です。
◆根本的な解決方法
「SharePoint Foundationを使う」。これに限ります。
基本は同居構成の場合はSharePoint Foundationを使いましょう。
本番環境ではMicrosoft Identity Manager(MIM)Synchronization ServiceとMIM Service/Portalは分離すると思うので、あまり問題になることはありませんが、開発や検証環境では一台のサーバ上に環境を作ることも多いと思います。
しかし、本番環境になるべく近い構成にするためにMIM Service/PortalのベースとしてStandard/Enterprise EditionのSharePointをインストールすると、同梱されているUser Profile Service(実体はFIM Synchronization Service)がインストールされてしまいます。
このことにより、MIM Synchronization Serviceの構成が壊れてしまうので、検証環境等でMIM Synchronization ServiceとMIM Service/Portal(およびベースとなるSharePoint)を同一のサーバにインストールする場合は注意が必要です。
(SharePoint FoundationにはUser Profile Serviceが入っていないので問題は起きません)
Microsoft Identity Manager 2016 のポータル
早速見ていきましょう。
◆発生条件
・MIM Synchronization ServiceとMIM Service/Portalを一台のサーバに同居する
・Standard/EnterpriseエディションのSharePointを利用する
◆発生する不具合
・MIM Synchronization Serviceをインストールした後でSharePointをインストールするとSynchronization Service Managerが起動しなくなる。
・サービス実行ファイルのパスがSharePoint側のFIM Synchronization Serviceになってしまう
・サービス実行アカウントが「\」となってしまう
・サービス起動設定が無効化となってしまう
・アカウントをSynchronization Service用に設定しなおしてもAccess Deniedエラーが出てサービスが起動しない
◆対策
結局のところ、サービスの設定のパス関係がすべて置き換わってしまっているので修正をする必要があります。
レジストリをガンガン触りますので、基本自己責任です。
①レジストリのサービス関連ファイルのパス修正
対象キー①
HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationServive\ImagePath
修正前)
"C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\Bin\miiserver.exe"
修正後)
"C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe"
対象キー②
HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationServive\Parameters\Path
修正前)
C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\
修正後)
C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\
※その他、Management Agent関連のパスも修正が必要になる場合もあります。
②サービス実行ユーザの修正
「\」となっているのでSynchronization Service実行ユーザに変更する
③パーミッションの変更
上記①、②でサービス自体の修正は終わりなのですが、どうやらPeopleILMなどSharePoint側の設定で消えないものがあるらしく、Synchronization Service起動ユーザにSharePoint側のSynchronization Serviceのパスへの読み取り・実行権限を与える必要があります。
C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\
一応ここまでで使えるようになります。
◆他の解決方法
インストールする順番をSharePoint⇒MIM Synchronization Serviceの順にすることでSharePoint側の設定を逆にMIMが上書きするのでレジストリの修正は不要になります。
が、やはりPeopleILM関係の問題は出るので、上記③の権限付与は必要です。
◆根本的な解決方法
「SharePoint Foundationを使う」。これに限ります。
基本は同居構成の場合はSharePoint Foundationを使いましょう。
2015年10月9日金曜日
[Azure AD]Azure AD B2Cを利用してソーシャル認証するアプリケーションを開発する
こんにちは、富士榮です。
先日Public Previewが公開されたAzure Active Directory B2C(Azure AD B2C)を使うと、これまでAccess Control Service(ACS)が担ってきたコンシューマ・アイデンティティ・プロバイダを使った認証をサポートするアプリケーションを開発することができます。
参考)
・公式Blogでの発表
Azure AD B2C and B2B are now in Public Preview!
http://blogs.technet.com/b/ad/archive/2015/09/16/azure-ad-b2c-and-b2b-are-now-in-public-preview.aspx
・安納さんによる世界一はやいまとめ資料
https://docs.com/junichia/8538/azure-ad-b2c-preview-v0-6
ASP.NET IdentityやACSでも同じようなことが出来るので、今後どのようにすみ分けていくのかは要注目ですが、まずは手始めにOpenID Connectに対応しているものも、そうでないものも含め各種IdPをAzure AD B2Cを経由することによりOpenID Connect対応のIdPにすることができる、という点でアプリケーション開発者から見ると利点があると思われます。
早速、これまでAzure ADやAD FSのOpenID Connect対応を検証するために書いたコードをどこまで再利用できるのか?を確認してみたいと思います。
参考)過去のポスト
[Azure AD]App Model v2.0を利用して組織内外共用のアプリケーションを開発する
http://idmlab.eidentity.jp/2015/08/azure-adapp-model-v20.html
[AD FS]OpenID Connectに対応した次期AD FSを試す
http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html
◆OpenID Connect関連のパラメータを確認する
まずは、Azure AD B2CのOpenID Connect関連パラメータをwell-known/openid-configurationエンドポイントから覗いてみます。
エンドポイントアドレスは、
https://login.microsoftonline.com/{tenant}.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_signin
です。
これはマイクロソフトの悪い癖だと思うんですが、エンドポイントのアドレスにクエリパラメータをつけるのはちょっと頂けない感じですね。。。
実際にアプリケーションを開発する時にはConfiguration情報から取得したエンドポイントアドレスに他のパラメータをつけて処理を行うわけなので、クエリパラメータが2重についてエラーが起きてしまいます。。。
ここはAzure AD B2Cを使ったアプリケーション開発をする際の注意点ですね。
◆クライアント登録を行う
Azure AD B2Cの管理は新しいAzureポータルから行います。
このあたりの細かい設定方法は別の機会に紹介したいと思いますが、といあえずクライアント(アプリケーション)を登録してclient_idとclient_secretを取得しないと始まりませんので、まずは登録します。
◆アプリケーションを開発する
既存のOpenID Connect/RP(アプリケーション)のコードの再利用性を確認するのが目的なので、以前のポストで使ったPHPアプリケーションを再利用します。
完全互換であれば、
・authorization_endpoint
・token_endpoint
・client_id
・client_secret
・redirect_uri
を今回の環境に合わせて修正すればそのまま動くはずです。
早速修正してみました。
これで実行すると、、、404エラー来ました・・・。
先ほどのエンドポイントアドレスにクエリパラメータが入っているので変なエンドポイントへアクセスしてしまっています。
仕方がないので、認可エンドポイントへのGETリクエストのパラメータを'?'ではなく、'&'で連結します。
基本はこれで動くようになりましたが、id_tokenのフォーマットが微妙に違うようです。
具体的にはemailsクレームがマルチバリューで返ってくるので、jsonのパースをちゃんとしてあげないといけません。
例えばGoogle+だと以下のようなid_tokenがかえってきます。
◆実行してみる
今回はGoogle+およびFacebookを使ってサインインする様にAzure AD B2Cを構成してみました。
それぞれの実行結果を確認してみます。
まずはアプリケーションへアクセスするとAzure AD B2Cのログイン画面へ遷移します。
デフォルト画面なので恐ろしくシンプルな画面です。
ここにあらかじめ設定しておいたアイデンティティ・プロバイダが出てきます。
初回アクセス時は認可の確認が求められますので許可すると、クレームが取得できます。
(ちなみに本当の初回はソーシャルIDでサインアップする必要があります。こちらの手順は別途紹介します)
Google+でサインインした場合
Facebookでサインインした場合
どちらの場合もsubが取得できないんですね。。。
今後にいろいろと期待です。
参考:今回利用したコード)
先日Public Previewが公開されたAzure Active Directory B2C(Azure AD B2C)を使うと、これまでAccess Control Service(ACS)が担ってきたコンシューマ・アイデンティティ・プロバイダを使った認証をサポートするアプリケーションを開発することができます。
参考)
・公式Blogでの発表
Azure AD B2C and B2B are now in Public Preview!
http://blogs.technet.com/b/ad/archive/2015/09/16/azure-ad-b2c-and-b2b-are-now-in-public-preview.aspx
・安納さんによる世界一はやいまとめ資料
https://docs.com/junichia/8538/azure-ad-b2c-preview-v0-6
ASP.NET IdentityやACSでも同じようなことが出来るので、今後どのようにすみ分けていくのかは要注目ですが、まずは手始めにOpenID Connectに対応しているものも、そうでないものも含め各種IdPをAzure AD B2Cを経由することによりOpenID Connect対応のIdPにすることができる、という点でアプリケーション開発者から見ると利点があると思われます。
早速、これまでAzure ADやAD FSのOpenID Connect対応を検証するために書いたコードをどこまで再利用できるのか?を確認してみたいと思います。
参考)過去のポスト
[Azure AD]App Model v2.0を利用して組織内外共用のアプリケーションを開発する
http://idmlab.eidentity.jp/2015/08/azure-adapp-model-v20.html
[AD FS]OpenID Connectに対応した次期AD FSを試す
http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html
◆OpenID Connect関連のパラメータを確認する
まずは、Azure AD B2CのOpenID Connect関連パラメータをwell-known/openid-configurationエンドポイントから覗いてみます。
エンドポイントアドレスは、
https://login.microsoftonline.com/{tenant}.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_signin
です。
{ "issuer": "https://login.microsoftonline.com/xxxxxx/v2.0/", "authorization_endpoint": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1_signin", "token_endpoint": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_signin", "end_session_endpoint": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/logout?p=b2c_1_signin", "jwks_uri": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/discovery/v2.0/keys?p=b2c_1_signin", "response_modes_supported": [ "query", "fragment", "form_post" ], "response_types_supported": [ "code", "id_token", "code id_token" ], "scopes_supported": [ "openid" ], "subject_types_supported": [ "pairwise" ], "id_token_signing_alg_values_supported": [ "RS256" ], "token_endpoint_auth_methods_supported": [ "client_secret_post" ], "claims_supported": [ "emails", "sub", "idp" ] }
これはマイクロソフトの悪い癖だと思うんですが、エンドポイントのアドレスにクエリパラメータをつけるのはちょっと頂けない感じですね。。。
実際にアプリケーションを開発する時にはConfiguration情報から取得したエンドポイントアドレスに他のパラメータをつけて処理を行うわけなので、クエリパラメータが2重についてエラーが起きてしまいます。。。
ここはAzure AD B2Cを使ったアプリケーション開発をする際の注意点ですね。
◆クライアント登録を行う
Azure AD B2Cの管理は新しいAzureポータルから行います。
このあたりの細かい設定方法は別の機会に紹介したいと思いますが、といあえずクライアント(アプリケーション)を登録してclient_idとclient_secretを取得しないと始まりませんので、まずは登録します。
◆アプリケーションを開発する
既存のOpenID Connect/RP(アプリケーション)のコードの再利用性を確認するのが目的なので、以前のポストで使ったPHPアプリケーションを再利用します。
完全互換であれば、
・authorization_endpoint
・token_endpoint
・client_id
・client_secret
・redirect_uri
を今回の環境に合わせて修正すればそのまま動くはずです。
早速修正してみました。
これで実行すると、、、404エラー来ました・・・。
先ほどのエンドポイントアドレスにクエリパラメータが入っているので変なエンドポイントへアクセスしてしまっています。
仕方がないので、認可エンドポイントへのGETリクエストのパラメータを'?'ではなく、'&'で連結します。
基本はこれで動くようになりましたが、id_tokenのフォーマットが微妙に違うようです。
具体的にはemailsクレームがマルチバリューで返ってくるので、jsonのパースをちゃんとしてあげないといけません。
例えばGoogle+だと以下のようなid_tokenがかえってきます。
{ "exp": 1444322056, "nbf": 1444318456, "ver": "1.0", "iss": "https://login.microsoftonline.com/xxxx/v2.0/", "acr": "b2c_1_signin", "sub": "Not supported currently. Use oid claim.", "aud": "60a26a60-1c47-497c-b4c3-5cea0f1bc293", "iat": 1444318456, "auth_time": 1444318456, "idp": "google.com", "emails": [ "xxx@gmail.com" ] }
◆実行してみる
今回はGoogle+およびFacebookを使ってサインインする様にAzure AD B2Cを構成してみました。
それぞれの実行結果を確認してみます。
まずはアプリケーションへアクセスするとAzure AD B2Cのログイン画面へ遷移します。
デフォルト画面なので恐ろしくシンプルな画面です。
ここにあらかじめ設定しておいたアイデンティティ・プロバイダが出てきます。
初回アクセス時は認可の確認が求められますので許可すると、クレームが取得できます。
(ちなみに本当の初回はソーシャルIDでサインアップする必要があります。こちらの手順は別途紹介します)
Google+でサインインした場合
Facebookでサインインした場合
どちらの場合もsubが取得できないんですね。。。
今後にいろいろと期待です。
参考:今回利用したコード)
<?php // パラメータ類 $authorization_endpoint = 'https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1_signin'; $token_endpoint = 'https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_signin'; $client_id = '60a26a60-1c47-497c-b4c3-5cea0f1bc293'; $client_secret = 'xxxx'; $redirect_uri = 'https://xxxx.azurewebsites.net/index.php'; $response_type = 'code'; $state = 'hogehoge'; // 手抜き $nonce = 'fogafoga'; // 手抜き // codeの取得(codeがパラメータについてなければ初回アクセスとしてみなしています。手抜きです) $req_code = $_GET['code']; if(!$req_code){ // 初回アクセスなのでログインプロセス開始 // GETパラメータ関係 $query = http_build_query(array( 'client_id'=>$client_id, 'response_type'=>$response_type, 'redirect_uri'=> $redirect_uri, 'scope'=>'openid', 'state'=>$state, 'nonce'=>$nonce )); // リクエスト header('Location: ' . $authorization_endpoint . '&' . $query ); exit(); } // POSTデータの作成 $postdata = array( 'grant_type'=>'authorization_code', 'client_id'=>$client_id, 'code'=>$req_code, 'client_secret'=>$client_secret, 'redirect_uri'=>$redirect_uri ); // TokenエンドポイントへPOST $ch = curl_init($token_endpoint); curl_setopt( $ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt( $ch, CURLOPT_POSTFIELDS, http_build_query($postdata)); curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true ); $response = json_decode(curl_exec($ch)); curl_close($ch); // id_tokenの取り出しとdecode $id_token = explode('.', $response->id_token); $payload = base64_decode(str_pad(strtr($id_token[1], '-_', '+/'), strlen($id_token[1]) % 4, '=', STR_PAD_RIGHT)); $payload_json = json_decode($payload, true); // 整形と表示 print<<<EOF <html> <head> <meta http-equiv='Content-Type' content='text/html; charset=utf-8' /> <title>Obtained claims</title> </head> <body> <table border=1> <tr><th>Claim</th><th>Value</th></tr> EOF; foreach($payload_json as $key => $value){ if($key == "emails"){ foreach($value as $mail_key => $mail_value){ print('<tr><td>'.$key.'</td><td>'.$mail_value.'</td></tr>'); } }else{ print('<tr><td>'.$key.'</td><td>'.$value.'</td></tr>'); } } print<<<EOF </table> </body> </html> EOF; ?>
[AD FS]Azure ADに引き続きAD FSもOpenID Connect適合性認定
こんにちは、富士榮です。
本blogでも紹介してきたとおり、Azure Active Directory(Azure AD)に引き続き、次期Active Directory Federation Services(AD FS)もOpenID Connectに対応していますが、OpenID Foundationによる適合性を認定されたとの発表がありました。
Active Directory Federation Server gains OpenID Certifications!
http://blogs.technet.com/b/ad/archive/2015/10/08/active-directory-federation-server-gains-openid-certifications.aspx
OpenID Foundationの認定ページ
http://openid.net/certification/
ここを見るとAzure Active DirectoryおよびAD FS for Windows10(Windows Server 2016のことだと思うので表現はどうかと思いますが)が認定されていることがわかります。
参考)本blogでの検証結果
[AD FS]OpenID Connectに対応した次期AD FSを試す
http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html
[AD FS]OpenID Connectに対応した次期AD FSを試す(UserInfo編)
http://idmlab.eidentity.jp/2015/09/ad-fsopenid-connectad-fsuserinfo.html
検証結果を見るとまだまだな点もありますが、このようなオープンな仕様に準拠していることがわかる形で公表されると安心できますね。
ちなみに、AD FSがLibertyのSAML2.0の相互運用性テストに合格したのは2009年でした。
クラウド時代のID管理へ? ~ADFS2.0がSAML2.0相互運用性テストにパス~
http://idmlab.eidentity.jp/2009/10/idadfs20saml20.html
もう6年も前なんですね。
(6年前からやってることが変わらないこのblogもアレですが)
本blogでも紹介してきたとおり、Azure Active Directory(Azure AD)に引き続き、次期Active Directory Federation Services(AD FS)もOpenID Connectに対応していますが、OpenID Foundationによる適合性を認定されたとの発表がありました。
Active Directory Federation Server gains OpenID Certifications!
http://blogs.technet.com/b/ad/archive/2015/10/08/active-directory-federation-server-gains-openid-certifications.aspx
OpenID Foundationの認定ページ
http://openid.net/certification/
ここを見るとAzure Active DirectoryおよびAD FS for Windows10(Windows Server 2016のことだと思うので表現はどうかと思いますが)が認定されていることがわかります。
参考)本blogでの検証結果
[AD FS]OpenID Connectに対応した次期AD FSを試す
http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html
[AD FS]OpenID Connectに対応した次期AD FSを試す(UserInfo編)
http://idmlab.eidentity.jp/2015/09/ad-fsopenid-connectad-fsuserinfo.html
検証結果を見るとまだまだな点もありますが、このようなオープンな仕様に準拠していることがわかる形で公表されると安心できますね。
ちなみに、AD FSがLibertyのSAML2.0の相互運用性テストに合格したのは2009年でした。
クラウド時代のID管理へ? ~ADFS2.0がSAML2.0相互運用性テストにパス~
http://idmlab.eidentity.jp/2009/10/idadfs20saml20.html
もう6年も前なんですね。
(6年前からやってることが変わらないこのblogもアレですが)
2015年10月5日月曜日
[お知らせ]IdM実験室別館をオープンしました
こんにちは、富士榮です。
既に一部ソーシャルメディアではお知らせしていたり、現在@ITで連載しているIDaaSに関する記事からもリンクを張っていますが、MSDNの動画投稿サイトであるChannel9に「IdM実験室別館」をオープンしました。
https://channel9.msdn.com/Blogs/IdM-Lab-Annex-MVP-for-Directory-Services-Naohiro-Fujie
とりあえずは@ITの記事に連動する形でAzure Active Diretory(Azure AD)に関する以下のプレゼンテーションと実際の動作のデモンストレーションを動画で公開しています。
今後は、記事連動以外のトピックスについても取り上げていきたいので、文字ばっかりじゃ良くわからない、とか自分でやるのは面倒だから動いているところがみたい!!というリクエストなどあれば、コメントを頂ければコンテンツ化をしていければと思います。
参考)現在連載中の@ITの記事
企業のID管理/シングルサインオンの新しい選択肢「IDaaS」の活用:
第1回 もはや企業のID管理で避けては通れない「IDaaS」とは?
http://www.atmarkit.co.jp/ait/articles/1508/07/news034.html
第2回 IDaaSの実装をAzure ADで理解する(前編)
http://www.atmarkit.co.jp/ait/articles/1509/30/news051.html
第3回 IDaaSの実装をAzure ADで理解する(後編)
http://www.atmarkit.co.jp/ait/articles/1510/05/news013.html
既に一部ソーシャルメディアではお知らせしていたり、現在@ITで連載しているIDaaSに関する記事からもリンクを張っていますが、MSDNの動画投稿サイトであるChannel9に「IdM実験室別館」をオープンしました。
https://channel9.msdn.com/Blogs/IdM-Lab-Annex-MVP-for-Directory-Services-Naohiro-Fujie
とりあえずは@ITの記事に連動する形でAzure Active Diretory(Azure AD)に関する以下のプレゼンテーションと実際の動作のデモンストレーションを動画で公開しています。
- Azure AD アプリケーション連携(1) ~ アプリ連携の概要
- Azure AD アプリケーション連携(2) ~ Google Apps との連携
- Azure AD アプリケーション連携(3) ~ Google への ID配信
- Azure AD アプリケーション連携(4) ~ ASP.NET アプリとの ID 連携
- Azure AD アプリケーション連携(5) ~ グループベースのユーザー割り当て
- Azure AD アプリケーション連携(6) ~ ユーザーの動的な割り当て
- Azure AD アプリケーション連携(7) ~ ルールベースのアクセス制御
今後は、記事連動以外のトピックスについても取り上げていきたいので、文字ばっかりじゃ良くわからない、とか自分でやるのは面倒だから動いているところがみたい!!というリクエストなどあれば、コメントを頂ければコンテンツ化をしていければと思います。
参考)現在連載中の@ITの記事
企業のID管理/シングルサインオンの新しい選択肢「IDaaS」の活用:
第1回 もはや企業のID管理で避けては通れない「IDaaS」とは?
http://www.atmarkit.co.jp/ait/articles/1508/07/news034.html
第2回 IDaaSの実装をAzure ADで理解する(前編)
http://www.atmarkit.co.jp/ait/articles/1509/30/news051.html
第3回 IDaaSの実装をAzure ADで理解する(後編)
http://www.atmarkit.co.jp/ait/articles/1510/05/news013.html