2011/1/5に更新されたAD FS2.0 RTWのパッケージが再度アップデートされています。
今回も前回同様バグ修正を行ったようです。（そういえばFIM2010と違ってMicrosoft Updateで更新されないですねぇ。。もともとAD FS2.0自身がOSの更新プログラムだからかもしれません）
ダウンロードは以下のURLから。
http://www.microsoft.com/downloads/details.aspx?FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&displayLang=ja
修正内容は以下の2点です。
・KB2254265対応
Windows Server 2008 R2 または Windows Server 2008 を実行しているコンピューター上の「/adfs/サービス/信頼/mex」エンドポイント、HTTP SOAP 要求を送信するとき、「500」エラー コードが返される
The "500" error code is returned when you send an HTTP SOAP request to the "/adfs/services/trust/mex" endpoint on a computer that is running Windows Server 2008 R2 or Windows Server 2008
・KB2272757対応
サインオンはの id プロバイダーを開始プロセスが Windows Server 2008 R2 および Windows Server 2008 では、低速であります。
An identity-provider-initiated sign-on process is slow in Windows Server 2008 R2 and in Windows Server 2008
相変わらずKBの機械翻訳は微妙です。
特に2つ目のKB対応はsalesforce.comへのSSOを行うシナリオの場合は有効だと思われます。
2011年4月19日火曜日
2011年4月15日金曜日
ディレクトリ同期ツールを使って Office365 へのユーザ同期を行う
# はじめに
# ベータ版の Office365 をベースに実験した結果ですので正式版で使える情報とは限りません。
前回は AD FS2.0 を使った Office365 とのフェデレーションの話でしたが、今回はディレクトリ同期を使ったオンプレミスの AD DS と Office365 のアカウント同期についてです。
まずはディレクトリ同期ツールをオンプレミス側にインストールする必要があるのですが、条件が少々あります。これは後からも書きますがこのディレクトリ同期ツールの正体が Identity Lifecycle Manager 2007 FP1（ ILM 2007 FP1 ) だからです。。（たぶん）
■インストール要件
・OS
Windows Server 2003 / 2003 R2 / 2008
32bit版
ドメインに参加しているサーバ（ドメインコントローラ以外）
・必要な機能
.NET Framework 3.5.1
PowerShell
では、さっそくインストールと設定をしてみます。（モジュールは Office365 のポータルからダウンロードできます）
■インストール
インストーラを起動するとセットアップウィザードが起動するので基本はそのままセットアップを行います。
# ベータ版の Office365 をベースに実験した結果ですので正式版で使える情報とは限りません。
前回は AD FS2.0 を使った Office365 とのフェデレーションの話でしたが、今回はディレクトリ同期を使ったオンプレミスの AD DS と Office365 のアカウント同期についてです。
まずはディレクトリ同期ツールをオンプレミス側にインストールする必要があるのですが、条件が少々あります。これは後からも書きますがこのディレクトリ同期ツールの正体が Identity Lifecycle Manager 2007 FP1（ ILM 2007 FP1 ) だからです。。（たぶん）
■インストール要件
・OS
Windows Server 2003 / 2003 R2 / 2008
32bit版
ドメインに参加しているサーバ（ドメインコントローラ以外）
・必要な機能
.NET Framework 3.5.1
PowerShell
では、さっそくインストールと設定をしてみます。（モジュールは Office365 のポータルからダウンロードできます）
■インストール
インストーラを起動するとセットアップウィザードが起動するので基本はそのままセットアップを行います。
■設定
インストールが完了したら構成ウィザードを使って設定を行います。
[構成ウィザードを今すぐ開始する]にチェックを入れて[完了]をクリックします。
インストールが完了したら構成ウィザードを使って設定を行います。
[構成ウィザードを今すぐ開始する]にチェックを入れて[完了]をクリックします。
構成ウィザードが起動します。
ここで Microsoft Online Services 管理者の情報を入力すると同期設定が開始されるのですが、開始前に Office365 側のディレクトリ同期をアクティブ化する必要があります。アクティブ化を行っていないと以下の様なメッセージが出て構成が開始できません。
Office365 側でのディレクトリ同期のアクティブ化は管理ポータルから実施します。
[管理]→[ユーザー]メニューから「 Active Directory 同期 」のセットアップを行います。
セットアップ画面の中の3番目に「 Active Directory 同期をアクティブ化する 」というメニューがあるので [ アクティブ化 ] をクリックします。
[管理]→[ユーザー]メニューから「 Active Directory 同期 」のセットアップを行います。
セットアップ画面の中の3番目に「 Active Directory 同期をアクティブ化する 」というメニューがあるので [ アクティブ化 ] をクリックします。
構成ウィザードに戻り、先ほどの Microsoft Online Services 管理者の情報を入力すると今度は Active Diretory の資格情報を入力する画面が出てきますので、Active Directory の管理者権限のあるユーザ情報を入力します。
構成が終わると、自動的にディレクトリ同期が3時間おき開始されます。尚、その場ですぐに同期を実行したい場合は [ ディレクトリを今すぐ同期する ] にチェックを入れてウィザードを完了します。
ただ、ここで1点注意なのですが前回のポストで紹介した UPN を変更せずに AD FS2.0 とのフェデレーションを行う場合はディレクトリ同期をまだ開始しないでください。デフォルトではやはり UPN 情報が同期されてしまいますので、次に同期設定を変更します。
（これも同じくサポートされない可能性があるので注意が必要です）
■同期設定のカスタマイズ
先にも書きましたがディレクトリ同期ツールの実体は ILM 2007 FP1 です。ということで ILM 2007 の管理画面（ Identity Manager ) から同期設定をカスタマイズするのですが、ディレクトリ同期をインストールしてから一度もログアウトしていない場合は、一旦ログオフします。（ ILM / FIM を使っている方はわかると思いますが、 MIIS Admin グループにインストールしたユーザが登録されるのですがログオフ / ログオンを行わないと権限が反映されないためです )
再度ログオンをしたら、Identity Manager を起動します。
デフォルトでは
C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell
以下にインストールされます。
実行ファイル名は miisclient.exe です。
Identity Manager を起動して Management Agent メニューを起動すると
・TargetWebService
・SourceAD
という2つの Management Agent が自動的に作成されているのがわかります。
今回は Active Directory の UPN ( userPrincipalName ) 属性ではなく、電子メールアドレス ( mail ) 属性を Office365 のログイン ID として使いたいので Office365 に対して UPN を渡している部分で電子メールアドレスを渡すように変更します。
変更手順は TargetWebService を選択した状態で右側の Action メニューの Properties をクリックします。すると Management Agent の設定画面が起動してくるので、 Configure Attribute Flow を選択して user オブジェクトの設定を開きます。
各種属性のマッピングルールが定義されている箇所から userPrincipalName を設定を見ると確かに MetaVerse の userPrincipalName を同期する形になっています。（尚、この MetaVerse の userPrincipalName 属性はもう一つの Management Agent の SourceAD の Attribute Flow 設定で Active Directory の userPrincipalName 属性がマッピングされています）
（これも同じくサポートされない可能性があるので注意が必要です）
■同期設定のカスタマイズ
先にも書きましたがディレクトリ同期ツールの実体は ILM 2007 FP1 です。ということで ILM 2007 の管理画面（ Identity Manager ) から同期設定をカスタマイズするのですが、ディレクトリ同期をインストールしてから一度もログアウトしていない場合は、一旦ログオフします。（ ILM / FIM を使っている方はわかると思いますが、 MIIS Admin グループにインストールしたユーザが登録されるのですがログオフ / ログオンを行わないと権限が反映されないためです )
再度ログオンをしたら、Identity Manager を起動します。
デフォルトでは
C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell
以下にインストールされます。
実行ファイル名は miisclient.exe です。
Identity Manager を起動して Management Agent メニューを起動すると
・TargetWebService
・SourceAD
という2つの Management Agent が自動的に作成されているのがわかります。
今回は Active Directory の UPN ( userPrincipalName ) 属性ではなく、電子メールアドレス ( mail ) 属性を Office365 のログイン ID として使いたいので Office365 に対して UPN を渡している部分で電子メールアドレスを渡すように変更します。
変更手順は TargetWebService を選択した状態で右側の Action メニューの Properties をクリックします。すると Management Agent の設定画面が起動してくるので、 Configure Attribute Flow を選択して user オブジェクトの設定を開きます。
各種属性のマッピングルールが定義されている箇所から userPrincipalName を設定を見ると確かに MetaVerse の userPrincipalName を同期する形になっています。（尚、この MetaVerse の userPrincipalName 属性はもう一つの Management Agent の SourceAD の Attribute Flow 設定で Active Directory の userPrincipalName 属性がマッピングされています）
この MetaVerse 側のマッピング属性を mail に変更することで Office365 に渡される userPrincipalName 属性の値に Active Directory の mail 属性の値を入れることが可能になります。
まずは、 MetaVerse 側の属性から mail を選択します。
まずは、 MetaVerse 側の属性から mail を選択します。
このマッピングの Type が Rule Extension となっているので [ Edit ] ボタンをクリックして Rule Extension を変更します。 Flow rule name のテキストボックスに入っている文字列を以下の様に変更します。
「 cd.generic.string.trim:userPrincipalName:userPrincipalName 」
↓
「 cd.generic.string.trim:userPrincipalName:mail 」
「 cd.generic.string.trim:userPrincipalName:userPrincipalName 」
↓
「 cd.generic.string.trim:userPrincipalName:mail 」
これで、OKを押して Management Agent の設定を保存すれば同期設定のカスタマイズは完了です。
■同期する
さて、実際にユーザーを同期してみます。
3時間待っても良いのですが、ここでは手動で同期を実行します。
これも Identity Manager の画面から実行することになります。
実行のステップは以下の通りです。対象の Management Agent を選択して Action メニューから Run Profile を選択して実行します。
１．SourceAD / Full import and full sync
２．TargetWebService / Full confirm import
３．TargetWebService / Export
※2回目以降は Full となっている部分が Delta となっているプロファイルを選択します。この辺りは MIIS / ILM / FIM の話と同様です。
実行がうまく行くと、
C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\MaData\TargetWebService
以下にexport.txtというファイルができるので内容を確認すると
version: 1
dn: CN={61537477396F527452454731677A395550362B5A70773D3D}
changetype: add
objectclass: user
CommonName: Fujie Naohiro
Surname: Fujie
accountEnabled: TRUE
countryCode: 0
displayName: Fujie Naohiro
givenName: Naohiro
mail: nfujie@adfs20.net
sourceAnchor: aStw9oRtREG1gz9UP6+Zpw==
userPrincipalName: nfujie@adfs20.net
という様な形で同期するユーザのエントリ情報が出力されています。
ここまで行けば Office365 の管理ポータルのユーザー一覧を見るとユーザが追加されているはずです。
ユーザの表示名の左側のアイコンが同期マーク？になっていれば Active Directory から同期されたユーザです。
■同期する
さて、実際にユーザーを同期してみます。
3時間待っても良いのですが、ここでは手動で同期を実行します。
これも Identity Manager の画面から実行することになります。
実行のステップは以下の通りです。対象の Management Agent を選択して Action メニューから Run Profile を選択して実行します。
１．SourceAD / Full import and full sync
２．TargetWebService / Full confirm import
３．TargetWebService / Export
※2回目以降は Full となっている部分が Delta となっているプロファイルを選択します。この辺りは MIIS / ILM / FIM の話と同様です。
実行がうまく行くと、
C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\MaData\TargetWebService
以下にexport.txtというファイルができるので内容を確認すると
version: 1
dn: CN={61537477396F527452454731677A395550362B5A70773D3D}
changetype: add
objectclass: user
CommonName: Fujie Naohiro
Surname: Fujie
accountEnabled: TRUE
countryCode: 0
displayName: Fujie Naohiro
givenName: Naohiro
mail: nfujie@adfs20.net
sourceAnchor: aStw9oRtREG1gz9UP6+Zpw==
userPrincipalName: nfujie@adfs20.net
という様な形で同期するユーザのエントリ情報が出力されています。
ここまで行けば Office365 の管理ポータルのユーザー一覧を見るとユーザが追加されているはずです。
ユーザの表示名の左側のアイコンが同期マーク？になっていれば Active Directory から同期されたユーザです。
同期が完了したらユーザにライセンスを割り当てれば AD FS2.0 でのフェデレーションでログインができるようになっているはずです。
また、一部のOUのユーザのみを同期する方法を MVP 国井さんがまとめているのでこちらも参考にしてください。
http://sophiakunii.wordpress.com/2010/10/18/bpos%E3%81%A7%E4%B8%80%E9%83%A8%E3%81%AE%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%81%A0%E3%81%91%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E5%90%8C%E6%9C%9F%E3%81%99%E3%82%8B%E6%96%B9/
また、一部のOUのユーザのみを同期する方法を MVP 国井さんがまとめているのでこちらも参考にしてください。
http://sophiakunii.wordpress.com/2010/10/18/bpos%E3%81%A7%E4%B8%80%E9%83%A8%E3%81%AE%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%81%A0%E3%81%91%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E5%90%8C%E6%9C%9F%E3%81%99%E3%82%8B%E6%96%B9/
2011年4月14日木曜日
AD FS2.0の構築手順まとめサイトの紹介
最近になってようやく日本語のアイデンティティ関連の情報も増えてきました。
例えば日本マイクロソフトでも Technet で翻訳情報などを集めているサイトが大分整理されてきました。
http://technet.microsoft.com/ja-jp/cloud/gg190748.aspx
他にも @kamebuchi さんが AD FS2.0 や AppFabric Access Control Service の情報を発信していたり、と私が Geneva の情報を必死で集めていたころとは大違いです。
今回はそんな中で AD FS2.0 の構築手順を割とリアルにまとめているサイトを紹介します。
http://www.tensi.info/home/kensyo-infra
実はこのサイトを作っているのは知り合いなのですが、ドメイン名の tenshi とは正反対の性格をしている”できる”エンジニアです。
今後色々とコンテンツの拡充を予定しているらしいので要注目です。
例えば日本マイクロソフトでも Technet で翻訳情報などを集めているサイトが大分整理されてきました。
http://technet.microsoft.com/ja-jp/cloud/gg190748.aspx
他にも @kamebuchi さんが AD FS2.0 や AppFabric Access Control Service の情報を発信していたり、と私が Geneva の情報を必死で集めていたころとは大違いです。
今回はそんな中で AD FS2.0 の構築手順を割とリアルにまとめているサイトを紹介します。
http://www.tensi.info/home/kensyo-infra
実はこのサイトを作っているのは知り合いなのですが、ドメイン名の tenshi とは正反対の性格をしている”できる”エンジニアです。
今後色々とコンテンツの拡充を予定しているらしいので要注目です。
AD FS2.0 で Office365 への認証連携を行う
# はじめに
# ベータ版の Office365 をベースに実験した結果ですので正式版で使える情報とは限りません。
長らく待った Office365 のベータがやっと使えるようになったので早速 AD FS2.0 を使った認証連携を設定してみました。
細かい手順は ブチザッキさんで紹介されているので、基本的にはそちらを参照してもらえれば良いと思いますが、今回は以前紹介した制限事項の確認がポイントです。
以前のポストで紹介した制限（前提）事項は以下の2点でした。
１．オンプレミスのActive DirectoryのUPN属性がインターネットから解決出来る必要がある
→下手に.localドメインで社内ADを構築しているとかなり大幅な変更になるかも知れません。他のアプリケーションへの影響もあるでしょうし。。FIM2010などの自動化ツールは必須かも知れません。
２．Office365からのドメインの正当性確認を受ける必要がある
→LiveIDとのFederationの時にもはまりましたが、Office365というかMFG（Microsoft Federation Gateway）が認めてくれる必要があります。証明書の発行元はシビアです。。
結論から言いますと両方とも気にする必要はありますが回避することができます。
まず簡単な方の２からお話しをしますが、こちらは実際には「ドメインの所有確認さえできれば良い」です。つまり AD FS2.0 が使う証明書が信頼できる証明機関からの発行であろうと自己署名の証明書であろうと関係ない、ということです。
これは Google Apps を独自ドメインでホストするのと同じ考え方なのですが、シングルサインオン（認証連携）を設定する際には Office365 を独自ドメインで運用することになりますので、手持ちのドメインの CNAME レコードに Office365 が指定する値を設定することでドメインの所有確認を行います。
次に１の UPN 属性問題です。既に運用している Active Directory の UPN 属性を変更するのは非常に困難です。
図：UPN のドメインパート（@以下）は固定されている
※4/19追記（MSの方にご指摘をいただきました） ここに記載されている方法でドメインにUPNサフィックスを追加することによって各ユーザのUPNを変更することができるようになります。ただし、結局は各ユーザのUPNを変更することにはなるので、他のアプリケーションへの影響などを十分にテストするか、今回紹介する方法でUPNを変えずに運用できる方法を検討することになりそうです。
・カスタマイズしたルール
こうすることで実際に UPN がローカルドメイン名であっても Office365 との認証連携が実現できます。
ただし、この手法がサポートされるかどうかは全く別問題なので、実際に利用する際はその点をよく確認して環境を構築することをおすすめします。
# ベータ版の Office365 をベースに実験した結果ですので正式版で使える情報とは限りません。
長らく待った Office365 のベータがやっと使えるようになったので早速 AD FS2.0 を使った認証連携を設定してみました。
細かい手順は ブチザッキさんで紹介されているので、基本的にはそちらを参照してもらえれば良いと思いますが、今回は以前紹介した制限事項の確認がポイントです。
以前のポストで紹介した制限（前提）事項は以下の2点でした。
１．オンプレミスのActive DirectoryのUPN属性がインターネットから解決出来る必要がある
→下手に.localドメインで社内ADを構築しているとかなり大幅な変更になるかも知れません。他のアプリケーションへの影響もあるでしょうし。。FIM2010などの自動化ツールは必須かも知れません。
２．Office365からのドメインの正当性確認を受ける必要がある
→LiveIDとのFederationの時にもはまりましたが、Office365というかMFG（Microsoft Federation Gateway）が認めてくれる必要があります。証明書の発行元はシビアです。。
結論から言いますと両方とも気にする必要はありますが回避することができます。
まず簡単な方の２からお話しをしますが、こちらは実際には「ドメインの所有確認さえできれば良い」です。つまり AD FS2.0 が使う証明書が信頼できる証明機関からの発行であろうと自己署名の証明書であろうと関係ない、ということです。
これは Google Apps を独自ドメインでホストするのと同じ考え方なのですが、シングルサインオン（認証連携）を設定する際には Office365 を独自ドメインで運用することになりますので、手持ちのドメインの CNAME レコードに Office365 が指定する値を設定することでドメインの所有確認を行います。
次に１の UPN 属性問題です。既に運用している Active Directory の UPN 属性を変更するのは非常に困難です。
図：UPN のドメインパート（@以下）は固定されている
※4/19追記（MSの方にご指摘をいただきました） ここに記載されている方法でドメインにUPNサフィックスを追加することによって各ユーザのUPNを変更することができるようになります。ただし、結局は各ユーザのUPNを変更することにはなるので、他のアプリケーションへの影響などを十分にテストするか、今回紹介する方法でUPNを変えずに運用できる方法を検討することになりそうです。
こうなると UPN 属性を変更するためには FIM2010 などの IdM ツールが必要になってしまいますし、動いているドメインの UPN 属性を変更することの影響度の調査などなかなかハードルが高い話になってしまいます。
では、UPN 属性を変えずに既存ドメインユーザを使った認証連携を行うにはどうすればよいのでしょうか？
そのためにはまず Office365 との認証連携において UPN 属性がどのように使われているのか？を理解する必要があります。
認証連携を行うための環境を構築するためには Microsoft Online Services ID フェデレーション管理ツールをインストールして、
convert-MSOLDomainToFederated -DomainName <ドメインのFQDN>
というコマンドレットを実行します。
このコマンドレットを実行すると AD FS2.0 の Relying Party として Microsoft Federation Gateway が自動的に登録されるのですが、その RP の要求規則ルールを見ると以下のように設定がされています。
【ルール１】
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,proxyAddresses,objectGUID;{1}", param = regexreplace(c.Value, "(?[^\\]+)\\(?.+)", "${user}"), param = c.Value);
【ルール２】
c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");
ルール１を見ると userPrincipalName を加工して UPN クレームとしてトークンを発行していることがわかります。( 4/15 修正：nameidentifier には ObjectGUID が入ります )
では、逆に言うと userPrincipalName ではない別の属性に Office365 で使うカスタムドメインのユーザ名を設定してこのルール１の要求規則を変更してやれば大丈夫、という話になります。
今回は例えばカスタムドメインに adfs20.net 、オンプレミスの Active Directory ドメインを adfs20.local という環境で構築します。
本来は UPN に user@adfs20.net という値が入っていないと認証連携はできませんが、この環境で普通にユーザを作ると UPN には user@adfs20.local という値が入ってしまいます。
では、代わりに 電子メールアドレス属性に Office365 が期待する UPN に相当する値である user@adfs20.net を入れてみます。
次にこの電子メールアドレス属性をクレームとして発行するように要求規則を変更します。
上のルール１を以下のように変更します。
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};mail,proxyAddresses,objectGUID;{1}", param = regexreplace(c.Value, "(?[^\\]+)\\(?.+)", "${user}"), param = c.Value);
・オリジナルのルール
では、UPN 属性を変えずに既存ドメインユーザを使った認証連携を行うにはどうすればよいのでしょうか？
そのためにはまず Office365 との認証連携において UPN 属性がどのように使われているのか？を理解する必要があります。
認証連携を行うための環境を構築するためには Microsoft Online Services ID フェデレーション管理ツールをインストールして、
convert-MSOLDomainToFederated -DomainName <ドメインのFQDN>
というコマンドレットを実行します。
このコマンドレットを実行すると AD FS2.0 の Relying Party として Microsoft Federation Gateway が自動的に登録されるのですが、その RP の要求規則ルールを見ると以下のように設定がされています。
【ルール１】
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,proxyAddresses,objectGUID;{1}", param = regexreplace(c.Value, "(?
【ルール２】
c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");
ルール１を見ると userPrincipalName を加工して UPN クレームとしてトークンを発行していることがわかります。( 4/15 修正：nameidentifier には ObjectGUID が入ります )
では、逆に言うと userPrincipalName ではない別の属性に Office365 で使うカスタムドメインのユーザ名を設定してこのルール１の要求規則を変更してやれば大丈夫、という話になります。
今回は例えばカスタムドメインに adfs20.net 、オンプレミスの Active Directory ドメインを adfs20.local という環境で構築します。
本来は UPN に user@adfs20.net という値が入っていないと認証連携はできませんが、この環境で普通にユーザを作ると UPN には user@adfs20.local という値が入ってしまいます。
では、代わりに 電子メールアドレス属性に Office365 が期待する UPN に相当する値である user@adfs20.net を入れてみます。
次にこの電子メールアドレス属性をクレームとして発行するように要求規則を変更します。
上のルール１を以下のように変更します。
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};mail,proxyAddresses,objectGUID;{1}", param = regexreplace(c.Value, "(?
・オリジナルのルール
2011年4月13日水曜日
本が出ます。「クラウド環境におけるアイデンティティ管理ガイドライン」
日本ネットワークセキュリティ協会（JNSA）というところで数年前からアイデンティティ管理のWGをやっているのですが、このたび成果物が書籍化されることになりました。
タイトルは
クラウド環境におけるアイデンティティ管理ガイドライン［内部統制に対応した統合ID管理の計画から導入まで］
です。
内容的には技術的な話というよりも、企業がアイデンティティ管理システムを検討～導入する上で考えるべきことを具体的な導入プロセスや事例を踏まえながら解説する、という形をとっています。私も「クラウド環境におけるID管理の位置づけ」という部分や「ID管理システム導入指針」という部分でお手伝いをさせていただいています。
内容的にもあくまで企業が購入することを想定しているのでお値段もそれなりｗですが、以下のページで予約を受け付けていますので、よろしければどうぞ。
インプレスR&D
Amazon
以下が目次です。
タイトルは
クラウド環境におけるアイデンティティ管理ガイドライン［内部統制に対応した統合ID管理の計画から導入まで］
です。
内容的には技術的な話というよりも、企業がアイデンティティ管理システムを検討～導入する上で考えるべきことを具体的な導入プロセスや事例を踏まえながら解説する、という形をとっています。私も「クラウド環境におけるID管理の位置づけ」という部分や「ID管理システム導入指針」という部分でお手伝いをさせていただいています。
内容的にもあくまで企業が購入することを想定しているのでお値段もそれなりｗですが、以下のページで予約を受け付けていますので、よろしければどうぞ。
インプレスR&D
Amazon
以下が目次です。
目次
はじめに
第1章 アイデンティティ管理（ID管理）とは
1.1 ID管理登場の背景
1.1.1 コンピュータパラダイムの変遷とID管理の必要性
1.1.2 ID情報をめぐる多くのステークホルダー
1.2 ID管理の定義
1.2.1 デジタルIDとは
1.2.2 ユーザの視点からみるID情報
1.2.3 ID管理とは
1.2.4 ID管理の構成要素
1.3 ID管理の目的
1.4 ID管理の内容
1.4.1 プロビジョニング
1.4.2 IDサービス
1.4.3 概念・データモデルとリポジトリ
1.4.4 ID監査
1.4.5 ID管理に関する標準化動向
1.5 ID管理の範囲
第2章 ID管理の意義
2.1 企業システムにおけるID管理の位置づけ
2.1.1 IT全般統制におけるID管理
2.1.2 ID管理に関連するインシデントと教訓
2.1.3 ID管理の必要性
2.2 ID管理基盤導入における課題と解決
2.2.1 個別運用での課題
2.2.2 ID管理基盤導入の課題
2.2.3 ID管理基盤導入時に求められる対策
2.3 ID管理導入のメリットと業界ごとの特徴
2.3.1 ID管理基盤整備により解決される問題
2.3.2 業務/業界別ID管理の特徴
第3章 IT内部統制におけるID管理の位置づけ
3.1 IT内部統制の必要性
3.2 IT内部統制のフレームワーク
3.3 COBITにおけるID管理の位置づけと要求事項
3.3.1 DS5.3 Identity Management（ID管理）
3.3.2 DS5.4 User Account Management（ユーザアカウントの管理）
3.3.3 DS5.5 Security Testing, Surveillance and Monitoring（セキュリティのテスト、監視、モニタリング）
3.4 ISMSにおけるID管理の位置づけと要求事項
3.5 COBIT、ISMSにおけるID管理についての考察
第4章 クラウド環境におけるID管理の位置づけ
4.1 クラウド環境におけるID管理の必要性と課題
4.1.1 利用者側の考慮点
4.1.2 提供者側の考慮点
4.2 クラウド環境におけるセキュリティガイドライン
4.2.1 CSAガイドラインにおけるID管理の位置づけと推奨事項
4.2.2 ENISAガイドラインにおけるID管理の位置づけと推奨事項
4.2.3 各ガイドラインにおけるID管理についての考察
4.3 クラウド環境におけるID管理システム
4.3.1 考えられる実装パターンと利用者側の考慮点への対応
4.3.2 各実装パターンのメリットとデメリット
第5章 ID管理システム導入指針
5.1 ID管理導入の流れID管理導入の流れ
5.2 企画フェーズ
5.2.1 目的の明確化
5.2.2 現状分析
5.2.3 ID管理システム計画案作成
5.2.4 ID体系の決定
5.2.5 ID管理運用体制・役割の決定
5.3 要件定義
5.3.1 IDサービスの要件定義
5.3.2 プロビジョニングの要件定義
5.3.3 リポジトリの要件定義
5.3.4 移行の要件定義
5.4 設計
5.4.1 IDサービスの設計
5.4.2 プロビジョニングの設計
5.4.3 リポジトリの設計
5.4.4 移行計画の詳細化
5.5 実装・テスト
5.5.1 IDサービスの実装・テスト
5.5.2 プロビジョニングの実装・テスト
5.5.3 リポジトリの実装・テスト
5.5.4 移行リハーサル
5.6 サービスイン
5.7 教育・トレーニング
5.8 評価
5.9 クラウドサービスのID管理を行う際の留意点
5.9.1 クラウドサービスのID管理を行うための主要機能と標準技術
5.9.2 実装方法の検討プロセス
第6章 ID管理システムにおける仮想企業導入事例
6.1 金融業の仮想企業事例
6.2 製造業の仮想企業事例
第7章 ID管理アンチパターン
7.1 絵に描いたモチ
7.2 業務知らず
7.3 製品そっちのけ
7.4 ブラックボックスプロビジョニング
7.5 つながるだろう症候群
第8章 ID管理に関するFAQ
8.1 ID管理全般
8.1.1 ID管理とは
8.1.2 ID管理システムの導入メリット
8.1.3 内部統制における役割
8.1.4 ID管理導入に必要な体制
8.1.5 ID管理システムの導入期間
8.1.6 ワークフローシステムの標準的な機能
8.1.7 導入事例
8.1.8 COBITやISMSとID管理の関係
8.1.9 ID管理に関する標準化動向
8.2 企画・稟議
8.2.1 ワークフローの必要性
8.2.2 ID管理システム導入の事前準備
8.2.3 ID管理システム導入における主な課題
8.2.4 導入計画
8.2.5 導入に必要な作業項目・順序
8.2.6 ID管理の対象システムの考え方
8.2.7 システム監査からの指摘事項
8.3 導入
8.3.1 ID管理プロビジョニングの対象システムの設定
8.3.2 管理対象システムが多い場合の考慮
8.3.3 ID管理に必要な源泉情報
8.3.4 組織・人事変更の際の注意点
8.3.5 システム導入の主な納品物
8.3.6 連携対象システム側の作業について
8.3.7 取り扱うデータのセキュリティ
8.4 運用・保守
8.4.1 システム導入後のIDの取り扱い
8.4.2 システム導入後の各システムのパスワード管理
8.4.3 システム導入後の既存システムの運用影響
8.4.4 ID管理データの整合性
8.4.5 システム導入による運用効果
8.4.6 運用部門への教育、啓蒙活動
用語集
索引
2011年4月9日土曜日
ACSv2 正式リリース：OpenIDはどうなった？
期末～期初のばたばたでしばらく間が開いてしまいました。
さて昨日、長らくラボ公開だった Windows Azure AppFabric Access Control Service ver.2 (ACSv2) が正式にリリースされました。
私として一番気になっているのがラボ時代は Management Service 経由でしか管理できなかった OpenID プロバイダのサポート。
早速どうなっているのか新しい管理画面を見てみました。
結果、「やっぱりポータルからは管理できない」でした。
ネームスペースを作成すると Activation が走りしばらくすると使えるようになります。ACSv1 時代に作成したネームスペースは ACS Version の列に ACSV1 と表示され区別されます。
ステータスが Active になったら Management をクリックし管理画面へ遷移します。URL が新しいものに変わっています。
さて昨日、長らくラボ公開だった Windows Azure AppFabric Access Control Service ver.2 (ACSv2) が正式にリリースされました。
私として一番気になっているのがラボ時代は Management Service 経由でしか管理できなかった OpenID プロバイダのサポート。
早速どうなっているのか新しい管理画面を見てみました。
結果、「やっぱりポータルからは管理できない」でした。
しばらくは以前紹介した方法で管理をするしかなさそうです。
GUI も正式 ACSv2 に対応させたものを近日公開したいと思います。
とりあえず本日は軽く管理画面を紹介しておきます。
http://windows.azure.com から AppFabric -> Access Control Service を選択し、ネームスペースを作成します。
もちろんラボのネームスペースは引き継がれませんが、ACSv1 のネームスペースは引き継がれます。
GUI も正式 ACSv2 に対応させたものを近日公開したいと思います。
とりあえず本日は軽く管理画面を紹介しておきます。
http://windows.azure.com から AppFabric -> Access Control Service を選択し、ネームスペースを作成します。
もちろんラボのネームスペースは引き継がれませんが、ACSv1 のネームスペースは引き継がれます。
ネームスペースを作成すると Activation が走りしばらくすると使えるようになります。ACSv1 時代に作成したネームスペースは ACS Version の列に ACSV1 と表示され区別されます。
ステータスが Active になったら Management をクリックし管理画面へ遷移します。URL が新しいものに変わっています。
こんな感じです。ラボを使い慣れてしまっているとあんまり変わり映えはしませんが、ようやく正式リリースです。
尚、旧ラボ環境は今のところ使えていますので、課金を考えるとしばらくはやはりラボを使うかもしれません。
尚、旧ラボ環境は今のところ使えていますので、課金を考えるとしばらくはやはりラボを使うかもしれません。