11月2日の Tech Fielder セミナー「AD FS 2.0 を使用して Windows Azure との SSO を実現しよう」にご参加くださったみなさま、ありがとうございました。SSL 不調により途中お見苦しいところをお見せしましてすみませんでした。IIS でバインドの再設定を行ったところ、動作させることができました。懇親会にご参加いただいた20名ほどのみなさまには最後までご覧いただけたかと思います。
そして、ライブ中継をお申込みいただいたにもかかわらず、がサーバー不調により中止となってしまいましたこと、お詫び申し上げます。
当日の様子はビデオにして配信いたしますので、今少しお待ちください（もちろんお見苦しい部分は再収録いたします orz）
とりいそぎ、当日の資料を加筆修正し、SlideShare にアップロードしました。
フォントがおかしいので、是非ともダウンロードしてからご参照ください。
枚数が多いため5分割してあります（すいません）。
すみません。すっかり以下の投稿の続編を失念しておりました。
【IDM】AD FS 2.0 カスタムルール（カスタム規則）の作り方 1/2 - フィールドSEあがりの安納です - Site Home - TechNet Blogs
上記の投稿では、以下のシナリオに沿ったカスタムルールを作成することになっています。
■想定するシナリオ
Active Directory にログオンした回数 (LogonCount) によって利用者の利用状況を判断し、WEB アプリケーションに表示するメニューを変えたい。例えば、100 回以上ログオンしたことがあるユーザーは「操作に慣れたユーザー」であると判断して、使えるアプリケーションを増やしてあげるとか…。（適当なシナリオですんません）
上記のシナリオをカスタムルールとして展開するには、以下のルールを作成して順番に実行しなければなりません
ということで、ちゃちゃっと作ってしまいましょう。
1. ログオン回数（logonCount）属性を Active Directory から取得して LogonCount クレームに放り込む
[カスタム規則] に以下のルールを入力
c:[Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname, Issuer == "AD AUTHORITY"] => issue (store = "Active Directory", types = ("http://schemas.tf.com/identity/claims/logonCount"), query = ";logonCount;{0}", param = c.Value);
2. ログオン回数が 10未満（1桁の数字）ならばステータス「BEGINNER」を UserStatus クレームに放り込む
c:[Type == http://schemas.tf.com/identity/claims/logonCount, Value =~ "^[0-9]{1}$"] => add (Type = "http://schemas.tf.com/identity/claims/userstatus", Value = "BEGINNER");
一度クレームとして発行しているクレーム名（今回は logonCount）は大文字小文字を判別しますので、くれぐれも注意してください。 ちなみに、^[0-9]{1}$ は正規表現です。「1桁の0から9の文字」という意味になります。つまり、logonCount が 1桁の数字ならば userstatus クレームに BEGINNER という文字列を入れて発行する..ということです。 なお、発行ステートメントの「add」には十分注意してください。add を使用すると、クレームはルール内部で使用することはできますが、外部には発行されません。詳細は以下の記事をご覧ください。 【IDM】Active Directory の「直属の部下」属性からマネージャーかどうかを判断する 2/2 - フィールドSEあがりの安納です - Site Home - TechNet Blogs
一度クレームとして発行しているクレーム名（今回は logonCount）は大文字小文字を判別しますので、くれぐれも注意してください。
ちなみに、^[0-9]{1}$ は正規表現です。「1桁の0から9の文字」という意味になります。つまり、logonCount が 1桁の数字ならば userstatus クレームに BEGINNER という文字列を入れて発行する..ということです。
なお、発行ステートメントの「add」には十分注意してください。add を使用すると、クレームはルール内部で使用することはできますが、外部には発行されません。詳細は以下の記事をご覧ください。
【IDM】Active Directory の「直属の部下」属性からマネージャーかどうかを判断する 2/2 - フィールドSEあがりの安納です - Site Home - TechNet Blogs
3.ログオン回数が 10以上 100未満（2ケタの数字）ならばステータス「SENIOR」を UserStatus クレームに放り込む（発行しない）
c:[Type == http://schemas.tf.com/identity/claims/logonCount, Value =~ "^[0-9]{2}$"] => add(Type = "http://schemas.tf.com/identity/claims/userstatus", Value = "SENIOR");
2.のカスタムルールと何が違うかわかりますか？今回は2ケタの数字であれば、"SENIOR" を入力するように記述しています。
4. ログオン回数が 100以上（3ケタ以上）ならばステータス「EXPERT」を UserStatus クレームに放り込む（発行しない）
c:[Type == http://schemas.tf.com/identity/claims/logonCount, Value =~ "^[0-9]{3}$"] => add(Type = "http://schemas.tf.com/identity/claims/userstatus", Value = "EXPERT");
2.および3. との違いは大丈夫ですよね？ここでは3ケタの数字だったら EXPERT を userstatus に入力します。なお、4ケタ以上については今回は考慮していません。
5. UserStatus クレームを発行する
ここまでのルールで、ログオン回数に応じて userstatus クレームに「BEGINNER」「SENIOR」「EXPERT」のいずれかの文字列が格納されているはずです。ただし、userstatus は add で発行されたため、外部に対して発行されていません。 よって、ここではアプリケーションに対してクレームを発行するために Issue を使用ます。
ここまでのルールで、ログオン回数に応じて userstatus クレームに「BEGINNER」「SENIOR」「EXPERT」のいずれかの文字列が格納されているはずです。ただし、userstatus は add で発行されたため、外部に対して発行されていません。
よって、ここではアプリケーションに対してクレームを発行するために Issue を使用ます。
以上でクレームルールの設定は完了です。
以下のように5つのルールが順番に並んでいるでしょうか？
よろしければ保存して、アプリケーションの動作を確認してみましょう。以下は出力例です。
カスタムルールの作成方法については、以下の投稿も参考にしてください。
いろいろと書きたいことがあるのですが、今回は AD FS 2.0 の PowerShell コマンドレットについて、その第一歩を書いておきます。
英語がイヤでない方は、原文である以下の記事もどうぞ。
AD FS 2.0 for Windows PowerShell Basics
AD FS 2.0 をインストールすると、AD FS 2.0 用 PowerShell コマンドレットもインストールされます。
試しに、AD FS 2.0 がインストールされた環境で PowerShell コンソールを起動し、「Get-PSSnapin –Registered」と入力してみてください。AD FS 2.0 用コマンドレットが正しくインストールされていれば以下のように表示されます。
PS C:\> Get-PSSnapin –Registered
Name : Microsoft.Adfs.PowerShell PSVersion : 1.0 Description : This powershell snap-in contains cmdlets used to manage Microsoft Identity Server resources.
なおこの結果は「システムに登録されている」ことを示しており、実際に使用するには、おなじみの「Add-PSSnapin」を使用する必要があります。以下のように入力すれば、現在のセッションで AD FS 2.0 コマンドレットを使用することができます。
PS C:\> Add-PSSnapin Microsoft.Adfs.PowerShell
PowerShell を使ったことがある方ならばご存知の通り、Add-PSSnapin をプロファイルに書いておけば、次回 PowerShell 起動時に自動的に AD FS 2.0コマンドレットを読み込ませることができます。
AD FS 2.0 がインストールされたマシンでプロファイルを作ったことが無い場合には、はじめに以下のコマンドで WindowsPowerShell ディレクトリを作成してください。<UserName> は、ログオンしているユーザー ID を指定します。
次に上記フォルダにプロファイル（Microsoft.PowerShell_profile.ps1）を作成します。$PROFILE には、プロファイルへのフルパスが格納されています（C:\Users\<UserName>\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1)。
なお、プロファイルが存在しない場合には、当然ですが以下のメッセージが表示されますので「はい」をクリックしてください。
ファイル C:\Users\<username>\Documents\WindowsPowerShell\Microsoft_PowerShell_Profile.ps1 が見つかりません。新しく作成しますか？
メモ帳が開いたら、以下のコマンドを書き込み、保存します。
Add-PSSnapin Microsoft.Adfs.PowerShell
なお、未署名のローカルに保存されたスクリプトの実行を許可するために、以下のコマンドも入力しておいてください。知っている方にとってはお約束ではありますが、念のため。
PS C:\> Set-ExecutionPolicy RemoteSigned
実行ポリシーの変更 実行ポリシーは、信頼されていないスクリプトからの保護に役立ちます。実行ポリシーを変更すると、about_Execution_Policies のヘルプ トピックで説明されているセキュリティ上の危険にさらされる可能性があります。実行ポリシーを変更しますか? [Y] はい(Y) [N] いいえ(N) [S] 中断(S) [?] ヘルプ (既定値は "Y"): Y PS C:\>
使用可能なコマンドレットの一覧を表示するには Get-Command を使用しますが、これでは一切合財のコマンドが表示されてしまって面倒です。
AD FS 2.0 用コマンドレットは、ADFS というプレフィックスがついているので、以下のように入力すれば ADFS 関連のコマンドレットのみを表示することができます。
PS C:\> Get-Command *-ADFS*
CommandType Name Definition ----------- ---- ---------- Cmdlet Add-ADFSAttributeStore Add-ADFSAttributeStore -Name <String> -StoreType... Cmdlet Add-ADFSCertificate Add-ADFSCertificate -CertificateType <String> -T... Cmdlet Add-ADFSClaimDescription Add-ADFSClaimDescription -Name <String> -ClaimTy... Cmdlet Add-ADFSClaimsProviderTrust Add-ADFSClaimsProviderTrust -Name <String> -Iden... Cmdlet Add-ADFSRelyingPartyTrust Add-ADFSRelyingPartyTrust -Name <String> -Identi... Cmdlet Disable-ADFSClaimsProviderTrust Disable-ADFSClaimsProviderTrust -TargetClaimsPro... Cmdlet Disable-ADFSEndpoint Disable-ADFSEndpoint [[-TargetAddressPath] <Stri... Cmdlet Disable-ADFSRelyingPartyTrust Disable-ADFSRelyingPartyTrust -TargetIdentifier ... Cmdlet Enable-ADFSClaimsProviderTrust Enable-ADFSClaimsProviderTrust -TargetClaimsProv... Cmdlet Enable-ADFSEndpoint Enable-ADFSEndpoint [[-TargetAddressPath] <Strin... Cmdlet Enable-ADFSRelyingPartyTrust Enable-ADFSRelyingPartyTrust -TargetIdentifier <... Cmdlet Get-ADFSAttributeStore Get-ADFSAttributeStore [[-Name] <String[]>] [-Ve... Cmdlet Get-ADFSCertificate Get-ADFSCertificate [[-CertificateType] <String[... Cmdlet Get-ADFSClaimDescription Get-ADFSClaimDescription [[-Name] <String[]>] [-... Cmdlet Get-ADFSClaimsProviderTrust Get-ADFSClaimsProviderTrust [[-Name] <String[]>]... Cmdlet Get-ADFSEndpoint Get-ADFSEndpoint [[-AddressPath] <String[]>] [-V... Cmdlet Get-ADFSProperties Get-ADFSProperties [-Verbose] [-Debug] [-ErrorAc... Cmdlet Get-ADFSProxyProperties Get-ADFSProxyProperties [-Verbose] [-Debug] [-Er... Cmdlet Get-ADFSRelyingPartyTrust Get-ADFSRelyingPartyTrust [[-Name] <String[]>] [... Cmdlet Get-ADFSSyncProperties Get-ADFSSyncProperties [-Verbose] [-Debug] [-Err... Cmdlet New-ADFSClaimRuleSet New-ADFSClaimRuleSet -ClaimRule <String[]> [-Ver... Cmdlet New-ADFSContactPerson New-ADFSContactPerson [-Company <String>] [-Emai... Cmdlet New-ADFSOrganization New-ADFSOrganization -DisplayName <String> -Orga... Cmdlet New-ADFSSamlEndpoint New-ADFSSamlEndpoint -Binding <String> -Protocol... Cmdlet Remove-ADFSAttributeStore Remove-ADFSAttributeStore [-TargetName] <String>... Cmdlet Remove-ADFSCertificate Remove-ADFSCertificate [-TargetCertificate] <Ser... Cmdlet Remove-ADFSClaimDescription Remove-ADFSClaimDescription [-TargetName] <Strin... Cmdlet Remove-ADFSClaimsProviderTrust Remove-ADFSClaimsProviderTrust -TargetClaimsProv... Cmdlet Remove-ADFSRelyingPartyTrust Remove-ADFSRelyingPartyTrust -TargetIdentifier <... Cmdlet Revoke-ADFSProxyTrust Revoke-ADFSProxyTrust [-Verbose] [-Debug] [-Erro... Cmdlet Set-ADFSAttributeStore Set-ADFSAttributeStore [-TargetName] <String> [-... Cmdlet Set-ADFSCertificate Set-ADFSCertificate -CertificateType <String> -T... Cmdlet Set-ADFSCertSharingContainer Set-ADFSCertSharingContainer -ServiceAccount <St... Cmdlet Set-ADFSClaimDescription Set-ADFSClaimDescription [-TargetName] <String> ... Cmdlet Set-ADFSClaimsProviderTrust Set-ADFSClaimsProviderTrust [-Name <String>] [-I... Cmdlet Set-ADFSEndpoint Set-ADFSEndpoint [[-TargetAddressPath] <String>]... Cmdlet Set-ADFSProperties Set-ADFSProperties [-AuthenticationContextOrder ... Cmdlet Set-ADFSProxyProperties Set-ADFSProxyProperties [-HostName <String>] [-H... Cmdlet Set-ADFSRelyingPartyTrust Set-ADFSRelyingPartyTrust [-Name <String>] [-Not... Cmdlet Set-ADFSSyncProperties Set-ADFSSyncProperties [-PrimaryComputerName <St... Cmdlet Update-ADFSCertificate Update-ADFSCertificate [[-CertificateType] <Stri... Cmdlet Update-ADFSClaimsProviderTrust Update-ADFSClaimsProviderTrust [-MetadataFile <S... Cmdlet Update-ADFSRelyingPartyTrust Update-ADFSRelyingPartyTrust [-MetadataFile <Str...
コマンドレットのヘルプを参照するには、ご存知 Get-Help を使用します。以下は、Set-ADFSProperties のヘルプを参照しています。
名前 Set-ADFSProperties
概要 フェデレーション サービスのプロパティを設定します。
構文 Set-ADFSProperties [-AcceptableIdentifier <Uri[]>] [-AddProxyAuthorizationRules <string>] [-ArtifactDbConnection <s tring>] [-AuthenticationContextOrder <Uri[]>] [-AutoCertificateRollover <Boolean>] [-CertificateCriticalThreshold < int>] [-CertificateDuration <int>] [-CertificateGenerationThreshold <int>] [-CertificatePromotionThreshold <int>] [ -CertificateRolloverInterval <int>] [-CertificateThresholdMinutesMultiplier <int>] [-ContactPerson <ContactPerson[] >] [-EncryptionCertRevocationCheck <string>] [-ExtendedProtectionTokenCheck <string>] [-FederationPassiveAddress <s tring>] [-HostName <string>] [-HttpPort <int>] [-HttpsPort <int>] [-Identifier <Uri>] [-LogLevel <string[]>] [-Moni toringInterval <int>] [-NetTcpPort <int>] [-NtlmOnlySupportedClientAtProxy <Boolean>] [-OrganizationInfo <Organizat ion>] [-PassThru] [-PreventTokenReplays <System.Nullable[bool]>] [-ProxyTrustTokenLifetime <int>] [-RequireSignedSa mlRequests <System.Nullable[bool]>] [-SamlMessageDeliveryWindow <int>] [-SigningCertRevocationCheck <string>] [-Sig nSamlAuthnRequests <System.Nullable[bool]>] [-SsoLifetime <int>] [-Confirm] [-WhatIf] [<CommonParameters>]
説明 Set-ADFSProperties コマンドレットは、フェデレーション サービスのグローバル プロパティおよび構成を設定します。
関連するリンク Online version: http://go.microsoft.com/fwlink/?LinkId=177389 Get-ADFSProperties
注釈 例を参照するには、次のように入力してください: "get-help Set-ADFSProperties -examples". 詳細を参照するには、次のように入力してください: "get-help Set-ADFSProperties -detailed". 技術情報を参照するには、次のように入力してください: "get-help Set-ADFSProperties -full".
PS C:\>
ワイルドカードを使用すれば複数のコマンドレットのヘルプを一度に表示することもできます。例えば以下のように入力します。
PS C:\> Get-Help *-ADFS*
Name Category Synopsis ---- -------- -------- Add-ADFSAttributeStore Cmdlet フェデレーション サービスに属性ストアを追加します。 Add-ADFSCertificate Cmdlet 署名、暗号化解除、または通信保護のための新しい証明書をフェデレーション ... Add-ADFSClaimDescription Cmdlet フェデレーション サービスに要求記述を追加します。 Add-ADFSClaimsProviderTrust Cmdlet 新しい要求プロバイダー信頼をフェデレーション サービスに追加します。 Add-ADFSRelyingPartyTrust Cmdlet 新しい証明書利用者信頼をフェデレーション サービスに追加します。 Remove-ADFSClaimsProviderTrust Cmdlet フェデレーション サービスから要求プロバイダー信頼を削除します。 Disable-ADFSClaimsProviderTrust Cmdlet フェデレーション サービスの要求プロバイダー信頼を無効にします。 Enable-ADFSEndpoint Cmdlet フェデレーション サービスのエンドポイントを有効にします。 Disable-ADFSEndpoint Cmdlet フェデレーション サービスのエンドポイントを無効にします。 Remove-ADFSRelyingPartyTrust Cmdlet フェデレーション サービスから証明書利用者信頼を削除します。 Disable-ADFSRelyingPartyTrust Cmdlet フェデレーション サービスの証明書利用者信頼を無効にします。 Enable-ADFSClaimsProviderTrust Cmdlet フェデレーション サービスの要求プロバイダー信頼を有効にします。 Enable-ADFSRelyingPartyTrust Cmdlet フェデレーション サービスの証明書利用者信頼を有効にします。 Get-ADFSAttributeStore Cmdlet フェデレーション サービスの属性ストアを取得します。 Get-ADFSCertificate Cmdlet フェデレーション サービスに存在する証明書を取得します。 Get-ADFSClaimDescription Cmdlet フェデレーション サービスに存在する要求記述を取得します。 Get-ADFSClaimsProviderTrust Cmdlet フェデレーション サービスの要求プロバイダー信頼を取得します。 Get-ADFSEndpoint Cmdlet フェデレーション サービスのエンドポイントを取得します。 Get-ADFSProxyProperties Cmdlet フェデレーション サーバー プロキシのプロパティを取得します。 Get-ADFSRelyingPartyTrust Cmdlet フェデレーション サービスの証明書利用者信頼を取得します。 Get-ADFSProperties Cmdlet フェデレーション サービスのプロパティを取得します。 Get-ADFSSyncProperties Cmdlet フェデレーション サービスの構成データベースの同期プロパティを取得します。 New-ADFSClaimRuleSet Cmdlet 新しい要求規則のセットを作成します。 New-ADFSContactPerson Cmdlet 新しい連絡担当者オブジェクトを作成します。 New-ADFSOrganization Cmdlet 新しい組織情報オブジェクトを作成します。 New-ADFSSamlEndpoint Cmdlet 新しい SAML プロトコル エンドポイント オブジェクトを作成します。 Remove-ADFSAttributeStore Cmdlet フェデレーション サービスから属性ストアを削除します。 Remove-ADFSCertificate Cmdlet フェデレーション サービスから証明書を削除します。 Remove-ADFSClaimDescription Cmdlet フェデレーション サービスから要求記述を削除します。 Revoke-ADFSProxyTrust Cmdlet フェデレーション サービスに構成されているすべてのフェデレーション サーバ... Set-ADFSAttributeStore Cmdlet 属性ストアのプロパティを設定します。 Set-ADFSCertificate Cmdlet フェデレーション サービスが署名、暗号化解除、または通信保護に使用する既... Set-ADFSClaimDescription Cmdlet 既存の要求記述のプロパティを設定します。 Set-ADFSClaimsProviderTrust Cmdlet 要求プロバイダー信頼のプロパティを設定します。 Set-ADFSCertSharingContainer Cmdlet フェデレーション サーバー ファーム内で管理対象証明書を共有するために使用... Set-ADFSEndpoint Cmdlet フェデレーション サービスのエンドポイントのプロパティを設定します。 Set-ADFSProxyProperties Cmdlet フェデレーション サーバー プロキシのプロパティを設定します。 Set-ADFSRelyingPartyTrust Cmdlet 証明書利用者信頼のプロパティを設定します。 Set-ADFSProperties Cmdlet フェデレーション サービスのプロパティを設定します。 Set-ADFSSyncProperties Cmdlet フェデレーション サーバー ファームのデータベース同期エンジンのプロパティ... Update-ADFSCertificate Cmdlet フェデレーション サービスの証明書を更新します。 Update-ADFSClaimsProviderTrust Cmdlet フェデレーション メタデータの要求プロバイダー信頼を更新します。 Update-ADFSRelyingPartyTrust Cmdlet フェデレーション メタデータの証明書利用者信頼を更新します。
ちょっと最近の流れと関係のない話を。
昨日、とある知り合いの方からこんなメールをもらいました。
「CALCS って[継承]の設定ってできなかったですよね？」
一瞬「あれ？どうだったっけかな」と悩みました。icacls.exe には /inheritance パラメタがあるからできそうですよね。
でも cacls ってどうだったっけ？
ちょっとBINGってみたところ、デジタルアドバンテージの打越さんがとても素晴らしい記事を残してくれていました。
なんてマニアックな記事でしょう!（笑）。素晴らしすぎて涙が出ます。（何名の方がこの記事をご覧になったのか気になるところではありますが...）
あ、結論を言うと、「cacls コマンドでも継承の設定は可能です」。
補足記事として、英語ですが以下の記事もありますので興味のある方はどうぞ。
そろそろ、いろいろと本気を出さないとやばい感じの安納です orz
それはともかく、12月11日（土）に半期に一度のお楽しみ「Tech Fielders の集い」を開催いたします。
Tech Fielders の集い 2010 冬 ～ クラウドごった煮で温まろう
今回のお題は「クラウドをテーマに情報発信 ! 」。
ということで、クラウドテクノロジーを基盤とした各コミュニティの方々および、「中の方々」にご参加いただき、各テクノロジーについて思う存分語っていただきます。
実は、既に上記サイトに当日のアジェンダを掲載しつつ参加募集を開始しておりますが、各界のコミュニティメンバーから、
「甘い！」「MS、Amazon、Google だけだと思うなよ！」「思い上がるな！」「これじゃ面白くない！」「ふざけんな！」「中の人は LT でもやってろ！」「もっとやせろ！」
などと叩かれまして、さらに参加団体を増やし、もっとカバー範囲を広げたイベントにしようとしております。
現時点では以下の内容をベースに詳細を詰めておりますので、既にお申込みのみなさま、ご了承いただければ幸いです。
いずれにしても、内容の濃い、ご満足いただける、おもわずつぶやきたくなる内容になることに違いはありませんので、ご期待ください。
司会 パブリックキー 新野さん
13:00-14:35 「IaaS 陣営紹介＋後半パネルディスカッション」
Amazon Web Services・CUPA(Eucalyptus/OpenStack/CloudStack/Wakame)・ニフティクラウド
もはや価格競争の段階に突入した感のある IaaS 各ベンダーは次の価値を何に求めるか！
14:40-16:15 「PaaS 陣営紹介＋後半パネルディスカッション」
マイクロソフト・Google・Heroku・SalesForce IaaS に比べて普及が遅れている感のある PaaS 陣営普及のカギとは一体なんぞや？
マイクロソフト・Google・Heroku・SalesForce
IaaS に比べて普及が遅れている感のある PaaS 陣営普及のカギとは一体なんぞや？
16:20-18:00 「（方向性検討中）＋後半パネルディスカッション」
Hadoop・DeNA・Vyatta
クラウドによって変化するアプリケーションの開発・デリバリそれとユーザー視点での変化について
18:00-18:30 中の人のライトニングトーク (MS, Amazon, Google, SalesForce)
18:30-20:00 懇親会
2010年11月29日、PDC Japan 2010 に間に合わず残念だった Windows Azure の新ポータルがオープンしました。
http://windows.azure.com/ にアクセスすると以下の画面が最初に出てきます。
ここで 「Use the New Portal」を選択すれば新しいポータル画面に移動することができます。旧ポータルで使用していた資源はそのまま新しいGUIでしようすることができますので安心してください。
新ポータルの新機能は実際に見ていただくのが早いのですが、ベータプログラムにも参加できるようになっています。
中でもお勧めなのが、「Windows Azure Connect」という機能。コードネーム「Project “Sydney”」と呼ばれていたものです。この機能を使用すると、クラウドとオンプレミスの間に IPSEC が張られ、クラウドからオンプレミスに直接アクセスすることができます。
Windows Azure Connect の利用シナリオとして挙げられているのが、以下のようなものです。
などなど。
この他、クラウドのインスタンスにリモートデスクトップで入れるようになっていたりなど、IT Pro として魅力的な機能が満載です。
是非とも試してみてください。
2011/6/7 最新の手順は以下をご覧ください！
Windows Azure に簡単なサービスを展開するための操作手順
ｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ
Windows Azure ポータルが新しくなり、何がうれしいってリモートデスクトップ機能が使えるようになったことです。つまり、リモートデスクトップを使用して、Winodws Azure のインスタンスにログオンし、OS や アプリケーションの状態を社内サーバーのように参照することができます。
ただし...リモートデスクトップで入るには事前に設定をしておく必要があり、これがまた ITPro には敷居が高いところでして...なぜならば Visual Studio を使用しなければならないから....なので、今回は IT Pro のために リモートデスクトップを有効にするための手順を紹介します。
１．Visual Web Developer 2010 Express をインストールする
現時点では、Windows Azure 上の OS のリモートデスクトップ機能を有効にするには、Visual Studio を使用する必要があります。PowerShell 等で有効にできるとよいのですが、現時点でその方法が公開されておりません。仕方がないので、ここは涙をこらえて Visual Studio を使用しましょう。 既に Visual Studio 2010 がインストールされているという IT Pro の方は読み飛ばしてください。 今回使用するのは、Visual Studio 2010 Express の中でも、Web 開発に特化したエディションである Visual Web Developer 2010 Express です。
現時点では、Windows Azure 上の OS のリモートデスクトップ機能を有効にするには、Visual Studio を使用する必要があります。PowerShell 等で有効にできるとよいのですが、現時点でその方法が公開されておりません。仕方がないので、ここは涙をこらえて Visual Studio を使用しましょう。
既に Visual Studio 2010 がインストールされているという IT Pro の方は読み飛ばしてください。
今回使用するのは、Visual Studio 2010 Express の中でも、Web 開発に特化したエディションである Visual Web Developer 2010 Express です。
以下の Web プラットフォーム インストーラー（Web PI）サイトに移動し、Web PI をダウンロードして実行しましょう。
Download the Microsoft Web Platform
Web PI を実行すると、以下の画面が表示されます。何も考えずに「 Visual Web Developer 2010 Express」を選択して [インストール] ボタンをクリックしてください。
２．Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio (November 2010) をインストールする
Windows Azure に関連した開発を行うには、Windows Azure 用の SDK および Visual Studio 用の Addin がインストールされていなければなりません。 以下のサイトから、「Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio (November 2010) 」をダウンロードしてインストールしてください。インストールするのは、以下の2つのファイルです。 WindowsAzureSDK-x64.exe または WindowsAzureSDK-x86.exe (x64 と x86 が用意されているので環境に合ったものをインストールしてください) VSCloudService.exe Download details: Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio (November 2010) インストールが完了したら、コントロールパネルの[プログラムと機能]に以下が表示されていることを確認してください。特にバージョン番号は重要ですので注意しましょう。 Windows Azure SDK v1.3.11122.0038 Widnows Azure Tools for Visual Studio 2010 1.3 v1.3.31122.1601
Windows Azure に関連した開発を行うには、Windows Azure 用の SDK および Visual Studio 用の Addin がインストールされていなければなりません。
以下のサイトから、「Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio (November 2010) 」をダウンロードしてインストールしてください。インストールするのは、以下の2つのファイルです。
Download details: Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio (November 2010)
インストールが完了したら、コントロールパネルの[プログラムと機能]に以下が表示されていることを確認してください。特にバージョン番号は重要ですので注意しましょう。
以上で準備は完了です。
あ、もちろん、Windows Azure のアカウントは事前に用意しておいてください。
次回は Visual Studio を起動しアプリケーションを作成します（するのか？）。
つづき
前回の続きです。
【Azure for ITPro】Widnows Azure にリモートデスクトップで入り込むための手順 (1) http://blogs.technet.com/b/junichia/archive/2010/11/30/3371946.aspx
さっそくはじめましょう。
３．Visual Studio を起動する
スタートメニューから、Microsoft Visual Web Developer 2010 Express を右クリックして、「管理者として実行」を選択してください。
Visual Studio が起動したら、スタートページで [ファイル]-[新しいプロジェクト] を選択します。
４．Azure アプリ用のテンプレートを選択する
「新しいプロジェクト」ウィンドウの右側には [Visual Basic] と [Visual C#] という2つのノードが表示されますが、好きなほうを開いてください。今回は Visual C# を選択していますが、どうせコードは書きませんから関係ありません（笑）。 そんなことよりも、その配下にある「Cloud」が重要です。「Cloud」を選択し、中央のペインに「Windows Azure Project」が表示されていることを確認したら「OK」をクリックします。 最後に、プロジェクトに含めるロールインスタンスを選択するのですが、ここも何も考えず「ASP.NET Web Role」を選択し、「>>」ボタンをクリックしてください。すると、以下のように表示されているはずです。 問題が無ければ [OK] をクリックしてください。 以下のように表示されていれば、OKです。
「新しいプロジェクト」ウィンドウの右側には [Visual Basic] と [Visual C#] という2つのノードが表示されますが、好きなほうを開いてください。今回は Visual C# を選択していますが、どうせコードは書きませんから関係ありません（笑）。
そんなことよりも、その配下にある「Cloud」が重要です。「Cloud」を選択し、中央のペインに「Windows Azure Project」が表示されていることを確認したら「OK」をクリックします。
最後に、プロジェクトに含めるロールインスタンスを選択するのですが、ここも何も考えず「ASP.NET Web Role」を選択し、「>>」ボタンをクリックしてください。すると、以下のように表示されているはずです。
問題が無ければ [OK] をクリックしてください。
以下のように表示されていれば、OKです。
５．動作確認してみる
試しに、[F5] をクリックしてデバッグを開始してみてください。デバッグといっても何もコードを書いてないのでエラーの出ようがないのですが...。 もし、以下のようなエラーが出る場合には、「管理者として実行」されていないためです。一度 Visual Studio を停止して、再度「管理者として実行」で起動してください。 The Windows Azure comute emulator must be run elevated.Please restart Visual Studio in elevated administrator mode in order to run the project. 正常に実行されると、デスクトップの右下に「Windows Azure Emulator」が起動し、デバッグが始まります。 正常に実行されると、以下のような画面が表示されます。これはテンプレートに既定で組み込まれたコードです。今回はこのまま Windows Azure 上にアップロードしてしまいましょう。 確認したらブラウザは閉じてください。デバッグも自動的に終了します。
試しに、[F5] をクリックしてデバッグを開始してみてください。デバッグといっても何もコードを書いてないのでエラーの出ようがないのですが...。
もし、以下のようなエラーが出る場合には、「管理者として実行」されていないためです。一度 Visual Studio を停止して、再度「管理者として実行」で起動してください。
The Windows Azure comute emulator must be run elevated.Please restart Visual Studio in elevated administrator mode in order to run the project.
正常に実行されると、デスクトップの右下に「Windows Azure Emulator」が起動し、デバッグが始まります。
正常に実行されると、以下のような画面が表示されます。これはテンプレートに既定で組み込まれたコードです。今回はこのまま Windows Azure 上にアップロードしてしまいましょう。
確認したらブラウザは閉じてください。デバッグも自動的に終了します。
次回は Windows Azure 上にサービスを作成し、いま作成したアプリケーション（テンプレートのままですが（笑））をアップロードします。
前回までの投稿は以下の通りです。
今回は アプリケーションにリモートデスクトップの設定を埋め込んでパッケージ化しましょう。
６．リモートデスクトップを有効にしたパッケージを作成する
Visual Studio の右側にある「ソリューションエクスプローラー」から作成中のプロジェクト（ここでは WindowsAzureProject）を右クリックして [発行] を選択します。
「Deploy Windows Azure Project」画面が表示されるので、「Create Service Package Only」を選択し、さらに一番下にある「Configure Remote Desktop Connections...」をクリックしてください。 ちなみに、いま選択した「Create Service Package Only」についてちょっとだけ触れておきましょう。 「Deploy your Windows Azure project to Windows Azure」はアプリケーションを直接 Windows Azure 上に展開する際に使用するオプションです。Visual Studio はこのオプションを使用して、作成したパッケージを直接 Widnows Azure のサービスに展開することができるのですが、IT Pro のみなさんにとっては、それは勘弁してほしいですよね。つまり、開発者が自分の知らないところでアプリケーションを展開してしまうのはやめてほしいと考えるはずです。 そこで、「Create Service Package Only」を使用してパッケージファイルだけ作成し、展開は IT Pro が Winodws Azure ポータルから実施する...これがおそらく当面のスタンダードな手順かと思います（今後は、こうした文化も変わってくるのかもしれませんね） さて、話を戻しましょう。 [Configure Remote Desktop connections...] をクリックすると、「Remote Desktop Configuration」画面が表示されます。ここで「Enable connections for all roles」をチェックしてください。 次に、リモートデスクトップに使用する証明書を作成します。オンプレミスの Windows Server に接続する場合には、自動的に証明書が作成されて使用されるので意識することはあまり無いのですが、Windows Azure の場合には証明書の管理方法が特殊（言い換えれば普通のWindows Server と比較してセキュア）なこともあり、自分で準備してあげる必要があります。 「証明書」といっても別に構える必要はありません。このGUIを使用して作成することができます。 プルダウンを開き、 <Create...> を選択してください。既に一覧に証明書が表示されているかもしれませんが、ひとまず無視してください。 [Create Certificate] ウィンドウが開くので、証明書の識別名を入力してください。何でも結構です。気にせず入力しちゃってください。今回は certificate for RDS と入力しました。 [OK] をクリックすると元の画面に戻り、いま作成した証明書が選択されています。 ここで、[View...] をクリックしてください。以下のように、いま作成した証明書が表示されます。 さて、ちょいと面倒...というか理解しずらいのがここからです。 今行った作業によって何が完了したのか...というと、 リモートデスクトップサービスの通信に使用する証明書の作成 使用する証明書と OS の関連付け です。何か足りませんよね？そうです。証明書は Windows Azure 上の OS にアップロードされていなければなりませんが、Visual Studio はそこまでやってくれません。別途実施（サービス証明書のアップロード）する必要があるのです。 アップロードする証明書は「サービス証明書」と呼ばれるもので、PFX形式でなければなりません。PFX形式の証明書を出力するには、上のように、[詳細]タブを選択して、[ファイルにコピー」をクリックします。 証明書のエクスポートウィザードが表示されるので、以下のような流れで PFXファイルを作成してください。 →→→ →→ エクスポートした PFX ファイルはあとで Windows Azure Portal で使用しますから、保存場所を忘れないでください。 最後にリモートデスクトップでログオンするための ユーザーID とパスワード、そしてアカウントの有効期限を指定します。個々で指定したユーザーIDが Windows Azure 上のインスタンスに自動的に作成され、リモートデスクトップログオンの権限が与えられます。 なお、有効期限にはくれぐれも注意してください。既定では 1月 しか与えられません。 全て指定したら OK をクリックしてください。 さらに、Deploy Windows Azure project 画面でも [OK] をクリックしましょう。 以下のように、作成されたパッケージファイルが表示されます。
「Deploy Windows Azure Project」画面が表示されるので、「Create Service Package Only」を選択し、さらに一番下にある「Configure Remote Desktop Connections...」をクリックしてください。
ちなみに、いま選択した「Create Service Package Only」についてちょっとだけ触れておきましょう。
「Deploy your Windows Azure project to Windows Azure」はアプリケーションを直接 Windows Azure 上に展開する際に使用するオプションです。Visual Studio はこのオプションを使用して、作成したパッケージを直接 Widnows Azure のサービスに展開することができるのですが、IT Pro のみなさんにとっては、それは勘弁してほしいですよね。つまり、開発者が自分の知らないところでアプリケーションを展開してしまうのはやめてほしいと考えるはずです。
そこで、「Create Service Package Only」を使用してパッケージファイルだけ作成し、展開は IT Pro が Winodws Azure ポータルから実施する...これがおそらく当面のスタンダードな手順かと思います（今後は、こうした文化も変わってくるのかもしれませんね）
さて、話を戻しましょう。
[Configure Remote Desktop connections...] をクリックすると、「Remote Desktop Configuration」画面が表示されます。ここで「Enable connections for all roles」をチェックしてください。
次に、リモートデスクトップに使用する証明書を作成します。オンプレミスの Windows Server に接続する場合には、自動的に証明書が作成されて使用されるので意識することはあまり無いのですが、Windows Azure の場合には証明書の管理方法が特殊（言い換えれば普通のWindows Server と比較してセキュア）なこともあり、自分で準備してあげる必要があります。
「証明書」といっても別に構える必要はありません。このGUIを使用して作成することができます。
プルダウンを開き、 <Create...> を選択してください。既に一覧に証明書が表示されているかもしれませんが、ひとまず無視してください。
[Create Certificate] ウィンドウが開くので、証明書の識別名を入力してください。何でも結構です。気にせず入力しちゃってください。今回は certificate for RDS と入力しました。
[OK] をクリックすると元の画面に戻り、いま作成した証明書が選択されています。
ここで、[View...] をクリックしてください。以下のように、いま作成した証明書が表示されます。
さて、ちょいと面倒...というか理解しずらいのがここからです。
今行った作業によって何が完了したのか...というと、
です。何か足りませんよね？そうです。証明書は Windows Azure 上の OS にアップロードされていなければなりませんが、Visual Studio はそこまでやってくれません。別途実施（サービス証明書のアップロード）する必要があるのです。
アップロードする証明書は「サービス証明書」と呼ばれるもので、PFX形式でなければなりません。PFX形式の証明書を出力するには、上のように、[詳細]タブを選択して、[ファイルにコピー」をクリックします。
証明書のエクスポートウィザードが表示されるので、以下のような流れで PFXファイルを作成してください。
→→→
→→
エクスポートした PFX ファイルはあとで Windows Azure Portal で使用しますから、保存場所を忘れないでください。
最後にリモートデスクトップでログオンするための ユーザーID とパスワード、そしてアカウントの有効期限を指定します。個々で指定したユーザーIDが Windows Azure 上のインスタンスに自動的に作成され、リモートデスクトップログオンの権限が与えられます。
なお、有効期限にはくれぐれも注意してください。既定では 1月 しか与えられません。
全て指定したら OK をクリックしてください。
さらに、Deploy Windows Azure project 画面でも [OK] をクリックしましょう。
以下のように、作成されたパッケージファイルが表示されます。
ITPRO にとっての Windows Azure Platform は、ハードウェアなどの日常メンテ業務から解放されることが着目されがちですが、実を言えばすこし面倒（?）な事態も発生します。それは、これまで敬遠しがちだったテクノロジーに正面（とはいわず斜め前くらい）から向き合わなければならない...という点です。その1つが、「証明書」です。
過去の Azure for ITPRO シリーズも参考にしてください。
先の投稿でも触れている通り、Windows Azure 上のサービスに展開したアプリケーションを SSL 対応にするには、「サービス証明書（.pfx）」と呼ばれる証明書ファイルを準備しておく必要があります。
ただ、ちょっとテストがしたい...など正式な証明書の発行を待てない場合には、とりいそぎ自己署名証明書を使用したいはずです。
自己署名証明書を作成する代表的な方法は2つあります。
IIS 管理コンソールを使用した場合、作成できる自己署名証明書の主体（発行先）は自分自身です。
Windows Azure 上にアプリケーションを展開した場合、その URL は xxxxxxx.cloudapp.net もしくは CNAME ですので、IIS 管理コンソールでは対応できません（ローカルに xxxxxxxx.cloudapp.net を展開する...という手もなくはありませんが...）。
主体名（発行先）を自由に指定するには、Windows SDK で提供されている makecert コマンドおよび pvk2pfx コマンドを使用することができます。
コマンドを使用する前に、以下をインストールしておいてください。
もしコマンドは既に手元にある...という場合には、以下だけダウンロードしてインストールすれば使用することができます。
サービス証明書を作成する流れを以下に示します。
上の図に示したとおり、まずは makecert コマンドを使用して .cer ファイルと .pvk ファイルを作成します。次に、pvk2pfx コマンドを使用して .pfx ファイルを作成し、これを サービス証明書として Windows Azure に展開したサービスに登録します。
さっそくやってみましょう。
まずは以下のように makecert コマンドを入力します。「test.cloudapp.net」は今回展開したサービスの FQDN です。もし CNAME でアクセスさせたい場合には、その FQDN を指定してください。
途中、証明書にセットするパスワードを2回聞かれますので、間違えずに入力してください。
このコマンドの結果、以下の 2つのファイルが作成されます。
今度は、この2つのファイルを入力パラメタとして使用し、pfx ファイルを作成します。<パスワード>部分には、makecert コマンドで指定したパスワードを入力してください。
この結果、以下のファイルが作成されます。
あとは、以下の記事で手順を解説しているとおり、Windows Azure のポータル画面から「サービス証明書」として登録します。
【Azure for ITPRO】証明書の管理について - フィールドSEあがりの安納です - Site Home - TechNet Blogs
AD FS 2.0 のクレームルール言語に関する解説を書いていて、ちょっと気になったことがありました。
Manager かどうか判断する場合に、TITLE（役職）属性を見る以外に何か方法は無いだろうかと...。
そういえば、Active Directory には「部下」的な属性があったよなぁ..と思い確認してみると...確かに「直属の部下」という属性があります。しかも、本人が触ることができないため、「役職」で判断するよりかは信頼がおけそうです。
さて、ここで問題です。この「直属の部下」という属性、Active Directory Domain Service 上での Attribute Name はなんでしょう？
正解は、
DirectReports
です。
属性エディタで確認するには、[フィルター] で [後方リンク] を有効にしなければなりません。
「後方リンク」について説明しようと思ったのですが、MVP の国井さんが詳細に解説してくれていますのでそちらをご覧ください。
Always on the clock（MVP 国井さん） 【再掲】前方リンクと後方リンク « Always on the clock
後方リンクを見えるようにすると、以下のように DirectReports 属性が見えるようになります。
ってことで、AD FS 2.0 のカスタムクレームルールを使用して directReports 属性を取得してみたいと思いますが、それは以下の投稿で。
【IDM】Active Directory の「直属の部下」属性からマネージャーかどうかを判断する 1/2 - フィールドSEあがりの安納です - Site Home - TechNet Blogs
前回、以下の記事を投稿しました。
【IDM】Active Directory の「直属の部下」属性 - フィールドSEあがりの安納です - Site Home - TechNet Blogs
今回は、AD FS 2.0 のカスタムルールで「直属の部下」属性を取り出してみます。
① 規則テンプレートの選択画面で、「カスタム規則を使用して要求を送信」を選択します
② 規則の構成画面で、要求規則名とカスタム規則を入力します
カスタム規則になんて書いてあるかというと、以下の通りです。 c:[Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname, Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.tf.com/Identity/Claims/directReports"), query = ";directReports;{0}", param = c.Value);
カスタム規則になんて書いてあるかというと、以下の通りです。
c:[Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname, Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.tf.com/Identity/Claims/directReports"), query = ";directReports;{0}", param = c.Value);
作業としては上記の通りです。
簡単に上記のクレーム規則を解説しておきます。
■ c
後ろに続くクレームが格納される変数です。意味が解りませんよね...。あとでわかります。
■ Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
クレームパイプラインから、windowsaccountname というクレームが渡されたかどうかを判断しています。windowsaccountname に値が入っていない場合にはクレームは渡されませんので、このクレームが存在するということは、事実上「Active Directory」で認証されたことの証拠となります。 ちなみに、windowsaccountname に入っている値はユーザーの msDS-PrincipalName であり、<ドメイン名>\<ユーザー名> の形式です。
クレームパイプラインから、windowsaccountname というクレームが渡されたかどうかを判断しています。windowsaccountname に値が入っていない場合にはクレームは渡されませんので、このクレームが存在するということは、事実上「Active Directory」で認証されたことの証拠となります。
ちなみに、windowsaccountname に入っている値はユーザーの msDS-PrincipalName であり、<ドメイン名>\<ユーザー名> の形式です。
■ Issuer == "AD AUTHORITY"
Issuer という綴りから、なんとなく想像つきますよね。そうです。windowsaccountname というクレームを発行したのが「AD AUTHORITY」であることを示しています。 つまり、「c:[Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname, Issuer == "AD AUTHORITY"] 」の部分全体で、 「Active Directory に認証されたユーザーならば」 というクレーム発行の条件を表現しています。
Issuer という綴りから、なんとなく想像つきますよね。そうです。windowsaccountname というクレームを発行したのが「AD AUTHORITY」であることを示しています。
つまり、「c:[Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname, Issuer == "AD AUTHORITY"] 」の部分全体で、
「Active Directory に認証されたユーザーならば」
というクレーム発行の条件を表現しています。
■ issue
クレームを発行するためのコマンドです。これ以降に続く文字列が、どんなクレームを発行するかを表現しています。
■ store = "Active Directory"
クレームが格納されている場所が「Active Directory」という名前の場所であることを示しています。勘違いしないでいただきたいのは、これが Active Directory Domain Service を示しているわけではありません。 AD FS 2.0 をインストールすると、規定で「Active Directory」という識別名の要求プロバイダーが登録されるのですが、このことを示しています。とはいえ、実際には Active Directory Domain Service なので、ひとまずあまり気にする必要はありません。
クレームが格納されている場所が「Active Directory」という名前の場所であることを示しています。勘違いしないでいただきたいのは、これが Active Directory Domain Service を示しているわけではありません。
AD FS 2.0 をインストールすると、規定で「Active Directory」という識別名の要求プロバイダーが登録されるのですが、このことを示しています。とはいえ、実際には Active Directory Domain Service なので、ひとまずあまり気にする必要はありません。
■ types = (“http://schemas.tf.com/Identity/Claims/directReports”)
発行するクレームタイプ（クレームの識別名）です。
■ query = ";directReports;{0}"
「Active Directory」ストアに対してクエリーを投げて結果をもらうのですが、その条件式です。見たとおり、directReports という属性を引っ張ってくるうことを示しています。では、誰の directReports 属性を引っ張ってくるのでしょう？ その条件を表現しているのが 「{0}」です。{0}は、msDS-PrincipalName に渡す引数を表しています。でも{0}がそのまま入るわけではありません。これは「0番目のパラメタ」という意味で、実際には下の「param」で指定された文字列が入ります。
「Active Directory」ストアに対してクエリーを投げて結果をもらうのですが、その条件式です。見たとおり、directReports という属性を引っ張ってくるうことを示しています。では、誰の directReports 属性を引っ張ってくるのでしょう？
その条件を表現しているのが 「{0}」です。{0}は、msDS-PrincipalName に渡す引数を表しています。でも{0}がそのまま入るわけではありません。これは「0番目のパラメタ」という意味で、実際には下の「param」で指定された文字列が入ります。
■ param = c.Value
param に指定された文字列で Active Directory の msDS-PrincipalName を検索するのですが、その値として c.Value が指定されています。 勘の良い方ならばおわかりですよね。この解説の冒頭に書いた「c」のことです。
param に指定された文字列で Active Directory の msDS-PrincipalName を検索するのですが、その値として c.Value が指定されています。
勘の良い方ならばおわかりですよね。この解説の冒頭に書いた「c」のことです。
ということで、このクレームルールを実行してみると、以下の通り、部下の一覧を取得することができます。
さて、ここでハタと気づきます....
「いやいや、部下の一覧をアプリケーションに渡したってアプリ側が面倒になるだけじゃん。 そうじゃなくて、部下がいたら「Manager」というクレームを渡したいのだよ」
はい、おっしゃるとおりです。
次回（以下）は、そんなカスタムクレームを書いてみます。
「マネージャーかどうかを判断しよう」の第3弾です。以前の投稿は以下をご覧ください。
前回の投稿で、Active Directory の DirectReports 属性から部下の一覧を持ってきました。
でも、この部下一覧をアプリケーションにごそっと渡したところで、アプリ側は迷惑なだけです。
どうせならば「DirectReports に部下が 一人以上存在していれば Manager である」と判断することはできないものでしょうか？
できます（それも乱暴な話ではあるのですが...）。
これを実現するには、以下のような 2 つのクレームルールを作成する必要があります。
■1つ目
1つ目のルールは、前回作成したものとほとんど変わりません。どこが違うかよーく見てください。
前回のルール c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue (store = "Active Directory", types = ("http://schemas.tf.com/Identity/Claims/directReports"), query = ";directReports;{0}", param = c.Value); 今回のルール c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add (store = "Active Directory", types = ("http://schemas.tf.com/Identity/Claims/directReports"), query = ";directReports;{0}", param = c.Value);
前回のルール c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue (store = "Active Directory", types = ("http://schemas.tf.com/Identity/Claims/directReports"), query = ";directReports;{0}", param = c.Value);
今回のルール c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add (store = "Active Directory", types = ("http://schemas.tf.com/Identity/Claims/directReports"), query = ";directReports;{0}", param = c.Value);
違いは、発行ステートメントとして、issue を使うか、add を使うかです。今回は、add を使っています。
両者の何が違うのか...詳しく描くと混乱を招くので興味のある方は以下をご覧ください。簡単に言ってしまうと、「外向けにクレームを発行するのが Issue で、クレームに格納するけども外には発行しないのが add 」です。つまり、add を使用すると、アプリケーションに余計なクレームを渡すことなく内部の処理だけで使用することができるのです。
■2つ目
DirectReports に格納されている値が1個以上ならば....なんて判断をどうするかというと、以下のようにします。
count ( [Type == "http://schemas.tf.com/Identity/Claims/directReports"]) > 0 => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value = "Manager");
なんと、count などという関数を使用することができるんですね。上の例では、directReports クレームに0より大きい値が入っていたら role クレームに Manager を放り込んで Issue する.. という意味になります。
実行結果例は以下の通りです。
こちらのほうが、アプリ側の処理もシンプルになっていいですよね。