Condividi tramite

Gestire le app locali basate su Active Directory (Kerberos) usando Microsoft Entra ID Governance

  • Articolo

Importante

L'anteprima pubblica del writeback dei gruppi v2 in Microsoft Entra Connect Sync non sarà più disponibile dopo il 30 giugno 2024. Questa funzionalità verrà sospesa in tale data e non sarà più supportata in Connect Sync per effettuare il provisioning dei gruppi di sicurezza cloud in Active Directory. La funzionalità continuerà a essere utilizzabile oltre la data di interruzione; tuttavia, dopo tale data non riceverà più supporto e potrebbe smettere di funzionare in qualsiasi momento senza preavviso.

È disponibile una funzionalità simile in Microsoft Entra Cloud Sync denominata Provisioning dei gruppi in Active Directory che è possibile usare al posto del writeback dei gruppi v2 per il provisioning di gruppi di sicurezza cloud in Active Directory. Microsoft sta lavorando per migliorare questa funzionalità in Cloud Sync insieme ad altre nuove funzionalità che verranno sviluppate in Cloud Sync.

I clienti che usano questa funzionalità di anteprima in Connect Sync dovranno cambiare la configurazione da Connect Sync to Cloud Sync. È possibile scegliere di spostare tutta la sincronizzazione ibrida in Cloud Sync (se soddisfa specifiche esigenze). È anche possibile eseguire Cloud Sync in modalità affiancata e spostarvi solo il provisioning di gruppi di sicurezza in Active Directory.

I clienti che effettuano il provisioning di gruppi di Microsoft 365 in Active Directory possono continuare a usare il writeback dei gruppi v1 per questa funzionalità.

È possibile valutare lo spostamento esclusivo in Cloud Sync usando la procedura guidata di sincronizzazione utenti.

Scenario: gestire le applicazioni locali con gruppi di Active Directory di cui viene effettuato il provisioning e gestiti nel cloud. La sincronizzazione in cloud di Microsoft Entra consente di gestire completamente le assegnazioni di applicazioni in AD sfruttando al tempo stesso le funzionalità di Microsoft Entra ID Governance per controllare e correggere eventuali richieste correlate all'accesso.

Con il rilascio dell'agente di provisioning 1.1.1370.0, la sincronizzazione cloud ha ora la possibilità di effettuare il provisioning dei gruppi direttamente nell'ambiente Active Directory locale. È possibile usare le funzionalità di governance delle identità per gestire l'accesso alle applicazioni basate su Azure AD, ad esempio includendo un gruppo in un pacchetto di accesso di gestione entitlement.

Disegno concettuale del provisioning dei gruppi di sincronizzazione cloud di Microsoft Entra in Active Directory.

Guardare il video del writeback dei gruppi

Per una panoramica generale del provisioning dei gruppi di sincronizzazione cloud in Active Directory e quali operazioni è possibile eseguire, vedere il video seguente.

Prerequisiti

Per implementare questo scenario, è necessario soddisfare i prerequisiti seguenti.

  • Account Microsoft Entra con almeno un ruolo di amministratore delle identità ibride.
  • Ambiente Active Directory Domain Services locale con sistema operativo Windows Server 2016 o versioni successive.
    • Necessario per l'attributo dello schema di Active Directory: msDS-ExternalDirectoryObjectId.
  • Agente di provisioning con build 1.1.1367.0 o versioni successive.

Nota

Le autorizzazioni per l'account del servizio vengono assegnate solo durante l'installazione pulita. Se si esegue l'aggiornamento dalla versione precedente, è necessario assegnare manualmente le autorizzazioni usando il cmdlet di PowerShell:

$credential = Get-Credential 

 Set-AADCloudSyncPermissions -PermissionType UserGroupCreateDelete -TargetDomain "FQDN of domain" -TargetDomainCredential $credential

Se le autorizzazioni vengono impostate manualmente, è necessario assicurarsi che lettura, scrittura, creazione ed eliminazione di tutte le proprietà per tutti i gruppi e gli oggetti utente discendenti.

Queste autorizzazioni non vengono applicate agli oggetti AdminSDHolder per impostazione predefinita

Cmdlet di PowerShell gMSA dell'agente di provisioning di Microsoft Entra

  • L'agente di provisioning deve essere in grado di comunicare con uno o più controller di dominio sulle porte TCP/389 (LDAP) e TCP/3268 (Catalogo globale).
    • Necessario per la ricerca nel catalogo globale per filtrare riferimenti ad appartenenze non valide.
  • Microsoft Entra Connect con versione build 2.2.8.0 o successive
    • Obbligatorio per supportare l'appartenenza utente locale sincronizzata con Microsoft Entra Connect.
    • Obbligatorio per sincronizzare AD:user:objectGUID con Microsoft Entra ID:user:onPremisesObjectIdentifier.

Gruppi supportati

Per questo scenario sono supportati solo i gruppi seguenti:

  • Sono supportati solo i gruppi di sicurezza creati nel cloud
  • Gruppi di appartenenza dinamica o assegnata
  • Possono contenere solo utenti sincronizzati locali e/o altri gruppi di sicurezza creati nel cloud
  • Gli account utente locali sincronizzati e membri di questo gruppo di sicurezza creato dal cloud possono appartenere allo stesso dominio o tra domini, ma tutti devono appartenere alla stessa foresta
  • Vengono sottoposti a writeback con l'ambito dei gruppi universale di Active Directory. L'ambiente locale deve supportare l'ambito del gruppo universale
  • Non superiore a 50.000 membri
  • Ogni gruppo annidato figlio diretto viene conteggiato come un membro nel gruppo di riferimento

Scenari supportati

Le sezioni seguenti illustrano gli scenari supportati con il provisioning dei gruppi della sincronizzazione cloud.

Configurazione degli scenari supportati

Se si desidera controllare se un utente è in grado di connettersi a un'applicazione Active Directory che usa l'autenticazione di Windows, è possibile usare il proxy dell'applicazione e un gruppo di sicurezza Microsoft Entra. Se un'applicazione controlla le appartenenze ai gruppi di Active Directory di un utente, tramite Kerberos o LDAP, è possibile usare il provisioning del gruppo della sincronizzazione cloud per assicurarsi che l'utente di Active Directory disponga di tali appartenenze ai gruppi prima che acceda alle applicazioni.

Le sezioni seguenti illustrano due opzioni dello scenario supportate con il provisioning del gruppo della sincronizzazione cloud. Le opzioni dello scenario hanno lo scopo di garantire che gli utenti assegnati all'applicazione dispongano delle appartenenze ai gruppi quando eseguono l'autenticazione all'applicazione.

  • Creare un nuovo gruppo e aggiornare l'applicazione, se già esistente, per verificare la presenza del nuovo gruppo oppure
  • Creare un nuovo gruppo e aggiornare i gruppi esistenti verificati in precedenza dall'applicazione per includere il nuovo gruppo come membro

Prima di iniziare, assicurarsi di essere un amministratore di dominio nel dominio in cui è installata l'applicazione. Assicurarsi di poter accedere a un controller di dominio o di disporre di Strumenti di amministrazione remota del server per Active Directory Domain Services (AD DS) installati nel PC Windows.

Configurazione dell'opzione nuovi gruppi

In questo scenario viene aggiornata l'applicazione per verificare la presenza del SID, del nome o del nome distinto dei nuovi gruppi creati dal provisioning del gruppo di sincronizzazione cloud. Questo scenario è applicabile a:

  • Distribuzioni per le nuove applicazioni connesse ad Active Directory Domain Services per la prima volta.
  • Nuove coorti di utenti che accedono all'applicazione.
  • Modernizzazione delle applicazioni, per ridurre la dipendenza dai gruppi di Active Directory Domain Services esistenti. È necessario aggiornare le applicazioni che attualmente controllano l'appartenenza al gruppo Domain Admins, anche per verificare la presenza di un gruppo di Active Directory appena creato.

Eseguire la procedura seguente per impostare le applicazioni all'utilizzo dei nuovi gruppi.

Creare un'applicazione e un gruppo

  1. Usando l'interfaccia di amministrazione di Microsoft Entra, creare un'applicazione in Microsoft Entra ID che rappresenta l'applicazione basata su Azure AD e configurarla per richiedere l'assegnazione di utenti.
  2. Se si usa il proxy dell'applicazione per consentire agli utenti di connettersi all'applicazione, configurare il proxy dell'applicazione.
  3. Creare un nuovo gruppo di sicurezza in Microsoft Entra ID.
  4. Usare Provisioning di gruppi in AD per eseguire il provisioning di questo gruppo in AD.
  5. Avviare Utenti e computer di Active Directory e attendere la creazione del nuovo gruppo Active Directory nel dominio Active Directory. Quando è presente, registrare il nome distinto, il dominio, il nome dell'account e il SID del nuovo gruppo di Active Directory.

Configurare l'applicazione per l'uso del nuovo gruppo

  1. Se l'applicazione usa AD tramite LDAP, configurare l'applicazione con il nome distinto del nuovo gruppo di Active Directory. Se l'applicazione usa AD tramite Kerberos, configurare l'applicazione con il SID o il nome di dominio e account del nuovo gruppo di Active Directory.
  2. Creare un pacchetto di accesso. Aggiungere l'applicazione da #1 e il gruppo di sicurezza da #3 come risorse nel pacchetto di accesso. Configurare un criterio di assegnazione diretta nel pacchetto di accesso.
  3. In Gestione entitlement assegnare al pacchetto di accesso gli utenti sincronizzati che devono accedere all'app basata su AD.
  4. Attendere che il nuovo gruppo AD venga aggiornato con i nuovi membri. Usando Utenti e computer di Active Directory, verificare che gli utenti corretti siano presenti come membri del gruppo.
  5. Nel monitoraggio del dominio AD, concedere solo all'account gMSA che esegue l'agente di provisioning l'autorizzazione a modificare l'appartenenza al nuovo gruppo AD.

È ora possibile gestire l'accesso all'applicazione AD tramite questo nuovo pacchetto di accesso.

Configurazione dell'opzione gruppi esistenti

In questo scenario viene aggiunto un nuovo gruppo di sicurezza di Active Directory come membro del gruppo annidato di un gruppo esistente. Questo scenario è applicabile alle distribuzioni per le applicazioni che hanno una dipendenza hardcoded da un determinato nome dell'account del gruppo, SID o nome distinto.

L'annidamento di tale gruppo nel gruppo AD esistente delle applicazioni consente:

  • Gli utenti di Microsoft Entra, assegnati da una funzionalità di governance e che in seguito accedono all'app, possono disporre del ticket Kerberos appropriato. Questo ticket contiene il SID dei gruppi esistenti. L'annidamento è consentito dalle regole di annidamento del gruppo di Active Directory.

Se l'app usa LDAP e segue l'appartenenza a gruppi annidati, visualizzerà gli utenti di Microsoft Entra con il gruppo esistente incluso nelle loro appartenenze.

Determinare l'idoneità del gruppo esistente

  1. Avviare Utenti e computer di Active Directory e registrare il nome distinto, il tipo e l'ambito del gruppo di Active Directory esistente usato dall'applicazione.
  2. Se il gruppo esistente è Domain Admins, Domain Guests, Domain Users, Enterprise Admins, Enterprise Key Admins, Group Policy Creation Owners, Key Admins, Protected Users o Schema Admins, sarà necessario modificare l'applicazione per l'utilizzo di un nuovo gruppo, come descritto in precedenza, perché questi gruppi non possono essere usati dalla sincronizzazione cloud.
  3. Se il gruppo ha ambito Globale, modificare il gruppo in modo che abbia ambito Universale. Un gruppo globale non può avere gruppi universali come membri.

Creare un'applicazione e un gruppo

  1. Nell'interfaccia di amministrazione di Microsoft Entra creare un'applicazione in Microsoft Entra ID che rappresenta l'applicazione basata su Azure AD e configurare l'applicazione per richiedere l'assegnazione dell'utente.
  2. Se viene usato il proxy dell'applicazione per consentire agli utenti di connettersi all'applicazione, configurare il proxy dell'applicazione.
  3. Creare un nuovo gruppo di sicurezza in Microsoft Entra ID.
  4. Usare Provisioning di gruppi in AD per eseguire il provisioning di questo gruppo in AD.
  5. Avviare Utenti e computer di Active Directory e attendere la creazione del nuovo gruppo di Active Directory nel dominio AD. Quando è presente, registrare il nome distinto, il dominio, il nome dell'account e il SID del nuovo gruppo di Active Directory.

Configurare l'applicazione per l'uso del nuovo gruppo

  1. Usando Utenti e computer di Active Directory, aggiungere il nuovo gruppo di Active Directory come membro del gruppo AD esistente.
  2. Creare un pacchetto di accesso. Aggiungere l'applicazione da #1 e il gruppo di sicurezza da #3 come risorse nel pacchetto di accesso. Configurare un criterio di assegnazione diretta nel pacchetto di accesso.
  3. In Gestione entitlement assegnare al pacchetto di accesso gli utenti sincronizzati che necessitano di accedere all'app basata su AD, inclusi gli utenti membri del gruppo AD esistente che necessitano ancora dell'accesso.
  4. Attendere che il nuovo gruppo AD venga aggiornato con i nuovi membri. Usando Utenti e computer di Active Directory, verificare che gli utenti corretti siano presenti come membri del gruppo.
  5. Usando Utenti e computer di Active Directory, rimuovere i membri esistenti del gruppo AD esistente, ad eccezione del nuovo gruppo AD.
  6. Nel monitoraggio del dominio AD, concedere solo all'account gMSA che esegue l'agente di provisioning l'autorizzazione a modificare l'appartenenza al nuovo gruppo AD.

Sarà quindi possibile gestire l'accesso all'applicazione AD tramite questo nuovo pacchetto di accesso.

Risoluzione dei problemi

Un utente membro del nuovo gruppo AD, su un PC Windows già connesso a un dominio AD, potrebbe disporre di un ticket esistente emesso da un controller di dominio AD che non include l'appartenenza al nuovo gruppo AD. Ciò è dovuto al fatto che il ticket potrebbe essere stato emesso prima del provisioning del gruppo di sincronizzazione cloud che aggiunge l'utente al nuovo gruppo AD. L'utente non potrà usare il ticket per accedere all'applicazione e dovrà quindi attendere la scadenza del ticket e l'emissione di un nuovo ticket, oppure rimuovere i propri ticket ed effettuare nuovamente l'accesso al dominio. Per maggiori dettagli, consultare il comando klist.

Clienti writeback dei gruppi v2 di Microsoft Entra Connect

Se si usa il writeback dei gruppi v2 di Microsoft Entra Connect, è necessario passare al provisioning tramite sincronizzazione cloud in AD prima di poter usufruire del provisioning del gruppo di sincronizzazione cloud. Vedere Eseguire la migrazione del writeback dei gruppi di sincronizzazione v2 di Microsoft Entra Connect alla sincronizzazione cloud di Microsoft Entra

Passaggi successivi