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 funzionare oltre la data di interruzione; tuttavia, non riceverà più supporto dopo questa data 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 affiancato e spostare in Cloud Sync solo il provisioning dei 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. Microsoft Entra Cloud Sync consente di gestire completamente le assegnazioni di applicazioni in AD sfruttando al tempo stesso le funzionalità di governance di Microsoft Entra ID 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 ACTIVE Directory, ad esempio includendo un gruppo in un pacchetto di accesso di gestione entitlement.

Disegno concettuale del provisioning del gruppo di Microsoft Entra Cloud Sync in AD.

Guardare il video di writeback del gruppo

Per una panoramica generale del provisioning del gruppo di sincronizzazione cloud in Active Directory e delle operazioni che può essere eseguita, 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 versione successiva.
    • Obbligatorio per l'attributo schema di ACTIVE Directory - msDS-ExternalDirectoryObjectId.
  • Agente di provisioning con build versione 1.1.1367.0 o successiva.

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 discendenti e gli oggetti utente.

Queste autorizzazioni non vengono applicate agli oggetti AdminSDHolder per impostazione predefinita

Cmdlet di PowerShell per l'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).
    • Obbligatorio per la ricerca del catalogo globale per escludere riferimenti di appartenenza non validi.
  • Microsoft Entra Connect con build 2.2.8.0 o successiva.
    • 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 dal cloud
  • questi gruppi possono avere un'appartenenza dinamica o assegnata
  • questi gruppi possono contenere solo utenti sincronizzati locali e/o gruppi di sicurezza creati nel cloud
  • Gli account utente locali sincronizzati e membri di questo gruppo di sicurezza creato dal cloud possono essere dello stesso dominio o tra domini, ma tutti devono trovarsi dalla stessa foresta
  • Questi gruppi vengono sottoposti a writeback con l'ambito dei gruppi universale di AD. L'ambiente locale deve supportare l'ambito del gruppo universale
  • i gruppi con dimensioni superiori a 50.000 membri non sono supportati
  • 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 di sincronizzazione cloud.

Configurazione di scenari supportati

Se si desidera controllare se un utente è in grado di connettersi a un'applicazione Active Directory che usa autenticazione di Windows, è possibile usare il proxy di 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 acceda alle applicazioni.

Le sezioni seguenti illustrano due opzioni di scenario supportate con il provisioning del gruppo di sincronizzazione cloud. Le opzioni dello scenario sono progettate per garantire che gli utenti assegnati all'applicazione abbiano 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, l'applicazione stava verificando, 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 Dominio di Active Directory Services (AD DS) installati nel PC Windows.

Configurazione dell'opzione nuovi gruppi

In questo scenario si aggiorna 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.
  • per la 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 dovranno essere aggiornate anche per verificare la presenza di un nuovo gruppo di Active Directory creato.

Usare la procedura seguente per le applicazioni per l'uso di 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 gruppo in ACTIVE Directory per effettuare il provisioning di questo gruppo in ACTIVE Directory.
  5. Avviare Utenti e computer di Active Directory e attendere che il nuovo gruppo di Active Directory risultante 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 di un 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, il gruppo di sicurezza da #3, 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.
  4. Attendere che il nuovo gruppo di Active Directory 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 di Active Directory consentire solo l'account del servizio gestito del gruppo che esegue l'agente di provisioning, l'autorizzazione per 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 del gruppo annidato di un gruppo esistente. Questo scenario è applicabile alle distribuzioni per le applicazioni che hanno una dipendenza hardcoded da un determinato nome di account di gruppo, SID o nome distinto.

L'annidamento del gruppo nelle applicazioni esistenti di Active Directory consentirà:

  • Gli utenti di Microsoft Entra, assegnati da una funzionalità di governance e successivamente accedono all'app, per avere un ticket Kerberos appropriato. Questo ticket conterrà il SID dei gruppi esistenti. Questo annidamento è consentito dalle regole di annidamento dei gruppi di Active Directory.

Se l'app usa LDAP e segue l'appartenenza a gruppi annidati, l'app visualizzerà gli utenti di Microsoft Entra come uno dei 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 GuestsGroup Policy Creation OwnersDomain UsersEnterprise Key AdminsKey AdminsEnterprise 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 il proxy dell'applicazione verrà usato 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 gruppo in ACTIVE Directory per effettuare il provisioning di questo gruppo in ACTIVE Directory.
  5. Avviare Utenti e computer di Active Directory e attendere che il nuovo gruppo di Active Directory risultante 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 di un nuovo gruppo

  1. Usando Utenti e computer di Active Directory, aggiungere il nuovo gruppo di Active Directory come membro del gruppo di Active Directory esistente.
  2. Creare un pacchetto di accesso. Aggiungere l'applicazione da #1, il gruppo di sicurezza da #3, 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. Sono inclusi tutti i membri utente del gruppo di Active Directory esistente che continueranno a richiedere l'accesso.
  4. Attendere che il nuovo gruppo di Active Directory 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, oltre al nuovo gruppo di Active Directory, del gruppo di Active Directory esistente.
  6. Nel monitoraggio del dominio di Active Directory consentire solo l'account del servizio gestito del gruppo che esegue l'agente di provisioning, l'autorizzazione per 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 AD che non include la nuova appartenenza al gruppo di Active Directory. Ciò è dovuto al fatto che il ticket potrebbe essere stato rilasciato prima del provisioning del gruppo di sincronizzazione cloud aggiungendoli al nuovo gruppo di Active Directory. L'utente non sarà in grado di presentare il ticket per l'accesso all'applicazione e quindi deve attendere che il ticket scada e un nuovo ticket emesso o ripulire i ticket, disconnettersi e accedere di nuovo al dominio. Per altri dettagli, vedere il comando klist .

Clienti del writeback del gruppo Microsoft Entra Connect v2 esistenti

Se si usa il writeback del gruppo Microsoft Entra Connect v2, è necessario passare al provisioning della sincronizzazione cloud in AD prima di poter sfruttare il provisioning del gruppo di sincronizzazione cloud. Vedere Eseguire la migrazione del writeback del gruppo di sincronizzazione Microsoft Entra Connect V2 a Microsoft Entra Cloud Sync

Passaggi successivi