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...
Voici l'architecture à laquelle nous allons aboutir après avoir mis en place 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...
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 !