Ce chapitre est basé sur la documentation officielle de CUPS.
CUPS (Common UNIX Printing System) offre une couche d'impression portable pour les systèmes UNIX®. Ce fut développé par Easy Software Products pour faire la promotion d'une solution d'impression standard pour tous les fournisseurs et pour tous les utilisateurs de systèmes UNIX®. CUPS fournit une interface de ligne de commande pour System V et Berkeley.
Lors de la première impression vers une imprimante, CUPS crée une file d'attente pour suivre l'état de l'imprimante (OK, manque de papier, etc.) et des travaux d'impression. La plupart du temps, la file d'attente pointe vers une imprimante branchée directement sur votre ordinateur par USB ou un port parallèle. Par contre, CUPS peut aussi pointer vers une imprimante réseau, sur Internet ou vers plusieurs imprimantes selon votre configuration. Indépendemment de sa destination, CUPS s'affichera comme les autres imprimantes pour vous et vos applications.
À chaque impression, CUPS crée une tâche contenant la file d'attente vers laquelle vous envoyez votre document, le nom du document et la description de page. Les tâches sont numérotées (queue-1, queue-2, etc.) afin de permettre le suivi des tâches en cours d'impression ou l'annulation, si vous constatez une erreur. Lorsque CUPS reçoit une tâche, il détermine le meilleur programme (filtres, pilotes d'imprimantes, moniteur de port, etc.) pour convertir la page en format imprimable et les exécute ensuite pour imprimer le document.
Lorsque la tâche est complètement imprimée, CUPS retire la tâche de la file d'attente, et entame la tâche suivante. Vous pouvez également être averti lorsqu'une tâche est complétée ou en cas de problème.
CUPS utilise le protocole d'impression Internet (IPP) pour gérer les tâches et les listes d'attente. Les protocoles Line Printer Deamon (LPD), Server Block Message (SMB et AppSocket (aussi appelé JetDirect) sont aussi supportés avec des fonctionnalités limitées. CUPS ajoute la consultation d'imprimante réseau et les options basées sur PostScript Printer Description (PPD) pour permettre l'impression de tous les jours avec UNIX®.
CUPS inclut également
une image RIP qui permet d'imprimer sur des
imprimantes incompatibles avec PostScript. Une version
personnalisée de GNU Ghostscript 7.05
pour CUPS appelée ESP Ghostscript
est disponible séparément pour supporter l'impression de fichier
PostScript à travers l'architecture du pilote CUPS. Des
exemples de pilotes utilisant ces filtres pour les imprimantes
Dymo, EPSON, HP et OKIDATA sont inclus.
Mandriva Corporate Server 4 fournit CUPS 1.2, avec des nouvelles fonctionnalités. En voici quelques-unes :
Détection d'imprimantes réseau : CUPS peut maintenant trouver des imprimantes sur le réseau grâce à SNMP.
Support LDAP : CUPS supporte désormais le partage d'imprimantes via LDAP version 3 (Lightweight Directory Access Protocol).
Exportation d'imprimante vers Samba : la page d'administration propose maintenant un bouton qui permet d'exporter les pilotes d'imprimantes vers les clients réseau par Samba.
Déterminer les usagers permis : vous pouvez maintenant établir la liste des usagers ou des groupes ayant la permission (ou non) d'accéder à une imprimante ou à une classe.
Gestion des tâches: vous pouvez annuler toutes les tâches pour une imprimante ou la déplacer vers une autre imprimante.
API CUPS : la sécurité et les performances ont été amélioré.
Pour en savoir plus, consultez le site officiel de CUPS : http://cups.org/
Voici les paquetages dont
vous aurez besoin pour profiter du serveur CUPS ainsi que
les principaux fichiers ppd requis par la
plupart des imprimantes.
cups-drivers : contient les pilotes d'imprimantes spéciaux à utiliser avec CUPS et leur fichier PPD appropriés.
hplip-hpijs-ppds : fichier PPD pour le pilote de l'imprimante HPIJS
postscript-ppds : contient les fichiers PPD pour de vieilles imprimantes PostScript
hplip: un paquetage de pilotes HP pour fournir du support GNU/Linux pour la plupart des imprimantes Hewlett-Packard DeskJet, LaserJet, PSC, OfficeJet, et PhotoSmart, ainsi que les périphériques tout-en-un.
Décrivons l'arborescence de CUPS :
/etc/cups: fichiers de configuration tels queprinters.conf, annulés par la directive ServerRoot danscupsd.conf./usr/lib/cups: programmes serveur tels quebackendsetfilters, annulés par la directive ServerBin danscupsd.conf./usr/share/cups: fichiers de données tels que des polices, annulés par la directive DataDir danscupsd.conf./usr/share/cups/doc: fichiers de documentation, annulés par la directive DocumentRoot danscupsd.conf./var/cache/cups: fichiers en mémoire cache tels que ppds.dat et remote.cache, annulés par la directive CacheDir danscupsd.conf./var/log/cups:access_log,error_log, etpage_log, surpassé par les directives AccessLog, ErrorLog, PageLog danscupsd.conf./var/run/cups: fichier d'interface de domaine et données d'état tel que les certificats d'authentification, annulés par la directive StateDir danscupsd.conf./var/spool/cups: tâches d'impression mises dans la file d'attente, annulées par la directive RequestRoot danscupsd.conf.
Vous pouvez configurer CUPS avec les fichiers de configuration ou l'interface Web. Nous recommandons l'interface Web pour les configurations de base et la gestion des imprimantes (ajout, modification, suppression) et l'édition des fichiers de configuration pour les tâches avancées, principalement pour la sécurité.
Vous pouvez accéder à l'interface Web par HTTPS sur le port 631 : https://<cups_server:631.
L'onglet Jobs permet de gérer les tâches d'impression. Le bouton administration vous offrira une interface Web pour ajouter, modifier et supprimer des imprimantes. Cliquez simplement sur Add printers (ajouter une imprimante) ou Manage printers (gérer les imprimantes) .
Cupsd
est configuré par défaut pour afficher les imprimantes partagées
par d'autres systèmes et limiter l'accès au système et ses
imprimantes. Les opérations d'administration demandent une
authentification de base pour un membre du groupe
sys. Les connections sont acceptées via
(/var/run/cups/cups.sock) ou "localhost"
(127.0.0.1). Les usagers n'ont pas les droits pour annuler des
tâches qui ne leur appartiennent pas.
Vous pouvez changer ces paramètres dans l'onglet Administration dans la section Server : cochez les options que vous voulez.
La section serveur vous donne également accès aux fichiers de journalisation :
Ajoutons une nouvelle imprimante. CUPS 1.2 permet la détection automatique. Si les imprimantes sont activées et branchées sur le réseau, CUPS devrait les détecter, et la liste New Printers Found apparaîtra. Cliquez sur Add this printer et remplissez les champs avec les informations relative à cette imprimante.
![[Astuce]](images/tip.png) |
Astuce |
|---|---|
|
Votre imprimante n'est peut-être pas détectée par CUPS parce que le fichier PPD n'est pas dans la liste.
Cette procédure n'est pas infaillible puisque certain fichiers PPD ne sont pas complétés adéquatement. Consultez http://linuxprinting.org pour vérifier la compatibilité de votre équipement. |
Une fois que vos imprimantes sont ajoutées, vous pouvez modifier leur configuration. Cliquez sur Printers. Choisissez l'imprimante en cliquant sur celle que vous désirez modifier. Vous verrez alors ce qui suit :
Print Test Page : Imprimer une page test pour l'imprimante configurée.
Reject Jobs : l'imprimante ne sera pas arrêtée, mais elle n'acceptera pas de tâches.
Move all Jobs : déplacer toutes les tâches vers une nouvelle imprimante.
Cancel all Jobs : annuler toutes les tâches pour cette imprimante.
Modify Printer : modifier la configuration de l'imprimante, accès URI, pilotes, etc.
Set Printer Options : modifier les options d'impression tel que la résolution, taille de la page, bannière, etc.
Set as Default : définir en tant qu'imprimante par défaut pour les usagers.
Set allowed Users : afficher les usagers qui peuvent utiliser ou non cette imprimante.
Vous trouverez les fichiers
de configuration dans /etc/cups. Le fichier
/etc/cups/client.conf permet d'établir les
accès clients. /etc/cups/cupsd.conf permet
de définir la configuration du serveur CUPS.
Le
/etc/cups/cupsd.conf contient les directives
de configuration contrôlant le fonctionnement du serveur. Chaque
directive est affichée sur une ligne et est suivie de sa
valeur. Les commentaires sont introduit avec le dièse
(« # ») au début de la ligne.
La syntaxe générale de
cupsd.conf est comparable à celle de
Apache. Vous pouvez spécifier des
paramètres généraux en utilisant <directive>
<parametre>.
Voyons les principales options de configuration :
- AuthType
-
La directive AuthType définie le type d'authentification à utiliser :
Basic : l'authentification de base (Basic) sera appliquée en utilisant le mot de passe et les fichiers de groupe de UNIX®
Digest : Le mode d'authentification Digest sera utilisé avec le fichier
/etc/cups/passwd.md5BasicDigest : L'authentification de base sera appliquée en utilisant
/etc/cups/passwd.md5
Lors de l'utilisation de mode d'authentification Basic, Digest, or BasicDigest, les clients se branchant par l'interface localhost peuvent également s'authentifier avec un certificat. La directive AuthType doit apparaître dans la section Location ou Limit.
- BrowseAddress
-
La directive BrowseAddress spécifie une adresse où envoyer l'information de consultation. Plusieurs directives BrowseAddress peuvent être spécifiées pour l'envoi d'information à plusieurs réseaux ou systèmes.
Le nom @LOCAL va envoyer les informations d'impression à toutes les interfaces locales. Le nom @IF(name) va envoyer les informations seulement à l'interface identifiée.
- BrowseAllow
-
La directive BrowseAllow spécifie un système ou un réseau pour accepter les requêtes d'information. Le défaut est d'accepter les requêtes de tous les clients. Afin de valider sur les hôtes et les domaines, vous devez activer la directive HostNameLookups.
La validation des adresses IP supporte des concordances exactes, partielles qui correspondent à des réseaux en utilisant le masque réseau de 255.0.0.0, 255.255.0.0 et 255.255.255.0 ou des adresses réseau utilisant le masque réseau spécifié ou un compte des bits. @LOCAL name permet la consultation à partir de toutes les interfaces locales. @IF(name) ne permettra la consultation qu'à partir des interfaces identifiées.
Vous pouvez également avoir recours à la directive BrowseDeny pour interdire les requêtes. Son comportement est identique à BrowseAllow.
- Browsing
Cette directive détermine si la consultation des imprimantes réseau est permise. Le valeur par défaut est On (activé). Cette directive n'active pas le partage d'une imprimante locale, vous devez également utiliser la directive BrowseAddress ou BrowseProtocols pour annoncer les imprimantes locales aux autres systèmes.
- DefaultShared
Cette directive spécifie si les imprimantes sont partagées (publiées) par défaut. La valeur par défaut est yes (oui).
- JobRetryInterval
JobRetryInterval indique le nombre de secondes à attendre entre les tentatives pour réessayer une tâche. Habituellement utilisée pour les fax, elle peut également être utilisée avec les imprimantes normales dont la politique d'erreur est
retry-job. La valeur pat défaut est 30 secondes.
CUPS vous permet d'établir les droits d'accès au serveur :
<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From @LOCAL
</Location>
Dans cet exemple, nous permettons aux usagers d'accéder à l'interface Web de CUPS à partir de localhost et lorsqu'ils sont dans le même réseau. Avec cette méthode, vous pouvez configurer les droits d'administration.
- Location
-
La directive Location spécifie le contrôle d'accès et les options d'authentification pour les ressources HTTP ou le chemin spécifié. Les directives Allow, AuthType, Deny, Encryption, Limit, LimitExcept, Order, Require, et Satisfy peuvent toutes apparaître dans une location.
Voici des locations communes dans le serveur CUPS :
/ : le chemin pour toutes les opérations de get (get-printers, get-jobs, etc.)
/admin: le chemin pour toutes les opérations d'administration (add-printer, delete-printer, start-printer, etc.)
/admin/conf : le chemin pour accéder aux fichiers de configuration de CUPS (cupsd.conf, client.conf, etc.)
/admin/log : chemin pour accéder aux logs (access_log, error_log, page_log)
/jobs : chemin pour toutes les tâches (hold-job, release-job, etc.)
- Allow
-
<Location /path> ... Allow from All Allow from None Allow from *.domain.com Allow from .domain.com Allow from host.domain.com Allow from nnn.* Allow from nnn.nnn.* Allow from nnn.nnn.nnn.* Allow from nnn.nnn.nnn.nnn Allow from nnn.nnn.nnn.nnn/mm Allow from nnn.nnn.nnn.nnn/mmm.mmm.mmm.mmm Allow from xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx Allow from @LOCAL Allow from @IF(name) </Location>
La directive Allow spécifie un nom d'hôte, une adresse IP, ou un réseau qui peut accéder au serveur. Les directives Allow sont cumulatives, donc plusieurs Allow peuvent être utilisées pour permettre l'accès à plusieurs hôtes ou réseaux. La notation /mm précise un masque de sous-réseau CIDR.
Le nom @LOCAL permettra l'accès à toutes les interfaces locales. Le nom @IF(name) limitera l'accès à l'interface nommée.
Dans la configuration autonome par défaut, il y a peu de risques de sécurité - le serveur CUPS n'accepte pas les connexions distantes, et accepte seulement les informations partagées à partir de son sous-réseau local. Lorsque vous partagez une imprimante ou activez l'administration distante, vous exposez potentiellement votre système à des accès non autorisés. Cette page fournit une analyse des problèmes potentiels de sécurité avec CUPS et décrit des stratégies pour améliorer la sécurité de votre serveur.
- Enjeux de l'authentification
-
Lorsque vous activez l'administration distante, le serveur utilisera l'authentification de base pour les tâches d'administration. Le serveur CUPS supporte l'authentification en mode Basic, Digest et Local Certificate :
-
L'authentification en mode de base (Basic) envoie les noms d'usagers et mots de passe de manière lisible sur le réseau. Comme CUPS a recours au nom d'usager et mot de passe du système, ces informations peuvent donc être lues, puis utilisées pour accéder au serveur et possiblement accéder à des comptes privilégiés.
Il est donc recommandé d'activer le chiffrement pour cacher le nom d'usager et le mot de passe - c'est l'option par défaut sur MacOS X et sur les systèmes GNU lorsque TLS ou OpenSSL sont installés.
-
L'authentification Digest utilise le MD5 checksum du nom d'usager, mot de passe et du domaine de CUPS, afin que le nom d'usager et mot de passe original ne soient pas envoyés sur le réseau. L'implémentation courante n'authentifie pas le message en entier et utilise l'adresse IP pour la valeur nonce, ce qui permet de lancer une attaque man in the middle et de rejouer des attaques à partir de ce client.
Vous devriez activer le chiffrement pour cacher l'information nom d'usager et mot de passe.
-
L'authentification par certificat local (local certificate authentication) envoie un certificat 128-bit permettant d'identifier un usager authentifié. Les certificats sont créés à la volée au hasard et conservés dans des fichiers sous
/var/run/cups/certs. Ils ont des restrictions de lecture :root + system-group(s)pour les certificats root etlp + lppour les certificats CGI. Comme les certificats ne sont disponibles que sur le système local, le serveur CUPS n'accepte pas d'authentification local si le client n'est pas connecté à l'interface loopback (127.0.0.1) ou à l'interface de connexion de domaine (domain socket).Assurez-vous que seuls les usagers autorisés fassent partie du(des) groupe(s) système.
-
- Attaque de déni de service
-
Lorsque le partage d'imprimante ou l'administration distante est activée, le serveur CUPS, comme tous les services Internet, est vulnérable face aux multiples attaques par déni de service possibles :
-
Établir de multiples connexions au serveur jusqu'à ce que le serveur ne puisse plus répondre.
Aucun logiciel ne permet de protéger votre serveur contre ce genre d'attaque. La directive MaxClientsPerHost peut être utilisée pour configurer CUPS afin qu'il limite le nombre de connexions permises à un même client, ce qui ne prévient pas une attaque distribuée.
Vous devriez limiter l'accès aux clients et réseaux de confiance.
-
À répétition, ouvrir et fermer une connexion au serveur le plus vite possible.
Il n'y a pas de façon facile de se protéger contre ceci dans CUPS. Si l'attaque origine de l'extérieur du réseau, vous pourriez filtrer ce genre d'attaque. Cela dit, dès que le serveur reçoit une requête, il doit au moins l'ouvrir pour identifier son origine.
-
Submerger le réseau avec des paquets de diffusion sur le port 631.
Il est possible de désactiver la consultation si CUPS détecte cette condition. Par contre, si vous avez plusieurs imprimantes sur votre réseau, ce genre de règles peu conclure qu'une attaque est en cours alors qu'une requête valide est reçue.
Vous devriez bloquer les paquets de diffusion des réseaux étranges avec votre routeur ou votre pare-feu.
-
Envoi de requêtes IPP partielles, plus précisément, envoyer une partie d'attribut puis arrêter la transmission.
La code actuel va attendre jusqu'à une seconde avant de faire expirer la valeur partielle envoyée et fermer la connexion. Ce qui va ralentir le temps de réponse du serveur pour les requêtes valides et peut même engendrer des pertes de paquets de diffusion, mais n'aura pas d'autre impact significatif sur les opérations du serveur.
Vous devriez bloquer les paquets IPP en provenance de réseau distant ou non autorisé avec votre routeur ou votre pare-feu.
-
L'envoi de gros/longs fichiers à l'imprimante, empêchant les autres usagers d'imprimer.
Il y a peu de moyen de contrôler la taille des fichiers envoyés à l'impression, seulement l'attribut MaxRequestSize. Cependant, celui-ci ne vous protégera pas contre les usagers abusifs et l'impression de centaines, voir de milliers de pages.
Vous devriez restreindre l'accès aux hôtes ou réseaux connus, et ajouter un contrôle d'accès au niveau usager tels que requis pour les imprimantes haut de gamme.
-
- Enjeux du chiffrement
-
CUPS supporte le chiffrement SSL 3.0 128-bit et TLS 1.0 des connexions réseau avec OpenSSL, GNU TLS et la bibliothèque de chiffrement CDSA. Au delà des problèmes des protocoles TLS ou de SSL, CUPS a présentement les problèmes suivants :
Validation/révocation de certificat : actuellement, CUPS ne valide pas et ne révoque pas les certificats client ou serveur au moment d'établir une connexion sécurisée. Cette situation peu permettre une attaque man in the middle ou des attaques basées sur le vol d'identité sur des réseaux non sécurisés. Les prochaines versions de CUPS vont supporter la validation et la révocation de certificats.
Ne vous fiez pas au chiffrement pour la sécurité lorsque vous vous branchez sur un serveur par Internet ou sur un réseau non sécurisé.
CUPS 1.2 permet de
consulter les imprimantes dans un répertoire LDAP afin de les
ajouter comme nouvelle imprimante. Comme plusieurs autres services,
vous devrez indiquer à CUPS comment accéder au répertoire
LDAP, dans /etc/cups/cupsd.conf :
- BrowseLDAPBindDN
La directive BrowseLDAPBindDN spécifie le domaine LDAP à utiliser au moment d'écouter l'enregistrement d'une imprimante. La valeur par défaut n'est pas définie (undefined).
- BrowseLDAPDN
La directive BrowseLDAPDN établit le nom de domaine LDAP à utiliser lors de l'enregistrement d'une imprimante partagée. La valeur par défaut n'est pas définie.
- BrowseLDAPPassword
Cette directive spécifie le mot de passe pour accéder au serveur LDAP. Par défaut, elle n'est pas définie.
- BrowseLDAPServer
Cette directive indique le nom du serveur LDAP sur lequel se brancher. Par défaut, elle n'est pas définie.
BrowseLocalProtocols ldap
BrowseRemoteProtocols ldap
BrowseLDAPServer localhost
BrowseLDAPDN ou=printers,dc=example,dc=com
BrowseLDAPBindDN uid=Manager,dc=example,dc=com
BrowseLDAPPassword password
NFS permet d'exporter des répertoires complets, voire un système de fichiers, à travers le réseau, permettant ainsi le partage de fichiers entre utilisateurs. Ce type de partage est simple à mettre en place et est utilisé essentiellement avec les systèmes GNU/Linux et UNIX®. NFS n'est pas recommandé si vous avez de fortes contraintes de sécurité. L'utilisation de NFS est de toute façon à limiter à un réseau local.
La configuration des
exportations de systèmes de fichiers NFS se fait dans le fichier
/etc/exports. Il vous permet d'établir le
mode d'accès aux données, les droits accordés aux utilisateurs et
aux machines. Il est impératif de veiller à l'assignation de ces
droits pour sécuriser l'accès aux données.
Pour présenter la configuration, nous utiliserons le module Webmin prévu à cet effet. Il est accessible dans la section Réseau puis dans le module Partages NFS.
Pour ajouter un nouveau partage, cliquez sur le lien Ajouter un nouveau partage. La fenêtre est divisée en deux sections. La première partie présente les options générales du partage. Pour des raisons de compatibilité, vous pouvez choisir NFS Version 3. Spécifiez ensuite le répertoire à exporter et à quel endroit vous souhaitez l'exporter. Vous pouvez également limiter l'accès du partage à des machines données ou des sous-réseaux. Par défaut, le partage est accessible à tous.
La section Sécurité de l'export vous permet de préciser le paramétrage de la sécurité. Vous pouvez, par exemple, choisir les UIDs et GID de confiance, le type d'accès (écriture et/ou lecture), etc.
Une fois le paramétrage terminé, sauvegardez en cliquant sur le bouton . Le nouveau partage apparaît alors dans la liste. Vous pouvez alors ajouter de nouveaux exports ou modifier les exports existants en cliquant sur le lien correspondant. Ensuite, n'oubliez pas de cliquer sur le bouton pour appliquer les modifications et mettre à disposition les nouveaux partages.
Mandriva Corporate Server 4 propose un serveur de type NFS v4. Cette nouvelle version apporte de fortes améliorations concernant la sécurité et les fonctionnalités :
Ajout des états sur les fichiers concernant les verrouillages, la lecture et l'écriture, entre le client et le serveur.
Base de baux pour le verrouillage des fichiers, permettant au client de récupérer la propriété du fichier pendant le temps du bail. Le client doit contacter le serveur pour éventuellement en étendre la durée.
Ajout de composants de sécurité tels que Kerberos 5 et SPKM3.
Extension du support des ACL fichiers, ajoutant notamment les noms de groupes et utilisateurs permettant ce type d'accès direct.
Combinaison de plusieurs protocoles NFS permettant une meilleure gestion par les pare-feu.
La capacité pour les clients de maintenir des sessions ou de les récupérer malgré un crash serveur ou une panne du réseau.
Gestion d'un pseudo système de fichiers permettant de gérer tous les exports NFS à partir d'une même racine.
Voici une procédure vous permettant de mettre en oeuvre l'arborescence des exports NFS, avec la mise en place de Kerberos 5. Les pré-requis à cette configuration sont de disposer des paquetages NFS installés et d'un serveur Kerberos opérationnel.
-
Déclarer le pseudo système de fichiers dans
/etc/fstabIl vous suffit d'ajouter les deux lignes suivantes :
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs defaults 0 0 nfsd /proc/fs/nfsd nfsd defaults 0 0Puis, comme pour un système de fichiers classique, montez-le :
# mount rpc_pipesfs
-
Créer la racine de l'arborescence d'exports
NFSv4 mettant à votre disposition un nouveau pseudo système de fichiers, tous les exports sont positionnés à partir d'une arborescence racine :
/exports/ |-- test1 |-- ... `-- testnPour la créer, il suffit de spécifier le paramètre fsid=0 :
# cat /etc/exports /export *(rw,fsid=0,insecure,no_subtree_check,5)
-
Créer l'arborescence d'export
La suite de l'arborescence est alors plus classique :
# cat /etc/exports /export *(rw,fsid=0,insecure,no_subtree_check) /export/test1 *(rw,nohide,insecure,no_subtree_check) ...Le montage de la ressource se fait en relation à la racine NFS :
# mount nfs4srv:/test1 /mnt/nfs
-
Utilisation de Kerberos
Créez, dans un premier temps, un principal pour NFS. Créez également une clé pour le serveur et le client en utilisant le shell kadmin :
kadmin.local: addprinc -randkey nfs/nfs4srv.edge-it.subnet WARNING: no policy specified for nfs/nfs4srv.example.com@EXAMPLE.COM; defaulting to no policy Principal "nfs/nfs4srv.example.com@EXAMPLE.COM" created. kadmin.local: ktadd -e des-cbc-crc:normal nfs/nfs4srv.example.com Entry for principal nfs/nfs4srv.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal nfsnfs4srv.example.com with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.Copier le fichier krb5.keytab sur le serveur NFS et les clients utilisant NFSv4.
Il reste alors à créer les exports utilisant krb5, au moyen d'un client spécifique, gss/krb5.
# cat /etc/exports /export gss/krb5(rw,fsid=0,insecure,no_subtree_check,sync,5)
Utilisez la commande mount avec l'option sec=kbr5 :
# mount -t nfs4 -o sec=krb5 nfs4srv:/ /nnt/nfs
ProFTPD vous permet de créer et configurer un serveur FTP. Vous pouvez le configurer grâce au module Webmin dédié à cet effet, dans la catégorie Serveurs.
Il y a deux paquetages pour proftpd :
Pour des raisons de sécurité, nous n'installerons que le premier paquetage.
# urpmi proftpd
L'arborescence fournie par proftpd est relativement simple :
Pour vérifier la syntaxe du fichier de configuration :
# proftpd -t
Checking syntax of configuration file
Syntax check complete.
Pour vérifier le bon fonctionnement du serveur :
# service proftpd status
proftpd (pid 32445) est en cours d'exécution ...
# telnet 192.168.40.52 21
Trying 192.168.40.52...
Connected to tellure.edge-it.subnet (192.168.40.52).
Escape character is '^]'.
220 ProFTPD 1.2.10 Server (ProFTPD Default Installation)
[192.168.40.52]
On testera également une session complète en se connectant au serveur.
Le paquet proftpd installe, outre le
démon serveur, un certain nombre de commandes qui peuvent s'avérer
utiles pour suivre l'état du serveur.
- ftpcount
-
Permet de compter le nombre de connexions au serveur ftp à un moment donné
$ ftpcount Master proftpd process 32445: Service class - 1 user
- ftptop
-
Permet de visualiser en temps réel l'activité du serveur ftp et de ses connexions
ftptop/0.9: Thu Jan 5 11:54:49 2006, up for 1 min 1 Total FTP Sessions: 0 downloading, 0 uploading, 1 idle PID S USER CLIENT SERVER TIME COMMAND 32455 I anne test.domain.subne 0.0.0.0:21 0m47s idle
- ftpwho
-
Permet de visualiser à un moment donné les connexions actives au serveur et des informations concernant les sessions en cours.
$ ftpwho -v standalone FTP daemon [32445], up for 2 hrs 18 min 542 anne [ 0m11s] 0m11s idle client: bidule.edge-it.subnet [192.168.40.140] server: 0.0.0.0:21 (ProFTPD Default Installation) location: / Service class - 1 user
La sécurisation d'un serveur FTP passe en amont par la mise en place d'un coupe feu efficace. Hormis ce point, la sécurisation passe avant tout par la gestion des utilisateurs et la personnalisation de la configuration.
Ci-dessous un fichier de configuration type, que nous allons détailler par la suite :
# cat /etc/proftpd.conf
ServerName "FTP SERVER"
ServerType standalone
DeferWelcome off
TransferLog /var/log/proftpd.xferlog
DefaultRoot ~
RequireValidShell off
ServerIdent off
RootLogin off
ShowSymlinks off
DefaultServer on
AllowOverwrite off
TimeoutNoTransfer 600
TimeoutStalled 600
TimeoutIdle 1200
DisplayLogin /etc/welcome.msg
DisplayFirstChdir .message
DenyFilter \*.*/
Bind 192.168.10.55
Une grande partie de la sécurisation d'un serveur FTP est liée à la gestion des utilisateurs, d'où des étapes indispensables.
- Utilisateurs sans shell
-
Il est préférable de dédier les accès ftp à des utilisateurs sans shell qui seront créés de la manière suivante :
# useradd -s /bin/false user
# usermod -s /bin/false user
Pour autoriser l'accès au ftp pour des utilisateurs sans shell, on ajoute dans
/etc/proftpd.conf:RequireValidShell on
- Sessions utilisateurs en mode chroot
-
On emprisonne les utilisateurs dans un répertoire fixé, l'empêchant ainsi de remonter dans l'arborescence. Pour ce faire, on ajoute la ligne suivante dans
/etc/proftpd.conf:DefaultRoot ~
- Interdire l'accès du serveur ftp à root
-
Comme les mots de passe circulent en texte, on court le risque de voir le mot de passe de root récupéré. Pour ce faire, on ajoute la ligne suivante dans
/etc/proftpd.conf:RootLogin off
- Interdire les connexions anonymes
C'est chose faite par défaut car la mise en place de cette fonctionnalité demande l'installation d'un paquetage supplémentaire (proftpd-anonymous).
- Limiter les connexions à une liste donnée d'utilisateurs
-
La directive Limit permet de spécifier des utilisateurs et/ou des groupes autorisés ou non à se connecter.
<Limit LOGIN> AllowUser bidule AllowGroups devels DenyAll </Limit>
Tous les points mentionnés ci-dessous sont relatifs à des
modifications du fichier
/etc/proftpd.conf.
- Masquer la bannière
-
Il s'agit de ne pas afficher les informations concernant le type de serveur ftp et sa version.
ServerIdent off
# telnet 192.168.40.52 21 Trying 192.168.40.52... Connected to tellure.edge-it.subnet (192.168.40.52). Escape character is '^]'. 220 192.168.40.52 FTP server ready
- Modifier le port d'accès par défaut
Définir un port au-dessus du port 1024 (accessible à un utilisateur non root). On peut éventuellement prévoir une règle iptables pour rendre transparente la manipulation.
- Modifier les messages par défaut
-
Le serveur proftpd renvoie un certain nombre de messages lors des différentes étapes d'une session ftp. Certains d'entre eux peuvent être modifiés pour communiquer avec l'utilisateur (rappel de règles de sécurité, droits et devoirs...) ou pour masquer des messages qui pourraient mettre en évidence un type de serveur et une version.
Voici la liste des directives correspondant à ces messages :
DisplayConnect <fichier> : message affiché avant la procédure d'authentification
DisplayFirstChdir <fichier> : message affiché lors du premier changement de répertoire
DisplayGoAway <filename> : message affiché lors d'une connexion rejetée
DisplayQuit <filename> : message affiché en fin de session ftp
ServerName <texte> : chaîne affichée lors des messages de login
À ces directives, on peut ajouter DeferWelcome qui, lorsqu'il est activé, n'affiche le message de bienvenue que lorsque l'utilisateur est authentifié avec succès.
- Établir des timeouts
-
Ils permettent d'éviter de maintenir ouvertes des connexions non utilisées. Il existe un certain nombre de niveaux sur lesquels on peut fixer des timeouts :
TimeoutNoTransfer <seconds> : nombre maximum de secondes pendant lesquelles un client authentifié peut rester connecté inactif, (par défaut : 300)
TimeoutStalled <seconds> : nombre maximum de secondes pendant lesquelles une connexion ftp peut rester dans l'état stalled (par défaut : 3600)
TimeoutIdle <seconds> : nombre maximum de secondes pendant lesquelles une connexion FTP peut rester dans l'état inactif (idle) (par défaut : 600).
- Contrôle des commandes passées par l'utilisateur
-
La directive Limit permet de lister précisément les commandes autorisées pour les utilisateurs du serveur ftp. Ces commandes peuvent être spécifiées une par une ou par une désignation de groupe de commandes.
READ All FTP : commandes concernant la lecture de fichiers (ne concerne pas le listage d'un répertoire) : RETR, SITE, SIZE, STAT
WRITE All FTP : commandes concernant l'écriture, la création et la suppression d'un répertoire APPE, DELE, MKD, RMD, RNTO, STOR, XMKD, XRMD
DIRS All FTP : commandes concernant l'affichage des fichiers des répertoires CDUP, CWD, LIST, MDTM, NLST, PWD, RNFR, XCUP, XCWD, XPWD
Limiter les utilisateurs dans leurs commandes en leur retirant tous les droits de suppression de fichiers et de répertoires dans le dépôt ftp
<Limit RNFR DELE RMD> DenyAll </Limit>
- Gestion des interfaces réseau
-
Dans le cas où la machine dispose de plusieurs interfaces et/ou de plusieurs adresses IP, il est conseillé de lier le serveur à une adresse unique.
Bind 192.168.10.55
- Correction d'une faille de sécurité de ftp
-
La ligne ci-dessous permet de contrer une faille provoquée par la commande NLST /../*/../*/../*/../*/../*/../*/../*/../*/../*/../.
DenyFilter \*.*/
Proftpd donne la possibilité de préciser la configuration du serveur en fonction de contextes bien définis :
Prenons le cas de répertoires. Le dépôt ftp est situé dans
/var/lib/ftp :
La configuration correspondante serait :
<Directory /var/lib/ftp/datas>
<Limit WRITE DIRS>
DenyGroup visiteurs
AllowGroup devels
</Limit>
</Directory>
<Directory /var/lib/ftp/pub>
<Limit ALL>
AllowGroup visiteurs devels
</Limit>
</Directory>
Proftpd dispose, par défaut, d'un module permettant d'authentifier les utilisateurs du serveur ftp à partir d'un annuaire OpenLDAP.
La configuration est relativement simple. Nous partirons de la configuration suivante :
LDAPServer <adresse_ip_serveur_ldap> LDAPDNInfo
"cn=Manager,dc=example,dc=com" "<password>" LDAPQueryTimeout 5
LDAPDoAuth on "dc=example,dc=com" LDAPDoUIDLookups on
"ou=Personnes,dc=example,dc=com" LDAPDoGIDLookups on
"ou=Groupes,dc=example,dc=com" LDAPNegativeCache off
LDAPHomedirOnDemand off LDAPDefaultAuthScheme MD5
La configuration s'appuie sur les paramètres spécifiant les données essentielles pour accéder au serveur LDAP et l'interroger :
- LDAPDNInfo
Contient les informations de DN pour le contact initial à l'annuaire
- LDAPQueryTimeout
- LDAPDoAuth
- LDAPDoUIDLookups
Fixe le GID par défaut à assigner aux utilisateurs quand l'attribut uidNumber n'est pas trouvé.
- LDAPDoGIDLookups
Autorise la résolution LDAP pour les droits de groupe et GID pour la lecture des répertoires.
- LDAPHomedirOnDemand
Force tous les utilisateurs authentifiés par LDAP à utiliser par défaut HomeDironDemand.
- LDAPDefaultAuthScheme
Fixe le hash d'authentification à utiliser lorsque {hashname} n'est pas spécifié.
Ce document a pour but de présenter l'installation d'un serveur Samba (contrôleur principal de domaine, authentification et autorisations, serveur de fichiers et d'impression) basé sur un annuaire LDAP pour la gestion des utilisateurs. Il décrit la méthode d'installation, les éléments spécifiques aux besoins du service ainsi que la configuration mise en oeuvre. On trouvera aussi une notice explicative des outils de base pour tester le service et ajouter les premiers utilisateurs.
Annoncé en janvier 1992, par Andrew Tridgell, étudiant au laboratoire d'informatique à l'Université nationale d'Australie, nbserver ne devait uniquement permettre que de monter des partages Microsoft Windows sur une machine Unix. Devenu un ensemble complet d'outils pour assurer la gestion des ressources réseau en milieu hétérogène, nbserver prend le nom de Samba (1.6.05) en avril 1994 pour évoquer le protocole implémenté. Au fil des versions, il se rapproche du comportement d'un serveur Microsoft NT4 (Contrôle du domaine, gestion de l'authentification aux ressources, partage des ressources, parcours du réseau SMB...). Samba 2.0 sort en janvier 1999, et Samba 3.0, qui permet enfin la gestion des groupes d'utilisateurs Microsoft Windows, en septembre 2003.
Samba 4 annonce la possibilité de mettre en place un serveur de type Active Directory
Samba est une suite logicielle permettant l'interconnexion de différents systèmes autour d'un protocole commun baptisé NetBIOS (Network Basic Input Output System), sur lequel s'appuient SMB (Server Message Block) ou CIFS (Common Internet File System) pour assurer le partage de ressources (fichiers, imprimantes, ports séries et parallèles).
Si le protocole de Microsoft SMB a pour but principal le partage de fichiers, les fonctionnalités sont étendues par :
L'authentification permet notamment la mise en place de domaines de type Microsoft NT4.
À la fin de cette partie, un serveur PDC (Primary Domain Controler, ou Contrôleur Primaire de Domaine) aura été mis en place. Les utilisateurs, groupes et machines seront conservés dans un annuaire LDAP. On considère qu’un annuaire est déjà fonctionnel, et permettra l’ajout des données nécessaires. Mais avant de se lancer dans cette partie, il est impératif d’installer les paquetages Samba et de tester une configuration simple.
samba-server : contient les démons smbd (authentification et gestion de l’accès aux partages) et nmbd (dialogue)
réseau : résolution de nom, gestion des rôles. C’est la base d’un service de type Serveur Microsoft NT4.
samba-client : contient les clients qui permettent d’accéder à des ressources SMB/CIFS distantes (nécessite mount-cifs, pour monter un système de fichiers distant de type CIFS).
samba-winbind : permet à des logiciels tiers (PAM, serveur Samba membre du domaine, Squid, apache,...) de s’authentifier sur un serveur de domaine (Samba ou Microsoft Windows). Une telle architecture peut nécessiter nss_wins (pour PAM).
samba-smbldap-tools : ce paquetage au nom trompeur ne contient pas l’ensemble des
smbldap-tools, mais juste le script/usr/share/samba/scripts/migrate-smbldapsamba-vscan-* : l’ensemble des VFS permettant le scan anti-virus à la volée (nécessite un serveur configuré).
smbldap-tools: ce paquetage contient l’ensemble des scripts
smbldap-tools, qui facilitent la manipulation des données (utilisateurs, groupes, machines) dans le cadre d’un serveur Samba authentifié sur un annuaire LDAP.
Passons en revue l'arborescence Samba :
/etc/samba: contient l'ensemble des fichiers de configuration du serveur, essentiellement
samba.confpour la configuration générale et la configuration des partages, etsmb-winbind.confpour la configuration de Winbind.-
/usr/lib/samba/vfs -
Ce répertoire liste l'ensemble des modules VFS (Virtual File System) disponibles sur votre serveur. Dans la version actuelle, vous disposez de :
audit : outil d'audit permettant une vérification exhaustive des accès au système de fichiers via les partages de données définies.
default_quota : permet d'établir des quotas par défaut pour des utilisateurs et/ou des groupes
extd_audit : identique à audit mais avec une conservation différente des logs
netatalk : permet de gérer une compatibilité Apple sur les partages de ressources.
vscan : permet de brancher un anti-virus pour effectuer des scans à la volée sur un ou plusieurs partages.
Vous trouverez plus d'information dans la documentation officielle : les VFS modules dans un serveur Samba.
/var/cache/sambaCe répertoire contient l'ensemble des mémoires caches dans des fichiers au format *.tdb. Ils contiennent des informations telles que le parcours des ressources, les noms Netbios, les logins... Ces fichiers peuvent être à l'origine de dysfonctionnements lorsque, par exemple, la mémoire cache demeure inchangée alors que des modifications sont intervenues.
/var/log/sambaVous trouverez ici l'ensemble des logs du serveur Samba. Attention ce répertoire peut rapidement atteindre une taille gigantesque, particulièrement si vous travaillez sur un réseau comportant un nombre important de machines.
![[Note]](images/note.png) |
Note |
|---|---|
Il est à préciser que dans
la phase de test, il est préférable de redémarrer Samba
complètement après chaque modification du fichier
|
Voici la liste des éléments à définir pour démarrer :
- Nom du groupe de travail
-
En mode autonome, il est nécessaire de définir le nom du groupe de travail auquel appartient le serveur. Il s’agit juste d’une information arbitraire mais obligatoire pour regrouper différentes machines dans un même groupe virtuel.
Cette information est donnée par l’attribut workgroup. C’est aussi cette option qui nous permettra de spécifier le nom du domaine à contrôler lorsque notre serveur deviendra un PDC. Pour cette documentation, le groupe de travail aura pour nom example.
# cat /etc/samba/smb.conf [global] ... workgroup = example ... - Nom NetBIOS de la machine
-
Il est possible de donner un nom NetBIOS à la machine qui sera différent du nom affecté dans le DNS, cela se gère via l’attribut netbios name :
# cat /etc/samba/smb.conf [global] ... netbios name = CS4 ... - Commentaire sur la machine
-
De même, on pourra associer un commentaire afin d’identifier plus clairement la machine :
# cat /etc/samba/smb.conf [global] ... server string = Samba Server %v ...
![[Avertissement]](images/warning.png)
C’est le moyen le plus simple et le plus rapide de tester les paquetages installés. Pas de notion de domaine, juste un serveur avec quelques utilisateurs qui peuvent se connecter sur un partage personnel ([homes]), et un partage public, ouvert à tous (même les anonymes). Ce simple test nous permet de valider que les paquetages sont opérationnels et que l’authentification fonctionne.
Utilisons le fichier
/etc/samba/smb.conf suivant :
# cat /etc/samba/smb.conf
[global]
workgroup = example
server string = Samba Server %v
map to guest = Bad User
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
[homes]
#l'utilisation du bloc [homes] correspond à une définition par défaut des répertoires personnels des utilisateurs
; le path par défaut sera donc ///home/nomDuUser//
# on pourrait rajouter les attributs suivants pour agrémenter la définition du partage
; comment = Home Directories
; browseable = no
# et les utilisateurs peuvent y créer/modifier/supprimer des fichiers/répertoires
read only = no
[public]
# ce partage définit un répertoire publique
path = /home/public
comment = Public Directory
# il n'est pas nécessaire de s'authentifier pour y accéder
guest ok = yes
# et les utilisateurs peuvent y créer/modifier/supprimer des fichiers/répertoires
read only = no
; browseable = no
Vérifions qu’il ne comporte pas d’erreurs :
# testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[public]"
Loaded services file OK.
WARNING: passdb expand explicit = yes is deprecated
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
[global]
workgroup = example
server string = Samba Server %v
map to guest = Bad User
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
[homes]
read only = No
[public]
comment = Public Directory
path = /home/public
read only = No
guest ok = Yes
Pas d’erreurs notables, seul un warning concerne un attribut obsolète qui est défini par défaut.
Le service peut donc être démarré :
# service smb start
Lancement du service Samba : [ OK ]
Lancement du service NMB : [ OK ]
# ps aux
...
root 27843 0.0 0.7 10724 4028 ? Ss 12:43 0:00 smbd -D
root 27844 0.0 0.7 10724 4020 ? S 12:43 0:00 smbd -D
root 27854 0.0 0.4 6568 2068 ? Ss 12:43 0:00 nmbd -D
...
Le service est démarré, il s’agit maintenant de voir s’il répond aux requêtes :
# smbclient -L localhost
Password:
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
Sharename Type Comment
--------- ---- -------
homes Disk
public Disk Public Directory
IPC$ IPC IPC Service (Samba Server 3.0.22)
ADMIN$ IPC IPC Service (Samba Server 3.0.22)
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
Server Comment
--------- -------
Workgroup Master
--------- -------
example
Le service répond
lorsqu’on lui demande de lister les ressources visibles. On
pourra jouer avec l’attribut browseable dans
les partages pour vérifier qu’ils apparaissent ou non. Pour la
suite des tests, le partage [homes] aura
l’attribut browseable = no.
Nous avons défini un partage public, accessible à tous, même sans authentification, il faut donc vérifier qu’il est utilisable dans ce cas :
# mkdir -m 777 /home/public
# ll /home
total 28
...
drwxrwxrwx 2 root root 4096 jui 26 13:03 public/
# smbclient //localhost/public
Password:
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
smb: \> dir
. D 0 Wed Jul 26 13:03:24 2006
.. D 0 Wed Jul 26 13:03:24 2006
48377 blocks of size 16384. 47347 blocks available
smb: \> mkdir test
smb: \> dir
. D 0 Wed Jul 26 13:03:56 2006
.. D 0 Wed Jul 26 13:03:24 2006
test D 0 Wed Jul 26 13:03:56 2006
48377 blocks of size 16384. 47347 blocks available
# ll /home/public/
total 4
drwxr-xr-x 2 nobody nogroup 4096 jui 26 13:03 test/
Créons maintenant un utilisateur sur le système et sur samba :
# useradd -g users -m qatest
# getent passwd qatest
qatest:x:1001:100::/home/qatest:/bin/bash
# ll /home/qatest/ -d
drwxr-xr-x 3 qatest users 4096 jui 26 12:34 /home/qatest//
# passwd qatest
Changing password for user qatest.
New UNIX password:
BAD PASSWORD: it is based on a dictionary word
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
# smbpasswd -a qatest
New SMB password:
Retype new SMB password:
# cat /etc/samba/smbpasswd
qatest:1001:8B28C7EF8A97362BAAD3B435B51404EE:EB407C0BA4F661A80BCF6B8231A0F6F7:[U ]:LCT-44C74D6A:
# ssh qatest@localhost
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
qatest@localhost's password:
[qatest@cs4] $ smbclient -L localhost -U qatest
Password:
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
Sharename Type Comment
--------- ---- -------
public Disk Public Directory
IPC$ IPC IPC Service (Samba Server 3.0.22)
ADMIN$ IPC IPC Service (Samba Server 3.0.22)
qatest Disk Home directory of qatest
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
Server Comment
--------- -------
Workgroup Master
--------- -------
example CS4
On voit ici que le partage [homes] a disparu de la liste (attribut browseable = no en place), mais qu’un partage du nom de l’utilisateur est apparu. En effet, un utilisateur a le droit de voir son propre répertoire, si on utilise la définition standard de [homes].
Connectons-nous à ce partage :
$ smbclient //localhost/qatest -U qatest
Password:
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
smb: \> dir
. D 0 Wed Jul 26 13:14:33 2006
.. D 0 Wed Jul 26 13:03:24 2006
tmp D 0 Wed Jul 26 12:34:36 2006
.screenrc H 3793 Wed Jul 26 12:34:37 2006
.bash_logout H 24 Wed Jul 26 12:34:37 2006
.bash_profile H 191 Wed Jul 26 12:34:37 2006
.bashrc H 124 Wed Jul 26 12:34:37 2006
.bash_completion H 145 Wed Jul 26 12:34:37 2006
.bash_history H 33 Wed Jul 26 13:14:33 2006
48377 blocks of size 16384. 47346 blocks available
smb: \> mkdir test
smb: \> dir
. D 0 Wed Jul 26 13:26:04 2006
.. D 0 Wed Jul 26 13:03:24 2006
tmp D 0 Wed Jul 26 12:34:36 2006
.screenrc H 3793 Wed Jul 26 12:34:37 2006
.bash_logout H 24 Wed Jul 26 12:34:37 2006
.bash_profile H 191 Wed Jul 26 12:34:37 2006
.bashrc H 124 Wed Jul 26 12:34:37 2006
.bash_completion H 145 Wed Jul 26 12:34:37 2006
.bash_history H 72 Wed Jul 26 13:24:36 2006
test D 0 Wed Jul 26 13:26:04 2006
48377 blocks of size 16384. 47346 blocks available
$ ll -a
total 40
drwxr-xr-x 4 qatest users 4096 jui 26 13:26 ./
drwxr-xr-x 6 root root 4096 jui 26 13:03 ../
-rw-r--r-- 1 qatest users 145 jui 26 12:34 .bash_completion
-rw------- 1 qatest users 72 jui 26 13:24 .bash_history
-rw-r--r-- 1 qatest users 24 jui 26 12:34 .bash_logout
-rw-r--r-- 1 qatest users 191 jui 26 12:34 .bash_profile
-rw-r--r-- 1 qatest users 124 jui 26 12:34 .bashrc
-rw-r--r-- 1 qatest users 3793 jui 26 12:34 .screenrc
drwxr-xr-x 2 qatest users 4096 jui 26 13:26 test/
drwx------ 2 qatest users 4096 jui 26 12:34 tmp/
Voyons maintenant le partage public :
$ smbclient //localhost/public -U qatest
Password:
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
smb: \> dir
. D 0 Wed Jul 26 13:03:56 2006
.. D 0 Wed Jul 26 13:03:24 2006
test D 0 Wed Jul 26 13:03:56 2006
48377 blocks of size 16384. 47346 blocks available
smb: \> mkdir qatest
smb: \> dir
. D 0 Wed Jul 26 13:30:35 2006
.. D 0 Wed Jul 26 13:03:24 2006
test D 0 Wed Jul 26 13:03:56 2006
qatest D 0 Wed Jul 26 13:30:35 2006
48377 blocks of size 16384. 47346 blocks available
$ ll /home/public/
total 8
drwxr-xr-x 2 qatest users 4096 jui 26 13:30 qatest/
drwxr-xr-x 2 nobody nogroup 4096 jui 26 13:03 test/
La configuration que nous avons utilisée jusqu’à maintenant va nous servir de base. Nous n’allons que modifier l’authentification. Celle-ci sera désormais basée sur un annuaire LDAP.
Il suffit de se reporter au paragraphe précédent (Section 2.4.2.2, « Configuration du serveur Samba en mode autonome »). On conservera les mêmes pré-requis qu’au paragraphe précédent concernant le nom de domaine, le nom NetBIOS de la machine et le commentaire associé.
# vi /etc/samba/smb.conf
[global]
...
workgroup = example
netbios name = CS4
server string = Samba Server %v
...
Tant que le service n’a pas été démarré au moins une fois, aucun SID n’a été attribué au serveur/domaine. C’est pour cette raison que la récupération de cette information n’est réalisée qu’après le test en mode autonome.
L’information est conservée dans
/etc/samba/secrets.tdb, mais elle n’est pas
lisible directement. On le récupérera avec la commande
net getlocalsid :
# net getlocalsid SID for domain dhcp110 is: S-1-5-21-1518519320-3136826138-1578965553
Rappelons dans un premier temps la liste des SID particuliers reconnus par Windows®. Lors de son installation, Windows® NT4/200x/XP est configuré avec certaines entités (utilisateur, groupe ou alias). Chaque entité a un RID identifié. Ces RID spécifiques doivent être respectés afin de préserver l’intégrité des opérations. Samba doit être alimenté avec ces entités essentielles du domaine.
Tableau 7.1. Entités d'un domaine Windows
D'après ces spécifications, nous déduisons des entités obligatoires et des entités facultatives :
-
entrées obligatoires : s’il n’est pas obligatoire au bon fonctionnement du PDC, l’administrateur du domaine (Domain Administrator/500 - par défaut, seul compte à avoir le contrôle intégral du système) est néanmoins important pour la gestion du domaine. Un utilisateur nobody doit être créé si on souhaite utiliser la directive ldapsam:trusted (pour diminuer le dialogue entre Samba et le sous-système posix).
Concernant les groupes, on créera impérativement : le groupe des Administrateurs du Domaine, le groupe des Utilisateurs du Domaine, le groupe des Invités du Domaine.
entités facultatives : à la vue du tableau, on ajoutera les entités correspondantes, et en particulier le groupe des Machines du Domaine afin d’y rattacher les machines qu’on intégrera dans ce domaine.
Le but de ce chapitre n’est pas d’installer un annuaire. Si certaines manipulations sont décrites ici, elles ne peuvent en aucun cas être considérées comme une recette de mise en oeuvre d’un annuaire LDAP de production. Sur un serveur utilisé pour l’authentification de services tels que ssh/PAM, la messagerie, apache, on trouvera déjà une arborescence.
Il faut créer une
OUpour conserver les comptes de machines, si on ne souhaite pas les mélanger avec les utilisateurs (ou=hosts,dc=example,dc=com).Il faut aussi disposer d’un (ou plusieurs) compte(s) qui aura (auront) le droit d’écrire dans ces
OUs, ainsi que dans lebasednpour ajouter/modifier/supprimer les informations propres à Samba, et les outils complémentaires.
Il est possible de mettre rapidement en place un serveur LDAP avec un script fourni avec la distribution. Il faut installer le paquetage openldap-example-dit. Puis exécuter le script qui génère la configuration avec les données qui seront spécifiées. Ce script crée l’arborescence et les comptes nécessaires à Samba+LDAP, mais aussi à d’autres applications :
# /usr/share/openldap/scripts/example-dit-setup.sh Please enter your DNS domain name [example.com]: exmaple.com Administrator account The administrator account for this directory is uid=LDAP Admin,ou=System Accounts,dc=example,dc=com Please choose a password for this account: New password: Re-enter new password: Summary ======= Domain: example.com LDAP suffix: dc=example,dc=com Administrator: uid=LDAP Admin,ou=System Accounts,dc=example,dc=com Confirm? (Y/n) config file testing succeeded Stopping ldap service Finished, starting ldap service Lancement de /usr/bin/db_recover sous /var/lib/ldap removing /var/lib/ldap/alock Lancement de slapd (ldap + ldaps) : [ OK ] Your previous database directory has been backed up as /var/lib/ldap.1155740637 All files that were backed up got the suffix "1155740637". # ldapsearch -x # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (objectclass=*) # requesting: ALL # # example.com dn: dc=example,dc=com dc: example objectClass: domain objectClass: domainRelatedObject associatedDomain: example.com # People, example.com dn: ou=People,dc=example,dc=com ou: People objectClass: organizationalUnit # Group, example.com dn: ou=Group,dc=example,dc=com ou: Group objectClass: organizationalUnit description: Container for user accounts # System Accounts, example.com dn: ou=System Accounts,dc=example,dc=com ou: System Accounts objectClass: organizationalUnit description: Container for System and Services privileged accounts # System Goups, example.com dn: ou=System Groups,dc=example,dc=com ou: System Groups objectClass: organizationalUnit description: Container for System and Services privileged groups # Hosts, example.com dn: ou=Hosts,dc=example,dc=com ou: Hosts objectClass: organizationalUnit description: Container for Samba machine accounts ... # Account Admin, System Accounts, example.com dn: uid=Account Admin,ou=System Accounts,dc=example,dc=com uid: Account Admin objectClass: account objectClass: simpleSecurityObject description: Account used to administer all users, groups, machines and genera l accounts # nssldap, System Accounts, example.com dn: uid=nssldap,ou=System Accounts,dc=example,dc=com uid: nssldap objectClass: account objectClass: simpleSecurityObject description: Unprivileged account which can be used by nss_ldap for when anony mous searches are disabled ...
On retrouve les OUs dont il est question
pour Samba
(People/Group/Hosts)
ainsi qu’une OU (System Accounts) contenant
les comptes de connexion pour les différents outils de gestion
des comptes (Account Admin, nssldap).
Nous avons vu dans la partie concernant le mode autonome (Section 2.4.2.2.5, « Création et utilisation d'un utilisateur ») qu’il fallait d’abord créer un utilisateur système puis le faire reconnaître par Samba (Création et utilisation d'un utilisateur). Il en va de même pour un PDC dont les utilisateurs sont enregistrés dans un annuaire LDAP.
Pour cela, il faut créer un utilisateur Posix dans l’annuaire LDAP puis ajouter les informations spécifiques à Samba (utilisation des smbldap-tools, par ex), et il faut aussi que le système puisse accéder à cet utilisateur. Il faut donc configurer NSS (Name Service Switch).
# urpmi nss_ldap
Pour que NSS sache qu’il doit consulter un annuaire
LDAP pour trouver des utilisateurs et des
groupes, il faut modifier
/etc/nsswitch.conf :
# /etc/nsswitch.conf # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # ... passwd: files ldap shadow: files group: files ldap ...
Il ne suffit pas d’indiquer à NSS
d’interroger un annuaire LDAP, encore faut-il
préciser lequel, et comment. Pour cela, il faut renseigner
/etc/ldap.conf. Dans ce fichier, on pourra
spécifier un utilisateur (ici uid=nssldap,ou=System
Accounts,dc=example,dc=com) qui se branchera à
l’annuaire LDAP pour lire les informations : ça n’est pas
indispensable, mais peut être utile à des fins de traçage des
requêtes et/ou de mise en place d’ACL
complexes.
# vi /etc/ldap.conf host 127.0.0.1 base dc=example,dc=com # On décommentera les 2 lignes suivantes à des fins de traçage/ACL #binddn uid=nssldap,ou=System Accounts,dc=example,dc=com #bindpw nssldap nss_base_passwd ou=People,dc=example,dc=com?one nss_base_passwd ou=Hosts,dc=example,dc=com?one nss_base_shadow ou=People,dc=example,dc=com?one nss_base_group ou=Group,dc=example,dc=com?one
Il faut maintenant vérifier que le mécanisme fonctionne. Il
faut pour cela disposer d’utilisateurs et de groupes dans
l’annuaire LDAP. Si ce n’est pas déjà le cas,
voici un fichier ldif qu’on peut ajouter le
temps des tests :
# vi /root/test.ldif # Groupe test dn: cn=test,ou=Group,dc=example,dc=com objectClass: top objectClass: posixGroup gidNumber: 200 cn: test # Utilisateur test dn: uid=test,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: test sn: test givenName: test uid: test uidNumber: 1000 gidNumber: 200 homeDirectory: /home/test loginShell: /bin/bash gecos: System User userPassword: test # ldapadd -x -D "uid=LDAP Admin,ou=System Accounts,dc=example,dc=com" -w <passwd> -f test.ldif adding new entry "cn=test,ou=Group,dc=example,dc=com" adding new entry "uid=test,ou=People,dc=example,dc=com"
Vérifions maintenant que le fonctionnement est adéquat avec les commandes suivantes :
# getent passwd test test:x:1000:200:System User:/home/test:/bin/bash # getent group test test:x:200: # id test uid=1000(test) gid=200(test) groupes=200(test)
Il est possible de permettre aux utilisateurs définis dans l’annuaire LDAP de se connecter physiquement à la machine via SSH ou via une mire de login. Pour cela, il faut aussi configurer PAM, et les services en question, cela se fait via le paquetage pam_ldap.
Installons le paquetage pam_ldap.
# urpmi pam_ldap
Il faut ensuite modifier le fichier
/etc/pam.d/system-auth, l’ensemble des
services utilisant PAM pointe
dessus.
# vi /etc/pam.d/system-auth #%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account sufficient pam_unix.so account sufficient pam_ldap.so account required pam_deny.so password required pam_cracklib.so retry=3 minlen=2 dcredit=0 ucredit=0 password sufficient pam_unix.so nullok use_authtok md5 shadow password sufficient pam_ldap.so password required pam_deny.so session required pam_limits.so session required pam_unix.so
Pour vérifier le bon fonctionnement de pam-ldap, il suffit d’essayer de se connecter avec l’utilisateur créé pour vérifier si la configuration est correcte ou non.
# su - test su: AVERTISSEMENT: ne peut changer de répertoire vers /home/test: Aucun fichier ou répertoire de ce type -bash-3.00$ id test uid=1000(test) gid=200(test) groupes=200(test)
Pour le même test avec SSH, il est nécessaire de modifier la configuration de SSH et de le redémarrer.
# vi /etc/ssh/sshd_config ... # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication mechanism. # Depending on your PAM configuration, this may bypass the setting of # PasswordAuthentication, PermitEmptyPasswords, and # "PermitRootLogin without-password". If you just want the PAM account and # session checks to run without PAM authentication, then enable this but set # ChallengeResponseAuthentication=no UsePAM yes ... # service sshd restart Arrêt de sshd : [ OK ] Lancement de sshd : [ OK ] # ssh test@localhost Warning: Permanently added 'localhost' (RSA) to the list of known hosts. Password: Could not chdir to home directory /home/test: No such file or directory /usr/X11R6/bin/xauth: error in locking authority file /home/test/.Xauthority -bash-3.00$ id uid=1000(test) gid=200(test) groupes=200(test)
Le paquetage smbldap-tools fournit un ensemble d’outils pour manipuler les comptes utilisateurs Samba dans l’annuaire LDAP.
# ll /usr/sbin/smbldap-* -rwxr-xr-x 1 root root 5987 mar 21 14:41 /usr/sbin/smbldap-groupadd* -rwxr-xr-x 1 root root 2473 mar 21 14:41 /usr/sbin/smbldap-groupdel* -rwxr-xr-x 1 root root 8881 mar 21 14:41 /usr/sbin/smbldap-groupmod* -rwxr-xr-x 1 root root 2005 mar 21 14:41 /usr/sbin/smbldap-groupshow* -rwxr-xr-x 1 root root 10294 mar 21 14:41 /usr/sbin/smbldap-passwd* -rwxr-xr-x 1 root root 14995 mar 21 14:41 /usr/sbin/smbldap-populate* -rwxr-xr-x 1 root root 20969 mar 21 14:41 /usr/sbin/smbldap-useradd* -rwxr-xr-x 1 root root 3244 mar 21 14:41 /usr/sbin/smbldap-userdel* -rwxr-xr-x 1 root root 7633 mar 21 14:41 /usr/sbin/smbldap-userinfo* -rwxr-xr-x 1 root root 18992 mar 21 14:41 /usr/sbin/smbldap-usermod* -rwxr-xr-x 1 root root 1958 mar 21 14:41 /usr/sbin/smbldap-usershow*
Pour utiliser ces outils, il faut les configurer afin
qu’ils respectent l’organisation que nous avons choisi pour
notre structure. On doit aussi récupérer le
SID du domaine.
Installons le paquetage smbdap-tools
# urpmi smbldap-tools
Pour utiliser ces outils,
il faut préciser le SID, le nom du domaine,
le nom des différentes OU de l’annuaire
LDAP, le ou les annuaires
LDAP à utiliser, ainsi que les attributs
posix et samba par défaut. On
pourra utiliser le fichier minimal suivant (ou reporter
l’équivalent dans le fichier fourni par défaut) :
# vi /etc/smbldap-tools/smbldap.conf
SID="S-1-5-21-2433760973-660784831-1051970529"
sambaDomain="example
slaveLDAP="127.0.0.1"
slavePort="389"
masterLDAP="127.0.0.1"
masterPort="389"
ldapTLS="0"
verify="require"
cafile="/etc/ssl/cacert.pem"
clientcert=""
clientkey=""
suffix="dc=example,dc=com"
usersdn="ou=People,${suffix}"
computersdn="ou=Hosts,${suffix}"
groupsdn="ou=Group,${suffix}"
idmapdn="ou=Idmap,${suffix}"
sambaUnixIdPooldn="sambaDomainName=${sambaDomain},${suffix}"
scope="sub"
hash_encrypt="SSHA"
crypt_salt_format="%s"
userLoginShell="/bin/false"
userHome="/home/%U"
userHomeDirectoryMode="700"
userGecos="smbldap System User"
defaultUserGid="513"
defaultComputerGid="515"
skeletonDir="/etc/skel"
defaultMaxPasswordAge="45"
userSmbHome="\\CS4\%U"
userProfile="\\CS4\profiles\%U"
userHomeDrive="U:"
userScript=""
mailDomain="example.com"
with_smbpasswd="0"
smbpasswd="/usr/bin/smbpasswd"
with_slappasswd="0"
slappasswd="/usr/sbin/slappasswd"
Il faut aussi renseigner le fichier
/etc/smbldap-tools/smbldap_bind.conf :
ce fichier spécifie les comptes qui permettront de se connecter
à l’annuaire LDAP pour effectuer les différentes
manipulations.
# cat /etc/smbldap-tools/smbldap_bind.conf slaveDN="uid=Account Admin,ou=System Accounts,dc=example,dc=com" slavePw="passwd" masterDN="uid=Account Admin,ou=System Accounts,dc=example,dc=com" masterPw="passwd"
Vérifions maintenant le bon fonctionnement des outils :
# smbldap-usershow test dn: uid=test,ou=People,dc=example,dc=com objectClass: top,person,organizationalPerson,inetOrgPerson,posixAccount,shadowAccount cn: test sn: test givenName: test uid: test uidNumber: 1000 gidNumber: 200 homeDirectory: /home/test loginShell: /bin/bash gecos: System User userPassword: test # smbldap-groupshow test dn: cn=test,ou=Group,dc=example,dc=com objectClass: top,posixGroup gidNumber: 200 cn: test
Créons maintenant les utilisateurs et groupes du domaine. Les smbldap-tools fournissent un outil (smbldap-populate) qui crée la base de l’annuaire LDAP avec les utilisateurs et groupes nécessaires au bon fonctionnement de la solution.
Ajoutons les comptes nécessaires à la solution :
# smbldap-populate -a Administrator -k 500 -m 512 Populating LDAP directory for domain example (S-1-5-21-2433760973-660784831-1051970529) (using builtin directory structure) entry dc=example,dc=com already exist. entry ou=People,dc=example,dc=com already exist. entry ou=Group,dc=example,dc=com already exist. entry ou=Hosts,dc=example,dc=com already exist. entry ou=Idmap,dc=example,dc=com already exist. adding new entry: uid=Administrator,ou=People,dc=example,dc=com adding new entry: uid=nobody,ou=People,dc=example,dc=com adding new entry: cn=Domain Admins,ou=Group,dc=example,dc=com adding new entry: cn=Domain Users,ou=Group,dc=example,dc=com adding new entry: cn=Domain Guests,ou=Group,dc=example,dc=com adding new entry: cn=Domain Computers,ou=Group,dc=example,dc=com adding new entry: cn=Administrators,ou=Group,dc=example,dc=com adding new entry: cn=Account Operators,ou=Group,dc=example,dc=com adding new entry: cn=Print Operators,ou=Group,dc=example,dc=com adding new entry: cn=Backup Operators,ou=Group,dc=example,dc=com adding new entry: cn=Replicators,ou=Group,dc=example,dc=com adding new entry: sambaDomainName=example,dc=example,dc=com Please provide a password for the domain Administrator: Changing UNIX and samba passwords for Administrator New password: Retype new password:
La section [global] du fichier
/etc/samba/smb.conf devra contenir les
informations suivantes :
[global]
...
# on peut définir plusieurs types de sources
;passdb backend = ldapsam, smbpasswd, guest
;passdb backend = ldapsam:ldap://myfirstldap.edge-it.fr, ldapsam:ldap://mysecondldap.edge-it.fr, guest
# ici, on travaille avec un annuaire LDAP local
passdb backend = ldapsam:ldap://127.0.0.1
# on se connecte à l'annuaire avec le compte LDAP suivant
ldap admin dn = uid=Account Admin,ou=System Accounts,dc=example.dc=com
# en TLS ou SSL
; ldap ssl = start_tls
ldap ssl = off
# le basedn et les OU où sont conservés les informations
ldap suffix = dc=example.com
ldap machine suffix = ou=hosts
ldap user suffix = ou=people
ldap group suffix = ou=group
# cette option permet de ne pas avoir besoin de configurer PAM
# ce n'est valable que si les utilisateurs Samba n'ont pas a accéder directement à un compte sur la machine.
ldapsam:trusted = yes
La vérification permet de constater qu’il n’y a pas d’erreurs détectées.
# testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[public]"
Loaded services file OK.
WARNING: passdb expand explicit = yes is deprecated
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
[global]
workgroup = EXAMPLE
server string = Samba Server %v
map to guest = Bad User
passdb backend = ldapsam:ldap://127.0.0.1
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
ldap admin dn = uid=Account Admin,ou=System Accounts,dc=example,dc=com
ldap group suffix = ou=group
ldap machine suffix = ou=hosts
ldap suffix = dc=example,dc=com
ldap ssl = no
ldap user suffix = ou=people
ldapsam:trusted = yes
[homes]
read only = No
browseable = No
[public]
comment = Public Directory
path = /home/public
read only = No
guest ok = Yes
Testons la connexion en mode anonyme :
# smbclient -L localhost
Password:
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
Sharename Type Comment
--------- ---- -------
ADMIN$ IPC IPC Service (Samba Server 3.0.22)
IPC$ IPC IPC Service (Samba Server 3.0.22)
public Disk Public Directory
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
Server Comment
--------- -------
Workgroup Master
--------- -------
example CS4
On doit ensuite faire connaître le mot de passe du compte de connexion à l’annuaire à Samba :
# smbpasswd -W Setting stored password for "uid=Samba Admin,ou=System Accounts,dc=example,dc=com" in secrets.tdb New SMB password: Retype new SMB password:
On peut déjà vérifier que le lien avec l’annuaire LDAP est en place (en saisissant un mauvais mot de passe puis le bon).
# smbclient -L localhost -U administrator
Password:
session setup failed: NT_STATUS_LOGON_FAILURE
# smbclient -L localhost -U administrator
Password:
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
Sharename Type Comment
--------- ---- -------
public Disk Public Directory
IPC$ IPC IPC Service (Samba Server 3.0.22)
ADMIN$ IPC IPC Service (Samba Server 3.0.22)
Domain=[CS4] OS=[Unix] Server=[Samba 3.0.22]
Server Comment
--------- -------
Workgroup Master
--------- -------
example
Définissons maintenant notre serveur comme PDC, car jusqu’à présent, nous l’utilisions en autonome :
# vi /etc/samba/smb.conf
[global]
...
# PDC
security = user
# OS level > 32 pour être élu
os level = 128
# permet le déclenchement des élections
# définition d'un PDC
local master = yes
# dmain master browser
domain master = yes
# force les élections pour devenir PDC
preferred master = yes
# le serveur fait de l'authentification
domain logons = yes
...
# testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[public]"
Loaded services file OK.
WARNING: passdb expand explicit = yes is deprecated
Server role: ROLE_DOMAIN_PDC
Press enter to see a dump of your service definitions
[global]
workgroup = example
server string = Samba Server %v
map to guest = Bad User
passdb backend = ldapsam:ldap://127.0.0.1
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
domain logons = Yes
os level = 128
preferred master = Yes
domain master = Yes
ldap admin dn = uid=Samba Admin,ou=System Accounts,dc=edge-it,dc=subnet
ldap group suffix = ou=group
ldap machine suffix = ou=hosts
ldap suffix = dc=edge-it,dc=subnet
ldap ssl = no
ldap user suffix = ou=people
ldapsam:trusted = yes
[homes]
read only = No
browseable = No
[public]
comment = Public Directory
path = /home/public
read only = No
guest ok = Yes
Nous avons vu jusqu'à présent la configuration générale d'un serveur Samba et la mise en place de son rôle sur le réseau. Passons maintenant en revue les types de partages de ressources que vous pouvez mettre en place.
La syntaxe d'un partage est relativement simple et s'inscrit à la suite des paramètres génériques du serveur :
[<nom_partage>] comment = "<votre commentaire>" path = <chemin_ressource> browseable = <yes|no> writable = <yes|no>
Tout comme pour la section générale, un partage est introduit par son nom entre crochets. Ci-dessous les paramètres les plus courants :
comment : entrez ici un commentaire suffisamment significatif, il apparaît lors du parcours des ressources et vous permet d'en identifier rapidement le contenu
browseable : détermine si la ressource doit apparaître lors du parcours des ressources
writable : indique les droits en écriture ou en lecture sur la ressource partagée
- partage de type
logon -
Ce partage spécifique concerne les scripts de netlogon ou scripts de connexion des utilisateurs du domaine. Il permet le partage des scripts de netlogon générés à la volée grâce à la directive root preexec.
[netlogon] comment = Network Logon Service path = /data/samba/netlogon guest ok = yes writable = no write list = @administrateurs browseable = no root preexec = /data/samba/netlogon/logon_script '%m' '%U' '%a' '%g' '%L'
- partage de type
profile -
Dans le cas où vous avez recours au profils itinérants, ceux-ci feront donc également l'objet d'un partage Samba spécifique utilisant le mot clé profiles.
[profiles] path = /data/samba/profiles browseable = no guest ok = yes writable = yes - partage de type
homes -
Vous pouvez mettre à disposition les répertoires personnel (homes) des utilisateurs. On utilisera pour cela le mot clé réservé homes. %u est une variable prédéfinie contenant le nom d'usager de l'utilisateur.
[homes] comment = Home Directories browseable = no writable = yes path = /data/samba/prives/%u
- partage de type
group -
Ce type de partage vous permet de définir des ressources accessibles pour un ou plusieurs groupes donnés. Il évite de définir un partage par groupe. Le principe est simple : il repose sur la détermination de droits dans l'arborescence des données. Le paramètre hide unreadable permet de cacher aux utilisateurs les répertoires pour lesquels il n'a aucun droit. Par exemple :
# ll /data/samba/groupes/ total 24 drwxrws--- 111 root commercial 4096 avr 28 17:45 clients/ drwxrws--- 23 root utilisateurs 4096 sep 9 2005 commercial/ drwxrws--- 6 root support 104 jui 19 14:24 support/Le partage peut alors être écrit de la manière suivante :
[groupes] comment = Stockage Groupes path = /data/samba/groupes writable = yes browseable = yes hide unreadable = yes
Nous avons vu les partages de fichiers, abordons maintenant les partages d'imprimantes. Samba vous permet de faire du partage d'accès mais aussi du partage de drivers, vous évitant ainsi d'avoir à installer ces drivers sur chacune des machines clientes.
Le partage spécifique [printers] permet le partage de toutes les imprimantes disponibles grâce à CUPS. Le partage spécifique [print$] permet lui le partage des drivers.
# partage des imprimantes déclarées
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
guest ok = yes
writable = no
printable = yes
create mode = 0700
# partage de distribution des pilotes d'impression
[print$]
path = /var/lib/samba/printers
browseable = yes
read only = yes
write list = @administrateurs
guest ok = yes
Vous devrez au préalable disposer d'un serveur CUPS fonctionnel et déclaré dans la section [global] :
[global] ... # on se sert des imprimantes définies dans CUPS # on charge la liste printcap name = cups load printers = yes # ajout des imprimantes autorisé pour le groupe administrateurs printer admin = @administrateurs
Si le serveur CUPS n'est pas sur la même machine, vous pouvez ajouter la directive cups server suivie de l'adresse du serveur.
Une fois que vos partages sont définis, ainsi que le serveur CUPS utilisé, il reste à faire prendre en compte les imprimantes définies dans CUPS par Samba. On utilise pour cela la commande cupsaddsmb :
cupsaddsmb
-a -u <nom_administrateur>
Régler un problème de Samba n'est pas toujours une tâche facile. Voici une liste de vérifications à réaliser pour les dysfonctionnements les plus courants :
Vérifier l’espace disque disponible dans les systèmes de fichiers contenant les partages
Vérifier l’espace disque disponible pour les fichiers de journalisation (attention, si le niveau est élevé, vérifier également l’espace dans /tmp. Un niveau élevé peut également affecter considérablement les performances du serveur.
Vérifier l'inactivité éventuelle de processus Samba afin de régler au mieux le timeout
La documentation officielle de Samba propose un guide complet vous permettant d'identifier de manière exhaustive les sources de problèmes et les outils à mettre en place pour les diagnostiquer : section Troubleshooting de la documentation Samba.
Microsoft Windows utilise un jeu d’ACLs (Access Control Lists) et d’attributs étendus par rapport au triplé standard accessible sur un système GNU/Linux (Read/Write/Execute pour un utilisateur, son groupe, ou tout le monde). Il est possible de simuler une partie de ces informations sous GNU/Linux en utilisant un système de fichiers qui supporte un tel format, et en ajoutant les paquetages qui facilitent la gestion de ces ACLs.
Vous devrez alors installer les paquetages suivants :
acl : ce paquetage contient les commandes getfacl et setfacl qui permettent de voir, ajouter/modifier/supprimer des ACLs étendues sur un fichier ou répertoire.
attr : ce paquetage contient les commandes getfattr et setfattr qui permettent de voir, ajouter/modifier/supprimer des attributs étendus sur un fichier ou répertoire.
Les système de fichiers supportant ces ACLs :
On pourra lire POSIX Access Control Lists on
Linux pour plus d'informations.