Controllo avanzato Selezione utenti per l'autenticazione moderna

SI APPLICA A:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

Quando viene usata l'autenticazione moderna ("provider di identità attendibile"), ad esempio SAML (Security Assertion Markup Language) 1.1 o OpenID Connect (OIDC) 1.0, il controllo Selezione Persone non può cercare, risolvere e convalidare utenti e gruppi. Il comportamento predefinito consiste invece nel risolvere qualsiasi valore immesso, anche se non si tratta di un'attestazione valida. Nelle versioni precedenti di SharePoint Server, l'unica soluzione era l'uso di un provider di attestazioni personalizzato.

In SharePoint Server Subscription Edition (SPSE), il selettore Persone è stato migliorato per consentire la risoluzione di utenti e gruppi in base ai profili nell'applicazione profilo utente (UPA, o UPSA). L'UPA deve essere configurato per sincronizzare utenti e gruppi dall'archivio di appartenenza del provider di identità attendibile. In questo modo, selezione Persone consente di risolvere utenti e gruppi validi senza richiedere un provider di attestazioni personalizzato.

Nota

L'uso di un provider di attestazioni personalizzato in SharePoint Server Subscription Edition è ancora una soluzione valida al problema di selezione Persone. Se le limitazioni del provider di attestazioni supportate da UPA descritte in questo articolo sono troppo limitate per l'organizzazione, vedere Creare un provider di attestazioni in SharePoint

Importante

Il motore di importazione del profilo utente predefinito incluso in SharePoint Server, denominato "Importazione Active Directory" (IMPORTAZIONE ACTIVE DIRECTORY), può essere usato solo per importare profili utente da Active Directory locale domini e foreste. Non può essere configurato per importare profili utente da Microsoft Entra ID. Se si usa l'autenticazione OIDC supportata dall'ID Entra, è possibile usare un provider di attestazioni personalizzato per fornire la funzionalità selezione Persone.

Di seguito sono riportati i passaggi di configurazione per il funzionamento della selezione Persone supportata da UPA.

Passaggio 1: Aggiungere un provider di attestazioni UPA-Backed a SPTrustedIdentityTokenIssuer

Nota

Per gli emittenti di token di identità attendibili SAML 1.1, è possibile aggiungere un provider di attestazioni supportato da UPA quando si crea l'autorità di certificazione del token oppure è possibile assegnarne uno in un secondo momento.
Per gli emittenti di token di identità attendibili OIDC 1.0, è necessario creare prima l'autorità di certificazione del token e quindi assegnare il provider di attestazioni. Vedere Aggiungere un provider di attestazioni supportato da UPA a un SPTrustedIdentityTokenIssuer esistente

Creare un nuovo SPTrustedIdentityTokenIssuer e assegnare contemporaneamente un provider di attestazioni supportato da UPA

Nota

Questa opzione è disponibile solo per gli emittenti di token di identità attendibili SAML 1.1.

Creare un nuovo emittente di token usando il cmdlet Di PowerShell New-SPTrustedIdentityTokenIssuer e assegnare un provider di attestazioni aggiungendo l'opzione 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]

I tre parametri seguenti richiedono particolare attenzione:

• ClaimsMappings
  ClaimsMappings specifica il mapping delle attestazioni dal token originale a un token di SharePoint. Usando questo parametro, SharePoint è in grado di generare un token di SharePoint quando viene specificato un token specifico da una proprietà dell'applicazione del servizio profili utente.
  Accetta un elenco di ClaimTypeMapping oggetti creati dal cmdlet New-SPClaimTypeMapping . Di seguito sono riportati alcuni esempi di ClaimTypeMapping oggetti di diversi tipi di token e questi oggetti possono essere forniti al ClaimsMappings parametro :

$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
  Il IdentifierClaim parametro specifica il tipo di attestazione che verrà usato come attestazione identificatore (in genere posta elettronica o UPN). Può essere impostato sull'oggetto InputClaimTypeClaimTypeMapping creato dal cmdlet New-SPClaimTypeMapping .

-IdentifierClaim $emailClaimMap.InputClaimType

• UseUPABackedClaimProvider
  Questo parametro di opzione consente al selettore Persone di cercare e selezionare utenti e gruppi dal servizio applicazione profilo utente. Crea anche un oggetto SPClaimProvider, che ha lo stesso nome di SPTrustedIdentityTokenIssuer.

Nota

Il parametro "UseUPABackedClaimProvider" non può essere usato per creare un SPTrustedIdentityTokenIssuer OIDC. Può essere usato solo per creare un SPTrustedIdentityTokenIssuer SAML.

Esempio:

# 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

Aggiungere un provider di attestazioni supportato da UPA a un SPTrustedIdentityTokenIssuer esistente

L'esempio precedente illustra come assegnare un provider di attestazioni supportato da UPA al momento della creazione dell'autorità di certificazione del token di identità attendibile (solo per i provider SAML). Se si dispone di un'autorità di certificazione del token di identità attendibile (SAML o OIDC) esistente e si vuole aggiungere un provider di attestazioni supportato da UPA, usare l'esempio seguente.

Nota

Gli esempi di script di PowerShell seguenti variano leggermente tra i provider di autenticazione SAML 1.1 e OIDC 1.0. Scegliere l'esempio corretto.

Esempio per 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

Esempio per 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

Passaggio 2: Sincronizzare i profili con UPSA

È ora possibile avviare la sincronizzazione dei profili utente nell'applicazione upsa (User Profile Service Application) di SharePoint dal provider di identità usato nell'organizzazione in modo che il provider di attestazioni appena creato possa funzionare sul set di dati corretto.

Di seguito sono riportati i due modi per sincronizzare i profili utente nell'applicazione del servizio profili utente di SharePoint:

• Usare Importazione Active Directory di SharePoint (importazione AD) con autenticazione del provider di attestazioni attendibili come tipo di provider di autenticazione nell'impostazione di connessione di sincronizzazione. Per usare Importazione Active Directory, vedere Gestire la sincronizzazione dei profili utente in SharePoint Server.

  

  Importante

  L'importazione di Active Directory può essere usata solo per importare profili utente da Active Directory locale domini e foreste. Non può essere configurato per importare profili dall'ID Entra. Se si usa l'autenticazione OIDC supportata dall'ID Entra, è possibile usare un provider di attestazioni personalizzato per fornire la funzionalità selezione Persone.

• Usare Microsoft Identity Manager (MIM). Per usare MIM, vedere Microsoft Identity Manager in SharePoint Server 2016 e 2019.

• Dopo la configurazione di MIM, devono essere presenti due agenti all'interno dell'esperienza utente di Gestione sincronizzazione MIM. Un agente viene usato per importare profili utente dall'IDP di origine al database MIM. Un altro agente viene usato per esportare i profili utente dal database MIM all'applicazione del servizio profili utente di SharePoint.

Durante la sincronizzazione, fornire le proprietà seguenti all'applicazione del servizio profili utente:

a. SPS-ClaimID

• Scegliere la proprietà identity univoca nell'origine che verrà mappata alla proprietà SPS-ClaimID nell'applicazione del servizio profili utente (Email preferita o nome entità utente).
• Questo deve essere il valore per il parametro IdentifierClaim corrispondente quando è stato creato l'autorità di certificazione del token di identità attendibile usando il cmdlet New-SPTrustedIdentityTokenIssuer .

Per la sincronizzazione dell'importazione di Active Directory, l'esperienza utente Amministrazione centrale -> Gestione applicazioni -> Gestione applicazioni di servizio -> Applicazione del servizio profili utente -> Gestisci proprietà utente consentirà agli amministratori di modificare la proprietà SPS-ClaimID per indicare quale attributo nel provider di identità di origine deve essere sincronizzato con SPS-ClaimID. Questa deve essere la proprietà usata come attestazione dell'identificatore nell'autorità di certificazione del token di identità attendibile. Ad esempio, se l'attestazione identificatore è posta elettronica e gli indirizzi di posta elettronica degli utenti vengono archiviati nell'attributo "mail" in Active Directory, impostare Claim User Identifier come "mail" in questa esperienza utente.

Nota

Il nome visualizzato di SPS-ClaimID è Claim User Identifier nell'esperienza utente e l'amministratore può personalizzare i nomi visualizzati.

Se non si è certi dell'attestazione dell'identificatore, è possibile controllare eseguendo questo PowerShell: $trust = Get-SPTrustedIdentityTokenIssuer$trust.IdentityClaimTypeInformation

Per la sincronizzazione MIM, eseguire il mapping dell'attestazione dell'identificatore (in genere Email o nome entità utente) a SPS-ClaimID nel database MIM all'agente dell'applicazione del servizio profili utente di SharePoint:

• Nella Service Manager di sincronizzazione MIM selezionare l'agente e aprire l'esperienza utente Configura flusso di attributi. È possibile eseguire il mapping della posta a SPS-ClaimID.

  

b. SPS-ClaimProviderID e SPS-ClaimProviderType

Nota

Per la sincronizzazione dell'importazione di Active Directory, è sufficiente aggiornare il mapping delle proprietà "Claim User Identifier" (SPS-ClaimID). A differenza della sincronizzazione MIM, NON è necessario eseguire il mapping di "Claim Provider Identifier" (SPS-ClaimProviderID) e "Claim Provider Type" (SPS-ClaimProviderType).

Per la sincronizzazione MIM, impostare queste due proprietà nell'esperienza utente Configura flusso di attributi per il database MIM sull'agente applicazione del servizio profili utente di SharePoint:

• Impostare SPS-ClaimProviderType su Trusted come Tipo costante.

• Impostare SPS-ClaimProviderID sul nome del provider usando il cmdlet New-SPTrustedIdentityTokenIssuer .

  

Passaggio 3: Rendere i gruppi ricercabili

Importante

L'uso del provider di attestazioni supportato da UPA per risolvere i gruppi di sicurezza funziona solo se viene usato l'identificatore di sicurezza (SID) dei gruppi e i gruppi vengono importati nell'applicazione del servizio profili utente.
Se si usa l'autenticazione OIDC supportata da Entra ID, è consigliabile che i gruppi solo cloud non dispongano di un SID e che AD Import non sia sincronizzato con l'ID Entra.
Se è necessario usare utenti o gruppi solo cloud all'interno delle autorizzazioni del sito di SharePoint, un provider di attestazioni personalizzato può essere l'unica soluzione.

Per abilitare il controllo selezione Persone per l'uso con i gruppi di sicurezza, completare la procedura seguente:

1. Assicurarsi che l'oggetto Group disponga di una proprietà denominata SID di tipo groupsid nel provider di identità.
   Se non si dispone già di un mapping delle attestazioni per "groupSID", è possibile creare un ClaimTypeMapping oggetto usando New-SPClaimTypeMapping e quindi fornire questo oggetto al cmdlet New-SPTrustedIdentityTokenIssuer con -ClaimsMappings il parametro .

Esempio:

# 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. Sincronizzare la proprietà SID dei gruppi dal provider di identità alla proprietà SID nell'applicazione del servizio profili utente.

   • Per la sincronizzazione dell'importazione di Active Directory, la proprietà SID verrà sincronizzata automaticamente dal provider di identità di origine all'applicazione del servizio profili utente di SharePoint.

   • Per la sincronizzazione MIM, eseguire il mapping delle proprietà dal provider di identità a MIM e quindi da MIM all'applicazione del servizio profili utente di SharePoint in modo che MIM possa sincronizzare il SID del gruppo dal provider di identità all'applicazione del servizio profili utente di SharePoint. I passaggi sono simili al modo in cui è stato eseguito il mapping della proprietà SPS-ClaimID per i profili utente, solo in questo caso vengono aggiornati i mapping per il tipo di oggetto "gruppo".

     Nota

     Per la sincronizzazione MIM, eseguire anche il mapping di sAMAccountName a accountName per l'oggetto Group da MIM all'applicazione del servizio profili utente di SharePoint.

Passaggio 4: Impostare le proprietà come ricercabili nell'UPSA

Per consentire il funzionamento della selezione utenti, il passaggio finale consiste nell'abilitare quali proprietà saranno ricercabili nell'applicazione del servizio profili utente.

Gli amministratori possono impostare le proprietà in cui viene eseguita la ricerca da selezione Persone seguendo questo script di PowerShell di esempio.

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

Per controllare quali proprietà UPSA sono state abilitate per la ricerca di selezione Persone, è possibile usare l'esempio di PowerShell seguente:

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