Freigeben über

SharePoint 2010 と ADFS v2 を最初から最後まで構成する

  • Artikel

SharePoint 2010 と ADFS v2 を最初から最後まで構成する

この投稿では、SAML クレーム認証を使用できるように SharePoint 2010 と ADFS v2 を一緒に構成する方法を最初から最後まで解説します。 手順と PowerShell スクリプトを提示し、1 つの大きな投稿にすべての要素が盛り込まれるようにしたつもりです。

まず、構成に関係するコンポーネントと、やる必要のあることを簡単に説明しておきましょう。 このシナリオでは、ADFS v2 が IP-STS (Security Token Service) とも呼ばれる ID プロバイダーです。 証明書利用者 (RP) に関する情報で ADFS を構成する必要があります。 この例では SharePoint が RP です。SharePoint は、認証の実行とクレームの提供を ADFS に依存します。 SharePoint の観点から見ると、クレームを送信している IP-STS を信頼するように SharePoint を構成する必要があり、そのクレームを使用する Web アプリケーションとサイトを設定する必要があります。

最初に、ADFS の証明書利用者を作成します。 どのような順番で手順を実行しても問題はありませんが、私は ADFS の構成から始めることを習慣にしています。 ADFS がインストールされているサーバーに移動し、AD FS 2.0 Management アプリケーションを開きます。[信頼関係] (Trust Relationships) ノードを展開し、[証明書利用者信頼] (Relying Party Trusts) ノードをクリックします。

右側のウィンドウの [証明書利用者信頼の追加] (Add Relying Party Trust) リンクをクリックして、証明書利用者の追加 (Add Relying Party Trust) ウィザードを開始します。

[開始] (Start) ボタンをクリックして続行します。

[証明書利用者に関するデータを手動で入力する] (Enter data about the relying party manually) のオプションをオンにし、[次へ] (Next) ボタンをクリックします。

[表示名] (Display name) を入力し、オプションで証明書利用者の説明を入力して、[次へ] (Next) ボタンをクリックします。

[AD FS 2.0 プロファイル] (AD FS 2.0 profile) を使用するオプションをオンにして、[次へ] (Next) ボタンをクリックします。

SAML トークン自体を暗号化する証明書を選択できます。 ADFS では SharePoint との接続を SSL で行う必要があり、トークンの送信に使われるチャネルが既に暗号化されているため、ここで証明書を選択することはほとんどありません。 [次へ] (Next) ボタンをクリックします。

[WS-Federation パッシブ プロトコルのサポートを有効にする] (Enable support for the WS-Federation Passive protocol) のボックスをオンにします。 プロトコル URL として SharePoint Web アプリケーションのルート サイトの URL を入力し、"trust" サブディレクトリを含める必要があります。 この例では、私の SharePoint Web アプリケーションの URL は https://seo14 なので、WS-Federation パッシブ プロトコル URL は https://seo14/_trust/ になります。 URL を入力したら、[次へ] (Next) ボタンをクリックします。

証明書利用者信頼の識別子 (Relying party trust identifier) としては、ユーザーが Web アプリケーションにログインするときに Web アプリケーションが ADFS に渡す領域を入力する必要があります。 通常、領域は urn:foo:bar の形式で作成されます。 領域は Web アプリケーションに関連付けられ、着信したログイン要求を ADFS が自分の持っている証明書利用者信頼にマップする手段になります。 ADFS を SharePoint と共に使用すると、ADFS はログイン要求に関連付けられた領域を確認し、その領域に基づいて証明書利用者信頼を検索し、ユーザーを認証した後、その証明書利用者の WS-Federation パッシブ プロトコル URL に基づいて、後でユーザーをリダイレクトする場所を特定します。 したがって、この例では、私は urn:seo:sharepoint という領域を入力しました。 私が https://seo14 にある自分の SharePoint サイトへ移動しようとすると、ADFS にリダイレクトされます。私は、その要求があった場合に領域 urn:seo:sharepoint を使用するように SharePoint を構成します。 ADFS は、私を認証した後、再び私を https://seo14/_trust/ にリダイレクトします。それは、この URL がその証明書利用者のパッシブ プロトコル URL だからです。 使用するすべての領域をここに追加します。SharePoint を構成するときに同じ領域を入力する必要があるので、追加した領域をメモしておきます。 次に、[次へ] (Next) ボタンをクリックします。

ほとんどの場合は、この証明書利用者の使用をすべてのユーザーに許可します。 このシナリオでもそれを前提としているので、既定の選択を受け入れて、[次へ] (Next) ボタンをクリックします。

この時点で証明書利用者信頼の構成に他の変更を加える場合は、ここで変更します。 このシナリオでは、そうする必要がないので、[次へ] (Next) ボタンをクリックして続行します。

これで証明書利用者信頼の構成は完了ですが、どのクレームを SharePoint に送り返すかを ADFS に指示するクレーム ルールを作成する必要があります。 したがって、[クレーム ルールの編集ダイアログ ボックスを開く] (Open the Edit Claim Rules dialog) のボックスをオンのままにして、[閉じる] (Close) ボタンをクリックします。

新しいルールを作成するので、[ルールの追加] (Add Rule…) ボタンをクリックします。

この例では Active Directory から情報を取得するので、LDAP 属性をクレームとして送信します。ユーザーは ADFS で認証され、ADFS は会社の Active Directory を使用してユーザーを認証し、ユーザーの属性を調べます。 したがって、既定の値が選択された状態にして、[次へ] (Next) ボタンをクリックして続行します。

まず、クレーム ルールの名前を入力します。任意の名前を使用できます。 次に、[属性ストア] (Attribute store) ドロップダウン リストから Active Directory を選択します。 このシナリオでは、電子メール アドレスとユーザーの属するグループが SharePoint に送り返されるようにします。 電子メール アドレスをユーザーの ID として使用し、ユーザーの属するすべてのグループがロール (Role) クレームとして送り返されるようにします。 マッピングを行うには、左側のドロップダウン リストから目的の属性を選択し、その属性をどのクレームとして送出するかを右側のウィンドウのドロップダウン リストで選択します。 この例では、Active Directory の 電子メール アドレス属性が標準の電子メール アドレス (E-Mail Address) クレームとして送出されるようにします。 ユーザーの属するグループは標準のロール (Role) クレームとして送出されるようにします。 この例で、私は Token-Groups – Unqualified Names を選択しました。そうすればグループ名という単純な文字列が送出されるからです。 グループの SID を送出することもできますが、SharePoint グループにロール (Role) クレームを割り当てようとすると、SID の使用は困難になります。 ここの説明に従ってこのルールの構成を完了したら、[完了] (Finish) ボタンをクリックしてルールの設定を終了します。

[OK] ボタンをクリックして、ADFS の証明書利用者信頼を作成するプロセスを終了します。 ADFS の構成の観点から見れば、これ以上やることはありません。 ただし、ADFS から取得しなければならないものが 1 つあります。 ADFS は、証明書を使用して、ADFS が送出するトークンに署名します。 そうすることで、トークンが作成された後、改ざんされていないことをトークンの使用者に対して保証します。 ADFS を IP-STS として使用するように SharePoint を構成するときに証明書を使用するので、SharePoint を構成するにはこの証明書のコピーが必要です。 このトークン署名証明書を ADFS から取得するには、[サービス] (Service) ノードを展開し、[証明書] (Certificates) ノードをクリックします。

[トークン署名] (Token-signing) 証明書のセクションがあります。 トークン署名証明書は 1 つしか存在しないことも複数存在することもありますが、プライマリ トークン署名証明書は常に 1 つしか存在しません。 証明書をクリックし、右側のウィンドウの [証明書の表示] (View Certificate) リンクをクリックします。

この例では、SSL 用に作成した証明書を ADFS Web サイトで使用することにしました。 私はたまたまそうしましたが、必ずしもそうする必要はないし、この方法を推奨しているわけでもありません。 証明書が表示されている状態で、ダイアログ ボックスの最上部にある [詳細] (Details) タブをクリックします。

[ファイルにコピー] (Copy to File…) ボタンをクリックします。 証明書のコピーをディスクに保存するウィザードが開始されます。

[次へ] (Next) ボタンをクリックして続行します。

秘密キーは必要ないので、既定の設定を受け入れて、[次へ] (Next) ボタンをクリックします。

既定の形式で問題ないので、[次へ] (Next) ボタンをクリックして続行します。

証明書を保存する場所を選択し、[次へ] (Next) ボタンをクリックします。 証明書を保存した場所から SharePoint サーバーへ後で証明書をコピーする必要があるので、この場所を必ず覚えておいてください。

証明書をローカルでコピーするのに必要なすべての情報が保存されたので、[完了] (Finish) ボタンをクリックしてウィザードを終了し、証明書をローカル ファイルに保存します。 このファイルを SharePoint サーバーにコピーすれば、ADFS サーバーの構成は完了です。

次に、SharePoint サーバーに切り替えて、SharePoint サーバーの構成を開始します。 SharePoint の構成を開始する前に、この時点で新しい Web アプリケーションを作成することをお勧めします。 Web アプリケーションを作成する目的はクレーム認証を使用することですが、[認証の設定] (Authentication Settings) としては [統合ウィンドウ認証 – NTLM] (Integrated Windows authentication – NTLM) を選択してください。 必ずポート 443 を使用するように Web アプリケーションを構成し、[SSL (Secure Sockets Layer) を使用する] (Use Secure Sockets Layer (SSL)) のラジオ ボタンをオンにしてください。 Web アプリケーションを作成したら、必ず IIS マネージャーに切り替えて、新しい仮想サーバーのバインドを編集し、適切な SSL 証明書を割り当てられるようにしてください。 これらの手順はこの投稿の範囲を超えていますが、インターネット上のさまざまな場所に手順を詳しく解説したドキュメントがあります。 以上をまとめると、このシナリオでは、ポート 443 と SSL を使用する、私の作成した Web アプリケーションがあり、その Web アプリケーションの URL は https://seo14 です。

SharePoint 側で最初にやることは、ADFS サーバーからコピーしたトークン署名証明書の追加です。 ただし、それを実行する前に、証明書を見る必要があります。 トークン署名証明書のチェーンには、1 つ以上の親証明書が含まれていることがあります。 親証明書が含まれている場合は、そのチェーン内のすべての証明書を SharePoint の信頼されたルート機関のリストに追加する必要があります。 それを調べるには、ADFS からコピーしたトークン署名証明書を見つけてダブルクリックし、証明書のプロパティ ウィンドウを表示します。 [証明のパス] (Certification Path) タブをクリックすると、チェーンに他の証明書が含まれているかどうかがわかります。 私のシナリオでは、トークン署名証明書に親証明書が含まれています。その親証明書はルート証明機関の証明書です。

ここでやる必要があるのは、チェーン内でトークン署名証明書の上にあるすべての証明書のコピーをローカルで保存することです。 そうするには、証明書をクリックして、ダイアログボックスの [証明書の表示] (View Certificate) ボタンを有効にします。 このボタンをクリックすると、その証明書に対応する別のプロパティ ダイアログ ボックスが開きます。 次に、先ほど説明した手順に従って、証明書のコピーをディスクに保存します。 [詳細] (Details) タブをクリックし、[ファイルにコピー] (Copy to File…) ボタンをクリックして、証明書を .CER ファイルとしてローカルで保存します。 私はこの方法で証明書を C:\adfsParent.cer にコピーしました。 これで SharePoint サーバー上の証明書は 2 つになりました。

· ADFS サーバーからコピーしたトークン署名証明書である C:\adfs.cer

· トークン署名証明書の親証明書である C:\adfsParent.cer

この 2 つの証明書があるので、信頼されたルート機関のリストにそれらを追加する必要があります。 以下のスクリプトを PowerShell で使用して、それを実行します。

$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfsParent.cer")

New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfs.cer ")

New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert

これらのコマンドを PowerShell で実行すると、出力は以下のようになります。

次に、SharePoint が使用するクレーム マッピングを作成します。 この記事で既に説明したように、私は電子メール クレームとロール クレームを SharePoint で使用する予定です。 そのマッピングの作成に使用する PowerShell を以下に示します。

$map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

次に、SharePoint に使用させる領域の変数を作成します。 既に説明したように、このシナリオでは領域 urn:seo:sharepoint を使用します。 領域変数を作成する PowerShell を以下に示します。

$realm = "urn:seo:sharepoint"

これで SPTrustedIdentityTokenIssuer を作成する準備が整いました。 IP-STS に接続し、IP-STS と情報をやり取りする方法が SharePoint にわかるように、ここにすべての構成情報をまとめます。 以下に PowerShell を示し、その後で重要な部分について説明します。

$ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" -Description "SharePoint secured by SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl "https://congen1.contoso.local/adfs/ls" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

“Name” 属性は、Web アプリケーションが使用する認証プロバイダーを構成するときに Web アプリケーションに表示されます。 “realm” 属性には、SharePoint がこの信頼された ID トークン発行者に対して使用する領域を入力します。 “ImportTrustCertificate” 属性は、ADFS サーバーからコピーしたトークン署名証明書を渡す場所です。 “ClaimsMappings” 属性では、この信頼された ID トークン発行者が使用するクレームを知らせます。 “SignInUrl” は、ユーザーが IP-STS の認証を受けるためにリダイレクトされる場所の URL です。 この例では、ADFS サーバーが Windows 統合セキュリティを使用してユーザーを認証するので、ユーザーを /adfs/ls サブディレクトリにリダイレクトします。 最後に、“IdentifierClaim” 属性で、どのクレームを使用してユーザーを識別するかを SharePoint に知らせます。 この例では、電子メール アドレスでユーザーを識別するように指示します。

この最後の PowerShell コマンドを実行すると、SharePoint Web アプリケーションで使用できる SPTrustedIdentityTokenIssuer が作成されます。 ここで、ブラウザーを開き、[サーバーの全体管理] (Central Administration) に移動します。[Web アプリケーションの管理] (Manage Web Applications) リンクをクリックし、ADFS を認証に使用するリスト内の Web アプリケーションをクリックして、リボン上の [認証プロバイダー] (Authentication Providers) ボタンをクリックします。 ADFS を使用して認証するゾーンに対応するダイアログ ボックスのリンクをクリックします。 [認証の種類] (Authentication Types) セクションまで下にスクロールします。 この状態で NTLM の選択を解除すると、“SAML Provider” という新しいプロバイダーが信頼されたプロバイダーのリストに表示されます。

プロバイダーの横のボックスをオンにし、[保存] (Save) ボタンをクリックして変更を保存します。 この状態で、Web アプリケーションのサイト コレクションを作成できます。 サイト コレクションの作成方法を手順を追って説明することはこの投稿の範囲を超えていますが、作成するときに注意を要する重要なことが 1 つあります。 [サイト コレクションの管理者] (Site Collection Administrator) を追加するときは、必ず ID クレームの形式で名前を入力してください。 たとえば、このシナリオでは電子メール アドレスが ID クレームです。 したがって、私が [サイト コレクションの管理者] (Site Collection Administrator) を追加したときに使った名前は administrator@contoso.local です。それが [サイト コレクションの管理者] (Site Collection Administrator) にする人の電子メール アドレスだからです。

これで、新しいサイト コレクションを試す準備が整いました。 ブラウザーを開いて https://seo14 と入力します。 Enter キーを押します。 最初に何が起きるかと言えば、私の Web サイトに関連付けられた SPTrustedIdentityTokenIssuer の SignInUrl に私がリダイレクトされます。 SPTrustedIdentityTokenIssuer の作成に使用した PowerShell では、その URL は https://congen1.contoso.local/adfs/ls でした。 したがって、私の SharePoint サイトへの URL をブラウザーに入力すると、以下の画面が表示されます。

ブラウザー ウィンドウの URL が ADFS サーバーを指しており、ログイン ダイアログ ボックスの背景が ADFS サーバー用の背景になっていることがおわかりでしょうか。 私が Windows 資格情報、つまりドメイン\ユーザーを使ってサインインしていることにもお気づきでしょうか。 これができるのは、私が SharePoint ではなく、ADFS サーバーの認証を受けるからだということを忘れないでください。 SharePoint は、電子メール アドレスを私の ID 情報として使用するように構成されていますが、ここでは、私が ADFS で認証され、ADFS が私の電子メール アドレスとグループを抽出するために私が作成したクレーム ルールを使用し、その電子メール アドレスとグループを SharePoint に送り返すクレームに含めます。 したがって、私の認証が完了すると、私が ADFS で設定した証明書利用者で構成した情報に従って、私はリダイレクトされ、https://seo14/_trust/ にある SharePoint に戻ります。 その時点で、SharePoint は SAML トークンを介して取得したクレームを SPUser に変換し、SharePoint 側の認証処理が完了します。 これで、遂にサイトのホーム ページにたどり着きます。

ページ右上のログイン コントロールに私の ID が電子メール アドレスとして表示されていることにお気づきでしょうか。そのように表示されるのは、それが私の ID クレームだからです。

以上で、開始から完了までの手順に簡単な説明を加えました。 この手順に従えば、サイトを構成し、運用できるはずです。

これはローカライズされたブログ投稿です。原文の記事は、「Configuring SharePoint 2010 and ADFS v2 End to End」をご覧ください。