Controleur secondaire de domaine

Le Contrôleur Secondaire de Domaine

Un peu de théorie

Le contrôle secondaire de domaine

Un contrôleur de domaine ( DC ) est une machine capable de répondre aux demandes de connexion
des stations de travail. Cette technologie est connue sous le nom de NT Logon Service.

Quand un utilisateur, sur une stations Windows NT4/2000/XP , se loggue, la station se connecte à un contrôleur de domaine pour valider le nom d’utilisateur et le mot de passe. Si les informations entrées ne correspondent pas à ce qui est enregistré dans la base de données du contrôleur ( SAM : Security Account Manager ), un code d’erreur est retourné à la station.

Si les informations utilisateur/mot de passe sont validées, le contrôleur répond par un ’paquet’ contenant toutes les informations enregistrées dans la base SAM pour cet utilisateur. Ces informations contiennent un profil d’accès réseau complet.

Il y a 2 situations dans pour lesquelles on utilise un BDC :

• Sur un réseau local, sur lequel se trouve beaucoup de stations, et/ou le PDC est généralement très occupé. Dans ce cas, le BDC prendra en charge les demandes de loggon.
• Sur des sites distants, pour réduire le trafic réseau extérieur.

Interactions PDC – BDC NT4.0

Dans un véritable environnement NT4, le PDC contient la copie maître de la base SAM. Si un administrateur effectue une modification, à partir du réseau local sur lequel se trouve effectivement le PDC, la modification sera directement apportée sur la base SAM du PDC.

Si l’administrateur se trouve sur une autre branche réseau, la modification sera mémorisée dans un ’delta file’ sur le BDC local. Le BDC envoi ensuite un évènement au PDC pour amorcer la synchronisation de la base SAM. C’est le PDC qui fait alors la demande de ’delta file’ au BDC et applique la modification à la base SAM maître. Ensuite le PDC envoi un évènement aux BDC pour
qu’ils appliquent la modification dans leur propre base SAM.

Samba 3 ne peut pas participer à une véritable réplication SAM et il n’est également pas capable d’employer le même protocole utilisé par Windows NT4. Un BDC Samba 3 ne peut pas créer de ’delta file’. Il ne peut pas interagir avec un PDC ( NT4.0 ou Samba ) dans ce sens.

Samba 3 ne peut pas fonctionner comme BDC pour un serveur PDC NT4.0

Samba 3 ne peut pas fonctionner comme PDC avec un serveur BDC NT4.0

Le BDC possède une base SAM en ’lecture seule’ sur laquelle il est capable d’effectuer des demande de logon réseau et d’authentification des utilisateurs. Le BDC peut continuer à fournir ces services particulièrement si la liaison avec le PDC est coupée.

Dans l’éventualité où le PDC NT4.0 est stoppé, un des BDC NT4.0 peut prendre le rôle de PDC. Si cela se produit alors que le PDC NT4.0 est ’en ligne’, celui ci est automatiquement rétrogradé en BDC.
Il est à noté que Samba 3 ne peut être promus de cette manière car cela nécessite la modification du fichier smb.conf. Mais il est assez facile de modifier manuellement ce fichier et de redémarrer les services samba.

Qu’est ce qui qualifie un contrôleur de domaine sur le réseau ?

Chaque machine qui est Contrôleur de Domaine , pour le domaine DOMAINE par exemple, enregistre le nom de groupe DOMAINE<1C>, sur le serveur Wins, ou par broadcast sur le réseau local. Le PDC,
enregistre le nom unique DOMAINE<1B> . Le nom de type <1B> est normalement réservé au Maître Explorateur du Domaine (Domain Master Browser : DMB) , qui n’a rien à voir avec  l’authentification, mais l’implémentation Microsoft nécessite que le DMB soit actif sur le PDC.

Comment les stations trouvent elles un contrôleur de domaine ?

Une station Windows NT4.0/2000/XP qui veut authentifier un utilisateur sur le domaine DOMAINE, doit trouver le contrôleur du domaine DOMAINE. Elle effectue sur le réseau, une demande de noms NetBios pour le groupe DOMAINE<1C>. Le DMB répond en renvoyant les noms des DC = PDC + BDCs.

A l’issue, la station envoi les informations de connexion au DC sélectionné. A priori , rien n’indique que le DC sélectionné sera le PDC ( celui qui répond le premier ? )

Etude de cas

Réplication LDAP

Samba 3 est configuré pour utiliser un ’backend LDAP’ comme base des comptes utilisateurs. Ce ’backend’ LDAP peut être indifféremment un serveur LDAP maître ou un serveur LDAP esclave. De ce fait, si le serveur LDAP maître ne répond plus, les utilisateurs peuvent s’authentifier à travers Samba sur le serveur esclave.

Dans cette configuration ( qui est en aucun cas celle d’un BDC ). Seul le service LDAP est protégé. Du coté Samba, l’authentification des clients se fait sur l’un ou l’autre des serveurs LDAP. Coté Linux,
l’identification est configurée par nsswitch sur les 2 serveurs LDAP et l’authentification des applications utilise le PAM de samba.

Si le service Samba tombe, aucune authentification Samba n’est possible sur le réseau. Seules les identification Linux fonctionnent via Ldap. Enfin, si le serveur hébergeant le PDC est stoppé, il y aura interruption total des services. La description de la mise en oeuvre de la réplication LDAP est fournie dans un autre document. Elle est nécessaire pour la construction d’un BDC.

Utilisation d’un LDAP Maître et Esclave pour configurer un BDC

Si on construit un LDAP maître et esclave, il est recommandé d’utiliser le maître pour le PDC et l’esclave pour les BDCs. Il n’est théoriquement pas nécessaire de disposer d’un LDAP esclave, mais dans ce cas, la sécurisation des services ne sera pas assurée.

Les BDC peuvent utiliser le même serveur esclave, il n’est pas nécessaire d’avoir un serveur esclave sur chaque BDC.

Les configurations possibles sont les suivantes :

PDC + BDC sur le même serveur LDAP

PDC -> LDAP maître

BDC – > LDAP esclave

PDC ->LDAP maître, LDAP esclave en secondaire

BDC ->LDAP maître, LDAP esclave en secondaire

PDC ->LDAP maître, LDAP esclave en secondaire

BDC ->LDAP esclave, LDAP maître en secondaire

Nous choisirons la dernière configuration, puisqu’elle est complète et qu’elle offre le plus de sécurité

NB : le répertoire des scripts de connexion n’est pas référencé par un chemin UNC. Il doit se trouver obligatoirement sur le serveur qui effectue l’authentification. Une réplication de ces fichiers est donc
nécessaire entre le PDC et les BDC.

Et les fichiers ?

Si , comme dans la majorité des cas, le PDC héberge également le serveur de fichier, l’arrêt de celui ci ne permettra pas de travailler sur les fichiers du serveur.

Comme les partages sont référencés par le nom du serveur, une duplication des fichiers vers le BDC ne les rendra pas pour autant disponibles. Il est donc possible d’installer un troisième serveur,
Membre du domaine, pour les partages et les profils errants.

Cette configuration peut paraître idyllique, mais en regardant de plus près et en prenant en compte le fait que les serveurs ont le même taux d’indisponibilité prévisible, il apparaît que la disponibilité des fichiers repose sur celle du serveur de fichier, qui n’est pas, à priori, meilleure que celle du PDC. A moins de disposer d’un quatrième serveur Membre du domaine, replica exact du premier ( à l’adresse IP près ), la solution à 3 serveurs n’a que peu d’intérêt. Dans ce contexte, nous étudierons la solution à 2 serveurs :

PDC + fichiers / BDC :

Configuration

La première chose à faire est de mettre en oeuvre la réplication LDAP. Pour ce faire se référer au document traitant de ce sujet.

Installer un PDC à l’aide de l’assistant de migration, sur le serveur BDC en donnant les mêmes paramètres ( domaine, racine ldap, mot de passe Manager ) sauf le nom du serveur. Ceci permet de
pré-configuer, samba, ldap, nsswitch et pam. Stopper Samba et configurer ensuite le LDAP esclave (utiliser le script replildap ).

Les informations utilisées dans cet exemple sont :

• DOMAINE : VETO
• NOM NetBios/@IP du PDC : CENTRAL/10.44.180.1
• NOM NetBios/@IP du BDC : SECOURS/10.44.180.6
• @IP du LDAP Maître : 10.44.180.1:389
• @IP du LDAP Esclave : 10.44.180.6:389
• Racine du LDAP : ou=ddsv44,ou=agriculture,o=gouv,c=fr
• Manager LDPA : cn=Manager,ou=ddsv44,ou=agriculture,o=gouv,c=fr

Configuration du PDC
Samba.

Configurer /etc/samba/smb.conf en tant que PDC.

Seuls les paramètres nécessaires du fichier /etc/samba/smb.conf sont décrit ici :

Nom du domaine ( VETO ) et non netbios du PDC ( CENTRAL )

Indique que l’authentification aura lieu au niveau ’utilisateurs’ sur le backend de ce serveur

Les paramètres les plus importants pour un PDC :

• local master = yes c’est un serveur qui participe aux élections du ’Maître explorateur’ sur le réseau local.
• domain master = yes il est également ’Maître explorateur’ principal du domaine : c’est ce qui indique qu’il est PDC.
• os level = 80 Son niveau pour participer aux élections.
• preferred master = yes Force une élection (et la remporte) au  démarrage de Samba.
• domain logons = yes Enfin, ce serveur est un DC (Contrôleur de Domaine).

NB : si vous avez des stations W95 ou WNT4 sur le réseau, celle ci sont configurées par défaut pour provoquer une élection au démarrage. Elles n’ont aucune chance de gagner l’élection, mais cela engendre du traffic réseau supplémentaire et inutile. Penser à configurer ces stations pour qu’elles ne provoquent pas d’élection ( cf le site de JC.BELLAMY )

Répertoire des profiles errants

Dans le cas où ce paramètre est présent, mais est vide, les chemins des profiles errants sera fourni par l’attribut sambaProfilePath de l’annuaire LDAP. Dans ce cas, vous êtes libre de choisir le chemin des profiles pour chaque utilisateurs.

Dans le cas où ce paramètre n’est pas présent, c’est sa valeur par défaut qui sera appliquée pour tous les utilisateurs ( \SERVEURProfilesUTILISATEUR )

La configuration des backends LDAP

On ajoute ici, à la suite du LDAP maître , l’adresse du serveur LDAP esclave, le tout entre guillemets.

Recharger le fichier smb.conf dans Samba :

>(PDC) service smb reload

Linux.

Nsswitch

La configuration de LDAP pour nsswitch se fait dans le fichier /etc/ldap.conf

Indiquer l’adresse IP du serveur LDAP esclave à la suite de l’adresse IP locale ( serveur maître ). De cette manière, en cas d’indisponibilité du serveur maître les information d’identifications ( users, groups ) seront récupérées sur le serveur esclave

vérifier les paramètres nss :

La racine de l’annuaire

La version du protocole

La profondeur de rechercheLes bases de recherche

La crypto SSL à off

Le fichier de configuration de nsswitch est /etc/nsswitch.conf.

Le PDC est déjà configuré pour ldap , vérifier les lignes suivantes :

P.A.M

Le PDC est configuré pour que les services d’authentification utilise le pam_smbpass ( PAM Samba ), cela signifie que les services configurés pour utiliser le pam system-auth, feront leur authentification via Samba. Vérifier le fichier /etc/pam.d/system-auth

Vérification

A ce niveau, le PDC est configuré de la manière suivante :

Stopper LDAP sur le maître :

>(PDC) service ldap stop

Vérifier NSSWITCH :

>(PDC) getent passwd

Vous devez voir la liste des utilisateurs de votre domaine NT avec le LDAP maître stoppé. Les informations sont issues du LDAP esclave.

Vérifier PAM

Ouvrir une nouvelle session Linux sur le serveur PDC avec un utilisateur SAMBA :

Vous devez pouvoir vous connecter avec le LDAP maître stoppé. Les informations d’authentification sont issues du LDAP esclave.

Vérifier SAMBA

Essayer de vous connecter au domaine à partir d’une station Windows ,d’accéder à des partages Samba, , etc …

Essayer de changer votre mot de passe Windows à partir de Windows : Vous devez avoir un message d’erreur : « Vous n’êtes pas autorisé à changer votre mot de passe ». Cela est normal, car le LDAP maître est stoppé.

Rédémarrer LDAP

>(PDC) service ldap start

Essayez de changer de nouveau votre mot de passe. Cela doit fonctionner

Configuration du BDC

Samba

Stopper samba :

> ( BDC ) service smb stop

Configuration du fichier /etc/smb/smb.conf

Nom du domaine ( VETO ) et nom netbios du serveur ( SECOURS )

• workgroup = VETO
• netbios name = SECOURS

Identification au niveau des utilisateurs

• security = users

Les paramètres les plus importants pour un BDC

local master = yes c’est un serveur qui participe aux élections du ’Maître explorateur’ sur le réseau local. D’autant plus vrai si le BDC est sur un autre réseau que le PDC.

domain master = no il n’est pas ’Maître explorateur’ principal du domaine, donc ce n’est pas un PDC

os level = 60 Son niveau pour participer aux élections.

preferred master = no On ne force pas d’élection pour ce serveur.
domain logons = yes Enfin, ce serveur est un DC ( Contrôleur de Domaine ).

Les paramètres de configuration des backends LDAP :

On indique ici, le serveur LDAP maître en serveur LDAP de secours, le tout entre guillemets.

Ne redémarrer pas samba tout de suite.

Enregistrer le mot de passe du Manager LDAP dans Samba.

Ceci est nécessaire, même si la base LDAP principale est une base esclave. Les demandes de
modifications seront retransmise au maître si celui ci est en fonction. Par exemple dans la cas ou seul
le service ’samba’ du PDC est stoppé, alors que le LDAP maître fonctionne. ( garder à l’esprit que le
LDAP maître n’est pas forcément sur le même serveur que le PDC ) :

>( BDC ) smbpasswd -w

Joindre le BDC au domaine

>( BDC ) net rpc join -U Administrateur%

Utiliser un compte Administrateur du domaine, pour joindre le domaine. Les informations ’nom du
serveur’ et ’domaine à joindre’ sont issues du fichier smb.conf :

• joined domaine VETO

Vérifier, avec SRVMGR sur Windows, que le serveur à bien été inséré au domaine en tant que BDC :

Récupérer le SID du domaine : ce SID sera nécessaire pour la configuration des samba-tools :

>( BDC ) net rpc getsid

Storing SID S-1-5-21-1025534366-1344361479-xxxxx for Domain VETO in
secrets.tdb

Linux

Pour la configuration de nsswitch et de pam, la seule modification à effectuer est dans le fichier
/etc/ldap.conf :

Les autres informations sont identiques à celle du PDC. Vérifier quand même, notamment la racine du LDAP, si vous l’avez modifiée.

Il s’agit d’ajouter l’adresse IP du serveur LDAP secondaire ( ici se serra le maître )..

Samba-tools

Les samba-tools sont des outils nécessaires pour créer des utilisateurs ou des groupes POSIX dans le LDAP quand modifie avec une interface telle que USRMGR.

Les samba-tools ont dû être installést, il faut modifier le SID du domaine pour le faire correspondre à celui du PDC :

C’est le fichier /etc/samba/smbldap_conf.pm :

• indiquer ici le SID du domaine retourné par la commande : net rpc getsid

• garder ces informations :

Ce sont des notions propres à IDEALX, qui n’ont pas de correspondances avec un BDC.

• Vérifier le suffixe LDAP

• Et le mot de passe du Manager

Réplication des scripts de connexions

Avant de redémarrer samba, il faut répliquer les scripts de logon sur le BDC . Vous pouvez le faire manuellement , mais dans ce cas il faudra le faire à chaque modification sur le PDC.

Nous utiliserons ’rsync’ pour synchroniser les logon du BDC avec ceux du PDC.

La commande rsync avec ssh

Rsync est une commande qui permet de copier des fichiers d’un serveur à l’autre en ne transférant que les modifications. Elle peut donc être appliquée à intervalle régulier et rapide sans engendrer de traffic réseau.

Sur la distribution, rsync utilise SSH. C’est à dire qu’une communication cryptée est établie entre les 2 serveurs. Cette communication nécessite le mot de passe du compte sur le serveur distant ou alors utilise un mécanisme de clé privée – clé publique pour initialiser la communication.

Comme nous ferons exécuter la commande ’rsync’ par ’cron’, il n’est pas question de saisir le mot de passe à chaque fois. Nous utiliserons donc les clés. Le compte utilisé sera celui de root pour la copie, il faut donc établir une paire de clés pour le compte root du PDC et fournir la clé publique au compte root du BDC.

 

• Nous utiliserons les noms des clés par défaut, ce qui permettra d’avoir un accès ’root’ sur le BDC en permanence.avec ssh, scp

Création et initialisation des clés

• Sur le PDC, loggué root

Installer ssh-client ( urpmi ssh-client )

Créer le répertoire /root/.ssh, si celui ci n’existe pas déjà

>( PDC ) cd /root/.ssh

Créer la paire de clé :

>( PDC ) ssh-keygen -t dsa

saisir pour le nom du fichier ( garder id_dsa par défaut )

saisir pour la passphrase ( pas de passphrase )

A l’issue, un fichier id_dsa est créé pour la clé privé et un fichier id_dsa.pub pour la clé publique.

Copier la clé publique sur le serveur BDC ( utiliser scp )

• (PDC) scp id_dsa.pub root@10.44.180.6:id_dsa.pub

Le mot de passe root du serveur BDC vous sera demandé pour la copie.

• Sur le BDC, loggué root

Vérifier que la clé publique se trouve bien dans /root

Créer un répertoire /root/.ssh , si celui ce n’existe pas.

Ajouter la clé publique au fichier /root/.ssh/authorized_keys

• (PDC) cat id_dsa.pub >> .ssh/authorized_keys

Vérification

Sur le PDC essayer de copier le répertoire des scripts de connexion avec rsync.
Aucun mot de passe ne doit vous être demandé.

(ici le répertoire des NETLOGON est sur /smb/share_NETLOGON). Les options ’a’ permettent de conserver les attributs, et l’option ’z’ compresse les fichiers.

>( PDC ) rsync -azv /smb/share_NETLOGON 10.44.180.6 :/smb

Vous pouvez supprimer le fichier /root/id_dsa.pub du BDC, il ne sert plus à rien.

Planification

Il s’agit de d’effectuer la synchronisation une fois par heure par exemple :

>( PDC ) crontab -e -u root

Ajouter la ligne suivante :

0 * * * * rsync -az rsync /smb/share_NETLOGON 10.44.180.6 :/smb.

Ajouter ou modifier un fichier dans le répertoire des netlogon, sur le PDC, et vérifier à l’heure suivante sur le BDC.

Configuration du BDC :

Il faut que le partage NETLOGON pointe vers le répertoire /smb/share_NETLOGON

Vous pouvez à présent lancer votre BDC Samba :

>( BDC ) service smb start