Partager via

Amélioration des Sélecteurs de personnes pour l’authentification moderne

  • Article

S’APPLIQUE À :no-img-132013 no-img-162016 no-img-192019 oui-img-seÉdition d’abonnement no-img-sopSharePoint dans Microsoft 365

Lorsque l’authentification moderne (« fournisseur d’identité approuvé ») telle que SAML (Security Assertion Markup Language) 1.1 ou OpenID Connect (OIDC) 1.0 est utilisée, le contrôle Sélecteur de personnes ne peut pas rechercher, résoudre et valider les utilisateurs et les groupes. Au lieu de cela, le comportement par défaut consiste à résoudre toute valeur entrée, même s’il ne s’agit pas d’une revendication valide. Dans les versions précédentes de SharePoint Server, la seule solution consistait à utiliser un fournisseur de revendications personnalisées.

Dans SharePoint Server Subscription Edition (SPSE), le sélecteur de personnes a été amélioré pour permettre la résolution des utilisateurs et des groupes en fonction de leurs profils dans l’application de profil utilisateur (UPA, alias UPSA). L’UPA doit être configuré pour synchroniser les utilisateurs et les groupes à partir du magasin d’appartenances du fournisseur d’identité approuvé. Cela permet au sélecteur de personnes de résoudre les utilisateurs et les groupes valides sans nécessiter de fournisseur de revendications personnalisées.

Notes

L’utilisation d’un fournisseur de revendications personnalisées dans SharePoint Server Édition d’abonnement est toujours une solution valide au problème du sélecteur de personnes. Si les limitations du fournisseur de revendications UPA décrites dans cet article sont trop restrictives pour votre organisation, voir Créer un fournisseur de revendications dans SharePoint

Importante

Le moteur d’importation de profil utilisateur par défaut fourni avec SharePoint Server, appelé « Importation Active Directory » (Importation AD), peut uniquement être utilisé pour importer des profils utilisateur à partir de forêts et de domaines Active Directory locaux. Il ne peut pas être configuré pour importer des profils utilisateur à partir de l’ID Microsoft Entra. Si vous utilisez l’authentification OIDC avec l’ID Entra, vous pouvez envisager d’utiliser un fournisseur de revendications personnalisées pour fournir la fonctionnalité sélecteur de personnes.

Voici les étapes de configuration pour que le sélecteur de personnes soutenu par l’UPA fonctionne.

Étape 1 : Ajouter un fournisseur de revendications UPA-Backed à votre SPTrustedIdentityTokenIssuer

Notes

Pour les émetteurs de jetons d’identité approuvés SAML 1.1, vous pouvez ajouter un fournisseur de revendications upA lorsque vous créez l’émetteur de jeton, ou vous pouvez en attribuer un ultérieurement.
Pour les émetteurs de jetons d’identité approuvés OIDC 1.0, l’émetteur de jeton doit d’abord être créé, puis vous pouvez affecter le fournisseur de revendications. Consultez Ajouter un fournisseur de revendications upA à un SPTrustedIdentityTokenIssuer existant.

Créez un SPTrustedIdentityTokenIssuer et affectez un fournisseur de revendications upA sauvegardé en même temps

Notes

Cette option est disponible uniquement pour les émetteurs de jetons d’identité approuvés SAML 1.1.

Créez un émetteur de jeton à l’aide de l’applet de commande PowerShell New-SPTrustedIdentityTokenIssuer et affectez un fournisseur de revendications en ajoutant le commutateur 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]

Les trois paramètres suivants nécessitent une attention particulière :

  • ClaimsMappings
    ClaimsMappings spécifie le mappage des revendications du jeton d’origine à un jeton SharePoint. En utilisant ce paramètre, SharePoint comprend comment générer un jeton SharePoint lorsqu’un jeton spécifique est attribué à partir d’une propriété d’application de service de profil utilisateur.
    Il accepte une liste d’objets ClaimTypeMapping créés par l’applet de commande New-SPClaimTypeMapping . Voici des exemples d’objets ClaimTypeMapping de différents types de jetons et ces objets peuvent être fournis au ClaimsMappings paramètre :
$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
    Le IdentifierClaim paramètre spécifie le type de revendication qui sera utilisé comme revendication d’identificateur (généralement email ou UPN). Il peut être défini sur le InputClaimType de l’objet ClaimTypeMapping créé à partir de l’applet de commande New-SPClaimTypeMapping .
-IdentifierClaim $emailClaimMap.InputClaimType
  • UseUPABackedClaimProvider
    Ce paramètre switch permet au sélecteur de personnes de rechercher et de sélectionner des utilisateurs et des groupes à partir du service Application de profil utilisateur. Il crée également un SPClaimProvider, qui porte le même nom que .SPTrustedIdentityTokenIssuer

Notes

Le paramètre « UseUPABackedClaimProvider » ne peut pas être utilisé pour créer un OIDC SPTrustedIdentityTokenIssuer. Il peut uniquement être utilisé pour créer un SPTrustedIdentityTokenIssuer SAML.

Exemple :

# 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

Ajouter un fournisseur de revendications upA sauvegardé à un SPTrustedIdentityTokenIssuer existant

L’exemple ci-dessus montre comment attribuer un fournisseur de revendications soutenu par UPA au moment de la création de l’émetteur de jeton d’identité approuvé (pour les fournisseurs SAML uniquement). Si vous disposez d’un émetteur de jeton d’identité approuvé existant (SAML ou OIDC) et que vous souhaitez y ajouter un fournisseur de revendications upA, utilisez l’exemple suivant.

Notes

Les exemples de scripts PowerShell suivants varient légèrement entre les fournisseurs d’authentification SAML 1.1 et OIDC 1.0. Choisissez l’exemple approprié.

Exemple pour 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

Exemple pour 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

Étape 2 : Synchroniser les profils avec UPSA

Vous pouvez maintenant commencer à synchroniser les profils utilisateur dans l’application de service de profil utilisateur SharePoint (UPSA) à partir du fournisseur d’identité utilisé dans l’organisation afin que le fournisseur de revendications nouvellement créé puisse fonctionner sur le jeu de données approprié.

Voici les deux façons de synchroniser les profils utilisateur dans l’application de service de profil utilisateur SharePoint :

  • Utilisez SharePoint Active Directory Import (AD Import) avec l’authentification du fournisseur de revendications approuvé comme type de fournisseur d’authentification dans le paramètre de connexion de synchronisation. Pour utiliser l’importation AD, consultez Gérer la synchronisation des profils utilisateur dans SharePoint Server.

    Ajoutez une nouvelle connexion de synchronisation.

    Importante

    L’importation AD peut uniquement être utilisée pour importer des profils utilisateur à partir de forêts et de domaines Active Directory locaux. Il ne peut pas être configuré pour importer des profils à partir de l’ID Entra. Si vous utilisez l’authentification OIDC soutenue par l’ID Entra, vous pouvez plutôt envisager d’utiliser un fournisseur de revendications personnalisées pour fournir la fonctionnalité sélecteur de personnes.

  • Utilisez Microsoft Identity Manager (MIM). Pour utiliser MIM, consultez Microsoft Identity Manager dans SharePoint Server 2016 et 2019.

  • Il doit y avoir deux agents à l’intérieur de l’expérience utilisateur du Gestionnaire de synchronisation MIM après la configuration de MIM. Un agent est utilisé pour importer des profils utilisateur du fournisseur d’identité source vers la base de données MIM. Un autre agent est également utilisé pour exporter les profils utilisateur de la base de données MIM vers l’application de service Profil utilisateur SharePoint.

Pendant la synchronisation, fournissez les propriétés suivantes à l’application de service Profil utilisateur :

a. SPS-ClaimID

  • Choisissez la propriété d’identité unique dans la source qui sera mappées à la propriété SPS-ClaimID dans l’application de service Profil utilisateur ( adresse e-mail ou nom d’utilisateur principal par défaut).
  • Il doit s’agir de la valeur du paramètre IdentifierClaim correspondant lorsque l’émetteur du jeton d’identité approuvé a été créé à l’aide de l’applet de commande New-SPTrustedIdentityTokenIssuer .

Pour la synchronisation d’importation AD, l’expérience utilisateur Administration centrale -> Gestion des applications -> Gérer les applications de service -> Application de service profil utilisateur -> Gérer les propriétés utilisateur permet aux administrateurs de modifier la propriété SPS-ClaimID pour indiquer quel attribut du fournisseur d’identité source doit être synchronisé avec SPS-ClaimID. Il doit s’agir de la propriété utilisée comme revendication d’identificateur dans l’émetteur du jeton d’identité approuvé. Par exemple, si la revendication d’identificateur est e-mail et que les adresses e-mail des utilisateurs sont stockées dans l’attribut « mail » dans Active Directory, définissez Claim User Identifier sur « mail » dans cette expérience utilisateur.

Notes

Le nom d’affichage de SPS-ClaimID est Claim User Identifier dans l’expérience utilisateur et l’administrateur peut personnaliser les noms d’affichage.

Si vous n’êtes pas sûr de votre revendication d’identificateur, vous pouvez vérifier en exécutant cette commande PowerShell : $trust = Get-SPTrustedIdentityTokenIssuer$trust.IdentityClaimTypeInformation

Revendiquer l’identificateur d’utilisateur.

Paramètres de propriété.

Mappage de propriétés pour la synchronisation.

Pour la synchronisation MIM, mappez votre revendication d’identificateur (généralement adresse e-mail ou nom d’utilisateur principal) à SPS-ClaimID dans la base de données MIM à l’agent d’application du service profil utilisateur SharePoint :

  • Dans le Gestionnaire de service de synchronisation MIM, sélectionnez l’agent et ouvrez l’expérience utilisateur Configurer le flux d’attributs . Vous pouvez mapper le courrier à SPS-ClaimID.

    Flux d’attributs de build.

b. SPS-ClaimProviderID et SPS-ClaimProviderType

Notes

Pour la synchronisation d’importation AD, vous devez uniquement mettre à jour le mappage de propriété « Claim User Identifier » (SPS-ClaimID). Contrairement à la synchronisation MIM, vous n’avez PAS besoin de mapper « Claim Provider Identifier » (SPS-ClaimProviderID) et « Claim Provider Type » (SPS-ClaimProviderType).

Pour la synchronisation MIM, définissez ces deux propriétés dans l’expérience utilisateur Configurer le flux d’attribut pour la base de données MIM sur l’agent d’application du service Profil utilisateur SharePoint :

  • Définissez SPS-ClaimProviderType sur Approuvé comme type constant.

  • Définissez SPS-ClaimProviderID sur le nom du fournisseur à l’aide de l’applet de commande New-SPTrustedIdentityTokenIssuer .

    Configurer le flux d’attributs.

Étape 3 : Rendre les groupes pouvant faire l’objet d’une recherche

Importante

L’utilisation du fournisseur de revendications upA pour résoudre les groupes de sécurité fonctionne uniquement si l’identificateur de sécurité (SID) des groupes est utilisé et que les groupes sont importés dans l’application de service de profil utilisateur.
Si vous utilisez l’authentification OIDC avec l’ID Entra, notez que les groupes cloud uniquement n’ont pas de SID et qu’AD Import ne peut pas se synchroniser avec l’ID Entra.
Si vous devez utiliser des utilisateurs ou des groupes cloud uniquement au sein de vos autorisations de site SharePoint, un fournisseur de revendications personnalisées peut être la seule solution.

Pour permettre au contrôle Sélecteur de personnes de fonctionner avec des groupes de sécurité, procédez comme suit :

  1. Vérifiez que l’objet Group a une propriété nommée SID de type groupsid dans le fournisseur d’identité.
    Si vous n’avez pas encore de mappage de revendication pour « groupSID », vous pouvez créer un ClaimTypeMapping objet à l’aide de New-SPClaimTypeMapping , puis fournir cet objet à l’applet de commande New-SPTrustedIdentityTokenIssuer avec -ClaimsMappings le paramètre .

Exemple :

# 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

  1. Synchronisez la propriété SID des groupes du fournisseur d’identité avec la propriété SID dans l’application de service de profil utilisateur.

    • Pour la synchronisation d’importation AD, la propriété SID se synchronise automatiquement à partir du fournisseur d’identité source vers l’application de service de profil utilisateur SharePoint.

    • Pour la synchronisation MIM, prenez le mappage des propriétés du fournisseur d’identité à MIM, puis de MIM à l’application de service Profil utilisateur SharePoint afin que MIM puisse synchroniser le SID de groupe du fournisseur d’identité avec l’application de service De profil utilisateur SharePoint. Les étapes sont similaires à la façon dont la propriété SPS-ClaimID a été mappée pour les profils utilisateur. Dans ce cas seulement, les mappages pour le type d’objet « group » sont mis à jour.

      Notes

      Pour la synchronisation MIM, mappez également sAMAccountName à accountName pour l’objet Group de MIM à l’application de service De profil utilisateur SharePoint.

Étape 4 : Définir les propriétés comme pouvant faire l’objet d’une recherche dans l’UPSA

Pour que le sélecteur de personnes fonctionne, la dernière étape consiste à activer les propriétés pouvant faire l’objet d’une recherche dans l’application de service de profil utilisateur.

Les administrateurs peuvent définir les propriétés à rechercher par le sélecteur de personnes en suivant cet exemple de script 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()
    }
}

Pour vérifier quelles propriétés UPSA ont été activées pour la recherche sélecteur de personnes, vous pouvez utiliser l’exemple PowerShell suivant :

# 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()
    }
}