Configurar a autenticação baseada em declarações usando o Windows Live ID (SharePoint Server 2010)
Aplica-se a: SharePoint Foundation 2010, SharePoint Server 2010
Tópico modificado em: 2016-11-30
A autenticação baseada em declarações no Microsoft SharePoint Server 2010 pode delegar a autenticação para o STS (serviço de token de segurança) do Windows Live ID. Isso é importante se você deseja implementar um cenário em que o Windows Live ID é usado para gerenciamento de senhas. O serviço Windows Live ID é configurado como o provedor de identidade para o SharePoint Server 2010. Uma relação de confiança unidirecional baseada em certificado é estabelecida entre o SharePoint Server 2010 e o serviço Windows Live ID. Quando um usuário fornece credenciais ao Windows Live ID, o serviço Windows Live ID retorna uma PUID (Identidade Exclusiva do Passport) e informações de email encapsuladas em um token de declarações SAML (Security Assertion Markup Language) versão 1.1. A chave pública do Windows Live ID, que faz parte do XML de Metadados do Windows Live ID, criptografa o token de declarações.
Para obter mais informações sobre o Windows Live ID, consulte os seguintes recursos:
Introdução ao Windows Live ID (https://go.microsoft.com/fwlink/?linkid=201477&clcid=0x416)
Microsoft Federation Gateway (https://go.microsoft.com/fwlink/?linkid=150843&clcid=0x416)
Windows Live Developer Center (https://go.microsoft.com/fwlink/?linkid=191075&clcid=0x416)
O cookie do Windows Live ID é armazenado em cache no computador cliente e enviado ao SharePoint Server 2010 por meio de uma resposta POST a uma solicitação de autenticação bem-sucedida. O SharePoint Server 2010 converte o token SAML do Windows Live ID em um token SAML do SharePoint Server 2010. O PUID para o usuário é gerado com base na declaração de nome UPN retornada no token SAML. Esse valor é usado em todo o SharePoint Server 2010 para identificar o usuário com exclusividade e executar o controle de acesso. O SharePoint Server 2010 pode aumentar os tokens do usuário com declarações adicionais usando um provedor de declarações personalizadas, que é configurado no aplicativo Web do SharePoint Server 2010. O cookie do SharePoint Server 2010 também é retornado para o computador cliente e armazenado em cache para solicitações subsequentes. Quando o cookie do Windows Live ID ou do SharePoint Server 2010 expira, o usuário é redirecionado para um servidor do Windows Live ID.
Neste artigo:
Configurar o Serviço de Token de Segurança do Windows Live ID
Configurar o SharePoint para a autenticação do Windows Live ID
Converter um ambiente interno do Windows Live ID em um ambiente de produção
Criar diferentes tipos de aplicativos Web baseados em declarações do SharePoint
Conceder permissões a todos os usuários autenticados do Windows Live ID
Configurar o Serviço de Token de Segurança do Windows Live ID
O protocolo Web Services Federation é implementado pelo serviço Windows Live ID e fornece a infraestrutura do STS do Live ID que é designada como um provedor de identidade confiável. Você pode extrair um certificado público do Windows Live ID de um nó de X509Certificate
de XML de metadados e salvá-lo em um certificado de segurança da Internet com uma extensão de arquivo .cer. Se o XML de metadados contiver vários nós de X509Certificate
, você poderá usar qualquer um deles. Forneça acesso de leitura à conta pool de aplicativos do farm do SharePoint Server 2010 no certificado de segurança da Internet (arquivo .cer).
Configure o MSM (Microsoft Services Manager) utilizando os seguintes valores:
Valor | Descrição |
---|---|
Nome do domínio: |
O nome de domínio para o qual as solicitações de autenticação para o STS do Live ID serão geradas. Use um FQDN (Nome de Domínio Totalmente Qualificado). |
URL de Retorno Padrão |
A URL para a qual o Windows Live ID STS redirecionará o usuário após a autenticação bem-sucedida; por exemplo: https://nome_de_usuário.global.corp.contoso.com/_trust/default.aspx. |
Nome DNS |
O identificador exclusivo fornecido em uma solicitação de autenticação para o STS do Windows Live ID. Esse identificador exclusivo habilita a funcionalidade de pesquisa para a URL de Retorno Padrão. O Nome DNS deve corresponder ao valor de realm especificado na solicitação de autenticação do Windows Live ID. |
Parâmetro WRealm |
O parâmetro WRealm deve corresponder ao campo DNS na configuração do site do MSM. O parâmetro WRealm deve ser criado em um dos seguintes formatos: sub.domínio.superior ou Urn:domínio:nome. |
Política para Substituir Autenticação |
Configure a Política para Substituir Autenticação usando o seguinte valor: MBI_FED_SSL. |
Configure o SharePoint para a autenticação do Windows Live ID
Use os procedimentos desta seção para configurar o SharePoint Server 2010 para a autenticação do Windows Live ID.
Para configurar o SharePoint para a autenticação do Windows Live ID usando o Windows PowerShell
Verifique se você atende aos requisitos mínimos: Consulte Add-SPShellAdmin.
No menu Iniciar, clique em Todos os Programas.
Clique em Produtos do Microsoft SharePoint 2010.
Clique em Shell de Gerenciamento do SharePoint 2010.
No prompt de comando do Windows PowerShell (ou seja, PS C:\>), defina o valor de realm para corresponder ao valor de Nome DNS especificado no Microsoft Services Manager. O valor de realm na integração do Windows Live ID deve corresponder ao nome DNS correto, como é mostrado no exemplo a seguir:
$realm = "urn:" + $env:ComputerName + ":ServerName"
Para obter o valor de PUID da conta que você usará como conta de Administrador do Farm, primeiro entre no seguinte site: Windows Live ID(https://accountservices.passport.net); em seguida, localizando o campo
Unique ID
na página Credenciais.Especifique o valor PUID usando o seguinte formato: PUID@live.com.
Localize um dos nós de
<X509Certificate>
na seguinte origem: URL de XML de Metadados (https://nexus.passport-int.com/federationmetadata2/2007-06/federationmetadata.xml).Copie o conteúdo de qualquer um dos dois nós de
X509Certificate
, como é mostrado no seguinte exemplo: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==
Cole o conteúdo de um dos nós de
X509Certificate
em um novo arquivo do Bloco de Notas e salve o arquivo com o seguinte nome: LiveID-INT.cer.Configure o certificado do Windows Live ID (extraído do XML de metadados), como é mostrado no seguinte exemplo:
$certloc = "C:\LiveIDWithSAML\LiveID-INT.cer"
Defina uma nova autoridade raiz confiável no SharePoint Server 2010, como é mostrado no seguinte exemplo:
$rootcert = Get-PfxCertificate $certloc New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null
Crie um objeto com um certificado do Windows Live ID, como mostra o seguinte exemplo:
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)
Defina a declaração que você usará como identificador exclusivo do usuário. Mapeie a declaração de UPN para o Identificador de nome de declaração reservado. A declaração de Endereço de email também pode ser mapeada, como mostra o seguinte exemplo:
$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"
Crie um novo provedor de autenticação do SharePoint Server 2010 para um novo aplicativo Web, como é mostrado no seguinte exemplo:
$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"
Crie um novo aplicativo Web SharePoint Server 2010 para uso com o provedor de autenticação criado na etapa anterior, como mostra o seguinte exemplo:
$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
Inicie o Gerenciador do IIS digitando INETMGR no prompt de comando.
Acesse o site Aplicativo Web de Declarações no IIS.
No painel esquerdo, clique com o botão direito do mouse em Aplicativo Web de Declarações e selecione Editar Ligações.
Selecione https e clique em Editar.
Em Certificado SSL, selecione qualquer certificado listado. Considere o uso de um certificado auto-assinado.
Importe o certificado público do Windows Live ID para o Computador local, o SharePoint Server 2010 e as pastas Pessoas Confiáveis.
Converter um ambiente interno do Windows Live ID em um ambiente de produção
Use os procedimentos desta seção para converter um ambiente interno do Windows Live ID em um ambiente de produção.
Para converter um ambiente interno do Windows Live ID em um ambiente de produção
Verifique se o site foi migrado para um ambiente de produção no MSM e se a conformidade foi concluída. Uma análise de conformidade não será necessária se o ambiente do Windows Live ID no MSM for interno.
Verifique se a política de autenticação do ambiente de produção do Windows Live ID está configurada com o seguinte valor: MBI_FED_SSL.
Verifique se o ambiente de produção do Windows Live ID usa URLs baseadas em HTTPS, pois a política de autenticação do ambiente de produção está configurada para o transporte SSL. Os sites do ambiente de produção enviam solicitações POST sobre SSL para https://login.live.com/. No SPTrustedIdentityTokenIssuer existe uma URI de provedor que deve ser a URI de logon do Live. Verifique se a URI de logon do Live é baseada em HTTPS.
Se o provedor de declarações do Windows Live ID estiver configurado para utilizar um endereço de email em vez de um PUID, o site do ambiente de produção deverá estar no grupo de políticas da Microsoft. Lembre-se de que esse grupo de políticas é auto-aprovado para parceiros internos, e a aprovação explícita é necessária para parceiros externos.
Criar diferentes tipos de aplicativos Web baseados em declarações do SharePoint
Use os procedimentos nesta seção para executar um script do Windows PowerShell para criar diferentes tipos de aplicativos Web baseados em declarações do SharePoint Server 2010.
Para criar diferentes tipos de aplicativos Web baseados em declarações do SharePoint usando o Windows PowerShell
Verifique se você atende aos requisitos mínimos: Consulte Add-SPShellAdmin.
No menu Iniciar, clique em Todos os Programas.
Clique em Produtos do Microsoft SharePoint 2010.
Clique em Shell de Gerenciamento do SharePoint 2010.
No prompt de comando do Windows PowerShell, execute o script do DeployLiveIdWithSAML, como é mostrado no seguinte exemplo:
#.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
Inicie o Gerenciador do IIS digitando INETMGR em um prompt de comando.
Acesse o site Aplicativo Web de Declarações no IIS.
No painel esquerdo, clique com o botão direito do mouse em Aplicativo Web de Declarações e selecione Editar Ligações.
Selecione https e clique em Editar.
Em Certificado SSL, selecione qualquer certificado listado. Considere o uso de um certificado auto-assinado.
Importe o certificado público do Windows Live ID para o Computador local, o SharePoint Server 2010 e as pastas Pessoas Confiáveis.
Execute a redefinição do IIS e procure a URL do site.
Conceder permissões a todos os usuários autenticados do Windows Live ID
Use os procedimentos desta seção para conceder permissões a todos os usuários autenticados do Windows Live ID.
Para conceder permissões a todos os usuários autenticados do Windows Live ID
Navegue até o site do SharePoint Server 2010 que você criou e faça logon usando a conta de administrador.
No menu Ações do Site, clique em Configurações do Site.
Na seção Usuários e Permissões, clique em Permissões de Site.
Clique no grupo Visitantes de Nome do Site, em que Nome do Site é o nome do site.
Clique em Novo e, em seguida, em Adicionar Usuários.
Na janela Conceder Permissões, clique no ícone Navegar.
Na janela Selecionar Pessoas e Grupos, clique em Todos os Usuários e em Todos os Usuários (LiveIDSTS) no painel direito.
Clique em Adicionar.
Clique em OK.
Verifique se Todos os Usuários (LiveIDSTS) agora faz parte do grupo de visitantes. Agora você deverá poder fazer logon no site do SharePoint Server 2010 com as credenciais de qualquer outro usuário do Live ID.
Sobre o autor
Birendra Acharya é um Engenheiro de Projeto de Software Sênior do MSIT da Microsoft.
See Also
Other Resources
Entendendo o Web Services Federation (https://go.microsoft.com/fwlink/?linkid=192377&clcid=0x416)