Configure claims-based authentication using Windows Live ID (SharePoint Server 2010)

Article
07/22/2014

Applies to: SharePoint Server 2010, SharePoint Foundation 2010

Claims-based authentication in Microsoft SharePoint Server 2010 can delegate authentication to the Windows Live ID Security Token Service (STS). This is important if you want to implement a scenario in which you use Windows Live ID for password management. The Windows Live ID service is configured as the identity provider for SharePoint Server 2010. A one-way, certificate-based trust relationship is established between SharePoint Server 2010 and the Windows Live ID service. When a user provides Windows Live ID credentials, the Windows Live ID service returns a Passport Unique Identity (PUID) and e-mail information encapsulated in a Security Assertion Markup Language (SAML) version 1.1 claims token. The Windows Live ID public key, which is part of Windows Live ID Metadata XML, encrypts this claims token.

For more information about Windows Live ID, refer to the following resources:

The Windows Live ID cookie is cached on the client computer and sent to SharePoint Server 2010 by way of a POST response to a successful authentication request. SharePoint Server 2010 converts the Windows Live ID SAML token to a SharePoint Server 2010 SAML token. The PUID for the user is generated based on the user principal name (UPN) claim returned in the SAML token. This value is used throughout SharePoint Server 2010 to uniquely identify the user and perform access control. SharePoint Server 2010 can augment user tokens with additional claims by using a custom claims provider, which is configured in the SharePoint Server 2010 Web application. The SharePoint Server 2010 cookie is also returned to the client computer and cached for subsequent requests. When the Windows Live ID or SharePoint Server 2010 cookie expires, the user is redirected to a Windows Live ID server.

In this article:

-
Configure the Windows Live ID Security Token Service

-
Configure SharePoint for Windows Live ID authentication

-
Convert a Windows Live ID internal environment to a production environment

-
Create different types of SharePoint claims-based Web applications

-
Grant permissions to all Windows Live ID authenticated users

Configure the Windows Live ID Security Token Service

The WS-Federation protocol is implemented by the Windows Live ID service, and provides the infrastructure of the Live ID STS that is designated as a trusted identity provider. You can extract a Windows Live ID public certificate from a metadata XML X509Certificate node and save it to an Internet security certificate with a .cer file extension. If the metadata XML contains multiple X509Certificate nodes, you can use any of them. Provide read access to the SharePoint Server 2010 farm application pool account in Internet security certificate (.cer file).

Configure the Microsoft Services Manager (MSM) using the following values:

Value	Description
Domain Name	The domain name for which authentication requests to the Live ID STS will be generated. Use a Fully Qualified Domain Name (FQDN).
Default Return URL	The URL that the Windows Live ID STS will redirect a user to after successful authentication, for example: https://username.global.corp.contoso.com/_trust/default.aspx.
DNS Name	The unique identifier provided in an authentication request to the Windows Live ID STS. This unique identifier enables look-up functionality for the Default Return URL. The DNS Name must correspond to the realm value specified in Windows Live ID authentication request.
WRealm Parameter	The WRealm parameter must match the DNS field in the MSM Site configuration. The WRealm parameter must be created by using one of the following formats: sub.domain.top or Urn:domain:name.
Override Authentication Policy	Configure the Override Authentication Policy by using the following value: MBI_FED_SSL.

Configure SharePoint for Windows Live ID authentication

Use the procedures in this section to configure SharePoint Server 2010 for Windows Live ID authentication.

To configure SharePoint for Windows Live ID authentication by using Windows PowerShell

Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
On the Start menu, click All Programs.
Click Microsoft SharePoint 2010 Products.
Click SharePoint 2010 Management Shell.
From the Windows PowerShell command prompt (that is, PS C:\>), define the realm value to match the DNS Name value specified in the Microsoft Services Manager. The realm value in Windows Live ID integration should correspond to the correct DNS name, as shown in the following example:
```
$realm = "urn:" + $env:ComputerName + ":ServerName"
```
Get the PUID value of the account that you will use as the Farm Administrator account by first signing in to following Web site: Windows Live ID(https://accountservices.passport-int.net/?ru=https://accountservices.passport-int.net/Credentials.srf%3Fvv%3D750%26mkt%3DEN-US%26lc%3D1033\&vv=750\&mkt=EN-US\&lc=1033\&id=10), and then locating the Unique ID field on the Credentials page.
Specify the PUID value using the following format: PUID@live.com.
Locate one of the <X509Certificate> nodes in the following source: Metadata XML URL (https://nexus.passport-int.com/federationmetadata2/2007-06/federationmetadata.xml).

Copy the contents of either of the two X509Certificate nodes, as shown in the following example:

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==

Paste the contents of either X509Certificate node into a new Notepad file and save the Notepad file with the following file name: LiveID-INT.cer.
Configure the Windows Live ID certificate (extracted from metadata XML), as shown in the following example:
```
$certloc = "C:\LiveIDWithSAML\LiveID-INT.cer"
```

Define a new trusted root authority in SharePoint Server 2010, as shown in the following example:

$rootcert = Get-PfxCertificate $certloc
New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null

Create an object with a Windows Live ID certificate, as shown in the following example:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)

Define the claim you will use as the unique identifier of the user. Map the UPN claim to the reserved claim name Identifier. The e-mail Address claim can also be mapped, as shown in the following example:

$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"

Create a new SharePoint Server 2010 authentication provider for a new Web application, as shown in the following example:

$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"

Create a new SharePoint Server 2010 Web application to use with the authentication provider created in the previous step, as shown in the following example:

$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

Start IIS Manager by typing INETMGR at a command prompt.
Go to the Claims Web Application site in IIS.
In the left pane, right-click Claims Web Application, and select Edit Bindings.
Select https and click Edit.
Under SSL Certificate, select any listed certificate. Consider using a self-signed certificate.
Import the Windows Live ID public certificate to the Local computer, SharePoint Server 2010, and Trusted People folders.

Convert a Windows Live ID internal environment to a production environment

Use the procedures in this section to convert a Windows Live ID internal environment to a production environment.

To convert a Windows Live ID internal environment to a production environment

Make sure the site is migrated to a production environment in MSM, and that compliance is complete. A compliance review is not required if the Windows Live ID environment in MSM is internal.
Make sure that the authentication policy of the Windows Live ID production environment is configured with the following value: MBI_FED_SSL.
Make sure that the Windows Live ID production environment uses HTTPS-based URLs because the production environment authentication policy is configured for SSL transport. The production environment sites send POST requests over SSL to https://login.live.com. In the SPTrustedIdentityTokenIssuer there is a Provider URI that should be the live login URI. Make sure the live logon URI is HTTPS-based.
If the Windows Live ID claims provider is configured to use an e-mail address instead of a PUID, the production environment site should be in the Microsoft policy group. Be aware that this policy group is auto-approved for internal partners, and explicit approval is required for external partners.

Create different types of SharePoint claims-based Web applications

Use the procedures in this section to run a Windows PowerShell script to create different types of SharePoint Server 2010 claims-based Web applications.

To create different types of SharePoint claims-based Web applications by using Windows PowerShell

Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
On the Start menu, click All Programs.
Click Microsoft SharePoint 2010 Products.
Click SharePoint 2010 Management Shell.

From the Windows PowerShell command prompt, run the DeployLiveIdWithSAML script, as shown in the following example:

#.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

Start IIS Manager by typing INETMGR at a command prompt.
Go to the Claims Web Application site in IIS.
In the left pane, right-click Claims Web Application, and select Edit Bindings.
Select https and click Edit.
Under SSL Certificate, select any listed certificate. Consider using a self-signed certificate.
Import the Windows Live ID public certificate to the Local computer, SharePoint Server 2010, and Trusted People folders.
Perform IIS reset and browse the site URL.

Grant permissions to all Windows Live ID authenticated users

Use the procedures in this section to grant permissions to all Windows Live Id authenticated users.

To grant permissions to all Windows Live ID authenticated users

Browse to the SharePoint Server 2010 site that you created and log on using the administrator account.
On the Site Actions menu click Site Settings.
In the Users and Permissions section, click Site Permissions.
Click Site Name Visitors group, where Site Name is the name of the site.
Click New, and then click Add Users.
In the Grant Permissions window, click the browse icon.
In the Select People and Groups window, click All Users, and then click All Users (LiveIDSTS) in the right pane.
Click Add.
Click OK.
Verify that All Users (LiveIDSTS) is now part of the visitor’s group. You should now be able to log on to the SharePoint Server 2010 site with any other Live ID user’s credentials.

About the author

Birendra Acharya is a Senior Software Design Engineer for MSIT at Microsoft.

Share via