Configurer l’authentification basée sur les revendications à l’aide de Windows Live ID (SharePoint Server 2010)

Article
02/05/2017

S’applique à : SharePoint Foundation 2010, SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

L’authentification basée sur les revendications dans Microsoft SharePoint Server 2010 peut déléguer l’authentification pour le service d’émission de jeton de sécurité (STS) Windows Live ID. Ceci est important si vous souhaitez implémenter un scénario dans lequel vous utilisez Windows Live ID pour la gestion de mot de passe. Le service Windows Live ID est configuré en tant que fournisseur d’identité pour SharePoint Server 2010. Une relation d’approbation à sens unique par certificat est établie entre SharePoint Server 2010 et le service Windows Live ID. Lorsqu’un utilisateur fournit les informations d’identification Windows Live ID, le service Windows Live ID retourne un identificateur unique de passeport (PUID) et des informations de messagerie encapsulées dans un jeton de revendications SAML (Security Assertion Markup Language) version 1.1. La clé publique Windows Live ID, qui fait partie du XML de métadonnées Windows Live ID, crypte ce jeton de revendications.

Pour plus d’informations sur Windows Live ID, consultez les ressources suivantes :

Le cookie Windows Live ID est mis en cache sur l’ordinateur client et envoyé à SharePoint Server 2010 par le biais d’une réponse POST à une demande d’authentification réussie. SharePoint Server 2010 convertit le jeton SAML Windows Live ID en un jeton SAML SharePoint Server 2010. Le PUID pour l’utilisateur est généré en fonction de la revendication de nom d’utilisateur principal renvoyée dans le jeton SAML. Cette valeur est utilisée dans la totalité de SharePoint Server 2010 pour identifier de façon unique l’utilisateur et effectuer le contrôle d’accès. SharePoint Server 2010peut augmenter les jetons d’utilisateur avec des déclarations supplémentaires à l’aide d’un fournisseur de déclarations personnalisé, qui est configuré dans l’application Web SharePoint Server 2010. Le SharePoint Server 2010cookie est également renvoyé à l’ordinateur client et mis en cache pour les demandes suivantes. Lorsque le cookie Windows Live ID ou SharePoint Server 2010 expire, l’utilisateur est redirigé vers un serveur Windows Live ID.

Dans cet article :

Configurer le service d'émission de jeton de sécurité Windows Live ID
Configurer SharePoint pour l’authentification Windows Live ID
Convertir un environnement interne Windows Live ID en un environnement de production
Créer différents types d'applications Web SharePoint basées sur des revendications
Accorder des autorisations à tous les utilisateurs authentifiés Windows Live ID

Configurer le service d’émission de jeton de sécurité Windows Live ID

Le protocole WS-Federation est implémenté par le service Windows Live ID et fournit l’infrastructure du service d’émission de jeton de sécurité Live ID désigné en tant que fournisseur d’identité approuvé. Vous pouvez extraire un certificat public Windows Live ID d’un nœud X509Certificate XML de métadonnées et l’enregistrer dans un certificat de sécurité Internet avec une extension de fichier .cer. Si le XML de métadonnées contient plusieurs nœuds X509Certificate, vous pouvez utiliser le nœud de votre choix. Fournissez un accès en lecture au compte de pool d’applications de la batterie de serveurs SharePoint Server 2010 dans le certificat de sécurité Internet (fichier .cer).

Configurez Microsoft Services Manager (MSM) à l’aide des valeurs suivantes :

Valeur	Description
Domain Name	Nom de domaine pour lequel les demandes d’authentification destinées au service d’émission de jeton de sécurité Live ID sont générées. Utilisez un nom de domaine complet (FQDN).
Default Return URL	URL vers laquelle le service d’émission de jeton de sécurité Windows Live ID redirige un utilisateur après une authentification réussie, par exemple : https://username.global.corp.contoso.com/_trust/default.aspx.
DNS Name	Identificateur unique fourni dans une demande d’authentification au service d’émission de jeton de sécurité Windows Live ID. Cet identificateur unique active la fonctionnalité de recherche pour l’URL de retour par défaut. Le nom DNS doit correspondre à la valeur de domaine spécifiée dans la demande d’authentification Windows Live ID.
WRealm Parameter	Le paramètre WRealm doit correspondre au champ DNS dans la configuration de site de MSM. Le paramètre WRealm doit être créé à l’aide d’un des formats suivants : sub.domain.top ou Urn:domain:name .
Override Authentication Policy	Configurez la valeur Override Authentication Policy à l’aide de la valeur suivante : MBI_FED_SSL.

Configurer SharePoint pour l’authentification Windows Live ID

Utilisez les procédures de cette section pour configurer SharePoint Server 2010 pour l’authentification Windows Live ID.

Pour configurer SharePoint pour l’authentification Windows Live ID à l’aide de Windows PowerShell

Vérifiez que vous disposez de la configuration minimale requise suivante : Voir Add-SPShellAdmin.
Dans le menu Démarrer, cliquez sur Tous les programmes.
Cliquez sur Produits Microsoft SharePoint 2010.
Cliquez sur SharePoint 2010 Management Shell.
À partir de l’invite de commande Windows PowerShell (c’est-à-dire, PS C:\ >), définissez la valeur de domaine sur la valeur de nom DNS spécifiée dans Microsoft Services Manager. La valeur de domaine dans l’intégration Windows Live ID doit correspondre au nom DNS correct, comme le montre l’exemple suivant :
```
$realm = "urn:" + $env:ComputerName + ":ServerName"
```
Obtenez la valeur PUID du compte que vous utiliserez comme compte d’administrateur de batterie de serveurs en vous connectant au site Web Windows Live ID(https://accountservices.passport-int.net/?ru=https://accountservices.passport-int.net/Credentials.srf%3Fvv%3D750&mkt%3DFR-FR&lc%3D1036\&vv=750\&mkt=FR-FR\&lc=1036\&id=10), puis en recherchant le champ Unique ID sur la page Informations d’identification.
Spécifiez la valeur PUID en utilisant le format suivant : PUID@live.com.
Recherchez l’un des nœuds <X509Certificate> dans la source suivante : URL du XML de métadonnées (https://nexus.passport-int.com/federationmetadata2/2007-06/federationmetadata.xml).

Copiez le contenu de l’un des deux nœuds X509Certificate, comme le montre l’exemple suivant :

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

Collez le contenu de l’un des deux nœuds X509Certificate dans un nouveau fichier de bloc-notes et enregistrez le fichier de bloc-notes sous le nom de fichier suivant : LiveID-INT.cer.
Configurez le certificat Windows Live ID (extrait du XML de métadonnées), comme le montre l’exemple suivant :
```
$certloc = "C:\LiveIDWithSAML\LiveID-INT.cer"
```
Définissez une nouvelle autorité racine approuvée dans SharePoint Server 2010, comme illustré dans l’exemple suivant :
```
$rootcert = Get-PfxCertificate $certloc
New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null
```

Créez un objet avec un certificat Windows Live ID, comme le montre l’exemple suivant :

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

Définissez la revendication que vous allez utiliser comme identificateur unique de l’utilisateur. Mappez la revendication du nom d’utilisateur principal sur le nom de revendication réservé Identifier. La revendication de l’adresse de messagerie peut également être mappée, comme le montre l’exemple suivant :

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

Créez un fournisseur d’authentification SharePoint Server 2010 pour une nouvelle application Web, comme le montre l’exemple suivant :

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

Créez une application Web SharePoint Server 2010 à utiliser avec le fournisseur d’authentification créé à l’étape précédente, comme illustré dans l’exemple suivant :

$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

Démarrez le Gestionnaire des services Internet en tapant INETMGR à une invite de commandes.
Accédez au site Application Web des revendications dans IIS.
Dans le volet gauche, cliquez avec le bouton droit sur Application Web des revendications et sélectionnez Modifier les liaisons.
Sélectionnez https et cliquez sur Modifier.
Sous Certificat SSL, sélectionnez un certificat dans la liste. Envisagez l’utilisation d’un certificat auto-signé.
Importez le certificat public Windows Live ID dans les dossiers Ordinateur local, SharePoint Server 2010 et Personnes autorisées.

Convertir un environnement interne Windows Live ID en un environnement de production

Utilisez les procédures de cette section pour convertir un environnement interne Windows Live ID en un environnement de production.

Pour convertir un environnement interne Windows Live ID en un environnement de production

Vérifiez que le site est migré vers un environnement de production dans MSM, et que la conformité est totale. Un examen de la conformité n’est pas nécessaire si l’environnement Windows Live ID dans MSM est interne.
Assurez-vous que la stratégie d’authentification de l’environnement de production Windows Live ID est configurée avec la valeur suivante : MBI_FED_SSL.
Assurez-vous que l’environnement de production Windows Live ID utilise des URL basées sur HTTPS, car la stratégie d’authentification de l’environnement de production est configurée pour le transport SSL. Les sites de l’environnement de production envoient des demandes POST via SSL à https://login.live.com. L’exemple de code SPTrustedIdentityTokenIssuer contient une URI de fournisseur qui doit être l’URI de l’ouverture de session active. Assurez-vous que l’URI de l’ouverture de session active est de type HTTPS.
Si le fournisseur de revendications Windows Live ID est configuré pour utiliser une adresse de messagerie au lieu d’un PUID, le site de l’environnement de production doit se trouver dans le groupe de stratégies de Microsoft. N’oubliez pas que ce groupe est automatiquement approuvé pour les partenaires internes et qu’une approbation explicite est requise pour les partenaires externes.

Créer différents types d’applications Web SharePoint basées sur des revendications

Utilisez les procédures de cette section pour exécuter un script Windows PowerShell afin de créer différents types d’applications Web SharePoint Server 2010 basées sur des revendications.

Pour créer différents types d’applications Web SharePoint basées sur des revendications à l’aide de Windows PowerShell

Vérifiez que vous disposez de la configuration minimale requise suivante : Voir Add-SPShellAdmin.
Dans le menu Démarrer, cliquez sur Tous les programmes.
Cliquez sur Produits Microsoft SharePoint 2010.
Cliquez sur SharePoint 2010 Management Shell.

À partir de l’invite de commandes Windows PowerShell, exécutez le script DeployLiveIdWithSAML, comme le montre l’exemple suivant :

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

Démarrez le Gestionnaire des services Internet en tapant INETMGR à une invite de commandes.
Accédez au site Application Web des revendications dans IIS.
Dans le volet gauche, cliquez avec le bouton droit sur Application Web des revendications et sélectionnez Modifier les liaisons.
Sélectionnez https et cliquez sur Modifier.
Sous Certificat SSL, sélectionnez un certificat dans la liste. Envisagez l’utilisation d’un certificat auto-signé.
Importez le certificat public Windows Live ID dans les dossiers Ordinateur local, SharePoint Server 2010 et Personnes autorisées.
Réinitialisez les services Internet (IIS), puis accédez à l’URL du site.

Accorder des autorisations à tous les utilisateurs authentifiés Windows Live ID

Pour accorder des autorisations à tous les utilisateurs authentifiés Windows Live Id, utilisez les procédures de cette section.

Pour accorder des autorisations à tous les utilisateurs authentifiés Windows Live ID

Accédez au site SharePoint Server 2010 que vous avez créé et ouvrez une session en utilisant le compte d’administrateur.
Dans le menu Actions du site, cliquez sur Paramètres du site.
Dans la section Utilisateurs et autorisations, cliquez sur Autorisations de site.
Cliquez sur le groupe Visiteurs de « nom du site », où nom du site est le nom du site.
Cliquez sur Nouveau, puis sur Ajouter des utilisateurs.
Dans la fenêtre Accorder des autorisations, cliquez sur l’icône de navigation.
Dans la fenêtre Sélectionner des personnes et des groupes, cliquez sur Tous les utilisateurs, puis cliquez sur Tous les utilisateurs (LiveIDSTS) dans le volet droit.
Cliquez sur Ajouter.
Cliquez sur OK.
Vérifiez que Tous les utilisateurs (LiveIDSTS) fait désormais partie du groupe du visiteur. Vous devez maintenant être en mesure d’ouvrir une session sur le site SharePoint Server 2010 avec les informations d’identification de n’importe quel autre utilisateur Live ID.

À propos de l’auteur

Birendra Acharya est ingénieur senior en conception de logiciels pour MSIT chez Microsoft.

Partager via