Martymac.orgcontribs.martymac.org/sambaEtudes/Etude_Samba_et_se… · Web viewEDF R&D. Département SINETICS. Groupe Infrastructures de communication et securite. 1, avenue du général

EDF R&D

D É P A R T E M E N T S INETICSGR O U P E IN F R A S T R U C T U R E S D E C O M M U N I C A T I O N E T S E C U R I T E

1, A V E N U E D U G É N É R A L D E G A U L L EF-92141 C L A M A R T C E D E X

T E L : 33 1 47 65 43 21 F A X : 33 1 47 65 54 28

Janvier 2004

GANAËL LAPLANCHE (GENESTA), DAVID LACOSTE (EDF R&D)

Samba 3 - Etudes, propositions et cahier des charges d'un outil

d'administration

V1.1

Licence de ce document :

Copyright (c) 2003-2004, EDFWork by Ganaël Laplanche (Genesta) at EDF R&D's Clamart research center. Author's website : http://www.martymac.com, email : [email protected]. 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

Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 1 sur 94

Table des matières :

Chapitre 1 : Installation d'une plateforme Samba 3 - LDAP...............................................................6I) Contexte.......................................................................................................................................................7II) Installation et configuration d'OpenLDAP (ldapserver.edf.fr)...................................................................7

A) Installation d’OpenLDAP......................................................................................................................7B) Configuration d'OpenLDAP...................................................................................................................7C) Création de la structure prête à recevoir les données Samba.................................................................8

III) Installation de Samba (bluepdc.edf.fr)....................................................................................................10A) Outils et librairies LDAP.....................................................................................................................10B) Configuration des outils LDAP............................................................................................................10C) Installation de Samba...........................................................................................................................10D) Configuration de Samba.......................................................................................................................10E) Ajout d’utilisateurs à notre domaine....................................................................................................12F) Création de l'environnement de l'utilisateur.........................................................................................12G) Connexion au domaine avec la machine Windows..............................................................................13

Chapitre 2 : Situation du mapping de groupes...................................................................................14I) Introduction................................................................................................................................................15II) Création d'un mapping.............................................................................................................................15

A) Création de l'utilisateur et de son groupe sous Unix............................................................................15B) Création du groupe Samba...................................................................................................................16C) Création du mapping............................................................................................................................16D) Création de l'utilisateur au sein du groupe mappé...............................................................................17

III) Etude des limites.....................................................................................................................................17A) Suppression du mapping......................................................................................................................17B) Création d'un utilisateur puis du mapping............................................................................................19C) Modification du mapping.....................................................................................................................20D) Ajout d'un mapping doublon (SID)......................................................................................................21E) Ajout d'un mapping doublon (gid).......................................................................................................22

IV) Récapitulatif des problèmes rencontrés - analyse...................................................................................24A) Propriétés utilisateur non mises à jour.................................................................................................24B) Mauvaise gestion des entrées multiples de SID...................................................................................24C) Modification des mappings..................................................................................................................24D) Conclusion............................................................................................................................................25

V) Propositions d'améliorations....................................................................................................................25A) Propriétés utilisateurs...........................................................................................................................25B) Gestion des doublons de SID...............................................................................................................25C) Gestion des gid.....................................................................................................................................26D) Mise à jour de 'net groupmap modify'..................................................................................................26

Annexe 1 : RIDs standards NT4....................................................................................................................27

Chapitre 3 : Connectivité aux annuaires d'entreprise.......................................................................28I) Introduction................................................................................................................................................29II) Méthodes d'import....................................................................................................................................29III) Exemple de script d'import.....................................................................................................................29


Chapitre 4 : Etat des lieux concernant 'Net Vampire'........................................................................34I) Introduction................................................................................................................................................35II) Préparation du serveur GNU/Linux à la migration..................................................................................35III) Import des comptes : net vampire...........................................................................................................36IV) Migration des données et des ACLs.......................................................................................................39V) Promotion du BDC en PDC.....................................................................................................................40VI) Conclusion..............................................................................................................................................41

Chapitre 5 : Etat des lieux des outils d'administration existants...................................................42I) Introduction................................................................................................................................................43II) Outils existants.........................................................................................................................................43

A) Outils en lignes de commandes............................................................................................................43B) Outils graphiques..................................................................................................................................43

III) Etude des fonctionnalités des outils........................................................................................................44A) Outils en ligne de commande...............................................................................................................44

1) Outils Samba.....................................................................................................................................442) Smbldap-tools (http://samba.idealx.org)...........................................................................................45

B) Outils graphiques..................................................................................................................................461) SWAT (Samba Web Administration Tool)......................................................................................462) Modules Webmin..............................................................................................................................463) LAM : Ldap Account Manager (http://lam.sourceforge.net)............................................................474) Smbconftool (http://www.eatonweb.com/samba).............................................................................475) Slot (http://slot.netfoster.de/index.php)............................................................................................476) Faus (http://faus.sourceforge.net/english.html)................................................................................477) SambaLinkQ (http://www.spanware.com/linkq/sambalinkq.html)..................................................47

IV) Etude des résultats..................................................................................................................................48V) Tableaux comparatifs des outils...............................................................................................................48VI) Les retours des utilisateurs / Choix d'une solution d'administration.......................................................50VII) Conclusion.............................................................................................................................................55

Chapitre 6 : Propositions techniques concernant 'Net Vampire'...................................................56I) Introduction................................................................................................................................................57II) Migration de noms spéciaux.....................................................................................................................57III) Migration des données et ACLs..............................................................................................................57IV) Problèmes liés au backend LDAP..........................................................................................................59

Chapitre 7 : Stratégies de développement de l'outil d'administration..........................................60I) Introduction................................................................................................................................................61II) Réutilisation de code existant...................................................................................................................61

A) Swat......................................................................................................................................................61B) Webmin - module standard Samba......................................................................................................62C) LAM.....................................................................................................................................................62

III) Développement 'from scratch'.................................................................................................................62IV) Conclusion..............................................................................................................................................63


Chapitre 8 : Cahier des charges de l'outil d'administration - Fonctionnalités...........................64I) Introduction................................................................................................................................................65II) Etude des consoles d'administration NT4................................................................................................65

A) Le gestionnaire d'utilisateurs................................................................................................................65B) Le gestionnaire de serveur....................................................................................................................66C) L'éditeur de stratégies système (poledit.exe)........................................................................................67

III) Description détaillée des propriétés des acteurs NT..............................................................................68A) Les utilisateurs.....................................................................................................................................68B) Les groupes...........................................................................................................................................68C) Les machines........................................................................................................................................69D) Les domaines........................................................................................................................................69

IV) Les acteurs sous Samba..........................................................................................................................69A) Les utilisateurs - les machines..............................................................................................................69B) Les groupes d'utilisateurs.....................................................................................................................70C) Les domaines........................................................................................................................................70

V) Rapprochement à Samba - Fonctionnalités retenues...............................................................................71VI) Subdivision des fonctions.......................................................................................................................72

A) Tâches locales, propres au système......................................................................................................72B) Tâches locales, propres à Samba..........................................................................................................73C) Tâches exécutables à distance via des mécanismes Windows/Samba (RPC, partages CIFS).............73D) Tâches exécutables à distance (autres).................................................................................................75

VII) Une API et une GUI ?...........................................................................................................................75VIII) Cahier des charges de l'API.................................................................................................................76IX) Conclusion..............................................................................................................................................80

Chapitre 9 : Cahier des charges de l'outil d'administration - Contraintes d'implémentation.81I) Introduction................................................................................................................................................82II) Etude du besoin........................................................................................................................................82III) Structure de l'application finale..............................................................................................................82IV) La couche d'interface..............................................................................................................................83V) Contraintes fonctionnelles liées à la partie graphique..............................................................................83

A) Sélection du serveur à administrer.......................................................................................................83B) Authentification....................................................................................................................................83C) Gestion de comptes d'administrateurs..................................................................................................83D) Différents modes d'Administration......................................................................................................83

1) Simple...............................................................................................................................................842) Wizards.............................................................................................................................................843) Standard............................................................................................................................................844) Expert - Full......................................................................................................................................855) NT-Like.............................................................................................................................................856) Monitoring-only................................................................................................................................85

E) Gestion des modes................................................................................................................................85F) Configurations par défaut.....................................................................................................................85G) Conservation des commentaires / propreté du code produit................................................................86H) Un mode verbose..................................................................................................................................86I) Snapshots...............................................................................................................................................86J) Internationalisation................................................................................................................................86K) Administration de plusieurs serveurs...................................................................................................86


VI) Contraintes techniques liées à la partie graphique..................................................................................87A) Interface cliente Orientée Web ou "native"..........................................................................................87B) Documentation complète API et Outil d'administration......................................................................87C) Libre.....................................................................................................................................................88D) Propreté du code, commentaires, outils standards...............................................................................88

VII) Conclusion.............................................................................................................................................88

Annexe 1. Glossaire.........................................................................................................................................89Annexe 2. Liens - Bibliographie.....................................................................................................................90Annexe 3. Remerciements..............................................................................................................................90

GNU Free Documentation License................................................................................................................91

Note : Les outils et marques cités au sein de ce document appartiennent à leurs propriétaires respectifs.


Chapitre 1 : Installation d'une plateforme Samba 3 - LDAP


I) Contexte

Nous allons décrire à travers ce chapitre l'installation pas à pas de la plateforme de test Samba - LDAP.

Pour l'installation de cette plateforme, nous allons utiliser trois machines :

- Serveur samba PDC : Intel P3 1.2 Ghz, 256 Mo Ram- Serveur LDAP : Intel P3 700 Mhz, 128 Mo Ram- Station Windows :

Les deux serveurs GNU/Linux fonctionnent avec la distribution Debian 3.0r1. Le poste Windows fonctionne avec Windows XP.

II) Installation et configuration d'OpenLDAP (ldapserver.edf.fr)

A) Installation d’OpenLDAP

- Installation par les sources :

http://www.openldap.org/ftp://ftp.OpenLDAP.org/pub/OpenLDAP/openldap-release/openldap-2.1.23.tgz

tar xvzf openldap-2.1.23.tgzcd openldap-2.1.23env CPPFLAGS=-I/usr/mylocal/include LDFLAGS=-L/usr/mylocal/lib ./configure --enable-bdb --enable-ldbm --enable-slurpdmake && make install

- ou en utilisant apt (sous Debian GNU/Linux), solution que nous avons choisie ici :

apt-get install slapd ldap-utils

B) Configuration d'OpenLDAP

- Copie du fichier de schema, situé dans l'archive samba :

http://www.samba.orghttp://de.samba.org/samba/ftp/pre/samba-3.0.1pre2.tar.bz2

tar xvjf samba-3.0.1pre2.tar.bz2cp samba-3.0.1pre2/source/examples/LDAP/samba.schema /etc/ldap/schema/

- Edition du fichier /etc/ldap/slapd.conf :


------------- Début du fichier slapd.conf -------------

include /etc/ldap/schema/core.schemainclude /etc/ldap/schema/cosine.schemainclude /etc/ldap/schema/nis.schemainclude /etc/ldap/schema/inetorgperson.schemainclude /etc/ldap/schema/samba.schema

pidfile /var/run/slapd.pidargsfile /var/run/slapd.args

database ldbmsuffix "dc=edf,dc=fr"rootdn "cn=Manager,dc=edf,dc=fr"rootpw "secret"directory "/var/lib/ldap"

index objectClass eqindex cn pres,sub,eqindex sn pres,sub,eqindex uid pres,sub,eqindex displayName pres,sub,eq

index sambaSID eqindex sambaPrimaryGroupSID eqindex sambaDomainName eqindex default sub

------------- Fin du fichier slapd.conf -------------

- Edition du fichier /etc/ldap/ldap.conf :

------------- Début du fichier ldap.conf -------------

BASE dc=edf,dc=frHOST 127.0.0.1

------------- Fin du fichier ldap.conf -------------

- (Re-)Démarrage du serveur :

/etc/init.d/slapd start (ou /etc/init.d/slapd restart)

Le serveur est désormais opérationnel (vérifiable avec ps -a | grep slapd)

C) Création de la structure prête à recevoir les données Samba

- Création d'un fichier "base.ldiff" :


------------- Début du fichier base.ldiff -------------

# Organization for Samba Basedn: dc=edf,dc=frobjectclass: dcObjectobjectclass: organizationdc: edfo: Tests Samba 3description: Tests Samba 3

# Manager LDAPdn: cn=Manager,dc=edf,dc=frobjectclass: organizationalRolecn: Managerdescription: LDAP Manager

# Conteneur d'utilisateursdn: ou=Users,dc=edf,dc=frobjectclass: topobjectclass: organizationalUnitou: Users

# Conteneur de machinesdn: ou=Machines,dc=edf,dc=frobjectclass: topobjectclass: organizationalUnitou: Machines

# Administrateurdn: cn=admin,ou=Users,dc=edf,dc=frcn: adminobjectclass: topobjectclass: organizationalRoleobjectclass: simpleSecurityObjectuserPassword: {SSHA}VJ7nyQidusIDyz7jQqjbnItTTtesxWso

------------- Fin du fichier base.ldiff -------------

(le mot de passe a été créé par la commande slappasswd -s <mot de passe>)

- Insertion de ce fichier à l'annuaire LDAP :

ldapadd -W -D 'cn=Manager,dc=edf,dc=fr' -xh localhost -f base.ldiff

- Génération des indexes : slapindex -f /etc/ldap/slapd.conf

L'annuaire est désormais prêt à recevoir nos comptes Samba.


III) Installation de Samba (bluepdc.edf.fr)

A) Outils et librairies LDAP

- Installation des clients LDAP et des librairies nécessaires à Samba :

apt-get install ldap-utils libldap2-dev

B) Configuration des outils LDAP

- Editer le fichier /etc/ldap/ldap.conf :

------------- Début du fichier ldap.conf -------------

BASE dc=edf,dc=frHOST ldapserver.edf.fr

------------- Fin du fichier ldap.conf -------------

- Test de connexion au serveur LDAP :

ldapsearch -b 'dc=edf,dc=fr' -xh ldapserver.edf.fr

C) Installation de Samba

- Installation par les sources :

http://www.samba.orghttp://de.samba.org/samba/ftp/pre/samba-3.0.1pre2.tar.bz2

tar xvjf samba-3.0.1pre2.tar.bz2cd samba-3.0.1pre2/source/./configure --with-automount --with-smbmount --with-quotas --with-libsmbclient --with-acl-support --with-windbind --with-ldapmake && make install

D) Configuration de Samba

- Edition du fichier /usr/local/samba/lib/smb.conf :

------------- Début du fichier smb.conf -------------Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 10 sur 94

[global]passdb backend = ldapsam:ldap://ldapserver.edf.fr, guestldap admin dn = "cn=Manager,dc=edf,dc=fr"ldap ssl = offldap delete dn = noldap user suffix = ou=Users,dc=edf,dc=frldap machine suffix = ou=Machines,dc=edf,dc=frldap suffix = "dc=edf,dc=fr"workgroup = BLUEnetbios name = BLUE_PDCserver string = BLUE PDCencrypt passwords = yes

domain logons = yesos level = 65domain master = Yeslocal master = Yes

security = user

log file = /var/log/samba/%m.loglog level = 2

[tmp]comment = Partage des fichiers temporairespath = /tmpread only = nowritable = yesguest ok = yes

; Scripts et stratégies[netlogon]path = /export/samba-test/netlogoncomment = Network logon serviceread only = yesguest ok = yes

; A mapper via \\serveur\utilisateur[homes]path = /export/samba-test/homes/%ucomment = Home directoriesvalid users = %Swriteable = yesread only = nocreate mask = 0664directory mask = 0775browsable = no

; A mapper via \\serveur\profiles\utilisateur[profiles]path = /export/samba-test/profilescreate mask = 0600directory mask = 0700browsable = nowriteable = yes

------------- Fin du fichier smb.conf -------------

- Initialisation du mot de passe LDAP :Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 11 sur 94

smbpasswd –w secret

- Démarrage de Samba :

/etc/init.d/samba start

Le serveur est désormais prêt à contrôler notre domaine.

E) Ajout d’utilisateurs à notre domaine

1 - Ajout d'un administrateur Samba:useradd -o -u 0 -g 0 smbadmin (Unix)smbpasswd -a smbadmin (Samba)Ce compte sera utilisé pour toutes les opérations effectuées avec la commande net et pour la jonction de la machine Windows au domaine.

2 - Ajout d'un groupe d'utilisateurs :groupadd blueusers (Unix)

3 - Ajout d’un utilisateur dans ce groupe :useradd -g blueusers blueuser (Unix)smbpasswd -a blueuser (Samba)

4 - Modification de ses propriétés (Samba) :pdbedit -r -- profile=\\\\BLUE_PDC\\profiles\\blueuser --homedir =\\\\BLUE_PDC\\blueuser --script=blueuser.cmd --drive=U: blueuser

5 - Ajout d'un compte machine pour se connecter :useradd BLUEWKS$ (sous Unix)smbpasswd -a -m BLUEWKS (pour Samba)

6 - Vérification des utilisateurs présents dans la base :pdbedit -vL

F) Création de l'environnement de l'utilisateur

- Création du répertoire /export/samba-test/homes/blueuser et gestion des droits :mkdir /export/samba-test/homes/blueuserchown blueuser:blueusers /export/samba-test/homes/blueuserchmod 700 /export/samba-test/homes/blueuser

- Création du répertoire /export/samba-test/profiles/blueuser et gestion des droits :mkdir /export/samba-test/profiles/blueuserchown blueuser:blueusers /export/samba-test/profiles/blueuserchmod 700 /export/samba-test/profiles/blueuser

- Création du fichier /export/samba-test/netlogon/blueuser.cmd et gestion des droits :


echo -e "echo \"Test\"\npause" > /export/samba-test/netlogon/blueuser.cmdchown blueuser:blueusers /export/samba-test/netlogon/blueuser.cmdchmod 400 /export/samba-test/netlogon/blueuser.cmd

G) Connexion au domaine avec la machine Windows

On peut désormais joindre la machine BLUEWKS au domaine BLUE avec l'utilisateur smbadmin. On pourra ensuite se connecter au domaine avec l'utilisateur blueuser.


Chapitre 2 : Situation du mapping de groupes


I) Introduction

Ce chapitre présente les limites de la gestion du mapping de groupes observées dans Samba 3, notamment les problèmes de mise à jour des propriétés des utilisateurs appartenant aux groupes Unix mappés.

Nous étudierons la version Samba 3.0.1pre2 de Samba.

Contexte :

Unix identifie les groupes d'utilisateurs grâce à un gid (Group Identifier) ; Windows le fait grâce à un SID (Security Identifier). Samba, dans les versions 2.2 limitait les groupes de domaines aux "Utilisateurs du domaine", "Administrateurs du domaine" et "Invités du domaine", ce qui empêchait toute gestion fine des droits sur le domaine. La version 3 apporte une nouvelle gestion des groupes grâce au mapping de groupes.

Le mapping de groupes permet en effet de faire correspondre un SID (Identifiant un groupe) Windows vers un gid Unix. Une table interne à Samba est maintenue pour mémoriser ces correspondances. Le nombre de groupes Windows créés via un mapping est ainsi, en théorie, illimité.

Un SID est composé de deux parties : le SID local (identifiant le domaine) et le RID (identifiant l'acteur, le groupe, sur le domaine). Un exemple de SID peut être : S-1-5-21-3746524048-3196343125-3229652583-512 identifiant le groupe d'Administrateurs du domaine (RID 512) sur le domaine S-1-5-21-3746524048-3196343125-3229652583. Un gid est un entier. Un exemple de gid peut être 1012.

Note :

Samba nécessite deux types de comptes par utilisateur et par groupe : un compte standard Unix et un compte Samba, qui va étendre les informations concernant le compte Unix par des données qui lui sont propres. Il y a moyen de regrouper ces deux comptes en un seul dans un annuaire LDAP en utilisant deux librairies : libnss-ldap et libpam-ldap fournies par padl software (www.padl.com). Cependant, pour cette étude, nous n'utiliserons pas ces librairies, afin de conserver des comptes Unix bien distincts des comptes Samba, ce qui nous permettra de mieux comprendre les étapes à suivre pour mettre en oeuvre le mapping de groupes.

Toutes les étapes décrites ici se font à partir du PDC Samba (bluepdc.edf.fr).

II) Création d'un mapping

A) Création de l'utilisateur et de son groupe sous Unix

- Création du groupe Unix :groupadd domadm

- Création de l'utilisateur ' domadmuser' faisant partie de ce groupe :useradd -g domadm domadmuser


B) Création du groupe Samba

Pour effectuer le mapping, le groupe doit au préalable exister pour Samba, nous allons le créer. Malheureusement la commande "net group add" ne semble pas fonctionner. Nous allons donc ajouter le groupe dans LDAP de manière manuelle, avec ldapadd. Nous passons par un fichier ldiff.

- Création du fichier ajoutgroupe.ldiff :

------------------------- Début du fichier ajoutgroupe.ldiff -------------------------dn: cn=domadm,ou=Users,dc=edf,dc=frobjectClass: posixGroupgidNumber: 1012cn: domadmmemberUid: domadmuser-------------------------- Fin du fichier ajoutgroupe.ldiff --------------------------

Le gidNumber (ici 1012) est obtenu à partir de celui du groupe Unix par la commande :getent group | grep domadm | cut -f 3 -d ':' -s

- Ajout de ces informations à l'annuaireldapadd -W -D 'cn=Manager,dc=edf,dc=fr' -xh ldapserver.edf.fr -f ajoutgroupe.ldiff

C) Création du mapping

- Il faut tout d'abord récupérer le SID local de notre domaine :net getlocalsid | cut -f 2 -d ':' -s

S-1-5-21-3746524048-3196343125-3229652583

Ce SID va nous permettre de spécifier celui que l'on désire pour le groupe NT qui va correspondre à notre groupe Unix lors du mapping.

- Créons ensuite le mapping en utilisant le sid local que nous avons obtenu et en le complétant par le rid du groupe Windows correspondant au rôle que nous désirons obtenir (ici 512, administrateurs du domaine):net groupmap add sid=S-1-5-21-3746524048-3196343125-3229652583-512 unixgroup=domadm ntgroup="Domain Admins" type=domain

- Nous pouvons désormais lister les mappings existants grâce à la commande :net groupmap list

Domain Admins (S-1-5-21-3746524048-3196343125-3229652583-512) -> domadm

- Vérifions les données inscrites au niveau de l'annuaire LDAP :ldapsearch -b 'dc=edf,dc=fr' -xh ldapserver.edf.fr


[...]# domadm, Users, edf, frdn: cn=domadm,ou=Users,dc=edf,dc=frobjectClass: posixGroupobjectClass: sambaGroupMappinggidNumber: 1012cn: domadmmemberUid: domadmusersambaSID: S-1-5-21-3746524048-3196343125-3229652583-512sambaGroupType: 2displayName: Domain Adminsdescription: Local Unix group[...]

D) Création de l'utilisateur au sein du groupe mappé

- Rappelons que notre utilisateur 'domadmuser' a pour groupe Unix primaire 'domadm' qui est désormais mappé vers 'Domain Admins' dans notre domaine Windows. Ajoutons cet utilisateur à Samba :smbpasswd -a domadmuserNote : Il est également possible d'utiliser la commande 'net user add' pour ajouter l'utilisateur.

L'utilisateur 'domadmuser' fait désormais partie du groupe 'Domain Admins'.

- Vérifions que l'utilisateur appartienne bien au groupe mappé :net user info domadmuser -U smbadmin

Domain Admins

- Vérifions ses propriétés stockées au niveau du backend Samba :pdbedit -vL

Unix username: domadmuserNT username: domadmuserAccount Flags: [U ]User SID: S-1-5-21-3746524048-3196343125-3229652583-3022Primary Group SID: S-1-5-21-3746524048-3196343125-3229652583-512[...]

Le SID de son groupe primaire correspond bien au SID des administrateurs du domaine.

III) Etude des limites

A) Suppression du mapping

- Essayons de supprimer notre mapping :net groupmap delete sid=S-1-5-21-3746524048-3196343125-3229652583-512Le mapping est bien supprimé.


- Vérifions les propriétés de notre utilisateur domadmuser :pdbedit -vL


- Vérifions que l'utilisateur n'appartient plus aux Administrateurs du domaine :net user info domadmuser -U smbadminLa commande ne renvoie rien.

- Listons les données de notre annuaire LDAP :ldapsearch -b 'dc=edf,dc=fr' -xh ldapserver.edf.fr

[...]# domadm, Users, edf, frdn: cn=domadm,ou=Users,dc=edf,dc=frobjectClass: posixGroupgidNumber: 1012cn: domadmmemberUid: domadmuser

# domadmuser, Users, edf, frdn: uid=domadmuser,ou=Users,dc=edf,dc=fruid: domadmusersambaSID: S-1-5-21-3746524048-3196343125-3229652583-3022sambaPrimaryGroupSID: S-1-5-21-3746524048-3196343125-3229652583-512sambaAcctFlags: [U ]objectClass: sambaSamAccountobjectClass: account[...]

Les propriétés de domadm correspondant au mapping ont bien été supprimées.

Conclusion

On remarque que l'utilisateur conserve son 'Primary Group SID', ce qui signifie qu'il conserve ses droits d'administrateur sur le domaine, et ce, malgré la suppression du mapping, car Samba se fie à ce SID pour gérer les droits de l'utilisateur. La situation n'a donc pas évolué depuis les versions rc où ces problèmes avaient déjà été détectés. Ceci pose évidemment de gros problèmes de sécurité sur un domaine lors d'un changement de politique de droits d'accès.

La commande 'net user info domadmuser -U smbadmin' se fie aux mappings actifs pour lister les groupes de l'utilisateur et n'a pas indiqué que domadmuser possédait toujours les droits d'Administrateur de domaine.


B) Création d'un utilisateur puis du mapping

- Effaçons notre utilisateur sous Samba :net user delete -U smbadmin domadmuser

- Ainsi que le mapping de son groupe :net groupmap delete sid=S-1-5-21-3746524048-3196343125-3229652583-512

- Ajoutons à nouveau l'utilisateur sous Samba :net user add -U smbadmin domadmuser

- Vérifions les données stockées :pdbedit -vL


L'utilisateur ne dispose pas des droits d'administrateur (RID = 3025, différent de 512).

- Créons le mapping de groupes :net groupmap add sid=S-1-5-21-3746524048-3196343125-3229652583-512 unixgroup=domadm

- Vérifions à nouveau les données stockées :pdbedit -vL


Conclusion

Les données internes de l'utilisateur n'ont pas été mises à jour. Bien que son groupe primaire Unix soit mappé vers un groupe Windows disposant des droits d'administrateur de domaine, il ne sera pas administrateur de domaine. Cela provient du fait que la partie RID du SID du groupe primaire de l'utilisateur n'a pas été mise à jour par la commande net. Pour que le mapping soit pris en compte, il faut créer l'utilisateur Samba après que le mapping ait été créé. La encore, de gros problèmes de sécurité sont posés.


C) Modification du mapping

La commande 'net groupmap modify' va permettre de modifier le gid Unix associé à un SID Windows, et non de modifier le SID associé à un gid Unix. La recherche de l'élément à modifier se fait par l'intermédiaire du SID ou du nom de groupe Windows.

Nous avons supprimé l'utilisateur domadmuser sous Samba ainsi que le mapping de son groupe et sommes dans la situation suivante :- Deux groupes Unix, domadm et newdomadm créés sous Unix et Samba- domadm est mappé vers les Administrateurs du domaine- Deux utilisateurs domadmuser et newdomadmuser créés sous Unix et Samba (après le mapping) qui appartiennent respectivement aux groupes domadm et newdomadm

- Liste des groupes créés sous LDAP :ldapsearch -b 'dc=edf,dc=fr' -xh ldapserver.edf.fr

# domadm, Users, edf, frdn: cn=domadm,ou=Users,dc=edf,dc=frobjectClass: posixGroupobjectClass: sambaGroupMappinggidNumber: 1012cn: domadmmemberUid: domadmusersambaSID: S-1-5-21-3746524048-3196343125-3229652583-512sambaGroupType: 2displayName: Domain Adminsdescription: Local Unix group

# newdomadm, Users, edf, frdn: cn=newdomadm,ou=Users,dc=edf,dc=frobjectClass: posixGroupgidNumber: 1013cn: newdomadmmemberUid: newdomadmuser

- Liste des mappings actifs :net groupmap listDomain Admins (S-1-5-21-3746524048-3196343125-3229652583-512) -> domadm

- Détail des utilisateurs :pdbedit -vL


Unix username: newdomadmuserNT username: newdomadmuserAccount Flags: [U ]User SID: S-1-5-21-3746524048-3196343125-3229652583-3024Primary Group SID: S-1-5-21-3746524048-3196343125-3229652583-3027[...]


On remarque que domadmuser possède un RID de groupe primaire qui correspond bien au mapping vers le groupe d'Administrateurs du domaine (512). newdomadmuser, quant à lui, possède un RID quelconque (3027).

- Modifions le mapping pour que le groupe newdomadm devienne "Administrateur du domaine" et pour que domadm perde ce privilège :net groupmap modify sid=S-1-5-21-3746524048-3196343125-3229652583-512 unixgroup=newdomadm

[2003/11/13 16:00:20, 0] passdb/pdb_ldap.c:ldapsam_update_group_mapping_entry(2008) ldapsam_update_group_mapping_entry: failed to modify group 1013 error: attribute 'sambaSID' not allowed (Object class violation)Could not update group database

Conclusion

A ce stade, nous sommes confrontés à un problème lié à la commande 'net groumap modify' qui ne va pas (à la différence de net groupmap add) préparer le groupe à recevoir les données du mapping en ajoutant l'objectClass nécessaire (sambaGroupMapping). newdomadm est ici un objet posixGroup et ne peut recevoir les données concernant un mapping de groupe (le SID par exemple). Nous recevons donc en retour une erreur d'openLdap qui refuse d'ajouter les nouvelles informations du mapping dans un groupe posix. Nous ne pouvons donc continuer les tests à ce stade.

Cependant, l'étude du code source de 'net group modify' laisse à supposer que si la commande s'achevait avec succès, là non plus, les données des deux utilisateurs ne seraient pas mises à jour.

D) Ajout d'un mapping doublon (SID)

Un autre problème se pose, il est possible de mapper le même groupe Windows vers deux groupes Unix différents. En soi, cela ne pose aucun problème et semble logique. En pratique, il s'avère impossible de supprimer un tel mapping une fois créé.

Nous sommes dans la situation suivante :- Deux groupes Unix 'domadm' et 'newdomadm' existants sous Unix et Samba

net groupmap add sid=S-1-5-21-3746524048-3196343125-3229652583-512 unixgroup=domadmnet groupmap add sid=S-1-5-21-3746524048-3196343125-3229652583-512 unixgroup=newdomadmnet groupmap list

domadm (S-1-5-21-3746524048-3196343125-3229652583-512) -> domadmnewdomadm (S-1-5-21-3746524048-3196343125-3229652583-512) -> newdomadm

La suppression du mapping est alors impossible :net groupmap delete sid=S-1-5-21-3746524048-3196343125-3229652583-512

ldapsam_delete_entry: Entry must exist exactly once!Failed to removing group S-1-5-21-3746524048-3196343125-3229652583-512 from the mapping db!

On est alors forcé de supprimer le doublon à partir de l'annuaire LDAP :Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 21 sur 94

ldapdelete -W -D 'cn=Manager,dc=edf,dc=fr' -xh ldapserver.edf.fr cn=newdomadm,ou=Users,dc=edf,dc=fr

Conclusion

La politique de mapping de groupes ne semble pas intégralement respectée par l'outil net. Il semble normal de pouvoir mapper plusieurs groupes Unix vers le même groupe Windows, par contre, l'inverse serait invraisemblable. Cependant, il devrait être possible de supprimer l'un de ces mappings doublons. On comprend que les paramètres (le SID ou le nom de groupe NT) nécessités par la commande ne permettent pas de les différencier, il faudrait pouvoir préciser le nom Unix du groupe pour identifier à coup sûr le mapping, plutôt que le SID qui peut être double.

E) Ajout d'un mapping doublon (gid)

Il est en théorie impossible de mapper le même gid vers deux SID différents (l'inverse est possible, comme décrit plus haut). Cependant, essayons de le faire, afin de connaître la réaction de la commande net.

Liste des mappings existants :net groupmap list

Domain Admins (S-1-5-21-3746524048-3196343125-3229652583-512) -> domadm

Ajout d'un nouveau mapping :net groupmap add sid=S-1-5-21-3746524048-3196343125-3229652583-513 unixgroup=domadm

[2003/11/13 16:12:47, 0] passdb/pdb_ldap.c:ldapsam_add_group_mapping_entry(1884) ldapsam_add_group_mapping_entry: Group 1012 already exists in LDAPadding entry for group domadm failed!

Le mapping existant est détecté, le nouveau est refusé, la commande réagit correctement. Que se passe-t-il lorsque nous ré-itérons l'expérience via la commande 'net groupmap modify' afin d'obtenir le doublon par la suite ?

Nous sommes dans ce contexte :- domadm mappé vers 'Domain Admins'- Un nouveau groupe domusers mappé vers 'Domain Users' (RID = 513)

net groupmap list

Domain Admins (S-1-5-21-3746524048-3196343125-3229652583-512) -> domadmDomain Users (S-1-5-21-3746524048-3196343125-3229652583-513) -> domusers

On désire ensuite forcer le mapping de Domain Admins vers domusers, qui possède déjà un mapping.

net groupmap modify sid=S-1-5-21-3746524048-3196343125-3229652583-512 unixgroup=domusers

La commande fonctionne, ce qui n'est pas normal. Vérifions les mappings actifs.Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 22 sur 94

net groupmap list

Domain Admins (S-1-5-21-3746524048-3196343125-3229652583-512) -> domadmDomain Admins (S-1-5-21-3746524048-3196343125-3229652583-512) -> domusers

On s'aperçoit que c'est le deuxième mapping qui a été modifié, et non le premier ! Ce qui n'est pas ce que nous désirions.

Désormais, on ne peut plus supprimer le mapping à cause du doublon (voir problème décrit ci-dessus), ni le re-modifier :

net groupmap modify sid=S-1-5-21-3746524048-3196343125-3229652583-512 unixgroup=domusers(cette commande n'est pas utile en soi car ne modifie pas le mapping mais permet de voir si le SID peut être trouvé)

Failure to local group SID in the database

Le mapping à modifier ne peut être trouvé à cause des doublons du SID.

Conclusion

Ici, lors de la demande de modification du mapping, la commande n'a pas modifié l'entrée pour le SID désiré, mais pour le groupe correspondant au nom spécifié dans 'unixgroup'. Que s'est-il passé ? Le fait qu'aucune erreur ne soit reportée laisse déjà supposer qu'aucune vérification n'a été faite concernant l'existence d'un mapping utilisant le groupe Unix domusers.

De plus, on est ici à nouveau confronté au problème de la suppression/modification de doublons décrit ci-dessus.


IV) Récapitulatif des problèmes rencontrés - analyse

Les tests effectués révèlent plusieurs problèmes d'implémentation de la commande 'net groupmap'.

A) Propriétés utilisateur non mises à jour

- On remarque tout d'abord que l'outil net ne met pas à jour les propriétés des utilisateurs lors des modifications de mappings. Qu'il s'agisse d'un 'net groupmap add', 'net groupmap delete' ou 'net groupmap modify' (fortement supposé). Par contre, si l'utilisateur est ajouté après la création d'un mapping, les propriétés qui lui sont appliquées correspondent bien aux droits qu'il doit obtenir. cf. III)A) et III)B).

B) Mauvaise gestion des entrées multiples de SID

- Le mapping de groupe est unidirectionnel. On fait correspondre un ou plusieurs SID à un gid, et non l'inverse comme on a tendance à le penser. Il faut comprendre la mapping de groupes comme étant la création d'un groupe Windows associé à un ou plusieurs groupes Unix, non pas à la déclaration d'un groupe Unix comme étant un groupe de domaine Windows.

Si l'inverse est impossible, la déclaration de plusieurs groupes Unix pour un groupe Windows est compréhensible et réalisable : plusieurs groupes Unix peuvent faire partie des "Administrateurs de domaine". En d'autres termes, on peut posséder plusieurs fois le même SID dans la table de mappings, mais une seule occurrence de gid est possible. Le problème ici est que les outils ne semblent pas gérer ce cas de figure correctement. cf. III)D) et III)E). Il est en effet impossible de supprimer ou de modifier une entrée où le SID serait présent en double dans la table, que ce soit par son SID ou par son nom nt ('ntgroup'). Une fois une telle entrée ajoutée, il faut agir directement sur le backend pour supprimer les entrées.

C) Modification des mappings

La modification des mappings pose de nombreux problèmes.

- Tout d'abord, cette commande ne réalise pas la préparation d'un groupe à l'ajout d'attributs de groupmapping, à la différence de la commande 'net groupmap add' (cf. source/passdb/pdb_ldap.c : ldapsam_add_group_mapping_entry() : smbldap_set_mod(&mods, LDAP_MOD_ADD, "objectClass", LDAP_OBJ_GROUPMAP )). Ceci peut poser des problèmes, comme étudié au III)C).

- La compréhension de la commande elle-même pose problème. L'étude des sources (sources/utils/net_groupmap.c : net_groupmap_modify()) révèle que la commande recherche le mapping (erreur s'il y en a plusieurs) qui contient le SID passé en argument (directement ou par l'argument 'ntgroup') et modifie toutes les propriétés qui lui sont rattachées :

Ainsi les seules valeurs pouvant être modifiées sont comment, unixgroup et type. Le SID correspond à la clef de recherche de l'enregistrement dans la table de mappings. Il est impossible de le modifier et donc impossible de modifier directement le groupe Windows correspondant à un groupe Unix.

Mais alors pourquoi le problème rencontré en III)E) où le SID a été modifié pour un gid donné alors que nous attendions l'inverse ?


Le fichier sources/passdb/pdb_ldap.c : ldapsam_update_group_mapping_entry() nous apporte la réponse. En fait, la commande 'net groupmap modify' recherche le premier mapping correspondant au SID donné et le copie dans une structure temporaire. Cette structure est modifiée avec les valeurs passées en argument de la commande, puis doit être recopiée dans la table, ce que fait ldapsam_update_group_mapping_entry(). Cependant, cette fonction fait à nouveau une recherche sur l'entrée à modifier, mais cette fois-ci en se basant sur le gid contenu dans la structure ! Elle doit, a priori, trouver le même enregistrement que dans la fonction net_groupmap_modify() du fichier sources/utils/net_groupmap.c, mais ça n'est pas toujours le cas car la clef de recherche est différente. C'est ce qui s'est passé en III)E) où c'est le 2nd enregistrement qui a été trouvé et remplacé par le SID du premier enregistrement.

- Enfin, on remarque dans le III)E) qu'aucun test n'a été effectué afin de vérifier qu'aucun mapping n'utilisait déjà le nouveau groupe Unix spécifié.

D) Conclusion

La majorité des problèmes rencontrés ici semble provenir d'une mauvaise gestion des doublons de SID dans la base, autorisés par certaines commandes, interdits par d'autres. La gestion des doublons de gid semble également limitée.

De plus, aucune propriété des utilisateurs n'est mise à jour lors de la création/suppression/modification des mappings.

V) Propositions d'améliorations

A) Propriétés utilisateurs

- Pour chaque commande 'net groupmap', balayer tous les utilisateurs ayant pour groupe primaire le gid intervenant dans la modification du mapping et modifier le SID du groupe primaire de l'utilisateur en fonction (au besoin re-calculé en interne suivant la formule rid=2*gid+1001 lors de la suppression d'un mapping). Problème : l'opération va demander beaucoup de ressources si le nombre d'utilisateurs est important.

- Une autre solution est envisageable : ne plus stocker le SID du groupe primaire de l'utilisateur au sein de ses propriétés et stocker uniquement son gid Unix. On se référera ainsi à la table de mappings pour obtenir le SID de son groupe primaire. Problème : une étude préalable est nécessaire pour voir l'impact qu'aurait cette modification auprès du code déjà existant ; il faut savoir dans quelles mesures ce SID est utilisé.

B) Gestion des doublons de SID

- La première solution serait d'interdire les doublons de SID dans la table de mappings. Cette solution est peu élégante car limite les possibilités de gestion sur le domaine.

- La seconde serait d'identifier le mapping, au sein des commandes net, non pas par le SID, puisque celui-ci peut apparaître plusieurs fois, mais pas le gid Unix correspondant qui, lui, est unique.


C) Gestion des gid

- Ajouter à toutes les commandes net la fonction de vérification de doublons de gid.

D) Mise à jour de 'net groupmap modify'

- Modifier pdb_ldap.c : ldapsam_add_group_mapping_entry() pour que la fonction prépare l'enregistrement LDAP à recevoir des données de groupmapping s'il s'agit d'un posixGroup simple.


Annexe 1 : RIDs standards NT4

Cf. : Samba-HOWTO-Collection.html#groupmapping

Well-Known Entity RID Type EssentialDomain Administrator 500 User NoDomain Guest 501 User NoDomain KRBTGT 502 User NoDomain Admins 512 Group YesDomain Users 513 Group YesDomain Guests 514 Group YesDomain Computers 515 Group NoDomain Controllers 516 Group NoDomain Certificate Admins 517 Group NoDomain Schema Admins 518 Group NoDomain Enterprise Admins 519 Group NoDomain Policy Admins 520 Group NoBuiltin Admins 544 Alias NoBuiltin users 545 Alias NoBuiltin Guests 546 Alias NoBuiltin Power Users 547 Alias NoBuiltin Account Operators 548 Alias NoBuiltin System Operators 549 Alias NoBuiltin Print Operators 550 Alias NoBuiltin Backup Operators 551 Alias NoBuiltin Replicator 552 Alias NoBuiltin RAS Servers 553 Alias No


Chapitre 3 : Connectivité aux annuaires d'entreprise


I) Introduction

La réutilisation de comptes d'entreprises nécessite un import des données car le schéma de l'annuaire d'entreprise diffère de celui utilisé par Samba. La connectivité aux annuaires d'entreprises passe donc par une sélection des informations à importer et leur formatage en ajoutant les informations manquantes.

II) Méthodes d'import

Nous pouvons envisager plusieurs méthodes pour l'importation des comptes. Voici cependant une démarche commune à suivre :

- Interroger l'annuaire d'entreprise et "dumper" tous les enregistrements qui devront être copiés- Sélectionner les données à copier de manière brute- Calculer dynamiquement certaines informations non contenues dans l'annuaire source- Ajouter les enregistrements complets dans l'annuaire cible en respectant le schema Samba

- Créer dans le même temps les comptes Unix et les mappings de groupes- Créer enfin les répertoires nécessaires au stockage des données des utilisateurs (homes, profiles, netlogon)

La création des comptes peut se faire de deux manières différentes :- via les outils Samba, ce qui permet de conserver *théoriquement* l'indépendance au backend utilisé- agir directement sur le backend utilisé (LDAP)

Difficultés :

Une difficulté importante concerne l'import du mot de passe des utilisateurs. Le mot de passe étant chiffré au niveau de l'annuaire source, il est impossible de l'importer au niveau des comptes Samba si les méthodes de chiffrement utilisées diffèrent. La solution retenue est de réinitialiser tous les mots de passe aux logins des utilisateurs (par exemple), qui devront alors les modifier très rapidement.

III) Exemple de script d'import

La méthode que nous avons choisie est d'agir directement au niveau du backend LDAP. En d'autres termes, nous interrogeons le serveur source et agissons directement sur le serveur de destination, sans passer par des routines Samba pour importer les comptes.

Intervenir directement au niveau du backend offre une grande souplesse et permet de conserver une certaine indépendance vis à vis des outils Samba. Le script présenté ci-dessous génère un fichier à insérer dans l'annuaire contenant tous les comptes Samba importés. Il peut servir de base à la création d'un outil utilisant 'net user add' et 'pdbedit' pour importer les comptes.

Notez que le script ne génère que les comptes Samba. Il faudra le modifier pour qu'il crée les comptes Unix, les mappings de groupes, les répertoires (homes, profiles) et les scripts des utilisateurs.


#--------------- Début de export.sh ---------------#!/bin/sh# Importation des cn d'un annuaire LDAP vers un autre annuaire# RAZ des passwords utilisateurs avec leur login (cn)# Attention, ce script permettra de creer les comptes Samba,# Il faudra le modifier pour créer les comptes locaux## Apres execution du script : ldapadd -W -D <rootdn> -x -H ldap://<destserver> -f <fichexport># ex : ldapadd -W -D 'cn=Manager,dc=edf,dc=fr' -x -H ldap://ldapserver.edf.fr -f export.ldiff##################### Configuration ####################

### Parametres de recherche LDAP ###rootdn="cn=Manager,dc=samba,dc=edf,dc=fr"searchbase="dc=samba,dc=edf,dc=fr"searchfilter="-s sub (cn=*)" # Recherche tous les cnhost="importldap.edf.fr"

### Parametres pour l'export LDAP des utilisateurs ###userbase="ou=Users,dc=edf,dc=fr" # suffixe LDAP# Filtre du nom des utilisateurs importés : Limite a 16 caractères et " " remplacés par _# Le mot de passe de l'utilisateur sera base sur le login filtre# Ainsi que son homedir, profiledir, scriptuserfilter="sed 's/ /_/g' | cut -b 1-16"

### Fichiers ###fichexport="export.ldiff"fichdumpfull=".dump_full.ldiff"fichdumpfilt=".dump_filt.ldiff"fichtemplate="export_template.ldiff"

### Utilitaires ###lmpwdcmd="./mkntpwd -L" # Commande qui genere les passwords lanmanntpwdcmd="./mkntpwd -N" # Commande qui genere les passwords ntsmbnetcmd="/usr/local/samba/bin/net" # Commande net de Samba

# Parametres Sambasmbdomainname="VMWARE" # Nom du domaine auquel les utilisateurs vont appartenirhomeroot="\\\\\\\\VMWARE_DC" # Racine home des utilisateurs, sans \ à la finhomedrive="U:"profileroot="\\\\\\\\VMWARE_DC\\\\profiles" # Racine des répertoires de profils des utilisateursscriptext=".cmd" # Extension des scripts des utilisateurs (nom du script = login)

##################### Fonctions ####################

# Calcule attributs dynamiques - Independants de LDAPfunction attr_dyn () { # Application du filtre pour l'utilisateur user=ècho $user | eval $userfilter`

uid=ìd -u $user` if [ $? -ne 0 ] then echo " Warning - L'utilisateur $user n'existe pas en local" uid=0 fi sambarid=èxpr $uid \* 2 + 1000`

sambalocsid=`$smbnetcmd getlocalsid $smbdomainname | cut -d ':' -f 2` primgrouprid="513" # Tous les utilisateurs sont des utilisateurs du domaine pwdcanchange=`date "+%s"` # Time du changement pwdmustchange="2147483647" # Expiration, valeur fixe

sambalmpassword=`$lmpwdcmd $user` sambantpassword=`$ntpwdcmd $user`

pwdlastset=$pwdcanchange

userhomedir="$user" logonscript="$user$scriptext" userprofiledir="$user"}


# RAZ des attributs de l'utilisateurfunction raz_attr () { user="" sambarid="" sambalocsid="" primgrouprid="" pwdcanchange="" pwdmustchange="" sambalmpassword="" sambantpassword="" pwdlastset="" userhomedir="" logonscript="" userprofiledir=""}

# Ajoute notre utilisateur au fichier exportefunction add_user () { cat $fichtemplate | \ sed -e "s/<user>/$user/g" | \ sed -e "s/<userbase>/$userbase/g" | \ sed -e "s/<sambarid>/$sambarid/g" | \ sed -e "s/<sambalocsid>/$sambalocsid/g" | \ sed -e "s/<primgrouprid>/$primgrouprid/g" | \ sed -e "s/<pwdcanchange>/$pwdcanchange/g" | \ sed -e "s/<pwdmustchange>/$pwdmustchange/g" | \ sed -e "s/<sambalmpassword>/$sambalmpassword/g" | \ sed -e "s/<sambantpassword>/$sambantpassword/g" | \ sed -e "s/<pwdlastset>/$pwdlastset/g" | \ sed -e "s/<homeroot>/$homeroot/g" | \ sed -e "s/<homedrive>/$homedrive/g" | \ sed -e "s/<profileroot>/$profileroot/g" | \ sed -e "s/<userhomedir>/$userhomedir/g" | \ sed -e "s/<logonscript>/$logonscript/g" | \ sed -e "s/<userprofiledir>/$userprofiledir/g" >> $fichexport echo "" >> $fichexport echo " -> Utilisateur ajoute."}

##################### Main ####################

###### Dumping base ######

# Dumpe les infos dans un fichier localecho "Interrogation du serveur LDAP..."echo "Commande : ldapsearch -b $searchbase -D $rootdn -W -x -H ldap://$host $searchfilter"

ldapsearch -b $searchbase -D $rootdn -W -x -H ldap://$host $searchfilter > $fichdumpfullif [ $? -ne 0 ]then echo "Erreur lors de l'interrogation de $host" exit -1fi

echo "Dumping : Ok"echo ""

###### Traitement local ######

# Recupere uniquement les infos qui nous interessent (dn:,userpassword:)cat $fichdumpfull | grep -ie "^dn:" -ie "ûserpassword:" > $fichdumpfilt

# On parcourt le fichiernblignes=`wc -l $fichdumpfilt | cut -c1-8`nblignes=èxpr $nblignes + 0` # nblignes conversion en entier

# On vide le fichier de sortieecho "# --- Genere par $0 ---" > $fichexportecho "" >> $fichexport

# Boucle principale, parcourt chaque lignei=1while [ $i -le $nblignes ]do ligne=`head -$i $fichdumpfilt | tail -1` # Lis la ligne ligne=ècho $ligne | sed -e 's/,.*$//g'` # Conserve uniquement le CN et le password


if [ "ècho $ligne | grep -ie '^dn:'`" != "" ] # Un debut d'enregistrement est trouve (dn quelconque) then # Si enregistrement en attente de sauvegarde, pas à la premiere passe if [ $i -ne 1 ] then # Initialisation des valeurs calculees attr_dyn # On ajoute l'utilisateur et on efface les variables add_user fi

echo "Traitement de $ligne..."

# On efface les variables de l'utilisateur raz_attr

# On sauvegarde le cn user=ècho $ligne | cut -f 2 -d '='`

#else # Pas un debut d'enregistrement (dn), mais peut etre infos a recuperer # Recuperation des attributs dependants de LDAP #if [ "ècho $ligne | grep -ie 'ûserpassword:'`" != "" ] # Un password est trouve #then # !!! Pass reinitialise avec login #sambalmpassword=ècho $ligne | cut -f 2 -d ' '` #sambantpassword=$sambalmpassword #fi fi

i=èxpr $i + 1`done

#Fin de fichier, on sauvegarde le dernier utilisateuradd_user

###### Fin ######

# Termineecho ""echo "=> Utilisateurs Exportes dans $fichexport"echo ""#--------------- Fin de export.sh ---------------

L'exécution du script produit, dans l'ordre :

- Une dumping des utilisateurs de la base LDAP spécifiée dans la partie configuration- Une analyse du fichier dumpé et une extraction de chaque cn (utilisateur)- Le calcul de chaque propriété non déterminée des utilisateurs- La création d'un fichier export.ldiff (par défaut) contenant les utilisateurs exportés

Ce script utilise un template pour créer le fichier final contenant les utilisateurs exportés :Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 32 sur 94

#-------------- Début de export_template.ldiff --------------# Utilisateur : "<user>"dn: uid=<user>,<userbase>uid: <user>sambaSID: <sambalocsid>-<sambarid>sambaPrimaryGroupSID: <sambalocsid>-<primgrouprid>sambaPwdCanChange: <pwdcanchange>sambaPwdMustChange: <pwdmustchange>sambaLMPassword: <sambalmpassword>sambaNTPassword: <sambantpassword>sambaPwdLastSet: <pwdlastset>sambaAcctFlags: [U ]objectClass: sambaSamAccountobjectClass: accountsambaHomePath: <homeroot>\<userhomedir>sambaHomeDrive: <homedrive>sambaLogonScript: <logonscript>sambaProfilePath: <profileroot>\<userprofiledir>#-------------- Fin de export_template.ldiff --------------

Les éléments dynamiques à calculer pour chaque utilisateur comprennent :

[Cf. nom des variables au sein du template]- user : login de l'utilisateur, fourni par LDAP (cn avec espaces remplacés par des '_' et tronqué à 16 caractères)- sambalocsid : sid local du domaine (net getlocalsid <nom de domaine>)- sambarid : uid unix * 2 + 1000- primgrouprid : groupe primaire de l'utilisateur, 513 car "utilisateur du domaine"- pwdcanchange : date à partir de laquelle le mot de passe peut être modifié, date "+%s"- pwdmustchange : expiration du mot de passe, valeur fixe : 2147483647- sambalmpassword : mot de passe lanman, réinitialisé au login gâce à l'outil mkntpwd (http://www.demog.berkeley.edu/~aperrin/tips/src/mkntpwd.tar.gz)- sambantpassword : mot de passe nt, réinitialisé au login- pwdlastset : date a laquelle a été modifié le mot de passe (= pwdcanchange)- userhomedir : chemin UNC du répertoire de l'utilisateur- logonscript : nom du script de l'utilisateur au sein du partage netlogon- userprofiledir : chemin UNC du profil de l'utilisateur

Après l'exécution du script, il reste à inscrire les enregistrements contenus dans le fichier export.ldiff :

ldapadd -W -D <rootdn> -x -H ldap://<serveur ldap destination> -f export.ldiff


Chapitre 4 : Etat des lieux concernant 'Net Vampire'


I) Introduction

Nous allons tester la migration de comptes depuis un contrôleur de domaine NT4. La version da Samba utilisée est la version Samba 3.0.1pre3. Nous utiliserons tout d'abord un backend LDAP, puis un backend TDB.

Nous disposons déjà d'un contrôleur NT4 en fonctionnement. Voici sa configuration :

- Nom de domaine : VMWARE- Nom netbios du contrôleur de domaine VMWARE_PDC- 2 groupes : Groupe1, Groupe2- 4 utilisateurs : Groupe1User (appartient au groupe 1), Groupe2User (groupe 2), Groupe12User (groupes 1 et 2), VMWAREAdmin (administrateur du domaine).- Nous disposons également des groupes déjà prédéfinis par Windows- Les profils sont stockés sur \\VMWARE_PDC\profiles\<nom-utilisateur>- Les homes sont stockés sur \\VMWARE_PDC\homes\<nom-utilisateur>

II) Préparation du serveur GNU/Linux à la migration

Notre serveur doit être déclaré BDC à notre domaine VMWARE.

- Créer deux groupes qui vont servir de groupes primaires Unix à nos utilisateurs et machines importés :groupadd vmwareusersgroupadd vmwaremachines

- Il faut ensuite modifier le fichier smb.conf du serveur pour le déclarer BDC :

[...]workgroup = VMWAREnetbios name = VMWARE_BDCencrypt passwords = yes

os level = 40domain logons = Yesdomain master = Nolocal master = No

; Utilisé lors du net vampireadd machine script = /usr/sbin/useradd -g vmwaremachines -c "Samba Machine" -d /dev/null -s /bin/false '%u'add user script = /usr/sbin/useradd -g vmwareusers -c "Samba User" -d /dev/null -s /bin/false '%u'add group script = /usr/sbin/groupadd '%g'add user to group script = /usr/sbin/usermod -G `/usr/bin/id -G '%u' | /bin/sed 's/ /,/g'`,'%g' '%u'[...]

- Arrêter les démons Samba/etc/init.d/samba stop


- Créer un compte sur le contrôleur principal de domaine pour notre machine Samba (via le gestionnaire de serveurs)

- Redémarrer Samba :/etc/init.d/samba start

- Joindre le domaine :net rpc join -S VMWARE_PDC -w VMWARE -U Administrateur

Le BDC devrait alors apparaître comme contrôleur de domaine secondaire au niveau du gestionnaire de serveurs NT4.

III) Import des comptes : net vampire

- L'import des comptes du contrôleur de domaine se fait via la commande :net rpc vampire -S VMWARE_PDC -w VMWARE -U Administrateur

Nous sommes ici confrontés à un premier problème : les caractéristiques des noms de groupes/utilisateurs sous Unix ne sont pas les mêmes que sous Windows. Lors de l'import, tous les noms de groupes et d'utilisateurs (ici ceux prédéfinis par Windows en version Française) possédant des caractères spéciaux (espace, point, accents, apostrophe) et de plus de 16 caractères posent problème. Il existe une solution simple à ce problème : renommer tous les noms de groupes et d'utilisateurs pour qu'ils soient conformes aux règles de nommage Unix. Windows NT ne fournit pas d'outils pour le faire en standard ; on pourra par exemple utiliser un outil commercial tel que ultraadmin de DorianSoft (http://www.doriansoft.com/ultraadmin).

Une autre possibilité est de modifier le fichier smb.conf pour qu'il modifie "à la volée" les noms de comptes à ajouter sous Unix. Le problème est que ceci va permettre d'ajouter les comptes sous Unix, mais pas sous Samba, car les comptes Samba sont ajoutés via un mécanisme interne qu'il n'est pas possible de configurer.

Cette solution n'est donc pas totalement satisfaisante ; nous allons renommer nos groupes et utilisateurs manuellement pour la suite des tests. Voici comment nous avons procédé :

Les groupes :Administrateurs du domaine -> AdminDomUtilisa. du domaine -> UtilDomInvités -> InvitesInvités du domaine -> InvitDomOpérateurs de compte -> OpCompteOpérateurs de sauvegarde -> OpSauvOpérateurs de serveur -> OpServOpérateurs d'impression -> OpImpr

Les utilisateurs :Invité -> Invite

Désormais, nous pouvons migrer nos utilisateurs.

net rpc vampire -S VMWARE_PDC -w VMWARE -U Administrateur

Cependant, un autre problème se présente, propre au backend LDAP :Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 36 sur 94

Fetching DOMAIN databaseSAM_DELTA_DOMAIN_INFO not handledCreating unix group: 'AdminDom'Creating unix group: 'UtilDom'Creating unix group: 'InvitDom'Creating unix group: 'Groupe1'Creating unix group: 'Groupe2'Creating account: Administrateur[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_account_info(492) Primary group of Administrateur has no mapping!Creating account: Invite[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_account_info(492) Primary group of Invite has no mapping!Creating account: Groupe1User[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_account_info(492) Primary group of Groupe1User has no mapping!Creating account: Groupe2User[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_account_info(492) Primary group of Groupe2User has no mapping!Creating account: Groupe12User[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_account_info(492) Primary group of Groupe12User has no mapping!Creating account: VMWAREAdmin[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_account_info(492) Primary group of VMWAREAdmin has no mapping!Creating account: VMWARE_BDC$[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_account_info(492) Primary group of VMWARE_BDC$ has no mapping![2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_group_mem_info(594) Could not find global group 512[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_group_mem_info(594) Could not find global group 513[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_group_mem_info(594) Could not find global group 514[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_group_mem_info(594) Could not find global group 1001[2003/11/18 16:10:26, 0] utils/net_rpc_samsync.c:fetch_group_mem_info(594) Could not find global group 1002Fetching BUILTIN databaseSAM_DELTA_DOMAIN_INFO not handledCreating unix group: 'Administrateurs'Creating unix group: 'Duplicateurs'Creating unix group: 'Invites'Creating unix group: 'OpCompte'Creating unix group: 'OpImpr'Creating unix group: 'OpSauv'Creating unix group: 'OpServ'Creating unix group: 'Utilisateurs'

La commande 'net vampire' ne semble pas fonctionner correctement avec le backend LDAP... Les groupes et les mappings correspondants ne sont pas créés. En revanche, si l'on modifie le fichier smb.conf pour qu'il utilise un backend tdb :

[...]passdb backend = tdbsam, guest[...]

La commande net vampire fonctionne cette fois-ci parfaitement :Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 37 sur 94

net rpc vampire -S VMWARE_PDC -w VMWARE -U Administrateur

Fetching DOMAIN databaseSAM_DELTA_DOMAIN_INFO not handledCreating unix group: 'AdminDom'Creating unix group: 'UtilDom'Creating unix group: 'InvitDom'Creating unix group: 'Groupe1'Creating unix group: 'Groupe2'Creating account: AdministrateurCreating account: InviteCreating account: Groupe1UserCreating account: Groupe2UserCreating account: Groupe12UserCreating account: VMWAREAdminCreating account: VMWARE_BDC$Group members of AdminDom: Administrateur,VMWAREAdmin,Group members of UtilDom: Administrateur(primary),VMWARE_BDC$(primary),Groupe1User(primary),Groupe2User(primary),Groupe12User(primary),VMWAREAdmin(primary),Group members of InvitDom: Invite(primary),Group members of Groupe1: Administrateur,Groupe1User,Groupe12User,Group members of Groupe2: Administrateur,Groupe2User,Groupe12User,Fetching BUILTIN databaseSAM_DELTA_DOMAIN_INFO not handledCreating unix group: 'Administrateurs'Creating unix group: 'Duplicateurs'Creating unix group: 'Invites'Creating unix group: 'OpCompte'Creating unix group: 'OpImpr'Creating unix group: 'OpSauv'Creating unix group: 'OpServ'Creating unix group: 'Utilisateurs'

Les groupes et utilisateurs sont correctement créés (Unix et Samba), ainsi que les mappings correspondants. Les utilisateurs peuvent se connecter sur le contrôleur de domaine et disposent de leurs droits respectifs.

- Nous pouvons utiliser les commandes suivantes pour le vérifier :

getent passwdgetent grouppdbedit -vLnet user info <utilisateur> -U Administrateur

A ce stade, les comptes, c'est à dire les informations de connexion concernant les utilisateurs, sont migrés. Il reste une tâche importante à effectuer : la migration des données des utilisateurs, à savoir les répertoires homes, profiles, netlogon et tout répertoire partagé supplémentaire.

Conclusion :


Si la migration de comptes est tout à fait opérationnelle avec un backend tdb, elle semble plus hasardeuse avec un backend LDAP. Samba offre donc une transparence d'accès aux backends, mais les tests démontrent que ces accès n'en sont pas au même stade de développement et peuvent réagir de manières différentes suivant le backend employé.D'autre part, le renommage des comptes à la volée ne semble pas faisable sans une modification des outils Samba. En effet, les directives du fichier smb.conf concernent uniquement la création du compte Unix et non pas Samba, qui est réalisée via un mécanisme interne.

IV) Migration des données et des ACLs

La migration des données est une autre étape de la migration des comptes utilisateurs. La difficulté principale dans cette étape est de conserver les droits de chaque utilisateur et groupe sur les fichiers, en d'autres termes, de conserver les ACLs présentes au niveau des partages. Deux politiques sont envisageables. La première serait de diviser l'opération en deux : tout d'abord la recopie des fichiers sur le serveur Samba, puis la recopie des informations de sécurité. La seconde serait d'utiliser un outil permettant de faire tout ceci de manière transparente.

Dans tous les cas, il faudra prendre soin de re-créer chaque partage à l'identique sur le serveur (à déclarer dans le fichier smb.conf). Au sein de ces partages seront recopiés les fichiers du serveur original sur lesquels seront appliqués les mêmes droits (traduits en droits POSIX).

Malheureusement Samba ne fournit pas d'outil permettant d'effectuer ces deux opérations de manière simple. Deux outils sont toutefois intéressants : smbtar (script utilisant smbclient) et smbcacls.

Quatre solutions sont envisageables :

- La première est de copier les fichiers et répertoires de partages du PDC sur le BDC (via smbtar par exemple) et de réinitialiser par la suite les ACLs de manière manuelle (via setfacl). Cette manière de procéder ne convient pas à un grand nombre de fichiers et de groupes/utilisateurs. Elle peut cependant convenir pour un test de migration.

- La seconde solution s'inspire de la première : tout d'abord copier les fichiers manuellement (via smbtar par exemple), puis par la suite copier les ACLs, mais cette fois de manière automatique (via un script ou un programme natif). On pourrait par exemple générer un fichier contenant la liste d'ACLs sur le serveur NT et le réutiliser sur le serveur Samba pour les appliquer après la copie des fichiers. Une autre méthode plus simple serait de copier et d'appliquer les ACLs directement depuis le serveur Samba (avec smbcacls). Dans tous les cas, cette solution implique le développement de l'outil qui appliquera les ACLs. Deux outils sont particulièrement intéressants :Dumpsec (Freeware pour Windows) : http://www.somarsoft.comsmbcacls (outil de la suite Samba)

- La troisième solution serait de copier depuis le PDC NT l'intégralité des fichiers sur les partages du serveur Samba avec un outil qui tient compte des ACLs. Cette solution semble simple à mettre en oeuvre car Samba gère correctement les ACLs au niveau des partages CIFS ; l'outil pourra donc appliquer les ACLs au niveau des fichiers partagés par Samba de manière transparente.

Quatre outils semblent intéressants :


Robocopy, Scopy, PermCopy (Windows Resource Kit)XXCopy (Commercial) : http://www.xxcopy.com : n'a pas pu être testé

Les tests effectués avec Robocopy (version XP010 pour XP, robocopy c:\export\profiles \\VMWARE_BDC\profiles /E /COPY:DATSO) ont révélé quelques limites : les groupes UNIX impliqués dans les ACLs ne correspondent pas toujours aux groupes NT et il n'a pas été possible dans tous les cas de copier les propriétaires (utilisateur et groupe) des fichiers appartenant aux Administrateurs.

- La dernière solution serait de copier les fichiers depuis le serveur Samba. On pourrait ici, solution idéale, envisager de modifier l'outil smbclient pour qu'il tienne compte des ACLs.

Dans tous les cas, il faut disposer d'un compte ayant accès à chacun des fichiers et répertoires à migrer afin de pouvoir lire les ACLs.

Conclusion :

La copie des données/acls est la partie la plus difficile de la migration. Les recherches effectuées n'ont pas montré de méthode "clefs en main" pour la réaliser et les tests ne se sont pas révélés concluants. Les trois méthodes qui paraissant les mieux adaptées sont tout d'abord la recopie des ACLs avec Smbacls depuis le serveur Samba, ensuite la méthode du "push" de fichiers et d'ACLs depuis le PDC NT (robocopy, scopy...) et enfin la méthode idéale : la modification de smbclient pour lui ajouter le support des ACLs lors de la copie de fichiers. Cette dernière méthode implique une bonne connaissance du code source de Samba.

V) Promotion du BDC en PDC

A ce stade, pour que le contrôleur sur lequel on vient de migrer les comptes puisse prendre le relais du PDC NT, il reste quelques manoeuvres à effectuer :

- Modifier son nom netbios dans le fichier smb.conf pour indiquer le nom netbios exact de notre PDC :

[...]workgroup = VMWAREnetbios name = VMWARE_PDCserver string = VMWARE PDCencrypt passwords = yes[...]

- Changer les options concernant le contrôle du domaine :

[...]domain logons = yesos level = 65domain master = Yeslocal master = Yes[...]

- Eteindre le PDC NT4

- Redémarrer Samba :Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 40 sur 94

/etc/init.d/samba restart

Le domaine est désormais contrôlé par notre PDC migré.

VI) Conclusion

La migration semble une opération délicate et donne des résultats hétérogènes en fonction du backend utilisé. Un backend tdb permet une migration des comptes automatique, complète et opérationnelle, tandis que le backend LDAP pose problème.

La migration des données n'est pas réalisable simplement si l'on désire conserver les ACLs des fichiers et répertoires. Le développement d'un outil est ici nécessaire, à moins que l'on puisse utiliser les outils Microsoft fournis dans le Windows Resource Kit pour copier les fichiers sur le serveur Samba depuis le PDC NT. Cette méthode ne s'est pas révélée concluante lors des tests ('Network error 5' avec Robocopy et Permcopy n'a pas fonctionné).


Chapitre 5 : Etat des lieux des outils d'administration existants


I) Introduction

Cet état des lieux va permettre d'étudier et de comparer les outils d'administration Samba existants. Nous allons ainsi mettre en valeur les atouts et les faiblesses de chacun afin de pouvoir établir une carte d'identité de l'outil d'administration idéal. Cette étude pourra ainsi servir de base au développement d'un outil d'administration complet.

II) Outils existants

Voici la liste une liste des outils existants, graphiques ou non, permettant d'administrer Samba :

A) Outils en lignes de commandes

- Outils de la suite Samba- Smbldap-tools (http://samba.idealx.org)

B) Outils graphiques

- Swat (inclus dans Samba)- Modules Webmin - http://www.webmin.com/standard.html (et livré dans le tarball webmin 1.121) - http://webmin.idealx.org (idxldapaccounts)- LDAP Account Manager (http://lam.sourceforge.net/)- Smbconftool (http://www.eatonweb.com/samba/) - beta non mise à jour depuis plus d'un an- SLOT (http://slot.netfoster.de/index.php) - Allemand, non open-source- FAUS (http://faus.sourceforge.net/english.html)- SambaLinkQ (http://www.spanware.com/linkq/sambalinkq.html)

Nous nous limiterons à l'étude de ces projets car ils sont indépendants du desktop et de l'OS utilisés, et encore actifs à ce jour.

Non testés :

Voici une sélection d'autres projets...

- Module Webmin Samba-ldap (http://www.iniflux.com/webmin/samba-ldap/samba-ldap.xml) - non disponible pour debian- Smbedit (http://www.sambatech.demon.co.uk/mindex.htm) - sous Win9x- Mambo (http://http://www.chilliware.net) - commercial, site fermé- GnoSamba (http://www.open-systems.com/gnosamba.html) - site fermé (disponible sur ftp://ftp.us.debian.org/debian/pool/main/g/gnosamba/)- Gnomba (http://gnomba.sourceforge.net/) - dvpt stoppé- KSambaPlugin (http://ksambakdeplugin.sourceforge.net/) - s'intègre à kcontrol de KDE- Samba Configuration Tool, Fedora Project (http://fedora.redhat.com/projects/config-tools/redhat-config-samba.html) - Dépendant des outils RedHat (consolehelper)- Samba facile (http://vuillod.frederic.free.fr/SambaFacile/default.htm) - Borland Kylix


III) Etude des fonctionnalités des outils

A) Outils en ligne de commande

1) Outils Samba

Il s'agit des outils de référence livrés en standard dans la suite Samba. Il permettent d'administrer intégralement un domaine en lignes de commandes.

Gestion des utilisateurs/groupes :- net : commande simulant la commande net Windows. Offre de nombreuses options pour administrer le domaine : manipulation d'utilisateurs, de groupes, des mappings de groupes, jonction au domaine...- pdbedit : permet d'ajouter/supprimer/lister/modifier les utilisateurs Samba (backend quelconque)- smbpasswd : ajoute un utilisateur ou change son mot de passe, change le mot de passe du binddn LDAP- wbinfo : manipule les informations relatives à winbind (création d'utilisateurs/groupes...)

Gestion du réseau : - rpcclient : permet d'exécuter, via un shell, des commandes rpc sur un serveur CIFS- nmblookup : à la manière de nslookup, permet de résoudre des noms netbios vers une adresse IP. Interroge le serveur nmbd- findsmb (script utilisant nmblookup) : permet d'afficher tous les serveurs smb sur le réseau local- smbtree : affiche le voisinage réseau en mode texte

- smbclient : client ftp-like permettant le transfert de fichiers avec un serveur CIFS- smbtar (script utilisant smbclient) : permet d'effectuer des sauvegardes de fichiers situés sur un serveur CIFS- smbmount, smbmnt : monte un partage CIFS sur un répertoire local- smbumount : démonte un répertoire CIFS monté localement- smbcquotas : manipule les quotas sur des serveurs CIFS- smbcacls : manipule les acls d'un partage CIFS

- smbspool : permet d'utiliser une imprimante connectée à un serveur CIFS

- ntlm_auth (nécessite Winbind) : permet une authentification ntlm (utile pour des programmes externes)

Maintenance :- tdbdump : visualise un fichier tdb local- tdbbackup : teste l'intégrité d'un fichier tdb local et permet d'en faire une sauvegarde- testparm : vérifie la validité des options du fichier de configuration smb.conf- testprns : teste la validité des imprimantes spécifiées dans le fichier printcap local- profiles : permet de modifier les SIDs contenus dans un fichier NTUSER.DAT et NTCONFIG.POL(cf. : http://www.richardsharpe.com/samba-stuff.html et http://samba.org/~jelmer/kregedit)- editreg : permet de visualiser les SIDs contenus dans un fichier NTUSER.DAT et NTCONFIG.POL


Démons :- smbd : service de fichiers et d'impression aux clients CIFS- nmbd : service de nommage netbios - winbindd : utilise pam et nsswitch pour authentifier des utilisateurs Windows sur une machine Unix- swat : serveur http (port 901) offrant une interface de configuration de Samba

- smbcontrol : permet de contrôler les démons Samba- smbstatus : affiche les connexions actives au service smbd

2) Smbldap-tools (http://samba.idealx.org)

SmbLdapTools est une suite de scripts perl développée par idealx (http://samba.idealx.org). Elle offre plusieurs outils en ligne de commande permettant de gérer les comptes (utilisateurs/groupes) Unix et Samba (LDAP uniquement).

Gestion des utilisateurs :- smbldap-useradd.pl : ajoute un utilisateur- smbldap-userdel.pl : efface un utilisateur- smbldap-usermod.pl : édite les propriétés d'un utilisateur- smbldap-usershow.pl : affiche les propriétés d'un utilisateur- smbldap-passwd.pl : modifie le mot de passe d'un utilisateur

Gestion des groupes :- mbldap-groupadd.pl : ajoute un groupe- smbldap-groupdel.pl : efface un groupe- smbldap-groupmod.pl : édite les propriétés d'un groupe- smbldap-groupshow.pl : affiche les propriétés d'un groupe

Migration de données :- smbldap-migrate-accounts.pl : utilise les dumps créés par pwdump sous NT pour importer les utilisateurs/machines.- smbldap-migrate-groups.pl : importe les groupes d'utilisateurs- smbldap-populate.pl : crée les entrées initiales nécessaires dans l'annuaire LDAP


B) Outils graphiques

1) SWAT (Samba Web Administration Tool - http://www.samba.org)

Swat implémente un mini serveur web (port 901). Il est livré avec la suite Samba.

Fonctionnalités :

- Accès aux pages de man des outils de la suite ainsi qu'à différentes sources d'information (Samba Howto Collection, Using Samba, ...)- Configuration de la section Globale du fichier smb.conf- Edition de chaque partage du serveur- Configuration des imprimantes- Wizard permettant de configurer de manière simple le serveur- Visualisation du statut des démons smbd et nmbd ainsi que des connexions actives- Visualisation du fichier de configuration- Ajout/suppression des utilisateurs (Samba uniquement), modification de leurs mots de passe (sur un serveur distant quelconque), activation/désactivation d'un compte.

SWAT ne conserve pas l'ancien fichier de configuration et l'écrase par le nouveau. Il ne conserve donc pas les commentaires. Il ne permet pas non plus de gérer les opérations concernant les groupes d'utilisateurs.

2) Modules Webmin

Les modules Webmin supposent l'installation préalable de Webmin (http://www.webmin.com). La connexion au service webmin se fait via http sur le port 10000.

Module Samba (livré avec webmin 1.121 et sur http://www.webmin.com/standard.html)

Indépendant du backend utilisé. Il offre les fonctionnalités suivantes :

- Gestion de la partie [Global] du fichier de configuration à travers différents thèmes (Unix networking, Windows networking, Authentication, Misc)- Gestion des imprimantes (section globale et partages)- Gestion des partages de fichiers- Statut des connexions- Gestion des utilisateurs Samba- Gestion des groupes Samba- Import d'utilisateurs Unix vers Samba- Option de synchronisation des modification d'utilisateurs et de groupes entre Unix et Samba (si le module Webmin 'Users and Groups' est utilisé)

Idxldapaccounts (http://webmin.idealx.org)

Permet d'administrer les comptes Samba sur un annuaire LDAP.

- Gestion des utilisateurs et groupes Samba- Gestion des propriétés de chaque compteSamba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 46 sur 94

3) LAM : Ldap Account Manager (http://lam.sourceforge.net)

Scripts PHP. Outil dépendant d'un backend LDAP.

- Gestion des utilisateurs Unix et Samba - Gestion des Groupes Unix et Samba (mappings via enregistrements LDAP)- Gestion des comptes machines- Création et suppression automatiques des répertoires homes- Gestion des quotas- Gestion de différents domaines- Export des informations de comptes sous forme de fichier PDF- Possibilité d'insertion de données en masse à partir d'un fichier texte formaté- Gestion de profils d'administration

4) Smbconftool (http://www.eatonweb.com/samba)

Utilise Java pour une meilleure portabilité.

- Permet d'éditer le fichier smb.conf (gestion des partages)- Conserve les commentaires dans le fichier smb.conf

5) Slot (http://slot.netfoster.de/index.php)

Non open-source. Utilise le fichier smbpasswd.

- Gestion des utilisateurs et groupes- Création des scripts de connexion des utilisateurs avec gestion des mappings de lecteurs- Gestion des partages- Statut du serveur

6) Faus (http://faus.sourceforge.net/english.html)

Ensemble de scripts CGI PERL, utilisent le fichier smbpasswd

- Permet de gérer les utilisateurs Unix et Samba

7) SambaLinkQ (http://www.spanware.com/linkq/sambalinkq.html)

Utilise les librairies Qt3 (http://www.trolltech.com).

- Génère un fichier smb.conf et permet de gérer la section [global] et les partages- Affiche également le statut du serveur


IV) Etude des résultats

Plusieurs points sont intéressants à relever :

Aucun outil convivial ne semble permettre d'administrer de manière totale le serveur Samba. Beaucoup d'outils ne permettent d'éditer que le fichier smb.conf (configuration globale et partages), sans offrir la possibilité de gérer les comptes d'utilisateurs et de groupes. Les outils de la suite Samba restent difficile à prendre en mains pour un administrateur non expérimenté.

La plupart des outils existants sont assez vieillissants et ne se sont pas adaptés aux nouvelles foncionnalités de Samba 3. Ainsi, certains proposent encore d'éditer le fichier smbpasswd, qui n'est quasiment plus utilisé à l'heure actuelle.

Trois outils sortent du lot, bien que ne permettant pas un administration complète du serveur : SWAT, le module webmin de base et lam.

V) Tableaux comparatifs des outils

Deux aspects principaux sont à prendre en compte dans l'administration d'un domaines Samba :

- Il y a tout d'abord la gestion du fichier smb.conf : elle va permettre de modifier la section [global] et chaque partage et imprimantes, ainsi que de configurer le serveur de manière générale.- La gestion des utilisateurs et des groupes : deux types de comptes sont à créer : les comptes Unix et Samba ; l'outil doit permettre de les gérer de manière transparente afin de rester relativement simple d'emploi.

Il ressort des tests effectués que la plupart des outils ne proposent que l'une ou l'autre de ces fonctionnalités. Aucun outil n'est complet et propose d'administrer totalement le domaine Samba. Certains outils complètent cependant leurs fonctionnalités par :

- La gestion du serveur : possibilité d'accéder aux démons et de voir les connexions actives.- La gestion du domaine en exploitant les nouvelles fonctionnalités offertes par Samba 3 telles que le mapping de groupes (aucun ne propose d'approbations, de mécanisme de migration...).

Enfin, on remarque que certains outils vont manipuler directement le backend plutôt que d'utiliser les outils de la suite Samba et être ainsi dépendants du backend utilisé (smbpasswd, LDAP...).

Toutes ces informations sont récapitulées dans les tableaux comparatifs ci-dessous.


Tableau fonctionnel des outils :

Nom Edition smb.conf(globale, partages, imprimantes)

Edition des Acteurs (usr/gpe/mac)

Statut du serveur Indépendant d'un backend particulier

Import/Export de données

Divers

Outils de la suite Samba

Non, édition manuelle

Oui (utilisateurs et groupes Samba)

Oui Oui Oui, export Xml via pdbedit

Lignes de commandes

Smbldap-tools Non, édition manuelle

Oui (utilisateurs et groupes Unix + Samba)

Non Non (LDAP) Oui, import des utilisateurs et groupes NT

Lignes de commandes

SWAT Oui + visualisation du fichier

Oui (utilisateurs Samba)

Oui Oui Non Wizard de configuration, Documentation en ligne

Module Webmin standard

Oui Oui (utilisateurs et groupes Samba)

Oui Oui Oui, import des utilisateurs Unix

Synchronisation utilisateurs et groupes Unix/Samba

IdxLdapAccounts Non Oui Non Non (LDAP) NonLam Non Oui (Unix + Samba) Non Non (LDAP) Oui, export des

comptes en PDF ; Import à partir de fichiers formatés

Mapping de groupes, gestion des répertoires homes, quotas, multi-domaines, profils d'administration

SmbConftool Oui Non Non Oui Non Java, Conserve les commentaires du fichier de configuration

SLOT Oui (partages) Oui (Samba) Oui Non (Smbpasswd) Non Non open-source, création des scripts netlogon

Faus Non Oui (Unix + Samba) Non Non (Smbpasswd) NonSambaLinkQ Oui Non Oui Oui Non

Tableau technique des outils :

Nom Création Date de MAJ Version Lignes de code

Licence Lang. Sources dispo.

Gratuit Popularité URL

Outils de la suite Samba

1992 14/11/2003 3.0.1pre3

400000+ GPL C Oui Oui +++++ http://www.samba.org

Smbldap-tools 21/02/2003 28/11/2003 0.8.2 4000+ GPL Perl Oui Oui ++++ http://samba.idealx.orgSWAT ? 14/11/2003 3.0.1pre

32000+ GPL C Oui Oui ++++ http://www.samba.org

Module Webmin standard

? 02/11/2003 1.120 15000+ BSD (nouvelle)* ?

Perl Oui Oui ++++ http://www.webmin.com/standard.html

IdxLdapAccounts

? 15/04/2003 0.2-4 6000+ GPL Perl Oui Oui http://webmin.idealx.org

Lam 04/02/2003 29/10/2003 0.4 27000+ GPL Php Oui Oui ++++ http://lam.sf.netSmbConftool ? ? 1.0 beta 1200+ GPL Java Oui Oui http://

www.eatonweb.com/samba/

SLOT ? ? 0.8 ? ? C++ - Qt2

Non Oui pour un usage non-comm.

http://slot.netfoster.de

Faus 13/11/2002 01/07/2003 1.3 1400+ GPL Perl - Cgi

Oui Oui http://faus.sourceforge.net/english.html

SambaLinkQ 31/08/1999 24/10/2002 2.02 3800+ BSD (originale) ?

C++ - Qt3

Oui Oui http://www.spanware.com/linkq/sambalinkq.html

* Webmin est sous cette licence d'origine, mais la licence BSD permet l'utilisation de licences plus restrictives telles que GPL. Un module Webmin peut donc être diffusé sous ce type de licence.


VI) Les retours des utilisateurs / Choix d'une solution d'administration

Mailing-list [email protected] (http://lists.samba.org/archive/samba/2003-December/076146.html)

Hi all,

Just wondering what Samba administration tool is the most frequently used ?What tool do admins use daily ? I've tried Cmd line / Samba tools, Swat,Webmin, LAM... and still haven't found a full-featured one and*user-friendly* one...

Many Thanks :)

Ganael.

-----------------------------------------------------------------------------------------------------------------------------------

On Tue, 2 Dec 2003, Ganael LAPLANCHE wrote:

> Hi all,>> Just wondering what Samba administration tool is the most frequently used ?> What tool do admins use daily ? I've tried Cmd line / Samba tools, Swat,> Webmin, LAM... and still haven't found a full-featured one and> *user-friendly* one...

I am very interested in seeing answers to this question as I am currentlywriting the LDAP chapter of the "Samba-3 by Example" book and would liketo recommend a good tool.

I too have spent a lot of time evaluating the LDAP admin tools, as well ashow best to advise newer admins (those who have yet to cut their teeth onLDAP) how best to configure an LDAP backend.

SWAT does NOT do LDAP configuration.

LAM is nice, but has a little maturation aheead of it. It's very clsoethough.

I have not tried the IDEALX Webmin tool yet. That's on my plate fortomorrow, as I start to write the new chapter.

It's 3:21am here and I have been solidly at this since 8am yesterdaymorning. Time for bed now. I will see what your request delivers. Thanksfor asking.

- John T.-- John H TerpstraEmail: [email protected]

-----------------------------------------------------------------------------------------------------------------------------------

For LDAP I still use and recommend gq (http://biot.com/gq) on linux/unix systems. Another nice tool is JXplorer (http://www.jxplorer.org), which Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 50 sur 94

is written in Java and can be used on any operating system that has a Java runtime.

For creating and modifying users/groups I use a slightly cutomized version of the Idealx smbldap-tools, which were of great help especially at the beginning of our LDAP-era. :-)

For system administration, e.g. editing smb.conf, vim (http://www.vim.org) is all I need.

cu,Uwe

Mailing List [email protected] (http://listes.ujf-grenoble.fr/wws/arc/samba-fr/2003-12/msg00013.html)

Outils d'administration Samba Ganael LAPLANCHE # From: "Ganael LAPLANCHE" <[email protected]># To: [email protected]# Subject: Outils d'administration Samba# Date: Wed, 3 Dec 2003 11:02:55 +0100# Sensitivity:

Bonjour à tous,

J'aimerais connaitre votre (vos) outil(s) préféré(s) en matièred'administration Samba... Quest-ce que vous, utilisateurs etadministrateurs Samba, utilisez quotidiennement pour configurer vosserveurs préférés ? La ligne de commandes, SWAT, Webmin... autre ??? Jecherche un outil complet mais je ne l'ai pas encore trouvé :(((

Merci !

Ganael

-----------------------------------------------------------------------------------------------------------------------------------

Re: [samba-fr] Outils d'administration Samba Stephane Boireau # From: Stephane Boireau <[email protected]># To: [email protected]# Subject: Re: [samba-fr] Outils d'administration Samba# Date: Wed, 3 Dec 2003 14:58:38 +0100# Organization: MENRT# References: <[email protected]># User-agent: KMail/1.5

Bonjour,

Il y a swat et webmin que je n'utilise pas;o).

Il y a aussi "samba facile" que tu n'as pas cité......et que je n'ai pas testé;o).

Pour ma part, je préfère la ligne de commande.Au moins, je sais ce qu'il y a dans mon smb.confC'est moi qui l'y ai mis.

Et c'est à moi de faire attention en créant les bons dossiers sous Linux;o).(ceux qui correspondent aux partages déclarés avec les droits apprpriés)


Amicalement.--Stéphane Boireau.-----------------------------------------------------------------------------------------------------------------------------------Re: [samba-fr] Outils d'administration Samba Nicolas Cousin # From: Nicolas Cousin <[email protected]># To: [email protected]# Subject: Re: [samba-fr] Outils d'administration Samba# Date: Thu, 04 Dec 2003 11:31:57 +0100# Organization: SIAL# References: <[email protected]># Reply-to: [email protected]# User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031115 Debian/1.5-3.he-1

La ligne de commandes me semble (pour mon cas) un outil qui modifie le smf.conf comme j'ai envie.C'est à dire qu'avec SWAT ou WEBMIN (que j'ai testés) lorsqu'on modifie qqchose, un fichier smb.conf est recrée automatiquement.Le problème, c'est que si on personnalise le smb.conf, tout est écrasé à chaque modifs effectuées avec swat ou webmin (commentaires etc...)

Cordialement.

-- Nicolas COUSINTechnicien réseauEquipe système

Email : [email protected] Tél : 03-20-95-69-25Web : www.ac-lille.fr

-----------------------------------------------------------------------------------------------------------------------------------

# From: "Thierry FOURNIER" <[email protected]># To: <[email protected]># Subject: Re: [samba-fr] Re: Outils d'administration Samba# Date: Mon, 8 Dec 2003 10:33:05 +0100# References: <[email protected]> <[email protected]>

ce qui est bien avec samba, c'est quer tout ce qui est utile est dans desfichiers textes en clairle fichier de config est estrement soupleet l'utilisation de ldap comme base SAM ajoute encore une enorme souplesse.

donc pour les outils d'admin tu definit ce que tu a besoin pour ton serveur,et ensuitre tu fait un peu de perl ou autre, et voila, tout est automatisé aton gout.

persdonellement, j'ai créé une interface html avec des droit pour certainsutilisateurs et c'est meme plus moi qui ajoute les utilisateur, c'set unepersonne qui ne comprend aps l'informatique.

voila.


-----------------------------------------------------------------------------------------------------------------------------------

Re: [samba-fr] Outils d'administration Samba Thomas Sechet # From: Thomas Sechet <[email protected]># To: [email protected]# Subject: Re: [samba-fr] Outils d'administration Samba# Date: Fri, 5 Dec 2003 00:00:28 +0100# References: <[email protected]>

Bonjour,

Actuellemnt, je suis passé très récemment à samba 3 avec un annuaire ldap etj'utilise "lam". Ca me convient assez bien. Quelques développements sont encours pour l'adapter à mes besoins.Sinon j'utilise la ligne de commande pour des besoins spécifiques. Je nemaitrise pas tout, je suis en phase de tests (la grande découverte desfonctionnalités de samba 3).

Merci à tous ceux qui écrivent sur cette liste qui est vraiment un importantréservoir de réponses (à des questions que je ne me suis pas encore posées).

Thomas

Thread Linuxfr (journaux)(http://linuxfr.org/~martymac/7338.html)

Sondage musical...Posté par martymac (#17302). le 02/12/2003 @ 09:57:04

Cher journal,

Je voudrais poser une petite question aux utilisateurs/administrateurs Samba... Quel(s) outil(s) utilisez-vous au quotidien pour administrer votre serveur préféré ? Les outils Samba en lignes de commande, SWAT, Webmin, LAM (pour un backend LDAP)... ??? Je suis à la recherche de l'outil idéal, mais je ne l'ai pas encore trouvé... ! Merci de m'éclairer un peu :)-----------------------------------------------------------------------------------------------------------------------------------

Re: Sondage musical... (Score: 2/#1, #308499)Posté par PsychoFox (#8426). 02/12/2003 @ 10:14

fichiers de conf avec vi et ligne de commande, mais je n'en ai qu'une utilisation modérée (juste pour acceder à des machines win au boulot depuis mon linux).

SWAT et Webmin, je n'en vois pas l'interêt en tout cas.

-----------------------------------------------------------------------------------------------------------------------------------

Re: Sondage musical... (Score: 1/#0, #308553)Posté par neos (#6102). 02/12/2003 @ 11:05

Vim + SSH

Fichier de conf' de toute façon.


-----------------------------------------------------------------------------------------------------------------------------------

Re: Sondage musical... (Score: 1/#0, #308570) Posté par martymac (#17302). 02/12/2003 @ 11:25

Je pense que le meilleur moyen est en effet d'administrer Samba "à la main", mais il serait intéressant de disposer d'un outil complet et convivial, tirant parti des dernières fonctionnalités de la v3 (mapping de groupes, migration de comptes/données, jonction au domaine...) !

-----------------------------------------------------------------------------------------------------------------------------------

Re: Sondage musical... (Score: 1/#0, #308595) Posté par Pierre Tramo (#7781). 02/12/2003 @ 12:01

De manière plus générale, j'adore également Vim + SSH, mais dès qu'il s'agit d'aller au-delà c'est un peu le bordel tous les systèmes de configuration sous Linux, propre à chaque distributio ou a chaque environnement et qui marchent à moitié.

Il y a une discussion actuellement sur freedesktop.org pour voir comment on pourrait extraire la substantifique moelle de divers projets existants, et les faire travailler ensemble pour aboutir à quelque chose de bien.

Parmi ces projets actuels : Libconf http://qa.mandrakesoft.com/twiki/bin/view/Main/LibconfProject Config4Gnu http://config4gnu.sourceforge.net Un projet de Gnome : GST

Pour plus d'infos, vouz tenter votre chance ici https://listman.redhat.com/archives/xdg-list/2003-November/thread.html

-----------------------------------------------------------------------------------------------------------------------------------

Re: Sondage musical... (Score: 2/#1, #308605) Posté par FixXxeR (#2000). 02/12/2003 @ 12:15

Pareil: SSH + Vim. J'ai deja essayé SWAT il y a quelques années et je n'aime pas du tout la tronche du fichier smb.conf généré par cet outil.

Je pense qu'il vaut mieux se faire son petit smb.conf à la moumoune, ça permet de mieux maitriser le comportement de ton serveur SaMBa par la suite.

C'est vrai que le nombre de paramètres de SaMBa est assez gigantesque mais, pour beaucoup d'entre eux, les valeurs par défaut sont largement suffisantes.

-----------------------------------------------------------------------------------------------------------------------------------

Re: Sondage musical... (Score: 1/#0, #308876)Posté par jigso (#2075). 02/12/2003 @ 18:08

SWAT est pas mal ; j'aime surtout l'accés direct à la doc sur les différents paramêtres. 99% du temps on utilise les réglages par défaut, SWAT est très rapide pour creér un smb.conf minimal. Enfin il permet de "voir" les connections en cours.Un point noir : il faut utiliser root comme login (avec le mot de passe root) pour se loguer, dans un navigateur je trouve ca moyen. Il doit être possible de changer ca, mais comme j'y touche trés peu...

-----------------------------------------------------------------------------------------------------------------------------------


[... Un grand merci à tous ceux qui ont répondu à ces sondages ! Les noms de chacun ont été conservés ; chaque message cité est disponible de manière publique aux URL spécifiées.]

VII) Conclusion

Les outils les plus cités sont ceux que nous avons retenus : SWAT, Webmin (module standard), et LAM. Le manque d'outils conduit le plus souvent à l'administration manuelle des serveurs, solution citée comme étant la plus fiable et la plus complète.

Trois outils sortent donc du lot : SWAT, Webmin (module standard) et LAM. Nous allons étudier de manière plus technique ces trois outils dans le chapitre 7.


Chapitre 6 : Propositions techniques concernant 'Net Vampire'


I) Introduction

Ce chapitre propose quelques solutions aux problèmes rencontrés dans le chapitre 4 concernant l'utilisation de la commande 'net vampire' et la migration des données et des ACLs.

II) Migration de noms spéciaux

La migration des noms spéciaux doit se faire à deux niveaux. Le premier niveau se situe au niveau des noms sous Unix et peut être influencée par les commandes 'add <user|group|machine|user to group> script' dans le fichier de configuration. Voici les différences notables entre les architectures Windows et GNU/Linux :

Longueur : GNU/Linux : Max 32 caractères, Windows : Max 255Espaces : GNU/Linux : non, Windows : OuiCaractères internationaux : GNU/Linux : Oui mais à éviter, Windows : OuiCase Sensitive : GNU/Linux : Oui, Windows : Non

Il va donc falloir filtrer l'intégralité des noms d'utilisateurs/machines/groupes avant de les "injecter" dans le système GNU/Linux. Ceci peut se faire de cette manière (fichier smb.conf) :

; Utilisé lors du net vampire; sed retire espaces, ., ', et é des groupes par défaut Windows - coupe à 16 charactersadd machine script = /usr/sbin/useradd -g vmwaremachines -c "Samba Machine" -d /dev/null -s /bin/false ècho '%u' | sed -e "s/\ //g" -e "s/\.//g" -e "s/'//g" -e "s/Ã©/e/g" | cut -b 1-16àdd user script = /usr/sbin/useradd -g vmwareusers -c "Samba User" -d /dev/null -s /bin/false ècho '%u' | sed -e "s/\ //g" -e "s/\.//g" -e "s/'//g" -e "s/Ã©/e/g" | cut -b 1-16àdd group script = /usr/sbin/groupadd ècho '%g' | sed -e "s/\ //g" -e "s/\.//g" -e "s/'//g" -e "s/Ã©/e/g" | cut -b 1-16àdd user to group script = /usr/sbin/usermod -G ècho '%u' | sed -e "s/\ //g" -e "s/\.//g" -e "s/'//g" -e "s/Ã©/e/g" | cut -b 1-16 | xargs /usr/bin/id -G | /bin/sed 's/ /,/g'`,ècho '%g' | sed -e "s/\ //g" -e "s/\.//g" -e "s/'//g" -e "s/Ã©/e/g" | cut -b 1-16` ècho '%u' | sed -e "s/\ //g" -e "s/\.//g" -e "s/'//g" -e "s/Ã©/e/g" | cut -b 1-16`

Chaque utilisation de '%g' ou '%u' utilise préalablement une commande sed qui va en modifier la valeur. L'inconvénient de cette méthode est qu'elle s'avère relativement complexe à maintenir et à comprendre ! On préférera ici l'utilisation de scripts externes.

L'autre aspect à considérer se situe au niveau des comptes Samba. L'ajout d'un compte Samba se fait de manière interne, cet ajout n'est cette fois-ci pas "filtrable". La seule manière est ici d'intervenir au niveau du code de Samba ou d'intercepter les appels au backend utilisé. Une idée pourrait être de développer un backend supplémentaire (intermédiaire) permettant de filtrer les noms que Samba tente d'ajouter.

La solution de facilité est évidemment de renommer les utilisateurs et groupes côté Windows afin qu'ils répondent aux critères imposés par GNU/Linux.

III) Migration des données et ACLs

Comme étudié dans le chapitre 4, la méthode qui paraît la plus simple à mettre en oeuvre pour migrer les données et les ACLs est d'utiliser les outils Samba à notre disposition, notamment : smbclient et smbcacls. Voici un script shell qui crée une archive d'un partage et en "dumpe" les ACLs dans un fichier texte. Il faudra ensuite parcourir ce fichier pour convertir les ACLs Posix en ACLs NT et les ré-appliquer sur le PDC :


#----------------- Début de migr_acls.sh ---------------------#!/bin/sh

############################# Configuration ###############################"smbclient="/usr/local/samba/bin/smbclient"backupaccount="Administrateur"backupaccountpasswd="administrateur"

# Fichiers crees# Archivearchivefile="files_backup.tar"# Partage a "backuper"archiveroot="//VMWARE_PDC/profiles"# Fichier contenant les ACLs dumpees (et nettoyees)filelist_final="acls_backup.txt"

# Fichiers temporaires# Premier dump (sortie de smbclient)filelist_dump="filelist_dump.tmp"# Liste des fichiers nettoyeefilelist_clean="filelist_clean.tmp"# Liste des fichiers + ACLs completesfilelist_acls="filelist_acls.tmp"########################### Fin configuration #############################"

echo "Backup de $archiveroot dans $archivefile..."echo "Login: $backupaccount"$smbclient -U $backupaccount -c "tar c $archivefile" $archiveroot 2>$filelist_dumpif [ $? -ne 0 ]then echo "Erreur lors de la copie des fichiers" exit -1fiecho "Backup terminé."

echo "Backup des acls dans $filelist_final..."sleep 1# Suppr les lignes comm par [, les infos avant les noms de fich, et les lignes de fin avec ' ' devantsed -e '/^\[/D' \ -e 's/^[ 0-9a-z\/\.]\+\\//g' \ -e '/^ \+/D' \ -e 's/\\/\//g' $filelist_dump > $filelist_clean

# On parcourt le fichiernblignes=`wc -l $filelist_clean | sed -e 's/ \+.*$//'`nblignes=èxpr $nblignes + 0` # nblignes conversion en entier

echo "# --- Genere par $0 ---" > $filelist_aclsecho "" >> $filelist_acls

# Boucle principale, parcourt chaque ligne (fichier) et recupere les ACLs NTi=1while [ $i -le $nblignes ]do ligne=`head -$i $filelist_clean | tail -1` # Lis la ligne

echo "$i/$nblignes : $ligne" echo "$ligne" >> $filelist_acls smbcacls -d 0 -U $backupaccount%$backupaccountpasswd $archiveroot "$ligne" >> $filelist_acls echo "" >> $filelist_acls i=èxpr $i + 1`done

# On reformatte les ACLs récupérées

sed -e '/^REVISION/d' \ -e '/âdded/d' \ -e '/\\SYSTEM\:/d' $filelist_acls > $filelist_final

# Fini, on dispose d'un fichier contenant les fichiers/acls dumpésrm $filelist_dump $filelist_clean $filelist_aclsecho "Backup terminé."#----------------- Fin de migr_acls.sh ---------------------


Le principe de ce script est simple : nous utilisons smbclient pour effectuer le backup d'un partage CIFS. La sortie de smbclient est utilisée pour connaître les fichiers sauvegardés. Cette sortie est ensuite utilisée par smbcacls pour interroger le serveur Samba concernant les ACLs de chaque fichier/répertoire sauvegardé. Ces ACLs sont écrites dans un fichier de sortie.

IV) Problèmes liés au backend LDAP

Le problème d'import des groupes détecté dans le chapitre 4 nécessite probablement une modification du backend LDAP qui réagit différemment du backend tdb lors du 'net vampire'.


Chapitre 7 : Stratégies de développement de l'outil d'administration


I) Introduction

Ce chapitre a pour but d'étudier les différentes possibilités concernant le développement d'une interface graphique d'administration Samba. Il se base sur l'étude des différentes interfaces existantes proposée dans le chapitre 5.

Plusieurs pistes sont envisageables concernant le développement de l'interface d'administration : une première piste qui consiste en la réutilisation et l'extension d'un code existant, et une seconde en un développement "from scratch".

II) Réutilisation de code existant

A) Swat

Swat fait partie intégrante du projet Samba. Il a l'avantage de réutiliser directement les fonctions du code Samba, et peut ainsi bénéficier des fonctionnalités les plus récentes.

Il est développé en C et constitue un démon géré par (x)inetd en implémentant un mini-serveur web autonome. Chaque page d'administration de Swat est représentée par une fonction C qui gère les variables passées dans l'URL et effectue des actions en conséquence.

SWAT gère des droits différents et limite les fonctionnalités offertes en fonction de l'utilisateur loggé durant la session. Cet utilisateur doit être un utilisateur Unix local.

La modification de Swat peut sembler une bonne base à un outil complet d'administration. En effet, cet outil est le plus cité par les administrateurs Samba. Il est reconnu comme étant le plus à jour de par son statut et le fait qu'il soit intégré dans chaque distribution de Samba.

Cependant, le code de Swat, même s'il est assez facilement compréhensible, représente un projet dont les fonctionnalités semblent difficilement extensibles en raison de sa structure. En effet, son code constitue un cadre relativement statique (html généré 'à la main') et risque de devenir difficile à maintenir pour un projet plus conséquent. L'objet initial de Swat est de donner accès à la configuration du fichier smb.conf et aux utilisateurs de manière graphique, et non de constituer un projet de grande envergure et un outil d'administration complet. Enfin, l'utilisation de cet outil demande une bonne connaissance de Samba et peut ne pas être simple à prendre en main pour un administrateur débutant, ce qui ne correspond pas aux exigences de simplicité requises pour le développement de l'interface graphique.


B) Webmin - module standard Samba

Le module Webmin est également un outil d'administration très à jour et utilise, cette fois-ci, les commandes externes de Samba, puisqu'il n'a pas accès directement au code du projet. Le module est programmé en PERL et offre une certaine souplesse de développement, car le code n'inclut pas ici la gestion du serveur Web, déléguée au core Webmin. L'HTML est cependant généré "à la main" à la manière d'un script PHP.

La souplesse provient aussi d'une gestion relativement modulaire du code où chaque page correspond à un script cgi différent, à la différence de SWAT où l'intégralité du code est regroupé dans la même fichier c.

Enfin, le code est interprété, ce qui est non négligeable pour permettre une bonne portabilité (bien que la compilation de SWAT soit possible sur tout type d'architecture).

L'utilisation de commandes externes peut potentiellement poser des problèmes de sécurité, même si ce mécanisme peut offrir un avantage non négligeable qui est une certaine indépendance aux mécanismes internes de Samba (la gestion du backend par exemple), dont SWAT ne bénéficie pas.

Malheureusement, à l'instar de SWAT, le module Webmin ne correspond pas non plus aux exigences de simplicité et de convivialité imposées par le cahier des charges du projet.

C) LAM

LAM s'apparente à Webmin par son mode de fonctionnement. Il est développé entièrement en PHP, ce qui lui confère une certaine souplesse. Toutefois, LAM n'interagit pas directement avec les commandes Samba. Il manipule le backend de manière directe via des appels à la libraire LDAP de PHP.

LAM se limite donc uniquement à l'utilisation de LDAP comme moyen de stockage des comptes.

LAM peut interagir avec le système hôte pour ajouter des utilisateurs Unix ou créer leur répertoires homes via des appels 'system' (cf. lib/ldapdaemon.pl).

III) Développement 'from scratch'

Le développement 'from scratch' est certainement la solution la plus pertinente. Elle permettra d'implémenter l'ensemble des fonctionnalités requises de manière homogène au sein du projet. Cette démarche implique une réflexion préalable quant à la structure de l'application afin de lui offrir la souplesse nécessaire à la bonne implémentation de toutes les fonctionnalités, dans un premier temps, puis à son extension, dans un second.

Cette application devra répondre au cahier des charges qui impose notamment d'offrir à l'administrateur la souplesse et la simplicité des outils Microsoft. Cette exigence n'est pas remplie si l'on étend un outil existant.

La souplesse de l'application pourra prendre forme par l'utilisation d'une API, qu'il faudra développer, et d'une (ou plusieurs) interfaces qui l'exploiteront (web, native). Le développement préalable de cette API constituerait un projet à part entière qui pourrait s'intégrer parfaitement au projet Samba ne disposant pas encore de tels outils.

Ce type de développement constitue donc la démarche idéale, mais implique des moyens plus importants que la solution d'extension d'un outil existant.Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 62 sur 94

IV) Conclusion

Trois possibilités sont envisageables pour offrir à la communauté un outil d'administration répondant aux critères du cahier des charges :

1 - Extension de l'un des trois outils cités ci-dessus :

Cette solution peut, à court terme, apporter les fonctionnalités manquantes à l'un des outils, mais ne semble pas une solution pérenne. En effet, aucun outil étudié ne semble offrir de bonnes bases au développement de l'outil d'administration complet. Le résultat s'apparenterait plus à une rustine temporaire qu'à la création d'un outil homogène complet. De plus, aucun ne répond aux exigences de simplicité et de convivialité énoncées.

2 - Développement d'une API :

Solution préalable au développement d'un outil d'administration complet, cette API doit offrir l'intégralité des actions d'administration Samba. Elle proposera une manière plus élégante que l'utilisation de commandes externes pour conserver l'abstraction au backend et au système en utilisant le code Samba. Aucun outil étudié ne semble adapté à servir de base au développement de cette API. Toutefois, certaines fonctions de SWAT pourront être réutilisées ou servir d'exemple dans la mise en oeuvre du code interne de Samba.

3 - Développement intégral de l'outil :

Solution "idéale", finale, mais en contrepartie d'un coût et de délais de conception plus importants. Elle se base, de préférence, sur le développement préalable de l'API définie ci-dessus. L'interface viendra utiliser cette API et pourra être développée autour de technologies web ou 'natives'. L'outil d'administration final s'apparente alors à une surcouche graphique (voire en lignes de commandes) aux fonctions de plus bas niveau définies dans l'API.


Chapitre 8 : Cahier des charges de l'outil d'administration - Fonctionnalités


I) Introduction

Ce chapitre a pour but de présenter les différentes fonctionnalités que l'outil d'administration final devra proposer. Il se base sur l'étude des fonctionnalités utilisées dans le cadre d'une administration de domaine NT classique en tenant compte des spécificités Samba.

L'étude porte tout d'abord sur les interfaces d'administration NT4 existantes, puis sur celle de chaque fonctionnalité offerte. Nous allons par la suite rapprocher ces fonctionnalités aux exigences de l'architecture Samba pour enfin aboutir à un cahier des charges fonctionnel de l'outil d'administration.

II) Etude des consoles d'administration NT4

Voici une liste exhaustive des actions qu'il est possible de réaliser via les principales consoles d'administration NT4.

A) Le gestionnaire d'utilisateurs

Il permet de gérer les utilisateurs d'un domaine (que l'on peut sélectionner) :

- Afficher les utilisateurs et groupes locaux et globaux- Ajouter/Supprimer/Copier/Renommer un utilisateur local ou global- Ajouter/Supprimer/Copier un groupe local ou global- Edition des propriétés des groupes- Edition des propriétés des utilisateurs- Edition de stratégies de comptes pour le domaine (configuration par défaut du comportement des comptes) - Durée de vie min/max du password - Longueur min du password - Historique du password - Stratégies de verrouillage de compte (si accès infructueux...) - Forcer à ouvrir une session pour le changement de mot de passe- Edition de stratégies de droits de l'utilisateur (droits accordés à une liste d'utilisateurs) - Accéder à cet ordinateur depuis le réseau - Ajouter des stations de travail au domaine - Arrêter le système - Charger et décharger des pilotes de périphériques - Forcer l'arrêt à partir d'un système distant - Gérer le journal d'audit et de sécurité - Modifier l'heure système - Ouvrir une session localement - Prendre possession des fichiers ou d'autres objets - Restaurer des fichiers et des répertoires - Sauvegarder des fichiers et des répertoires- Stratégies d'audit (alertes sur différentes actions) - Ouverture/fermeture de sessions - Accès fichier et objet - Utilisation des droits de l'utilisateur - Gestion des utilisateurs et groupes


- Modification de la stratégie de sécurité (ensemble des 3 stratégies compte/utilisateur/audit) - Redémarrage/arrêt et système - Suivi de processus

- Edition des relations d'approbation - Domaines approuvés - Domaines pouvant approuver

Le gestionnaire des utilisateurs

B) Le gestionnaire de serveur

Il permet de gérer les comptes machines sur le domaine.

- Afficher les machines membres d'un domaine- Propriétés d'un serveur - Utilisateurs connectés - Partages disponibles - Fichiers en cours d'utilisation - Duplication de données vers plusieurs serveurs - Gestion de destinataires d'alertes- Services en cours sur une machine- Envoyer un message à une machine- Synchroniser le domaine (Synchronisation de la base SAM entre tous les DC)- Promotion d'un BDC en PDC


Le gestionnaire de serveur

C) L'éditeur de stratégies système (poledit.exe)

Il offre la possibilité de créer un fichier NTConfig.pol que l'on placera dans le répertoire netlogon auquel les utilisateurs du domaine accèdent. Ce fichier contient un ensemble de clefs de registres à modifier dynamiquement lors du logon de l'utilisateur. Un seul fichier NTConfig.pol doit être présent dans le partage netlogon ; il contient les informations concernant plusieurs utilisateurs/groupes/machines.

- Règle le comportement du système au logon d'un utilisateur. Plusieurs options sont disponibles.

L'éditeur de stratégies système


III) Description détaillée des propriétés des acteurs NT

A l'issue de l'étude des différentes fonctionnalités présentes, on en déduit, de manière plus générale, qu'il est nécessaire de pouvoir agir sur les propriétés suivantes pour les différents acteurs du domaine :

A) Les utilisateurs

Général(SID)Type de compte (global/local)NomNom détailléDescriptionMot de passeGroupe(s) d'appartenance (primaire, secondaires - transparent sous NT)

CheminsChemin du répertoire homeChemin du répertoire profileChemin du script netlogon

SécuritéHoraires d'accès autorisésWorkstations autoriséesEtat d'activation du compteEtat de verrouillage du compte

Stratégies de mots de passeL'utilisateur peut/doit changer de mot de passeExpiration du mot de passe (date, n tentatives infructueuses)Anciens mots de passe

Stratégies de numérotationAutorisé à numéroterType de rappel

B) Les groupes

Général(SID)Liste des membresDescription du groupeType (golbal/local)


C) Les machines

Général(SID)Nom de la machine

D) Les domaines

Général(SID)Nom du domaine

IV) Les acteurs sous Samba

Etudions le schema LDAP fourni avec Samba (3.0.1rc2) afin de connaître les propriétés réellement utilisées actuellement et utilisables dans Samba (les propriétés en rouges sont obligatoires pour un enregistrement) :

A) Les utilisateurs - les machines

sambaSamAccount : 'Samba 3.0 Auxilary SAM Account'

uidsambaSIDsambaLMPasswordsambaNTPasswordsambaPwdLastSetsambaLogonTimesambaLogoffTimesambaKickoffTimesambaPwdCanChangesambaPwdMustChangesambaAcctFlagsdisplayNamesambaHomePathsambaHomeDrivesambaLogonScriptsambaProfilePathdescriptionsambaUserWorkstations sambaPrimaryGroupSID sambaDomainName sambaMungedDial


Le backend MySQL fournit d'autres propriétés qui ne semblent pas encore utilisées par Samba, mais qui annoncent les futures fonctionnalités NT4 supportées :

logon_divs - int(9) hours_len - int(9) bad_password_count - int(9) logon_count - int(9)

B) Les groupes d'utilisateurs

sambaGroupMapping : 'Samba Group Mapping'

gidNumbersambaSIDsambaGroupTypedisplayNamedescription

C) Les domaines

sambaDomain : 'Samba Domain Information'

sambaDomainNamesambaSIDsambaNextRidsambaNextGroupRidsambaNextUserRidsambaAlgorithmicRidBase

Les propriétés sont en relations directes avec les besoins évoqués sous NT. On remarque cependant que certaines sont absentes du backend LDAP ou non gérées par Samba :

SécuritéHoraires d'accès autorisésEtat de verrouillage du compte (fonctionnement aléatoire)

Stratégies de mots de passeExpiration du mot de passe : date, n tentatives infructueuses (possible via patch)Anciens mots de passe

Stratégie de numérotationAutorisé à numéroterType de rappel


D'autres fonctionnalités propres à Windows NT ne sont pas disponibles sous Samba :

- Promotion dynamique d'un BDC en PDC- Synchronisation du domaine (base SAM synchronisée entre les différents serveurs, cf. 'net rpc vampire').- Seules les stratégies utilisateurs sont gérées (pas les stratégies de groupes/machines)- Pas d'outil d'édition des stratégies ('profiles' ou 'editreg' ne permettent que de lister/modifier les SIDs présents dans un fichier NTConfig.pol ou NTUser.dat existant)

Les fonctionnalités liées à ces propriétés ne sont donc pas pour l'instant exploitables. Elles seront écartées dans les spécifications de l'outil d'administration. L'intégralité des autres propriétés doit être renseignable par l'intermédiaire de l'outil d'administration.

V) Rapprochement à Samba - Fonctionnalités retenues

Le regroupement des fonctionnalités étudiées en II) et dans le chapitre 5, des propriétés devant être éditables définies en III) nous permet de constituer une liste exhaustive d'opérations que devrait permettre un outil d'administration Samba complet, après "filtrage" des fonctionnalités non disponibles sous Samba.

Gestion des Acteurs :Gestion des utilisateurs Unix et Samba (afficher/ajout/suppression/modification/gestion des propriétés)Gestion des groupes Unix et Samba (afficher/ajout/suppression/modification/gestion des propriétés)Gestion des mappings de groupes (afficher/ajout/suppression/modification)Gestion des machines Unix et Samba (afficher/ajout/suppression/modification/gestion des propriétés)

Contenu des Partages :Edition des scripts netlogon (mappings de lecteurs...)Upload de stratégies utilisateurs (fichier NTConfig.pol)Création et suppression automatique des répertoires 'homes' des utilisateurs

Smb.conf (section globale) - Samba :Configuration de la section globale du fichier smb.confConfiguration du backend (ex. : gestion du mot de passe principal LDAP)Edition brute du fichier smb.confConservation des commentaires

Smb.conf (section printers et print$) - Imprimantes :Gestion des imprimantesGestion des drivers d'impression

Smb.conf (autres sections) - Partages de fichiers :Gestion des quotas et ACLsConfiguration des partages du serveurCréation et suppression automatique des répertoires partagés

Système hôte Samba :Démarrage / arrêt des démons Samba (smbd et nmbd)Visualisation des logs du serveur


Gestion du domaine :Joindre/Quitter un domaineEtablir/supprimer une relation d'approbationAfficher les machines membres du domaineAfficher les propriétés du domaineAfficher les propriétés d'une machine particulière (partages, utilisateurs connectés, démons, sid, ...)Envoyer un message à une machine

Migration et partage de données :Migration des comptes Unix/Samba depuis un serveur NTImport de comptes Unix/Samba depuis un fichier externe (ldiff, texte...)Synchronisation des comptes Unix/Samba existantsEdition de rapports de comptes (PDF, Texte, Xml...)

Général :Gestion transparente du backend pour la gestion des comptesSimplicité d'utilisation, plusieurs modes (wizard, simple, avancé...)Documentation en ligne (man, Samba Howto Collection, Using Samba)Gestion de profils/préférences par administrateurPortabilité

"Les plus" :Explorateur CIFS (envoi/récep/suppr de fichiers, modification d'acls)Gestion de plusieurs Domaines/Serveurs pour les tâches effectuées via RPC

VI) Subdivision des fonctions

Suite à l'étude des fonctionnalités requises dans l'outil d'administration, et à leur classement fonctionnel, nous allons effectuer un second classement, cette fois-ci en fonction de la nature technique des tâches à accomplir.

A) Tâches locales, propres au système

Il s'agit des tâches purement systèmes propres à notre serveur Unix (cf. useradd).

- Gestion des comptes utilisateurs Unix :Même s'ils sont stockés sur une base externe (LDAP, MySQL...) et "détournés" via les mécanismes nsswitch et PAM, mieux vaut passer par des routines systèmes pour conserver le maximum d'indépendance au backend final.

- Gestion des groupes Unix (type groupadd) :Même remarque que pour les utilisateurs Unix.

- Gestion des comptes machines Unix :Un compte machine est un compte utilisateur avec des attributs différents et un nom terminé par un dollar.

- Import de comptes d'utilisateurs Unix depuis un fichier externe


B) Tâches locales, propres à Samba

Il s'agit des tâches d'administration locale de notre serveur Samba (ex : édition du fichier smb.conf).

- Edition du fichier smb.conf ([global],[printers], et autres...)Le fichier de base de Samba. Tous les partages se définissent au sein de ce fichier.

- Création des répertoires de base des partages (ex : homes, profiles, ...)Il s'agit de créer la structure qui va accueillir nos données partagées. Nous n'allons pas ici peupler ces répertoires ; mieux vaut les peupler via CIFS (cf. C)).

- Démarrage/Arrêt des démons Samba (smbd et nmbd)

- Visualisation des logs du serveur

- Synchronisation des comptes Samba avec les comptes Unix

- Gestion des mappings de groupes (et, ainsi, des groupes) Samba (cf. net groupmap add)Un groupe Samba correspond à un mapping d'un groupe Unix vers NT. Il faut cependant que l'entrée du groupe existe auparavant dans le backend. L'établissement d'un mapping doit être exécutée impérativement depuis le serveur Samba (mécanisme interne).

- [RPC - mais nécessite mécanisme Samba local] Joindre un domaine- [RPC - mais nécessite mécanisme Samba local] Etablir une relation d'approbation- [RPC - mais nécessite mécanisme Samba local] Migration des comptes depuis un serveur NT4

C) Tâches exécutables à distance via des mécanismes Windows/Samba (RPC, partages CIFS)

Il s'agit des actions d'administration réalisables via RPC (cf. rpcclient et commande net) et CIFS. Une liste exhaustive des actions actuellement réalisables peut être obtenue par une commande :

rpcclient -U Administrateur VMWARE_BDC -c help

--------------- ---------------------- SHUTDOWN shutdowninit Remote Shutdown (over shutdown pipe) shutdownabort Abort Shutdown (over shutdown pipe)--------------- ---------------------- ECHO echoaddone Add one to a number echodata Echo data sinkdata Sink data sourcedata Source data--------------- ---------------------- REG shutdown Remote Shutdown abortshutdown Abort Shutdown--------------- ---------------------- DFS dfsexist Query DFS support dfsadd Add a DFS share dfsremove Remove a DFS share dfsgetinfo Query DFS share info dfsenum Enumerate dfs shares--------------- ----------------------

SRVSVCSamba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 73 sur 94

srvinfo Server query info netshareenum Enumerate shares netfileenum Enumerate open files netremotetod Fetch remote time of day--------------- ---------------------- NETLOGON logonctrl2 Logon Control 2 logonctrl Logon Control samsync Sam Synchronisation samdeltas Query Sam Deltas samlogon Sam Logon samlogon Change Trust Account Password--------------- ---------------------- SPOOLSS adddriver Add a print driver addprinter Add a printer deldriver Delete a printer driver enumdata Enumerate printer data enumdataex Enumerate printer data for a key enumkey Enumerate printer keys enumjobs Enumerate print jobs enumports Enumerate printer ports enumdrivers Enumerate installed printer drivers enumprinters Enumerate printers getdata Get print driver data getdataex Get printer driver data with keyname getdriver Get print driver information getdriverdir Get print driver upload directory getprinter Get printer infogetprintprocdir Get print processor directory openprinter Open printer handle setdriver Set printer drivergetprintprocdir Get print processor directory addform Add form setform Set form getform Get form deleteform Delete form enumforms Enumerate forms setprinter Set printer comment setprinterdata Set REG_SZ printer data rffpcnex Rffpcnex test--------------- ---------------------- SAMR queryuser Query user info querygroup Query group infoqueryusergroups Query user groupsqueryuseraliases Query user aliases querygroupmem Query group membership queryaliasmem Query alias membership querydispinfo Query display info querydominfo Query domain info enumdomusers Enumerate domain users enumdomgroups Enumerate domain groups enumalsgroups Enumerate alias groups createdomuser Create domain user samlookupnames Look up names samlookuprids Look up names deletedomuser Delete domain user samquerysecobj Query SAMR security object getdompwinfo Retrieve domain password info lookupdomain Lookup Domain Name--------------- ---------------------- LSARPC-DS dsroledominfo Get Primary Domain Informationdsenumdomtrusts Enumerate all trusted domains in an AD forest--------------- ----------------------

LSARPC


lsaquery Query info policy lookupsids Convert SIDs to names lookupnames Convert names to SIDs enumtrust Enumerate trusted domains enumprivs Enumerate privileges getdispname Get the privilege name lsaenumsid Enumerate the LSA SIDSlsaenumprivsaccount Enumerate the privileges of an SIDlsaenumacctrights Enumerate the rights of an SIDlsaaddacctrights Add rights to an accountlsaremoveacctrights Remove rights from an accountlsaremoveacctrights Remove rights from an accountlsalookupprivvalue Get a privilege value given its name lsaquerysecobj Query LSA security object--------------- ----------------------[...]

La commande net help rpc peut également fournir quelques indications. Cependant, toutes les fonctionnalités offertes ne permettent pas de déterminer ce qui est entièrement réalisable via RPC. En effet, certaines de ces commandes nécessitent RPC pour faire transiter des informations mais doivent être exécutées sur le serveur Samba pour avoir accès à des fonctionnalités internes (ex. : net rpc join, net rpc vampire, ...).- [CIFS] Population des répertoires partagés de base : scripts netlogon, stratégies, ...Il semble préférable de peupler les répertoires partagés via CIFS, plutôt qu'en interne, afin de conserver une certaine homogénéité au sein de l'application et concernant les attributs de fichiers, par exemple les ACLs appliquées aux fichiers.

- [RPC] Gestion des comptes utilisateurs Samba (cf. net rpc user add)- [RPC] Gestion des comptes machines Samba (cf. net rpc user add)- [RPC] Gestion des comptes de groupes Samba (cf. net rpc group add) - non supporté

- [RPC] Afficher les machines membres d'un domaine- [RPC] Afficher les propriétés d'une machine particulière- [RPC] Envoyer un message à une machine

- [RPC] Edition de rapports de comptes utilisateurs/groupes Samba en différents formats (PDF, Xml...)

D) Tâches exécutables à distance (autres)

Il s'agit des autres tâches exécutables à distance.

- Administration directe du backend.

VII) Une API et une GUI ?

Il convient de mettre en place une architecture relativement souple et modulaire. L'idée d'une API semble la plus adaptée à nos besoins. Celle-ci posera les fondations de notre outil d'administration graphique et permettra de simplifier grandement le processus de développement d'interfaces d'administration. Une GUI, tout comme un outil web ou en lignes de commandes pourra ainsi se "brancher" simplement sur cette couche sous-jacente et bénéficier de toute ses fonctionnalités. Un projet de ce type aura aussi comme avantage de motiver les communautés de développement et d'accélérer la création d'interfaces diverses.


VIII) Cahier des charges de l'API

Cette API nécessitera l'ensemble des fonctionnalités décrites plus haut. Ces dernières se subdivisent en différentes opérations, ainsi que nous allons l'étudier. Nous n'allons pas étudier ici la méthode à employer (objet par ex.) pour implémenter ces fonctions. Le choix est laissé libre et se fera lors de la phase de développement.

Fonctionnalités PrécisionsGestion des acteurs (local - Unix) Forcer l'unicité des ids (pas de -o) Utilisateurs Identifié par son nom et uid Convertir un nom d'utilisateur Caract. spéciaux, espaces, longueur Ajouter un utilisateur Supprimer un utilisateur Attention si existe sous Samba Lister les utilisateurs L'utilisateur <utilisateur> existe-t-il ? Récupérer les propriétés d'un utilisateur Login, pwd, uid, primgrp, home, shell Modifier une propriété d'un utilisateur Pwd, primgrp, home, shell Lister tous les groupes d'un utilisateur Ajouter un groupe à un utilisateur Supprimer un groupe à un utilisateur Différent du primgrp Créer le rép. home d'un utilisateur Supprimer le rép. home d'un utilisateur Importer des comptes utilisateurs A partir d'un fichier Exporter des comptes utilisateurs Vers un fichier Machines Identifiée par son nom et uid Convertir un nom de machine Caract. spéciaux, espaces, longueur Ajouter une machine Supprimer une machine Attention si existe sous Samba Lister les machines La machine <machine> existe-t-elle ? Récupérer les propriétés d'une machine Nom, uid (aucune propriété modifiable) Importer des comptes machines A partir d'un fichier Exporter des comptes machines Vers un fichier Groupes Identifié par son nom et gid Convertir un nom de groupe Ajouter un groupe Supprimer un groupe Attention si existe sous Samba Lister les groupes Le groupe <groupe> existe-t-il ? Lister les utilisateurs d'un groupe Ajouter un utilisateur à un groupe Supprimer un utilisateur d'un groupe Attention si grp = primgrp Importer des groupes A partir d'un fichier Exporter des groupes Vers un fichierGestion des acteurs (local - Samba) Utilisateurs Convertir un nom d'utilisateur Caract. spéciaux, espaces, longueur Ajouter un utilisateur Existant sous Unix Supprimer un utilisateur Lister les utilisateurs L'utilisateur <utilisateur> existe-t-il ? Récupérer les propriétés d'un utilisateur Toutes les propriétés supportées par le backend (cf. sch.

LDAP par ex.) Modifier une propriété d'un utilisateur Tout sauf son nom (qui le mappe à l'utilisateur unix)

Flags (activation/désactivation compte...), répertoires... Créer le répertoire home d'un utilisateur (si local)


Supprimer le répertoire home d'un utilisateur (si local) Lister tous les groupes d'un utilisateur Ajouter un groupe à un utilisateur Supprimer un groupe à un utilisateur Différent du primgrp Récupérer le cpte Unix correspondant Importer des comptes utilisateurs A partir d'un fichier Importer un compte utilisateur Unix A partir du système Importer les comptes utilisateurs Unix A partir du système Exporter des comptes utilisateurs Vers un fichier Machines Convertir un nom de machine Caract. spéciaux, espaces, longueur Ajouter une machine Supprimer une machine Lister les machines La machine <machine> existe-t-elle ? Récupérer les propriétés d'une machine Nom, sid Modifier une propriété d'une machine Tout sauf son nom (qui la mappe à la machine Unix) Récupérer le cpte Unix correspondant Importer des comptes machines A partir d'un fichier Exporter des comptes machines Vers un fichier Groupes Convertir un nom de groupe Caract. spéciaux, espaces, longueur Ajouter un groupe Simple, sans mapping Supprimer un groupe Supprime aussi le mapping Lister les groupes Le groupe <groupe> existe-t-il ? Lister les utilisateurs d'un groupe Ajouter un utilisateur à un groupe Supprimer un utilisateur d'un groupe Attention si grp = primgrp Récupérer les propriétés d'un groupe Toutes les propriétés supportées par le backend (cf. sch.

LDAP par ex.) Modifier une propriété d'un groupe Tout sauf son nom (qui le mappe au groupe Unix) Lister les groupes mappés Groupes ayant un SID Mapper un groupe Ajoute les infos de mapping

(met les primgroupsid des utilisateurs à jour) Modifier un mapping Modifie le SID du groupe

(met les primgroupsid des utilisateurs à jour) Supprimer un mapping Supprime les infos de mapping

(met les primgroupsid des utilisateurs à jour) Récupérer le groupe Unix correspondant Importer des groupes A partir d'un fichier Exporter des groupes Vers un fichier Domaines* Ajouter un domaine Supprimer un domaine Lister les propriétés d'un domaine Sid Modifier les propriétés d'un domaine Lister les acteurs d'un domaine Importer des domaines A partir d'un fichier Exporter des domaines Vers un fichierGestion des acteurs (local - Unix + Samba) Fonctions "for dummies" - Utilisent Unix + Samba

vues précédemment. Utilisateurs Ajouter un utilisateur au domaine Sous Unix puis Samba - Création de Home Supprimer un utilisateur du domaine Sous Samba (puis Unix ?) - Suppression de Home Lister tous les groupes d'un utilisateur Unix + Samba Ajouter un groupe à un utilisateur Unix + Samba Supprimer un groupe à un utilisateur Différent du primgrp, Samba puis Unix


Machines Ajouter une machine au domaine Supprimer une machine du domaine Groupes Ajouter un groupe au domaine Ajoute groupe + mapping Supprimer un groupe du domaine Supprime mapping + groupe Lister les utilisateurs d'un groupe Samba + Unix Ajouter un utilisateur à un groupe Supprimer un utilisateur d'un groupe Domaines Pas de nouvelles fonctions car gestion purement propre à

Samba.Samba - Système (local) Système Démarrage du démon smbd (idem pour nmbd) Arrêt du démon smbd (idem pour nmbd) Statut du démon smbd (idem pour nmbd) Récupération "brute" des logs du serveur Parsing pour récupération structurée des logs Export des logs Xml, Html, PDF... Appliquer une ACL sur un fichier Récupérer une ACL d'un fichier Appliquer un quota sur un fichier Récupérer les informations de quotas d'un fichier Gestion du domaine Joindre un domaine Annuler la jonction à un domaine Etablir une relation d'approbation Annuler une relation d'approbation Importer les comptes depuis un serveur NT4 <=> Net vampire Importer le contenu d'un partage depuis un serveur NT4 + Gestion des ACLs (?)Samba (local - configuration - partages) Smb.conf (générique) Import d'un fichier de configuration Smb.conf, Xml... Export du fichier de configuration Xml, Html, PDF, ... Tester la validité du fichier de configuration Lister les sections disponibles Ajouter une section Supprimer section Sauf global - Suppression auto du répertoire associé Smb.conf (toutes sections) Parsing des options de configuration de la section (mémoire) Mémorisation des commentaires Commit des modifications apportées en mémoire Lecture d'une option de configuration (mémoire ou fichier) Lecture du commentaire de l'option (mémoire ou fichier) Situé au dessus par convention Modification d'une option de configuration (mémoire ou fichier) Possibilité d'attachement de commentaire Ajout d'un commentaire à une option (mémoire ou fichier) Tester la validité de notre configuration (mémoire ou fichier) Remise à zéro des paramètres (mémoire ou fichier) Différents modèles par défaut dispos Obtenir la liste des params dispos dans cette section Smb.conf (section [global]) Modifier le backend utilisé = Raccourci, ensemble de directives de conf Passer notre BDC en PDC (mémoire ou fichier) = Raccourci, ensemble de directives de conf Passer notre PDC en BDC (mémoire ou fichier) = Raccourci, ensemble de directives de conf Smb.conf (section [homes]) Création automatique du répertoire Unix de la section Smb.conf (section [printers]) Smb.conf (section [autres]) Notamment "Profiles", "Netlogon", "Print$" + partages

diversSamba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 78 sur 94

Création automatique du répertoire Unix de la sectionSamba (distant - RPC) Lister les propriétés d'un domaine Exporter les propriétés listées Xml, PDF, ... Lister les acteurs d'un domaine utilisateurs, machines, groupes Exporter les comptes listés Xml, PDF, ... Lister les propriétés d'un acteur utilisateurs, machines, groupes (lister membres) Exporter les propriétés listées Xml, PDF, ... Ajouter un acteur au domaine utilisateurs, machines, groupes Modifier un acteur du domaine utilisateurs, machines, groupes Supprimer un acteur du domaine utilisateurs, machines, groupes Afficher les propriétés d'une machine d'un domaine Exporter les propriétés listées Xml, PDF, ... Envoyer un message à une machineSamba (distant - CIFS) Copie d'un fichier local vers un partage CIFS Netlogon scripts, stratégies, drivers d'impression - Gestion

de fichiers par défaut Création d'un répertoire sur un partage CIFS Copie d'un partage CIFS vers un autre partage + Gestion des ACLs (?) Lister les fichiers d'un partage CIFS Supprimer un fichier sur un partage CIFS Appliquer une ACL sur un partage CIFS Récupérer une ACL sur un partage CIFS Appliquer un quota sur un partage CIFS Récupérer les informations de quotas d'un partage CIFSBackend (distant - dépendant du backend) Fonctionnalités non indispensables Lire/Ecrire dans le backend [...] Secours pour administration si pb Samba

* Par défaut, Samba ne gère que le domaine "en cours" spécifié dans le fichier smb.conf. Il se peut cependant que plusieurs domaines soient disponibles au niveau du backend. Les fonctions énoncées ici permettent d'y accéder. Les fonctions de manipulation d'acteurs (utilisateurs, machines, groupes) pourront permettre de manipuler ces utilisateurs en fonction des domaines existants ou en fonction du domaine "en cours" dans le fichier smb.conf.

Notes :

- Les fonctions présentées essayent de couvrir l'intégralité des besoins étudiés dans ce chapitre. Certaines fonctions nécessiteront une subdivision en différentes sous-fonctions non spécifiées ici.

- La gestion des commentaires utilise le principe suivant : à chaque paramètre du fichier smb.conf peut être rattaché un seul commentaire. Ce commentaire est situé au dessus du paramètre et peut contenir plusieurs lignes.

- Les commandes RPC présentent certaines fonctionnalités également disponibles via des mécanismes internes à Samba. Les versions RPC permettent alors d'administrer à distance le serveur.


IX) Conclusion

Cette API pose donc les fondations d'un outil d'administration plus complet. Elle présente les grandes fonctions nécessaires à la bonne administration d'un serveur Samba ; cependant, la méthode d'implémentation n'a pas été définie. Si la méthode objet semble la plus appropriée, elle demande une étude préalable et une définition des relations inter-classes. La méthode procédurale peut s'avérer plus rapide à mettre en oeuvre mais clairement moins adaptée à une gestion fine des relations (héritages impossibles) entre les entités définies au sein de l'API (utilisateurs Unix, Utilisateurs Samba, ...), ainsi que de leurs propriétés (pas d'encapsulation).


Chapitre 9 : Cahier des charges de l'outil d'administration - Contraintes d'implémentation


I) Introduction

Ce chapitre complète la partie fonctionnelle (API) de l'outil d'administration présentée précédemment. Nous allons ici évoquer les contraintes liées à l'implémentation de l'interface utilisateur. Cette interface utilisera la sous-couche applicative proposée par l'API.

II) Etude du besoin

Cette application répond aux besoins d'une application d'administration complète, simple et évolutive, car ce manque est souvent évoqué pour l'administration d'un domaine Samba. L'outil final doit pouvoir s'adresser aux administrateurs ne maîtrisant pas la ligne de commande comme à ceux qui préfèrent cette méthode d'administration. Les administrateurs de solutions Windows n'auront pas à s'adapter à l'outil qui leur proposera un visuel proche des outils communément utilisés. L'outil pourra également permettre d'administrer un ou plusieurs serveurs Samba à distance.

Les besoins spécifiques de l'application ont été étudiés dans les chapitres 5 et 8.

III) Structure de l'application finale

Nous avons défini dans le chapitre 8 l'API qui constituera la base de notre outil. Nous allons ici ajouter deux couches supplémentaires : une couche réseau, qui permettra d'exécuter à distance les fonctions de notre API et ainsi d'administrer plusieurs postes avec le même outil, et une couche graphique qui fera elle-même appel aux fonctions réseau. Voici la structure globale de l'application représentée de manière visuelle :


GUI

Poste d'administration

Interface

API

Samba

Serveur Samba 1

Interface

API

Samba

Serveur Samba 2

Structure en couches de l'application

GUI

Interface

Samba

API

IV) La couche d'interface

Cette couche permet l'invocation des méthodes de notre API sur nos serveurs Samba. Idéalement, ces invocations pourront se faire localement comme à distance par l'implémentation d'un démon exécuté sur la machine Samba qui exécutera les appels à l'API passés depuis l'interface graphique du poste client. Cette administration distante est différente des fonctionnalités offertes par l'API elle-même utilisant les RPC Microsoft.

V) Contraintes fonctionnelles liées à la partie graphique

A) Sélection du serveur à administrer

L'application doit gérer un ensemble de serveurs Samba administrables et permettre d'en sélectionner un à tout moment.

B) Authentification

Permet de spécifier le compte utilisé pour les connexions aux services RPC Samba. Ce compte doit pouvoir être spécifié à tout moment.

C) Gestion de comptes d'administrateurs

Possibilité de sauvegarder la configuration de l'outil pour chaque Administrateur (utilisateur Unix). On pourra également limiter les droits d'administration de chacun (visualisation simple, gestion des partages, des imprimantes, statut des serveurs, gestion des utilisateurs, [...]).

D) Différents modes d'Administration

L'outil devra proposer différents modes pour des profils variés d'administrateurs. Ces modes correspondent à un champ limité d'actions et à des visuels différents. Le passage d'un mode à l'autre doit se faire de manière simple tout en conservant une équivalence dans les options de configuration.


On peut définir les modes suivants :

1) Simple

Offre une interface très simplifiée permettant rapidement de :

- Configurer le rôle du serveur (PDC/BDC)- Nommer le serveur, le domaine- Configurer les partages du serveur- Ajouter/Supprimer des utilisateurs

Le backend est choisi par défaut : tdb, modifiable en passant en mode standard ou expert.

2) Wizards

Mode de configuration proposant plusieurs actions où l'utilisateur est guidé :

- Configuration de notre serveur (PDC/BDC, nom netbios, nom du domaine)- Ajout/Suppression d'un utilisateur- Ajout/Suppression d'un groupe- Ajout/Suppression d'un partage- Ajouter/Suppression d'une imprimante- Joindre le serveur à un domaine- Créer une relation d'approbation- Migrer les comptes depuis un serveur NT4- Import/Export de comptes utilisateurs (fichier texte, xml, ...)- Choix et configuration du backend (tdb, ldap)

3) Standard

- Configuration intégrale des options du fichier smb.conf via cases à cocher, listes déroulantes et zones de texte. (Configuration du serveur, choix du backend, ajout/suppression de partages, d'imprimantes...)- Gestion du système Unix (démons, logs)- Gestion des acteurs (utilisateurs, groupes, machines + import depuis fichier, export)- Gestion du domaine (jonctions, approbations, propriétés du domaine, envoyer un message à une machine)- Migration de comptes (migration depuis NT, import/export)


4) Expert - Full

- Configuration à la main du fichier smb.conf- Ligne de commandes disponible- Tâches ultra-subdivisées (granularité maximale) et classifiées (cf. chapitre 8, VI) : "tâches locales systèmes", "tâches locales Samba", "tâches distantes Samba", "tâches distantes autres". Globalement, chaque fonction de l'API doit être disponible.- Accès à la documentation Samba complète (man, howto-collection, site)

5) NT-Like

Administration via des outils dont le visuel est proche de NT. Sert à l'administration quotidienne du domaine, pour les administrateurs habitués aux outils NT. Offre :

- Un gestionnaire d'utilisateurs- Un gestionnaire de serveur

Ces deux gestionnaires reprennent le visuel est les fonctionnalités des gestionnaires NT, adaptés à Samba. Le gestionnaire de serveur pourra intégrer des fonctions propres à Samba comme la configuration du fichier smb.conf.

6) Monitoring-only

Ce mode permet de surveiller l'état du serveur Samba.

- Démarrer/Arrêter les démons Samba (nmbd/smbd)- Afficher les services du serveur- Afficher le statut du serveur, les utilisateurs connectés, les fichiers ouverts

E) Gestion des modes

Les différents modes pourront être gérés sous forme de plugins afin de pouvoir étendre de manière simple l'outil d'administration.

F) Configurations par défaut

Plusieurs configurations par défaut sont disponibles : contrôleur de domaine, serveur membre, serveur de fichiers autonome, ... Afin de faciliter l'administration initiale du serveur.


G) Conservation des commentaires / propreté du code produit

L'outil devra être capable de conserver les commentaires présents dans le fichier de configuration et produire une fichier de configuration propre et minimal (pas d'options par défaut inscrites).

H) Un mode verbose

Un mode "verbose" doit être présent afin d'afficher explicitement tous les changements (appels API) qui seront appliqués lors de la validation.

I) Snapshots

La possibilité de snapshots à un instant t pourra permettre à un administrateur expérimenté de rétablir la configuration du serveur :

Ce snapshot contiendra :- Le contenu du smb.conf- Un dump des utilisateurs/groupes/machines Unix- Un dump des données du backend Samba- La configuration de l'outil d'administration

J) Internationalisation

L'outil d'administration offrira une interface en plusieurs langues :

- Français- Anglais- Allemand- Espagnol[...]

Il devra être simple d'ajouter une langue à l'outil d'administration en utilisant, par exemple, un fichier contenant l'intégralité des messages dans une langue donnée.

K) Administration de plusieurs serveurs

Une extension de l'outil pourrait être de pouvoir administrer un serveur (même NT) distant, via les RPC Microsoft. L'API propose quelques fonctions qui vont dans ce sens. Ceci peut présenter une fonctionnalité future de l'outil et n'est pas une fonctionnalité requise actuellement.


VI) Contraintes techniques liées à la partie graphique

A) Interface cliente Orientée Web ou "native"

Une interface "orientée web" sera utilisée via un navigateur Internet, tandis qu'une interface "native" se suffira à elle-même :

Interface Web Interface NativePortabilité + -Simplicité, rapidité à mettre en oeuvre + -Maintenabilité + -Rapidité de déploiement / diffusion + -Propreté du code - +Rapidité d'exécution - +Intéractivité - +Compatibilité - +Sécurité - +Attrait visuel - +Uniformité visuelle - +Application autonome - +Utilisation distante de l'outil De base Via export d'affichage

Langages interprétés envisagés :

- Php (apache + mod_php)- Python (apache + mod_python ou CGI)- Perl (apache + mod_perl ou CGI)

On pourrait également utiliser tout autre langage, même compilé, et utiliser des appels CGI. Dans le cas d'un langage compilé, on perd les avantages d'une application "native" en tout en ayant les inconvénients de la compilation. Les appels CGI peuvent être évités en utilisant le mod du langage choisi pour apache web server.

Langages/Librairies compilés envisagés :

- Gtk+ - Gimp Toolkit : C/C++, et nombreux bindings (cf. : http://www.gtk.org/bindings.html)- Qt : C++, bindings C, Perl et Python (cf. : http://www.trolltech.com)- WxGtk : C++, bindings Perl et Python (cf. : http://www.wxwindows.org)

Qt offre une très bonne portabilité (Unix, Windows) et de nombreuses fonctionnalités avancées, mais est payant pour une utilisation commerciale. Gtk+ est un projet libre mais est relativement instable sur plateformes Windows (mais est-ce bien une fonctionnalité nécessaire ?). WxWindows offre une très bonne portabilité et est très intuitive.

B) Documentation complète API et Outil d'administration

L'outil d'administration, ainsi que l'API devront disposer d'une documentation complète afin de permettre aux développeurs désireux de participer au projet de découvrir et de comprendre rapidement le code.Samba 3 - Etudes, propositions et cahier des charges d'un outil d'administration Page 87 sur 94

C) Libre

Le projet sera développé autour de technologies libres et sera diffusé à la communauté.

D) Propreté du code, commentaires, outils standards

L'outil utilisera au maximum les technologies existantes et standardisées. Son code devra être lisible et correctement commenté.

VII) Conclusion

Ce chapitre retrace l'ensemble des éléments à prendre en compte pour le développement de l'outil d'administration finalisé. L'interface graphique présentée ici constitue un composant supplémentaire à l'API définie dans le chapitre 8. Elle offre ici un panel assez complet de fonctionnalités, qui pourront être limitées ou étendues suivant les besoins.


Annexe 1. Glossaire

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) : Terme générique pour désigner un contrôleur de domaine, qu'il soit PDC, BDC (NT) ou qu'il n'ait pas de niveau d'importance particulier (Active Directory).

DN (Distinguish Name) : Au sein d'un annuaire LDAP, représente le nom et le chemin d'un objet. Exemple : "cn=Users,ou=Groups,dc=martymac,dc=com".

GID (Group Identifier) : Identifiant numérique représentant un groupe d'utilisateurs sous Unix.

GUI (Graphical User Interface) : Interface graphique

LDAP (Lightweight Directory Access Protocol) : Adaptation allégée du protocole X500. Protocole de gestion d'annuaires réseaux.

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.

NSS (NSSwitch, Name Service Switch) : Mécanisme qui intercepte les requêtes de noms effectuées par la machine (concernant les noms de machines, d'utilisateurs : cf. getent, ...) et les redirige vers différentes sources d'informations (LDAP, MySQL...). Fonctionne avec différents modules.

PAM (Pluggable Authentication Modules) : Mécanisme d'authentification par modules. Il est ainsi possible d'utiliser toutes sortes de sources de données (fichier passwd, LDAP, biométrie...) pour valider un utilisateur.

PDC (Primary Domain Controller) : Contrôleur principal de domaine. Apellation propre à un domaine NT.

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-1-5-21-3493456274-4211610059-1786859526-512 qui identifie le groupe d'Administrateurs du domaine (512) au sein du domaine S-1-5-21-3493456274-4211610059 .

UID (User Identifier) : Identifiant numérique représentant un utilisateur sous Unix.


UNC (Universal Naming Convention) : Convention de nommage universelle (sous Windows) permettant de désigner le chemin d'un répertoire partagé. Ex. : \\Serveur\partage.

Annexe 2. Liens - Bibliographie

Général :http://www.samba.orghttp://samba.idealx.orghttp://www.openldap.orghttp://www.linuxfr.org

Howtos :http://de.samba.org/samba/docs/Samba-HOWTO-Collection.pdfhttp://samba.idealx.org/samba-ldap-howto.pdfhttp://www.martymac.com/contribs/samba2.2-Ldap/html/index.html

Tldp - LDAP :http://www.tldp.org/HOWTO/LDAP-Implementation-HOWTO/

Listes de diffusion officielles :- [email protected] : http://lists.samba.org- [email protected] : http://lists.samba.org

Liste de diffusion Samba-fr :http://listes.ujf-grenoble.fr/wws/info/samba-fr

Outils d'administration : cf. chapitre 5.

Annexe 3. Remerciements

Merci à René Boillot (Genesta), Patrick Andujar (Genesta), Xavier Lemesle (EDF) et David Lacoste (EDF) pour leur accueil, leur soutien et l'aide qu'ils ont su m'apporter.


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 02111-1307 USAEveryone is permitted to copy and distribute verbatim copiesof 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.

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."

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright (c) YEAR YOUR NAME. 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".


If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:

with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.


Documents

Martymac.orgcontribs.martymac.org/sambaEtudes/Etude_Samba_et_se… · Web viewEDF R&D. Département SINETICS. Groupe Infrastructures de communication et securite. 1, avenue du général