Konfigurieren der anspruchsbasierten Authentifizierung mithilfe von Windows Live ID (SharePoint Server 2010)

Artikel
01/22/2017

Gilt für: SharePoint Foundation 2010, SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Mit der anspruchsbasierten Authentifizierung in Microsoft SharePoint Server 2010 kann die Authentifizierung an den Windows Live ID-Sicherheitstokendienst (Security Token Service, STS) delegiert werden. Dies ist dann wichtig, wenn Sie ein Szenario implementieren möchten, bei dem Windows Live ID für die Kennwortverwaltung verwendet wird. Der Windows Live ID-Dienst ist als Identitätsanbieter für SharePoint Server 2010 konfiguriert. Es wird eine unidirektionale, zertifikatbasierte Vertrauensstellung zwischen SharePoint Server 2010 und dem Windows Live ID-Dienst hergestellt. Wenn ein Benutzer Windows Live ID-Anmeldeinformationen bereitstellt, werden eine PUID (Passport Unique Identity) sowie E-Mail-Informationen, eingekapselt in ein SAML-Anspruchstoken (Security Assertion Markup Language), Version 1.1, von Windows Live ID zurückgegeben. Dieses Anspruchstoken wird vom öffentlichen Windows Live ID-Schlüssel, der Teil der Metadaten-XML von Windows Live ID ist, verschlüsselt.

Weitere Informationen zu Windows Live ID finden Sie in den folgenden Ressourcen:

Das Windows Live ID-Cookie wird auf dem Clientcomputer zwischengespeichert und über eine POST-Antwort auf eine erfolgreiche Authentifizierungsanforderung an SharePoint Server 2010 gesendet. Das Windows Live ID-SAML-Token wird dann von SharePoint Server 2010 in ein SharePoint Server 2010-SAML-Token umgewandelt. Die PUID für den Benutzer wird auf der Grundlage des im SAML-Token zurückgegebenen UPN-Anspruchs (User Principal Name, Benutzerprinzipalname) generiert. Dieser Wert wird innerhalb von SharePoint Server 2010 zur eindeutigen Identifizierung des Benutzers und für die Zugriffssteuerung verwendet. Benutzertoken können von SharePoint Server 2010 mithilfe eines benutzerdefinierten Anspruchsanbieters, der in der SharePoint Server 2010-Webanwendung konfiguriert ist, mit zusätzlichen Ansprüchen versehen werden. Das SharePoint Server 2010-Cookie wird ebenfalls an den Clientcomputer zurückgegeben und für nachfolgende Anforderungen zwischengespeichert. Nach Ablauf des Windows Live ID- oder SharePoint Server 2010-Cookies wird der Benutzer an einen Windows Live ID-Server umgeleitet.

Inhalt dieses Artikels

Konfigurieren des Windows Live ID-Sicherheitstokendienstes
Konfigurieren von SharePoint für die Windows Live ID-Authentifizierung
Konvertieren einer Windows Live ID-basierten internen Umgebung in eine Produktionsumgebung
Erstellen unterschiedlicher Typen von anspruchsbasierten SharePoint-Webanwendungen
Erteilen von Berechtigungen für alle Windows Live ID-authentifizierten Benutzer

Konfigurieren des Windows Live ID-Sicherheitstokendienstes

Das WS-Verbund-Protokoll wird mithilfe des Windows Live ID-Dienstes implementiert und stellt die Infrastruktur des Live ID-Sicherheitstokendienstes bereit, der als vertrauenswürdiger Identitätsanbieter fungiert. Sie können ein öffentliches Windows Live ID-Zertifikat aus einem Metadaten-XML-X509Certificate-Knoten extrahieren und mit der Dateinamenerweiterung CER als Internetsicherheitszertifikat speichern. Wenn die Metadaten-XML mehrere X509Certificate-Knoten enthält, können Sie einen beliebigen Knoten verwenden. Stellen Sie den Lesezugriff auf das SharePoint Server 2010-Farmanwendungspoolkonto im Internetsicherheitszertifikat (CER-Datei) bereit.

Konfigurieren von Microsoft Services Manager (MSM) unter Verwendung der folgenden Werte:

Wert	Beschreibung
Domänenname	Der Domänenname, für den Authentifizierungsanforderungen an den Live ID-Sicherheitstokendienst generiert werden. Verwenden Sie einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN).
Standardrückgabe-URL	Die URL, an die ein Benutzer nach der erfolgreichen Authentifizierung vom Windows Live ID-Sicherheitstokendienst umgeleitet wird, wie z. B. https://username.global.corp.contoso.com/_trust/default.aspx.
DNS-Name	Der in einer Authentifizierungsanforderung bereitgestellte eindeutige Bezeichner für den Windows Live ID-Sicherheitstokendienst. Durch diesen eindeutigen Bezeichner sind Suchfunktionen für die Standardrückgabe-URL möglich. Der DNS-Name muss dem in der Windows Live ID-Authentifizierungsanforderung angegebenen Wertnamen entsprechen.
WRealm-Parameter	Der WRealm-Parameter muss mit dem DNS-Feld in der MSM-Websitekonfiguration übereinstimmen. Der WRealm-Parameter muss in einem der folgenden Formate erstellt werden: sub.domain.top oder Urn:domain:name.
Richtlinie zum Außerkraftsetzen der Authentifizierung	Konfigurieren Sie die Richtlinie zum Außerkraftsetzen der Authentifizierung unter Verwendung des folgenden Wertes: MBI_FED_SSL.

Konfigurieren von SharePoint für die Windows Live ID-Authentifizierung

Konfigurieren Sie SharePoint Server 2010 für die Windows Live ID-Authentifizierung unter Verwendung der in diesem Abschnitt beschriebenen Verfahren.

So konfigurieren Sie SharePoint für die Windows Live ID-Authentifizierung mithilfe von Windows PowerShell

Stellen Sie sicher, dass die folgenden Mindestanforderungen erfüllt sind: Weitere Informationen finden Sie unter Add-SPShellAdmin.
Klicken Sie im Startmenü auf Alle Programme.
Klicken Sie auf Microsoft SharePoint 2010-Produkte.
Klicken Sie auf SharePoint 2010-Verwaltungsshell.
Definieren Sie an der Windows PowerShell-Eingabeaufforderung (PS C:\>) den Bereichswert, mit dem der in Microsoft Services Manager angegebene Wert des DNS-Namens übereinstimmen soll. Der Bereichswert in der Windows Live ID-Integration sollte dem richtigen DNS-Namen entsprechen, wie im folgenden Beispiel veranschaulicht:
```
$realm = "urn:" + $env:ComputerName + ":ServerName"
```
Rufen Sie den PUID-Wert des Kontos ab, das Sie als Farmadministratorkonto verwenden möchten, indem Sie sich bei folgender Website anmelden: Windows Live ID(https://accountservices.passport-int.net/Credentials.srf%3Fvv%3D750%26mkt%3DDE-DE%26lc%3D1031\&vv=750\&mkt=DE-DE\&lc=1031\&id=10). Suchen Sie dann auf der Seite mit den Anmeldeinformationen nach dem Unique ID-Feld.
Geben Sie den PUID-Wert im folgenden Format an: PUID@live.com.
Suchen Sie nach einem der <X509Certificate>-Knoten in der folgenden Quelle: URL der Metadaten-XML (https://nexus.passport-int.com/federationmetadata2/2007-06/federationmetadata.xml).

Kopieren Sie den Inhalt eines der beiden X509Certificate-Knoten wie im folgenden Beispiel veranschaulicht:

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

Fügen Sie den Inhalt eines der X509Certificate-Knoten in eine neue Editor-Datei ein, und speichern Sie die Datei unter dem folgenden Dateinamen: LiveID-INT.cer.
Konfigurieren Sie das Windows Live ID-Zertifikat (aus Metadaten-XML extrahiert), wie im folgenden Beispiel veranschaulicht:
```
$certloc = "C:\LiveIDWithSAML\LiveID-INT.cer"
```
Definieren Sie eine neue vertrauenswürdige Stammautorität in SharePoint Server 2010, wie im folgenden Beispiel veranschaulicht:
```
$rootcert = Get-PfxCertificate $certloc
New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null
```
Erstellen Sie ein Objekt mit einem Windows Live ID-Zertifikat, wie im folgenden Beispiel veranschaulicht:
```
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)
```

Definieren Sie den Anspruch, den Sie als eindeutigen Bezeichner des Benutzers verwenden möchten. Ordnen Sie den UPN-Anspruch dem Bezeichner des reservierten Anspruchsnamens zu. Der E-Mail-Adress-Anspruch kann ebenfalls zugeordnet werden, wie im folgenden Beispiel veranschaulicht:

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

Erstellen Sie einen neuen SharePoint Server 2010-Authentifizierungsanbieter für eine neue Webanwendung, wie im folgenden Beispiel veranschaulicht:

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

Erstellen Sie eine neue SharePoint Server 2010-Webanwendung für den im vorhergehenden Schritt erstellten Authentifizierungsanbieter, wie im folgenden Beispiel veranschaulicht:

$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

Starten Sie den IIS-Manager, indem Sie INETMGR an einer Eingabeaufforderung eingeben.
Wechseln Sie zur Website Claims Web Application in IIS.
Klicken Sie im linken Fensterbereich mit der rechten Maustaste auf Claims Web Application, und wählen Sie Bindungen bearbeiten aus.
Wählen Sie https aus, und klicken Sie auf Bearbeiten.
Wählen Sie unter SSL-Zertifikat eines der aufgelisteten Zertifikate aus. Es kann auch ein selbstsigniertes Zertifikat verwendet werden.
Importieren Sie das öffentliche Windows Live ID-Zertifikat in die Ordner Lokaler Computer, SharePoint Server 2010 und Vertrauenswürdige Personen.

Konvertieren einer Windows Live ID-basierten internen Umgebung in eine Produktionsumgebung

Konvertieren Sie eine Windows Live ID-basierte Umgebung mithilfe der in diesem Abschnitt beschriebenen Verfahren in eine Produktionsumgebung.

So konvertieren Sie eine Windows Live ID-basierte interne Umgebung in eine Produktionsumgebung

Stellen Sie sicher, dass die Website in MSM zu einer Produktionsumgebung migriert wird und die Kompatibilität eingehalten wird. Wenn es sich um eine MSM-interne Windows Live ID-Umgebung handelt, ist keine Kompatibilitätsprüfung erforderlich.
Stellen Sie sicher, dass die Authentifizierungsrichtlinie der Windows Live ID-Produktionsumgebung unter Verwendung des folgenden Wertes konfiguriert wird: MBI_FED_SSL.
Stellen Sie sicher, dass in der Windows Live ID-Produktionsumgebung HTTPS-basierte URLs verwendet werden, da die Authentifizierungsrichtlinie der Produktionsumgebung für den SSL-Transport konfiguriert ist. Von den Produktionsumgebungswebsites werden POST-Anforderungen über SSL an https://login.live.com/ gesendet. In SPTrustedIdentityTokenIssuer ist ein Anbieter-URI enthalten, der dem Live-Anmelde-URI entsprechen sollte. Stellen Sie sicher, dass der Live-Anmelde-URI HTTPS-basiert ist.
Wenn der Windows Live ID-Anspruchsanbieter so konfiguriert ist, dass eine E-Mail-Adresse anstelle einer PUID verwendet wird, sollte die Produktionsumgebungswebsite in der Microsoft-Richtliniengruppe enthalten sein. Beachten Sie, dass diese Richtliniengruppe für interne Partner automatisch genehmigt wird, während für externe Partner eine explizite Genehmigung erforderlich ist.

Erstellen unterschiedlicher Typen von anspruchsbasierten SharePoint-Webanwendungen

Verwenden Sie die in diesem Abschnitt beschriebenen Verfahren zur Ausführung eines Windows PowerShell-Skripts, um verschiedene Typen von anspruchsbasierten SharePoint Server 2010-Webanwendungen zu erstellen.

So erstellen Sie unterschiedliche Typen von anspruchsbasierten SharePoint-Webanwendungen mithilfe von Windows PowerShell

Stellen Sie sicher, dass die folgenden Mindestanforderungen erfüllt sind: Weitere Informationen finden Sie unter Add-SPShellAdmin.
Klicken Sie im Startmenü auf Alle Programme.
Klicken Sie auf Microsoft SharePoint 2010-Produkte.
Klicken Sie auf SharePoint 2010-Verwaltungsshell.

Führen Sie an der Windows PowerShell-Eingabeaufforderung das DeployLiveIdWithSAML-Skript aus, wie im folgenden Beispiel veranschaulicht:

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

Starten Sie den IIS-Manager, indem Sie INETMGR an einer Eingabeaufforderung eingeben.
Wechseln Sie zur Website Claims Web Application in IIS.
Klicken Sie im linken Fensterbereich mit der rechten Maustaste auf Claims Web Application, und wählen Sie Bindungen bearbeiten aus.
Wählen Sie https aus, und klicken Sie auf Bearbeiten.
Wählen Sie unter SSL-Zertifikat eines der aufgelisteten Zertifikate aus. Es kann auch ein selbstsigniertes Zertifikat verwendet werden.
Importieren Sie das öffentliche Windows Live ID-Zertifikat in die Ordner Lokaler Computer, SharePoint Server 2010 und Vertrauenswürdige Personen.
Setzen Sie die Internetinformationsdienste (Internet Information Services, IIS) zurück, und navigieren Sie zur Website-URL.

Erteilen von Berechtigungen für alle Windows Live ID-authentifizierten Benutzer

Verwenden Sie die in diesem Abschnitt beschriebenen Verfahren, um Windows Live ID-authentifizierten Benutzern Berechtigungen zu erteilen.

So erteilen Sie allen Windows Live ID-authentifizierten Benutzern Berechtigungen

Navigieren Sie zur SharePoint Server 2010-Website, die Sie erstellt haben, und melden Sie sich über das Administratorkonto an.
Klicken Sie im Menü Websiteaktionen auf Websiteeinstellungen.
Klicken Sie im Abschnitt Benutzer und Berechtigungen auf Websiteberechtigungen.
Klicken Sie auf die Gruppe Besucher von Websitename, wobei Websitename den Namen der Website angibt.
Klicken Sie auf Neu und dann auf Benutzer hinzufügen.
Klicken Sie im Fenster Berechtigungen erteilen auf das Symbol zum Durchsuchen.
Klicken Sie im Fenster Personen und Gruppen auswählen auf Alle Benutzer, und klicken Sie dann im rechten Bereich auf Alle Benutzer (LiveIDSTS).
Klicken Sie auf Hinzufügen.
Klicken Sie auf OK.
Stellen Sie sicher, dass Alle Benutzer (LiveIDSTS) nun Teil der Gruppe der Besucher ist. Sie sollten nun in der Lage sein, sich über die Anmeldeinformationen eines beliebigen Live ID-Benutzers an der SharePoint Server 2010-Website anzumelden.

Informationen zum Autor

Birendra Acharya ist Senior Software Design Engineer für MSIT bei Microsoft.