Usare Enterprise Security Package in HDInsight

Il cluster Azure HDInsight standard è un cluster a utente singolo. Si tratta di un cluster adatto alla maggior parte delle aziende con team di piccole dimensioni che compilano carichi di lavoro di dati di grandi dimensioni. Ogni utente può creare un cluster dedicato diverso su richiesta ed eliminarlo quando non è più necessario.

Molte aziende sono passate a un modello in cui i team IT gestiscono i cluster e più team delle applicazioni condividono i cluster. Per queste aziende di grandi dimensioni è necessario l'accesso multiutente al cluster in Azure HDInsight.

HDInsight si basa su un provider di identità diffuso, Active Directory, in modo gestito. Integrando HDInsight con Microsoft Entra Domain Services, è possibile accedere ai cluster usando le credenziali di dominio.

Le macchine virtuali (VM) in HDInsight sono parte del dominio specificato. Pertanto, tutti i servizi in esecuzione in HDInsight, come Apache Ambari, server Apache Hive, Apache Ranger, server Apache Spark Thrift e altri, funzionano senza problemi per l'utente autenticato. Gli amministratori possono quindi creare criteri di autorizzazione sicuri usando Apache Ranger per fornire il controllo di accesso basato sui ruoli per le risorse nel cluster.

Integrare HDInsight con Active Directory

Apache Hadoop open source si basa sul protocollo Kerberos per l'autenticazione e la sicurezza. Di conseguenza, i nodi del cluster HDInsight con Enterprise Security Package (ESP) vengono aggiunti a un dominio gestito da Microsoft Entra Domain Services. La sicurezza Kerberos è configurata per i componenti Hadoop nel cluster.

Gli elementi seguenti vengono creati automaticamente:

  • Un'entità servizio per ogni componente Hadoop
  • Un'entità computer per ogni computer aggiunto al dominio
  • Un'unità organizzativa (OU) per ogni cluster in cui archiviare le entità servizio e computer

In sintesi, è necessario configurare un ambiente con gli elementi seguenti:

  • Un dominio di Active Directory (gestito da Microsoft Entra Domain Services). Il nome di dominio deve essere di almeno 39 caratteri per funzionare con Azure HDInsight.
  • Ldap sicuro (LD piattaforma di strumenti analitici) abilitato in Microsoft Entra Domain Services.
  • Connettività di rete appropriata dalla rete virtuale HDInsight alla rete virtuale di Microsoft Entra Domain Services, se si scelgono reti virtuali separate. Una macchina virtuale all'interno della rete virtuale HDInsight deve avere una linea di vista per Microsoft Entra Domain Services tramite il peering di rete virtuale. Se HDInsight e Microsoft Entra Domain Services vengono distribuiti nella stessa rete virtuale, la connettività viene fornita automaticamente e non sono necessarie altre azioni.

Configurazione diversa dei controller di dominio

HDInsight supporta attualmente solo Microsoft Entra Domain Services come controller di dominio principale usato dal cluster per la comunicazione Kerberos. Tuttavia, sono possibili altre configurazioni complesse di Active Directory, purché tale configurazione consenta l'abilitazione dell'accesso a Microsoft Entra Domain Services per HDInsight.

Servizi di dominio Microsoft Entra

Microsoft Entra Domain Services fornisce un dominio gestito completamente compatibile con Windows Server Active Directory. Microsoft si occupa della gestione, dell'applicazione di patch e del monitoraggio del dominio AD in una configurazione a disponibilità elevata. È possibile distribuire il cluster senza doversi preoccupare di gestire i controller di dominio.

Gli utenti, i gruppi e le password vengono sincronizzati da Microsoft Entra ID. La sincronizzazione unidirezionale dall'istanza di Microsoft Entra a Microsoft Entra Domain Services consente agli utenti di accedere al cluster usando le stesse credenziali aziendali.

Per altre informazioni, vedere Configurare cluster HDInsight con ESP con Microsoft Entra Domain Services.

Active Directory locale o Active Directory nelle macchine virtuali IaaS

Se si dispone di un'istanza di Active Directory locale o di configurazioni di Active Directory più complesse per il dominio, è possibile sincronizzare tali identità con Microsoft Entra ID usando Microsoft Entra Connessione. È quindi possibile abilitare Microsoft Entra Domain Services nel tenant di Active Directory.

Poiché Kerberos si basa sugli hash delle password, è necessario abilitare la sincronizzazione dell'hash delle password in Servizi di dominio Microsoft Entra.

Se si usa la federazione con Active Directory Federation Services (AD FS), è necessario abilitare la sincronizzazione dell'hash delle password. Per una configurazione consigliata, vedere questo video. La sincronizzazione dell'hash delle password consente il ripristino di emergenza in caso di errore dell'infrastruttura AD FS e consente anche di fornire protezione delle credenziali perse. Per altre informazioni, vedere Abilitare la sincronizzazione dell'hash delle password con Microsoft Entra Connessione Sync.

L'uso di Active Directory locale o Active Directory solo in macchine virtuali IaaS, senza ID Microsoft Entra e Microsoft Entra Domain Services, non è una configurazione supportata per i cluster HDInsight con ESP.

Nota

I moduli di Azure AD e MSOnline PowerShell sono deprecati a partire dal 30 marzo 2024. Per altre informazioni, leggere l'aggiornamento deprecato. Dopo questa data, il supporto per questi moduli è limitato all'assistenza per la migrazione a Microsoft Graph PowerShell SDK e alle correzioni di sicurezza. I moduli deprecati continueranno a funzionare fino al 30 marzo 2025.

È consigliabile eseguire la migrazione a Microsoft Graph PowerShell per interagire con Microsoft Entra ID (in precedenza Azure AD). Per domande comuni sulla migrazione, vedere Domande frequenti sulla migrazione. Nota: le versioni 1.0.x di MSOnline potrebbero verificarsi interruzioni dopo il 30 giugno 2024.

Se la federazione viene usata e gli hash delle password vengono sincronizzati correttamente, ma si verificano errori di autenticazione, verificare se l'autenticazione della password cloud è abilitata per l'entità servizio di PowerShell. In caso contrario, è necessario impostare un criterio di individuazione dell'area di autenticazione principale (HRD) per il tenant di Microsoft Entra. Per verificare e impostare i criteri di individuazione dell'area di autenticazione principale:

  1. Installare il modulo di Anteprima di Azure AD PowerShell.

    Install-Module AzureAD
    
  2. Connessione usando le credenziali di amministratore globale (amministratore tenant).

    Connect-AzureAD
    
  3. Controllare se è già stata creata l'entità servizio Microsoft Azure PowerShell.

    Get-AzureADServicePrincipal -SearchString "Microsoft Azure PowerShell"
    
  4. Se non esiste, creare l'entità servizio.

    $powershellSPN = New-AzureADServicePrincipal -AppId 1950a258-227b-4e31-a9cf-717495945fc2
    
  5. Creare e associare i criteri a questa entità servizio.

     # Determine whether policy exists
     Get-AzureADPolicy | Where {$_.DisplayName -eq "EnableDirectAuth"}
    
     # Create if not exists
     $policy = New-AzureADPolicy `
         -Definition @('{"HomeRealmDiscoveryPolicy":{"AllowCloudPasswordValidation":true}}') `
         -DisplayName "EnableDirectAuth" `
         -Type "HomeRealmDiscoveryPolicy"
    
     # Determine whether a policy for the service principal exist
     Get-AzureADServicePrincipalPolicy `
         -Id $powershellSPN.ObjectId
    
     # Add a service principal policy if not exist
     Add-AzureADServicePrincipalPolicy `
         -Id $powershellSPN.ObjectId `
         -refObjectID $policy.ID
    

Passaggi successivi