Chapitre 32 : Authentification des comptes utilisateurs

(1)

Authentification des comptes utilisateurs

Chapitre 32 : Authentification des comptes utilisateurs

Un compte utilisateur :

– définition de son identification pour le système – définition d’un environnement utilisateur Opérations possibles :

– création – modifications – destruction

Formation permanente – ARS 1

Authentification des comptes utilisateurs Le fichier /etc/passwd

§ 32.1 Le fichier /etc/passwd

Il contient les informations sur les identifications des utilisateurs.

Exemple :

root:U/oeCQo.cmnyc:0:1:Operator:/root:/bin/csh nobody:*:65534:65534::/:

daemon:*:1:1::/:

sys:*:2:2::/:/bin/csh bin:*:3:3::/bin:

besancon:vSHntkfqz8MEk:4332:1000::/users/adm/besancon:/bin/bash ...

(2)

Authentification des comptes utilisateurs Format du fichier/etc/passwd,<pwd.h>

§ 32.2 Format du fichier /etc/passwd , <pwd.h>

Le format est composé de 7 champs séparés par le caractére : :

login : mot de passe : UID : GID : gecos : homedir : shell

Pour la définition exacte sur sa machine, se reporter à

<pwd.h>

.

Par exemple sur Linux :

/* The passwd structure. */

struct passwd {

char *pw_name; /* Username. */

char *pw_passwd; /* Password. */

__uid_t pw_uid; /* User ID. */

__gid_t pw_gid; /* Group ID. */

char *pw_gecos; /* Real name. */

char *pw_dir; /* Home directory. */

char *pw_shell; /* Shell program. */

};

– champ 1 : login

Nom sous lequel un ordinateur connait un individu.

8 caractères en général. Pour plus, vérifier

Sur Linux, on peut avoir des noms plus longs que 8.

Conseils : pas de majuscules, éviter les caractères accentués.

– champ 2 : mot de passe

Mot de passe de l’utilisateur stocké sous forme chiffrée non déchiffrable.

Nécessité d’éduquer les utilisateurs pour choisir un bon mot de passe.

Les logiciels de crack de mots de passe ne déchiffrent pas les mots de passe : ils font des essais à base de dictionnaires.

crack

:ftp://ftp.lip6.fr/pub/unix/security/crack5.0.tar.gz

john

: ftp://ftp.false.com/pub/security/john/john-1.6.tar.gz

(3)

– champ 3 : UID

Identificateur numérique compris entre 0 et 32767 (short int a priori).

Sur Linux, c’est un

__uid_t

, un unsigned int.

Cette valeur doit être unique au sein des utilisateurs.

– champ 4 : GID

Identificateur numérique compris entre 0 et 32767 (short int a priori).

__gid_t

, un unsigned int.

Cette valeur doit être unique au sein des groupes.

% ls -ln

-rw-r--r-- 1 4332 1000 5544 Sep 15 22:47 cours.dvi -rw-r--r-- 1 4332 1000 940 Sep 15 22:27 cours.tex

% ls -l

-rw-r--r-- 1 besancon software 5928 Sep 15 22:49 cours.dvi -rw-r--r-- 1 besancon software 940 Sep 15 22:27 cours.tex

– champ 5 : gecos

Identité en clair de l’utilisateur.

Les systèmes BSD y ont stockés d’autres informations comme le numéro de téléphone, le numéro de bureau etc.

La commande chfn (change finger) permet de modifier ce champs.

– champ 6 : homedir Répertoire par défaut.

– champ 7 : shell Shell par défaut.

Si le champ est vide, on prend

/bin/sh

par défaut.

Le shell déterminera les fichiers de configuration à installer chez l’utilisateur.

La commande chsh (change shell) permet de choisir parmi les shells mentionnés dans

/etc/shells

.

(4)

Quelques conseils :

– Il faut toujours trier les lignes de

/etc/passwd

selon l’ordre numérique des UID :

# sort -t : +2n -3 /etc/passwd

– Il ne faut jamais laisser de comptes sans mot de passe.

Authentification des comptes utilisateurs Chiffrement des mots de passe,crypt()

§ 32.3 Chiffrement des mots de passe, crypt()

Les mots de passe sont stockés sur une forme chiffrée, mathématiquement non réversible.

Algorithme de chiffrement : DES, standard fédéral de l’administration américaine Ce chiffrement non réversible est dit hashing (le mot de passe chiffré est dit hashed ).

Disponible sur Unix via la fonction C

crypt()

: – premier paramètre : la chaine à chiffrer

– second paramètre : la graine (dite salt en anglais) composée de 2 caractères – résultat renvoyé : une chaine dont les 2 premiers caractères reprennent le salt

Ainsi

crypt("QWERTY", "NU")

renvoit

NUMVcLVD/dM12

(5)

Authentification des comptes utilisateurs Chiffrement des mots de passe,crypt()

Exemple de programme C complet :

#include<stdio.h>

main(int argc, char *argv[]) {

printf("=> %s\n", crypt(getpass("Chaine a chiffrer :"), argv[1]));

}

Une fois compilé, le programme montre :

% ./textCRYPT NU

Chaine a chiffrer : XXXXXXXX <-- QWERTY pour l’exemple

=> NUMVcLVD/dM12

Authentification des comptes utilisateurs Cycle du mot de passe et commandepasswd

§ 32.4 Cycle du mot de passe et commande passwd

La commande pour changer de mot de passe d’un utilisateur dans

/etc/passwd

est

passwd

. Elle appelle

crypt()

avec un nouveau salt tiré au hasard et avec le nouveau mot de passe entré.

passwd crypt()

randomseed or "salt"

serveur

/etc/passwd (/etc/shadow) hashed

password

(6)

Comportement lorsqu’un utilisateur change un mot de passe

% passwd

passwd: Changing password for besancon Enter login password: XXXXXXXX

New password: ZZZZZZZZ

Re-enter new password: ZZZZZZZZ

passwd (SYSTEM): passwd successfully changed for besancon

On tache de vérifier l’identité de la personne en demandant le mot de passe initial.

Comportement lorsque l’administrateur

root

change un mot de passe

# passwd besancon

New password: XXXXXXXX

Re-enter new password: ZZZZZZZZ

passwd (SYSTEM): passwd successfully changed for besancon

Root n’a jamais besoin de connaître le mot de passe d’un utilisateur pour en changer le mot de passe.

Lorsqu’un utilisateur a perdu son mot de passe :

– root ne peut pas déchiffrer la chaine chiffrée dans

/etc/passwd

– root peut changer le mot de passe par

passwd groslourd

(7)

Authentification des comptes utilisateurs Cycle du mot de passe et commandepasswd La commande

passwd

peut comporter plus ou moins de règles de vérification de la sûreté du mot de passe :

% passwd besancon

Enter login password: XXXXXXXX

New password: XXXXXXXX <-- on entre exprès le même mot de passe passwd(SYSTEM): Passwords must differ by at least 3 positions

New password: YYYYYYYY <-- mélange de lettres minuscules et majuscules passwd(SYSTEM): The first 6 characters of the password

must contain at least two alphabetic characters and at least one numeric or special character.

passwd(SYSTEM): Too many failures - try later.

Permission denied

Authentification des comptes utilisateurs Cycle du mot de passe et commandelogin

§ 32.5 Cycle du mot de passe et commande login

La commande lancée par le système pour se connecter est la commande

login

.

Elle va devoir vérifier si les mots de passe entré et stocké sont identiques, sachant que le mot de passe est stocké sous une forme hashée.

login

serveur

/etc/passwd (ou /etc/shadow) 1. L’utilisateur entre

login et mot de passe

4. crypt() des données entrées

2. On recupère la structure pwd de l’utilisateur

3. On extrait le salt

5. On extrait le passwd

6. Comparaison hash stocké et hash calculé

7a. comparaison OK : connexion acceptée

(8)

Authentification des comptes utilisateurs Cycle du mot de passe et commandelogin

Si le mot de passe hashé est

saeLydiaFuF5o

, on réalisera donc au login la comparaison C :

strcmp("saeLydiaFuF5o", crypt("XXXXXXXX", "sa"))

avec

XXXXXXXX

le mot de passe en clair.

Authentification des comptes utilisateurs Shadow Passwords,/etc/shadow,<shadow.h>

§ 32.6 Shadow Passwords, /etc/shadow , <shadow.h>

L’idée part de la constatation que, si beaucoup de programmes accèdent au contenu de

/etc/passwd

pour les informations concernant UID, homedir, shell, peu en revanche l’accèdent pour le mot de passe.

On supprime donc le mot de passe chiffré du fichier pour le stocker dans un fichier à accès plus restreints.

-rw-r--r-- root wheel 10557 Sep 15 22:51 /etc/passwd

-rw--- root wheel 13318 Sep 15 22:50 /etc/master.passwd

L’ancien mot de passe chiffré est remplacé par exemple par un caractère comme

*

ou

x

: besancon:x:4332:1000::/users/adm/besancon:/bin/bash

(9)

Plusieurs formats de fichiers shadow sont utilisés par les constructeurs qui ne se sont pas mis d’accord.

Linux

Fichiers

/etc/passwd

et

/etc/shadow

# cat /etc/passwd

root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:

daemon:x:2:2:daemon:/sbin:

adm:x:3:4:adm:/var/adm:

...

# cat /etc/shadow

root:fUQZjKzpwayTc:11237:0:99999:7:-1:-1:134540316 bin:*:11237:0:99999:7:::

daemon:*:11237:0:99999:7:::

adm:*:11237:0:99999:7:::

...

Solaris Fichiers

/etc/passwd

et

/etc/shadow

# cat /etc/passwd

root:x:0:1:Super-User:/:/sbin/sh daemon:x:1:1::/:

bin:x:2:2::/usr/bin:

...

boumaiza:x:1001:1000:Lyazid Boumaiza:/net/serveur/home/ars/boumaiza:/bin/tcsh corsini:x:1002:1000:Franck Corsini:/net/serveur/home/ars/corsini:/bin/tcsh ...

# cat /etc/shadow

root:y8fPbbq414TBU:6445::::::

daemon:NP:6445::::::

bin:NP:6445::::::

...

boumaiza:aalJCbuvX/xEM:11255::::::

corsini:5Ag56r/M.KD9A:10912::::::

...

(10)

Authentification des comptes utilisateurs Le fichier/etc/group,<grp.h>

§ 32.7 Le fichier /etc/group , <grp.h>

Le format est composé de 4 champs séparés par le caractére : :

group : mot de passe : GID : membres

Pour la définition exacte sur sa machine, se reporter à

<grp.h>

. Par exemple, sur une machine Linux :

/* The group structure. */

struct group {

char *gr_name; /* Group name. */

char *gr_passwd; /* Password. */

__gid_t gr_gid; /* Group ID. */

char **gr_mem; /* Member list. */

};

Authentification des comptes utilisateurs Le fichier/etc/group,<grp.h>

– champ 1 : group

Nom du groupe apparaissant par

ls -lg

. – champ 2 : mot de passe

Mot de passe du groupe.

– champ 3 : GID

Identificateur numérique compris entre 0 et 32767.

__gid_t

, un unsigned int.

Cette valeur doit être unique au sein des groupes.

– champ 4 : membres

Liste de noms de login séparés par des virgules.

(11)

Authentification des comptes utilisateurs Création d’un nouveau compte

§ 32.8 Création d’un nouveau compte

Action mécanique automatisable.

Selon le système, elle est déjà automatisée sous la forme d’une commande d’administration :

Système Program

AIX

smit

HP-UX

sam

Solaris

admintool

FreeBSD

adduser

etc.

Authentification des comptes utilisateurs Création d’un nouveau compte Exemple d’interface graphique de création de compte :

Problème : comment créer 3000 comptes en une après-midi avec cette interface ? Problème : comment personnaliser cette interface ?

(12)

Authentification des comptes utilisateurs Création d’un nouveau compte Actions schématiques à accomplir lors de la création d’un compte :

1. choix de l’UID et du GID en fonction du service d’appartenance de la personne 2. choix du homedir (en fonction du service ?)

3. choix du nom de login selon la politique locale 4. choix du shell de login

5. incorporation de ces informations dans la base de données des comptes (

/etc/passwd

ou NIS selon la politique du service) ;

*

comme mot de passe par défaut

Authentification des comptes utilisateurs Création d’un nouveau compte

6. ajout de l’utilisateur dans

/etc/group

7. création du homedir

8. copie des fichiers de configuration de l’environnement (

.profile

,

.cshrc

,

.xsession

etc.)

9. attribuer le homedir créé à l’utilisateur par chown + chgrp 10. initialisation du mot de passe si l’utilisateur est présent

L’étape délicate dans une automatisation de création de compte est bien sûr l’incorporation d’une nouvelle ligne dans la base de données.

(13)

Authentification des comptes utilisateurs Compte root

§ 32.9 Compte root

Sa particularité vient de son UID == 0.

Quelques règles :

1. L’utilisateur

root

n’a pas

.

dans son

PATH

(précédence de la commande locale par rapport à la commande système).

2. L’utilisateur

root

a 022 pour

umask

(accessibilité indispensable de certains fichiers par les utilisateurs normaux).

3. Eviter d’avoir

/

comme homedir pour

root

(pollution de

/

par les fichiers de configuration en

.foorc).

Authentification des comptes utilisateurs Comptes fictifs

§ 32.10 Comptes fictifs

Exemple de Linux :

root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:

daemon:x:2:2:daemon:/sbin:

adm:x:3:4:adm:/var/adm:

lp:x:4:7:lp:/var/spool/lpd:

sync:x:5:0:sync:/sbin:/bin/sync

shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt

mail:x:8:12:mail:/var/spool/mail:

news:x:9:13:news:/var/spool/news:

uucp:x:10:14:uucp:/var/spool/uucp:

operator:x:11:0:operator:/root:

games:x:12:100:games:/usr/games:

gopher:x:13:30:gopher:/usr/lib/gopher-data:

ftp:x:14:50:FTP User:/home/ftp:

nobody:x:99:99:Nobody:/:

xfs:x:43:43:X Font Server:/etc/X11/fs:/bin/false ...

(14)

Authentification des comptes utilisateurs Comptes fictifs Ces utilisateurs fictifs sont essentiellement des propriétaires de fichiers.

Par exemple bin est le propriétaire de la plupart des exécutables :

-rwxr-xr-x 1 bin bin 40960 Aug 9 1994 stty*

-rws--x--x 1 root bin 24576 Aug 9 1994 su*

-rwxr-xr-x 1 bin bin 24576 Aug 9 1994 sum*

A noter l’emploi du bit s sur la commande

su

.son exécution se fait au nom du propriétaire du fichier, ici root.

Authentification des comptes utilisateurs Commandesid,groups

§ 32.11 Commandes id , groups

La commande

id

renvoit votre UID et vos GID, primaire et secondaires :

% id

uid=1000(besancon) gid=4(adm) groups=4(adm),0(root),3(sys),\

12(daemon),1000(sae3),1002(www)

La commande

groups

renvoit vos GID d’appartenance :

% groups

adm root sys daemon sae3 www

(15)

Authentification des comptes utilisateurs Commandesu

§ 32.12 Commande su

La commande

su

permet de changer d’identité :

su [-] utilisateur2

Vérification par demande du mot de passe de l’utilisateur destination.

Pour hériter complètement de l’identité, utiliser l’option "-" de la commande "su".

Quand on se trompe sur le mot de passe :

% id

uid=4332(besancon) gid=1000(software) groups=1000(software)

% su besancon Password:

Sorry

Quand on donne le bon mot de passe :

% id

% su beurnez Password:

% id

uid=8520(beurnez) gid=8506(lps-06) groups=8506(lps-06)

(16)

Pour devenir root, la commande est donc simplement :

% su root

ce qui peut se simplifier encore en :

% su

Pour hériter complètement de l’identité, utiliser l’option "-" de la commande "su".

Exemple de transmission de données parasites de la premiére identité à la seconde identité :

% id

% pwd

/users/adm/besancon

% su beurnez

% id

% pwd

/users/adm/besancon

% printenv ...

MAIL=/var/mail/besancon ...

Certaines variables d’environnement font encore référence à l’identité de départ !

(17)

Exemple de non transmission de données parasites de la première identité à la seconde identité :

% id

% pwd

/users/adm/besancon

% su - beurnez

% id

% pwd

/users/stat/beurnez

% printenv ...

MAIL=/var/mail/beurnez ...

Les variables d’environnement font référence maintenant au second utilisateur exclusivement.

Authentification des comptes utilisateurs Deviner des mots de passe

§ 32.13 Deviner des mots de passe

L’algorithme DES sert à hasher les mots de passe.

Si l’on a accès au contenu de

/etc/shadow

(ou

/etc/passwd

en mode non protégé), on peut utiliser certains outils pour vérifier la complexité des mots de passe en appliquant des dictionnaires et des règles d’applications :

– John the ripper, disponible à

http://www.openwall.com/john/

– Crack, disponible à

http://www.users.dircon.co.uk/~crypto/

(18)

NIS

Chapitre 33 : NIS

NISNetwork Information Service – Créé par SUN en 1985

– Anciennement Yellow Pagescertaines commandes ont un nom en "yp. . ."

– Version NIS+ vers 1992, radicalement différente (cf annexe)

C’est un protocole réseau d’accès à des informations centralisées sur un ou plusieurs serveurs redondants.

Utilisation la plus courante : partager la base des comptes Unix.

NIS Architecture de NIS

§ 33.1 Architecture de NIS

Architecture construite en mode client / serveur :

Client 1 Client 2 Client 3 Client 4

D A T A

D A T A Maitre

Esclave 1 Esclave 2

Mise a jour push / pull

(19)

NIS Architecture de NIS

Caractéristiques :

– Communications réseau via RPC (Remote Procedure Call)

– Propagation des données (maps) du master server aux slave servers en mode pull ou en mode push.

– Propagation des maps complètes

– Seul le master server peut modifier les données

– Les slave servers diffusent les données sans pouvoir les modifier

NIS Données NIS : maps NIS, DBM,ypcat,ypmatch

§ 33.2 Données NIS : maps NIS, DBM, ypcat , ypmatch

Les données manipulées par NIS : maps Les maps contiennent des couples (clef, valeur).

Il n’y a que le serveur NIS maître qui peut changer le contenu d’une map.

Une map est au format DBM (cf man dbm) ; une map se compose de 3 fichiers : – le fichier source

– le fichier de suffixe

.pag

– le fichier de suffixe

.dir

(20)

La commande

makedbm

permet de convertir le fichier source en les 2 fichiers constituant le DBM.

% cat demo clef1 banane clef2 arbre

% makedbm demo demo

% ls -l demo test*

-rw-r--r-- 1 besancon adm 23 Aug 15 11:56 demo -rw--- 1 besancon adm 0 Aug 15 11:57 demo.dir -rw--- 1 besancon adm 1024 Aug 15 11:57 demo.pag Dans le système NIS, les maps sont stockées sur le master server dans

/var/yp/nom-du-domaine-NIS

:

% cd /var/yp/nom-de-domaine-NIS

% ls -l passwd*

-rw--- 1 root other 4096 Nov 23 07:26 passwd.byname.dir -rw--- 1 root other 8192 Nov 23 07:26 passwd.byname.pag -rw--- 1 root other 4096 Nov 23 07:26 passwd.byuid.dir -rw--- 1 root other 8192 Nov 23 07:26 passwd.byuid.pag

Les maps sont construites automatiquement à partir de tous les fichiers sources des maps :

/etc/hosts

/etc/passwd

makedbm

passwd.byname

passwd.byuid

hosts.byname

hosts.byuid

NIS MASTER

Le fichier

/var/yp/Makefile

automatise toutes les créations de maps et leur propagation aux slave servers (mode push).

(21)

NIS Données NIS : maps NIS, DBM,ypcat,ypmatch Extrait de

/var/yp/Makefile

:

...

hosts.time: $(DIR)/hosts

@($(MULTI) $(B) -l $(DIR)/hosts);

@($(STDHOSTS) $(DIR)/hosts $(CHKPIPE))| \

(awk ’BEGIN { OFS="\t"; } $$1 !~ /^#/ { print $$1, $$0 }’ $(CHKPIPE)) | \

$(MAKEDBM) $(B) - $(YPDBDIR)/$(DOM)/hosts.byaddr;

@touch hosts.time;

@echo "updated hosts";

@if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) hosts.byname; fi

@if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) hosts.byaddr; fi

@if [ ! $(NOPUSH) ]; then echo "pushed hosts"; fi ...

La construction d’une map se résume alors à (par exemple suite à une modification de

/etc/hosts

) :

# vi /etc/hosts

# cd /var/yp

# make hosts updated hosts

pushed hosts

La librairie DBM permet de créer des enregistrements de taille maximale 1024 octets :

% man dbm

SunOS/BSD Compatibility Library Functions dbm(3B) NAME

dbm, dbminit, dbmclose, fetch, store, delete, firstkey, nextkey - data base subroutines

...

The sum of the sizes of a key/content pair must not exceed the internal block size (currently 1024 bytes). Moreover all key/content pairs that hash together must fit on a single block. store will return an error in the event that a disk block fills with inseparable data.

(22)

NIS Données NIS : maps NIS, DBM,ypcat,ypmatch Quelques noms de maps :passwd.byname,passwd.byuid,group.byname,group.bygid,

publickey.byname,hosts.byaddr,hosts.byname,mail.byaddr,mail.aliases,

services.byname,services.byservicename,rpc.bynumber,rpc.byname,

protocols.bynumber,protocols.byname,networks.byaddr,networks.byname,

netmasks.bymask,netmasks.byaddr,ethers.byname,ethers.byaddr,bootparams,

auto.master,auto.home,auto.direct,auto.src dont les plus utiles sont : – map

passwd

– map

group

– map

hosts

– map

netgroup

La commande

ypcat

permet de consulter une map NIS depuis n’importe quel client.

Syntaxe :

ypcat map-NIS

La commande

ypmatch

permet de consulter la valeur d’une ou plusieurs clefs dans une certaine map NIS depuis n’importe quel client.

Syntaxe :

ypmap clef1 clef2... map-NIS

(23)

NIS Client NIS,domainname,ypbind,ypwhich,ypset

§ 33.3 Client NIS, domainname , ypbind , ypwhich , ypset

Un client NIS doit se connecter à un serveur NIS. C’est l’action de binding.

Le binding nécessite :

– de fournir un nom de domaine NIS, le domainname ;

une machine se déclare comme membre du groupe servi par les serveurs NIS – de préciser la méthode de localisation du serveur NIS : broadcast ou explicite

Nom de domaine

La commande activant le nom de domaine est domainname.

Pour consulter le nom de domaine :

domainname

Pour configurer manuellement le nom de domaine :

domainname nom-du-domaine-NIS

Configuration du domainname automatique au démarrage : – Sur Solaris : renseigner le fichier

/etc/defaultdomain

– Sur Linux : renseigner le fichier

/etc/sysconfig/network

NETWORKING=yes FORWARD_IPV4=false

HOSTNAME=pcars6.formation.jussieu.fr DOMAINNAME=formation.jussieu.fr GATEWAY=134.157.253.126

GATEWAYDEV=eth0 NISDOMAIN=real.world

(24)

Réalisation du binding

Un client NIS fait tourner le démon

ypbind

qui se connecte à un serveur NIS que l’on trouve selon 2 méthodes possibles :

– découverte par broadcast ; c’est le mode par défaut.

Sur Solaris,

/usr/lib/netsvc/yp/ypbind -broadcast

En pratique il y a une map

ypservers

qui contient les noms des serveurs.

Cf

/var/yp/binding/nom-de-domaine-NIS/ypservers

– demande de connexion explicite Sur Solaris faire :

# ypbind -ypsetme

# ypset nom-du-serveur-NIS-voulu

La commande

ypwhich

affiche le nom du serveur NIS utilisé.

On peut controler un peu quels sont les clients qui se bindent aux servers.

Pour cela, remplir sur les slave servers et sur le master server le fichier

/var/yp/securenets

. Il liste les machines autorisées, sous forme adresses et netmasks.

Par exemple :

159.169.0.0 255.255.0.0 129.187.135.0 255.255.255.0

Signification : seules les machines des réseaux

159.169.0.0/16

et

129.187.135.0/24

sont autorisées à se binder.

(25)

Consultation des maps

Un client NIS doit indiquer quels maps il utilisera. La plus courante est la map

passwd

dont on indique l’utilisation par l’ajout d’une ligne en fin de fichier

/etc/passwd

:

+::65534:65534:::

Signification de cette ligne supplémentaire (à vérifier sur chaque système car il existe des différences) :

Tout champ renseigné de cette ligne + remplace le même champ de la map inconditionnellement sauf pour UID et GID.

Pour UID et GID, les valeurs mentionnées s’activeront si ces champs sont absents de la map (c’est-à-dire quand la map est vérolée ce qui indique un problème de fichier source vérolé).

Exemple :

+:*LK*:65534:65534:::/usr/local/bin/tcsh Signification :

– le passwd chiffré des utilisateurs de la map passwd est

LK

– l’UID sera 65534 si l’entrée de la map ne précise pas d’UID – le GID sera 65534 si l’entrée de la map ne précise pas de GID

– le shell de login est mis automatiquement à

/usr/local/bin/tcsh

(26)

NIS Slave server NIS,ypserv,ypxfr

§ 33.4 Slave server NIS, ypserv , ypxfr

Un serveur NIS esclave fait tourner plusieurs démons : – ypserv

– ypbind

Le démon

ypserv

est là pour répondre aux requêtes des client NIS qui se sont bindés sur lui.

Le démon

ypbind

n’est là que pour faire du slave server un client NIS aussi (mais ce n’est pas obligatoire).

Il n’est pas garanti que le slave server soit client NIS de lui même. Il peut se binder sur un autre serveur NIS du même domaine.

NIS Slave server NIS,ypserv,ypxfr

Un slave server peut être down au moment où un master slave fait un push des maps.

besoin pour le slave server de se resynchroniser avec le master server ; pull des maps de la part du slave server

Cela se fait au moyen de shell scripts lancés périodiquement via la crontab : 30 * * * * /usr/lib/netsvc/yp/ypxfr_1perhour

31 1,13 * * * /usr/lib/netsvc/yp/ypxfr_2perday 32 1 * * * /usr/lib/netsvc/yp/ypxfr_1perday

Ces scripts récupérent plus ou moins de maps suivant la fréquence de leur lancement.

Exemple de l’un de ces shell scripts,

ypxfr_1perhour

:

#! /bin/sh

# ypxfr_1perhour.sh - Do hourly NIS map check/updates PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH

export PATH

ypxfr passwd.byname ypxfr passwd.byuid

(27)

NIS Master server NIS,ypxfrd,rpc.yppasswdd,yppasswd

§ 33.5 Master server NIS, ypxfrd , rpc.yppasswdd , yppasswd

Un serveur NIS maître fait tourner plusieurs démons : – ypserv

– ypbind – ypxfrd

– rpc.yppasswdd

Même rôle pour

ypserv

que pour un slave server.

Même rôle pour

ypbind

que pour un slave server.

Le démon

ypxfrd

assure les transferts de maps demandés par les slave servers (mode pull).(en Unix, on rencontre souvent le mot xfr pour transfert)

Le démon

rpc.yppasswdd

assure le changement des mots de passe.

Avec NIS, un client NIS ne peut pas modifier le contenu d’une map.

Pour changer un mot de passe, on va émuler le changement du mot de passe sur le master server dans son fichier source (

/etc/passwd

) puis la reconstruction de la map passwd et sa

transmission en totalité aux slave servers.

Ce processus se réalise en utilisant la commande yppasswd qui demande les mots de passe à l’utilisateur puis appelle rpc.yppasswdd sur le master server qui simule la session interactive composée des commandes :

# passwd

# cd /var/yp

# make passwd

(28)

Sur un client NIS Linux :

% yppasswd

Changing NIS account information for besancon on serveur.

Please enter old password: ********

Changing NIS password for besancon on serveur.

Please enter new password: ********

Please retype new password: ********

The NIS password has been changed on serveur.

Sur un master server NIS Solaris :

% yppasswd

Enter login(NIS) password: ********

New password: ********

Re-enter new password: ********

NIS passwd/attributes changed on serveur

NIS Netgroups

§ 33.6 Netgroups

Le système NIS permet de définir des groupes d’autorisation d’accès : les netgroups. Ces groupes sont diffusés via la map netgroup.

Un netgroup est un nom symbolique associé à un ensemble de triplets (je n’ai jamais vu le troisième champ avoir une quelconque utilité en pratique) :

nom-de-netgroup \

(machine, utilisateur, nom-de-domaine-NIS) \ (machine, utilisateur, nom-de-domaine-NIS) \ ...

On définit en pratique des netgroups concernant des machines et des netgroups concernant des utilisateurs. On autorisera ainsi ou pas des groupes d’utilisateurs ou de machines à accéder à certaines ressources.

(29)

NIS Netgroups

Exemple de netgroup de machines : nains \

(atchoum.phys.ens.fr,,physique) \ (dormeur.phys.ens.fr,,physique) \ (joyeux.phys.ens.fr,,physique) \ (grincheux.phys.ens.fr,,physique) \ (prof.phys.ens.fr,,physique) \ (timide.phys.ens.fr,,physique) \ (simplet.phys.ens.fr,,physique)

Exemple de netgroup d’utilisateurs : etudiants \

(,jean,) \ (,pierre,) \ (,valerie,)

NIS Netgroups

Exemple d’utilisation d’un netgroup d’utilisateurs au niveau de

/etc/passwd

: field:PASSWORD HERE:0:1:Field Service:/usr/field:/bin/csh operator:PASSWORD HERE:5:28:Operator:/opr:/opr/opser sys:PASSWORD HERE:2:3:Mr Kernel:/usr/sys:

bin:PASSWORD HERE:3:4:Mr Binary:/bin:

pot:*:16:16:MenuPot:/users/staffs/pot:

-@etudiants:

+@net_administrateurs::0:0:::

+@net_utilisateurs::65534:65534:::/bin/noshell Signification :

– On rejette les lignes de la map

passwd

dont le login est indiqué dans le netgroup

etudiants

– On accepte les lignes de la map

passwd

net_administrateurs

– On accepte les lignes de la map

passwd

net_utilisateurs

(30)

NIS Netgroups Exemple d’utilisation d’un netgroup de machines au niveau de l’exportation de disques via NFS (fichier

/etc/exports

, cf chapitre sur NFS) :

/usr/openwin -access=nains

NIS Installation de NIS

§ 33.7 Installation de NIS

Master server Lancer

ypinit -m

Slave servers

Lancer

ypinit -s master-server

Ajouter dans la crontab les appels aux scripts

ypxfr_*

Client NIS

Spécifier le domainname

(31)

NIS+

Chapitre 34 : NIS+

Cf annexe pour un document sur NIS+.

Nous n’évoquerons ici que les défauts de NIS ayant conduit à l’apparition de son successeur, NIS+.

Le système NIS+ n’a pas connu de succès et il est maintenant officiellement abandonné au profit de LDAP par son principal défenseur, SUN.

Principaux reproches à NIS :

– pas d’authentification du client aux serveurs NIS ; connaitre le domainname suffit à se binder – les maps sont transmises en totalité même en cas de faible modification de leurs contenus – inadaption du principe du domaine NIS dans le cas de structures WAN

– mode broadcast

(32)

LDAP

Chapitre 35 : LDAP

§ 35.1 Problématique

Cas de l’université de Paris 4 :

– base Microsoft Excel du personnel administratif – base Microsoft Access du personnel enseignant

– base

/etc/passwd

des comptes email des utilisateurs – base mysql des 2 catégories de personnel

– prochainement logiciel à base d’Oracle – prochainement Microsoft Active Directory

Date XYZ : envoyer un email à tous les personnels administratifs sachant que le service du personnel ne fournira qu’une liste avec nom et prénom. Comment l’ingénieur système fait-il ?

Date XYZ2 : envoyer un email à tous les personnels administratifs sauf ceux du site de Clignancourt, sachant que le service du personnel ne peut pas fournir de liste cette fois-ci. Comment l’ingénieur système fait-il ?

LDAP Principe d’annuaire

§ 35.2 Principe d’annuaire

Un annuaire informatique est un service permettant d’accéder à des informations, relatives à des personnes ou à diverses ressources de façon organisée.

Objectif : maintenir de façon cohérente et contrôlée les archipels de données et obtenir des données de référence.

Un annuaire n’est pas une base de données relationnelles.

Une base de données (SGBD) se caractérise par :

– Le schéma des données est défini à 100% pour résoudre un certain problème.

– Les applications connaissent explicitement le schéma des données.

– Les objets sont complexes et éclatés entre plusieurs tables liées par des relations complexes.

– Un SGBD supporte les transactions.

– Un SGBD supporte un langage comme SQL qui permet des fonctions d’interrogation et de mises à jour très complexes.

– Un SGBD centralise les données pour éviter les problèmes de synchronisation de données et de qualité des temps de réponse.

(33)

LDAP Principe d’annuaire Un annuaire se caractérise par :

– Les objets sont indépendants (pas de liens de dépendance entre eux).

– Les objets peuvent être distribué sur plusieurs annuaires pour assurer une meilleure disponibilité.

– Le schéma est standardisé pour pouvoir partager les données.

– Le schéma est extensible pour prendre en compte tous les besoins mais cela est fait de façon compatible avec les standards.

– Les applications d’annuaire ignorent la structure interne des données.

– Un annuaire est principalement consulté en lecture et est optimisé pour cela.

LDAP Annuaire LDAP

§ 35.3 Annuaire LDAP

LDAPLightweight Directory Access Protocol Héritier de l’annuaire ISO X500.

Version 3 actuellement. RFC 2251 à 2256, RFC 2829 à 2830, RFC 2849.

Il n’y a pas de standard de représentation des contrôles d’accès aux données.

LDAP :

– nom d’un protocole

– nom d’une structure de données

– nom d’implémentations de serveurs suivant le protocole Confusion possible. . .

(34)

LDAP Modèle de données de LDAP : DIT, suffixe

§ 35.4 Modèle de données de LDAP : DIT, suffixe

Les entrées sont organisées sous forme d’arbre ou DIT (Directory Information Tree).

L’une des difficultés de LDAP : construire l’organisation du DIT. De quoi est-il le reflet ?

DIT à caractère organisationnel ?

dc=company,dc=com

dc=marketing dc=finance

dc=recherche

dc=people

dc=groups

dc=people

dc=groups

dc=people

dc=groups

DIT à caractère géographique ?

dc=people

dc=groups

dc=people

dc=groups

dc=people

dc=groups

dc=america dc=europe dc=asia

Pas de solution universelle.

(35)

LDAP Modèle de données de LDAP : DIT, suffixe La racine de l’arbre est uniquement conceptuelle et n’existe pas réellement. C’est le suffixe qui sert à déterminer les adresses absolues des objets (comme

/

pour l’arborescence des fichiers Unix).

dc=marketing dc=finance

dc=recherche

dc=people

dc=groups

dc=people

dc=groups

dc=people

dc=groups

SUFFIXE

Le suffixe peut avoir plusieurs formes : – forme 1 :

o=company.com

– forme 2 :

o=company,c=fr

– forme 3 :

dc=company,dc=com

On préférera la 3ième forme, ayant un certain rapport avec les noms de domaine DNS.

Exemple de DIT visualisé avec LdapBrowser disponible à l’URL

http://www.iit.edu/~gawojar/dap/

:

(36)

LDAP Modèle de données de LDAP : entrée, attributs, DN, URL

§ 35.5 Modèle de données de LDAP : entrée, attributs, DN, URL

DSEDirectory Service Entry

Les entrées dans le DIT (DSE) sont des agrégats d’attributs monovalués ou multivalués qui

permettent de stocker n’importe quel format de données (prénom, numéro de téléphone, image, son, etc.)

Les DSE sont stockées dans le DIT et arrangés selon leur identifiant unique, le DN (Distinguished Name). Un DN est la concaténation d’un RDN (Relative DN) et du DN des parents. Un DN s’apparente à une clef primaire.

suffixe : dc=company,dc=com

RDN : ou=Recherche

DN : ou=Recherche,dc=company,dc=com

RDN : uid=besancon

DN : uid=besancon,ou=Recherche,dc=company,dc=com

(le RDN doit être un des attributs/valeurs du DSE)

LDAP Modèle de données de LDAP : entrée, attributs, DN, URL

(37)

LDAP Modèle de données de LDAP : entrée, attributs, DN, URL Il existe des URL LDAP (RC 2255) qui prennent la forme :

ldap://serveur:389/DN

Par exemple dans communicator de netscape :

LDAP Modèle de données de LDAP : schéma, syntaxes, OID, objectclass

§ 35.6 Modèle de données de LDAP : schéma, syntaxes, OID, objectclass

Le schéma du DIT regroupe les définitions relatives aux types d’objets que peut contenir l’annuaire ou que l’on peut rechercher.

Le schéma contiendra des objets instanciations de classes LDAP, les définitions de ces classes et de leurs attributs, les syntaxes de ces attributs.

Tous ces éléments seront identifiés par des Object Identifiers dits OID.

attributetype ( 1.3.6.1.1.1.1.0 NAME ’uidNumber’

DESC ’An integer uniquely identifying a user in a domain’

EQUALITY integerMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

objectclass ( 1.3.6.1.1.1.2.0 NAME ’posixAccount’ SUP top AUXILIARY DESC ’Abstraction of an account with POSIX attributes’

MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) ) (1.3.6.1.1.1.1.0et1.3.6.1.4.1.1466.115.121.1.27sont des OIDS)

(38)

LDAP Modèle de données de LDAP : schéma, syntaxes, OID, objectclass Une syntaxe est un modèle de représentation des valeurs de l’attribut. Par exemple booléen, entier, binaire (pour une image, un son), etc.

L’attribut

objectclass

spécifie la liste des classes qu’instancie un DSE. Chaque classe va construire la structure du DSE en spécifiant une liste d’attributs obligatoirement présents (

MUST

dans l’objectclass) et une liste d’attributs facultatifs (

MAY

dans l’objectclass).

objectclass ( 2.16.840.1.113730.3.2.2

NAME ’inetOrgPerson’ DESC ’RFC2798: Internet Organizational Person’

SUP organizationalPerson STRUCTURAL MAY (

audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $

userSMIMECertificate $ userPKCS12 ) )

MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) )

l’attribut

uid

sera de type MUST.

LDAP Modèle de données de LDAP : schéma, syntaxes, OID, objectclass

Les objectclass de LDAP s’inscrivent dans un hiérarchie dont la racine est l’objectclass

top

. Chaque classe hérite d’une seule classe mère.

Chaque classe peut donner lieu à plusieurs sous classes.

(Abstract)

top

(Structural)

person

(Auxiliary)

companyPerson

(Structural)

residentialPerson

(Structural)

organizationalPerson

(39)

LDAP Protocole LDAP / Bind

§ 35.7 Protocole LDAP / Bind

Au niveau réseau : – LDAP : TCP port 389 – LDAP + SSL : TCP port 636

– ( syntaxe LDAP au format ASN.1 ) + BER

Un dialogue LDAP s’établit après une phase d’ouverture de session dite bind.

Le bind peut être anonyme ou authentifié.

LDAP Format de données LDIF

§ 35.8 Format de données LDIF

Problème : comment manipuler les objets LDAP en pratique ?

Réponse : en les manipulant au format LDAP Data Interexchange Format, dit LDIF

LDIF n’intervient pas dans le protocole LDAP (pas de mention dans les RFC par exemple).

LDIF n’est compris que par les utilitaires qui le convertissent en protocole LDAP.

(40)

LDAP Format de données LDIF Attention aux caractères non ASCII :

– si la valeur d’un attribut est uniquement composé de caractères ASCII, on l’écrit

attribut : valeur

– si la valeur d’un attribut contient des caractères non ASCII, il faut coder cette valeur en Base64 puis la coder en UTF-8 et écrire au final

attribut :: valeur2

Par exemple l’attribut

description

de valeur Université de Paris-Sorbonne, Paris 4 ne sera pas codé en LDIF sous la forme

description: Université de Paris-Sorbonne, Paris 4 mais sous la forme

description:: VW5pdmVyc2l0w6kgZGUgUGFyaXMtU29yYm9ubmUsIFBhcmlzIDQ=!

Notez les différences ! 2 utilitaires pratiques :

http://docs.univ-nancy2.fr/ldap/OutilsPERL/DecodLDIF.pl http://docs.univ-nancy2.fr/ldap/OutilsPERL/EncodLDIF.pl

LDAP Format de données LDIF

Exemple d’une DSE avec des caractères accentués non encore codés en LDIF : dn: ou=Personnel,dc=paris4,dc=sorbonne,dc=fr

objectclass: top

objectclass: organizationalUnit

ou: Personnels de l’Université de Paris-Sorbonne, Paris 4 businessCategory: academic research

telephoneNumber: +33 (0) 1 40 46 22 11

facsimileTelephoneNumber: +33 (0) 1 40 46 25 88 postOfficeBox: Université de Paris-Sorbonne, Paris 4 postalCode: F-75230

postalAddress: 1 rue Victor Cousin l: Paris, France

description: Université de Paris-Sorbonne, Paris 4 Exemple d’une DSE au format LDIF :

dn: ou=Personnel,dc=paris4,dc=sorbonne,dc=fr objectclass: top

objectclass: organizationalUnit

ou:: UGVyc29ubmVscyBkZSBsJ1VuaXZlcnNpdMOpIGRlIFBhcmlzLVNvcmJvbm5lLCBQYXJpcyA0 businessCategory: academic research

telephoneNumber: +33 (0) 1 40 46 22 11

facsimileTelephoneNumber: +33 (0) 1 40 46 25 88

postOfficeBox:: VW5pdmVyc2l0w6kgZGUgUGFyaXMtU29yYm9ubmUsIFBhcmlzIDQ=

postalCode: F-75230

postalAddress: 1 rue Victor Cousin l: Paris, France

(41)

LDAP Implémentations

§ 35.9 Implémentations

Il existe plusieurs implémentations de LDAP :

– OpenLdap,

http://ww.openldap.org

, version 2.1.3 (au 21 août 2002)

– Iplanet Directory (anciennement Netscape Directory Server, racheté par SUN), incorporé de base dans Solaris 8 et ultérieur

– Novell Directory Services, version 4 ?

Les différentes implémentations respectent les normes du protocole. Par contre, elles différent au niveau de tout ce qui n’est pas norme. En particulier, les droits d’accès aux données sont codés de façon incompatible.

LDAP OpenLDAP

§ 35.10 OpenLDAP

Cf

http://www.openldap.org/

Les versions 2.x.y d’OpenLDAP sont compatibles avec les normes de LDAP v3.

Le logiciel se compose de : – du serveur LDAP

slapd

– du serveur de synchronisation

slurpd

– d’utilitaires (

slapadd ldapsearch

,

ldapadd

,

ldapdelete

,

ldapmodify

,

ldappasswd

, etc.) – librairies, include LDAP

– un fichier de configuration

slapd.conf

dans lequel on définit le suffixe, le rootDN, le mot de passe du rootDN

(42)

LDAP OpenLDAP Le mécanisme de réplication de serveurs OpenLDAP est le suivant :

slurpd

1) demande de modification 2) réponse : referral

3) demande de modification

4) réponse (OK/not OK)

slapd

(Esclave)

slapd

(Maitre)

Journal des modifications client

5)

6) 7)

LDAP ObjectClassposixAccount,shadowAccount

§ 35.11 ObjectClass posixAccount , shadowAccount

Cf RFC2307

Cf le schéma

nis.schema

dans OpenLDAP.

L’objectclass

posixAccount

est l’objet qui implémente l’équivalent de la structure C de

<pwd.h>

:

MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) )

L’objectclass

shadowAccount

est l’objet qui implémente le principe des shadow passwds : objectclass ( 1.3.6.1.1.1.2.1 NAME ’shadowAccount’ SUP top AUXILIARY

DESC ’Additional attributes for shadow passwords’

MUST uid

MAY ( userPassword $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ description ) )

(43)

LDAP Un peu de bibliographie

§ 35.12 Un peu de bibliographie

– http://docs.univ-nancy2.fr/ldap/

– http://www.openldap.org/

– http://www.linux-france.org/article/serveur/ldap/

– http://www.unich.edu/~dirsvc/ldap/

– http://www.redbooks.ibm.com

– http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/LDAP.html – http://www.cru.fr/ldap/

– http://www.ldapcentral.com – http://www.rage.net/ldap/

– http://www.annuairesldap.com

(44)

Sélection de naming services,/etc/nsswitch.conf

Chapitre 36 : Sélection de naming services, /etc/nsswitch.conf

§ 36.1 Problématique

Exemple :

– il y a les fichiers système (

/etc/passwd

,

/etc/hosts

,

/etc/services

, . . .) – il y a le DNS

– il y a NIS – il y a NIS+

– il y a LDAP – etc.

Comment choisir quels services répondront aux requêtes de recherche de nom ?

Une solution : préciser quels naming services seront utilisés et dans quel ordre au niveau du fichier

/etc/nsswitch.conf

(naming service switch).

Sélection de naming services,/etc/nsswitch.conf Syntaxe de/etc/nsswitch.conf

§ 36.2 Syntaxe de /etc/nsswitch.conf

Le fichier est au format suivant :

service: source [ status=action status=sction... ] source...

avec :

– pour source l’un des mots clef

files

,

dns

,

ldap

,

nis

,

nisplus

,

xfn

(liste à vérifier selon les systèmes Unix offrant plus ou moins de ces services)

– pour status l’un des mots clef suivants : –

SUCCESS

, entrée recherchée trouvée –

NOTFOUND

, entrée recherchée non trouvée

–

UNAVAIL

, la source n’est pas configurée sur ce système ou bien elle est défaillante

–

TRYAGAIN

, la source est occupée et ne peut pas répondre actuellement, peut-être plus tard

(45)

Sélection de naming services,/etc/nsswitch.conf Syntaxe de/etc/nsswitch.conf – pour action l’un des mots clefs :

–

return

, retourner la valeur trouvée ou la non valeur –

continue

, essayer la source suivante

–

forever

(uniquement pour

TRYAGAIN

), persister sur cette source jusqu’à avoir une réponse

Par défaut, on a pour chaque source :

[SUCCESS=return NOTFOUND=continue UNAVAIL=continue TRYAGAIN=forever]

Sélection de naming services,/etc/nsswitch.conf Exemple de/etc/nsswitch.conf

§ 36.3 Exemple de /etc/nsswitch.conf

(pris sur SOLARIS)

passwd: files ldap group: files ldap

hosts: ldap [NOTFOUND=return] files ipnodes: files

networks: ldap [NOTFOUND=return] files protocols: ldap [NOTFOUND=return] files rpc: ldap [NOTFOUND=return] files ethers: ldap [NOTFOUND=return] files netmasks: ldap [NOTFOUND=return] files bootparams: ldap [NOTFOUND=return] files publickey: ldap [NOTFOUND=return] files netgroup: ldap

automount: files ldap aliases: files ldap

# for efficient getservbyname() avoid ldap services: files ldap

sendmailvars: files

# role-based access control auth_attr: files ldap exec_attr: files ldap prof_attr: files ldap user_attr: files ldap

# audit

audit_user: files ldap project: files ldap

(46)

Sélection de naming services,/etc/nsswitch.conf A propos de LDAP

§ 36.4 A propos de LDAP

Pour les systèmes n’incorporant pas LDAP en natif dans l’OS, se reporter à : –

http://www.padl.com/download/nss_ldap.tgz

–

http://www.openldap.org/

(47)

Pluggable Authentification Module, PAM

Chapitre 37 : Pluggable Authentification Module, PAM

§ 37.1 Problématique

Exemple :

– Soit une machine dans une université, hébergeant les comptes de 10 professeurs et de 1000 élèves.

– La machine est équipée d’un modem.

– Les professeurs sont autorisés à se connecter à la machine par modem, pas les élèves.

– La machine est cliente NIS.

– Quand on se connecte par modem sur une machine, le système lance la commande

login

lorsque la connexion s’établit.

Comment implémenter cela ?

En modifiant le programme

login

pour l’adapter à ce cas très particulier ? ? ?

Pluggable Authentification Module, PAM Problématique

La problématique en général :

Comment changer une méthode d’authentification dans un programme (par exemple FTP) sans avoir à tout reprogrammer ?

Une solution développée par SUN à l’origine et reprise et encouragée dans Linux : Pluggable Authentification Module dit PAM

(48)

Pluggable Authentification Module, PAM Principe de PAM

§ 37.2 Principe de PAM

L’authentication fait appel par l’intermédiaire de PAM à des modules externes de code

d’authentification appropriée selon le service. On déporte l’authentification en dehors du programme.

4 catégories de modules PAM :

– module d’authentification (authentication)

fonctionnalités pour authentifier un utilisateur et définir ses créances – module de gestion de compte (account management)

fonctionnalités pour déterminer si l’utilisateur dispose d’un compte valide (car possibilité d’expiration de mot de passe dit password aging, de restrictions d’accès horaire) – module de gestion de session (session management)

fonctionnalités pour définir et terminer les sessions utilisateur – module de gestion de mot de passe (password management)

fonctionnalités pour changer un mot de passe utilisateur et certaines caractéristiques du compte Pour une certaine application, on organise les modules nécessaires sous forme d’une pile et chaque module de la pile va être essayé pour constituer l’authentification demandée.

Selon la configuration, un utilisateur pourra être amené à rentrer plusieurs mots de passe.

Pluggable Authentification Module, PAM Fichier de configuration/etc/pam.conf

§ 37.3 Fichier de configuration /etc/pam.conf

/etc/pam.conf

définit quels modules seront utilisés pour chaque application.

(Sur Linux, on trouve aussi le répertoire/etc/pam.dqui contient un fichier par application portant le nom de l’application. Ainsi/etc/pam.d/loginpour le servicelogin.)

Une ligne de

/etc/pam.conf

contient 5 champs :

service_name module_type control_flag module_path options

– Le

service_name

nomme le service concerné par la ligne (

other

pour service joker) – Le

module_type

est l’un des 4 mots clef :

auth

,

account

,

session

,

password

– Le

control_flag

est l’un des 4 mots clef :

requisite

,

required

,

optional

,

sufficient

– Le

module_path

est le chemin du module.

– Les options dépendent du module.

(49)

Pluggable Authentification Module, PAM Fichier de configuration/etc/pam.conf

Par exemple, le service

login

fait appel aux modules suivants :

# Authentication management

login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_dial_auth.so.1

# Account management

login account requisite /usr/lib/security/pam_roles.so.1 login account required /usr/lib/security/pam_projects.so.1 login account required /usr/lib/security/pam_unix.so.1

# Session management

other session required /usr/lib/security/pam_unix.so.1

# Password management

other password required /usr/lib/security/pam_unix.so.1

Pluggable Authentification Module, PAM Directives d’essai des modules

§ 37.4 Directives d’essai des modules

Les directives possibles d’essai des modules sont : – directive

required

la valeur de retour de ce module doit être

PAM_SUCCESS

pour sortir de la pile d’authentification avec succès ;

PAM_AUTH_ERR

fera recommencer toute la pile

– directive

requisite

une valeur de retour

PAM_AUTH_ERR

fait sortir de la pile d’authentification prématurément en échec

– directive

optional

si ce module échoue, on sortira de la pile avec succès si un autre module dans la pile réussit – directive

sufficient

une valeur de retour

PAM_SUCCESS

de ce module fait sortir de la pile d’authentification prématurément avec succès ; les autres modules dans la pile ne sont pas pris en compte

(50)

Pluggable Authentification Module, PAM Modules,/usr/lib/security

§ 37.5 Modules, /usr/lib/security

Les modules sont conventionnellement stockés dans

/usr/lib/security/

Par exemple sur Solaris :

% ls /usr/lib/security

amiserv pam_ldap.so.1 pam_sample.so.1

pam_ami.so pam_projects.so pam_smartcard.so pam_ami.so.1 pam_projects.so.1 pam_smartcard.so.1 pam_dial_auth.so pam_rhosts_auth.so pam_unix.so

pam_dial_auth.so.1 pam_rhosts_auth.so.1 pam_unix.so.1

pam_krb5.so pam_roles.so sparcv9

pam_krb5.so.1 pam_roles.so.1 pam_ldap.so pam_sample.so

Chaque module fournit l’implémentation d’un mécanisme spécifique.

Pluggable Authentification Module, PAM Modules,/usr/lib/security

/usr/lib/security/pam_unix.so.1

fournit un suport d’authentification, gestion de compte, session de mot de passe. Il utilise les mots de passe Unix pour l’authenfication.

/usr/lib/security/pam_dial_auth.so.1

peut seulement être utilisé pour

l’authentification. Il utilise des données stockées dans

/etc/dialups

et

/etc/d_passwd

. Principalement utilisé par

login

.

/usr/lib/security/pam_rhosts_auth.so.1

peut seulement être utilisé pour l’authentification. Il utilise les données stockées dans les fichiers

.rhosts

et

/etc/hosts.equiv

. Principalement utilisé par

rlogin

et

rsh

.

(51)

Pluggable Authentification Module, PAM Options des modules

§ 37.6 Options des modules

On peut passer certaines options aux modules

– des options spécifiques à chaque module ; cf la documentation de chaque module ; par exemple

retry=3

ou

debug

– option

use_first_pass

Cette option indique d’utiliser exclusivement le mot de passe entré pour le premier module de la pile du service.

– option

try_first_pass

Cette option indique d’utiliser d’abord le mot de passe entré pour le premier module de la pile du service et en cas d’échec de ce mot de passe d’en demander un autre.

(Le support des optionsuse_first_passettry_first_passest fortement conseillé auprès des développeurs de modules PAM ; à vérifier donc avec chaque module)

Pluggable Authentification Module, PAM Exemple 1

§ 37.7 Exemple 1

Extrait de

/etc/pam.conf

:

# Authentication management

login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_dial_auth.so.1 Fichier

/etc/dialups

:

/dev/pts/9

Fichier

/etc/d_passwd

/bin/bash:nuemRW70uy9M.:

Session interactive :

% tty /dev/pts/9

% exec login exec login login: besancon

Password: XXXXXXXX <-- mot de passe

Dialup Password: YYYYYYYY <-- mot de passe

%% <-- connexion établie, shell lancé

On voit bien la ligne supplémentaire «

Dialup Password:

»