Seletor de Pessoas aprimorado para autenticação moderna

APLICA-SE A:2013 2019 Subscription Edition SharePoint no Microsoft 365

Quando a autenticação moderna ("provedor de identidade confiável") como SAML (Linguagem de Marcação de Declaração de Segurança) 1.1 ou OIDC (OpenID Connect) 1.0 é usada, o controle Pessoas Picker não pode pesquisar, resolve e validar usuários e grupos. Em vez disso, o comportamento padrão é resolve qualquer valor inserido, mesmo que não seja uma declaração válida. Nas versões anteriores do SharePoint Server, a única solução era usar um Provedor de Declarações Personalizadas.

Em Edição de Assinatura do SharePoint Server (SPSE), o seletor de Pessoas foi aprimorado para permitir a resolução de usuários e grupos com base em seus perfis no APLICATIVO de Perfil de Usuário (UPA, também conhecido como UPSA). A UPA deve ser configurada para sincronizar usuários e grupos do repositório de associação do provedor de identidade confiável. Isso permite que o Seletor de Pessoas resolve usuários e grupos válidos sem exigir um Provedor de Declarações Personalizadas.

Observação

O uso de um provedor de declarações personalizadas no Edição de Assinatura do SharePoint Server ainda é uma solução válida para o problema Pessoas Picker. Se as limitações do provedor de declarações apoiadas por UPA discutidas neste artigo forem muito limitantes para sua organização, consulte Criar um provedor de declarações no SharePoint

Importante

O mecanismo de importação de perfil de usuário padrão incluído no SharePoint Server, chamado "Importação do Active Directory" (Importação de AD), só pode ser usado para importar perfis de usuário de Active Directory local domínios e florestas. Ele não pode ser configurado para importar perfis de usuário de Microsoft Entra ID. Se você estiver usando a autenticação OIDC apoiada pela ID do Entra, poderá considerar usar um Provedor de Declarações Personalizadas para fornecer Pessoas funcionalidade do Seletor.

A seguir estão as etapas de configuração para fazer o Pessoas Picker com suporte para UPA funcionar.

Etapa 1: Adicionar um provedor de declaração UPA-Backed ao SPTrustedIdentityTokenIssuer

Observação

Para emissores de token de identidade confiável SAML 1.1, você pode adicionar um provedor de declaração apoiado por UPA ao criar o emissor de token ou atribuir um posterior.
Para emissores de token de identidade confiável OIDC 1.0, o emissor de token deve ser criado primeiro e você pode atribuir o provedor de declaração. Consulte Adicionar um provedor de declaração com suporte UPA a um SPTrustedIdentityTokenIssuer existente

Crie um novo SPTrustedIdentityTokenIssuer e atribua um provedor de declaração apoiado por UPA ao mesmo tempo

Observação

Isso só está disponível para emissores de token de identidade confiável SAML 1.1.

Crie um novo emissor de token usando o cmdlet New-SPTrustedIdentityTokenIssuer PowerShell e atribua um provedor de declaração adicionando a opção UseUPABackedClaimProvider.

New-SPTrustedIdentityTokenIssuer
    -ClaimsMappings <SPClaimMappingPipeBind[]> 
    -Description <String> 
    -IdentifierClaim <String> 
    -Name <String>
    -Realm <String> 
    -SignInUrl <String> 
    [-AssignmentCollection <SPAssignmentCollection>]
    -ImportTrustCertificate <X509Certificate2>
    [-UseWReply]
    [-Confirm] [-RegisteredIssuerName <String>]
    [-SignOutUrl <String>] 
    [-WhatIf] [<CommonParameters>]
    [-UseUPABackedClaimProvider]

Os três parâmetros a seguir precisam de atenção especial:

• ClaimsMappings
  ClaimsMappings especifica o mapeamento de declarações do token original para um token do SharePoint. Ao usar esse parâmetro, o SharePoint entende como gerar um token do SharePoint quando dado um token específico de uma propriedade de aplicativo de serviço de perfil de usuário.
  Ele aceita uma lista de ClaimTypeMapping objetos, que são criados pelo cmdlet New-SPClaimTypeMapping . A seguir estão exemplos de ClaimTypeMapping objetos de diferentes tipos de tokens e esses objetos podem ser fornecidos ao ClaimsMappings parâmetro:

$emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" -SameAsIncoming
$roleClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming
$sidClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" -IncomingClaimTypeDisplayName "SID" -SameAsIncoming

• IdentifierClaim
  O IdentifierClaim parâmetro especifica qual tipo de declaração será usado como a declaração do identificador (normalmente email ou UPN). Ele pode ser definido como o InputClaimType do ClaimTypeMapping objeto criado a partir do cmdlet New-SPClaimTypeMapping .

-IdentifierClaim $emailClaimMap.InputClaimType

• UseUPABackedClaimProvider
  Esse parâmetro de comutador permite que o seletor de Pessoas pesquise e selecione usuários e grupos no serviço Aplicativo de Perfil de Usuário. Ele também cria um SPClaimProvider, que tem o mesmo nome que o SPTrustedIdentityTokenIssuer.

Observação

O parâmetro "UseUPABackedClaimProvider" não pode ser usado para criar um SPTrustedIdentityTokenIssuer do OIDC. Ele só pode ser usado para criar um SAML SPTrustedIdentityTokenIssuer.

Exemplo:

# Create a new trusted identity token issuer, and assign a UPA-backed claim provider at the same time
New-SPTrustedIdentityTokenIssuer -Name "UPATest" -Description "Contoso.local" -ClaimsMappings $emailClaimMap -IdentifierClaim $emailClaimMap.InputClaimType -UseUPABackedClaimProvider

Adicionar um provedor de declaração com suporte UPA a um SPTrustedIdentityTokenIssuer existente

O exemplo acima mostra como atribuir um provedor de declaração apoiado por UPA no momento da criação do emissor de token de identidade confiável (somente para provedores SAML). Se você tiver um emissor de token de identidade confiável existente (SAML ou OIDC) e quiser adicionar um provedor de declaração apoiado por UPA a ele, use o exemplo a seguir.

Observação

Os exemplos de script do PowerShell a seguir variam ligeiramente entre provedores de autenticação SAML 1.1 e OIDC 1.0. Escolha o exemplo correto.

Exemplo para SAML

# Get the existing trusted identity token issuer named "SAML"
$stsidp = Get-SPTrustedIdentityTokenIssuer "SAML"

# Create the new UPA-backed claim provider 
$claimprovider = New-SPClaimProvider -AssemblyName "Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, publicKeyToken=71e9bce111e9429c"  -Description "UPA-Backed" -DisplayName "UPA-Backed Claim Provider" -Type "Microsoft.SharePoint.Administration.Claims.SPTrustedBackedByUPAClaimProvider" -TrustedTokenIssuer $stsidp

# Set the trusted identity token issuer to use the new claim provider
Set-SPTrustedIdentityTokenIssuer $stsidp -ClaimProvider $claimprovider

Exemplo para OIDC

# Get the existing trusted identity token issuer named "OIDC"
$stsidp = Get-SPTrustedIdentityTokenIssuer "OIDC"

# Create the new UPA-backed claim provider 
$claimprovider = New-SPClaimProvider -AssemblyName "Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, publicKeyToken=71e9bce111e9429c"  -Description "UPA-Backed" -DisplayName "UPA-Backed Claim Provider" -Type "Microsoft.SharePoint.Administration.Claims.SPTrustedBackedByUPAClaimProvider" -TrustedTokenIssuer $stsidp

# Set the trusted identity token issuer to use the new claim provider
Set-SPTrustedIdentityTokenIssuer $stsidp -ClaimProvider $claimprovider -IsOpenIDConnect

Etapa 2: sincronizar perfis com UPSA

Agora você pode começar a sincronizar perfis de usuário no UPSA (Aplicativo de Serviço de Perfil de Usuário) do SharePoint do provedor de identidade que é usado na organização para que o provedor de declaração recém-criado possa trabalhar no conjunto de dados correto.

A seguir estão as duas maneiras de sincronizar perfis de usuário no Aplicativo do Serviço de Perfil de Usuário do SharePoint:

• Use o SharePoint Active Directory Import (Importação de AD) com a Autenticação do Provedor de Declarações Confiáveis como o Tipo de Provedor de Autenticação na configuração de conexão de sincronização. Para usar o AD Import, consulte Gerenciar sincronização de perfil de usuário no SharePoint Server.

  

  Importante

  A Importação de Anúncios só pode ser usada para importar perfis de usuário de Active Directory local domínios e florestas. Ele não pode ser configurado para importar perfis da ID do Entra. Se você estiver usando a autenticação OIDC apoiada pela ID do Entra, talvez considere usar um Provedor de Declarações Personalizadas para fornecer Pessoas funcionalidade do Seletor.

• Use Microsoft Identity Manager (MIM). Para usar o MIM, consulte Microsoft Identity Manager no SharePoint Servers 2016 e 2019.

• Deve haver dois agentes dentro do UX do Gerenciador de Sincronização mim após a configuração do MIM. Um agente é usado para importar perfis de usuário do IDP de origem para o banco de dados MIM. E outro agente é usado para exportar perfis de usuário do banco de dados MIM para o aplicativo de serviço perfil de usuário do SharePoint.

Durante a sincronização, forneça as seguintes propriedades ao aplicativo de serviço Perfil de Usuário:

a. SPS-ClaimID

• Escolha a propriedade de identidade exclusiva na origem que será mapeada para a propriedade SPS-ClaimID no aplicativo de serviço Perfil de Usuário (Email preferencial ou Nome da Entidade de Usuário).
• Esse deve ser o valor do parâmetro IdentifierClaim correspondente quando o emissor de token de identidade confiável foi criado usando o cmdlet New-SPTrustedIdentityTokenIssuer .

Para sincronização de importação do AD, a Administração Central –> Gerenciamento de Aplicativos –> Gerenciar aplicativos de serviço –> Aplicativo de Serviço de Perfil de Usuário –> Gerenciar Propriedades do Usuário UX permitirá que os administradores editem a propriedade SPS-ClaimID para indicar qual atributo no provedor de identidade de origem deve ser sincronizado com SPS-ClaimID. Essa deve ser a propriedade usada como a declaração do identificador no emissor de token de identidade confiável. Por exemplo, se a declaração do identificador for email e os endereços de email dos usuários forem armazenados no atributo "email" no Active Directory, defina o Identificador de Usuário de Declaração como "email" neste UX.

Observação

O nome de exibição do SPS-ClaimID é Identificador de Usuário de Declaração no UX e o administrador pode personalizar os nomes de exibição.

Se você não tiver certeza sobre sua declaração de identificador, poderá marcar executando este PowerShell:$trust = Get-SPTrustedIdentityTokenIssuer$trust.IdentityClaimTypeInformation

Para sincronização mim, mapeie sua declaração de identificador (geralmente Email ou Nome da Entidade de Usuário) para SPS-ClaimID no banco de dados MIM para o agente de aplicativo de serviço do Perfil de Usuário do SharePoint:

• No Service Manager de sincronização mim, selecione o agente e abra o UX Configurar Fluxo de Atributo. Você pode mapear o email para SPS-ClaimID.

  

b. SPS-ClaimProviderID e SPS-ClaimProviderType

Observação

Para sincronização de importação do AD, você só precisa atualizar o mapeamento de propriedade "Identificador de Usuário de Declaração" (SPS-ClaimID). Ao contrário da sincronização mim, você NÃO precisa mapear "Identificador de Provedor de Declaração" (SPS-ClaimProviderID) e "Tipo de Provedor de Declaração" (SPS-ClaimProviderType).

Para sincronização mim, defina essas duas propriedades no Configure Attribute Flow UX para o banco de dados MIM para o agente de aplicativo de serviço do Perfil de Usuário do SharePoint:

• Defina SPS-ClaimProviderType como Trusted como Tipo constante.

• Defina SPS-ClaimProviderID como o nome do provedor usando o cmdlet New-SPTrustedIdentityTokenIssuer .

  

Etapa 3: tornar os grupos pesquisáveis

Importante

Usar o provedor de declarações apoiado por UPA para resolve grupos de segurança só funcionará se o SID (Identificador de Segurança) de grupos for usado e os grupos forem importados para o Aplicativo de Serviço de Perfil de Usuário.
Se você estiver usando a autenticação OIDC com o apoio da ID do Entra, lembre-se de que os grupos somente na nuvem não têm um SID, nem a Importação do AD pode ser sincronizada com a ID do Entra.
Se você precisar usar usuários ou grupos somente na nuvem em suas permissões de site do SharePoint, um Provedor de Declarações Personalizadas pode ser a única solução.

Para habilitar o controle picker Pessoas para trabalhar com grupos de segurança, conclua as seguintes etapas:

1. Verifique se o objeto Group tem uma propriedade chamada SID do tipo groupsid no provedor de identidade.
   Se você ainda não tiver um mapeamento de declaração para "groupSID", poderá criar um ClaimTypeMapping objeto usando New-SPClaimTypeMapping e, em seguida, fornecer esse objeto para o cmdlet New-SPTrustedIdentityTokenIssuer com -ClaimsMappings parâmetro.

Exemplo:

# Add Group SID as a claim type to an existing trusted provider named "SAML"
$Trust = Get-SPTrustedIdentityTokenIssuer -Identity "SAML"
$Trust.ClaimTypes.Add("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid")
$Trust.Update()

# Add a claim mapping for Group SID
$GroupSidClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" -IncomingClaimTypeDisplayName "Group SID" -SameAsIncoming
$Trust = Get-SPTrustedIdentityTokenIssuer "SAML"
Add-SPClaimTypeMapping –TrustedIdentityTokenIssuer $Trust -Identity $GroupSidClaimMaps

2. Sincronizar a propriedade SID de grupos do provedor de identidade para a propriedade SID no Aplicativo de Serviço de Perfil de Usuário.

   • Para sincronização de importação do AD, a propriedade SID será sincronizada automaticamente do provedor de identidade de origem para o Aplicativo de Serviço de Perfil de Usuário do SharePoint.

   • Para sincronização mim, leve o mapeamento de propriedade do provedor de identidade para MIM e, em seguida, do MIM para o aplicativo de serviço perfil de usuário do SharePoint para que o MIM possa sincronizar o SID do grupo do provedor de identidade para o aplicativo de serviço perfil de usuário do SharePoint. As etapas são semelhantes à forma como a propriedade SPS-ClaimID foi mapeada para perfis de usuário, somente nesse caso, os mapeamentos para o tipo de objeto "grupo" são atualizados.

     Observação

     Para sincronização mim, também mapeie sAMAccountName para accountName para o objeto Group do MIM para o aplicativo de serviço Perfil de Usuário do SharePoint.

Etapa 4: definir propriedades como pesquisáveis no UPSA

Para fazer com que o seletor de pessoas funcione, a etapa final é habilitar quais propriedades serão pesquisáveis no Aplicativo de Serviço de Perfil de Usuário.

Os administradores podem definir quais propriedades são pesquisadas pelo seletor de Pessoas seguindo este exemplo de script do PowerShell.

# Get the UPA property list
$site = $(Get-SPWebApplication $WebApplicationName).Sites[0]
$context = Get-SPServiceContext $site
$psm = [Microsoft.Office.Server.UserProfiles.ProfileSubTypeManager]::Get($context)
$ps = $psm.GetProfileSubtype([Microsoft.Office.Server.UserProfiles.ProfileSubtypeManager]::GetDefaultProfileName([Microsoft.Office.Server.UserProfiles.ProfileType]::User))
$properties = $ps.Properties

# Set the proerties defined in $PropertyNames as searchable. 
# In this example, we set First Name, Last Name, claim ID, email address, and PreferredName as searchable for the People Picker.
$PropertyNames = 'FirstName', 'LastName', 'SPS-ClaimID', 'WorkEmail', 'PreferredName'
foreach ($p in $PropertyNames) {
    $property = $properties.GetPropertyByName($p)
    if ($property) {
        $property.CoreProperty.IsPeoplePickerSearchable = $true
        $property.CoreProperty.Commit()
        $property.Commit()
    }
}

Para marcar quais propriedades UPSA foram habilitadas para Pessoas pesquisa do Picker, você pode usar o seguinte exemplo do PowerShell:

# Get the UPA property list
$site = $(Get-SPWebApplication $WebApplicationName).Sites[0]
$context = Get-SPServiceContext $site
$psm = [Microsoft.Office.Server.UserProfiles.ProfileSubTypeManager]::Get($context)
$ps = $psm.GetProfileSubtype([Microsoft.Office.Server.UserProfiles.ProfileSubtypeManager]::GetDefaultProfileName([Microsoft.Office.Server.UserProfiles.ProfileType]::User))
$properties = $ps.Properties

# Set the proerties defined in $PropertyNames as searchable. 
# In this example, we set First Name, Last Name, claim ID, email address, and PreferredName as searchable for the People Picker.
$PropertyNames = 'FirstName', 'LastName', 'SPS-ClaimID', 'WorkEmail', 'PreferredName'
foreach ($p in $PropertyNames) {
    $property = $properties.GetPropertyByName($p)
    if ($property) {
        $property.CoreProperty.IsPeoplePickerSearchable = $true
        $property.CoreProperty.Commit()
        $property.Commit()
    }
}