Samba Etude de la version 2, Introduction à la version 3.

Transcription

1 EDF R&D D ÉP A R T E M E N T S IN ETIC S G R O U P E IN F R AS T R U C T U R E S D E C O M M U N IC A T IO N ET S E C U R IT E 1, AV E N U E D U GÉN É R A L D E GAU LLE F C LA M A R T C ED E X T EL : F AX : Janvier 2004 GANAËL LAPLANCHE (GENESTA), DAVID LACOSTE (EDF R&D) Samba Etude de la version 2, Introduction à la version 3. V1.1 Licence de ce document : Copyright (c) , EDF Work by Ganaël Laplanche at EDF R&D's Clamart research center. Author's website : ganael.laplanche@martymac.com. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Accessibilité : Selon licence ci-dessus EDF 2004 Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

2 Table des matières 1) Introduction...3 2) Samba, première approche...3 a) Présentation...3 b) Historique c) Notions techniques...4 3) Les domaines...4 a) Qu'est-ce qu'un domaine?...4 b) Exemple de domaine...5 4) L'administration de Samba...6 a) Configuration générale du serveur...6 b) Authentification - gestion des utilisateurs...7 c) Outils à notre disposition...7 5) Samba v2, ses atouts et ses limites...8 a) Introduction...8 b) Atouts de Samba 2.2.8a...8 c) Etude des besoins...8 d) Fonctionnalités - Limites...9 1) Stockage des utilisateurs...9 2) Gestion des groupes ) Architectures supportées ) Code monolithique ) Nouveautés apportées par la v a) Nouveaux backends...11 b) Modules VFS multiples...11 c) Mapping de groupes...11 d) Approbations de domaines...12 e) La commande Net...12 f) Outils de migration...12 g) Support d'active Directory...13 h) Support de l'unicode, gestion des ACLs, NTLM v ) Tests et résultats...13 a) Contexte des tests...13 b) Résultats ) Le Group mapping ) Les ACLs ) La Migration ) Les groupes de groupes ) Les groupes multiples ) Samba en tant que BDC ) Les Stratégies utilisateurs ) Active Directory ) Les interfaces d'administration ) Conclusion ) Glossaire ) Liens - bibliographie ) Remerciements...18 GNU Free Documentation License...19 Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

3 1) Introduction Ce document est issu de la seconde partie de mon stage de fin d'études effectué à EDF R&D à Clamart. La première partie m'avait permi d'aborder Samba en théorie, puis en pratique en proposant et testant des architectures de domaines utilisant LDAP comme media de stockage d'utilisateurs. Nous allons dans un premier temps présenter Samba, puis, dans un second, étudier les limites de l'ancienne version - la version et les nouveautés offertes par la version 3. Nous verrons en quoi ces nouvelles fonctionnalités peuvent intéresser une entreprise désireuse de migrer ses serveurs, puis les limites imposées par cette solution. Ce document se veut abordable et doit permettre à un néophyte de découvrir Samba de manière simple tout en ayant une vision globale de ses fonctionnalités. Il peut permettre une bonne approche du produit avant son utilisation concrète. 2) Samba, première approche a) Présentation Samba est une suite de logiciels permettant d'interconnecter Windows et toutes sortes d'unix-like (*BSD, GNU/Linux, Solaris...) afin d'en partager les ressources. Ces ressources sont composées d'utilisateurs, de groupes, de machines et d'imprimantes. Une machine Unix pourra ainsi accéder à une machine ou un domaine Windows et inversement. Il est composé de trois logiciels serveurs : nmbd, smbd et winbindd. Chacun d'entre eux joue un rôle très précis dans l'interconnexion réseau des machines. Nmbd permet de gérer la résolution de noms netbios (port 137), smbd, le partage de fichiers (port 139), et winbindd la mise en commun des comptes Windows et Unix. Grâce à eux, Samba parvient à recréer un environnement Windows NT quasiment identique à l'original. Samba va ainsi permettre de contrôler un domaine, d'en être le serveur de sauvegarde, un serveur membre ou tout simplement de servir de serveur autonome (serveur de fichiers). Samba offre également tout un panel d'outils d'administration et d'utilitaires permettant d'accéder aux ressources d'une machines Windows. b) Historique 1 Le développement de Samba a débuté en décembre 1991 par un étudiant au laboratoire d'informatique à l'université nationale d'australie. Andrew Tridgell n'avait développé au départ qu'un programme permettant de monter des partages Windows sur sa machine Unix. Ce logiciel, véritable prouesse technique à l'époque, est devenu au fil des temps un ensemble complet d'outils portant le nom de Samba. Ce nom rappelle le protocole SMB, précurseur de CIFS, utilisé pour le partage de fichiers sous Windows. Actuellement, l'équipe de développement, la "Samba Team", comporte une trentaine de personnes. De plus, chacun peut contribuer au projet puisque Samba est un projet open source et libre, diffusé sous licence GPL v2. Dans sa douzième année, le projet en est à la version 2.2.8a (stable) et la version 3 est en cours de finalisation. 1 Liens : Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

4 c) Notions techniques Samba utilise le protocole CIFS, évolution de SMB, pour le partage de fichiers (port TCP 139 ou 445). Le modèle de noms de machines utilisé est celui fourni par NetBios : chaque machine dispose d'un nom de 15 caractètes + 1 caractère spécial désignant les services offerts sur le réseau. NetBios constitue la couche Session au sein du modèle OSI ; bien qu'il ne soit plus obligatoire avec les machines direct-hosted, notez qu'il est encore très souvent utilisé. NTLM, héritée de DCE/RPC, procure une méthode d'authentification single-sign-on sur le domaine : l'utilisateur s'authentifie une seule fois à sa connexion. N'hésitez pas à vous reporter au glossaire en fin de document pour plus d'explications concernant les termes employés. Modèle OSI et situation des protocoles utilisés par Samba 3) Les domaines a) Qu'est-ce qu'un domaine? Nous avons évoqué la notion de domaine. Etudions-là un peu plus en détails. Nous pourrions définir un domaine comme "un ensemble de machines interconnectées partageant la même politique de gestion et disposant de ressources communes". Plus concrètement, cela signifie qu'au sein de ce groupe d'ordinateurs va être partagé un ensemble d'utilisateurs, de groupes, de machines, et que chacun de ces acteurs pourra, ou non, suivant ses droits, accéder à d'autres éléments du domaine, qui sont pricipalement des fichiers et des imprimantes partagés. Il s'agit d'une unité administrative. Toute cette gestion est orchestrée par un ordinateur particulier que l'on appelle contrôleur de domaine (DC : Domain Controler). Son rôle est de fournir des informations sur chacun des acteurs du domaine ; il en maintient une liste et les autorise ou non à effectuer des actions particulières. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

5 Pour des raisons de disponibilité et de fiabilité, il existe généralement un contrôleur "principal" de domaine (PDC : Primary Domain Controler) et plusieurs contrôleurs secondaires (BDC : Backup Domain Controler) qui vont prendre le relai de ce dernier en cas de panne. Cette architecture est valable pour un domaine Windows NT. Windows 200x propose une achitecture radicalement différente, puisqu'il n'existe plus de notion de PDC et de BDC : chaque serveur est un DC. D'autres détails sont à noter comme l'utilisation de Kerberos pour le contrôle d'accès et le stockage des éléments de l'active Directory dans un serveur LDAP. Sous Windows 2000, les rôles sont donc partagés, plus que ce qu'ils ne l'étaient auparavant. L'approche de Samba, plus particulièrement de Samba 3, se situe au centre de cette évolution : si l'architecture NT semble vieillissante, sa simplicité de mise en oeuvre et son efficacité sont un atout majeur ; Active directory quant à lui présente une certaine flexibilité. Samba permet de bénéficier de ces deux atouts, à savoir décentraliser les rôles de manière simple et efficace, par le biais d'une architecture NT4. b) Exemple de domaine \\MONDOM_PDC\netlogon PDC BDC \\MONDOM_BDC\<utilisateur> \\MONDOM_BDC\profiles\<utilisateur> Autres : \\MONDOM_BDC\Commun Station 1 Station 2 Station 3 Station 4 Station 5 Exemple d'un domaine simple Samba : "MONDOM" Le domaine ci-dessus est un exemple très simplifié d'un domaine Samba imitant totalement l'architecture classique Windows NT : des stations de travail, un PDC et un BDC. Les stations de travail s'authentifient régulièrement sur le PDC et si celui tombe en panne, le BDC prend le relais. La base d'utilisateurs est située ici sur le PDC, qui comporte un partage netlogon afin de permettre aux utilisateurs d'accéder à leurs scripts de connexion et à leurs stratégies (policies). Le BDC, quant à lui, sert de backup, mais aussi de partage des répertoires homes et profiles des utilisateurs. Ces répertoires sont mappés dynamiquement vers le nom de l'utilisateur connecté. Enfin, nous avons ici un partage commun de fichiers. Ce type d'architecture est assez courante, car simple à mettre en oeuvre et facilement appréhendable (compréhensible). Le principale problème est qu'elle est également monolithique car la base d'utilisateurs est liée au mécanisme d'authentification, ce qui signifie que si celui-ci tombe en panne, la base est inaccessible. Samba apporte une solution à ce problème en externalisant la base d'utilisateurs et en déléguant leur stockage à un annuaire LDAP. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

6 4) L'administration de Samba L'administration se fait en deux temps : tout d'abord, le réglage du comportement de Samba, ensuite, la gestion des acteurs du domaine (utilisateurs, groupes, machines) si Samba est voué à contrôler un domaine. a) Configuration générale du serveur Un seul fichier permet de contrôler l'intégralité du comportement de Samba : il s'agit du fichier smb.conf. Il est divisé en plusieurs sections : la première, [global], permet de configurer les options générales du serveur. C'est dans cette section notamment que l'on définira le rôle de Samba : PDC, BDC ou autonome. Les suivantes permettent de gérer les partages. Certaines sections sont prédéfinies : [homes] et [printers] et servent respectivement à définir les répertoires des utilisateurs et les imprimantes partagées. Les autres sections représentent le nom du partage créé. Voici un exemple de fichier smb.conf : [global] ; Informations relatives au domaine workgroup = DOMAINE netbios name = DOMAINE_DC server string = PDC du domaine encrypt passwords = Yes ; On contrôle les logons, on est DC domain logons = Yes ; Master browser, browser pour le domaine (un seul par domaine) domain master = Yes ; Force élections en tant que master browser + donne un avantage preferred master = Yes ; Poids lors des élections de master browser os level = 65 ; Local master browser (browser pour le sous réseau) local master = Yes ; Serveur Wins wins support = Yes security = user ; Partage de scripts netlogon [netlogon] path = /export/samba/netlogon comment = Service Netlogon guest ok = Yes ; Répertoires homes des utilisateurs [homes] path=/export/samba/home/%u comment = Repertoires homes valid users = %S read only = No create mask = 0664 directory mask = 0775 browseable = No Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

7 ; Répertoire de stockage du profil itinérant des utilisateurs [profiles] path = /export/samba/profiles writeable = yes browseable = no create mode = 0644 directory mode = 0755 guest ok = yes Nous n'allons pas nous étendre sur les significations de chaque directive, l'objet de cet exemple étant d'avoir une approche globale du fonctionnement de Samba. Remarquez simplement ici que nous avons un seul contrôleur dans le domaine et qu'il offre lui-même tous les partages nécessaires aux utilisateurs. b) Authentification - gestion des utilisateurs Samba gère l'authentification des utilisateurs si son rôle est d'être un contrôleur de domaine. Il lui faut dans ce cas une base à laquelle se référer afin de déterminer les droits de chacun. Cette base est double. Samba utilise tout d'abord les mécanismes internes à Unix pour identifier (via nsswitch) et authentifier (généralement via pam) les utilisateurs. Un compte Unix est donc le préalable nécessaire à tout compte Samba. Cependant, sous Unix les informations relatives à chaque utilisateur sont très limitées : principalement un nom, un uid (User id), gid (Group id), et un répertoire home. Elles sont, de plus, non appropriées : en effet, Windows utilise un SID - identifiant relatif au domaine - afin d'identifier un acteur du domaine, tandis qu'unix utilise un "simple" uid, sans aucun rapport à un quelconque domaine. Pour pallier ces manques, Samba doit ajouter ses propres informations telles que le chemin du répertoire home de l'utilisateur (cette fois pouvant être distant : chemin UNC), son répertoire de profils, son SID,... Cet ajout d'informations constitue en quelques sortes une base SAM et nécessite un espace de stockage supplémentaire, souvent un fichier de base de données (tdb) stocké sur le PDC. Nous parlions précédemment d'un stockage sur un annuaire LDAP, nous y reviendrons. c) Outils à notre disposition Une fois Samba démarré, nous avons un panel d'outils assez étendu pour contrôler et administrer notre domaine, voici les commandes les plus utiles : Gestion des utilisateurs : - pdbedit : manipule la base de comptes utilisateurs. - smbpasswd : permet de modifier le mot de passe Samba d'un utilisateur (et d'ajouter/supprimer des comptes si exécuté en tant que root). - net (Samba 3) : réimplémente la commande net Windows et inclue des fonctionnalités propres à Samba. Permet de lister/modifier les comptes Samba à distance. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

8 Gestion du domaine : - findsmb : affiche des informations sur les partages disponibles sur le réseau IP. - nmblookup : résoud un nom netbios (NBT) vers son adresse IP. - smbstatus : affiche les connexions actuelles. - rpcclient : client RPC. Commande un serveur à distance. - smbclient : à l'instar de ftp, permet de se connecter à un partage de fichiers Windows. - smbmount : monte un répertoire partagé par Windows ou Samba sur la machine. Gestion de la configuration : - testparm : permet de tester la validité du fichier smb.conf. - swat : serveur web (port 10000) permettant de configurer Samba de manière graphique. 5) Samba v2, ses atouts et ses limites a) Introduction La "branche" 2 de Samba est en version stable depuis le 14 janvier Elle a apporté, à son époque, son lot de nouveautés dont notamment une meilleure gestion du contrôle de domaine et l'intégration de SWAT. La version 2.2 quant à elle offrait entre autres un meilleur support de l'impression et une meilleure comptabilité avec les clients Windows La dernière version 2 de Samba se nomme 2.2.8a et est actuellement préconisée dans un environnement de production, eu égard à sa "maturité". b) Atouts de Samba 2.2.8a Cette version est, à l'heure où ces lignes sont écrites, la plus stable de Samba. La version 3, imminente, se destine à la remplacer. Samba 2.2.8a propose une compatibilité excellente avec les domaines de type NT, et les clients de type NT/2000/9x. Windows XP pose parfois quelques problèmes de manière très aléatoire. L'étude de cette version et son utilisation dans la mise en place de domaines de tests (avec LDAP notamment) a constitué la première partie de mon stage. Elle s'est révélée très stable, cependant, nous avons déploré le manque de plusieurs fonctionnalités importantes, limitant ainsi les perspectives de son implémentation dans un environnement professionnel. L'idée de départ étant d'arriver à des possibilités quasiidentiques à un domaine NT, tout en se limitant aux besoins réels de l'entreprise. c) Etude des besoins L'étude des besoins fut la première étape à la mise en place des plateformes de tests. L'idée de départ était de se baser sur une architecture NT, mais d'essayer de s'affranchir (en théorie) de la notion de PDC et de BDC : chaque contrôleur de domaine doit être potentiellement capable d'authentifier un utilisateur et doit pouvoir accéder à la base les concernant. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

9 La base doit pouvoir être mise à jour en temps réel, même si l'authentification ne se fait plus par le PDC. Il faut donc séparer la fonction d'authentification de celle de stockage, ainsi que nous l'avons évoqué plus haut dans ce document. En cas de panne du service d'authentification, nous serions ainsi dans la capacité de continuer à modifier les données concernant les utilisateurs. Il doit également être possible de disposer les répertoires de données et profils des utilisateurs sur n'importe quel serveur membre du domaine, sans dépendre du contrôleur de domaine. Enfin, l'administration doit être abordable, dans l'esprit des outils Microsoft, et complète. L'idéal serait également de disposer d'outils de migration permettant de recycler les comptes Windows et de les réutiliser dans le nouveau domaine Samba. d) Fonctionnalités - Limites 1) Stockage des utilisateurs Dans la version 2.2, le stockage des utilisateurs peut se faire dans 4 types de containers : fichier smbpasswd, fichier tdb, LDAP ou NIS. Les fichiers smbpasswd et tdb sont des fichiers de bases de données, à plat. Historiquement, smbpasswd est apparu avant tdb et stocke moins de propriétés. L'inconvénient de ce type de stockage est qu'il est adapté pour un nombre limité d'enregistrements ; il peut convenir pour quelques dizaines d'utilisateurs, au sein d'une petite structure. Il n'offre qu'une faible capacité à monter en charge, et une lenteur considérable au delà. Ces limitations ont abouti, dans les dernières versions de Samba 2.2 à l'apparition de deux "backends" supplémentaires : LDAP et NIS. L'avantage principal de tels media est une compatibilité accrue avec les applications déjà existantes, telles que les applications d'administration. Il permettent aussi de réutiliser des annuaires déjà existants et offrent une capacité à la montée en charge plus importante que les fichiers à plat. Enfin, un avantage très important est qu'ils autorisent une granularité très fine au niveau des paramètres de chaque compte d'utilisateur. Un exemple est qu'il est possible de paramétrer pour chacun le répertoire de profils, alors que ceci se faisait de manière générique - par l'utilisation de variables dans le chemin du répertoire - avec un fichier à plat. Un serveur LDAP va également permettre de mettre en place un système de tolérance de pannes en utilisant la réplication entre serveurs. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

10 2) Gestion des groupes La gestion des groupes de domaines est un aspect critique pour une entreprise : c'est par un regroupement d'utilisateurs que l'on va pouvoir obtenir une précision importante au niveau des droits attribués, tout en conservant une certaine facilité d'administration. Un des problèmes majeurs de la branche 2 de Samba est que cette gestion de groupes est extrêmement limitée : seulement trois groupes de domaine peuvent être utilisés : les "Administrateurs du domaine", les "Utilisateurs du domaine" et les "Invités". Malheureusement, une entreprise aura besoin de regrouper ses utilisateurs dans des groupes qu'elle aura créés : "Comptabilité", "Ressources Humaines",... et de leur attribuer des droits précis. La déclaration d'appartenance à un groupe de domaine se fait par le biais d'une directive dans le fichier de configuration. On fait correspondre le groupe Unix au groupe désiré. Deux directives sont disponibles : [global]... domain admin group = <groupe Unix> domain guest group = <groupe Unix>... Ainsi, un utilisateur appartenant au groupe Unix se verra attribué les droits du groupe Windows en correspondance. Les autres utilisateurs sont, par défaut, des utilisateurs du domaine. 3) Architectures supportées Samba respecte l'architecture imposée par le modèle NT. Certaines limites en découlent : s'il est possible de disposer les répertoires homes et profiles des utilisateurs à distance, il est impossible de déporter le partage netlogon et ses scripts de connexion. Ainsi, lorsque le PDC tombe en panne, aucun script n'est disponible. Ceci peut poser de réels problèmes en entreprise : un utilisateur standard saurait-il connecter un lecteur manuellement si son script n'est plus accessible? Malheureusement, cette limite est imposée par le modèle de base, puisqu'elle est également présente au niveau des PDC NT4. Une fonctionnalité importante manque également à Samba : la possibilité de constituer un serveur de backup pour un PDC NT4. Actuellement (versions 2 et 3), Samba ne peut être BDC que d'un autre serveur Samba. Ce manque devrait être comblé dans les versions à venir. Enfin, la version 2 ne supporte que l'architecture NT. Il est impossible d'interagir avec un domaine active directory. 4) Code monolithique Les options proposées par la v2 sont intégrables lors de la phase de compilation. Ceci complique la redistribution de packages pré-compilés et oblige à en fournir plusieurs versions, une intégrant différentes fonctionnalités dans chacun. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

11 6) Nouveautés apportées par la v3 2 a) Nouveaux backends Samba 3 ajoute deux nouveaux backends à ceux existants : MySQL et XML. Il modifie également le schéma LDAP de la version 2.2.8a. Ces deux nouveautés s'inscrivent dans une volonté de séparer les données (comptes) du traitement (authentification), et poursuivent le travail effectué concernant l'intégration du stockage LDAP dans les dernières versions 2. Le système de gestion des backends a été complètement revu : on peut désormais les charger dynamiquement sous forme de modules et les cumuler. Le backend MySQL apporte la souplesse de LDAP avec des avantages non négligeables : une montée en charge plus importante, une gestion des transactions, et surtout une administration encore plus simple, qu'elle se fasse de manière "manuelle" ou par le biais d'outils d'administration déjà existants (ex : phpmyadmin). La création de tels outils est aussi simplifiée car il est très facile d'accéder à ce type de base depuis la plupart des langages de développement. Le backend XML offre, grâce à la standardisation du format et à son universalité, de grandes possiblilités en ce qui concerne la migration des comptes et leur formatage. Il est bon de noter que ces backends nécessitent tous des comptes Unix en sus. L'idée de backends "_NUA" (No Unix Accounts) a émergé il y a quelques temps, mais leur développement et leur intégration ne sont plus à l'ordre du jour. Peut-être réapparaitront-ils dans des versions futures de Samba? b) Modules VFS multiples Les modules VFS peuvent être particulièrement utiles. VFS (ou Virtual File System) est un mécanisme d'interception des e/s disques. En d'autres termes, chaque fois que vous effectuez une action sur un fichier dans un répertoire partagé, elle peut être interceptée par Samba. On peut ainsi disposer d'une corbeille réseau ou encore d'un système d'audit. On peut étendre les fonctionnalités de VFS de manière relativement simple puisque son système d'implémentation a été revu et se fait désormais sous forme de modules, tout comme la gestion des backends. c) Mapping de groupes Le mapping de groupes est certainement la fonction qui a été la plus attendue lors des tests effectués ; elle corrige un problème majeur de la v2 : la limitation du nombre de groupes sur un domaine. Alors que nous ne disposions que de trois groupes de domaines auparavant, il est désormais possible d'en créer à volonté. Ceci se fait via la commande net (voir ci-après) et permet de créer dynamiquement une correspondance entre un groupe Unix et un groupe de domaine. L'utilisateur qui appartiendra à un certain groupe sous Unix se verra appartenir au groupe Windows mappé. Cette fonctionnalité très importante permet d'obtenir une précision importante au niveau de la gestion des droits de groupes, ce qui n'était pas possible auparavant. L'administration est également simplifiée. 2 Lien : WHATSNEW.txt à la racine des sources de Samba Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

12 d) Approbations de domaines Les approbations de domaines existent depuis longtemps sous Windows, mais apparaissent tout juste sous Samba. Elles autorisent un domaine à faire confiance à un autre domaine. En d'autres termes, il sera possible de se connecter sur un domaine avec un compte provenant d'un autre domaine auquel on fait explicitement confiance. Les approbations ont les mêmes propriétés que sous NT4 : unidirectionnelles et non-transitives. Ce qui signifie que si A fait confiance à B et B fait confiance à C, alors B ne fait pas confiance à A et A ne fait pas confiance à C. e) La commande Net Une nouvelle commande fait sont apparition : la commande net. Imitant la commande net de Windows, elle permet également de manipuler les différents comptes Samba. Il est quasiment possible d'administrer intégralement Samba avec cette commande. #net help.. ṅet time to view or set time information net lookup to lookup host name or ip address net user to manage users net group to manage groups net groupmap to manage group mappings net join to join a domain net cache to operate on cache tdb file net getlocalsid [NAME]to get the SID for local name... net setlocalsid SID net changesecretpw to set the local domain SID to change the machine password in the local secrets database only #net rpc help.. ṅet rpc info show basic info about a domain net rpc join net rpc oldjoin net rpc testjoin net rpc user net rpc group net rpc share net rpc file net rpc changetrustpw net rpc getsid net rpc vampire net rpc samdump net rpc trustdom net rpc abortshutdown net rpc shutdown... to join a domain to join a domain created in server manager tests that a join is valid to add, delete and list users to list groups to add, delete, and list shares to list open files to change the trust account password fetch the domain sid into the local secrets.tdb syncronise an NT PDC's users and groups into the local passdb diplay an NT PDC's users, groups and other data to create trusting domain's account or establish trust to abort the shutdown of a remote server to shutdown a remote server f) Outils de migration Il est désormais possible de migrer les comptes de serveurs NT4 ou Samba vers Samba. Cette manipulation se fait via la commande "net vampire". Fonctionnalité également très attendue, elle doit permettre de passer rapidement d'une architecture Windows à Samba et faciliter la tâche des administrateurs. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

13 g) Support d'active Directory Le support d'active Directory est pour l'instant partiel, il témoigne de l'orientation de Samba et de la volonté de suivre l'évolution des technologies actuelles. Il est possible avec Samba 3 de joindre une machine à un domaine Active Directory et d'y publier des imprimantes. Samba 3 ne fait pas office de contrôleur de domaine Active Directory. h) Support de l'unicode, gestion des ACLs, NTLM v2 Le support de l'unicode a été ajouté, autorisant ainsi l'utilisation de caractères internationaux. La gestion des ACLs a été améliorée. Enfin, NTLM v2 a été intégré. 7) Tests et résultats a) Contexte des tests J'ai eu à ma disposition 6 ordinateurs afin de pouvoir constituer un ou plusieurs domaines. Chacun d'entre eux fonctionnait sur un système d'exploitation GNU/Linux. Les distributions étaient assez variées : principalement Debian, RedHat, et Mandrake. Différentes phases de tests se sont déroulées, durant lesquelles j'ai pu tester chacune des fonctionnalités présentes dans la roadmap. J'ai également suivi quotidiennement les mises à jour de Samba (en alpha, beta, puis rc) et participé à différentes mailing-lists dont samba, samba-technical et samba-fr. Le suivi de ces tests a fait l'objet de trois documents : une étude théorique préalable, le suivi pratique des tests, et enfin un document récapitulatif des fonctionnalités de Samba v3. b) Résultats Les tests effectués se sont révélés concluants, malgré quelques problèmes dûs à la jeunesse des pré-versions 3. Cependant, certains problèmes inhérents aux choix d'implémentation peuvent constituer un frein à l'utilisation de Samba dans un environnement professionnel, nous allons les détailler. 1) Le Group mapping Le mapping de groupes Unix vers Windows ne semble pas dynamique. En effet, alors qu'il existe une table de correspondance interne, c'est le SID de groupe primaire de l'utilisateur (stocké dans ses propriétés) qui est utilisé. En d'autres termes, si un mapping est déclaré, puis qu'un utilisateur est créé au sein du groupe, alors il appartient bien au groupe Windows mappé. Malheureusement, si par la suite on modifie ou supprime le mapping, l'utilisateur appartiendra toujours au groupe d'origine, car l'utilisateur a conservé la valeur de sa propriété "SID". Concrètement, imaginons que l'on ait un mapping "promo2004 (Unix) -> Inge2 (Windows)" et qu'on le modifie par la suite en "promo2004 (Unix) -> Inge3", alors les utilisateurs feraient toujours partie du groupe Inge2. Ce mécanisme peut poser de nombreux problèmes de gestion. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

14 2) Les ACLs Les ACLs (Acces Control Lists) définissent les droits que chacun a sur un fichier. Elles existent depuis longtemps sous Windows et en proposent une gestion assez fine. Sous Unix, les ACLs POSIX se limitent à 3 entités pouvant agir sur le fichier : un utilisateur, un groupe et les autres ainsi que 3 types de droits : lecture, écriture, exécution. Samba dépend bien évidemment de cette limitation, ce qui ne permet pas, de manière native, de recréer un véritable environnement Windows. Plus récemment sont apparues les ACLs étendues sous Unix, disponibles en natif pour certains systèmes de fichiers (par exemple XFS) ou sous forme de patches (ext3fs). Elle permettent d'attribuer les mêmes droits (rwx, lecture écriture, exécution) mais pour une liste d'utilisateurs et de groupes. On se rapproche des ACLs NTFS, malheureusement, certaines fonctionnalités sont inaccessibles telles que les refus de droits explicites, les droits concernant les droits,... 3) La Migration La migration s'effectue normalement en deux étapes : la migration des comptes (utilisateurs/groupes/machines), puis celle des données. Malheureusement, les outils fournis pas Samba 3 ne permettent que la migration des comptes. Il faudra effectuer manuellement la seconde étape, sachant que toutes les ACLs seront perdues et devront être réinitialisées à la main. De plus, la migration des comptes elle-même pose problèmes : les noms des groupes importés doivent correspondre aux limitations imposées par les machines Unix : pas d'espaces, pas de caractères accentués. Il faut donc au préalable renommer les groupes standards Windows, tels que "Utilisateurs du domaine". Ceci n'étant pas possible avec les outils fournis par NT4, nous pouvons avoir recours à des outils commerciaux tels qu'ultraadmin, proposé par DorianSoft ( 4) Les groupes de groupes Samba ne permet pas la gestion de groupes imbriqués. 5) Les groupes multiples Des problèmes sont apparus lorsqu'un utilisateur appartient à plusieurs groupes en simultané. Lors des tests effectués, si un utilisateur avait pour groupe primaire "Utilisateur du domaine" et secondaire "Administrateur du domaine", alors il ne possédait pas les droits d'administrateur. Seul son groupe primaire était vu par le domaine Windows. 6) Samba en tant que BDC Comme nous l'avons vu, Samba ne peut être contrôleur secondaire que d'un contrôleur primaire Samba. La version 3 de Samba n'offrira pas la possibilité d'être contrôleur secondaire d'un PDC NT4. Ceci est en cours d'étude et en prévision pour des versions futures, mais est-ce bien utile dans notre cas? Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

15 7) Les Stratégies utilisateurs Seules les stratégies d'utilisateurs (NT4) sont utilisables. Les Machine Policy Objects et les Group Policy Objects ne le sont pas. 8) Active Directory La compatibilité Active Directory est limitée puisque Samba 3 ne peut pas encore en constituer un contrôleur de domaine. 9) Les interfaces d'administration Si Samba 3 propose des outils très complets d'administration en ligne, on peut déplorer le manque d'outils graphiques. Les outils tels que Swat (livré avec Samba) ou Webmin ne proposent pas une gestion intégrale du domaine et peuvent être déroutants pour une personne ne connaissant pas Samba. 8) Conclusion Samba devient un produit réellement mûr. Les principales fonctions que nous attendons d'un contrôleur de domaine sont désormais implémentées, même si certaines font encore défaut, ainsi que nous avons pu le constater. Samba peut réellement constituer une alternative à Windows, car ses atouts sont nombreux. Si la gratuité est souvent l'argument évoqué, on peut aussi citer sa fiabilité, sa robustesse et les outils d'administration puissants qui le composent. Produit libre, il apporte à l'entreprise un certaine autonomie et allie la simplicité de Windows NT à la souplesse d'une architecture décentralisée. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

16 9) Glossaire 3 ACL (Access Control List) : Liste spécifiant les droits attribués à un ou plusieurs acteurs (ex : un utilisateur) sur une ressource (ex : un fichier). BDC (Backup Domain Controller) : Contrôleur secondaire de domaine, prend le relais du PDC en cas de panne. Apellation propre à un domaine NT. DC (Domain Controller) : Contrôleur de domaine. Apellation qui met de côté les notions de PDC et de BDC (voir ci-dessous). Sous NT4, chaque PDC ou BDC peut aussi être appelée plus communément DC. DCE/RPC (Originel) -> MSRPC (Réimplémentation par Microsoft) -> SMB (Server Message Block - évolution) -> CIFS (Common Internet File System ) : protocole de partage de fichiers et d'imprimantes. Peut, ou non, utiliser NetBios - Ceci est souvent le cas mais est en train d'évoluer vers la méthode "Direct-hosted" et l'implémentation de CIFS directement sur TCP/IP. Fonctionne au niveau des couches 6 et 7 du modèle OSI. Direct-Hosted : Méthode de partage de fichiers/imprimantes directement sur le port TCP 445, sans passer par NetBios. Ces machines utilisent donc DNS pour la résolution de nom. Kerberos : Mécanisme d'authentification sous Windows 200x/Active Directory utilisant un mécanisme de tickets. Destiné à remplacer NTML. LDAP (Lightweight Directory Access Protocol) : Adaptation allégée du protocole X500. Protocole de gestion d'annuaires réseaux. NetBeui : "NetBIOS Extended User Interface". Protocole non routable, fonctionne au niveau des couches 3 à 5 du modèle OSI. NetBios : "Network Basic Input/Output System" : n'est pas un protocole. Méthode de communication sur un protocole existant ; est en fait une couche intermédiaire entre SMB et un protocole sous-jacent tel que TCP (cf. NBT) ou IPX. Il fonctionne à la couche 5 (session) du modèle OSI. Fournit une méthode de résolution de noms et de services aux couches supérieures. Utilise un modèle de noms de machines de 15 caractères + 1 caractère de contrôle spécifiant les services offerts par la machines. NetBios a été développé en 1983 par Sytec Inc. pour IBM. NBT (ou encore RFCNB ou NBF) : "NetBios over TCP" : extension de NetBios permettant de fonctionner avec TCP/IP. Il faut dans ce cas une correspondance entre les noms NetBios et les Adresses IP : via Serveur Wins, fichier lmhosts, broadcast ou, plus récemment, serveur DNS. NIS (Network Information Services - Yellow Pages) : Services fournissant toutes sortes d'informations sur un réseau (noms de machines, adresses IP, logins, passwords, home directories, groupes...). Anciennement connu sous le nom de "Pages jaunes" Yellow Pages, yp. NTLM : Protocole d'authentification utilisé à l'origine par DCE/RPC, il constitue actuellement un moyen de s'authentifier de façon unique (single-sign-on) sur un réseau Windows. PDC (Primary Domain Controller) : Contrôleur principal de domaine. Apellation propre à un domaine NT. 3 Lien : Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

17 RPC (Remote Procedure Call) : Terme générique désignant une méthode d'exécution distante de procédures. Sous Windows, les actes administratifs distants utilisent les RPC. SAM (Security Account Manager) : Base de données contenant les informations de sécurité sur un serveur Windows NT, notamment les comptes et mots de passes des utilisateurs. SID (Security Identifier): Un SID est un identifiant unique attribué à chaque acteur d'un domaine Windows. Il est composé d'une partie nommée "SID local", qui identifie le domaine, et d'une seconde que l'on appelle "RID" (Relative Identifier), qui identifie l'acteur (utilisateur/groupe/machine) au sein du domaine : un exemple de SID pourrait-être : S qui identifie le groupe d'administrateurs du domaine (512) au sein du domaine S UNC (Universal Naming Convention) : Convention de nommage universelle (sous Windows) permettant de désigner le chemin d'un répertoire partagé. Ex. : \\Serveur\partage. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

18 10) Liens - bibliographie Sites : Documents Samba : - Pages de man - WHATSNEW.txt à la racine des sources Samba-howto-collection dans le répertoire docs/html des sources Divers : - linux mag' 40 (p.37) et 46 (p32) Listes de diffusion : Officielles : - samba@lists.samba.org : - samba-technical@lists.samba.org : - samba-announce@lists.samba.org : Samba-fr : - samba-fr@ujf-grenoble.fr : 11) Remerciements Un grand merci à Vincent Gayrard, David Lacoste et Xavier Lemesle pour leur accueil et le soutien qu'ils ont su m'apporter. Un grand merci aussi à toute l'équipe d'i21, ainsi qu'i25, et toutes les personnes non citées ici mais qui se reconnaîtront... Merci enfin pour le sujet de mon stage, réellement passionnant, et les perspectives d'avenir offertes... Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

19 GNU Free Documentation License Version 1.2, November 2002 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. Ganaël LAPLANCHE - Samba - introduction, étude de la version /21

20 3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: * A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. * B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. * C. State on the Title page the name of the publisher of the Modified Version, as the publisher. * D. Preserve all the copyright notices of the Document. * E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. * F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. * G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. * H. Include an unaltered copy of this License. * I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. * J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. * K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. * L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. * M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. * N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. * O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements." Ganaël LAPLANCHE - Samba - introduction, étude de la version /21