sidebarIdM実験室いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。後は、関連するニュースなどを徒然と。2014年12月26日金曜日[AADSync]オンプレExchangeへのOAuth2認可サポート等マイクロソフトの製品ライフサイクルに関する考え方がこれまでの一気にバージョンアップ、から継続的にアップデートという方針に変わったのに対応してAADSyncの新機能がちょこちょこリリースされるようになっています。今回(2014/12/18)のリリース(1.0.475.1202)では以下の機能が追加になっています。私的に特にうれしいのはsourceAnchorの設定をカスタマイズしてインストールしてもセットアップウィザードを再度実行すると設定が反映されない、というバグ修正でした。(カスタマイズ前提なので)以下のページからダウンロードできます。クラウド2014年12月25日木曜日[Office365/AzureAD]OpenAMとのID連携3注意事項)今回のポストでの構成内容は非サポートの構成を含んでいますので、実環境への適用は避けてください。動作上、ライセンス上の問題が発生しても当方は責任を負いかねます。Manager(FIM)に関する知識をある程度持っている方を対象として書いていますので、細かいFIMの使い方については本blogの他のポストなどを参考にしてください。ここまでシングルサインオンを中心にOpenAMを使ったOffice365とのID連携(フェデレーション)の解説をしてきましたが、今回はそのバックエンドのプロビジョニングについて解説します。これまでのポスト・[Office365/AzureAD]OpenAMとのID連携1・[Office365/AzureAD]OpenAMとのID連携2今回も全体の図の中で枠線で囲っている部分の解説をしていきたいと思います。DS上のアカウントをAzureADおよびOpenAMのレポジトリであるOpenDJにプロビジョニングしています。構成していきましょう。AsserionとAzureAD上のユーザの以下の属性が一致すること」が必要となります。Assertionとして発行する値とAzureAD上のユーザの属性を一致させるように、OpenAMのユーザレポジトリであるOpenDJおよびAzureADを構成する必要があります。IDPEmailについては既に前回OpenAMのリモートサービスプロバイダーを設定する際にIDPEmailとOpenAMのmail属性をマッピングするように設定をしてありますので、追加の設定は不要ですので、NameID/ImmutableIdの値をどうするか考える必要があります。DS上のsAMAccountName属性とOpenDJ上のuidとAzureAD上のImmutableIdにマッピングすることでOpenAMとAzureADが共通の値を使えるようにします。何はともあれAADSyncをダウンロードしてセットアップします。DSのアカウントのマッチングに関する設定を行う画面が出てきますので、ここを以下のように設定します。mailこのsourceAnchorがAzureAD上のImmutableIdと紐づく属性となるので、先に述べたようにsAMAccountNameを設定します。DSを構成している環境においてはAzureADのメールアドレスと正しく紐づかないので、別属性(ここではメールアドレス属性)にAzureAD上のメールアドレスの値を設定することにします。DSとAzureADの同期しかサポートされませんので、当然のことながらそのままではOpenDJにユーザをプロビジョニングすることはできません。Connectorを無理やりAADSyncで使えるように構成します。Serviceなので、コネクタをインストールしてフォルダ構成を合わせれば認識してしまいます。Connectorをインストールすると実体のDLLは以下のフォルダに展開されます。Service\ExtensionsこれをAADSyncが利用するコネクタ用のフォルダへコピーします。Sync\Extensions同様にパッケージコネクタの定義ファイルもコピーします。Profileを定義します。Synchronization/Exportで大丈夫です。諸々の設定が終わると、こんな状態になります。Editorを使って属性のマッピングを行うのですが、その前に一つ大事な考慮事項があります。AzureADとOpenAMのID連携設定を行うと、AzureADからOpenAMへ以下の認証要求がSAMLプロトコルで飛んできます。Formatの部分です。意味合いとしては「Office365/AzureADにログインするには"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"というフォーマットでNameIDを発行して欲しい」、ということなので、OpenAM側で該当するフォーマットでアサーションを発行してあげるように設定する必要があります。OpenAMの全体設定として必ず当該フォーマットでの認証要求があったらNameIDの値に特定の値(ここではuid)を渡す、という設定を行うことも可能ですが、あまりにも汎用性がない構成となってしまいますので、AzureADからの"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"形式での要求があった場合にはuidの値をNameIDとして発行する、という設定を行いたいと思います。OpenAMでは上記のようなSP毎に発行するNameIDの値を定義するために、ユーザの以下の属性を使います。Managerの時代を彷彿とさせる属性名です。Ruleでマッピングを定義します。openam.example.com/OpenAM-11.0.0|urn:federation:MicrosoftOnline|kenshinuまた、上記属性を使うため、OpenDJ上のアカウントのスキーマ(objectClass)設定として以下を設定します。Editorでマルチバリュー属性を設定する場合は面倒ですが、複数のルールを定義し、joinをしていく必要があるので、追加するobjectClassの値ごとにルールを追加します。ここまでを踏まえて定義したルールが以下です。Update尚、objectClass、sun-fm-saml2-nameid-info、sun-fm-saml2-nameid-infokey属性はOpenDJ上でマルチバリュー属性となっているのでMergeTypeはMergeCaseを設定する必要があります。DS上のユーザをAzureADおよびOpenDJへ実際に同期をしてみます。DSを作成したので、userPrincipalNameの代わりにメールアドレスを使う設定を行いましたので、ユーザのメールアドレス属性にAzureADで使うメールアドレスを設定します。これで準備が整ったので、タスクスケジューラ上のAADSyncスケジュールを有効化して実行します。OpenDJへの同期についてはAADSyncのスケジューラには組み込まれていませんので手動で実行します。結果、OpenDJ上に以下のようなユーザが作成され、OpenAMでOffice365/AzureADへシングルサインオン出来るようになります。Managerを使えばちゃんとサポートされた構成を作ることが出来ますので、マネはしないでください。Editorの使い方を中心にAADSyncの使い方をマスターしておくと良いと思います。Soon)となっており、DirSyncやFIMがAADSyncに統合されていく姿が見えてくると思います。言うことで今後もAADSyncについては目が離せませんね。今回まででOpenAMを使ったOffice365とのID連携については終わりですが、次回以降で最初の全体構成図の他のパートについても解説をしていこうと思います。vol.7で「ID連携における仮名」の話をしてきました。Fujie当日行ったデモの内容を含め、少し補足しておきたいと思います。◆仮名(カメイ)とは仮名(カメイ/pseudonym)とは、プライバシーに考慮しつつID連携を行いたい、というユースケースに対応した仕組みです。Provider(IdP)で認証された、という事実だけがあれば本来個人を特定する情報(氏名やメールアドレス)は不要なはずです。(アプリケーションの動作上、もしくは運用上必要になるケースはありますが)しかし、実際のID連携のシナリオでは「なんとなく」様々な属性が連携されており、ID連携をしている複数のサービス間でユーザ情報の名寄せが出来てしまったりするケースが散見されます。Provider(SP)が存在し、かつ運営主体が別個であるコンシューマシナリオやセンシティブな情報を扱うシナリオ(例えば医療情報などを扱うSPを含むシナリオ)ではユーザ情報の名寄せは問題となることがあります。そんな時、サービス毎にユニークな名前(ハンドルネームのようなイメージ)をIdPが自動的に発行することで名寄せを防ぎます。このユニークな名前のことを「仮名」と呼びます。・一時的な仮名があります。永続的な仮名は同じSPに対しては何度ログインし直しても毎回同じ仮名が発行されますので、SP側でデータを持つ場合でも継続してサービスを使うことが出来ます。一方で一時的な仮名はSPに対してログインする度に異なる仮名が発行されるので、同じサービス内でのID情報(前回のログイン時に行った振る舞いなど)を紐づけられる心配はありません。Connectなどの各種ID連携プロトコルにおいて仮名が実装されています。・一時的仮名では「urn:oasis:names:tc:SAML:2.0:nameid-format:transient」が使われます。FSでも当然仮名を扱うことが出来ます。前の記事ですが、このあたりでこっそりと紹介されています。Format(persistent/transient)をプロパティとしてつけてクレームを発行する、という手順になります。以下に設定例を紹介します。Partyのクレームルール(要求変換規則)に以下の2つのルールを定義します。1._OpaqueIdStoreからIDの払い出し以下のカスタムルールを直接記載します。c.OriginalIssuer);2.払い出された値をNameIDとして発行するGUIで設定可能です。Formatに「urn:oasis:names:tc:SAML:2.0:nameid-format:persistent」が設定されていて、不必要な属性(名前やメールアドレスなど)が発行されていないことがわかります。old.(カスタムスキーマを設定して年齢だけ渡すルールを別途書いています)・認証情報(AuthnContextClassRef):urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport(パスワードで認証されたことを示します)といった情報くらいです。サービスは「あらかじめ信頼したIdP」で「パスワードで認証された」ユーザで「18歳以上(25歳という属性より)」であることがわかるので、ログインを許可しコンテンツを利用させることが出来る、と判断することが出来ます。発行されたNameIDは前回同じユーザがログインした時のものと同じ値なので、サービス側で保持している情報との紐づけも可能となります。Partyのクレームルール(要求変換規則)に以下の2つのルールを定義します。1._OpaqueIdStoreからIDの払い出し以下のカスタムルールを直接記載します。c2.Value);2.払い出された値をNameIDとして発行するGUIで設定可能です。Formatに「urn:oasis:names:tc:SAML:2.0:nameid-format:transient」が設定されていて、不必要な属性(名前やメールアドレスなど)が発行されていないことがわかります。old.(カスタムスキーマを設定して年齢だけ渡すルールを別途書いています)・認証情報(AuthnContextClassRef):urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport(パスワードで認証されたことを示します)といった情報くらいです。サービスは「あらかじめ信頼したIdP」で「パスワードで認証された」ユーザで「18歳以上(25歳という属性より)」であることがわかるので、ログインを許可しコンテンツを利用させることが出来る、と判断することが出来ます。発行されたNameIDは前回同じユーザがログインした時のものとは異なる値なので、サービス側では前回ログインしたユーザと今回ログインしてきたユーザが同じユーザであることが判別できないので、サービス内部でのユーザの紐づけは出来ません。◆仮名を使う場合の注意点せっかく仮名を使ったとしても、他にユーザを一意にする属性(メールアドレスなど)をAssertionの中に含めてしまうと仮名を使う意味が全くなくなってしまうので注意が必要です。Emailという属性でメールアドレスを設定する必要があるので、実は仮名の使い方としては意味がありません。アプリケーションとのID連携を設計する際は、必要とされるプライバシー要件を十分に考慮して利用するNameIDのタイプや連携する属性を検討しましょう。属性2014年12月14日日曜日[Office365/AzureAD]OpenAMとのID連携2前回のポストの続きです。Trust)定義の順に実際に設定していきます。Provider(IdP)として設定する必要があります。実際にはOffice365とOpenAMの間にAzureADが挟まっており、Office365/portal.office.com⇒(ws-federation)⇒AzureAD/login.microsoftonline.com⇒(SAML2.0)⇒OpenAMという流れになります。前回も掲載した図を厳密に書くと以下のようになります。OpenAMのインストールを終了し、管理コンソールの[共通タスク]より[ホストアイデンティティープロバイダの作成]をクリックし、IdP定義を作成します。ここでの設定項目は署名に使う鍵とトラストサークルの2点だけです。・署名鍵:test(実験なので。次はOffice365をOpenAMにRPとして設定します。Office365はSAML2.0のメタデータを公開しているので、それをベースにRP設定をします。以下のURLにアクセスし、メタデータをダウンロードします。https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml※私はいつもIEで上記URLを開き、ファイルメニューの名前を付けて保存よりXMLファイルを保存しています。ダウンロードしたメタデータをOpenAMにインポートと行きたいのですが、インポート前にXMLファイル内の最初の~が余分なので削除しておきます。メタデータの用意が出来たら、OpenAMの管理コンソールの[共通タスク]より[リモートサービスプロバイダを登録]をクリックし、先ほどのメタデータをベースにRP設定を行います。・メタデータ:ファイル⇒先ほどのメタデータファイル(federationmetadata.xml)・トラストサークル:先ほどIdP作成時に作ったCoT(MSO365)・属性マッピング:表明内の名前⇒IDPEmail、ローカル属性名⇒mailこれでOpenAM側の設定は完了なので、OpenAMのIdP設定(IdPメタデータ)を出力しておきます。以下のURLよりメタデータが取得できます。http://:8080/OpenAM-11.0.0/saml2/jsp/exportmetadata.jsp?realm=/&entityid=http://:8080/OpenAM-11.0.0※realmやポートなどは環境によって異なります。次はこのIdPメタデータを使ってOffice365/AzureAD側の設定を行います。◆Office365/AzureADのカスタムドメインの認証設定を行うここではOffice365で使うカスタムドメインの認証をOpenAMとのFederationで行う様に設定を行います。※ドメインの追加はOffice365の管理ポータルからでもAzureの管理ポータルからでも構いません。※カスタムドメインを追加する手順は省略します。具体的には、PowerShellの「Set-MsolDomainAuthentication」コマンドレットに以下のパラメータを付けて設定をします。※当然ですがコマンドレット実行前に「Connect-MsolService」でAzureADへ接続しておいてください。SAMLP実際のコマンドは以下のように実行します。SAMLPちなみに設定結果は「Get-MsolDomainFederationSettings」コマンドレットで確認できます。次回はAzureAD上のユーザとOpenAM上のユーザの紐づけを行うためのプロビジョニング時の工夫について解説します。2015(MIM2015)のCTP1が正式に公開されました。Europeなどでも解説されている通り、以下の通りです。Directory上のアカウントに限定ではありますが、ユーザに対して期間限定で特権を割り当てることが可能になります。具体的にはKerberosのチケットのTTLをコントロールしたグループへの参加をさせる形となります。Gateが実装されてきました。Factorが使えるようになったので、管理者の負荷を下げることが出来るかもしれません。Manager(CM)でのスマートカード発行がこれまでのWebベースからストアアプリでも出来るようになりました。タブレット端末で使うときなどは重宝するかも知れません。◆最新プラットフォームのサポートようやく、以下のプラットフォームに対応しました。2013connectサイトからダウンロードできるので、早々に試してみようと思います。Services(AADSync)にもパスワード同期機能が実装された、という話を書きました。http://idmlab.eidentity.jp/2014/11/aadsync.htmlしかし、ディレクトリ同期ツール(DirSync)にあって、AADSyncにない機能があり、その一つがパスワードの強制同期機能です。DirSyncではフォーラムのFAQに書かれているように'Set-FullPasswordSync'コマンドレットを実行してサービスを再起動すればパスワードの強制同期が出来ました。FIMSynchronizationService一方でAADSyncには先にポストしたPowerShellコマンドレット一覧を見ても'Set-FullPasswordSync'が見当たりません。Wikiに書いてくれました。強引な方法ですので、いずれちゃんとしたコマンドレットが用意される気がしますが。Managerで確認できます。-ADという名前のものがAzureADコネクタです)さっそく実行してみると、イベントログにパスワード同期が実行されたことが記録されます。基本的に2分に一回パスワードは同期されますし、ネットワーク障害などで更新が出来なかったときはリトライがされるので大きな問題になることは少ないとは思いますが、メンテナンス時など強制的に全同期をしておきたい時もあると思いますので、そのような際はこのコマンドを使えば良いですね。クラウド[Office365/AzureAD]OpenAMとのID連携1先日告知させて頂いた通り、今月末にCLR/HさんのイベントでID連携のプロトコル周りの話をします。イベントのために、手元にこんな環境を用意してみました。DS上のアカウントをAzureAD/OpenDJ/GoogleAppsへID情報を同期します。・AzureADからGoogleAppsへプロビジョニングを行います。Connectを使ってフェデレーションします。FSを使ったIdPを構築し、ws-federationで接続します。FSで認証、というマルチプロトコルのフェデレーションのチェインを行います。・並行してOpenAMをIdPとしてOffice365/GoogleAppsをSPとしてSAML2.0でフェデレーションします。実際の動きはイベントでお見せするとして、構築方法など細かい話を少しずつ書いていこうと思います。最初は図の右下部分のOffice365とOpenAMのID連携(SSO)について書いていきます。完成するとこんな感じで動きます。Office365のポータル(http://portal.office.com/)へアクセスするとログイン画面が表示されます。OpenAMと連携するように構成したドメインのユーザのメールアドレスを入力するとOpenAMへリダイレクトされます。この時、Office365からOpenAMに向けてSAML2.0の認証リクエストが発行されます。Policyがpersistentとなっているあたりです。IdP(OpenAM)はSP(Office365)向けに永続(固定)のNameIDを渡してあげる必要がある、ということです。Directory(AzureAD)に作成するユーザのImmutableIdという属性の値と一致した値をNameIDには指定します。Manager(FIM)などのID管理ソリューションを使ってユーザを作成します。Syncを改造しています。非サポートです)このあたりは次回以降で別途解説します。OpenAMへログインします。Assertion)を生成、ブラウザを経由してOffice365へHTTP/POSTします。Office365へログインします。うまくいけばシングルサインオンされます。Trust)定義を行います。第3回)ユーザのプロビジョニング設定AADSyncを使ってAzureAD/OpenDJへオンプレミスAD上のユーザを同期します。AD+IDスペシャルディ今月末の11月29日(土)にCLR/Hさんのイベント「AD+IDスペシャルディ〜ハンズオンもあるよ!?」が品川の日本マイクロソフト本社で開催されます。Middlewareを使って実装したカスタムアプリ)の実際の動きをトレースしながら解説しようと思います。以下がセッションスケジュールです。FSのクレームルールの解説など濃いセッションが予定されているので、ご興味のある方はどうぞ。Services(AADSync)にも用意されています。個々の詳しい内容は機会があれば紹介したいと思いますが、とりあえずモジュール名と使えるコマンドレット名の一覧を書いておきます。-ListAvailableを実行すると「ADSync」という名前であることがわかります。先ほどのADSyncをVerboseモードでインポートすると一覧が取得できます。'Update-ADSyncConnectorSchema'.基本はGUIツール(構成ウィザード、ルールエディタ、同期マネージャ)で出来ることはPowerShellで出来そうですね。IdPでの認証サポートが今月後半に実現することが発表されました。ADや外部IdPとつなげる、という構成なわけです。ADからOAuthのアクセストークンを取得してOffice365のサービスへOfficeクライアントがアクセスするわけですね。blogによると、以下のことが出来るようになるようです。1.多要素認証いわゆるPhoneFactorとかの追加要素を使った認証ですね。今回ADALを使うことでSAML2.0に対応するので、OpenAMなどと直接接続をすることが出来るようになります。FSを展開していてSmartCardで認証できるようにしている環境下において、ID/パスワードを入力する代わりにSmartCardのみで認証できるようになります。Onlineへ接続、という流れに変わります。Proxyが必要なくなります。Updateで更新プログラムが落ちてくるみたいなので、月末が楽しみです。Services(AADSync)ですが、10月の終わりに新ビルドがリリースされています。ダウンロードサイト(1.0.0470.1023)http://www.microsoft.com/en-us/download/details.aspx?id=44225GA版からの変化点は以下の2点です。構成ウィザードがローカライズされたパスワード同期(オンプレミスAD⇒AzureAD)がサポートされた1点目のローカライズですが、こんな感じで進化してきています。Managerは相変わらず英語表記です。Syncにも実装されてきました。基本的な仕様や使い方はディレクトリ同期ツールとほぼ同じです。ADへ同期されるようになります。Syncに指定したオンプレミスADとの接続に使うユーザに対して以下の権限を付与する必要があります。Directoryユーザとコンピュータより「制御の委任」で行います。ドメインのルートを右クリックし、[制御の委任]をクリックします。[委任するカスタムタスクを作成する]を選択します。[このフォルダー、このフォルダー内の既存のオブジェクト、およびこのフォルダー内の新しいオブジェクトの作成]を選択しウィザードを進めます。アクセス許可の選択しより「ディレクトリの変更のレプリケート」と「ディレクトリの変更をすべてにレプリケート」にチェックを入れます。Syncのサービスを再起動します。うまく同期されればイベントビューアに以下のようなログが記録されます。MVPの@genkiwさんの以前の記事の状況と同じだと思われます。Synchronizationを実行する必要があるようです。Synchronizationを実行してから同期タスクを有効化した方が安全です。Sync一択になりそうです。なるかの方が気になってしまうので早速確認してみました。一瞬で試せる環境が手に入ります。スタートメニューも復活しています。結論は「そんなに変わっていないけど、便利な機能がついてるっぽい」という感じなので、早速見ていきます。■インストールここははっきり言って何も変わっていません。■構成ウィザードここも全く変わりません。■管理コンソールちょっと変わってます。移動したメニュー、見慣れないメニューがあります。メニューが追加されています。◇バージョン6.4.0.0になってます。変わった部分をちょっと詳しく確認します。してスキーマ拡張をする必要がありましたが、今回からウィザードで構成出来るようになっています。FSが使う証明書のCNのサフィックスが同じ)サーバ証明書を入れる必要があるので、今回は試せてません。Templates完全に新しい機能っぽいので、まだ使い方がよく分かっていませんが、クレームの要求ルールを作成するのを補助してくれるツールっぽいです。こんな感じのルールエディタがついています。どこかで選択できるような気がするんですが、現状該当する設定箇所を見つけられていません。見つけたら更新します。当然ですが何も変わりません。段階なので何とも、、ですが、ポリシーの部分が楽になりそうなので、今後が楽しみです。よりアクセス解析を行っています。品質向上のみを目的とし、個人の特定などを目的とはしておりません。中で公開されることはあります。問い合わせ不明点等は管理人までご連絡ください。本プライバシーポリシーは予告なく変更/削除することがあります。プライバシーに関するトラブルについては一切の責任を負いかねますのでご了承ください。