Windows Live ID を使用してクレーム ベース認証を構成する (SharePoint Server 2010)
適用先: SharePoint Foundation 2010, SharePoint Server 2010
トピックの最終更新日: 2016-11-30
Microsoft SharePoint Server 2010 のクレーム ベース認証は認証を Windows Live ID Security Token Service (STS) に委任することができます。パスワード管理に Windows Live ID を使用するシナリオを実装する場合は、このことが重要になります。Windows Live ID サービスは、SharePoint Server 2010 の ID プロバイダーとして構成されます。一方向の証明書ベースの信頼関係が、SharePoint Server 2010 と Windows Live ID サービスの間に確立されます。ユーザーが Windows Live ID 資格情報を提供すると、Windows Live ID サービスは PUID (Passport Unique Identity) と、SAML (Security Assertion Markup Language) バージョン 1.1 のクレーム トークンにカプセル化された電子メール情報を返します。Windows Live ID メタデータ XML の一部である Windows Live ID 公開キーによって、このクレーム トークンが暗号化されます。
Windows Live ID の詳細については、以下のリソースを参照してください。
Introduction to Windows Live ID (英語) (https://go.microsoft.com/fwlink/?linkid=201477&clcid=0x411) (英語)
Microsoft Federation Gateway (英語) (https://go.microsoft.com/fwlink/?linkid=150843&clcid=0x411) (英語)
Windows Live ディベロッパー センター (英語) (https://go.microsoft.com/fwlink/?linkid=191075&clcid=0x411) (英語)
Windows Live ID Cookie は、クライアント コンピューター上でキャッシュされ、成功した認証要求に対する POST 応答を通じて SharePoint Server 2010 に送信されます。SharePoint Server 2010 は Windows Live ID SAML トークンを SharePoint Server 2010 SAML トークンに変換します。ユーザーの PUID が、SAML トークンで返されたユーザー プリンシパル名 (UPN) クレームに基づいて生成されます。この PUID は、ユーザーを一意に特定してアクセス制御を実行するために SharePoint Server 2010 全体で使用されます。SharePoint Server 2010 は、SharePoint Server 2010 Web アプリケーションで構成されているカスタム クレーム プロバイダーを使用して、ユーザー トークンを追加クレームで補うことができます。また SharePoint Server 2010 Cookie は、クライアント コンピューターに返され、後続の要求のためにキャッシュされます。Windows Live ID Cookie または SharePoint Server 2010 Cookie の有効期限が切れると、ユーザーは Windows Live ID サーバーにリダイレクトされます。
この記事の内容
Windows Live ID Security Token Service を構成する
Windows Live ID 認証のために SharePoint を構成する
Windows Live ID 内部環境を運用環境に変換する
さまざまな種類の SharePoint クレームベースの Windows アプリケーションを作成する
すべての Windows Live ID 認証ユーザーに権限を付与する
Windows Live ID Security Token Service を構成する
WS-Federation プロトコルが Windows Live ID サービスによって実装され、信頼できる ID プロバイダーとして指定される Live ID STS のインフラストラクチャを提供します。Windows Live ID パブリック証明書をメタデータ XML の X509Certificate
ノードから抽出し, .cer ファイル拡張子を持つインターネット セキュリティ証明書に保存します。メタデータ XML に複数の X509Certificate
ノードが含まれている場合は、そのノードのどれでも使用できます。インターネット セキュリティ証明書 (.cer ファイル) で、SharePoint Server 2010 ファーム アプリケーション プール アカウントに対する読み取りアクセスを提供します。
以下の値を使用して、Microsoft Services Manager (MSM) を構成します。
値 | 説明 |
---|---|
Domain Name |
Live ID STS に対して認証が要求するドメイン名が生成されます。完全修飾ドメイン名 (FQDN) を使用します。 |
Default Return URL |
認証の成功後に、Windows Live ID STS がユーザーをリダイレクトする URL です。例: https://username.global.corp.contoso.com/_trust/default.aspx. |
DNS Name |
Windows Live ID STS に対する認証要求で提供される一意 ID。この一意 ID によって、Default Return URL に対する参照機能が有効になります。DNS Name は Windows Live ID 認証要求で指定された領域の値に対応している必要があります。 |
WRealm Parameter |
WRealm Parameter は MSM サイト構成の DNS フィールドに一致している必要があります。WRealm Parameter は、sub.domain.top または Urn:domain:name のどちらかの形式で作成する必要があります。 |
Override Authentication Policy |
値 MBI_FED_SSL を使用して、Override Authentication Policy を構成します。 |
Windows Live ID 認証のために SharePoint を構成する
このセクションの手順を使用して、Windows Live ID 認証のために SharePoint Server 2010 を構成します。
Windows PowerShell 使用して、Windows Live ID 認証のために SharePoint を構成するには
次の最小要件を満たしていることを確認します。Add-SPShellAdmin を参照してください。
[スタート] メニューの [すべてのプログラム] をクリックします。
[Microsoft SharePoint 2010 製品] をクリックします。
[SharePoint 2010 管理シェル] をクリックします。
Windows PowerShell コマンド プロンプト (PS C:\>) から、Microsoft Services Manager で指定された DNS 名の値に一致するように領域の値を定義します。Windows Live ID 統合内の領域の値は、以下の例のように、正しい DNS 名に対応している必要があります。
$realm = "urn:" + $env:ComputerName + ":ServerName"
最初に Web サイト (Windows Live ID (https://accountservices.passport-int.net/?ru=https://accountservices.passport-int.net/Credentials.srf%3Fvv%3D750%26mkt%3DJA-JP%26lc%3D1041\&vv=750\&mkt=JA-JP\&lc=1041\&id=10)) にサインインし、次に
Unique ID
フィールドを [資格情報] ページで検索して、ファーム管理者アカウントとして使用するアカウントの PUID 値を取得します。PUID@live.com の形式で、PUID 値を指定します。
ソースであるメタデータ XML URL (https://nexus.passport-int.com/federationmetadata2/2007-06/federationmetadata.xml) の
<X509Certificate>
ノードの 1 つを検索します。以下の例のように、2 つの
X509Certificate
ノードのどちらかのコンテンツをコピーします。MIICWzCCAcSgAwIBAgIJAJEzHoaEodSoMA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNV BAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGljIEtleTAeFw0wODEwMzAyMjA5 MjNaFw0xMzEwMjkyMjA5MjNaMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25p bmcgUHVibGljIEtleTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArz97XPae GNAC4UnKl5zReyhgk3Bzf08U+CgD0R9+GZOahmpakJXFpI213gQWiHrUGaMN9nsK 4kzSfDPiquAMsV6vBYyWuPLZ0XrMzTAOV/WHSK3bCsYWWQZeH9Xn8G1Hkz+gQSC/ 92lBbq9oBCZfLv3OlkobOmT8d+ldRKGU4pUCAwEAAaOBijCBhzAdBgNVHQ4EFgQU VbJyIcGL0AjB4/Wm4DqUZux6uUkwWQYDVR0jBFIwUIAUVbJyIcGL0AjB4/Wm4DqU Zux6uUmhLaQrMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGlj IEtleYIJAJEzHoaEodSoMAsGA1UdDwQEAwIBxjANBgkqhkiG9w0BAQUFAAOBgQAO /5vGfu+Vg1TKBuxsAIMqjqKXX7aRrANNZM/5ACdwAUtMDG/n8INoXgOKr851fbF6 4yBesmFjg2TbR8y0/ITAD+d+iyEpR7IO3/is9rWAj4ggbw8yqaDWn26eh3bAdoa+ p38qtqJHkUGF5vApeHiu6zO573bKs+nXcKVM8mNbjA==
どちらかの
X509Certificate
ノードのコンテンツを新しいメモ帳ファイルに貼り付け、ファイル名を LiveID-INT.cer としてメモ帳ファイルを保存します。以下の例のように、(メタデータ XML から抽出された) Windows Live ID 資格情報を構成します。
$certloc = "C:\LiveIDWithSAML\LiveID-INT.cer"
以下の例のように、SharePoint Server 2010 で新しい信頼できるルート証明機関を定義します。
$rootcert = Get-PfxCertificate $certloc New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null
以下の例のように、Windows Live ID 証明書を持つオブジェクトを作成します。
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)
ユーザーの一意 ID として使用するクレームを定義します。UPN クレームを予約されたクレーム名 ID にマップします。以下の例のように、電子メール アドレス クレームもマップできます。
$map1 = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/claims/EmailAddress" -IncomingClaimTypeDisplayName "https://schemas.xmlsoap.org/claims/EmailAddress" -SameAsIncoming $map2 = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
以下の例のように、新しい Web アプリケーション用の新しい SharePoint Server 2010 認証プロバイダーを作成します。
$apSAML = New-SPTrustedIdentityTokenIssuer -Name "LiveID" -Description "LiveID" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2 -SignInUrl "https://login.live-int.com/login.srf" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
以下の例のように、前の手順で作成した認証プロバイダーで使用する新しい SharePoint Server 2010 Web アプリケーションを作成します。
$waurl = https://" + $env:ComputerName - You might use FQDN url of your site here. $title = "Site Title" $waexe = New-SPWebApplication -Name $title -ApplicationPool $title -ApplicationPoolAccount $owner -Url $waurl -AuthenticationProvider $scexe = New-SPSite $siteurl -Name $title -Description $title -Template 'STS#1' -OwnerAlias
コマンド プロンプトで「INETMGR」と入力して、IIS マネージャーを開始します。
IIS で、作成したクレーム Web アプリケーション サイトに移動します。
左側のウィンドウで、作成したクレーム Web アプリケーションを右クリックし、[バインドの編集] を選択します。
[https] を選択し、[編集] をクリックします。
[SSL 証明書] で、一覧から証明書を選択します。自己署名証明書の使用を検討します。
Windows Live ID パブリック証明書を、[ローカル コンピューター] フォルダー、[SharePoint Server 2010] フォルダー、[信頼されたユーザー] フォルダーにインポートします。
Windows Live ID 内部環境を運用環境に変換する
このセクションの手順を使用して、Windows Live ID 内部環境を運用環境に変換します。
Windows Live ID 内部環境を運用環境に変換するには
サイトが MSM の運用環境に移行されること、および法令が遵守されていることを確認します。MSM の Windows Live ID 環境が内部環境であれば、法令遵守の確認は必要ありません。
Windows Live ID 運用環境の認証ポリシーが、値 MBI_FED_SSL で構成されていることを確認します。
Windows Live ID 運用環境が HTTPS ベースの URL を使用していることを確認します。これは運用環境の認証ポリシーが SSL トランスポート用に構成されているためです。運用環境サイトでは、SSL を介して POST 要求を https://login.live.com に送信します。SPTrustedIdentityTokenIssuer には、有効なログイン URI であるプロバイダー URI があります。有効なログイン URI が HTTPS ベースであることを確認します。
Windows Live ID クレーム プロバイダーが PUID の代わりに電子メール アドレスを使用するように構成されている場合は、運用環境サイトはマイクロソフトのポリシー グループに存在している必要があります。このポリシー グループは内部パートナーの場合は自動承認されますが、外部パートナーの場合は明示的な承認が要求されます。
さまざまな種類の SharePoint クレーム ベースの Web アプリケションを作成する
このセクションの手順を使用して、Windows PowerShell スクリプトを実行し、さまざまな種類の SharePoint Server 2010 クレーム ベースの Web アプリケーションを作成します。
Windows PowerShell を使用して、さまざまな種類の SharePoint クレームベースの Web アプリケーションを作成するには
次の最小要件を満たしていることを確認します。Add-SPShellAdmin を参照してください。
[スタート] メニューの [すべてのプログラム] をクリックします。
[Microsoft SharePoint 2010 製品] をクリックします。
[SharePoint 2010 管理シェル] をクリックします。
以下の例のように、Windows PowerShell コマンド プロンプトから、DeployLiveIdWithSAML スクリプトを実行します。
#.SYNOPSIS # Script for creating different types of claims web applications from the Windows PowerShell command line. #.DESCRIPTION # Script will create ANON, WIN, FBA, MULTI, MIXED, SAML and combinations of these web applications. #.NOTES # Script: ClaimsWA.ps1 # Remark: The script will load/unload additional snap-ins depending on where it's being executed from. # Update: 1/15/2010 (v2.0) #.PARAMETER type # Indicates the type of claims web app to create (see examples for full list of valid supported types) #If not specified, this will default to ALL and each of the supported types of claims web apps will be created #.PARAMETER port # Indicates the port number to create the web app on (See reserved ports at https://support.microsoft.com/kb/832017) #If not specified, this will default to port 201 and will be incremented in sequence for multiple web apps #.PARAMETER owner # Indicates the domain account that will be used for App Pool (should be registered as a SharePoint Server managed account) #If not specified, this will default to logged on user and will use USERDOMAIN & USERNAME environment values #.EXAMPLE # claimswa.ps1 WIN (create WIN-claims web app at port# 201 and use logged on user for app pool account) # Here are some more examples of HOWTO use the script: # claimswa.ps1 ANON (create ANON web app at port# 201) # claimswa.ps1 ANON/FBA 701 (create ANON/FBA web app at port# 701) # claimswa.ps1 FBA (create FBA web app at port# 201 using LDAP provider; default is REDMOND instance) # claimswa.ps1 FBA/IBM (create FBA web app at port# 201 using LDAP provider pointing to the IBM instance) # claimswa.ps1 FBA/SQL 851 (create forms-based authentication web app at port# 851 using SQL provider) # claimswa.ps1 WIN/FBA/MIXED 501 (create Windows/forms-based authentication mixed-mode web apps at port# 501) # claimswa.ps1 WIN/SAML/MULTI 901 (create Windows/SAML multi-auth web apps at port# 901) # Here is the full list of all the support TYPEs (combine options delimited with slash for your config): # Basic auth types: # WIN : create Windows claims web application on the port# specified on command line # FBA : create forms-based authentication claims web apps with the specified membership provider (SQL Server/LDAP listed below) # SAML : create SAML-claims web application on the default HTTPS port# 443 # ANON : indicator switch for creating the web application to allow ANON mode # Complex auth types: # MULTI : create claims web application with multiple auth types using a single URL to access # MIXED : create claims web application with multiple auth types using multiple URLs to access # FBA membership/rolemanager providers # RED : use the REDMOND domain LDAP provider; this is the default setting if a provider is not specified # SQL : use the SQL Server provider for connecting to forms-based authentication web apps (connects to the ASPNETDB instance on ZADANG) # PPL : use the PEOPLEDC domain LDAP provider that is a private domain used for testing PEOPLE features # SUN : use the SUNOne LDAP provider in the PEOPLEDC domain which is used for profile import/sync testing # IBM : use the IBM LDAP provider in the PEOPLEDC domain which is used for profile import/sync testing # NVL : use the Novell LDAP provider in the PEOPLEDC domain which is used for profile import/sync testing # TODO (no specific ETA for these updates): # 1. Set the default IIS cert bindings for SAML web # 2. Use IIS CMDlets instead of updating XML object # 3. We should be able to define MixedMode base auth # 4. Use the domain for logged on user for LDAP string # 5. Do not attempt to write to CA/STS if running on WFE # Define the args list that we will accept & work with param ([string]$type, [int]$port, [string]$owner) function main() { # Valid options list $auths = @("WIN", "FBA", "SAML", "ANON") $extnd = @("MULTI", "MIXED") $provs = @("SQL", "RED", "PPL", "SUN", "IBM", "NVL") $optns = @("APP", "FIX") $typeOK = $true # Do we have the minimum args data before we can proceed # I'm not doing extensive validation but at least minimum foreach ($arg in $type.split("/")) { if (($auths+$extnd+$optns+$provs) -notcontains $arg) { write-host -Fore Red "`nInvalid TYPE argument was specified; execution aborted!`nTo see a list of valid TYPEs, execute with -examples option`n" $typeOK=$false; break } } if ($typeOK) { $type = @($type.toupper().split("/") | Sort | Get-Unique) switch ($type.count) { 1 { foreach ($arg in $type) { if (($auths+$extnd+$optns) -notcontains $arg) { write-host -Fore Red "`nInvalid AUTH argument was specified; execution aborted!`nTo see a list of valid AUTHs, execute with -examples option`n" $typeOK=$false; break } } if (($type -eq "MULTI") -or ($type -eq "MIXED")) { $type += @("WIN", "FBA"); write-host -Fore Yellow "MULTI/MIXED auth combo not specified; defaulting to $type" } if ($type -eq "ANON") { $type += @("WIN"); write-host -Fore Yellow "ANON auth combo not specified; defaulting to $type" } } 2 { if ($type -contains "ANON") { foreach ($arg in $type) { if ($auths -notcontains $arg) { write-host -Fore Red "`nInvalid ANON combo was specified; execution aborted!`nTo see a list of valid PROVIDERs, execute with -examples option`n" $typeOK=$false; break } } } else { $multiOK=$true foreach ($arg in $type) { if ($auth -notcontains $arg) { $multiOK=$false; break } } if ($multiOK) {$type += @("MULTI"); write-host -Fore Yellow "Multiple auth types specified; defaulting to $type"} } } } if (($type -contains "MULTI") -or ($type -contains "MIXED") -and ($type.count -lt 3)) { write-host -Fore Red "`nMULTI/MIXED option requires 2 base auth types be specified!`nTo see a list of valid TYPEs, execute with -examples option`n" $typeOK=$false } } if ($typeOK) { # We seem to have the TYPE argument, let's check the others if (-not $port) { if ($type -contains "SAML") {$port=443} else {$port=201} write-host -Fore Yellow "PORT not specified; defaulting to $port" } if (-not $owner) { $owner = $env:UserDomain + "\" + $env:UserName.tolower() write-host -Fore Yellow "OWNER not specified; defaulting to $owner" } #In case somebody attempts to execute this script in the regular PS/ISE console, #let's load the IIS/SP snap-in to ensure we have everything we need to work with Manage-SnapIns (1) # check what flavor of SERVER we're running $product = Get-SPProduct | Where-Object {$_.ProductName.contains("SharePoint Server 2010")}; if ($product.ProductName.contains("Debug")) {$flavor="DEBUG"} else {$flavor="SHIP"} write-host -Fore Green "Detected $flavor flavor of MOSS installed on this farm!" if ($type -contains "APP") { Write-WEBConfigs 0 "APP" } elseif ($type -contains "FIX") { Fix-Environment } else { Create-WebApp $type $port } # We're done with the snap-ins, so let's unload them Manage-SnapIns (0) } } function Fix-Environment { # This is just a series of steps to clean up # Not recommended to use unless you know why! Remove-SPTrustedRootAuthority NewRootAuthority Remove-SPTrustedIdentityTokenIssuer ServerName # I need to add the other clean up stuff here... } # This is the core script block that creates the different web apps function Create-WebApp ([string]$type, [int]$port) { $waurl = http://" + $env:ComputerName if ($type.contains("SAML")) { $waurl = $waurl.replace("http", "https") } $siteurl = $waurl + ":" + $port $title = "ClaimsWA-$port-" + $type.replace(" ","-") # Let's construct the WA/SC CMDlet call that we'll invoke later $waexe = "New-SPWebApplication -Name $title -ApplicationPool $title -ApplicationPoolAccount $owner -Url $waurl -AuthenticationProvider" $scexe = "New-SPSite $siteurl -Name $title -Description $title -Template 'STS#1' -OwnerAlias" write-host -Fore Cyan "`nSetting up $title on port $port now:" if ($type.contains("WIN")) { $apWIN = New-SPAuthenticationProvider -DisableKerberos:$true $cpWIN = New-SPClaimsPrincipal -Identity $owner -IdentityType 1 } if ($type.contains("FBA")) { if ($type.contains("SQL")) { $membership="SQLms"; $rolemanager="SQLrm"; $identity = "sqlms:user1" } elseif ($type.contains("PPL")) { $membership="PPLms"; $rolemanager="PPLrm"; $identity = "pplms:fbauser1" } elseif ($type.contains("SUN")) { $membership="SUNms"; $rolemanager="SUNrm"; $identity = "sunms:fbauser1" } elseif ($type.contains("IBM")) { $membership="IBMms"; $rolemanager="IBMrm"; $identity = "ibmms:fbauser1" } elseif ($type.contains("NVL")) { $membership="NVLms"; $rolemanager="NVLrm"; $identity = "nvlms:fbauser1" } else { $membership="REDms"; $rolemanager="REDrm"; $identity = ("redms:$env:UserName").tolower() } $apFBA = New-SPAuthenticationProvider -ASPNETMembershipProvider $membership -ASPNETRoleProviderName $rolemanager; $cpFBA = New-SPClaimsPrincipal -Identity $identity -IdentityType 4 } if ($type.contains("SAML")) { $realm = "urn:" + $env:ComputerName + ":ServerName" $user = "000300008448E34D@live.com" $certloc = "C:\LiveIDWithSAML\LiveID-INT.cer" $rootcert = Get-PfxCertificate $certloc New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc) $map1 = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/claims/EmailAddress" -IncomingClaimTypeDisplayName "https://schemas.xmlsoap.org/claims/EmailAddress" -SameAsIncoming $map2 = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" $apSAML = New-SPTrustedIdentityTokenIssuer -Name "LiveID" -Description "LiveID" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2 -SignInUrl "https://login.live-int.com/login.srf" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" $cpSAML = New-SPClaimsPrincipal -TrustedIdentityTokenIssuer $apSAML -Identity $user.tolower() } if ($type.contains("WIN")) { $waexe += " `$apWIN"; $scexe += " `$cpWIN.ToEncodedString()" } elseif ($type.contains("FBA")) { $waexe += " `$apFBA"; $scexe += " `$cpFBA.ToEncodedString()" } else { $waexe += " `$apSAML -SecureSocketsLayer"; $scexe += " `$cpSAML.ToEncodedString()" } if ($type.contains("MULTI")) { if ($type.contains("WIN")) { if ($type.contains("FBA")) { $waexe += ",`$apFBA"; $scexe += " -SecondaryOwnerAlias `$cpFBA.ToEncodedString()" } if ($type.contains("SAML")) { $waexe += ",`$apSAML -SecureSocketsLayer"; if (!$scexe.contains("Secondary")) { $scexe += " -SecondaryOwnerAlias `$cpSAML.ToEncodedString()" } } } else { $waexe += ",`$apSAML -SecureSocketsLayer"; $scexe += " -SecondaryOwnerAlias `$cpSAML.ToEncodedString()" } } # Check if we're creating the ANON web apps if ($type.contains("ANON")) { $waexe += " -AllowAnonymousAccess" } $waexe += " -Port $port | Out-Null"; $scexe += " | Out-Null" write-host -Fore Cyan "Deploying app..." -noNewLine Invoke-Expression $waexe # We could do this with a simple if/else but there may be other auth types too if ($type.contains("WIN")) { Create-UserPolicy $siteurl $cpWIN.ToEncodedString() } if ($type.contains("FBA")) { Create-UserPolicy $siteurl $cpFBA.ToEncodedString() } if ($type.contains("SAML")) { Create-UserPolicy $siteurl $cpSAML.ToEncodedString() } write-host -Fore Cyan "Creating site..." -noNewLine Invoke-Expression $scexe # If this is the ANON web app, then set the root site access to entire web if ($type.contains("ANON")) { $web = Get-SPWeb $siteurl; $web.AnonymousState="On"; $web.Update() } # At this time, let's also check if it's going to be a MixedMode web app if ($type.contains("MIXED")) { # If it's a Mixed-Mode web app we need to extend the base app to another auth type too $port++; write-host -Fore Cyan "Extending port $port..." -noNewLine $waurl = $waurl.replace("https", "http") $waexe = "Get-SPWebApplication $siteurl | New-SPWebApplicationExtension -Name $title-Ext -Zone `"Intranet`" -URL $waurl -Port $port -AuthenticationProvider" if ($type.contains("WIN")) { if ($type.contains("FBA")) { $waexe += " `$apFBA" } else { $waexe += " `$apSAML" } } else { $waexe += " `$apSAML" } Invoke-Expression $waexe } # If we've created a FBA web app, then it's time to update the CA/STS/FBA web.config files if ($type.contains("FBA")) { Write-WEBConfigs 0 $port.tostring() }; write-host -Fore Cyan "done!" } function Create-UserPolicy ([string]$weburl, [string]$encodeduser) { $webapp = Get-SPWebApplication $weburl $policy = $webapp.Policies.Add($encodeduser, "ClaimsWA.ps1 User") $role = $webapp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl) $policy.PolicyRoleBindings.Add($role) $webapp.Update() } function Write-WEBConfigs ([int]$begin, [string]$vroot) { # For now I'm using the XML object to load/save the config files # Eventually we should use the IIS:CMDlets from WebAdministration write-host -Fore Cyan "Writing WEBConfig..." -noNewLine #$filei = "\\back\scratch\suntoshs\backup\webconfigs.xml" $filei = "\\back\scratch\suntoshs\scripts\oobinstall\webconfigs.xml" $xmli = [xml](get-content $filei) $root = $xmli.get_DocumentElement() for ($j=$begin; $j -le 2; $j++) { if ($j -eq 0) { [void][reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint") $fileo = [Microsoft.SharePoint.Administration.SPAdministrationWebApplication]::Local.IisSettings.get_Item(0).Path.FullName + "\web.config" } elseif ($j -eq 1) { $fileo = $env:CommonProgramFiles + "\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken\web.config" if ($flavor -eq "DEBUG") { $fileo = $fileo.replace("Shared", "Shared Debug") } } else { if ($vroot -ne "APP") { $fileo = $env:HomeDrive + "\inetpub\wwwroot\wss\VirtualDirectories\$vroot\web.config" } } $xmlo = [xml](get-content $fileo) $perf = $xmlo.CreateElement("clear") if ($flavor -eq "DEBUG") { $ship = $root.config[1].tokens.token[0].value $debug = $root.config[1].tokens.token[1].value $token = $root.config[0]["system.web"].membership.providers.add[0].type $root.config[0]["system.web"].membership.providers.add[0].SetAttribute("type", $token.replace($ship,$debug)) | Out-Null $token = $root.config[0]["system.web"].rolemanager.providers.add[0].type $root.config[0]["system.web"].rolemanager.providers.add[0].SetAttribute("type", $token.replace($ship,$debug)) | Out-Null } if ($j -eq 0) { # Update the CA web config if (-not $xmlo.SelectSingleNode("/configuration/connectionStrings")) { $xmlo.configuration["system.web"].membership.ParentNode.RemoveChild($xmlo.configuration["system.web"].membership) | Out-Null $xmlo.configuration["system.web"].roleManager.ParentNode.RemoveChild($xmlo.configuration["system.web"].roleManager) | Out-Null $xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["connectionStrings"], $true)) | Out-Null $xmlo.SelectSingleNode("/configuration/system.web").AppendChild($xmlo.ImportNode($root.config[0]["system.web"].membership, $true)) | Out-Null $xmlo.SelectSingleNode("/configuration/system.web/membership/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null $xmlo.SelectSingleNode("/configuration/system.web").AppendChild($xmlo.ImportNode($root.config[0]["system.web"].rolemanager, $true)) | Out-Null $xmlo.SelectSingleNode("/configuration/system.web/roleManager/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null } } elseif ($j -eq 1) { # Update the STS web config if (-not $xmlo.SelectSingleNode("/configuration/system.web")) { $xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["connectionStrings"], $true)) | Out-Null $xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["system.web"], $true)) | Out-Null } } else { # Update the FBA web config if ($vroot -ne "APP") { if ($type.contains("PPL")) {$provider=1} elseif ($type.contains("SUN")) {$provider=2} elseif ($type.contains("IBM")) {$provider=3} elseif ($type.contains("NVL")) {$provider=4} elseif ($type.contains("SQL")) {$provider=5} else {$provider=0} $xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["connectionStrings"], $true)) | Out-Null $xmlo.SelectSingleNode("/configuration/system.web/membership/providers").PrependChild($xmlo.ImportNode($root.config[0]["system.web"].membership.providers.add[$provider], $true)) | Out-Null $xmlo.SelectSingleNode("/configuration/system.web/membership/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null $xmlo.SelectSingleNode("/configuration/system.web/roleManager/providers").PrependChild($xmlo.ImportNode($root.config[0]["system.web"].rolemanager.providers.add[$provider], $true)) | Out-Null $xmlo.SelectSingleNode("/configuration/system.web/roleManager/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null } } $xmlo.Save($fileo) } } function Manage-SnapIns ([int]$action) { #The OWSTimer process always causes an update conflict (known bug) while #creating multiple web apps; let's temporarily shut it down until we're done if ($action -eq 1) { Stop-Service "SPTimerV4" } # We need to do this only if we're running on ISE so check it if ($host.name.contains("ISE")) { if ($action -eq 1) { write-host -Fore Yellow "Detecting host and loading dependent snap-ins..." # Add-PSSnapIn WebAdministration (later!) Add-PSSnapIn Microsoft.Sharepoint.PowerShell } else { write-host -Fore Yellow "Unloading dependent snap-ins loaded earlier on..." # Remove-PSSnapIn WebAdministration (later!) Remove-PSSnapIn Microsoft.Sharepoint.PowerShell } } if ($action -eq 0) {Start-Service "SPTimerV4"; write-host -Fore Yellow "`nAll done; if there were errors please research PS database for known issues!`n"} } main
コマンド プロンプトで「INETMGR」と入力して、IIS マネージャーを開始します。
IIS で、作成したクレーム Web アプリケーション サイトに移動します。
左側のウィンドウで、作成したクレーム Web アプリケーションを右クリックし、[バインドの編集] を選択します。
[https] を選択し、[編集] をクリックします。
[SSL 証明書] で、一覧から証明書を選択します。自己署名証明書の使用を検討します。
Windows Live ID パブリック証明書を、[ローカル コンピューター] フォルダー、[SharePoint Server 2010] フォルダー、[信頼されたユーザー] フォルダーにインポートします。
IIS リセットを実行し、サイト URL を参照します。
Windows Live ID 認証ユーザーのすべてに権限を付与する
このセクションの手順を使用して、Windows Live ID 認証ユーザーのすべてに権限を付与します。
すべての Windows Live ID 認証ユーザーに権限を付与するには
作成した SharePoint Server 2010 サイトを参照し、管理者アカウントを使用してログオンします。
[サイトの操作] メニューで [サイトの設定] をクリックします。
[ユーザーと権限] セクションで、[サイトの権限] をクリックします。
[サイト名の閲覧者] グループをクリックします。サイト名にはサイトの名前が入ります。
[新規作成] をクリックし、次に [ユーザーの追加] をクリックします。
[アクセス許可の付与] ウィンドウで、参照アイコンをクリックします。
[ユーザーとグループの選択] ウィンドウの右ウィンドウで [すべてのユーザー]、[すべてのユーザー (LiveIDSTS)] を順にクリックします。
[追加] をクリックします。
[OK] をクリックします。
[すべてのユーザー (LiveIDSTS)] が、閲覧者のグループに属していることを確認します。他の Live ID のユーザー資格情報を使用して、SharePoint Server 2010 サイトにログオンできます。
執筆者について
Birendra Acharya は、MSIT の上級ソフトウェア設計エンジニアです。
See Also
Other Resources
Understanding WS-Federation (https://go.microsoft.com/fwlink/?linkid=192377&clcid=0x411) (英語)