Catégories
Documents techniques

Data serveur Linux et Contrôleur de données Windows 2000

Comment faire cohabiter un serveur de données fonctionnant sous RedHat avec Samba et un contrôleur de données fonctionnant sous Windows 2000 avec Active Directory.

Comment faire cohabiter un serveur de données fonctionnant sous RedHat avec Samba et un contrôleur de données fonctionnant sous Windows 2000 avec Active Directory.

L’étude de cas si après à été réalisée avec les matériels suivants:

  • Windows 2000 serveur sp4 avec Active Directory en mode natif.
  • RedHat Entreprise Server 3 et Samba > 3.0.9

1 – Introduction

1.1 – La problématique

Il existe, architecturé en domaine autour d’un serveur Windows 2000 ou 2003 supportant une base Active Directory native. On veut ajouter à ce réseau un serveur dont le but est d’accueiller et de gérer la sauvegarde des données du réseau. Pour des raison de coût ou de savoir faire disponible, on désire que le serveur fonctionne sous Linux.

Contrairement à certains préjugés, il est tout a fait possible que ce serveur de données gérent l’authentification des utilisateurs à travers l’Active Directory comme s’il s’agissait d’un second serveur Windows, condition d’utiliser les bon outils et de bien prévoir – au préalable – le schéma de fonctionnement de cette architecture.

1.2 – Les pré-requis

Du côté de Windows…

Le contrôleur de donnée doit utiliser Active Directory en mode natif, c’est à dire que ce type d’installation ne peut fonctionner avec un Active Directory en mode mixte ou une base SAM type Windows NT4. Dans ce dernier cas de figure il existe d’autre possibilités.

… et de Linux

Vous aurez besoin des outils suivants:

  • Samba en version 3 ou supérieure avec son module de gestion des ACL
  • Un serveur WINS et/ou DNS actif sur le réseau
  • WinBind
  • Les protocoles d’identifiaction Kerberos actifs
  • Un noyau GNU/Linux compatible XFS

Tout ceci est possible quelque soit la version de Linux utilisée, une installation par défaut de RedHat Entreprise Server 3 (ou supérieur) dispose de tout celà.

2 – Déporter l’autentification vers Active Directory

2.1 – Authentifier le serveur Linux sur l’Active Directory

Avant toute autre chose, il faut déclarer le serveur Linux comme membre du domaine windows et créer son compte machine dans l’Active Directory, ce qui se fait tout simplement avec la commande suivante:

$ net ads join -Ulogin%password

Où vous avez remplacé login et password par les identifiant d’un utilisateur ayant le droit de rajouter des machines sur l’Active Directory.

2.2 – Adapter Samba

La première étape consiste à indiquer à Samba comment référer l’identification des utilisateurs sur Active Directory, pour se faire il suffit de modifier le fichier de configuration en y ajoutant le bloc ci-dessous:

[global]
# Option de sécurité utilisateur
# Type de sécurité: Active Directory Services
security = ADS
# Adresse ou nom netbios du contrôleur de domaine
password server = 192.168.1.202
# On crype les mots de passe pour plus de sécurité
encrypt passwords = yes
# Enfin, on indique le "royaume" Kerberos
realm = LR.CA17INT.NET

Le nom du « royaume » Kerberos correspond au nom complet du domaine avec ses attributs DNS. Attention toutefois, il est indispensable de l’indiquer en majuscule si l’on veut que cela fonctionne bien, on le retrouve dans l’Active Directory en tant que suffixes des logins d’utilisateurs comme dans la capture ci-dessous.

2.3 – Le résultat…

Relancez Samba:

$ service smb restart

Pour l’instant vous n’avez encore rien fait si ce n’est que votre serveur Linux et maintenant considéré par le contrôleur de domaine comme un membre du dit domaine. Il est donc maintenant théoriquement possible de s’appuyer sur le contrôleur de domaine pour gérer les accés de la machine locale à peu près de la même manière que le ferait un poste client windows. Cependant, il est nécessaire de mettre en service un second service pour que Samba soit à même de récupérer la liste des utilisateurs enregistrés dans l’active directory, c’est le rôle de WinBind.

3 – Récupérer les comptes de l’Active Directory

3.1 – Configurer et lancer WinBind

L’intéret de WinBind est de connecter la base des utilistateurs de samba à celle stockée dans l’Active Directory. Il faut alors, dans NSSwitch qui gére la base des utilisateur du serveur Linux sur des fichiers ou des bases de donnée locales, indiquer l’utilitaire winbind qui lui gère la transision avec Active Directory.

# /etrc/nsswitch.conf
# Partie concernant la gestion des comptes
passwd: files winbind
shadow: files
groups: files winbind
#...

Une fois NSSwitch prêt, vous pouvez lancer le démon WinBind.

$ /usr/sbin/winbindd

Il reste alors à exploiter les utilisateurs de l’Active Directory avec Samba.

3.2 – Activer winbind dans Samba

Le grand intéret de la manipulation précédente et surtout de récupérer les utilisateurs de l’Active Directory pour gérer les droit d’accés au partage, pour se faire il faut utiliser l’utilitaire WinBind. On retourne donc dans le fichier de configuration de Samba pour ajouter, dans les variables globales, l’activation de ces services.

# Définition du séparateur entre domaine et nom d'utilisateur
winbind separator = .
# Récupération des identificateur de groupes et d'utilisateurs
idmap uid = 10000-20000
idmap gid = 10000-20000
# Autoriser l'énumération des groupes et des utilisateurs
winbind enum users = yes
winbind enum groups = yes

Généralement, sous windows, le séparateur entre domaine et nom d’utilisateur et l’anti-slash « \ » mais l’utilisation de ce paramétre peut poser problème dans Samba (testez avec testparm) car il peut être interprété comme un saut de ligne. Le point « . » est un bon ersatz.

Puis relancez Samba pour prendre en compte toutes ces modifications.

$ service smb restart

3.2 – Lancer winbind au démarrage et connaître ses outil

Pour que tout cela fonctionne bien il est évidement indispensable que WinBind soit lancé au démarrage tout comme Samba et NSSwitch le sont par défaut. Pour ajouter un service cela se fait par l’utilitaire redhat-config-service qui dispose aussi d’une interface graphique:

Je vous laisse trouver par vous même comment cela fonctionne que vous consultiez le « man » ou que vous cliquiez partout, ce n’est pas vraiment compliqué.

La commande wbinfo permet de récupérer des informations sur ce que fourni WinBind. Par exemple, wbinfo -u liste les utilisateurs connnu et wbinfo -g les groupes.

$ wbinfo -u
CA17INT.Administrateur
CA17INT.Comptable
CA17INT.MarcelDupont
CA17INT.PDG

3.3 – Etat des lieux

Et voilà la partie du travail la plus complexe est faite, voilà, en gros, ce qui se passe:

  1. Grâce à Samba le serveur Linux fait partie du domaine Windows
  2. NSSwitch liste les utilisateur locaux ainsi que ceux reconnus par WinBind
  3. WindBind fait le lien avec les utilisateurs connus dans Active Directory
  4. Samba est capable de gérer toutes les utilisateurs du domaine

Vous pouvez maintenant configurer vous partages Samba de la manière habituelle en y integrant les nom noms et les partages reconnu par votre contrôleur de domaine Windows 2000 comme dans l’exemple ci-dessous:

# Soit un partage pour la comptabilité...
[Comptabilité]
comment = Compta sur le serveur Linux
path = /var/partages/comptabilite
# Le dossier n'est pas public
public = no
# Mais est accessible par l'équipe de comptable
# et M. de Directeur
valid users = @C A17INT.Compta CA17INT.PDG
# etc. en fonction des besoins
writeable = yes
create mode = 0640

4 – Une petite note sur « Droits Unix & ACLs »

Les ALCs ne supplantent jamais les droits Unix, par conséquent il faut gérer les deux pour mener à bien sa politique de gestion de partages sur le serveur.

Une des astuce consiste à créer un utilisateur local, qui n’a accés à la console du serveur, que l’on nomme propriétaire des dossiers. Ensuite, avec un jeu de create user, force user et compagnie on distribue des droits Unix qui, concernant un utilisateur non reconnu pas le serveur Windows, ne peuvent entrer en interféce avec les ACLs

Il ne vous reste plus qu’à tester… et bon courage.

Une réponse sur « Data serveur Linux et Contrôleur de données Windows 2000 »

Moi tout marche bien jusqu’au 3.2, en effet la commande wbinfo -u me renvoi "error looking up domain users" alors que la commande wbinfo -g fonctionne. Quelqu’un pourrait-il me dépanner svp??

Les commentaires sont fermés.