Tutoriel - Déployer un connecteur Active Directory (AD) en mode Keytab géré par le client
Cet article explique comment déployer un connecteur Active Directory (AD) en mode Keytab géré par le client. Le connecteur est un composant clé pour activer l’authentification Active Directory sur SQL Managed Instance activé par Azure Arc.
Un connecteur Active Directory en mode Keytab géré par le client
En mode Keytab géré par le client, un connecteur Active Directory déploie un service proxy DNS qui transmet les demandes DNS provenant de l’instance gérée à l’un des deux services DNS en amont :
- Serveurs DNS Active Directory
- Serveurs DNS Kubernetes
Le connecteur AD organise l’environnement dont SQL a besoin pour authentifier les connexions AD.
Le diagramme suivant illustre le fonctionnement du connecteur AD et du service proxy DNS en mode Keytab géré par le client :
Prérequis
Avant de continuer, vous devez disposer des éléments suivants :
- Une instance de contrôleur de données déployée sur une version prise en charge de Kubernetes
- Un domaine Azure Directory (AD)
Entrée pour le déploiement du connecteur d’Active Directory (AD)
Pour déployer une instance de connecteur Active Directory, plusieurs entrées sont nécessaires à partir de l’environnement de domaine Active Directory.
Ces entrées sont fournies dans une spécification YAML d’une instance AD Connector.
Les métadonnées suivantes relatives au domaine Active Directory doivent être disponibles avant le déploiement d’une instance du connecteur AD :
- Nom du domaine Active Directory
- Liste des contrôleurs de domaine (noms de domaine complets)
- Liste des adresses IP des serveurs DNS
Les champs d’entrée suivants sont exposés aux utilisateurs dans la spécification du connecteur Active Directory :
Obligatoire
spec.activeDirectory.realm
Nom du domaine Active Directory en majuscules. Il s’agit du domaine AD auquel cette instance du connecteur AD sera associée.spec.activeDirectory.dns.nameserverIpAddresses
Liste des adresses IP du serveur DNS Active Directory. Le service proxy DNS transfère les requêtes DNS dans le nom de domaine fourni à ces serveurs.
Facultatif
spec.activeDirectory.netbiosDomainName
Nom NETBIOS du domaine Active Directory. Il s’agit du nom de domaine court (pré-Windows 2000) de votre domaine Active Directory. Cette valeur est souvent utilisée pour qualifier les comptes dans le domaine AD. Par exemple, si les comptes du domaine sont appelés CONTOSO\admin, CONTOSO est le nom de domaine NETBIOS.Ce champ est facultatif. Lorsqu’il n’est pas renseigné, la première étiquette du champ
spec.activeDirectory.realm
est définie par défaut.Dans la plupart des environnements de domaine, il s’agit de la valeur par défaut, mais certains environnements de domaine peuvent avoir une valeur non définie par défaut. Vous devez utiliser ce champ uniquement lorsque le nom NetBIOS de votre domaine ne correspond pas à la première étiquette de son nom complet.
spec.activeDirectory.dns.domainName
Nom de domaine DNS pour lequel les recherches DNS doivent être transférées aux serveurs DNS Active Directory.Une recherche DNS pour tout nom appartenant à ce domaine ou à ses domaines descendants sera transférée à Active Directory.
Ce champ est facultatif. Lorsqu’il n’est pas fourni, la valeur par défaut de est
spec.activeDirectory.realm
convertie en minuscules.spec.activeDirectory.dns.replicas
Nombre de réplicas pour le service proxy DNS. Ce champ est facultatif et prend par défaut la valeur 1 lorsqu’il n’est pas fourni.spec.activeDirectory.dns.preferK8sDnsForPtrLookups
Indicateur indiquant s’il faut préférer la réponse du serveur DNS Kubernetes à la réponse du serveur DNS AD pour les recherches d’adresses IP.Le service de proxy DNS s’appuie sur ce champ pour déterminer le groupe en amont de serveurs DNS à préférer aux recherches d’adresses IP.
Ce champ est facultatif. S’il n’est pas renseigné, la valeur par défaut est
true
, ce qui signifie que les recherches DNS d’adresses IP seront d’abord transférées aux serveurs DNS Kubernetes. Si les serveurs DNS Kubernetes ne parviennent pas à répondre à la recherche, la requête est ensuite transférée aux serveurs DNS AD. Lorsqu’il est défini surfalse
, ces recherches DNS seront transférées aux serveurs DNS AD en premier et en cas d’échec, reviendront à Kubernetes.
Déployer un connecteur Active Directory (AD) en mode Keytab géré par le client
Pour déployer un connecteur AD, créez un fichier de spécifications .yaml appelé active-directory-connector.yaml
.
L’exemple suivant est un connecteur AD en mode Keytab géré par le client qui utilise un domaine AD nommé CONTOSO.LOCAL
. Veillez à remplacer les valeurs par celles de votre domaine AD.
apiVersion: arcdata.microsoft.com/v1beta1
kind: ActiveDirectoryConnector
metadata:
name: adarc
namespace: <namespace>
spec:
activeDirectory:
realm: CONTOSO.LOCAL
dns:
preferK8sDnsForPtrLookups: false
nameserverIPAddresses:
- <DNS Server 1 IP address>
- <DNS Server 2 IP address>
La commande suivante déploie l’instance du connecteur AD. Actuellement, seule l’approche Kube-native du déploiement est prise en charge.
kubectl apply –f active-directory-connector.yaml
Après avoir soumis le déploiement de l’instance de connecteur AD, vous pouvez vérifier l’état du déploiement à l’aide de la commande suivante.
kubectl get adc -n <namespace>