Active Directory s’appuie sur le DNS pour fonctionner correctement. Si votre environnement dispose déjà d'un serveur DNS BIND basé sur Linux, il est possible que les zones DNS Active Directory soient hébergées sur le serveur DNS existant.
Les avantages :
Les inconvénients :
Un domaine Active Directory a besoin d'enregistrements de ressources du localisateur SRV (Service Location) pour fonctionner. Ces enregistrements permettent aux clients et aux contrôleurs de domaine de localiser les services AD comme les contrôleurs de domaine, les serveurs LDAP, Kerberos, etc.
Les enregistrement SRV doivent alors exister pour les services suivants :
Ces enregistrements associent un nom d’hôte à l'adresse IP des contrôleurs de domaine AD.
Ces enregistrements seront utilisés pour que les clients puissent résoudre le nom du contrôleur de domaine AD en adresse IP.
Exemple : agence-dc.agence.cub.fr qui a l'adresse IP 172.16.50.70
agence-dc IN A 172.16.50.70
Les enregistrements SRV sont nécessaires pour localiser les services AD. Ces enregistrements ont le format suivants :
_service._protocol.domain
Voici les principaux enregistrements SRV adapté au contexte CUB:
| . Enregistrement | Description |
|---|---|
| _ldap._tcp.dc._msdcs.agence.cub.fr | Localise les contrôleurs de domaine via LDAP. |
| _kerberos._tcp.dc._msdcs.agence.cub.fr | Localise les serveurs Kerberos pour l’authentification. |
| _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.agence.cub.fr | Localise les DCs dans le site AD créé par défaut. |
| _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.agence.cub.fr | Localise les serveurs Kerberos dans un site créé par défaut. |
| _gc._tcp.agence.cub.fr | Localise les serveurs de catalogue global (Global Catalog). |
| _ldap._tcp.pdc._msdcs.agence.cub.fr | Localise le contrôleur de domaine principal (PDC Emulator). |
Pour vérifier les enregistrements SRV avec Nslookup :
; enregistrement Active directory du domaine cub.fr cub-dc IN A 172.16.x.y _ldap._tcp IN SRV 0 0 389 cub-dc _ldap._tcp.pdc._msdcs IN SRV 0 0 389 cub-dc _ldap._tcp.default-First-Site-Name._sites IN SRV 0 0 389 DC-01 _ldap._tcp.dc._msdcs IN SRV 0 0 389 cub-dc _ldap._tcp.gc._msdcs IN SRV 0 0 389 cub-dc _kerberos._tcp IN SRV 0 0 88 cub-dc _kerberos._tcp.dc._msdcs IN SRV 0 0 88 cub-dc _ldap._tcp.default-First-Site-Name._sites IN SRV 0 0 389 cub-dc _kerberos._tcp.Default-First-Site-Name._sites IN SRV 0 0 88 cub-dc
dcdiag /test:DNS /v /s:NomDuDC
ipconfig /registerdns net stop netlogon net start netlogon
Cela recréera les enregistrements SRV dans DNS si le DC est bien configuré.
Kerberos exige une synchronisation stricte (±5 minutes). Si l’horloge dérive, l’authentification échoue :
apt install openntpd
apt install packagekit samba-common-bin sssd-tools sssd libnss-sss libpam-sss sssd realmd sudo apt install adcli oddjob oddjob-mkhomedir packagekit
realm discover agence.cub.fr
realm join --user=Administrator@agence.cub.fr agence.cub.fr
La configuration d'un proxy GSS-TSIG (Generic Security Service Algorithm for TSIG) va permettre au contrôleur de domaine Active Directory (Windows Server) de faire des mises à jour DNS dynamiques sécurisées vers le serveur BIND9, en utilisant Kerberos comme mécanisme d’authentification.
C’est la méthode native utilisée par Windows Server pour sécuriser les mises à jour DNS.
GSS-TSIG est une extension de TSIG.
Une clé TSIG (Transaction SIGnature) est une clé cryptographique partagée utilisée pour sécuriser les mises à jour dynamiques DNS entre le client contrôleur de domaine Active Directory et le serveur DNS BIND9.
La a clé TSIG permet :
Avantages de GSS-TSIG :
Créez dans votre annuaire AD un utilisateur nommé dnsbind avec le mot de passe de votre choix (exemple Sio1234*) dédié à la mise à jour du serveur BIND. Le mot de passe de ce compte ne doit pas être changé et ne doit pas expirer.
Ce compte représentera le serveur BIND dans le domaine.
L'installation du client Kerberos est nécessaire pour que Bind9 puisse authentifier les requêtes venant d’AD via GSSAPI.
apt update apt install krb5-user libkrb5-dev libgssapi-krb5-2
Lors de l’installation, renseignez les informations suivantes :
Modifiez / complétez le fichier /etc/krb5.conf
[libdefaults]
default_realm = AGENCE.CUB.FR
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[realms]
AGENCE.CUB.FR = {
kdc = agence-dc.age,ce.cub.fr
admin_server = agence-dc.agence.cub.fr
[domain_realm]
.agence.cub.fr = AGENCE.CUB.FR
agence.cub.fr = AGENCE.CUB.FR
Depuis une invite de commande de votre serveur BIND, testez une authentification avec le compte dnsbind :
kinit dnsbind@AGENCE.CUB.FR
Le mot de passe sera demandé et la commande suivant permet de lister le ticket Kerberos créé :
klist
Depuis une invite de commande de votre serveur BIND, testez une authentification avec le principal (SPN) du compte dnsbind :
// Authentification Kerberos avec le principal voulu avec saisie du mot de passe kinit DNS/nsO.agence.cub.fr@AGENCE.CUB.FR // Authentification Kerberos avec le principal voulu sans saisie du mot de passe kinit -k -t /etc/krb5.keytab DNS/nsO.agence.cub.fr@AGENCE.CUB.FR
* Commentaires : * -k : préciser l'utilisation d'un fichier keytab * -t ou -T : préciser l'utilisation d'un ticket kerberos
Pour retirer les tickets d’authentification actifs (invalider la session Kerberos), utilise la commande suivante :
kdestroy
Cela détruit le cache des tickets Kerberos (TGT et TGS). Options utiles :
Par défaut, le cache est dans /tmp/krb5cc_<UID>.
Pour permettre au serveur Windows AD de s’authentifier automatiquement auprès du service BIND, un principal va être créé.
En Kerberos, un principal est une identité unique utilisée pour l’authentification. C’est l’équivalent d’un “utilisateur” ou “service” dans le système Kerberos.
Un principal est généralement composé de trois parties : nom_utilisateur/nom_service@REALM
Dans l'invite de commande Windows, utilisez la commande suivante pour créer un principal pour dnsbind qui sera enregistré dans le fichier dnsbind.keytab
ktpass -princ DNS/ns0.agence.cub.fr@AGENCE.CUB.FR -mapuser dnsbind -pass Sio1234* -out dnsbind.keytab -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1
Le principal Kerberos doit correspondre au FQDN du serveur BIND
SPN : ServicePrincipalName
setspn -L dnsbind
setspn -A DNS/ns0.agence.cub.fr dnsbind
setspn -D DNS/ns0.agence.cub.fr dnsbind
setspn -X
Copier avec scp de fichier dnsbind.keytab dasn le dossier /etc du serveur BIND avec le nom krb5.keytab
scp dnsbind.keytab sio@ipDebian:/home/sio/
Dans l'invite de commandes du serveur BIND
cp /home/sio/dbsbind.keytab /etc/krb5.keytab chown bind:bind /etc/krb5.keytab chmod 600 /etc/krb5.keytab
Tester l’authentification Kerberos
kinit -k -t /etc/krb5.keytab DNS/ns0.oslo.cub.fr@OSLO.CUB.FR
Visualiser le ticket
klist
Un ticket valide doit être affiché
root@NS0:/etc/bind# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: DNS/ns0.oslo.cub.fr@OSLO.CUB.FR
Valid starting Expires Service principal
11/17/25 16:10:03 11/18/25 02:10:03 krbtgt/OSLO.CUB.FR@OSLO.CUB.FR
renew until 11/18/25 16:10:03
Tester la création d'un enregistrement
// Authentification Kerberos avec le principal voulu avec saisie du mot de passe kinit DNS/nsO.agence.cub.fr@AGENCE.CUB.FR // Authentification Kerberos avec le principal voulu sans saisie du mot de passe kinit -k -t /etc/krb5.keytab DNS/nsO.agence.cub.fr@AGENCE.CUB.FR nsupdate -g > server ns0.agence.cub.fr > zone agence.cub.fr > update add test.agence.cub.fr 3600 A 192.168.1.50 > send
Les lignes de configuration tkey-gssapi-credential et tkey-domain doivent être ajoutées dans le fichier named.conf.options de BIND9, dans le bloc options.
options {
directory "/var/cache/bind";
// Autoriser les mises à jour dynamiques sécurisées via GSS-TSIG
tkey-gssapi-credential "DNS/dnsbind.agence.cub.fr@AGENCE.CUB.FR";
tkey-domain "AGENCE.CUB.FR";
tkey-gssapi-keytab "/etc/krb5.keytab";
...
};
Dans la zone DNS du fichier named.conf.local :
zone "agence.cub.fr" {
type master;
file "/etc/bind/db.agence.cub.fr";
update-policy {
grant DNS/ns0.oslo.cub.fr@OSLO.CUB.FR zonesub ANY;
};
};
Le mot-clé zonesub :
zonesub autorise les mises à jour dans la zone et ses sous-domaines.
Pour limiter les mises à jour à la zone principale, utilisez zone ANY à la place de zonesub ANY.
Relancer BIND9
systemctl restart bind9
ipconfig /registerdns