Creating a Samba Server with LDAP and XFS Exploring SAMBA/ LDAP / XFS www.boulderdash.org Jérôme Verdon
2 TITRE UN SERVEUR SAMBA / OPENLDAP / XFS RESUME Description de l installation et de la configuration d un serveur SAMBA jouant le rôle de PDC pour les station Windows du réseau local, authentifiant les utilisateurs sur un service LDAP et autorisant la manipulation des permissions sur les fichiers et répertoires des partages de SAMBA par les utilisateurs depuis leur station Windows. ORIGINE Jérôme VERDON VISA Destinataires Services A Destinataires Services I HISTORIQUE Motifs 20/03/2003 1.0 JEROME VERDON Création du document 1.1 JEROME VERDON Modification du document 19/05/2003 JEROME VERDON Modification du document Un serveur SAMBA / OPENLDAP / XFS 2
3 1 INTRODUCTION... 5 2 DESCRIPTION... 5 3 LE SYSTEME D EXPLOITATION... 6 4 OPENLDAP... 6 4.1 LA CONFIGURATION DU SERVEUR... 7 4.2 L ARBRE LDAP... 8 4.3 LE REMPLISSAGE DE L ARBRE LDAP... 10 4.4 LA MANIPULATION D UN ARBRE LDAP... 10 5 SAMBA... 11 5.1 RECONSTRUCTION DES PAQUETS SAMBA XFS ACL - LDAP... 11 5.2 LE FICHIER DE CONFIGURATION... 12 5.3 MANIPULATION DES OBJETS SAMBA... 14 5.3.1 LE PACK SMBLDAP-TOOLS...14 5.3.2 LA CONFIGURATION DES SMBLDAP-TOOLS...14 5.3.3 ENTRÉES INITIALES...14 5.3.4 L ADMINISTRATION DES UTILISATEURS...15 5.3.4.1 Le rapport entre UID et RID...15 5.3.4.2 La création d un compte utilisateur UNIX (POSIX)...15 5.3.4.3 La création d un compte utilisateur SAMBA...15 5.3.4.4 Assigner un mot de passe à un utilisateur...16 5.3.4.5 Supprimer un compte utilisateur POSIX...16 5.3.4.6 Supprimer un compte utilisateur SAMBA...16 5.3.5 L ADMINISTRATION DES GROUPES...16 5.3.6 L ADMINISTRATION DES ORDINATEURS...16 5.3.6.1 Création d un compte ordinateur...17 5.3.6.2 Suppression d un compte ordinateur...17 5.3.7 L ADMINISTRATION DES PROFILES UTILISATEURS...17 5.3.7.1 Les Roaming Profiles...17 5.3.7.2 Les Mandatory Profiles...17 5.3.8 LES SCRIPTS DE CONNEXIONS...18 5.3.9 MIGRER UNE BASE EXISTANTE...18 6 LES STATIONS WINDOWS... 18 6.1 ENREGISTREMENT D UNS STATION WINDOWS SUR LE DOMAINE... 18 6.2 GESTION DES DROITS DEPUIS UNE STATION WINDOWS... 20 7 LE CARNET D ADRESSES POUR OUTLOOK... 21 7.1 COTE SERVEUR - LDAP... 21 Un serveur SAMBA / OPENLDAP / XFS 3
4 7.2 COTE CLIENT - OUTLOOK... 22 8 IMAP ET POP3... 24 9 APACHE... 24 9.1 LA CONFIGURATION DU SERVEUR APACHE... 24 9.2 LA PROTECTION DES REPERTOIRES DU SITE... 25 10 REFERENCES... 26 11 ANNEXES... 27 11.1 DISQUETTES DE BOOT XFS POUR L INSTALLATION D UN SYSTEME DEBIAN... 27 1 COMMANDES POUR UN SYS TEME DE FICHIERS XFS... 27 1.1 INTRODUCTION...27 1.2 MAIS POURQUOI VOULOIR UTILISER DES ACL?...29 1.3 STRUCTURE D'UNE ACCESS CONTROL LIST...29 1.4 MANIPULATION D'UNE ACCESS CONTROL LIST...29 1.5 UTILISER LES ACL...30 1.6 CONCLUSION...31 11.3 FICHIER SLAPD.CONF... 31 11.4 FICHIER BASE.LDIF... 32 11.5 FICHIER SMB.CONF... 34 11.6 EXEMPLES DE COMPTES LDAP... 36 11.6.1 COMPTE UTILISATEUR POSIX ET SAMBA...36 11.6.2 COMPTE UTILISATEUR POSIX ET NON SAMBA...37 11.6.3 COMPTE ORDINATEUR...37 Un serveur SAMBA / OPENLDAP / XFS 4
5 1 Introduction Ce document a pour but de décrire l installation d un système Linux jouant le rôle d un contrôleur de domaine Microsoft, en le couplant avec un serveur LDAP pour l authentification des utilisateurs (et donc de centraliser l authentification des utilisateurs sur le système), ainsi que la gestion des ACLS permettant ainsi une gestion très fine des permissions sur les fichiers et répertoires. 2 Description Le système sur lequel est installé le serveur Samba avec le support XFS et l authentification LDAP est un système Linux Debian Woody dont les partitions ont été formatées pour un système de fichiers XFS (système de fichiers journalisé de SGI Silicon Graphics). Le serveur samba installé est un PDC (Primary Domain Controler) pour le réseau local. Il authentifie les utilisateurs des stations Windows (Me et XP), exécute un script lors de la connections de l utilisateur, et sauvegarde et recharge le profile de l utilisateur à chaque connection/déconnection. Ce document a été écrit après avoir mis en place et testé le bon fonctionnement du serveur (qui est d ailleurs en production) avec les versions suivantes : Samba 2.2.8 Openldap 2.0.x Debian Woody Ce document décrit la configuration d un serveur samba qui sera contrôleur de domaine primaire pour les postes de travail Windows du réseau local et d un serveur OpenLDAP qui aura pour rôle l authentification des stations de travail et des utilisateurs sur ce service SAMBA. Nous considérons comme pré requis pour la suite : Tous les postes de travail et serveurs sont dans le même LAN et dans le même plan d adressage privé et sont correctement configurés. La résolution DNS fonctionne correctement. Les objectifs à atteindre sont : La configuration du contrôleur de domaine pour le domaine BOULDERDASH. Ce contrôleur de domaine doit être un serveur WINS et master browser server pour le domaine BOULDERDASH. Tout les objets d authentification (utilisateurs et groupes) seront stockés sur un serveur LDAP en utilisant la base DN: dc=boulderdash, dc=org. Les comptes utilisateurs seront stockés dans «ou=users, ou=group,dc=boulderdash, dc=org». Les comptes ordinateurs seront stockés dans «ou=computers, ou=group,dc=boulderdash, dc=org». Les groupes seront stockés dans «ou=groups, ou=group,dc=boulderdash, dc=org». En bonus, nous verrons comment coupler d autres services tels qu apache, courier-pop ou courier-imap sur notre serveur LDAP. Un serveur SAMBA / OPENLDAP / XFS 5
6 3 Le système d exploitation Afin de pouvoir administrer les permissions sur les fichiers et répertoires des partages Samba depuis une station Windows, il est indispensable que le système de fichiers hébergeant ces partages supporte un système d ACL (Access Control List). Ici, le choix s est porté sur le système de fichier XFS de SGI pour ses performances. Par défaut, un système debian s installe sur un système de fichiers de type EXT2. Toutefois, des disquettes patchées avec un noyau compilé avec le support XFS, et les utilitaires nécessaires sont disponibles sur Internet. Toutes les URL sont disponibles en annexe de ce document. Ainsi, le système Debian pourra être intégralement installé sur des partitions XFS. Notre serveur Linux sera donc installé sur un disque partitionné comme suit : Partition Point de montage Système de fichiers Options de montages /dev/hda1 / XFS RW /dev/hda4 /goinfre XFS RW, QUOTA /dev/hda5 /root XFS RW /dev/hda6 /var XFS RW /dev/hda7 /usr XFS RW /dev/hda8 /home XFS RW Les partitions qui seront partagées avec Samba seront les partitions /home pour les comptes utilisateurs, et la partition /goinfre qui servira à hébergé une partition ou les utilisateurs pourront mettre ce qui veulent dessus. En ligne de commande UNIX, les ACL sur ces partitions seront manipulées avec les commandes setfaccl, getfaccl, Des explications sur ces commandes sont fournis en annexe de ce document. 4 Openldap La deuxième partie consiste à installer un serveur LDAP, et à le configurer pour qu il puisse servir pour l authentification du service Samba. Les paquets nécessaires sont : Pour l installation : - ldap-utils - libldap2 - OpenLDAP libraries (without TLS support). - libldap2-dev - slapd Apt-get install ldap-utils libldap2 libldap2-dev slapd L ensemble des fichiers de configuration du serveur LDAP se situe dans le répertoire «/etc/ldap» : - ldap.conf Un serveur SAMBA / OPENLDAP / XFS 6
7 Contient les informations que le système doit contacter dans le cas d un contact LDAP. - slapd.conf Contient la configuration du serveur LDAP. Dans le répertoire «/etc/ldap/schema» se situent les fichiers contenant les schémas LDAP nécessaires, on a donc besoin des schéma suivant : - extension.schema - (krb5-kdc.schema) - openldap.schema - core.schema - inetorgperson.schema - misc.schema - samba.schema Par rapport, aux schémas fournit de base, il faut donc rajouter les deux schémas suivant : - samba.schema Pour le support de Samba. - outlook.schema Pour le carnet d adresse Outlook. 4.1 La configuration du serveur Tous les paquets nécessaires sont maintenant installés, la configuration va donc être faite dans le fichier «/etc/ldap/slapd.conf». Un exemple de fichier de configuration fonctionnel est fournit en annexe, mais nous allons détailler ici les quelques options importantes. On indique dans un premier temps, les schémas que le serveur LDAP doit prendre en compte et gérer (les schémas importants pour le support de SAMBA, puis à moindre degré d Outlook sont marqués en gras) : include include include include include include include /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/inetorgperson.schema /etc/ldap/schema/samba.schema /etc/ldap/schema/extension.schema /etc/ldap/schema/outlook.schema Le type de la base LDAP database ldbm Le base de l annuaire que nous allons créer, ici nous nous servons du nom de domaine du réseau sur lequel le serveur LDAP sera utilisé, mais c est au libre choix de l administrateur : suffix "dc=boulderdash,dc=org" Le login administrateur et le mot de passe associé de l arbre LDAP en question (et non pas de l administrateur du système qui héberge le service LDAP) Un serveur SAMBA / OPENLDAP / XFS 7
8 rootdn rootpw "cn=admin,dc=boulderdash,dc=org" secret La localisation sur le système de fichiers ou sont stockés les fichiers de la base directory "/var/lib/ldap" Les mots clé d indexation index objectclass eq Les ACL positionnant les permissions sur les types d objets en fonction des utilisateurs (ici par exemple, l administrateur définit ci-dessus a accès à tout les champs) access to attribute=userpassword by dn="cn=admin,dc=boulderdash,dc=org" write by anonymous auth by self write by * none access to * by dn="cn=admin,dc=boulderdash,dc=org" write by * read 4.2 L arbre LDAP Maintenant que le serveur est configuré, il va rester deux choses, la création de l arbre LDAP, et le remplissage des objets. Nous allons donc créer l arborescence LDAP que l on veut utiliser, elle sera créée dans un fichier au format LDIF. La base LDAP sera mise dans un fichier texte LDIF, puis ajouté par la commande : ldapadd -x -D "cn=admin,dc=boulderdash,dc=org" -W -f./base_ldap.ldif La base LDAP est représentée par le schéma suivant : Un serveur SAMBA / OPENLDAP / XFS 8
9 Base DN dc=boulderdash,dc=org Ou=Groups Ou=Users Ou=Computers Ou=Contacts Cn=Domain Admins Cn=Domain Users Cn=Domain Guests Cn=Administrators Cn=Users Cn=Guests Cn=Power Users Cn=Account operators Cn=server Operators Cn=Print Operators Cn=Backup Operators Cn=Replicators Le fichier LDIF correspondant à cet arbre est fournit en annexe de ce document. Un serveur SAMBA / OPENLDAP / XFS 9
4.3 Le remplissage de l arbre LDAP 10 Maintenant que la structure de l arbre LDAP est crée, il reste à insérer tous les objets à l intérieur. Dans notre cas, il existera 4 types différends d objets : - Utilisateur POSIX Cet utilisateur correspond à un utilisateur du système qui possède un compte UNIX, mais pas de compte SAMBA. Il ne pourra donc pas se connecter sur le domaine Samba. - Utilisateur SAMBA Cet utilisateur correspond à un utilisateur qui possède un compte Samba, il pourra donc s authentifier sur le domaine. En plus de l attribut samba, il pourra aussi posséder l attribut POSIX et posséder un compte UNIX classique. - Ordinateur Cet utilisateur ne possède qu un compte SAMBA. En fait il correspond à une station Windows autorisées à se connecter sur le domaine. Le nom d un utilisateur de ce type sera de la forme NOM$. - Contact Cet objet correspond à un contact pour le carnet d adresse. Il ne possède ni compte Samba, ni compte UNIX. Il convient donc maintenant de rentrer les utilisateurs dans la base. De la même façon que pour l arbre LDAP, la définition de ceux-ci seront écrit dans un fichier LDIF, puis rajouter de la même manière grâce à la commande : ldapadd -x -D "cn=admin,dc=boulderdash,dc=org" -W -f./users_ldap.ldif Deux exemples d entrées utilisateurs sont fournis en annexe, un compte utilisateur SAMBA, et un compte utilisateur POSIX non SAMBA. Enfin, pour compléter la configuration de notre arbre Samba, et le rendre prêt à l emploi, il reste une dernière chose. Pour enregistrer une station Windows sur un domaine samba, seul un compte root peut le faire. Il est donc nécessaire de créer un «faux» utilisateur root dans l arbre LDAP, grâce aux commandes suivantes : smbldap-useradd.pl -a -m -g 0 root smbldap-usermod.pl -u 0 -g 0 root smbldap-passwd.pl root 4.4 La manipulation d un arbre LDAP Avec l installation du serveur OpenLDAP, sont fournit un ensemble d outils en ligne de commande pour manipuler les données de l arbre. Par exemple : La recherche de tous les objets ldapsearch -x -b "dc=boulderdash,dc=org" '(objectclass=*)' La recherche dans les objets dont le champ uid à pour valeur «jerome» ldapsearch -x -b "dc=boulderdash,dc=org" '(uid=jerome)' Un serveur SAMBA / OPENLDAP / XFS 10
11 La suppression de l utilisateur «jerome» ldapdelete -x -D "cn=admin,dc=boulderdash,dc=org" -W "uid=snoop,ou=users,ou=group,dc=boulderdash,dc=org" De plus, la société IDEALX a développé un ensemble d outils qui permette de migrer une base UNIX vers une base LDAP. La description de ces outils se expliquée un peu plus loin dans ce document. 5 Samba Enfin, nous terminons par l installation et la configuration du service Samba. Les paquets debian existant ne sont pas compilés avec le support des ACL XFS et le support LDAP, il est donc nécessaire de recompiler les paquets. Pour cela, nous allons récupérer les sources de la dernière versions 2.2.8 sur le site www.samba.org, puis recompiler ces sources avec les options manquantes afin de recréer les paquets. 5.1 Reconstruction des paquets Samba XFS ACL - LDAP Afin de pouvoir modifier les ACL des fichiers et répertoires du système de fichiers XFS depuis un postes Windows, il est indispensable de recompiler les paquets Samba Debian. De plus, afin de pouvoir compiler Samba avec le support des ACL, il faut installer le paquet suivant : acl-dev Ensuite, il faut récupérer les paquets sources de la dernière version, disponibles sur le site de samba (www.samba.org). On édite alors le fichier «/etc/apt/sources.list», et on y rajoute la ligne suivante : main deb-src http://us2.samba.org/samba/ftp/binary_packages/debian stable On régénère ensuite la base apt avec la commande : Apt-get update Il ne reste alors plus qu à récupérer les paquets : mkdir ~/samba cd ~/samba apt-get source samba cd ~/samba/samba-2.2.8-0.1/debian/ Dans le fichier «rules», il faut rajouter l option «--with-acl-support \» juste avant «--with-msdfs» pour les ACL XFS. Nous aurons donc : [ -f source/makefile ] (cd source &&./configure \ --host=$(deb_host_gnu_type) \ --build=$(deb_build_gnu_type) \ --with-fhs \ --prefix=/usr \ --sysconfdir=/etc \ Un serveur SAMBA / OPENLDAP / XFS 11
12 --with-privatedir=/etc/samba \ --localstatedir=/var \ --with-netatalk \ --with-smbmount \ --with-syslog \ --with-sambabook \ --with-utmp \ --with-readline \ --with-libsmbclient \ --with-winbind \ --with-acl-support \ --with-msdfs \ --with-automount \ --with-profile \ --disable-static \ --with-ldapsam) Enfin, dans le fichier config.cache, il faut modifier la ligne : par : ac_cv_header_sys_acl_h=${ac_cv_header_sys_acl_h=no} ac_cv_header_sys_acl_h=${ac_cv_header_sys_acl_h=yes} Puis on compile le tout pour créer les paquets Debian correspondants à cette nouvelle configuration : cd ~/samba/samba-2.2.3a/ dpkg-buildpackage Il ne reste alors plus qu à installer nos nouveaux paquets fraîchement crées : cd ~/samba/ dpkg -i [de tous les paquets crées] Voilà, c est fait, nous avons maintenant installé un serveur SAMBA supportant l authentification sur un serveur LDAP, et la gestion des droits d accès sur les fichiers et répertoires par les utilisateurs depuis leur station de travail Windows. Important Placez tout les paquets crées et installés précédemment à «HOLD» dans dselect afin d'éviter de voir le système de paquet de Debian qui les remplace par les paquets par défaut de la distribution (les ACL ne fonctionneraient plus et les droits d'accès par défaut de Linux pourraient être trop laxistes). 5.2 Le fichier de configuration Toute la configuration du service Samba est située dans le fichier «/etc/samba/smb.conf». Ce fichier possède une structure bien définie composée d une partie GLOBAL correspondant à la configuration du service samba dans sa globalité, puis une section par partage Samba disponible. Ainsi, nous avons une section Netlogon pour le login des utilisateurs (il contient par exemple des scripts de connections sur le domaine), une section Profiles qui contient le répertoire ou sont contenu les profiles des utilisateurs du domaine. Et une section Homes qui contient les comptes UNIX des utilisateurs. La configuration de l authentification de samba sur l arbre LDAP est faite dans la section globale par les options suivantes : Un serveur SAMBA / OPENLDAP / XFS 12
13 - ldap suffix Contient le base DN de l arbre LDAP sur lequel Samba va authentifier les utilisateurs. - ldap admin dn Contient le login de l administrateur de la base LDAP. - ldap port Le port sur lequel écoute le serveur LDAP (par défaut 389). - ldap server L adresse IP du serveur LDAP à contacter. - ldap ssl Support du protocole SSL. Les options à rajouter dans le fichier de configuration de samba pour le support LDAP et PDC sont uniquement dans la section Globale, et sont : [global] ; Support LDAP ldap suffix = "dc=boulderdash,dc=org" ldap admin dn = "cn=admin,dc=boulderdash,dc=org" ldap port = 389 ldap server = 127.0.0.1 ldap ssl = No ; Support PDC workgroup = boulderdash netbios name = buzz server string = Files Server os level = 66 domain master = yes local master = yes preferred master = yes domain logons = yes logon script = %U.bat logon path = \\%L\profile\%U logon home = \\%L\profile\%U name resolve order = wins bcast lmhosts host dns proxy = no time server = yes ; Support WINS wins support = yes ; Support ACL nt acl support = yes Enfin, on termine en exécutant la commande suivante : smbpasswd -w secret ou «secret» est le mot de passe root sur l arbre LDAP. Afin que Samba puisse se connecter sur l arbre LDAP pour authentifier les utilisateurs. Un serveur SAMBA / OPENLDAP / XFS 13
5.3 Manipulation des objets Samba 14 Toutes les modifications sur des objets Samba, que ce soit un compte ordinateur ou un utilisateur, telles que l ajout, la suppression, la modification, le changement de mot de passe, sont faites à partir d un ensemble de scripts développés en Perl par IDEALX. Nous allons maintenant décrire toutes les opérations spécifiques qui peuvent être nécessaire pour l administration, ainsi que la description des outils développés par IDEALX. 5.3.1 Le pack smbldap-tools Le package smbldap-tools contient un ensemble de scripts qui simplifient et facilitent l administration des utilisateurs et groupes lorsque ceux-ci sont stockés dans une base LDAP. Dans ce document, nous utiliserons ces scripts pour ajouter, effacer, modifier les utilisateurs et les groupes d utilisateurs. Il suffit de télécharger l archive smbldap-tools-0.7.tgz, et d installer les scripts dans le répertoire /usr/local/sbin/. 5.3.2 La configuration des smbldap-tools Le packs de scripts smbldap-tools doit être configuré afin qu il puisse avoir accès au serveur LDAP. Le fichier de configuration «/usr/local/sbin/smbldap.pm» est utilisé par tout les scripts et contient donc les informations suivantes à renseigner afin de pouvoir utiliser les scripts : Le mot de passe RootDN. L adresse IP du serveur LDAP. 5.3.3 Entrées initiales Afin de pouvoir modifier les objets stockés dans l arbre LDAP, le mot de passe administrateur (cn=manager, dc=boulderdash,dc=org, celui qui est définit dans le fichier smb.conf) de l arbre doit être renseigné dans samba. Afin de renseigner ce mot de passe, nous allons utiliser la commande smbpasswd, en supposant que le mot de passe administrateur de l arbre LDAP soit «secret» : smbpasswd -w secret Samba va alors stocker ce mot de passe dans le fichier /etc/samba/secrets.tbd. NB : Le mot de passe administrateur renseigné à SAMBA peut être un autre que le Root DN de l arbre. Un autre compte peut être utilisé, il suffit juste qu il ai les permissions nécessaires pour écrire des comptes sambaaccount et des attributs posixaccount Il faut ensuite créer l administrateur : smbldap-useradd.pl -a -m -g 200 administrator Puis définir son mot de passe : smbldap-passwd.pl administrator Un serveur SAMBA / OPENLDAP / XFS 14
15 NB : Tout utilisateur placé dans le groupe «domain Admins» se verra assigner les droits administrateurs Windows. Afin de tester la configuration de samba, il suffit de lancer la commande «testparam». 5.3.4 L administration des utilisateurs Pour administrer les comptes utilisateurs, les scripts suivant sont utilisés : smbldap-useradd.pl Pour ajouter un nouvel utilisateur. smbldap-userdel.pl Pour supprimer un utilisateur. smbldap-usermod.pl Pour modifier les propriétés d un utilisateur. 5.3.4.1 Le rapport entre UID et RID Pour calculer le «userrid», SAMBA utilise le calcul suivant : userrid = 2 * uidnumber + 1000 grouprid = 2 * gidnumber + 1001 Ce calcul est utilisé pour tout les utilisateurs, sauf pour les user rids des utilisateurs spéciaux. Les seuls «well-known rids» sont : Domain User Admin 0x1F4 Domain User Guest 0x1F5 Les rids des utilisateurs et des groupes doivent être donnés en valeur héxadécimales dans l arbre LDAP. 5.3.4.2 La création d un compte utilisateur UNIX (POSIX) Pour créer un utilisateur POSIX (compte UNIX classique), dont le login sera testldap, il suffit d utiliser : smbldap-useradd.pl m testldap Puis : smbldap-passwd.pl testldap pour définir son mot de passe. 5.3.4.3 La création d un compte utilisateur SAMBA Pour créer un utilisateur SAMBA (SambaAccount, compte UNIX classique et SAMBA), dont le login sera testldap, il suffit d utiliser : Un serveur SAMBA / OPENLDAP / XFS 15
16 smbldap-useradd.pl a m c «Utilisateur de test» testldap Puis : smbldap-passwd.pl testldap pour définir son mot de passe. 5.3.4.4 Assigner un mot de passe à un utilisateur Pour assigner le mot de passe d un utilisateur, la commande smbldap-passwd.pl sera utilisée en remplacement de la commande système classique : smbldap-passwd.pl testldap 5.3.4.5 Supprimer un compte utilisateur POSIX Pour supprimer un utilisateur POSIX de la base : smbldap-userdel.pl -r testldap 5.3.4.6 Supprimer un compte utilisateur SAMBA Pour supprimer un utilisateur SAMBA de la base : smbldap-userdel.pl -r testldap 5.3.5 L administration des groupes De la même façons que la gestion des utilisateurs, la gestion des groupes est faite par plusieurs scripts fournis : smbldap-groupadd.pl Création d un groupe. smbldap-groupdel.pl Suppression d un groupe. smbldap-groupmod.pl Modification d un groupe existant. 5.3.6 L administration des ordinateurs Pour administrer les comptes utilisateurs correspondants aux stations de travail, un ensemble de scripts est disponible. En fait, les mêmes scripts que pour la gestion des utilisateurs sont utilisés : Un serveur SAMBA / OPENLDAP / XFS 16
17 smbldap-useradd.pl Ajouter une nouvelle station de travail. smbldap-userdel.pl Supprimer une station de travail. smbldap-usermod.pl Modifier les propriétés d une station de travail existante. 5.3.6.1 Création d un compte ordinateur Pour créer un compte ordinateur, il suffit de : smbldap-useradd.pl -w testcomputer1 5.3.6.2 Suppression d un compte ordinateur Pour effacer un compte ordinateur avec les outils, il suffit de : smbldap-userdel.pl computer1 Au lieu d effacer un compte ordinateur, il peut être nécessaire de simplement le désactiver. Il suffit alors de modifier le champ «accflags» correspondant au compte ordinateur en question, et de modifier la valeur «[W]» en «[WD]» (D pour «disabled»). Pour ré activer un compte, il suffit de faire l opération inverse. 5.3.7 L administration des profiles utilisateurs 5.3.7.1 Les Roaming Profiles Lorsqu un utilisateur du domaine se connecte sur le domaine, son profile est automatiquement sauvegardé dans le répertoire définit dans la section «profile» du fichier de configuration de samba. Ce profile est enregistré à chaque déconnexion de l utilisateur du domaine. C est un «roaming profile» (profile errant) car l utilisateur peut utiliser son profile depuis n importe quelle station du domaine autorisée à se connecter sur le domaine. Si la configuration personnelle de l utilisateur change, elle sera intégrée à son profile. Un profile errant «standard» a une taille d à peu près 186 Kb (plus ou moins suivant différents paramètres tels que l image de fonds,...). 5.3.7.2 Les Mandatory Profiles Les profiles mandatés sont crées de la même façon que les profiles errants. La seule différence est que ce type de profil est crée en lecture seul par l administrateur ce qui implique que l utilisateur ne peut avoir qu un seul profil sur le domaine. Afin de créer un profil mandaté, il suffit de créer un profil errant, et de renommer le fichier «Nuser.dat» en «NTuser.man» (pour profil MANdaté), puis enlever le bit d accès. Par exemple : Un serveur SAMBA / OPENLDAP / XFS 17
18 mv /home/smb/profiles/testsmbuser1/ntuser.dat /home/smb/profiles/testsmbuser1/ntuser.man chmod -w /home/smb/profiles/testsmbuser1/ntuser.man De cette façon, il est possible de créer un profil commun à tous les utilisateurs du domaine. 5.3.8 Les scripts de connexions Des scripts de connexions peuvent être utilisés pour les connexions des utilisateurs sur le domaine. Ces scripts sont des fichiers exécutables au format Windows (.BAT ou.cmd) 5.3.9 Migrer une base existante Plutôt que d entrer les utilisateurs un par un, la base d utilisateur peut être migrée en utilisant le script «smbldap-migrate-accounts.pl pour remplir automatiquement l arbre LDAP à partir d un fichier d utilisateurs SAMBA classique. Les script utilise les options suivantes : -a : ne traite que les utilisateurs, ignore les comptes ordinateurs. -w : ne traite que les comptes ordinateurs, ignore les utilisateurs. Ainsi, pour remplir l arbre LDAP, il suffit de : smbldap-migrate-accounts.pl < pwdump-file.txt ou le fichier pwdump-file.txt contient la liste des comptes utilisateurs. 6 Les stations Windows 6.1 Enregistrement d uns station Windows sur le domaine Enfin, il ne reste plus qu à configurer les stations Windows qui doivent s enregistrer sur le domaine : 1. La clé de registre pour les postes 2000 et XP. Pour qu une station Windows 2000 ou XP puisse entrer dans un domaine Microsoft dont le PDC est un samba, il faut modifier une clé de la base de registre : [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters] "requiresignorseal"=dword:00000000 Celle-ci correspond à une propriété du chiffrement du mot de passe lors du logon d un utilisateur depuis la station sur le domaine. Cette propriété à été modifié depuis la version 2000 de Windows. Par défaut, sur une station XP, la valeur de cette clé est à 1. Si cette clé n est pas modifiée, la station pourra être enregistrée sur le domaine, mais des problèmes se poseront lorsque les utilisateurs essayeront de se connecter. Un serveur SAMBA / OPENLDAP / XFS 18
19 2. Enregistrer la station Windows dans le domaine : a. Click droit sur le poste de travail, puis onglet «nom de l ordinateur» b. Cliquer sur «Modifier» Un serveur SAMBA / OPENLDAP / XFS 19
20 c. Cocher la case «Domaine», et renseigner le nom du domaine Samba, puis terminer en cliquant sur «OK». Une fenêtre s ouvre alors en demandant un login et un mot de passe, il faut donner alors le couple login/password de l utilisateur root qui a été créé spécialement dans l arbre LDAP. Ensuite un message s affiche indiquant la bienvenue dans le domaine. Ca y est, la station est prête à se connecter sur le domaine. On redémarre la station Windows, et là, ô miracle, on peut se connecter sur le domaine, et même changer les propriétés des fichiers et répertoires situés sur les partitions XFS du serveur Linux. 6.2 Gestion des droits depuis une station Windows Il est donc maintenant possible de gérer les permissions sur les fichiers et répertoires depuis une station Windows. Un serveur SAMBA / OPENLDAP / XFS 20
21 Toutefois, les permissions qui seront gérées, seront celles des ACL du système de fichiers XFS. En effet les permissions classiques UNIX (Owner-Group-World) ne sont pas administrables. Une version ultérieure de ce document expliquera plus en détail la gestion de ces permissions depuis Windows. 7 Le carnet d adresses pour Outlook 7.1 Coté serveur - LDAP Il est possible dans Outlook (la version utilisée ici est Outlook XP), d utiliser un carnet d adresse basé sur un serveur LDAP. L idée est donc de rajouter des objets dont la structure correspond aux contacts d un carnet d adresse d Outlook. Afin de pouvoir supporter les attributs d Outlook, il est indispensable de rajouter le schéma LDAP correspondant : «schema.outlook». Nous allons donc créer une «organization Unit» spécifique aux contacts dans l arborescence de l arbre LDAP : dn: ou=contacts,dc=boulderdash,dc=org objectclass: top objectclass: organizationalunit Un serveur SAMBA / OPENLDAP / XFS 21
22 ou: Contacts description: Carnet d adresses Un objet correspondant à un contact possèdera les attributs suivant : dn: uid=,ou=contacts,dc=boulderdash,dc=org uid: cn: objectclass: top objectclass: person objectclass: inetorgperson objectclass: officeperson mail: givenname: sn: homepostaladdress: postaladdress: l: st: postalcode: c: telephonenumber: homephone: title: facsimiletelephonenumber: Le schéma nécessaire pour le support du carnet d adresse Outlook, ainsi qu un exemple d entrée du carnet d adresse sont fournis en annexe de ce document. 7.2 Coté client - Outlook Ensuite, il ne reste plus qu à configurer le nouveau serveur LDAP dans Outlook : 1. Cliquer sur «outils/comptes de messagerie», «ajouter un nouvel» puis «Suivant» 2. Cliquer sur «Service d annuaire Internet (LDAP)» puis «Suivant» Un serveur SAMBA / OPENLDAP / XFS 22
23 3. Puis entrer les propriétés du serveur LDAP sur lequel le carnet d adresse est disponible : Un serveur SAMBA / OPENLDAP / XFS 23
24 Le carnet d adresse est maintenant configuré dans Outlook, il ne reste plus qu à l utiliser. 8 IMAP et POP3 Il est possible, d authentifier tout les services supportant LDAP, ou PAM sur l arbre LDAP et donc de centraliser l authentification dessus. Ceci en bénéficiant des avantages du protocole LDAP. Ici, l authentification LDAP sera mise en place pour les serveurs courier-imap et courier-pop. Cette configuration fera l objet d une deuxième documentation un peu plus tard. 9 Apache De même, l authentification NCSA d apache peut être configurée pour authentifier les utilisateurs directement sur l arbre LDAP. Ainsi, pour protéger un répertoire, il n y aura plus besoin d avoir les deux fichiers «.htaccess» et «.htpasswd». Seul le fichier.htaccess comportant l authentification sera suffisant. 9.1 La configuration du serveur Apache Il suffit pour cela de charger le module supportant l authentification LDAP. Ceci se fait par la directive LoadModule du fichier de configuration d apache. Avec une installation classique d apache, il suffit donc de rajouter dans le fichier «/etc/apache/httpd.conf» de configuration d apache les lignes suivantes : Un serveur SAMBA / OPENLDAP / XFS 24
25 LoadModule auth_ldap_module /usr/lib/apache/1.3/auth_ldap.so LoadModule ldap_module /usr/lib/apache/1.3/mod_ldap.so Nous redémarrons ensuite le service apache : /etc/init.d/apache stop && /etc/init.d/apache start 9.2 La protection des répertoires du site Maintenant que le serveur apache supporte l authentification LDAP, il suffit de placer uniquement un fichier.htaccess dans le(s) répertoire(s) à protéger. Par exemple : AuthName www.boulderdash.org AuthType Basic AuthLDAPURL ldap://127.0.0.1:389/ou=users,ou=group,dc=boulderdash,dc=org?uid require valid-user Un serveur SAMBA / OPENLDAP / XFS 25
26 10 s Le site de la société IDEALX www.idealx.com THE SAMBA -2.2.4/LDAP PDC HOWTO Document écrit par la société IDEALX Le site officiel du projet SAMBA www.samba.org Using Samba, 2 nd Edition De David Collier-Brown, Robert Eckstein, Jay Ts Editions O Reilly Des liens sur les ACLS http://acl.bestbits.at http://acl.bestbits.at/download.html http://e2fsprogs.sourceforge.net ftp://ftp.kernel.org ftp://alpha.gnu.org/gnu/fetish/ Un serveur SAMBA / OPENLDAP / XFS 26
27 11 Annexes 11.1 Disquettes de boot XFS pour l installation d un système Debian Les disquettes de démarrage comprenant un noyau dont le support XFS est activé, permettant l installation d un système Debian sur des partitions XFS peuvent être trouvées sur : http://people.debian.org/~blade/xfs-install/ 1 Commandes pour un système de fichiers XFS Les ACLS feront l objet d une documentation spécifique un peu plus tard. Voici pour le moment quelques descriptions. La documentation suivante a été écrite par Christophe Le Cannellier (Saint Paul Research Labs) et publiée dans Linux Magazine France n 28 - Mai 2001, l article complet peut être trouvé à l adresse : http://okki666.free.fr/docmaster/articles/linux100.htm. 1.1 Introduction Les ACL (Access Control Lists = Listes de Contrôle d'accès) permettent de gérer les permissions caractérisant les autorisations d'accès à un fichier de façon beaucoup plus fine qu'avec les mécanismes Unix traditionnels. Le mécanisme traditionnel, permettant de déterminer si un utilisateur donné possède une autorisation de type donné sur un fichier ou un répertoire, est basé sur un schéma à trois niveaux d'accès distincts, avec trois classes d'utilisateurs également distinctes, soit un codage sur 9 bits, avec en plus 3 bits spéciaux (SetUserID, SetGroupID, StickyBit; respectivement). Les trois niveaux de permission, Read, Write et execute, sont codés chacun sur un bit, sont manipulables avec la commande chmod, et sont appliqués sur les trois uniques classes d'utilisateurs : User, Group, et Other. Dans ce schéma, User représente le propriétaire du fichier, Group les utilisateurs du même groupe que User, c'est-à-dire partageant les mêmes GID (group id, défini dans /etc/group), et Other, tous les autres utilisateurs, c'est-à-dire appartenant à un groupe différent. Le masque de bits contenant les protections données par défaut à un fichier (c'est-à-dire lors de sa création) est stocké dans le fichier inode, et ce masque est initialisé par défaut avec la valeur définie dans la variable d'environnement umask. Cette variable est définie au niveau système, existe pour tout utilisateur donné et peut lui être spécifique, même si la valeur 022 (octal) est la valeur canonique. Cette valeur correspond aux protections rw,r,r pour User, Group et Other, respectivement. Comment passe-t-on de cette valeur octale à ces protections? Le umask, comme son nom l'indique est un masque appliqué avec un OR (somme) sur l'ensemble des bits codant les protections possibles. Un serveur SAMBA / OPENLDAP / XFS 27
28 Remarquez que le premier digit, c'est-à-dire les trois premiers bits (SUID, SGID, sticky), n'est jamais manipulé, et que l'accès de type execute n'est pas pris en compte dans le masque, pour des raisons de sécurité. Voici la table décrivant les bits codant la protection de tout fichier, et si vous y appliquez un masque, en tenant compte des deux règles de protection que nous venons de voir, vous obtiendrez alors le codage effectif. owner 0400 (a=rwx,u-r) Read by owner 0200 (a=rwx,u-w) Write by owner 0100 (a=rwx,u-x) Execute (search in directory) by 0040 (a=rwx,g-r) Read by group 0020 (a=rwx,g-w) Write by group 0010 (a=rwx,g-x) Execute/search by group 0004 (a=rwx,o-r) Read by others 0002 (a=rwx,o-w) Write by others 0001 (a=rwx,o-x) Execute/search by others Ce schéma, bien qu'efficace et pouvant répondre à nombre de situations, n'offre guère de souplesse, notamment en raison de son incapacité à offrir la possibilité de spécifier un ensemble de permissions spécifiques à un utilisateur donné ou à un groupe d'utilisateurs donné, en dehors de la notion de GID dans ce dernier cas. Les ACL offrent la possibilité de définir des droits d'accès sur des fichiers ou des répertoires au sein d'un système de fichiers, pour des ensembles d'utilisateurs, en s'affranchissant de la notion d'identification d'utilisateur (uid), ou de groupe (gid). Les accès consentis par une liste de contrôle d'accès vont venir enrichir, et non remplacer, les protections offertes par le schéma classique. Les trois classes d'appartenance (User, Group, Other) vont pouvoir être vues comme trois entrées (de base) dans une liste de contrôle des droits d'accès, potentiellement plus riche de caractérisations spécifiques. Cette fonctionnalité est conforme au standard Posix 1003.1e version 17, lequel définit les relations entre ces deux mécanismes de protection. Ainsi, en allant au-delà du cadre traditionnel User / Group / Other que nous connaissons tous depuis longtemps, nous allons pouvoir effectuer des opérations permettant de définir des schémas de protection jusqu'alors considérés comme impossibles à réaliser. De plus, il est possible de définir un ensemble d'acl par défaut sur un répertoire, ACL qui seront automatiquement associées à chaque fichier nouvellement créé dans ce même répertoire. La structure d'une ACL est la suivante : entrée:[uid/gid]:permissions Le premier paramètre, entrée, définit l'acl comme établie pour l'utilisateur, le groupe ou les autres, ou bien comme un masque d'acl. Le deuxième paramètre, uid/gid, est l'identification de l'utilisateur ou du groupe, soit en valeur numérique, soit en valeur symbolique, pour l'entrée qui se trouve ici définie. Pour les définitions de masques, et les propriétaires de type other, ce champ n'est pas utilisé et donc n'est pas requis. Un serveur SAMBA / OPENLDAP / XFS 28
29 Le troisième paramètre, permissions, définit quant à lui les permissions associées aux fichiers, et ces permissions sont décrites comme elles le seraient dans le schéma de protection Unix classique. Lorsque sont omis les champs optionnels uid et gid, le schéma de protection traditionnel des systèmes Unix est alors employé. Les ACL sont manipulées par l'utilisateur en création ou en modification avec la commande setfacl(1), et sont manipulées en visualisation avec la commande getfacl(1). Ces deux commandes sont ajoutées aux commandes existant par défaut sur une machine, lors de la mise en place de l'environnement ACL. 1.2 Mais pourquoi vouloir utiliser des ACL? Comme nous l'avons dit précédemment, les ACL permettent de mettre en place des stratégies de sécurité qui ne seraient pas réalisables avec les mécanismes standards. Mais plutôt que de nous lancer dans de fumeuses explications théoriques, nous allons imaginer un scénario nous permettant d'aborder par la pratique la mise en oeuvre des ACL. 1.3 Structure d'une Access Control List Une ACL est une structure composée des données suivantes : ACL_USR_OBJ ACL_USR ACL_GROUP_OBJ ACL_GROUP ACL_MASK ACL_OTHER propriétaire utilisateur identifié groupe d'appartenance groupe nommé droits effectifs autres utilisateurs Les champs ACL_USR_OBJ, ACL_GROUP_OBJ et ACL_OTHER correspondent exactement aux structures de protection conventionnelles sur les fichiers Unix. Il y a une et une seule de chacune de ces trois structures dans une ACL. ACL_USER et ACL_GROUP définissent les appartenances et les droits pour les utilisateurs et les groupes et impliquent une définition dans ACL_MASK. Cette définition limite les droits portés par les deux structures précédentes, en réalisant un droit effectif, qui est la somme des droits portés par les champs USER et/ou GROUP et le masque. Dans le cas où la valeur définie dans le masque vient réduire l'étendue des droits définis dans les champs USER et GROUP, la valeur affichée par la commande getfacl sera suivie du champ effective, indiquant les droits réellement mis en oeuvre. Le caractère + peut être affiché à la suite des attributs d'un fichier suite à un ls -l si les attributs qui sont alors affichés ne décrivent pas complètement les protections associées au fichier. 1.4 Manipulation d'une Access Control List Les permissions de manipulation des ACL sur un inode sont celles qui régissent les autres permissions relatives à la modification des modes d'accès. Les processes avec une autorisation search/execute peuvent lire les ACL existantes, et seul le propriétaire d'un fichier, ainsi que root (sous Linux, seul nanti du CAP_FOWNER), peuvent créer et modifier des ACL. getfacl 0.7.8 -- get file access control lists Un serveur SAMBA / OPENLDAP / XFS 29
30 Usage: getfacl [-adrlpvh] file... -a, --access display the file access control list only -d, --default display the default access control list only --omit-header do not display the comment header --all-effectiveprint all effective rights --no-effective print no effective rights --skip-base skip files that only have the base entries -R, --recursive recurse into subdirectories --post-oder visit subdirectories first -L, --logical logical walk, follow symbolic links -P, --physical physical walk, do not follow symbolic links --tabular use tabular output format --absolute-names don't strip lending '/' in pathnames -v, --version print version and exit -h, --help this help text setfacl 0.7.8 -- set file access control lists Usage: setfacl [-bkndrlpvh] { -s -S -m -M -x -X... }... file... -s, --set=acl set the ACL of file(s), replacing the current ACL -S, --set-file=fileread ACL entries to set from file -m, --modify=acl modify the current ACL(s) of file(s) -M, --modify-file=file read ACL entries to modify from file -x, --remove=acl remove entries from the ACL(s) of file(s) -X, --remove-file=file read ACL entries to remove from file -b, --remove-all remove all extended ACL entries -k, --remove-default remove the default ACL --mask do recalculate the effective rights mask -n, --no-mask don't recalculate the effective rights mask -d, --default operations apply to the default ACL -R, --recursive recurse into subdirectories --post-order visit subdirectories first -L, --logical logical walk, follow symbolic links -P, --physical physical walk, do not follow symbolic links --restore=file restore ACLs (inverse of `getfacl -R') --test test mode (ACLs are not modified) -v, --version print version and exit -h, --help this help text Les systèmes de fichiers seront désormais montés avec le support des ACL par défaut. Vous avez toutefois la possibilité de spécifier le non support des ACL avec l'option de mount attr=noacl, ou de choisir de lancer un boot sur un kernel sans support des ACL. Les paramètres relatifs aux ACL ne sont alors pas pris en compte, et toutes les opérations relatives à la modification des paramètres de sécurité des fichiers ne seront pas répercutées sur les structures ACL, existantes mais non vues. 1.5 Utiliser les ACL La mise en oeuvre des ACL au quotidien, une fois toutes les étapes d'installation accomplies, c'est-àdire de patch et de recompilation, s'avère assez simple. Les commandes utilisateur sont peu nombreuses, et les options ainsi que leurs attributs de commande sont très réduites. Le principe même des ACL est très facile à appréhender, et tout système Linux destiné à être partagé entre plusieurs utilisateurs dans un cadre professionnel devrait en être pourvu. Prenez bien le temps de faire le plan de l'utilisation prévue des ressources de la machine, et tout se passera sans douleur. Les commandes setfacl(1) et getfacl(1) vont vous permettre de définir des ACL, et de voir le contenu des ACL que vous venez de définir, respectivement. Tout n'étant pas encore parfait dans ce monde, les utilitaires de sauvegarde n'ont pas encore connaissance des ACL, ou même des attributs étendus. Cependant, une nouvelle spécification de format d'archive, appelé pax, est en train de voir le jour, et il y a fort à parier pour que cet environnement soit quant à lui à même de prendre en compte ces caractéristiques. Un serveur SAMBA / OPENLDAP / XFS 30
31 Jusqu'à ce jour, le problème de la sauvegarde des ACL sous Linux restera, et seules des stratégies de contournement nous permettront de nous tirer d'affaire. Voici un petit exemple de ce qui peut être fait, afin de nous tirer d'affaire : getfacl -sr. > acl.bck L'option s permet de ne sélectionner que les fichiers possédant des attributs étendus; quant au R, il demande une très classique opération de balayage récursif des répertoires. La restauration des ACL ainsi sauvegardées s'effectue alors comme suit : setfacl - restore=./acl.bck Les attributs étendus se sauvegardent de la même façon, avec les programmes aget et aset. aget -sdr -e base64. > ea.bck L'option e spécifie la valeur d'encodage, ici en base64, mais les options text et hex sont également disponibles. Le choix de l'encodage effectué n'est réellement important qu'en fonction des utilitaires qui pourraient ensuite lire le fichier ainsi généré. asset -B ea.bck 1.6 Conclusion Si toutes les distributions des différents Unix propriétaires, ainsi que d'autres systèmes également (l'auteur a rencontré les ACL pour la première fois sur VAX/VMS en 84/85), possèdent depuis longtemps leur propre implémentation des ACL, la disponibilité de cette fonctionnalité haut de gamme n'est disponible que depuis fort récemment sous notre OS favori. Il reste encore de nombreux développements à envisager afin de parfaire et d'étendre ce qui existe déjà, mais ce qui a été réalisé mérite d'ores et déjà d'être salué et, pourquoi pas, testé en conditions réelles, afin peut-être de combler un manque déjà perçu par certains utilisateurs en environnement de production. Il ne reste qu'à espérer que cet environnement sera accessible dans un proche avenir sur les distributions majeures, sans obliger les personnes ayant besoin de ces fonctions à se livrer à des manipulations complexes, rébarbatives et consommatrices de temps, car si certains font de l'informatique, d'autres, beaucoup d'autres, veulent se contenter de l'utiliser dans le cadre de leurs activités. D'ailleurs, le succès de Linux dépend très largement de l'intégration la plus conviviale possible du plus grand nombre de fonctionnalités possibles, et les éditeurs de distributions Linux qui ont oeuvré dans ce sens ont vu la reconnaissance du marché se manifester au travers de la croissance de leurs parts de marché. Cet article ayant été réalisé à partir de divers articles existant sur le Web, les internautes ayant déjà exploré cette voie peu ou prou ne seront pas surpris de retrouver des exemples, entre autres, similaires à ceux qu'ils auraient déjà pu voir en parcourant certains articles, en particulier ceux que l'on pourra trouver à partir des liens suivants. 11.3 Fichier slapd.conf Voici un fichier fonctionnel de configuration pour OpenLDAP : Un serveur SAMBA / OPENLDAP / XFS 31
32 include include include include include include pidfile argsfile replogfile /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/inetorgperson.schema /etc/ldap/schema/samba.schema /etc/ldap/schema/extension.schema /var/run/slapd.pid /var/run/slapd.args /var/lib/ldap/replog loglevel 0 database suffix rootdn rootpw directory ldbm "dc=boulderdash,dc=org" "cn=admin,dc=boulderdash,dc=org" secret "/var/lib/ldap" index objectclass eq lastmod on access to attribute=userpassword by dn="cn=admin,dc=boulderdash,dc=org" write by anonymous auth by self write by * none access to * by dn="cn=admin,dc=boulderdash,dc=org" write by * read 11.4 Fichier base.ldif dn: dc=boulderdash,dc=org objectclass: domain dc: boulderdash dn: ou=groups,dc=boulderdash,dc=org objectclass: top objectclass: organizationalunit ou: Groups description: System Groups dn: ou=users,dc=boulderdash,dc=org objectclass: top objectclass: organizationalunit ou: Users description: Users of the Organization dn: ou=computers,dc=boulderdash,dc=org objectclass: top objectclass: organizationalunit ou: Computers description: Windows Domain Computers dn: cn=domain Admins,ou=Groups,dc=boulderdash,dc=org objectclass: posixgroup gidnumber: 200 cn: Domain Admins memberuid: administrator description: Windows Domain Users Un serveur SAMBA / OPENLDAP / XFS 32
33 dn: cn=domain Users,ou=Groups,dc=boulderdash,dc=org objectclass: posixgroup gidnumber: 201 cn: Domain Users description: Windows Domain Users dn: cn=domain Guests,ou=Groups,dc=boulderdash,dc=org objectclass: posixgroup gidnumber: 202 cn: Domain Guests description: Windows Domain Guests Users dn: cn=administrators,ou=groups,dc=boulderdash,dc=org description: Members can fully administer the computer/domain objectclass: posixgroup gidnumber: 220 cn: Administrators description: Windows Domain Members can fully administer the computer/domain dn: cn=users,ou=groups,dc=boulderdash,dc=org description: Ordinary users objectclass: posixgroup gidnumber: 221 cn: Users description: Windows Domain Ordinary users dn: cn=guests,ou=groups,dc=boulderdash,dc=org description: Users granted guest access to the computer/domain objectclass: posixgroup gidnumber: 222 cn: Guests memberuid: nobody description: Windows Domain Users granted guest access to the computer/domain dn: cn=power Users,ou=Groups,dc=boulderdash,dc=org description: Members can share directories and printers objectclass: posixgroup gidnumber: 223 cn: Power Users description: Windows Domain Members can share directories and printers dn: cn=account Operators,ou=Groups,dc=boulderdash,dc=org objectclass: posixgroup gidnumber: 224 cn: Account Operators description: Windows Domain Users to manipulate users accounts dn: cn=server Operators,ou=Groups,dc=boulderdash,dc=org objectclass: posixgroup gidnumber: 225 cn: Server Operators description: Windows Domain Server Operators dn: cn=print Operators,ou=Groups,dc=boulderdash,dc=org objectclass: posixgroup gidnumber: 226 cn: Print Operators description: Windows Domain Print Operators dn: cn=backup Operators,ou=Groups,dc=boulderdash,dc=org objectclass: posixgroup gidnumber: 227 cn: Backup Operators description: Windows Domain Members can bypass file security to back up files dn: cn=replicator,ou=groups,dc=boulderdash,dc=org description: Supports file replication in a domain objectclass: posixgroup gidnumber: 228 cn: Replicator description: Windows Domain Supports file replication in a domain Un serveur SAMBA / OPENLDAP / XFS 33