Condividi tramite

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

  • Articolo

Importante

L'anteprima pubblica di Group Writeback v2 in Microsoft Entra Connect Sync non è più disponibile a partire dal 30 giugno 2024. Questa funzionalità non è più disponibile in questa data e non è più supportata in Microsoft Entra Connect Sync per effettuare il provisioning dei gruppi di sicurezza cloud in Active Directory. La funzionalità continua a funzionare oltre la data di interruzione; tuttavia, non riceve più supporto e potrebbe smettere di funzionare in qualsiasi momento senza preavviso.

È disponibile una funzionalità simile in Microsoft Entra Cloud Sync chiamata Provisioning dei gruppi in Active Directory che può essere usata invece di Group Writeback v2 per il provisioning di gruppi di sicurezza cloud in Active Directory. Stiamo lavorando per migliorare questa funzionalità in Microsoft Entra Cloud Sync insieme ad altre nuove funzionalità che stiamo sviluppando in Microsoft Entra Cloud Sync.

I clienti che usano questa funzionalità di anteprima in Microsoft Entra Connect Sync devono cambiare la configurazione da Microsoft Entra Connect Sync a Microsoft Entra Cloud Sync. È possibile scegliere di spostare tutta la sincronizzazione ibrida in Microsoft Entra Cloud Sync (se supporta le proprie esigenze). È anche possibile eseguire Microsoft Entra Cloud Sync in parallelo e spostare solo il provisioning del gruppo di sicurezza cloud verso Active Directory tramite Microsoft Entra Cloud Sync.

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 il passaggio esclusivamente a Microsoft Entra Cloud Sync usando la procedura guidata di sincronizzazione utente .

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 utilizzare le funzionalità di governance delle identità per gestire l'accesso alle applicazioni basate su AD. Ad esempio, è possibile includere un gruppo in un pacchetto di accesso di gestione delle assegnazioni.

Disegno concettuale del provisioning dei gruppi di Microsoft Entra Cloud Sync in Active Directory.

Guardare il video del writeback dei gruppi

Per un'ottima panoramica del provisioning dei gruppi di sincronizzazione cloud in Active Directory e cosa può fare per te, guarda il video qui sotto.

Prerequisiti

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

  • Account Microsoft Entra che ha almeno il 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 le proprietà di lettura, scrittura, creazione ed eliminazione siano applicate a tutti i gruppi e oggetti utente discendenti.

Queste autorizzazioni non vengono applicate agli oggetti AdminSDHolder per impostazione predefinita

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

  • 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 di 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
  • Questi gruppi devono avere un'appartenenza dinamica o assegnata
  • Questi gruppi possono contenere solo utenti sincronizzati locali e/o gruppi di sicurezza creati dal cloud
  • Gli account utente in sede che sono sincronizzati e sono membri di questo gruppo di sicurezza creato nel cloud possono appartenere allo stesso dominio o inter-dominio, ma devono tutti provenire dalla stessa foresta.
  • Questi gruppi vengono riscritti con l'ambito universale dei gruppi di Active Directory. L'ambiente on-premise deve essere in grado di supportare l'ambito del gruppo universale
  • I gruppi con dimensioni superiori a 50.000 membri non sono supportati
  • Ogni gruppo annidato figlio diretto è conteggiato come un membro nel gruppo di riferimento

Scenari supportati

Le sezioni seguenti discutono gli scenari che sono supportati con la creazione di gruppi di 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 di sincronizzazione cloud per assicurarsi che un utente di Active Directory disponga di tali appartenenze ai gruppi prima che l'utente accesa alle applicazioni.

Le sezioni seguenti illustrano due opzioni di scenario supportate con il provisioning del gruppo di 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 o
  • Creare un nuovo gruppo e aggiornare i gruppi esistenti che l'applicazione stava controllando 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 degli 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 si aggiorna l'applicazione per controllare il SID, il nome o il nome distinto dei nuovi gruppi creati tramite il provisioning dei gruppi di sincronizzazione cloud. Questo scenario è applicabile a:

  • Implementazioni per nuove applicazioni connesse ai Servizi di dominio Active Directory 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. Le applicazioni che attualmente controllano l'appartenenza al Domain Admins gruppo devono essere aggiornate per verificare anche la presenza di un gruppo di Active Directory appena creato.

Segui i seguenti passaggi per utilizzare le applicazioni con i 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 AD e configurare l'applicazione per richiedere l'assegnazione dell'utente.
  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. Avvia Utenti e Computer di Active Directory e attendi che il nuovo gruppo di Active Directory venga creato nel dominio di 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 dominio e il nome dell'account del nuovo gruppo di Active Directory.
  2. Creare un pacchetto di accesso. Aggiungere l'applicazione dal passaggio 1 e dal gruppo di sicurezza del passaggio 3 come descritto nella sezione Creare un'applicazione e un gruppo sopra come risorse nel pacchetto di accesso. Configurare un criterio di assegnazione diretta nel pacchetto di accesso.
  3. In Gestione delle autorizzazioni, assegnare al pacchetto di accesso gli utenti sincronizzati che devono accedere all'applicazione basata su Active Directory (AD).
  4. Attendere che il nuovo gruppo AD venga aggiornato con i nuovi membri. Utilizzando Utenti e Computer di Active Directory, verificare che siano presenti nel gruppo gli utenti corretti.
  5. Nel monitoraggio del dominio di Active Directory, consentire solo all'account gMSA che esegue l'autorizzazione dell'agente di provisioning di modificare l'appartenenza al nuovo gruppo di Active Directory.

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

Configurazione dell'opzione gruppi esistenti

In questo scenario, si aggiunge un nuovo gruppo di sicurezza di Active Directory come membro di un gruppo annidato all'interno di un gruppo esistente. Questo scenario è applicabile alle distribuzioni di applicazioni che hanno una dipendenza predefinita da un determinato nome dell'account del gruppo, SID o nome distinto.

L'annidamento di tale gruppo nel gruppo di Active Directory esistente dell'applicazione consentirà:

  • Utenti di Microsoft Entra assegnati da una funzionalità di governance e che accedono all'app per avere il ticket Kerberos appropriato. Questo ticket contiene il SID del gruppo esistente. L'annidamento è consentito dalle norme di annidamento dei gruppi di Active Directory.

Se l'app utilizza LDAP e segue l'appartenenza a gruppi annidati, vedrà gli utenti di Microsoft Entra come membri del gruppo esistente.

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 GuestsDomain UsersEnterprise AdminsEnterprise Key Admins, Group Policy Creation OwnersKey AdminsProtected Userso Schema Admins, sarà necessario modificare l'applicazione per usare 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 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. Utilizza Provisioning del gruppo in Active Directory per eseguire il provisioning di questo gruppo in Active Directory.
  5. Avvia Utenti e Computer di Active Directory e attendi che il nuovo gruppo di Active Directory venga creato nel dominio di 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. Usando Utenti e Computer di Active Directory, aggiungere il nuovo gruppo AD come membro del gruppo AD esistente.
  2. Creare un pacchetto di accesso. Aggiungere l'applicazione dal passaggio 1 e dal gruppo di sicurezza del passaggio 3 come descritto nella sezione Creare un'applicazione e un gruppo sopra come risorse nel pacchetto di accesso. Configurare un criterio di assegnazione diretta nel pacchetto di accesso.
  3. In Entitlement Management assegnare gli utenti sincronizzati che devono accedere all'app basata su AD al pacchetto di accesso, inclusi tutti i membri utente del gruppo di Active Directory esistente che necessitano ancora dell'accesso.
  4. Attendere che il nuovo gruppo AD venga aggiornato con i nuovi membri. Utilizzando Utenti e Computer di Active Directory, verificare che siano presenti nel gruppo gli utenti corretti.
  5. Usando Utenti e computer di Active Directory, rimuovere i membri esistenti, tranne il nuovo gruppo di AD, dal gruppo di Active Directory esistente.
  6. Nel monitoraggio del dominio di Active Directory, consentire solo all'account gMSA che esegue l'autorizzazione dell'agente di provisioning di modificare l'appartenenza al nuovo gruppo di Active Directory.

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

Risoluzione dei problemi

Un utente membro del nuovo gruppo di Active Directory e si trova in un PC Windows già connesso a un dominio di Active Directory potrebbe avere un ticket esistente emesso da un controller di dominio di Active Directory che non include la nuova appartenenza al gruppo di Active Directory. Questo è dovuto al fatto che il ticket potrebbe essere stato emesso prima che il provisioning del gruppo di sincronizzazione cloud aggiungesse l'utente al nuovo gruppo AD. L'utente non sarà in grado di presentare il ticket per l'accesso all'applicazione e quindi deve attendere che il ticket scada e che venga emesso un nuovo ticket oppure deve ripulire i ticket, disconnettersi e quindi accedere di nuovo al dominio. Per maggiori dettagli, consultare il comando klist.

Clienti esistenti del 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 Active Directory prima di poter usufruire del provisioning dei gruppi tramite sincronizzazione cloud. Vedere Migrare il writeback dei gruppi di Microsoft Entra Connect Sync V2 a Microsoft Entra Cloud Sync

Passaggi successivi