Compartir a través de


Tutorial: Implementación del conector de Active Directory en modo keytab administrado por el sistema

En este artículo se explica cómo implementar el conector de Active Directory en modo keytab administrado por el sistema. Es un componente clave para habilitar la autenticación de Active Directory en SQL Managed Instance habilitada por Azure Arc.

Conector de Active Directory en modo keytab administrado por el sistema

En el modo keytab administrado por el sistema, un conector de Active Directory implementa un servicio de proxy DNS que proporciona proxy a las solicitudes DNS procedentes de una instancia administrada a cualquiera de los dos servicios DNS ascendentes:

  • Servidores DNS de Active Directory
  • Servidores DNS de Kubernetes

Además del servicio de proxy DNS, el conector de AD también implementa un servicio de soporte técnico de seguridad que facilita la comunicación con el dominio de AD para la creación y administración automáticas de cuentas de AD, nombres de entidad de seguridad (SPN) y keytabs.

En el diagrama siguiente se muestra la funcionalidad del conector de AD y del servicio proxy DNS en modo keytab administrado por el sistema:

Conector de Active Directory

Requisitos previos

Antes de continuar, debe disponer de lo siguiente:

  • Una instancia de Data Controller implementada en una versión compatible de Kubernetes.
  • Un dominio de Active Directory.
  • Una unidad organizativa (OU) creada previamente en el dominio de Active Directory
  • Una cuenta de servicio del dominio de Active Directory

La cuenta de servicio del dominio de AD debe tener permisos suficientes para crear y eliminar automáticamente cuentas de usuario en la unidad organizativa (OU) proporcionada en el directorio activo.

Conceda los permisos siguientes, con ámbito a la unidad organizativa (OU), a la cuenta de servicio de dominio:

  • Leer todas las propiedades
  • Escribir todas las propiedades
  • Crear objetos de usuario
  • Eliminación de objetos de usuario
  • Restablecimiento de la contraseña en los objetos de usuario descendiente

Para más información sobre cómo configurar la unidad organizativa y la cuenta de AD, vaya a Implementación de servicios de datos habilitados para Azure Arc en la autenticación de Active Directory con keytab administrado por el sistema: requisitos previos

Entrada para implementar el conector de Active Directory en modo keytab administrado por el sistema

Para implementar una instancia de Conector Active Directory, se necesitan varias entradas del entorno del dominio de Active Directory.

Estas entradas se proporcionan en una especificación .yaml de la instancia del conector de AD.

Los siguientes metadatos sobre el dominio de AD deben estar disponibles antes de implementar una instancia del conector de AD:

  • Nombre del dominio de Active Directory
  • Lista de controladores de dominio (nombres de dominio completos)
  • Lista de las direcciones IP de servidores DNS

Los usuarios pueden ver los siguientes campos de entrada en la especificación de Conector de Active Directory:

  • Obligatorio

    • spec.activeDirectory.realm Nombre del dominio de Active Directory en mayúsculas. Este es el dominio de AD al que se asociará esta instancia del conector de AD.

    • spec.activeDirectory.domainControllers.primaryDomainController.hostname Nombre de dominio completo del controlador de dominio principal (PDC) en el dominio de AD.

      Si no sabe qué controlador de dominio del dominio es principal, puede averiguarlo ejecutando este comando en cualquier máquina Windows unido al dominio de AD: netdom query fsmo.

    • spec.activeDirectory.dns.nameserverIpAddresses Lista de direcciones IP del servidor DNS de Active Directory. El servicio de proxy DNS reenviará las consultas de DNS en el nombre de dominio proporcionado a estos servidores.

  • Opcional

    • spec.activeDirectory.serviceAccountProvisioning Se trata de un campo opcional que define el modo de implementación del conector de AD con los valores posibles como manual para keytab administrado por el cliente o automatic para keytab administrado por el sistema. Cuando no se establece este campo, el valor predeterminado es manual. Cuando se establece en automatic (keytab administrado por el sistema), el sistema generará automáticamente cuentas de AD y nombres de entidad de seguridad de servicio (SPN) para las instancias administradas de SQL asociadas a este conector de AD y creará archivos keytab para ellos. Cuando se establece en manual (keytab administrado por el cliente), el sistema no proporcionará la generación automática de la cuenta de AD y la generación de keytab. Se espera que el usuario proporcione un archivo keytab.

    • spec.activeDirectory.ouDistinguishedName Este campo es opcional. Sin embargo, se vuelve condicionalmente obligatorio cuando el valor de serviceAccountProvisioning se establece en automatic. Este campo acepta el nombre distintivo (DN) de la unidad organizativa (OU) que los usuarios deben crear en el dominio de Active Directory antes de implementar el conector de AD. Se usa para almacenar las cuentas de AD generadas por el sistema para SQL Managed Instance en el dominio de Active Directory. Este es un ejemplo del valor: OU=arcou,DC=contoso,DC=local.

    • spec.activeDirectory.domainServiceAccountSecret Este campo es opcional. Se vuelve condicionalmente obligatorio cuando el valor de serviceAccountProvisioning se establece en automatic. Este campo acepta el nombre del secreto de Kubernetes que contiene el nombre de usuario y la contraseña de la cuenta de servicio de dominio que se creó antes de la implementación del conector de AD. El sistema usará esta cuenta para generar otras cuentas de AD en la unidad organizativa y realizar acciones en esas cuentas de AD.

    • spec.activeDirectory.netbiosDomainName Nombre de NetBIOS del dominio de Active Directory. Este es el nombre de dominio corto (nombre anterior a Windows 2000) del dominio de Active Directory. Esto se suele usar para calificar cuentas en el dominio de AD. Por ejemplo, si las cuentas del dominio se conocen como CONTOSO\admin, CONTOSO es el nombre de dominio NETBIOS.

      Este campo es opcional. Cuando no se proporciona, su valor predeterminado es la primera etiqueta del campo spec.activeDirectory.realm.

      En la mayoría de los entornos de dominio, se establece en el valor predeterminado, pero algunos entornos de dominio pueden tener un valor que no sea predeterminado. Tendrá que usar este campo solamente cuando el nombre NetBIOS del dominio no coincida con la primera etiqueta de su nombre completo.

    • spec.activeDirectory.domainControllers.secondaryDomainControllers[*].hostname Lista de los nombres de dominio completos de los controladores de dominio secundarios del dominio de AD.

      Si son varios los controladores de dominio que atienden el dominio, se recomienda incluir algunos de sus nombres de dominio completos en esta lista. Esto permite que haya una alta disponibilidad para las operaciones de Kerberos.

      Este campo es opcional y no es necesario. El sistema detectará automáticamente los controladores de dominio secundarios cuando no se proporcione un valor.

    • spec.activeDirectory.dns.domainName Nombre del dominio DNS en el que las búsquedas DNS se deben reenviar a los servidores DNS de Active Directory.

      Una búsqueda DNS de cualquier nombre que pertenezca a este dominio o a sus dominios descendientes se reenviará a Active Directory.

      Este campo es opcional. Cuando no se proporciona, el valor predeterminado es el valor proporcionado para spec.activeDirectory.realm convertido a minúsculas.

    • spec.activeDirectory.dns.replicas Recuento de réplicas para el servicio de proxy DNS. Este campo es opcional y el valor predeterminado es 1 cuando no se proporciona.

    • spec.activeDirectory.dns.preferK8sDnsForPtrLookups Marca que indica si se prefiere la respuesta del servidor DNS de Kubernetes sobre la respuesta del servidor DNS de AD para las búsquedas de direcciones IP.

      El servicio de proxy DNS se basa en este campo para determinar qué grupo ascendente de servidores DNS es el preferido para las búsquedas de direcciones IP.

      Este campo es opcional. Cuando no se proporciona, el valor predeterminado es true, es decir, las búsquedas DNS de direcciones IP se reenviarán primero a los servidores DNS de Kubernetes. Si los servidores DNS de Kubernetes no responden a la búsqueda, la consulta se reenvía a los servidores DNS de AD. Cuando se establece en false, estas búsquedas DNS se reenviarán primero a los servidores DNS de AD y, tras un error, recurren a Kubernetes.

Implementación del conector de Active Directory en modo keytab administrado por el sistema

Para implementar un conector de AD, cree un archivo de especificaciones de YAML denominado active-directory-connector.yaml.

A continuación se muestra un ejemplo de conector AD de keytab administrado por el sistema que utiliza un dominio AD de nombre CONTOSO.LOCAL. Asegúrese de reemplazar los valores por los de su dominio de AD. adarc-dsa-secret contiene la cuenta de servicio del dominio de AD que se creó antes de la implementación de AD.

Nota:

Asegúrese de que la contraseña de la cuenta de AD del servicio de dominio proporcionada aquí no contiene ! como caracteres especiales.

apiVersion: v1 
kind: Secret 
type: Opaque 
metadata: 
  name: adarc-dsa-secret
  namespace: <namespace>
data: 
  password: <your base64 encoded password>
  username: <your base64 encoded username>
---
apiVersion: arcdata.microsoft.com/v1beta2
kind: ActiveDirectoryConnector
metadata:
  name: adarc
  namespace: <namespace>
spec:
  activeDirectory:
    realm: CONTOSO.LOCAL
    serviceAccountProvisioning: automatic
    ouDistinguishedName: "OU=arcou,DC=contoso,DC=local"
    domainServiceAccountSecret: adarc-dsa-secret
    domainControllers:
      primaryDomainController:
        hostname: dc1.contoso.local
      secondaryDomainControllers:
      - hostname: dc2.contoso.local
      - hostname: dc3.contoso.local
  dns:
    preferK8sDnsForPtrLookups: false
    nameserverIPAddresses:
      - <DNS Server 1 IP address>
      - <DNS Server 2 IP address>

El siguiente comando implementa la instancia del conector de AD. Actualmente, solo se admite el enfoque de la implementación nativo de kubernetes.

kubectl apply –f active-directory-connector.yaml

Después de enviar la implementación de la instancia del conector de AD, puede usar el siguiente comando para comprobar el estado de la implementación.

kubectl get adc -n <namespace>