Uso de Enterprise Security Package en HDInsight
El clúster de Azure HDInsight estándar es de un único usuario. Es apropiado para la mayor parte de las empresas que tienen equipos de aplicaciones pequeños que generan grandes cargas de trabajo de datos. Cada usuario puede crear un clúster dedicado a petición y destruirlo cuando ya no sea necesario.
Muchas empresas han migrado a un modelo en el que los equipos de TI administran los clústeres y varios equipos de aplicaciones los comparten. Estas empresas más grandes necesitan acceso multiusuario a cada clúster de Azure HDInsight.
HDInsight se basa en un proveedor de identidades conocido (Active Directory) de una manera administrada. Mediante la integración de HDInsight con Microsoft Entra Domain Services, puede acceder a los clústeres utilizando sus credenciales de dominio.
Las máquinas virtuales (VM) de HDInsight están unidas al dominio proporcionado. De este modo, todos los servicios que se ejecutan en HDInsight (Apache Ambari, servidor de Apache Hive, Apache Ranger, servidor Thrift de Apache Spark, etc.) funcionan perfectamente para el usuario autenticado. Los administradores pueden crear entonces directivas de autorización seguras con Apache Ranger para proporcionar control de acceso basado en rol para los recursos del clúster.
Integración de HDInsight con Active Directory
Apache Hadoop de código abierto se basa en el protocolo Kerberos para proporcionar autenticación y seguridad. Por lo tanto, los nodos de clúster de HDInsight con Enterprise Security Package (ESP) se unen a un dominio administrado por Microsoft Entra Domain Services. Se configura la seguridad de Kerberos para los componentes de Hadoop en el clúster.
Las siguientes cosas se crean automáticamente:
- Una entidad de servicio para cada componente de Hadoop.
- Una entidad de seguridad de máquina para cada máquina unida al dominio.
- Una unidad organizativa (UO) para cada clúster para almacenar estas entidades de servicio y de máquina.
En resumen, es necesario configurar un entorno con:
- Un dominio de Active Directory (administrado por Microsoft Entra Domain Services). El nombre de dominio debe tener 39 caracteres como máximo para funcionar con Azure HDInsight.
- LDAP seguro (LDAPS) habilitado en Microsoft Entra Domain Services.
- Conectividad de red adecuada desde la red virtual de HDInsight a la red virtual de Microsoft Entra Domain Services, si elige redes virtuales independientes para ellas. Una máquina virtual dentro de la red virtual de HDInsight debe tener una línea de visión a Microsoft Entra Domain Services a través del emparejamiento de redes virtuales. Si HDInsight y Microsoft Entra Domain Services se implementan en la misma red virtual, se proporciona automáticamente la conectividad y no se necesita ninguna acción adicional.
Configuración de distintos controladores de dominio
HDInsight actualmente solo admite Microsoft Entra Domain Services como controlador de dominio principal que usa el clúster para la comunicación Kerberos. Pero hay otras configuraciones complejas de Active Directory que son posibles, siempre y cuando dicha configuración lleve a habilitar Microsoft Entra Domain Services para el acceso a HDInsight.
Servicios de dominio de Microsoft Entra
Microsoft Entra Domain Services proporciona un dominio administrado que es totalmente compatible con Windows Server Active Directory. Microsoft se encarga de administrar y supervisar el dominio, y de aplicarle los parches, en una configuración de alta disponibilidad (HA). Puede implementar el clúster sin preocuparse por mantener los controladores de dominio.
Los usuarios, grupos y contraseñas se sincronizan con Microsoft Entra ID. La sincronización unidireccional desde la instancia de Microsoft Entra a Microsoft Entra Domain Services permite a los usuarios iniciar sesión en el clúster mediante las mismas credenciales corporativas.
Para obtener más información, vea Configuración de clústeres de HDInsight con ESP mediante Microsoft Entra Domain Services.
Active Directory local o Active Directory en máquinas virtuales de IaaS
Si tiene una instancia de Active Directory local o configuraciones más complejas de Active Directory para su dominio, puede sincronizar esas identidades con Microsoft Entra ID utilizando Microsoft Entra Connect. A continuación, puede habilitar Microsoft Entra Domain Services en ese inquilino de Active Directory.
Dado que Kerberos se basa en hashes de contraseñas, debe habilitar la sincronización de hash de contraseñas en Microsoft Entra Domain Services.
Si está usando la federación con los Servicios de federación de Active Directory (AD FS), debe habilitar la sincronización del hash de contraseña. (Para ver una configuración recomendada, consulte este vídeo.) La sincronización del hash contraseña le permite llevar a cabo la recuperación ante desastres en caso de que su infraestructura de AD FS falle; asimismo, también le ayudará a proporcionar protección para las credenciales filtradas. Para obtener más información, vea Habilitar sincronización de hash de contraseña con Microsoft Entra Connect Sync.
Cuando se usa Active Directory local o Active Directory solo en máquinas virtuales IaaS, sin Microsoft Entra ID y Microsoft Entra Domain Services, no es una configuración compatible para clústeres de HDInsight con ESP.
Nota:
Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lee la actualización de desuso. Desde esta fecha, el soporte de estos módulos se limita a la asistencia de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos en desuso seguirán funcionando hasta el 30 de marzo de 2025.
Se recomienda migrar a PowerShell de Microsoft Graph para interactuar con Microsoft Entra ID (anteriormente Azure AD). Para preguntas comunes sobre la migración, consulta las Preguntas más frecuentes sobre migración. Nota: versiones 1.0.x de MSOnline pueden experimentar interrupciones después del 30 de junio de 2024.
Si usa hashes de federación y contraseña se sincronizan correctamente, pero recibe errores de autenticación, compruebe si la autenticación con contraseña en la nube está habilitada para la entidad de servicio de PowerShell. Si no es así, debe establecer una directiva Home Realm Discovery (HRD) para su inquilino de Microsoft Entra. Para comprobar y establecer la directiva de HRD:
Instale la versión preliminar del módulo de PowerShell de Azure AD.
Install-Module AzureADConéctese con las credenciales de un administrador (administrador de inquilinos).
Connect-AzureADCompruebe si ya se ha creado la entidad de servicio "Microsoft Azure PowerShell".
Get-AzureADServicePrincipal -SearchString "Microsoft Azure PowerShell"Si no existe, cree la entidad de servicio.
$powershellSPN = New-AzureADServicePrincipal -AppId 1950a258-227b-4e31-a9cf-717495945fc2Cree y asocie la directiva a la entidad de servicio.
# 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