Authentification sur un annuaire LDAP via SSL 1/50

Transcription

1 Authentification sur un annuaire LDAP via SSL 1/50 Authentification LDAP via SSL Anthony PAUL avec la participation de Damien MASCRE Le 8 Décembre 2004 Le texte surligné signifie qu'il s'agit d'un passage à revoir. Le 22 Août 2005: Je viens de faire l'acquisition d'un Xserve (un second arrivera plus tard). Je crains donc devoir laisser cette doc de côté pendant un certain moment, le temps de bien comprendre Mac OS X server. Ceci dit, Mac OS X utilisant OpenLDAP, je pense que je pourrais continuer plus tard. Le 6 Juin 2005: Calcul des RID pour former les SID des groupes et utilisateurs Information sur l'existence des scripts smbldap tools de Idealx, comme me l'avait suggéré Jean Michel MARTINIERE lors des journées CRI IUT 2005 à Arles. Le 17 Mai 2005: Commande pour pouvoir utiliser les accents dans les valeurs des attributs LDAP Le 12 Mai 2005 Un grand merci à Damien MASCRE pour ses critiques constructives. J'ai donc apporté les modifications suivantes: Un bind anonyme dans le premier exemple de ldap.conf Des explications sur le use_first_pass de PAM La méthode "tls_checkpeer no" du ldap.conf Des infos utiles sur les fichiers LDIF Et supprimé les confusions possibles entre TLS et SSL Finalement, la jonction du domaine à la volée fonctionne (et a toujours fonctionné...). Un problème de path dans mon script (la honte...) Une description plus complète de SSL, avec schémas Le 6 Mai 2005: Tableau des RID réservés et une présentation plus sympa Le 4 Mai 2005: Révision de la partie SSL Plus de détails sur l'attachement des clients sur le domaine Samba Le 19 Avril 2005: Le problème avec le smbpasswd est résolu en enlevant le suffixe de certaines entrées du smb.conf Mappage des groupes entre Unix et NT Modification d'entrées dans l'annuaire Le 14 Avril 2005: Un problème LDAP lors de l'exécution de smbpasswd Quelques infos supplémentaires sur les profils errants/obligatoires avec Samba. Le 13 Avril 2005: Je m'aperçois que l'entrée "ldap port" n'est pas reconnue par testparm. Pas très grave puisque inutile ici, mais à voir. Avant: Test d'un certificat SSL créé avec le nom de "borea" alors que le client se connecte en demandant "ldap", l'alias DNS de "borea". Création d'une ou Machines pour stocker les comptes machines Windows. Modification de la marche à suivre pour la création d'un certificat SSL (j'avais des problèmes avec les clients Macintosh). Table des matières

2 Authentification sur un annuaire LDAP via SSL 2/50 1 Introduction Installation sur Compaq Proliant ML370 (G1) Pourquoi SuSE et pas Debian Installation du système: Installation du serveur LDAP Le serveur OpenLDAP Configuration du daemon slapd Remplissage de la base: Configuration de ldap.conf Configuration de /etc/nsswitch.conf Configuration de PAM Configuration du poste client (Knoppix 3.6) Le root peut changer les mots de passe utilisateurs s'il connait l'ancien Le root peut changer les mots de passe Un utilisateur spécifique pour le bind Bind anonyme Sécurisation avec SSL/TLS Présentation de SSL et TLS Exemple de négociation Création des certificats et des clés Reconfiguration du daemon ldap Reconfiguration du ldap.conf du client Petite vérification Egalement bon à savoir Opérations courantes Ajouter un groupe Ajouter un utilisateur: Supprimer un utilisateur Modifier une entrée: Utiliser les accents Samba Installation pour SLES Modifications du daemon ldap Configuration de samba Les scripts smbldap- tools Ajout des groupes Ajout des utilisateurs Joindre une station Windows 2000 au domaine Créer une ou réservée aux comptes machines Création d'un utilisateur aux droits spéciaux Joindre le domaine APRES avoir créé un compte machine Quelques problèmes auxquels j'ai eu droit Joindre le domaine à la volée Les mots de passe Configuration des clients MacOS X ( Jaguar) Versions compatibles Configuration sans SSL Activation de SSL Le point sur les mots de passe Obsolète Installation du serveur OpenLDAP sous Debian 3.0r2...40

3 Authentification sur un annuaire LDAP via SSL 3/50 10 Sources Introduction Documentation pour la mise en place d'un serveur OpenLDAP permettant l'authentification des utilisateurs de machines Windows, Linux et MacOS X via SSL. Systèmes d'exploitation utilisés: Serveurs: - SuSE Linux Entrerprise Server 8 (SLES 8) - (dans la partie "obsolète", une partie Debian 3.0r2) Clients: - GNU/Linux Knoppix MS Windows 2000 Pro - Mac OS X Jaguar (10.2), Panther (10.3) 2 Installation sur Compaq Proliant ML370 (G1) 2.1 Pourquoi SuSE et pas Debian... L'utilisation de cette distribution est dûe au fait que les serveurs sont des Compaq Proliant ML370. Compaq/HP ne fournit ses drivers que pour les distributions de United Linux 1.0 dont SUSE fait partie, et plus particulièrement cette version SLES8. Ceci dit, je joins dans la partie "obsolète" une partie de la doc que j'avais écrite lorsque j'avais débuté mes travaux sous Debian (donc avant que le bruit des ventilateurs vienne à bout de ma patience). De plus, j'essaie de donner des explications les plus indépendantes des distributions possible. 2.2 Installation du système: Avant tout, voir le CD bootable Compaq: "Smart Start and Support Software" Release 4.70 Système minimal auquel on ajoute: - LSB Runtime Environment + lsb (+lprng) + pax + python + rsync + patch

4 Authentification sur un annuaire LDAP via SSL 4/50 - C/C+ + Compiler and Tools + gcc, gcc- c+ +, gcc- info + ncurses- devel + emacs21 + make + kernel- source - Authentication Server + openldap2 (+client) + pam_ldap + nss_ldap Une fois l'installation terminée, remplacer dans /etc/modules.conf le e100 par eepro100 pour le chipset réseau. Installation du rpm de hpasm (dans psp ul10.i586.en.tar.gz) qui gère, entre autres, les ventilateurs. Puis on fait en sorte que l daemon soit lancé au démarrage avec: # insserv /etc/init.d/hpasm

5 Installation du serveur LDAP 5/50 3 Installation du serveur LDAP 3.1 Le serveur OpenLDAP La base que je vais utiliser pour le serveur LDAP sera la suivante: o=iut, dc=stlo, dc=unicaen, dc=fr Lors de mes premiers tests, j'ai utilisé la base o=iut, dc=stlo, dc=unicaen, c=fr qui me paraissait plus correcte, mais l'autre base utilisant seulement des "dc" semble plus commune... Tant que j'y suis, voici les significations de quelques attributs: dn= Distinguished Name dc= Domain Component o= Organization c= Country cn= Common Name ou= Organizational Unit En ce qui concerne SLES 8, il existe déjà un utilisateur ldap (76) du groupe ldap (70). Les fichiers de configuration ldap se trouvent dans /etc/openldap. Les droits sur les fichiers de configuration: slapd.conf appartient à ldap:ldap en 440 ldap.conf appartient à root:root en Configuration du daemon slapd Edition du fichier /etc/openldap/slapd.conf pour la configuration du serveur LDAP: # slapd.conf # Les schémas include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema # On veut que ce qu'on ajoute dans l'annuaire corresponde au schémas définis schemacheck on pidfile argsfile /var/run/slapd/slapd.pid /var/run/slapd/slapd.args # Le type de base de données

6 Installation du serveur LDAP 6/50 database bdb # La base et le Manager (admin) suffix "o=iut,dc=stlo,dc=unicaen,dc=fr" rootdn "cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr" # Le mot de passe admin en clair. # Il vaut mieux le crypter avec la commande slappasswd -h {CRYPT} #rootpw {CRYPT}blabla... rootpw secret # La base de données DOIT exister avant de lancer slapd ET doit être # accessible seulement par l'utilisateur ldap en 700. directory /var/lib/ldap # Les index index objectclass eq # Les ACLs # # Le userpassword peut- être modifié par son propriétaire une fois authentifié # Les autres ne peuvent pas le voir a part l'admin access to attribute=userpassword by dn="cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr" write by self write by anonymous auth by * none # L'admin a tous les droits (yeh) access to * by dn="cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr" write by dn="cn=nss,o=iut,dc=stlo,dc=unicaen,dc=fr" read by * read Remplissage de la base: A présent, nous allons entrer les premières données dans notre annuaire. Pour ce faire, on va créer un fichier LDIF. C'est un simple fichier texte qu'on pourra importer dans la base plus tard. Exemple de création de la racine de l'annuaire: dn: o=iut, dc=stlo, dc=unicaen, c=fr objectclass: top objectclass: organization o: iut description: IUT de Saint Lo

7 Installation du serveur LDAP 7/50 La classe d'objets "top" représente la classe d'objet initiale. Elle est obligatoire. On peut préciser d'autres classes d'objets selon nos besoins. Les classes d'objets permettent d'ajouter des attributs (des champs de renseignement) supplémentaires. Par exemple la classe d'objets posixaccount va nous permettre de renseigner des attributs comme homedirectory ou uidnumber... Dans notre cas, on veut un annuaire de la forme suivante pour y stocker nos comptes utilisateurs (dans "People") et nos groupes (dans "Group"): Tous les éléments de cet arbre possède un "Distinguished Name". Par exemple, "People" sera accessible grâce à son Distinguished Name dn: ou=people, o=iut, dc=stlo, dc=unicaen, dc=fr et le groupe etu par dn: cn=etu, ou=group, o=iut, dc=stlo, dc=unicaen, dc=fr Chaque dn est unique. Concernant les fichiers ldif: Lorsqu'on utilise un attribut, il ne faut pas laisser sa valeur vide. Ex: description: est mal description: - est mieux Les sauts de lignes permettent de séparer différents dn. Il ne faut donc pas insérer de lignes vides au milieu d'un "paragraphe" définissant un dn. Pour notre premier fichier LDIF, on se doit de commencer par la racine de la base LDAP: dn: o=iut, dc=stlo, dc=unicaen, dc=fr objectclass: top objectclass: organization o: iut description: IUT de Saint Lo On continue avec le Manager. C'est l'administrateur de la base, le root, celui qui a tous les droits sur celle- ci. dn: cn=manager, o=iut, dc=stlo, dc=unicaen, dc=fr objectclass: organizationalrole

8 Installation du serveur LDAP 8/50 cn: Manager description: Manager de l'annuaire Puis les entrées People et Group, les unités organisationnelles qui contiendront respectivement les entrées utilisateurs et groupes d'utilisateurs. dn: ou=people, o=iut, dc=stlo, dc=unicaen, dc=fr objectclass: organizationalunit ou: People description: Les Utilisateurs dn: ou=group, o=iut, dc=stlo, dc=unicaen, dc=fr objectclass: organizationalunit ou: Group description: Les Groupes Un premier groupe: dn: cn=admin, ou=group, o=iut, dc=stlo, dc=unicaen, dc=fr objectclass: posixgroup objectclass: top cn: admin gidnumber: 200 description: Groupe du SysAdmin A noter, la présence d'une classe d'objets "posixgroup" et de l'attribut gidnumber. Et un premier utilisateur test, nommé "minus". Cette entrée a été générée par les Migration- Tools disponibles sur le site Plus de détails sur les entrées de comptes utilisateur plus bas. dn: uid=minus,ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr uid: minus cn: minus objectclass: account objectclass: posixaccount objectclass: top objectclass: shadowaccount userpassword: {crypt}$1$yth0hs8y$k4wvgg/vnyfc4qfquzf6v/ shadowlastchange: shadowmax: shadowwarning: 7 loginshell: /bin/bash uidnumber: 1000 gidnumber: 100 homedirectory: /home/minus Le mot de passe peut toujours être crypté grâce à la commande slappasswd -h

9 Installation du serveur LDAP 9/50 {CRYPT} vue précédemment. On peut donner plusieurs valeurs à un même attribut en le répétant sur plusieurs lignes (utile par exemple si on veut inclure des numéros de téléphone). On peut remplacer le dn: uid=mmm,... en dn: cn=mmm,... mais il semblerait que la forme avec uid soit préférée par les outils de migration. D'ailleurs, on peut noter également que l'attribut uid donne le nom du compte. L'UID "classique" est donné dans le champ uidnumber. Pour ajouter tous ces fichiers LDIF à la base, on utilise la commande: /usr/bin/slapadd -l fichier.ldif Puis on vérifie avec slapcat, qui permet de donner un listing complet du contenu de la base LDAP. Tous les messages d'erreurs sont redirigés vers /var/log/messages (en ce qui concerne SLES8). 3.2 Configuration de ldap.conf Pour que les authentifications soient possibles, on édite le fichier / etc/openldap/ldap.conf valable pour NSS et PAM (SLES8). Debian utilise deux fichiers de config différents: /etc/pam_ldap.conf et /etc/libnssldap.conf mais a priori, rien n'empêche de créer deux liens symboliques vers un même fichier puisque leurs syntaxes sont exactement identiques. De plus, en ce qui concerne l'attribut binddn, plus d'explications sur les options possible dans le chapitre concernant la configuration des clients Linux. # ldap.conf host uri base borea.stlo.unicaen.fr ldap://borea.stlo.unicaen.fr o=iut,dc=stlo,dc=unicaen,dc=fr ldap_version 3 # Par défaut, le bind se fait en anonyme # on peut préciser le nom d'un utilisateur mais ce n'est pas conseillé puisque le mot de passe # doit apparaître en clair # binddn cn=nss,o =iut,dc =stlo,dc =unicaen,dc = fr # bindpw mot_de_passe_en_clair # Pour un bon filtre de recherche:

10 Installation du serveur LDAP 10/50 # # Definit l'attribut contenant le login (defaut: uid) pam_login_attribute uid # Filtre a utiliser pour et avec pam_login_attribute pam_filter objectclass=posixaccount nss_base_passwd ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr?one nss_base_shadow ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr?one nss_base_group ou=group,o=iut,dc=stlo,dc=unicaen,dc=fr?one # Codage des mots de passe pam_password crypt Maintenant, on édite le script de démarrage de slapd, qui est /etc/init.d/ldap sous SLES8 afin de lui préciser vers quelles adresses on veut distribuer les donnés. On remplace le SLAPD_URLS="ldap:/// par SLAPD_URLS="ldap:// / qui signifie qu'on autorise toutes les adresses (mais a priori, /// correspond à // /). On démarre le serveur: /etc/init.d/ldap start 3.3 Configuration de /etc/nsswitch.conf Editer le /etc/nsswitch.conf en ajouter des entrées pour ldap: # passwd: ldap compat # group: ldap compat # ou alors: passwd: files ldap shadow: files ldap group: files ldap # il me semble que ces dernières entrées conviennent mieux... A partir de là, on doit être capable de voir les utilisateurs et groupes de l'annuaire LDAP en faisant: getent passwd ou getent group ou encore finger <login> 3.4 Configuration de PAM Les fichiers de /etc/pam.d cf. "man pam" et le "Linux- PAM - System Administrators Guide" dont une version française est disponible à ~ m a thieuc/linux- PAM/pam_fr.xhtml) Pour PAM, il y a deux moyens de configuration:

11 Installation du serveur LDAP 11/50 - utiliser le fichier /etc/pam.conf - utiliser les fichiers qui se trouvent dans le répertoire /etc/pam.d/ C'est cette dernière solution qui est utilisée ici. Chaque fichier comporte le nom d'un service (su, login...)et contient la configuration associée de la forme: groupe control-flag module options Pour chaque service, il y a quatre groupes: >>> auth: Vérifie que l'utilisateur est bien celui qu'il prétend être. Par exemple, en demandant un mot de passe (ou autre système d'authentification) >>> account: Regarde si l'utilisateur peut se connecter (est- ce que le compte a expiré, est- ce qu'il peut se connecter sur cette machine...) >>> session: Ce groupe gère tout ce qui doit être fait avant et juste après l'accès au service par l'utilisateur. Par exemple, monter le Home Directory. >>> password: Pour mettre à jour le système d'authentification, comme changer le mot de passe par exemple. Pour chaque module est associé un control- flag qui permet à PAM de gérer les succès ou échecs des différents modules pour un groupe. Ils sont au nombre de quatre: >>> requisite: Si le module échoue, alors PAM refuse l'accès immédiatement sans regarder les modules suivants du même groupe. >>> required: Si le module échoue, l'accès sera refusé mais PAM vérifie tout de même les autres modules. >>> sufficient: Si accepté, PAM ne vérifie pas les autres modules et offre l'accès (sauf si un précédent required a été refusé). >>> optional: Le succès ou l'échec de ce module n'a aucune importance sauf s'il est le seul module du groupe. Vient donc le moment de configurer PAM pour LDAP. En fait, une méthode simple est, pour chaque service, de précéder la ligne du module "classique" pam_unix.so par une ligne contenant le module pam_ldap.so. Voici par exemple mon fichier / etc/pam.d/other (qui donne la configuration de tous les autres services non spécifiés dans /etc/pam.d/) avec (en gras) les entrées à ajouter: #%PAM-1.0 auth required pam_warn.so auth sufficient pam_ldap.so auth required pam_unix2.so use_first_pass #nullok set_setrpc account required pam_warn.so account sufficient pam_ldap.so account required pam_unix2.so password required pam_warn.so password required pam_pwcheck.so use_cracklib password sufficient pam_ldap.so

12 Installation du serveur LDAP 12/50 password required pam_unix2.so use_first_pass use_authtok session required pam_warn.so session sufficient pam_ldap.so session required pam_unix2.so debug # none or trace ATTENTION: Il faut également ajouter l'option " use_first_pass" au module pam_unix.so du groupe auth. Et ce, pour tous les service excepté SSH. L'explication m'a été donnée par Damien MASCRE: En fait, le use_first_pass évite que si pam_ldap échoue, pam_unix relance un prompt. Admettons par exemple qu'on veuille se connecter avec l'utilisateur root, lequel n'existe pas dans l'annuaire LDAP. PAM commence donc par pam_ldap, demande un mot de passe, et va se binder à l'annuaire en tant que uid=root et le mot de passe donné. Fatalement, ça va rater. PAM passe donc à pam_unix. Il connaît le username (root), mais il va redemander le mot de passe SAUF si on utilise use_first_pass. Par contre, le service ssh qui utilise des clés ne passe pas par le groupe auth du fichier de configuration PAM. On peut donc même se passer d'ajouter le pam_ldap dans la section auth du service ssh (d'ailleurs, pour Debian 3.1, il n'y a même pas de pam_unix dans cette section). Toujours le même Damien MASCRE me précise que use_authtok n'est utile que pour les authentifications à base de ticket, comme Kerberos. Simplement pour info, voici le other d' une distribution Debian après modification pour LDAP (c'est un peu plus clair...): auth sufficient pam_ldap.so auth required pam_unix.so use_first_pass account sufficient pam_ldap.so account required pam_unix.so password sufficient pam_ldap.so password required pam_unix.so session sufficient pam_ldap.so session required pam_unix.so

13 Configuration des clients Linux 13/50 4 Configuration du poste client (Knoppix 3.6) dpkg -i libnss-ldap_220-1_i386.deb dpkg -i libpam-ldap_169-1_i386.deb Modification des fichiers /etc/pam.d/ et /etc/nsswitch.conf de la même façon que pour le serveur. Copie du ldap.conf du serveur /etc/ldap/ du client. Puis création de liens symboliques car, comme dit plus haut, Debian utilise deux fichiers de configuration distincts pour PAM et NSS. ln -s /etc/ldap/ldap.conf /etc/pam_ldap.conf ln -s /etc/ldap/ldap.conf /etc/libnss-ldap.conf A ce stade, la commande getent passwd renvoie bien tous les utilisateurs et on peut se logguer. Par contre, le changement de mot de passe est possible mais on doit le rentrer 4 fois quand on effectue ce changement directement sur le serveur... (sur le client, il ne le demande que 2 fois) Solution: mettre la première ligne de la section password de /etc/pam.d/passwd en commentaire. (exclusivité SLES 8?) #password required pam_pwcheck.so nullok password sufficient pam_ldap.so password required pam_unix2.so nullok use_first_pass use_authtok Il y a plusieurs façons de se connecter au serveur LDAP. La façon qui sera utilisée dépend de la configuration du ldap.conf. De plus, deux de ces solutions permettent les changements des mots de passe utilisateurs par le root local avec la commande passwd. 4.1 Le root peut changer les mots de passe utilisateurs s'il connait l'ancien Dans ce cas, on donne comme binddn un utilisateur ayant les droits d'écriture sur l'attribut userpassword: binddn cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr bindpw secret Mais attention! Le mot de passe doit apparaître en clair dans un fichier qui doit être lisible par tout le monde! Cette solution est déconseillée! 4.2 Le root peut changer les mots de passe Configuration idéale pour le serveur par exemple. On utilise alors: rootbinddn cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr

14 Configuration des clients Linux 14/50...et on crée un fichier /etc/ldap.secret en 600 contenant le mot de passe du Manager: # echo mot_de_passe > /etc/ldap.secret (root:root 600) Cette technique dépend de PAM, donc que ce soit une distribution SUSE ou Knoppix, le fichier est toujours /etc/ldap.secret (indépendant du répertoire ldap ou openldap) 4.3 Un utilisateur spécifique pour le bind On peut créer un utilisateur sur le même modèle que le Manager, mais qui n'aurait aucun droit particulier mis à part celui de lecture. Par exemple un utilisateur nommé nss. Dans le slapd.conf, on ajoute alors: access to * by dn="cn = Manager,o =iut,dc =stlo,dc =u nicaen,dc =fr" write by dn="cn=nss,o=iut,dc=stlo,dc=unicaen,dc=fr" read # by * read Puis dans le ldap.conf: binddn cn=nss,o=iut,dc=stlo,dc=unicaen,dc=fr (bindpw mdp?) 4.4 Bind anonyme Puisqu'on a déjà (dans le slapd.conf): access to * by dn="cn = Manager,o =iut,dc =stlo,dc =u nicaen,dc =fr" write by * read Il est possible de faire les bind en anonyme. Il suffit juste d'enlever les lignes binddn et bindpw du ldap.conf. C'est le comportement par défaut.

15 Sécurisation avec SSL/TLS 15/50 5 Sécurisation avec SSL/TLS 5.1 Présentation de SSL et TLS SSL (Secure Socket Layer) est un protocole pour la sécurisation des données, créé par Netscape. La dernière version (le version 3) date de TLS (Transport Layer Security - RFC 2246 ) est en fait la nouvelle version de SSL (racheté et rebaptisé par l' Internet Engineering Task Force IETF en 2001). La principale différence au niveau utilisateur est que SSL fait des transferts sécurisés sur le port 636 (ldaps) tandis que TLS les fait sur le port standard 389 (ldap), ce qui permet aux clients sécurisés et non sécurisés d'utiliser le même port standard. Dans la pratique, du côté serveur, TLS est activé dès que TLSCertificateFile et TLSCertificateKeyFile sont présents dans le slapd.conf. Côté client, si on veut utiliser SSL: l'uri est ldaps://serveur:636/ et on l'active avec ssl on et pour TLS (nécessite OpenLDAP > = 2.1): ldap://serveur:389/ et ssl start_tls. TLS utilise un algorithme différent pour le cryptage de la clé de session, ce qui a pour conséquence une incompatibilité avec SSL. Cependant, TLS contient un mécanisme permettant une compatibilité ascendante. SSL/TLS utilise le chiffrement asymétrique (aka chiffrement à clé publique) pour l'authentification et le chiffrement symétrique, plus rapide, pour l'échange des données. Le serveur dispose de 2 clés. Une clé publique et l'autre pivée. Il distribue la clé publique à tous ceux qui la demande alors qu'il est le seul à connaître la clé privée. Enfin, les données cryptées par la clé publique ne peuvent être décryptées que par la clé privée. Et invers ement, les données cryptées par la clé privée ne peuvent être décryptées que par la clé publique. ATTENTION: Dans cette doc, je n'utilise que SSL. 5.2 Exemple de négociation Une négociation SSL se fait en 4 étapes. Tout d'abord, le client demande le certificat du serveur.

16 Sécurisation avec SSL/TLS 16/50 Le serveur lui envoie alors son certificat. Ce certificat contient: - La clé publique du serveur - Des informations comme le nom de l'organisation, la date d'expiration du certificat... - Le signature de l'autorité de Certification (AC) L'autorité de certification (Cetificate Authority CA en anglais) est un tiers responsable de l'émission des certificats, comme l'est par exemple VeriSign. Elle doit suivre des procédures strictes pour authentifier et vérifier les organisations auxquelles elle délivre un certificat. Ce certificat est signé avec le clé privée de l'ac pour en guarantie l'authenticité. Si cette AC n'est pas connue du client, le service (HTTP, LDAP...) demandera à l'utilisateur s'il fait confiance à cette AC ou pas. C'est ce qui se produit par exemple quand on va sur un site sécurisé ( mais que le navigateur internet nous demande d'accepter ou pas un certificat. Pour info, les navigateurs internet disposent tous du certificat de VeriSign. Ils ne demandent donc pas aux utilisateurs s'ils font ou non confiance aux sites qui envoient un certificat signé par VeriSign. Etape suivante de la négociation: Le client approuve l'ac. Puis il vérifie que le certificat correspond bien à celui attendu. Il génère alors aléatoirement une clé de session qu'il crypte avec la clé publique du serveur et lui envoie. Ce qui est crypté avec la clé publique ne peut être décrypté que par la clé privée

17 Sécurisation avec SSL/TLS 17/50 qui est seulement en possession du serveur. Seul le serveur est alors en mesure de décrypter la clé de session. Le serveur et le client disposent maintenant d'une clé de session qu'eux seuls connaissent. Ils peuvent alors utiliser le chiffrement symétrique pour s'échanger des données. 5.3 Création des certificats et des clés Il existe un script (en Perl ou Bash) qui permet de créer les certificats et clés de façon assez simple. Ces scripts se nomment CA.pl ou CA.sh et se trouvent dans / usr/share/ssl/misc/ pour SLES8 ou dans /usr/lib/ssl/misc/ pour Debian 3.1. On va dans le répertoire réservé à SSL (pour SLES8 ou Debian 3.1, /etc/ssl/) et on crée une arborescence correspondant au fichier de configuration / etc/ssl/openssl.cnf (éventuellement, corriger selon le fichier de config). # cd /etc/ssl # mkdir -p democa/{private,newcerts} Le répertoire democa contiendra l'authority Certificate (CA) et le répertoire democa/private contiendra sa clé privée. Ensuite on crée le fichier qui servira de base de donnée à OpenSSL (index.txt) et on initialise les numéros de série: # touch democa/index.txt # echo "01" > democa/serial Tout d'abord, on va créer une AC. On pourrait s'en passer, en faisant un certificat "auto- signé" mais dans ce cas, la clé privée du serveur serait incluse dans le certificat qu'il distribue. Ce qui est évidemment une mauvaise idée. On crée donc l'autorité de Certification et sa clé privée (./CA.sh -newca): # openssl req -new -x509 -keyout democa/private/cakey.pem \ -out democa/cacert.pem -days 365

18 Sécurisation avec SSL/TLS 18/50 (sortie:) Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to 'private/cakey.pem' Enter PEM pass phrase: (entrer un mot de passe) Verifying password - Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:France Locality Name (eg, city) []:Saint Lo Organization Name (eg, company) [Internet Widgits Pty Ltd]:IUT Organizational Unit Name (eg, section) []:SI Common Name (eg, YOUR name) []:borea.stlo.unicaen.fr Address []:a.paul@chbg.unicaen.fr Le common name doit être le nom de la machine pleinement défini (hostname + domaine). On crée ensuite un nouveau certificat incluant la clé privée du serveur mais non cryptée (option -nodes, OpenLDAP ne peut pas fonctionner avec une clé cryptée). Un tel certificat est connu sous le nom de server Certificate Signing Request - CSR) # openssl req -new -nodes -keyout newreq.pem -out newreq.pem (ATTENTION:./CA.sh -newreq crée bien un CSR, mais avec une clé cryptée) (sortie:) Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to 'newreq.pem' You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [AU]:FR

19 Sécurisation avec SSL/TLS 19/50 State or Province Name (full name) [Some-State]:France Locality Name (eg, city) []:Saint Lo Organization Name (eg, company) [Internet Widgits Pty Ltd]:IUT Organizational Unit Name (eg, section) []:SI Common Name (eg, YOUR name) []:borea.stlo.unicaen.fr Address Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: [entrée] An optional company name []:[entrée] "newreq.pem" est donc la clé privée du serveur. Enfin, on signe le certificat du serveur avec l'ac (./CA.sh -sign): # openssl ca -policy policy_anything -out newcert.pem \ -infiles newreq.pem (sortie:) Using configuration from /etc/ssl/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryname :PRINTABLE:'FR' stateorprovincename :PRINTABLE:'France' localityname :PRINTABLE:'Saint Lo' organizationname :PRINTABLE:'IUT' organizationalunitname:printable:'si' commonname :PRINTABLE:'borea.stlo.unicaen.fr' address :IA5STRING:'a.paul@chbg.unicaen.fr' Certificate is to be certified until Feb 3 15:17: GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated "newcert.pem" est le certificat signé du serveur, contenant sa clé publique. La clé privée ne doit être visible QUE par le serveur: # cp newreq.pem /etc/openldap/slapd_key.pem # chown ldap:ldap /etc/openldap/slapd_key.pem # chmod 600 /etc/openldap/slapd_key.pem Le certificat contenant la clé publique (lisible par tout le monde) # cp newcert.pem /etc/openldap/slapd_cert.pem Et le certificat de l'ac, qui devra être copié également sur les clients

20 Sécurisation avec SSL/TLS 20/50 # cp democa/cacert.pem /etc/openldap 5.4 Reconfiguration du daemon ldap Dans le slapd.conf, on ajoute: # SSL / TLS TLSCACertificateFile /etc/openldap/cacert.pem TLSCertificateFile /etc/openldap/slapd_cert.pem TLSCertificateKeyFile /etc/openldap/slapd_key.pem # Les Cipher a utiliser (?) TLSCipherSuite HIGH:MEDIUM:+SSLv2 Dans /etc/init.d/ldap on remplace les 2 adresses: ldap:/// en ldap:// / (déjà fait) ldaps:/// en ldaps:// / Mais a priori, on peut laisser simplement /// Dans /etc/sysconfig/openldap, on remplace OPENLDAP_START_LDAPS="no" par OPENLDAP_START_LDAPS="yes" On relance le serveur. De temps en temps, je n'arrive pas à le redémarrer à distance (par ssh). Dans ce cas, je me loggue en root directement sur le serveur et lance # /etc/init.d/ldap start 5.5 Reconfiguration du ldap.conf du client Dans le fichier de configuration du client, on ajoute un "s" à l'uri ldap:// pour avoir uri ldaps://borea.stlo.unicaen.fr...et on ajoute également les lignes: ssl on port 636 TLS_REQCERT demand TLS_CACERT /etc/ssl/certs/cacert.pem (après bien sûr, l'avoir copié sur la machine cliente) Et voilà! Il se trouve que copier les certificats sur chaque machine cliente peut vite devenir fastidieux voire pénible, surtout si on est sûr de la sécurité de son réseau. Damien MASCRE m'a appris l'existence de l'option " tls_checkpeer no". Cette option va permettre au client de faire confiance au serveur et ne va donc pas vérifier l'autorité de Certification. En conséquence, le client va accepter la signature de l'ac sans avoir à lui donner une copie de cette signature, ni lui spécifier si on l'accepte ou pas. Les lignes à ajouter dans le ldap.conf deviennent donc:

21 Sécurisation avec SSL/TLS 21/50 ssl on port 636 tls_checkpeer no 5.6 Petite vérification On installe ngrep Si on prend l'exemple de l'utilisateur "paul", on lance alors sur le serveur: # ngrep "paul" port 636 ou # ngrep "paul" port 389 or 636 (pour s'assurer de tous les ports) Sur un poste client, on peut par exemple lancer un "id paul". Si SSL n'est pas activé, ngrep affichera du plaintext, avec par exemple le dn complet de l'utilisateur. Si SSL est activé, on obtiendra simplement des données cryptées. 5.7 Egalement bon à savoir Pour pouvoir lire l'annuaire avec Mozilla Mail (sinon, erreur "requested protocol version not allowed"), ajouter dans slapd.conf: allow bind_v2

22 Opérations courantes 22/50 6 Opérations courantes 6.1 Ajouter un groupe Fichier LDIF: dn: cn=nouveau_groupe,ou=group,o=iut,dc=stlo,dc=unicaen,dc=fr objectclass: top objectclass: posixgroup cn: nouveau_groupe gidnumber: 1000 description: - Commande: # /usr/bin/ldapadd -x -D \ 'cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr' -w secret \ -f fichier.ldif 6.2 Ajouter un utilisateur: Voici un modèle: dn: uid=paul,ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr objectclass: inetorgperson objectclass: posixaccount objectclass: top objectclass: shadowaccount objectclass: organizationalperson sn: PAUL givenname: Anthony cn: PAUL Anthony uid: paul userpassword: {CRYPT}ggkNMtzLudHUw shadowlastchange: shadowmax: shadowwarning: 7 shadowinactive: -1 shadowexpire: -1 shadowflag: loginshell: /bin/bash uidnumber: 201 gidnumber: 200 homedirectory: /home/paul mail: a.paul@chbg.unicaen.fr postaladdress: IUT Saint Lo$120 rue de lexode$50000 Saint Lo telephonenumber: (+33)(0) mobile: - facsimiletelephonenumber: (+33)(0) labeleduri: jpegphoto:< file:///path/to/photo.jpg description: bla-bla

23 Opérations courantes 23/50 Attention, ne pas mettre les valeurs entre guillemets. Mobile: Pas de valeur vide! postaladdress: IUT Saint Lô$120 rue de lexode$50000 Saint Lô jpegphoto:< file:///path/to/photo.jpg Pas d'espace entre le ":" et le "<". Ainsi, jpegphoto contient une valeur binaire (la photo peut être déplacée après, puisque c'est sa valeur qui est enregistrée dans l'annuaire). shadowlastchange: Date de derniere modif depuis le shadowmax: Nb de jours de validité du mot de passe avant changement obligatoire (99999 = pas de limite) shadowwarning: 7 Nb de jours avant expiration pour prévenir l'utilisateur shadowinactive: 1 Nb de jours après la date d'expiration avant désactivation du compte (-1= fonction désactivée) shadowexpire: 1 Nombre de jours après le où le compte sera désactivé (-1= fonction désactivée) shadowflag: Pour une utilisation future Commande: # /usr/bin/ldapadd -x -D \ 'cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr' -w secret \ -f fichier.ldif # -x: simple authentification (pas de SASL) # -D: introduit l'utilisateur à utiliser comme bindn # -w: introduit le mot de passe en plaintext (-W pour un prompt) # -f: introduit le fichier Attention: slapadd nécessite que slapd soit éteint. Pas ldapadd. Ajouter l'utilisateur paul à un groupe secondaire "gr2": Fichier LDIF: dn: cn=gr2,ou=group,o=iut,dc=stlo,dc=unicaen,dc=fr Add: memberuid

24 Opérations courantes 24/50 memberuid: paul Commande: # /usr/bin/ldapmodify -x -D \ 'cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr' -w secret \ -f fichier.ldif Création du Home Directory à la main: # mkdir /home/paul/ # cp -Rf /etc/skel/.??* /etc/skel/* /home/paul/ # chown -R paul:admin /home/paul # chmod 700 /home/paul # find /home/paul -type f -exec chmod 600 {} \; # find /home/paul -type d -exec chmod 700 {} \; 6.3 Supprimer un utilisateur Commande: # /usr/bin/ldapdelete -x -D \ 'cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr' -w secret \ 'uid=utilisateur_à_effacer,ou=people,o=iut,dc=stlo, \ dc=unicaen,dc=fr' Ainsi que la suppression de son entrée dans les groupes secondaires : Fichier LDIF: dn: cn=gr2,ou=group,o=iut,dc=stlo,dc=unicaen,dc=fr delete: memberuid memberuid: utilisateur_à_effacer Commande: # /usr/bin/ldapmodify -x -D \ 'cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr' -w secret \ -f fichier.ldif 6.4 Modifier une entrée: Fichier LDIF pour ajouter un attribut: dn: uid=paul,ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr changetype: modify add: roomnumber roomnumber: Bureau 119 Fichier LDIF pour modifier la valeur d'un attribut:

25 Opérations courantes 25/50 dn: uid=paul,ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr changetype: modify replace: postaladdress postaladdress: 120 rue de l'exode$50000 Saint Lo Commande: # ldapmodify -x -D 'cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr' \ -w secret -f fichier.ldif Pour modifier et ajouter des attributs dans le même fichier LDIF (merci à Damien MASCRE): version: 1 dn: uid=paul,ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr changetype: modify replace: postaladdress postaladdress: 120 rue de l'exode$50000 Saint Lo - changetype: modify add: roomnumber roomnumber: Bureau 119 Le tiret (-) indique qu'il y a d'autres modifications à faire sur l'entrée en cours. Par contre, on ne peut pas modifier un attribut qui n'existe pas ou en ajouter un qui existe déjà (en fait, dans ce cas, l'attribut traité se verra ajouter une deuxième valeur). Une solution serait de lancer les 2 commandes ldapadd et ldapmodify avec l'option -c pour que la commande continue malgré les erreurs. 6.5 Utiliser les accents Pour que l'annuaire gère bien les accents, il faut que les fichiers LDIF contenant ces accents soient encodés en UTF-8. Si ce n'est pas le cas, la commande pour passer d'un encodage à un autre est iconv. Dans notre cas, cela donne: $ iconv fichier.ldif -f LATIN1 -t UTF-8 -o fichier_utf-8.ldif On peut obtenir la liste des encodages gérés par un simple iconv --list.

26 Samba 3 26/50 7 Samba Installation pour SLES8 Des RPMs de la version pour ul1- sles8 sont disponibles sur le site de Samba. C'est cette version que j'utilise. Voici la liste des RPM installés ainsi que leurs dépendances: ldapsmb i586.rpm -> perl- ldap (trouvé sur internet) --> perl- URI (CD1) --> perl- XML-Parser (CD1) --> perl- Convert- ASN1 (internet, SuSE 8.1) samba3- doc i586.rpm samba3- client i586.rpm -> libattr.so.1 (attr i586.rpm internet SuSE 8.1) samba i586.rpm -> libcups.so.2 (cups- libs rc2-1.i586.rpm internet sles8) Les fichiers de config sont dans /etc/samba/ # cp smb.conf smb.conf.orig 7.2 Modifications du daemon ldap Samba est livré avec son schema LDAP, on doit le copier dans /etc/openldap/schema # cp /usr/share/doc/packages/samba3/examples/ldap/samba.schema / etc/openldap/schema/ Dans le slapd.conf, on ajoute le schema: include /etc/openldap/schema/samba.schema Et on remplace la ligne access to attribute=userpassword par access to attribute=userpassword,sambalmpassword,sambantpassword 7.3 Configuration de samba Créer un fichier smb.conf minimal: %I= Adresse IP du client %m= nom netbios du client %M= nom DNS du client %U= nom d'utilisateur unix %G= groupe principal de %U

27 Samba 3 27/50 %H= homedir de %u %h= nom DNS du serveur samba %L= nom netbios du serveur samba %T= date et heure courantes %v= Version de samba # smb.conf [global] # Nom du domaine workgroup = IUTSTLO # Le nom netbios du serveur: netbios name = BOREA server string = %h (samba %v) # Ne pas inclure 'root' ici. Les clients qui joignent le domaine en ont besoin... invalid users = bin daemon adm sync shutdown halt mail \ news uucp operator gopher # Les machines autorisées: hosts allow = localhost # ou #hosts allow = / localhost # Les logs log file = /var/log/samba/log.%m max log size = 50 # LDAP: passdb backend = ldapsam:ldap:// / ldap admin dn = cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr ldap suffix = o=iut,dc=stlo,dc=unicaen,dc=fr # ne surtout pas rajouter le suffixe: ldap user suffix = ou=people ldap group suffix = ou=group ldap machine suffix = ou=machines # LDAP: Support SSL. Inutile si les serveurs samba et ldap sont sur # la meme machine # ldap ssl = on (start_tls par défaut) # ldap port ne semble pas reconnu par testparm alors qu'il est dans le howto... #ldap port = 636 #ldap ssl = on # Pour faire un PDC domain logons = yes security = user os level = 255 local master = yes

28 Samba 3 28/50 preferred master = yes domain master = yes # Z: par défaut logon drive = h: # Les 2 lignes suivantes désactivent les profils errants logon home = logon path = encrypt passwords = yes [tmp] path = /tmp browseable = yes writeable = yes guest ok = yes passdb backend sert à dire qu'on utilise la base LDAP et non pas le fichier smbpasswd ldap suffix introduit le suffixe LDAP qui sera ajouté à tous les autres DN correspondants à l'emplacement des entrées utilisateurs, groupes et machines. ldap user suffix = ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr semblera fonctionner dans un premier temps, mais des commandes comme net groupmap ne fonctionneront pas. Attention donc. On enregistre le mot de passe du Manager dans secret.tdb pour que Samba n'ait plus à le demander. # smbpasswd -w secret Setting stored password for "cn=manager, o=iut, dc=stlo, dc=unicaen, dc=fr" in secrets.tdb 7.4 Les scripts smbldap- tools Il existe un package contenant une série de scripts nommé smbldap- tools. Ces scripts sont fournis par la société idealx ( et facilitent grandement la création des groupes et des utilisateurs Samba. Je ne les utilisent pas car, en rédigeant cette documentation, je cherche à comprendre comment OpenLDAP et Samba interagissent, mais je conçois que cela n'intéresse pas du tout bon nombre de personnes, et je ne peux que les encourager à utiliser ces scripts très populaires. 7.5 Ajout des groupes Ensuite, on doit mapper les groupes. A chaque groupe NT doit correspondre un groupe UNIX. On obtient la liste des groupes et leurs SID (Secure Identifier Domain) avec la commande: # net groupmap list Pour mapper un groupe, on doit tout d'abord avoir un groupe POSIX existant dans

29 Samba 3 29/50 l'annuaire LDAP. On doit également connaître le SID de notre domaine: # net getlocalsid SID for domain BOREA is: S On peut alors exécuter la commande suivante: # net groupmap add sid=s ntgroup="le groupe 1" unixgroup=groupe1 type=domain Successfully added group gte1g1 to the mapping db A noter le qui suit le SID du domaine. Il s'agit d'un RID (R pour Relative). On le calcule en fonction du GID du groupe: RID= gidnumber x Certains RID sont réservés (voir plus bas). On fait de même pour tous les groupes. Dans le HOWTO officiel de Samba 3, il est fait mention de 3 autres groupes à créer impérativement pour le bon fonctionnement. Il s'agit des fameux groupes NT "Administrateurs du domaine", "Utilisateurs du domaine" et "Invités du domaine". On les crée donc tout d'abord dans la base LDAP en utilisant un fichier LDIF comme d'habitude: dn: cn=ntadmins, ou=group, o=iut, dc=stlo, dc=unicaen, dc=fr objectclass: posixgroup objectclass: top gidnumber: 512 cn: ntadmins description: Admins du domaine Samba dn: cn=ntusers, ou=group, o=iut, dc=stlo, dc=unicaen, dc=fr objectclass: posixgroup objectclass: top gidnumber: 513 cn: ntusers description: Utilisateurs du domaine Samba dn: cn=ntguests, ou=group, o=iut, dc=stlo, dc=unicaen, dc=fr objectclass: posixgroup objectclass: top gidnumber: 514 cn: ntguests description: Invites du domaine Samba Puis on les mappe: # net groupmap add sid=s \ ntgroup="domain Admins" unixgroup=ntadmins type=domain # net groupmap add sid=s \ ntgroup="domain Users" unixgroup=ntusers type=domain # net groupmap add sid=s \ ntgroup="domain Guests" unixgroup=ntguests type=domain

30 Samba 3 30/50 Attention! Leurs RID (512, 513 et 514) sont importants! Ceux là ne peuvent pas être changés. Voici la liste des RID réservés (liste issue du HOWTO de Samba3): (les entrées "builtin" sont en fait les utilisateurs ou groupes "locaux") Entité RID Type Essentiel Domain Administrator Domain Guest Domain KRBTGT Utilisateu r Utilisateu r Utilisateu r Non Non Non Domain Admins 512 Groupe Oui Domain Users 513 Groupe Oui Domain Guests 514 Groupe Oui Domain Computers 515 Groupe Non Domain Controllers 516 Groupe Non Domain Certificate Admins 517 Groupe Non Domain Schema Admins 518 Groupe Non Domain Enterprise Admins 519 Groupe Non Domain Policy Admins 520 Groupe Non Builtin Admins 544 Alias Non Builtin users 545 Alias Non Builtin Guests 546 Alias Non Builtin Power Users 547 Alias Non Builtin Account Operators 548 Alias Non Builtin System Operators 549 Alias Non Builtin Print Operators 550 Alias Non Builtin Backup Operators 551 Alias Non Builtin Replicator 552 Alias Non Builtin RAS Servers 553 Alias Non 7.6 Ajout des utilisateurs Si un compte utilisateur existe, on peut l'ajouter comme compte Samba avec: # smbpasswd -a utilisateur Pour l'enlever de la base Samba: # smbpasswd -x utilisateur Cela ajoute ou enlève des attributs dans l'entrée LDAP de cet utilisateur comme par

31 Samba 3 31/50 exemple son propre SID (sambasid) et le SID de son groupe principal (sambaprimarygroupsid). D'ailleurs, l'importance d'ajouter les utilisateurs APRES le mappage des groupes est là: si le groupe n'est pas mappé quand on ajoute l'utilisateur, alors l'attribut sambaprimarygroupsid comportera une valeur erronée. Il faudra alors le modifier soi-même. A noter que le RID utilisé pour l'attribut sambasid de l'utilisateur suit également un algorithme. On le calcule de la façon suivante: RID= uidnumber x Ceci dit, la commande smbpasswd -a se charge de le calculer elle même. A partir d'ici, sur une machine Windows, on peut voir le nouveau domaine, le serveur samba, et se connecter dessus à partir du "voisinage réseau" en lui précisant un compte et un mot de passe présent dans la base LDAP. 7.7 Joindre une station Windows 2000 au domaine Créer une ou réservée aux comptes machines Tout d'abord, on peut créer un nouvelle branche dans l'annuaire LDAP qui accueillera les comptes machines si on veut les séparer des comptes utilisateur s. Mais ATTENTION, les comptes machines doivent toujours être consultable avec un " getent passwd" ainsi qu'un " id ma_machine$" (par expérience, l'un ne fait pas l'autre). Cela implique donc des modifications dans le ldap.conf. Si on veut une ou réservée aux comptes machines: Le fichier LDIF à taper: dn: ou=machines, o=iut, dc=stlo, dc=unicaen, dc=fr objectclass: organizationalunit ou: Machines description: Les comptes machines Puis la commande: # /usr/bin/ldapadd -x -D \ 'cn=manager,o=iut,dc=stlo,dc=unicaen,dc=fr' -w secret \ -f fichier.ldif Puis on modifie le ldap.conf: nss_base_passwd ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr?one nss_base_shadow ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr?one nss_base_group ou=groups,o=iut,dc=stlo,dc=unicaen,dc=fr?one devient nss_base_passwd o=iut,dc=stlo,dc=unicaen,dc=fr?sub nss_base_shadow o=iut,dc=stlo,dc=unicaen,dc=fr?sub nss_base_group ou=groups,o=iut,dc=stlo,dc=unicaen,dc=fr?one Le?sub signifie qu'il faut également parcourir les "sous- répertoires", contrairement au?one qui n'explore que le "répertoire" précisé. Ainsi, getent passwd et id sont

32 Samba 3 32/50 en mesure de trouver les comptes machines Création d'un utilisateur aux droits spéciaux Pour permettre à un client de joindre le domaine, on a besoin d'un utilisateur avec les mêmes propriétés que root dans la base (ex, un compte appelé su avec UID=0 et GID=0): dn: uid=su,ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr objectclass: inetorgperson objectclass: posixaccount objectclass: top objectclass: shadowaccount objectclass: organizationalperson sn: - givenname: - cn: SuperUser uid: su userpassword: {CRYPT}ggkNMtzLudHUw shadowlastchange: shadowmax: shadowwarning: 7 shadowinactive: -1 shadowexpire: -1 shadowflag: loginshell: /bin/false uidnumber: 0 gidnumber: 0 homedirectory: /dev/null mail: - postaladdress: - telephonenumber: - mobile: - facsimiletelephonenumber: - labeleduri: - jpegphoto: - description: Compte pour joindre le domaine Samba On l'ajoute à samba: # smbpasswd -a su Joindre le domaine APRES avoir créé un compte machine Ajouter un compte machine dans la base LDAP, ex: dn: uid=carless-reef$,ou=machines,o=iut,dc=stlo,dc=unicaen,dc=fr objectclass: posixaccount objectclass: inetorgperson objectclass: top uid: carless-reef$ cn: carless-reef$

33 Samba 3 33/50 sn: Compte Machine Samba userpassword: {CRYPT}x loginshell: /bin/false uidnumber: gidnumber: homedirectory: /dev/null ATTENTION: Le nom de la machine doit être suivi impérativement par un $! Nul besoin d'exécuter un smbpasswd -m, au contraire, je soupçonne d'apporter des problèmes... Maintenant, à partir de la station cliente, on peut joindre le domaine de la manière habituelle (Clic droit sur poste de travail - Propriétés -...) en utilisant le compte su précédemment créé Quelques problèmes auxquels j'ai eu droit getent passwd renvoit bien le nom de la machine, mais id machine$ ne le trouve pas. Le problème semble venir de nscd (name service cache daemon). Le redémarrer suffit souvent. Je ne pense pas que ce soit un service primordial, je le stoppe. Sur une machine Windows 2000 (SP3), je peux me connecter, mais je n'arrive pas à explorer le réseau. "Impossible d'effectuer cette action. Réseau actif", ou quelque chose du genre. Ca m'est arrivé alors que j'avais essayé de joindre la station au domaine alors que je n'avais pas encore créé son compte LDAP. Solution, TRES bizarre: Je me suis aperçu qu'après m'être connecté en ssh sur le serveur (en root) à partir de ce client (avec putty), tout rentrait dans l'ordre Joindre le domaine à la volée L'avantage de joindre un domaine "à la volée" est qu'il n'y a plus besoin de créer le compte machine soi-même. Pour cela, il suffit d'ajouter cette ligne dans le smb.conf: add user script = /usr/local/bin/ldap-smbmachineadd.py %u Où LDAP-smbmachineadd.py est un script qui ajoute un utilisateur du nom de machine$ ex: dn: uid=carless-reef$,ou=people,o=iut,dc=stlo,dc=unicaen,dc=fr objectclass: posixaccount objectclass: inetorgperson objectclass: top uid: carless-reef$ cn: carless-reef$