ADFSというか、Active DirectoryのLDAP属性は、ここに一覧があります。
http://msdn.microsoft.com/en-us/library/ms675090(v=VS.85).aspx
ADSIエディターなどで表示される属性は、LDAP表示名（Ldap-Display-Name）と呼ばれるもののようですね。
E-Mail-Addressだとこういう感じの内容で書かれています。
2011年2月20日日曜日
IdPとSPを連携させてクレーム対応アプリケーションを試してみた
IdP側のSTSで認証して属性ストアからメールアドレスをセキュリティトークンとしてもらい、SP側のSTSでそのメールアドレスに対応する役職をセキュリティトークンに追加する動作を試してみました。
アプリケーションにアクセスしてからの一連の動作は、以下の図のようになります。
そして、それぞれどのような信頼関係や属性ストアがあるかは、以下の図の通りです。
注）IdP側STSからActive Directoryに対する"要求プロバイダー信頼"、"属性ストア"は、AD FS 2.0の構成時に合わせて作られています。
今回は、以下のものを設定しています。
(1)IdP側STSから、SP側STSに対する"証明書利用者信頼"
(2)SP側STSから、役割(役職)ストアに対する"属性ストア"
これは、SQL Server 2008 R2 Express上に作ったデータベースです。
DBMSに対する属性ストアの接続については、日本マイクロソフトの安納さんのブログ記事を参考にしています。
【IDM】AD FS 2.0 で属性ストアとしてSQL Server を使用する
ただ、SQL Server 2008 R2 Expressの場合は、
server=ホスト名\sqlexpress
としてやる必要がありますね。
参考： SQL Server Express ユーザー インスタンスへの接続 (ADO.NET)
(3)SP側STSで認証しないように、Web.configを以下のように変更します。
localAuthenticationTypesタグの要素をコメントアウトすると、このADFSで認証しない様になります。
(4)SP側STSから、IdP側STSに対する"要求プロバイダー信頼"
(5)SP側STSから、クレーム対応アプリケーションに対する"証明書利用者信頼"
では、(1)、(4)、(5)の要求規則セットと要求規則についても書いておきます。
(1)は、"発行承認規則"に以下の要求規則を定義しました。
メールアドレス属性を名前というクレームに入れて発行してます。
(4)は、"受け付け変換規則"に以下の要求規則を定義しました。
名前というクレームをパススルーしてます。
(5)は、"発行承認規則"に二つの規則を定義しました。
一つ目は、名前というクレームを発行してます。
名前というクレームをパススルーしてます。
二つ目は、カスタム規則で、名前（メールアドレス）に応じた役職（役割）をSP側STSに設定した属性ストアから取り出して発行します。
ここは、SQL文をカスタム規則に書いて、クレームとして発行しています。
ということで、参考になれば幸いです。
参考）
【セミナー資料】AD FS 2.0 を使用して Windows Azure との SSO を実現しよう V1.1
【IDM】AD FS 2.0 カスタムルール（カスタム規則）の作り方 1/2
【IDM】AD FS 2.0 カスタムルール（カスタム規則）の作り方 2/2
BoF-09 Silverlight and WIF /TechEd Japan 2010
IdM実験室
アプリケーションにアクセスしてからの一連の動作は、以下の図のようになります。
そして、それぞれどのような信頼関係や属性ストアがあるかは、以下の図の通りです。
注）IdP側STSからActive Directoryに対する"要求プロバイダー信頼"、"属性ストア"は、AD FS 2.0の構成時に合わせて作られています。
今回は、以下のものを設定しています。
(1)IdP側STSから、SP側STSに対する"証明書利用者信頼"
(2)SP側STSから、役割(役職)ストアに対する"属性ストア"
これは、SQL Server 2008 R2 Express上に作ったデータベースです。
DBMSに対する属性ストアの接続については、日本マイクロソフトの安納さんのブログ記事を参考にしています。
【IDM】AD FS 2.0 で属性ストアとしてSQL Server を使用する
ただ、SQL Server 2008 R2 Expressの場合は、
server=ホスト名\sqlexpress
としてやる必要がありますね。
参考： SQL Server Express ユーザー インスタンスへの接続 (ADO.NET)
(3)SP側STSで認証しないように、Web.configを以下のように変更します。
localAuthenticationTypesタグの要素をコメントアウトすると、このADFSで認証しない様になります。
<localAuthenticationTypes>
<!-- add name="Integrated" page="auth/integrated/" />
<add name="Forms" page="FormsSignIn.aspx" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" / -->
</localAuthenticationTypes>
(4)SP側STSから、IdP側STSに対する"要求プロバイダー信頼"
(5)SP側STSから、クレーム対応アプリケーションに対する"証明書利用者信頼"
では、(1)、(4)、(5)の要求規則セットと要求規則についても書いておきます。
(1)は、"発行承認規則"に以下の要求規則を定義しました。
メールアドレス属性を名前というクレームに入れて発行してます。
(4)は、"受け付け変換規則"に以下の要求規則を定義しました。
名前というクレームをパススルーしてます。
(5)は、"発行承認規則"に二つの規則を定義しました。
一つ目は、名前というクレームを発行してます。
名前というクレームをパススルーしてます。
二つ目は、カスタム規則で、名前（メールアドレス）に応じた役職（役割）をSP側STSに設定した属性ストアから取り出して発行します。
ここは、SQL文をカスタム規則に書いて、クレームとして発行しています。
ということで、参考になれば幸いです。
参考）
【セミナー資料】AD FS 2.0 を使用して Windows Azure との SSO を実現しよう V1.1
【IDM】AD FS 2.0 カスタムルール（カスタム規則）の作り方 1/2
【IDM】AD FS 2.0 カスタムルール（カスタム規則）の作り方 2/2
BoF-09 Silverlight and WIF /TechEd Japan 2010
IdM実験室
2011年2月6日日曜日
ログオンしているユーザー情報から、そのユーザーが格納されているOUまで移動するPowerShellコード
ログオンしているユーザー情報から、そのユーザーが格納されているOUまで移動するPowerShellコードを書いてみたので、晒しておきます。
制御の委任が行われていれば、cd $DNPATH 以降で、新規にユーザーを作成するなどの処理が実行できます。
実行にあたっては、PowerShellのActive Directoryモジュールが必要です。
・Windows Server 2008 R2は、"機能の追加"で追加しましょう。
・Windows 7は、RSATのダウンロードとインストールが必要です。
ただこのコード、あまり深く考えていないところがあるので、複数のグループで制御の委任を受けているユーザーはどうするのかとか、administratorだとこれまずいのじゃという点、多々留意点があります。
制御の委任が行われていれば、cd $DNPATH 以降で、新規にユーザーを作成するなどの処理が実行できます。
実行にあたっては、PowerShellのActive Directoryモジュールが必要です。
・Windows Server 2008 R2は、"機能の追加"で追加しましょう。
・Windows 7は、RSATのダウンロードとインストールが必要です。
ただこのコード、あまり深く考えていないところがあるので、複数のグループで制御の委任を受けているユーザーはどうするのかとか、administratorだとこれまずいのじゃという点、多々留意点があります。
2011年1月30日日曜日
Windows Server 2008 R2の信頼関係ウィザード
マイナーネタ第二弾
Windows Server 2008 R2の信頼関係ウィザードです。
まあ、もしかしたらWindows Server 2008も同じウィザードが使えるかもしれませんけど、確認していません。
一番のトピックは、片方のドメインから、両方のドメインに対する信頼関係の設定ができること。
��もちろん、両方のドメインの管理者パスワードを教えたくない等、セキュリティ的な懸念事項がある場合は、従来通り別々に設定できます）
信頼される側（ユーザーアカウントなどを使いたい）ドメインは、"exsshzk.local"とします。
信頼する側（リソースにアクセスさせたい）ドメインは、"exsshzk2.local"とします。
信頼関係の設定では、双方のドメインを名前解決できる必要があります。今となっては、DNSが一番良いですが、HOSTSファイルでも良いかと（もしかしてまだLMHOSTSでも良い？！）。
新機能が使えるので、信頼される側のドメインで、信頼関係の設定をまとめて行うことにします。
信頼関係の設定は、従来通り、ドメインの信頼関係（名前が正しくないかも、違っていたら後日修正します）で行います。
ドメインの信頼関係]でプロパティを表示させると以下のような画面が表示されます。
ここで、[信頼]タブにある[新しい信頼]ボタンを押してやります。
[新しい信頼ウィザード]が起動します。
信頼する側のドメイン名を入力します。
ここでは、自動的に信頼関係を推移させることはしないので、[外部の信頼]をチェックしています。
自動的に信頼関係を推移させたい場合は[フォレストの信頼]をチェックすれば良いです。
信頼関係の方向を指定します。
ここでは、信頼される側のユーザーアカウントから、信頼する側のリソースへのアクセスを許可するだけにしたいので、[一方向:入力方向]を指定します。
信頼の対象ですが、ここが新機能なんですよね？！
今回は信頼される側からすべての設定を行いたいので、[このドメインと指定されたドメインの両方]を選択します。
[このドメインと指定されたドメインの両方]を選択したので、指定されたドメイン=信頼される側 のドメイン管理者名とそのパスワードを入力します。
今回は、テスト環境で両方とも私が管理していますので、[ドメイン全体の認証]を選択しました。
組織が違う場合は、[認証の選択]を選択すれば良いです。
設定内容の確認画面です。
信頼関係について、設定完了した旨のメッセージが出ています。
これは、入力方向の信頼関係ができているかをきちんと確認するためのものです。
今回は省きました（本来はやったほうが良いです）。
ここで、[新しい信頼ウィザード]が完了します。
このようなダイアログが表示されます。
内容を読んで[OK]ボタンを押します。
信頼される側のドメインでは、以下のように設定されています。
信頼する側のドメインでは、以下のように設定されています。
ということで、信頼関係の確立も少し手間が減ったといえますね。
Windows Server 2008 R2の信頼関係ウィザードです。
まあ、もしかしたらWindows Server 2008も同じウィザードが使えるかもしれませんけど、確認していません。
一番のトピックは、片方のドメインから、両方のドメインに対する信頼関係の設定ができること。
��もちろん、両方のドメインの管理者パスワードを教えたくない等、セキュリティ的な懸念事項がある場合は、従来通り別々に設定できます）
信頼される側（ユーザーアカウントなどを使いたい）ドメインは、"exsshzk.local"とします。
信頼する側（リソースにアクセスさせたい）ドメインは、"exsshzk2.local"とします。
信頼関係の設定では、双方のドメインを名前解決できる必要があります。今となっては、DNSが一番良いですが、HOSTSファイルでも良いかと（もしかしてまだLMHOSTSでも良い？！）。
新機能が使えるので、信頼される側のドメインで、信頼関係の設定をまとめて行うことにします。
信頼関係の設定は、従来通り、ドメインの信頼関係（名前が正しくないかも、違っていたら後日修正します）で行います。
ドメインの信頼関係]でプロパティを表示させると以下のような画面が表示されます。
ここで、[信頼]タブにある[新しい信頼]ボタンを押してやります。
[新しい信頼ウィザード]が起動します。
信頼する側のドメイン名を入力します。
ここでは、自動的に信頼関係を推移させることはしないので、[外部の信頼]をチェックしています。
自動的に信頼関係を推移させたい場合は[フォレストの信頼]をチェックすれば良いです。
信頼関係の方向を指定します。
ここでは、信頼される側のユーザーアカウントから、信頼する側のリソースへのアクセスを許可するだけにしたいので、[一方向:入力方向]を指定します。
信頼の対象ですが、ここが新機能なんですよね？！
今回は信頼される側からすべての設定を行いたいので、[このドメインと指定されたドメインの両方]を選択します。
[このドメインと指定されたドメインの両方]を選択したので、指定されたドメイン=信頼される側 のドメイン管理者名とそのパスワードを入力します。
今回は、テスト環境で両方とも私が管理していますので、[ドメイン全体の認証]を選択しました。
組織が違う場合は、[認証の選択]を選択すれば良いです。
設定内容の確認画面です。
信頼関係について、設定完了した旨のメッセージが出ています。
これは、入力方向の信頼関係ができているかをきちんと確認するためのものです。
今回は省きました（本来はやったほうが良いです）。
ここで、[新しい信頼ウィザード]が完了します。
このようなダイアログが表示されます。
内容を読んで[OK]ボタンを押します。
信頼される側のドメインでは、以下のように設定されています。
信頼する側のドメインでは、以下のように設定されています。
ということで、信頼関係の確立も少し手間が減ったといえますね。
2011年1月21日金曜日
Windows Server 2008 R2のdcpromo step by step
dcpromoのウィザードの順番を見たかったのですが、意外とインターネットに無い。
ということで、確認のためにdcpromoを動作させながら、画面を撮ってみました。
何かの参考になれば幸いです。
最初のウィザード画面。詳細モードのスイッチもあります。
オペレーティングシステムの説明画面。
フォレストとドメインを新規作成するのか、既存のものに追加するのかという画面。
ドメイン名の指定画面。今回の例では、exsshzk2.localというFQDNを指定してみました。
ドメインNetBIOS名の指定画面。exsshzk2が自動的に指定されています。
フォレストの機能レベルの指定画面。各機能レベル毎に、機能の違いが記載されています。
この例は、Windows Server 2003。
この例は、Windows Server 2008。
この例は、Windows Server 2008 R2。
追加のドメインコントローラオプションの指定画面。
DNSサーバーをインストールするように指定すると、DNSサーバーの委任に関するダイアログが出ます。
データベース、ログファイル、およびSYSVOLの場所の指定画面。
ディレクトリサービス復元モードの管理者パスワードの指定画面。
インストールの概要を確認する画面。
"設定のエクスポート"ボタンもあります。
完了画面。
以上、終わり。
ということで、確認のためにdcpromoを動作させながら、画面を撮ってみました。
何かの参考になれば幸いです。
最初のウィザード画面。詳細モードのスイッチもあります。
オペレーティングシステムの説明画面。
フォレストとドメインを新規作成するのか、既存のものに追加するのかという画面。
ドメイン名の指定画面。今回の例では、exsshzk2.localというFQDNを指定してみました。
ドメインNetBIOS名の指定画面。exsshzk2が自動的に指定されています。
フォレストの機能レベルの指定画面。各機能レベル毎に、機能の違いが記載されています。
この例は、Windows Server 2003。
この例は、Windows Server 2008。
この例は、Windows Server 2008 R2。
追加のドメインコントローラオプションの指定画面。
DNSサーバーをインストールするように指定すると、DNSサーバーの委任に関するダイアログが出ます。
データベース、ログファイル、およびSYSVOLの場所の指定画面。
ディレクトリサービス復元モードの管理者パスワードの指定画面。
インストールの概要を確認する画面。
"設定のエクスポート"ボタンもあります。
完了画面。
以上、終わり。
2011年1月3日月曜日
システムイメージによるバックアップ、リカバリ
プレインストール機のハードディスク換装（120GB⇒320GB）を行うため、システムイメージによるバックアップ＆リカバリを試してみました。
プレインストール機のOSは、Windows 7 Home Premium 32bitです。
注）ハードディスク換装自体は、メーカー保証外の行為です。この記事を参考にされて何らかの問題が発生しても当方は責任を負いかねます。すべて自己責任でお願いします。
バックアップでは、
・システムイメージ
USB接続の3.5inch 300GBハードディスクを用意しそちらにバックアップ。
・システム修復ディスク
今回はCD-RWへ書き込み。
を作成しました。
リカバリは、システム修復ディスクより起動し、システムイメージより復元する方法をとりました。
そのさわりは、
システム イメージ バックアップからコンピューターを復元する
を少し見てもらえると良いです。
時間を図るのを忘れてしまいましたが、120GBのうち55GB程度を使用していたハードディスクをバックアップ、リストアするのにそれぞれ1時間～1時間半程度を要したのではなかったかと。
さて、リカバリが終了したので、ディスクの管理でパーティション構成を確認してみます。
お、Cドライブ以外にリカバリー用のパーティションもリカバリされていますね！
これはうれしい誤算です。
さて折角、より大容量のハードディスクに換装したので、パーティションを拡張してみます。
全体的な手順は、
を参考にさせていただきました。
では、拡張したいパーティションを右クリックして、[ボリュームの拡張]を選択します。
[次へ]ボタンを押します。
最大限、拡張したいので、特に[ディスク領域を選択]の値は変更せず、[次へ]ボタンを押します。
[完了]ボタンを押します。
そうすると、このように拡張されます。
ここまで、システムイメージによるバックアップ、リストア、パーティションの拡張を見てきました。
partimageを使うことを考えてもいましたが、システムイメージによる方法のほうがとても簡単かつ比較的短時間で済むことがわかりました。
ハードディスク換装でなくても、ハードディスクの故障に対する備えとして、システムイメージは十分役立ちます。是非、システムイメージによるバックアップを外部ハードディスクなどにとることをお勧めします。
プレインストール機のOSは、Windows 7 Home Premium 32bitです。
注）ハードディスク換装自体は、メーカー保証外の行為です。この記事を参考にされて何らかの問題が発生しても当方は責任を負いかねます。すべて自己責任でお願いします。
バックアップでは、
・システムイメージ
USB接続の3.5inch 300GBハードディスクを用意しそちらにバックアップ。
・システム修復ディスク
今回はCD-RWへ書き込み。
を作成しました。
リカバリは、システム修復ディスクより起動し、システムイメージより復元する方法をとりました。
そのさわりは、
システム イメージ バックアップからコンピューターを復元する
を少し見てもらえると良いです。
時間を図るのを忘れてしまいましたが、120GBのうち55GB程度を使用していたハードディスクをバックアップ、リストアするのにそれぞれ1時間～1時間半程度を要したのではなかったかと。
さて、リカバリが終了したので、ディスクの管理でパーティション構成を確認してみます。
お、Cドライブ以外にリカバリー用のパーティションもリカバリされていますね！
これはうれしい誤算です。
さて折角、より大容量のハードディスクに換装したので、パーティションを拡張してみます。
全体的な手順は、
http://journal.mycom.co.jp/special/2009/windows7/030.html
を参考にさせていただきました。
では、拡張したいパーティションを右クリックして、[ボリュームの拡張]を選択します。
[次へ]ボタンを押します。
最大限、拡張したいので、特に[ディスク領域を選択]の値は変更せず、[次へ]ボタンを押します。
[完了]ボタンを押します。
そうすると、このように拡張されます。
ここまで、システムイメージによるバックアップ、リストア、パーティションの拡張を見てきました。
partimageを使うことを考えてもいましたが、システムイメージによる方法のほうがとても簡単かつ比較的短時間で済むことがわかりました。
ハードディスク換装でなくても、ハードディスクの故障に対する備えとして、システムイメージは十分役立ちます。是非、システムイメージによるバックアップを外部ハードディスクなどにとることをお勧めします。
登録:
投稿 (Atom)