7. Mise en place d'un BDC (Serveur 3, bdc.martymac.com)

La mise en place d'un BDC dans notre réseau va permettre de séparer la fonction d'authentification de celle du partage de fichiers. Nous allons pouvoir ajouter sur notre domaine la gestion des répertoires "homes" et "profiles" des utilisateurs, habituellement situés sur le PDC. Cette décentralisation permet de supprimer les points sensibles sur notre réseau et de limiter les goulets d'étranglement.

Comme vous avez pu le constater, le partage netlogon est inséparable du PDC (il est impossible de passer un chemin UNC au niveau du fichier smb.conf ou de l'annuaire LDAP) ; la même restriction existe au niveau de Windows NT4... nous le laisserons donc sur celui-ci, ce qui ne pose pas de problème majeur : seuls les scripts ne seront pas accessibles en cas de panne du PDC.

Note : Pour remédier à cela, plusieurs solutions pourraient être envisagées (que l'on ne va pas mettre en oeuvre car leur intérêt n'est pas primordial) : avoir deux partages netlogon : sur le BDC et le PDC, et monter, via NFS par exemple, les scripts du BDC sur le PDC ; seconde solution : avoir deux partages netlogon : sur le BDC et le PDC, et synchroniser les scripts via rsync ou rcp entre le PDC et le BDC...

7.1. Processus de montage du répertoire Home d'un utilisateur

Voici l'architecture à laquelle nous allons aboutir après avoir mis en place notre BDC.


Le BDC assure le partage des fichiers de l'utilisateur


1 : L'utilisateur demande l'authentification sur le domaine auprès du PDC
2 : Le PDC se connecte au serveur LDAP pour vérifier la validité du compte utilisateur
[2 bis] : Le BDC (si le PDC est en panne) se connecte au serveur LDAP pour vérifier la validité du compte utilisateur
3 : L'annuaire LDAP répond au PDC
[3 bis] : L'annuaire LDAP répond au BDC (si le PDC est en panne)
4 : Il autorise (ou non) l'utilisateur à accéder aux ressources du domaine
5 : Si l'utilisateur est autentifié, il peut accéder au BDC, et demander l'accès à une ressource (son répertoire Home)
6 : Le BDC lui fournit cet accès

7.2. Configurons notre BDC

La configuration du BDC se fait de la même manière que celle du PDC, à la différence des options d'élections présentes dans le fichier smb.conf qu'il faut modifier (baisser) et les partages qui seront différents. Le BDC doit, lui aussi, disposer d'un nsswitch modifié, ainsi que de la librairie libnss-ldap (et éventuellement libpam-ldap). Il faudra également installer la base ldap-client et les smbldap-tools.

Notre BDC a pour nom netbios MARTYMAC-BDC, voici sa configuration samba (/etc/samba/smb.conf) :

[global]
   ; le nom de notre domaine
   workgroup = MARTYMAC
   ; notre nom de machine netbios
   netbios name = MARTYMAC-BDC
   ; le nom complet
   server string = Martymac BDC Server
   encrypt passwords = Yes

   ; Synchro pass Unix
   passwd program = /usr/local/sbin/smbldap-passwd.pl -o %u
   passwd chat = *new*password* %n\n *new*password* %n\n *successfully*
   unix password sync = Yes

   ;  Ajout de machine via smbldap-tools
   add user script = /usr/local/sbin/smbldap-useradd.pl -w %u
   domain admin group = " @"Domain Admins" "

   ; Logs
   log file = /var/log/samba/%m.log
   log level = 2
   max log size = 5000

   ; Quelques options réseau
   socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

   ; On contrôle les logons, on est DC
   domain logons = Yes
   ; Master browser, browser pour le domaine (un seul par domaine)
   domain master = No
   ; Force élections en tant que master browser + donne un avantage
   preferred master = No
   ; Poids lors des élections de master browser
   os level = 48
   ; Local master browser (browser pour le sous réseau)
   local master = No

   dns proxy = No
   ; Serveur Wins actif (un seul par reseau)
   wins support = No

   security = user

   ; LDAP
   ldap suffix = dc=martymac,dc=com
   ldap admin dn = cn=Manager,dc=martymac,dc=com
   ldap port = 389
   ldap server = ldap1.martymac.com
   ldap ssl = No

   ; Impression
   load printers = yes
   printing = cups
   printcap name = cups

   ; Prise en charge du francais
   character set = iso8859-1

; Répertoires homes, à mapper via \\SERVEUR\utilisateur
[homes]
   path=/export/samba/home/%u
   comment = Home Directories
   valid users = %S
   read only = No
   create mask = 0664
   directory mask = 0775
   browseable = No

; Répertoires profiles, à mapper via \\SERVEUR\profiles\utilisateur
[profiles]
   path = /export/samba/profiles
   writeable = yes
   browseable = no
   create mode = 0644
   directory mode = 0755
   guest ok = yes

[tmp]
   comment = Temporary file space
   path = /tmp
   read only = No
   guest ok = Yes

Le BDC offre désormais les partages auparavant assurés par le PDC. Il va donc falloir y créer les répertoires partagés génériques, (ici /export/samba/home et /export/samba/profiles), ainsi que le répertoire home de chaque utilisateur :

Exemple pour l'utilisateur 'utilisateur' :
- mkdir /export/samba/home/utilisateur
- chown utilisateur:Users /export/samba/home/utilisateur
- chmod 755 /export/samba/home/utilisateur
Il faut aussi régler les droits du répertoire profiles de la même manière que pour le PDC :
- chown :Users /export/samba/profiles
- chmod 775 /export/samba/profiles
Enfin, il faut modifier le chemin des répertoires 'home' et 'profile' de notre utilisateur au sein de LDAP. Nous allons indiquer ceux que l'on vient de partager :
- smbldap-usermod.pl -C \\\\MARTYMAC-BDC\\utilisateur -F \\\\MARTYMAC-BDC\\profiles\\utilisateur utilisateur
Ainsi,notre utilisateur y aura enfin accès.

Ne pas oublier d'initialiser le password samba LDAP :
- smbpasswd -w secret

Enfin, il ne faut pas oublier de synchroniser le SID du BDC avec celui du PDC. Le SID sera stocké dans le fichier secrets.tdb, le même qui stocke le mot de passe LDAP. Sur le BDC (le PDC doit être joignable) :
- smbpasswd -S -r MARTYMAC-PDC

Voilà, si on démarre le PDC et le BDC, la station s'authentifiera sur le PDC et montera les partages du BDC. Si le PDC tombe en panne, la station devrait s'authentifier sur le BDC. Effectuons quelques tests pour confirmer ceci...

7.3. Test : le BDC prend-il correctement le relai en cas de panne du PDC ?

Nous allons effectuer ces tests avec un client Windows XP, appelé XP-CLIENT.

Le problème majeur pour tester la validité de notre configuration est que notre machine Windows peut authentifier elle-même un utilisateur s'il s'est déjà connecté sur le domaine à partir de celle-ci. Pour être plus clair, voici un exemple : on crée un utilisateur sous LDAP, le PDC et le BDC sont en marche. Si on se "log" à partir de notre station Windows, tout fonctionne normalement. Eteignons maintenant le PDC et le BDC. Normalement, nous n'avons plus de DC pour nous authentifier sur le domaine... Cependant, notre station va quand même le faire : elle a gardé l'utilisateur en cache.

Ceci offre un avantage : si le PDC et le BDC tombent en panne en même temps sur un réseau (peu probable), nous avons quand même la possibilité d'utiliser la station. L'inconvénient est que des problèmes de sécurité peuvent se poser... Quels sont-ils ? Tout simplement la non-concordance des bases d'utilisateurs. Imaginons qu'un utilisateur soit supprimé de la base LDAP après que le PDC et le BDC soient tombés en panne, l'utilisateur peut toujours se connecter à la station tandis qu'il a normalement été rayé de la liste des utilisateurs valides !

Testons un peu notre configuration...

- PDC et BDC démarrés
- Création d'un utilisateur sous LDAP
- On peut se connecter avec l'utilisateur, on dispose des scripts netlogon (ceci est normal, ils sont sur le PDC)
- Extinction du PDC
- On peut toujours se connecter avec l'utilisateur, on ne dispose plus des scripts netlogon (ceci est normal, il n'y en a pas sur le BDC)

Problème : a-t-on bien été identifiés pas le BDC ? Ne serait-ce pas la machine Windows qui l'aurait fait (car si on éteint le BDC, on observe ici le même résultat) ?

- Supprimons l'utilisateur sous LDAP
- On ne peut plus se connecter avec l'utilisateur... C'est bien le BDC qui nous a authentifié

Si cela n'est pas le cas, c'est que c'est votre machine Windows qui vous a authentifié, on en revient au problème cité ci-dessus : elle n'est pas synchronisée avec LDAP et ne sait donc pas que l'utilisateur a été supprimé. Par contre, le BDC, lui, interroge constamment l'annuaire, donc si votre machine passe par lui pour l'authentification, vous êtes refusé, ce qui se passe ici.

La suppression d'un utilisateur permet de manière flagrante de savoir si la machine Windows fait appel ou non à un contrôleur de domaine pour s'authentifier. Dès qu'un contôleur de domaine est en marche, tous les problèmes d'incohérence concernant les utilisateurs disparaissent. Si on les éteint puis que l'on supprime ou que l'on ajoute des utilisateurs, la machine reste autonome et conserve ses anciennes données pour l'authentification. D'où une impossibilité de se connecter alors qu'un utilisateur existe et inversement.

Le BDC a bien pris le relai du PDC tombé en panne... Mais lors de la reprise de celui-ci, que se passe-t-il ?

- Le PDC est toujours éteint et le BDC allumé
- Création d'un utilisateur sous LDAP
- On peut se connecter avec l'utilisateur, mais pas de scripts netlogon (ce qui correspond bien à notre BDC)
- Démarrage du PDC
- On peut se connecter avec l'utilisateur, avec scripts netlogon, le PDC a bien pris le dessus sur notre BDC

La présence ou non de scripts netlogon nous permet de savoir ici quel est le DC qui nous a authentifié. Ceci est valable dans notre cas car seul le PDC possède le partage netlogon...

En cas de panique, si rien ne fonctionne, n'oubliez pas que les logs sont une source d'information très importante (d'après notre configuration dans /var/log/samba), n'hésitez pas à les consulter ! Les tests que je vous présente ici permettent de se faire rapidement une idée de ce qui se passe mais ne remplacent pas les informations détaillées contenues dans ces précieux fichiers !!!

Pensez également à vous assurer que les SID de domaines sont bien synchronisés entre le PDC et le BDC avec la commande smbpasswd -S -r MARTYMAC-PDC (à exécuter sur le BDC), si ce n'est pas le cas, vous risquez de vous arracher les cheveux, le BDC refusant de prendre le relai du PDC, mais recevant quand même la demande de la machine Windows... attendez vous à des heures de recherche !