Selector de usuarios mejorada para la autenticación moderna

SE APLICA A:2013 2016 2019 Subscription Edition SharePoint en Microsoft 365

Cuando se usa la autenticación moderna ("proveedor de identidades de confianza"), como El lenguaje de marcado de aserción de seguridad (SAML) 1.1 o OpenID Connect (OIDC) 1.0, el control Selector de personas no puede buscar, resolver y validar usuarios y grupos. En su lugar, el comportamiento predeterminado es resolver cualquier valor especificado, incluso si no es una notificación válida. En versiones anteriores de SharePoint Server, la única solución era usar un proveedor de notificaciones personalizado.

En SharePoint Server Subscription Edition (SPSE), el selector de personas se ha mejorado para permitir la resolución de usuarios y grupos en función de sus perfiles en la aplicación de perfil de usuario (UPA, también conocido como UPSA). El UPA debe configurarse para sincronizar usuarios y grupos desde el almacén de pertenencia del proveedor de identidades de confianza. Esto permite que el selector de personas resuelva usuarios y grupos válidos sin necesidad de un proveedor de notificaciones personalizado.

Nota:

El uso de un proveedor de notificaciones personalizado en SharePoint Server Subscription Edition sigue siendo una solución válida para el problema del selector de personas. Si las limitaciones del proveedor de notificaciones respaldadas por UPA descritas en este artículo son demasiado limitadas para su organización, consulte Creación de un proveedor de notificaciones en SharePoint.

Importante

El motor de importación de perfiles de usuario predeterminado incluido con SharePoint Server, denominado "Importación de Active Directory" (importación de AD), solo se puede usar para importar perfiles de usuario desde dominios y bosques de Active Directory locales. No se puede configurar para importar perfiles de usuario desde Microsoft Entra ID. Si usa la autenticación OIDC respaldada por Entra ID, puede considerar la posibilidad de usar un proveedor de notificaciones personalizado para proporcionar la funcionalidad selector de personas.

A continuación se muestran los pasos de configuración para que el selector de personas respaldado por UPA funcione.

Paso 1: Agregar un proveedor de notificaciones de UPA-Backed a SPTrustedIdentityTokenIssuer

Nota:

En el caso de los emisores de tokens de identidad de confianza de SAML 1.1, puede agregar un proveedor de notificaciones respaldado por UPA al crear el emisor del token, o bien puede asignar uno más adelante.
En el caso de los emisores de tokens de identidad de confianza de OIDC 1.0, primero debe crearse el emisor de tokens y, a continuación, puede asignar el proveedor de notificaciones. Consulte Incorporación de un proveedor de notificaciones respaldado por UPA a un SPTrustedIdentityTokenIssuer existente

Cree un nuevo SPTrustedIdentityTokenIssuer y asigne al mismo tiempo un proveedor de notificaciones con copia de seguridad de UPA.

Nota:

Esto solo está disponible para emisores de tokens de identidad de confianza saml 1.1.

Cree un nuevo emisor de tokens mediante el cmdlet de PowerShell New-SPTrustedIdentityTokenIssuer y asigne un proveedor de notificaciones agregando el modificador 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]

Los tres parámetros siguientes requieren especial atención:

• ClaimsMappings
  ClaimsMappings especifica la asignación de notificaciones del token original a un token de SharePoint. Con este parámetro, SharePoint entiende cómo generar un token de SharePoint cuando se le proporciona un token específico a partir de una propiedad de aplicación de servicio de perfil de usuario.
  Acepta una lista de ClaimTypeMapping objetos creados por el cmdlet New-SPClaimTypeMapping . A continuación se muestran ejemplos de ClaimTypeMapping objetos de distintos tipos de tokens y estos objetos se pueden proporcionar al 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
  El IdentifierClaim parámetro especifica qué tipo de notificación se usará como notificación de identificador (normalmente correo electrónico o UPN). Se puede establecer en el InputClaimType del ClaimTypeMapping objeto creado a partir del cmdlet New-SPClaimTypeMapping .

-IdentifierClaim $emailClaimMap.InputClaimType

• UseUPABackedClaimProvider
  Este parámetro switch permite al selector de personas buscar y seleccionar usuarios y grupos en el servicio de aplicación de perfil de usuario. También crea un SPClaimProviderobjeto , que tiene el mismo nombre que .SPTrustedIdentityTokenIssuer

Nota:

El parámetro "UseUPABackedClaimProvider" no se puede usar para crear un SPTrustedIdentityTokenIssuer de OIDC. Solo se puede usar para crear un SPTrustedIdentityTokenIssuer de SAML.

Ejemplo:

# 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

Adición de un proveedor de notificaciones con copia de seguridad de UPA a un SPTrustedIdentityTokenIssuer existente

En el ejemplo anterior se muestra cómo asignar un proveedor de notificaciones respaldado por UPA en el momento de la creación del emisor de tokens de identidad de confianza (solo para proveedores SAML). Si tiene un emisor de token de identidad de confianza existente (SAML o OIDC) y desea agregarle un proveedor de notificaciones respaldado por UPA, use el ejemplo siguiente.

Nota:

Los siguientes ejemplos de script de PowerShell varían ligeramente entre los proveedores de autenticación SAML 1.1 y OIDC 1.0. Elija el ejemplo correcto.

Ejemplo de 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

Ejemplo de 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

Paso 2: Sincronizar perfiles con UPSA

Ahora puede empezar a sincronizar perfiles de usuario en la aplicación de servicio de perfiles de usuario (UPSA) de SharePoint desde el proveedor de identidades que se usa en la organización para que el proveedor de notificaciones recién creado pueda trabajar en el conjunto de datos correcto.

A continuación se muestran las dos maneras de sincronizar perfiles de usuario en la aplicación de servicio de perfiles de usuario de SharePoint:

• Use importación de Active Directory de SharePoint (importación de AD) con autenticación de proveedor de notificaciones de confianza como tipo de proveedor de autenticación en la configuración de conexión de sincronización. Para usar la importación de AD, vea Administrar la sincronización de perfiles de usuario en SharePoint Server.

  

  Importante

  La importación de AD solo se puede usar para importar perfiles de usuario desde dominios y bosques de Active Directory locales. No se puede configurar para importar perfiles desde el id. de entra. Si usa la autenticación OIDC respaldada por Entra ID, en su lugar puede considerar la posibilidad de usar un proveedor de notificaciones personalizado para proporcionar la funcionalidad selector de personas.

• Use Microsoft Identity Manager (MIM). Para usar MIM, consulte Microsoft Identity Manager en SharePoint Servers 2016 y 2019.

• Debe haber dos agentes dentro de la experiencia de usuario del administrador de sincronización de MIM después de configurar MIM. Un agente se usa para importar perfiles de usuario desde el IDP de origen a la base de datos de MIM. Y se usa otro agente para exportar perfiles de usuario de la base de datos MIM a la aplicación de servicio de perfiles de usuario de SharePoint.

Durante la sincronización, proporcione las siguientes propiedades a la aplicación de servicio perfil de usuario:

a. SPS-ClaimID

• Elija una propiedad de identidad única en el origen que se asignará a la propiedad SPS-ClaimID en la aplicación de servicio perfil de usuario (correo electrónico preferido o nombre principal de usuario).
• Este debe ser el valor del parámetro IdentifierClaim correspondiente cuando se creó el emisor del token de identidad de confianza mediante el cmdlet New-SPTrustedIdentityTokenIssuer .

En el caso de la sincronización de importación de AD, la administración central -> Administración de aplicaciones -> Administrar aplicaciones de servicio -> Aplicación de servicio de perfil de usuario -> Administrar la experiencia de usuario de propiedades de usuario permitirá a los administradores editar la propiedad SPS-ClaimID para indicar qué atributo del proveedor de identidades de origen se debe sincronizar con SPS-ClaimID. Debe ser la propiedad que se usa como notificación de identificador en el emisor de tokens de identidad de confianza. Por ejemplo, si la notificación de identificador es correo electrónico y las direcciones de correo electrónico de los usuarios se almacenan en el atributo "mail" de Active Directory, establezca Claim User Identifier (Identificador de usuario de notificación) como "mail" en esta experiencia de usuario.

Nota:

El nombre para mostrar de SPS-ClaimID es Identificador de usuario de notificación en la experiencia de usuario y el administrador puede personalizar los nombres para mostrar.

Si no está seguro de la notificación de identificador, puede comprobarlo ejecutando este PowerShell: $trust = Get-SPTrustedIdentityTokenIssuer$trust.IdentityClaimTypeInformation

Para la sincronización de MIM, asigne la notificación de identificador (normalmente correo electrónico o nombre principal de usuario) a SPS-ClaimID en la base de datos MIM al agente de la aplicación de servicio de perfil de usuario de SharePoint:

• En el Administrador de servicios de sincronización de MIM, seleccione el agente y abra la experiencia de usuario Configurar flujo de atributos . Puede asignar correo a SPS-ClaimID.

  

b. SPS-ClaimProviderID y SPS-ClaimProviderType

Nota:

Para la sincronización de importación de AD, solo necesita actualizar la asignación de propiedades "Claim User Identifier" (SPS-ClaimID). A diferencia de la sincronización de MIM, NO es necesario asignar "Identificador de proveedor de notificaciones" (SPS-ClaimProviderID) y "Tipo de proveedor de notificaciones" (SPS-ClaimProviderType).

Para la sincronización de MIM, establezca estas dos propiedades en configurar la experiencia de usuario de Flujo de atributos para la base de datos MIM en el agente de aplicación del servicio de perfiles de usuario de SharePoint:

• Establezca SPS-ClaimProviderType en Trusted como Tipo constante.

• Establezca SPS-ClaimProviderID en el nombre del proveedor mediante el cmdlet New-SPTrustedIdentityTokenIssuer .

  

Paso 3: Hacer que los grupos puedan realizar búsquedas

Importante

El uso del proveedor de notificaciones respaldado por UPA para resolver grupos de seguridad solo funciona si se usa el identificador de seguridad (SID) de los grupos y los grupos se importan a la aplicación de servicio de perfiles de usuario.
Si usa la autenticación OIDC respaldada por Entra ID, tenga en cuenta que los grupos solo en la nube no tienen un SID ni que AD Import se puede sincronizar con Entra ID.
Si necesita usar usuarios o grupos solo en la nube dentro de los permisos de sitio de SharePoint, un proveedor de notificaciones personalizado puede ser la única solución.

Para habilitar el control Selector de personas para que funcione con grupos de seguridad, siga estos pasos:

1. Asegúrese de que el objeto Group tiene una propiedad denominada SID de tipo groupsid en el proveedor de identidades.
   Si aún no tiene una asignación de notificaciones para "groupSID", puede crear un ClaimTypeMapping objeto mediante New-SPClaimTypeMapping y, a continuación, proporcionar este objeto al cmdlet New-SPTrustedIdentityTokenIssuer con -ClaimsMappings el parámetro .

Ejemplo:

# 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. Sincronice la propiedad SID de los grupos del proveedor de identidades con la propiedad SID de la aplicación de servicio de perfiles de usuario.

   • Para la sincronización de importación de AD, la propiedad SID se sincronizará automáticamente desde el proveedor de identidades de origen a la aplicación de servicio de perfiles de usuario de SharePoint.

   • Para la sincronización de MIM, tome la asignación de propiedades del proveedor de identidades a MIM y, a continuación, de MIM a la aplicación de servicio de perfil de usuario de SharePoint para que MIM pueda sincronizar el SID de grupo del proveedor de identidades con la aplicación de servicio de perfil de usuario de SharePoint. Los pasos son similares a cómo se asignó la propiedad SPS-ClaimID para los perfiles de usuario, solo en este caso, se actualizan las asignaciones para el tipo de objeto "group".

     Nota:

     Para la sincronización de MIM, asigne también sAMAccountName a accountName para el objeto Group de MIM a la aplicación de servicio de perfil de usuario de SharePoint.

Paso 4: Establecer las propiedades como que se pueden buscar en el UPSA

Para que el selector de personas funcione, el paso final es habilitar qué propiedades se pueden buscar en la aplicación de servicio de perfiles de usuario.

Los administradores pueden establecer qué propiedades busca el selector de personas siguiendo este script de PowerShell de ejemplo.

# 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 comprobar qué propiedades de UPSA se han habilitado para la búsqueda del selector de personas, puede usar el siguiente ejemplo de 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()
    }
}