transfert recherches documentaires LDAP
This commit is contained in:
parent
a8ec9448a0
commit
1dc8a6d16b
360
doc.md
360
doc.md
|
|
@ -19,366 +19,6 @@ Compilation :
|
|||
## Acronymes
|
||||
|
||||
# Annuaires
|
||||
Le premier concept étudié ici est le mécanisme d'annuaire, largement répandu dans les systèmes d'information.
|
||||
On utilise le terme *directory* en anglais, et il faut comprendre cet outil comme un répertoire où les données sont structurées de façon à refléter l'organisation des entités qu'elles représentent.
|
||||
Cette structuration passe par la hiérarchisation des hiérarchisation des données d'identités. Lors de la phase de conception de l'annuaire, il est par exemple possible de déduire la hiérarchisation des données d'identités par la structure organisationnelle des entités stockées dans l'annuaire.
|
||||
|
||||
Les annuaires numériques sont apparus parallèlement à l'apparition des réseaux privés, afin de recenser les différentes entités et ressources présente sur le réseau, ainsi que proposer un moyen d'identification de ces ressources (qui sont-elles ? comment les contacter ?).
|
||||
|
||||
Le premier système de service d'annuaire, toujours utilisé aujourd'hui, est DNS (*Domain Name Service*). Toutes les propriétés fondamentales de l'annuaire y sont déjà présentes : structuration arborescente des données, accès en lecture plus souvent qu'en écriture, architecture centralisée localement mais distribuée d'un point de vue global, possibilité d'étendre la structure de base pour prendre en charge de nouveaux cas d'utilisation, utilisation de protocoles réseaux standardisés.
|
||||
|
||||
Par la suite, Sun Microsystems a mis aussi point le protocole Yellow Pages, devenu par la suite NIS (Network Information Service). Outre la prise en charge des données relatives au réseau, NIS étend le principe d'annuaire aux mécanismes d'authentification sur une architecture client-serveur. Aux fichiers d'identités usuels des systèesm UNIX (`/etc/{passwd,shadow,group,...}`) viennent s'ajouter des données présentes sur un serveur NIS. Les principes de délégation de l'authentification à une autorité tierce sont introduits : on parle alors de fournisseur d'identité (ou IdP). NIS définit aussi les protocoles de communication client-serveur pour accéder à l'annuaire.
|
||||
|
||||
La capacité des annuaires à décrire des structures de nature vaste et complète est réalisée par la mise en place des annuaires X.500 par la CCITT/UIT-T (Union Internationale des Télécommunications). Les différents protocoles de communication client-serveur de X.500 sont normalisés par l'OSI.
|
||||
|
||||
Plus généralement, la question de la pertinence de l'utilisation d'un annuaire en fonction des cas d'utilisation se pose. En effet, les données d'identités peuvent tout aussi bien être stockées sur une base de données. Plusieurs critères de choix de la technologie utilisée entrent alors en jeu :
|
||||
* Si les données sont plus souvent lues qu'écrites, alors un annuaire peut être plus pertinent.
|
||||
* S'il est nécessaire de rendre compte de relations entre entités stockées, il peut être préférable de recourir à une BdD.
|
||||
* S'il est nécessaire de standardiser la structuration des données de façon à garantir l'interopérabilité des services, ou bien de d'utiliser des protocoles de consultation du support de stockage standardisés, alors un annuaire est plus adapté qu'une SGBD.
|
||||
|
||||
Nous remarquerons toutefois que le mode d'accès aux différentes ressources du réseau peut être défini au cas par cas à l'aide d'outils tels que NSS (*Name Service Switch*). Ainsi, le fichier `/etc/nsswitch.conf` défini un ordre de priorité pour les différentes méthodes d'accès aux ressources telles que *passwd*, *shadow*, *group*, *hosts*, *aliases*.
|
||||
|
||||
La prochaine section de ce document traite du standard d'annuaire le plus utilisé actuellement, LDAP (*Lightweight Directory Accès Protocol*). Différentes implémentation de cette RFC seront ensuite présentés.
|
||||
|
||||
## LDAP
|
||||
|
||||
### Présentation générale
|
||||
Il convient tout d'abord d'expliquer en quoi LDAP se démarque des technologies d'annuaire précédentes.
|
||||
|
||||
LDAP se veut une simplification de X.500, par définition d'une structure arborescente minimale relativement simple à déployer (et cependant largement extensible).
|
||||
Ainsi, si LDAP et X.500 ont de nombreux points communs (par exemple les attributs et objets typés de façon similaire, ou encore les mêmes opérations d'accès à l'annuaire), leur fonctionnement diverge en de nombreux points :
|
||||
- les premières versions de LDAP supportaient déjà TCP/IP, tandis que X.500 n'a longtemps supporté que ses propres protocoles réseau.
|
||||
- LDAP définit un mécanisme de duplication des annuaires selon plusieurs cas d'usage (Cf paragraphe suivant consacré à LDUP).
|
||||
- LDAP allège le nombre de fonctions présentes dans X.500, proposant ainsi un standard plus facilement implémentable (justifiant ainsi le plus grand nombre d'implémentations LDAP disponibles par rapport à X.500).
|
||||
|
||||
[//]: <> (clairement les tenants et aboutissants d'une telle standardisation pour description organisationnelle, à l'aide des schémas couramment utilisés nis, inetorg ?)
|
||||
|
||||
Etudions par exemple le schéma InetOrgPerson fourni par l'IETF. Ce schéma décrit la façon dont un employé est défini dans l'annuaire.
|
||||
Ce schéma, défini de façon exhaustive par la RFC2798, reste bien évidemment extensible (afin de répondre à des besoins spécifiques, non-couverts par la RFC).
|
||||
Au total, 27 attributs permettent de définir une InetOrgPerson : carLicense, departmentNumber, displayName, employeeNumber, employeeType, jpegPhoto, etc.
|
||||
|
||||
Une fois déclarés tous les types mis en jeu pour la défini d'une InetOrgPerson, la définition de cet objet peut avoir lieu :
|
||||
|
||||
`# inetOrgPerson`
|
||||
`# The inetOrgPerson represents people who are associated with an`
|
||||
`# organization in some way. It is a structural class and is derived`
|
||||
`# from the organizationalPerson which is defined in X.521 [X521].`
|
||||
` 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 )`
|
||||
` )`
|
||||
|
||||
Deux choses importantes sont à remarquer pour cette définition.
|
||||
|
||||
Tout d'abord, et de façon similaires à tous les types utilisés dans les schémas standard, les objet (*objectClass*) possèdent un OID (ou *Object IDentifier*). Les OID standard, délivrés par l'IANA, permettent d'identifier de façon univoque un élément (objet, attribut, ou type) intervenant dans la définition d'un schéma LDAP.
|
||||
|
||||
[//]: <> (chaque OID correspond à la standardisation d'un attribut)
|
||||
[//]: <> ( LDAP reprend le format de la norme X500 mais propose une spécification plus légère et plus facile à mettre en place. "L" pour *Lightweight* Fonctionne sur TCP/IP contrairement DAP/X.500)
|
||||
|
||||
Ensuite, la définition des *objectClass* se fait à l'aide de mot-clés indiquant à l'administrateur système quels attributs peuvent entrer en jeu pour l'objet donné.
|
||||
Les différents mot-clés, à savoir MUST et MAY, permettent de déterminer le caractère optionnel ou obligatoire de chacun des attributs.
|
||||
Un objet peut comporter un ensemble d'attributs obligatoires (i.e. qui doivent être présents pour chacun occurrence de l'objet dans l'annuaire) et un ensemble d'attributs optionnels seulement.
|
||||
La RFC4519 (*LDAP: Schema for user applications*) donne l'exemple de l'*objectClass* `groupOfNames` qui possède ces deux ensembles d'attributs obligatoires et facultatifs :
|
||||
` ( 2.5.6.9 NAME 'groupOfNames'`
|
||||
` SUP top`
|
||||
` STRUCTURAL`
|
||||
` MUST ( member $`
|
||||
` cn )`
|
||||
` MAY ( businessCategory $`
|
||||
` seeAlso $`
|
||||
` owner $`
|
||||
` ou $`
|
||||
` o $`
|
||||
` description ) )`
|
||||
|
||||
|
||||
[//]: <> ( Les données sont organisées selon un schéma.)
|
||||
LDAP spéficie aussi une interface de consultation de l'annuaire pour les clients autorisés (voir les outils client de type `ldap-utils`)
|
||||
Par définition, les accès les plus fréquents se font en lecture plutôt qu'en écriture. On parle d'annuaire car ce référentiel est plus souvent consulté que modifié.
|
||||
Il est important de remarquer qu'à travers les schémas, LDAP standardise la structure et l'organisation des données stockées dans l'annuaire. Cette standardisation a pour but de garantir l'interopérabilité entre structures organisationnelles.
|
||||
|
||||
Le stockage des données de l'annuaire peut se faire sur une BDD ou simplement sur un fichier.
|
||||
|
||||
On distingue quatre composantes - ou quatre modèles (cf *Understanding and deploying LDAP Directory Services*) :
|
||||
- le modèle de nommage
|
||||
- le modèle fonctionnel
|
||||
- le modèle d'information
|
||||
- le modèle de sécurité
|
||||
|
||||
#### Modèle de nommage
|
||||
Ce modèle consiste en une convention de formation des DC (*Domain Components*)
|
||||
Identification univoque par utilisation d'un DN (Distinguished Name), ou utilisation du RDN si pas besoin d'identifiant unique.
|
||||
|
||||
Attributs de base des entrées LDAP [//]: <> (TODO Courte présentation de ces différents attributs)
|
||||
* dn (*Distinguished Name*)
|
||||
* rdv (*Relative Distinguished Name*)
|
||||
* objectClass
|
||||
* dc (*Domain Component*)
|
||||
* o (*Organization*)
|
||||
* ou (*Organizational Unit*)
|
||||
* cn (*Common Name*)
|
||||
* sn (*Surname*)
|
||||
* uid (*User IDentifier*)
|
||||
|
||||
Structure arborescente de représentation des données.
|
||||
|
||||
|
||||
#### Modèle fonctionnel
|
||||
Le modèle fonctionnel de la RFC LDAP se base sur les mécanismes de portées et de filtres pour les opérations CRUD.
|
||||
La recherche d'entrées dans un annuaire se fait selon une portée (*scope*) :
|
||||
- **base** : recherche seulement sur l'entrée LDAP mentionné dans la recherche
|
||||
- **sub** : recherche récursive complète
|
||||
- **one** : un seul niveau de profondeur à partir de l'élément mentionné dans la requête
|
||||
|
||||
Les filtres définissent leur propre syntaxe d'expressions régulières et d'expressions booléennes pour imposer des conditions logiques sur les attributs des entrées recherchées.
|
||||
|
||||
Prenons par exemple la requête suivante :
|
||||
```
|
||||
"(|(telephoneNumber=*)(mail=*)(street=*))"
|
||||
```
|
||||
|
||||
La RFC stipule que le symbole `|` désigne l'opérateur logique OU. Ainsi, la recherche ci-dessus renvoie toutes les entrées (à partir du DN définissant le sous-arbre de recherche) dont l'un des trois champs `telephoneNumber`, `mail` ou `street` est désigné.
|
||||
|
||||
De façon similaire, l'opérateur logique ET est représenté par le symbole `&`.
|
||||
|
||||
On remarquera par ailleurs que la RFC standardise une syntaxe de requêtes étendue permettant d'exprimer des conditions logiques plus complexes que ce qui est présenté ici. Nous renvoyons le lecteur à la documentation en ligne abordant la notions de filtres étendus, notamment les paragraphes 2 et 3 de la RFC4515 (String representation of LDAP Search Filters).
|
||||
|
||||
|
||||
Les filtres ne prennent sens que par association aux différentes opérations effectuable sur l'annuaire . Elles sont au nombre de 11 : *abandon*, *add*, *bind*, *compare*, *delete*, *extended*, *modify*, *modify DN*, *rename*, *search*, *unbind*. Ces opérations appartiennent chacunes à l'une des quatre catégories CRUD (Create,Read, Update, Delete).
|
||||
De par la nature-même de la structure d'annuaire, les développeurs de OpenLDAP ont pris le parti de proposer une implémentation optimisant les opérations de lecture au détriment des opérations d'écriture.
|
||||
|
||||
Enfin, il est important de noter que LDAP s'appuie sur les propriétés modulaires de SASL, lesquelles permettent délégation de l'authentification à un mécanisme tiers, spécialisé dans cette tâche.
|
||||
|
||||
//
|
||||
//URLs Echappement par caractères hexadécimal préfixé par %
|
||||
//`ldap[s]://<hostname>:<port>/<base_dn>?<attributes>?<scope>?&<filter>?<extensions>`
|
||||
//
|
||||
//Opérations côté client de type CRUD
|
||||
//
|
||||
//
|
||||
|
||||
#### Modèle d'information
|
||||
Le modèle d'information de LDAP introduit deux notions importantes:
|
||||
- Le DIT (*Directory Information tree*) est la structure de données adoptées par le protocole. Cette structure arborescente, en pratique souvent peu profonde (beaucoup de noeuds sont des feuilles), permet de représenter un vaste ensemble de structures de données.
|
||||
- Le DSE (*Directory Service Entry*) est une entrée du serveur, associée à une chaîne de caractère de longueur zéro. L'entrée DSE contient les méta-données de l'annuaire, telles que les `namingContexts`, le `vendorName`, les `supportedAuthPasswordSchemes` ou encore les `supportedSASLMechanisms`.
|
||||
|
||||
En fonction des schémas utilisés, certaines entrées peuvent contenir des attributs multivalués (une même personne peut posséder plusieurs adresses, être associées à plusieurs unités d'affectation, etc). On notera néanmoins que la RFC impose l'absence d'ordre dans la déclaration des attributs multivalués.
|
||||
|
||||
// La définition des schémas standard se fait par recours aux OIDs , attributeType et et OIDs // Redite...
|
||||
|
||||
#### Modèle de sécurité
|
||||
On peut aussi choisir de mettre en place une authentification anonyme (en général ce mode d'authentification présente des droits d'accès moindres par rapport à une authentification identifiée).
|
||||
|
||||
Deux protocoles principaux pour assurer la sécurité par chiffrement des échanges client-annuaire :
|
||||
- LADPS a recours a SSL // obsolète, non ?
|
||||
- StartTLS, qui utilise TLS (successeur de SSL)
|
||||
|
||||
Le serveur peut avoir recours à des ACLs pour restreindre les droits d'accès du client après authentification de ce dernier.
|
||||
Nous renvoyons le lecteur de ce document aux *man pages* de *slapd.conf(5)*, fichier de configuration du serveur OpenLDAP.
|
||||
La syntaxe des ACL y est assurée par une gestion de droits de façon déclarative, sous la forme :
|
||||
`access to <what> [ by <who> <access> <control> ]+`
|
||||
|
||||
//Finalement, l'authentification peut-être laissée à un mécanisme d'authentification forte ou du moins renforcée, à l'aide du protocole SASL. //Redite
|
||||
|
||||
#### Fonctionnnalités annexes
|
||||
##### Réplication
|
||||
// cf plus bas LDUP -> TODO reorganiser, expliquer les différentes raisons pour instaurer une redondance de l'annuaire sur plusieurs serveurs
|
||||
|
||||
##### Distribution
|
||||
La distribution introduit un concept similaire, à des fins différentes.
|
||||
Cette fois-ci il n'y a pas de redondance, mais éclatement de l'annuaire en plusieurs parties sur différents serveurs.
|
||||
On parle de *referrals* (càd de référencement), c'est à dire que les entrées de l'annuaire sont réparties sur plusieurs sites logiques.
|
||||
|
||||
##### Liens symboliques
|
||||
En lien avec le concept de distribution, l'introduction du mécanisme de liens symboliques dans la RFC permet d'éviter la redondance des données.
|
||||
La mise en place d'alias au sein d'un même annuaire permet d'éviter cette redondance.
|
||||
La RFC parle d'*aliasedObjectName* (RFC4512LDAP Directory Information Models - Section 2.6 : Alias Entries)
|
||||
|
||||
### Schémas
|
||||
#### Présentation
|
||||
Un schéma de données LDAP est défini au format LDIF. Certains standards sont définis par la IETF et disposent d'OID approuvés par l'IANA //a vérifier
|
||||
Les fichiers LDIF d'un serveur LDAPv3 sont en général disponibles en tant que fichier texte sur le serveur.
|
||||
Il y a alors la possibilité de modifier (déconseillé) ou d'étendre (préférable) des schémas existant pour les adapter au scenario d'utilisation du serveur d'annuaire.
|
||||
|
||||
### LDAP Duplication/Replication/Update Protocols (ldup)
|
||||
Le WG LDUP définit un mécanisme de duplication pour les annuaires LDAPv3.
|
||||
Il ne s'agit pas de synchronsation à proprement parler (l'annuaire, l'implémentation, les schémas, les données sont identiques).
|
||||
*LDAP Duplication/Replication/Update* -- LDAPv3
|
||||
|
||||
Différentes configurations prises en charge pour la réplication des données de l'annuaire :
|
||||
- plusieurs maîtres (multi-master)
|
||||
- maître - esclave
|
||||
|
||||
#### LDAPv3 Replication requirements (RFC3384)
|
||||
Concepts fondamentaux :
|
||||
* Réplication anonyme (*anonymous replication*) : source et cible sont identifiées mais pas authentifiées
|
||||
* Zone de réplication (*area of replication*) : sous-partie de l'arborescence qui subit réplication. (=> Cette réplication ne concerne pas toujours la totalité de l'annuaire)
|
||||
* Opération atomique : cf théorie de la synchro entre différents process
|
||||
* Conflits : sur les informations répliquées (par ex deux changements non conciliables concernant la même sous-partie des données répliquées)
|
||||
* OID Critique : Critique au sens de la réplication. Synchronicité entre modification d'un OID critique et propagation des modifications sur tous les réplicats.
|
||||
* Mise-à-jour incrémentale (*incremental update*) : Mise à jour dont le contenu ne concerne que ce qui a été modifié, et non pas les données restées identiques entre les deux modifications
|
||||
* Réplication à sens unique (*one-way replication*) -> par opposition à :
|
||||
* Réplication bidirectionnelle (*two-way replication*) : changements locaux appliqués dans les deux sens pour parvenir à un état identique ~> 'LDAP merge'
|
||||
* Réplicat esclave (*Slave replica*) : exemplaire du LDAP disponible en lecture seule seulement. Ne peut être instigateur de modifications sur son exemplaire local de l'annuaire.
|
||||
|
||||
#### Cas d'usage
|
||||
TODO ou pas
|
||||
|
||||
#### Limites de LDUP
|
||||
LDUP concerne un seul annuaire, selon un modèle distribué master*s*/slaves, pas forcément centralisé.
|
||||
Mais en pratique, il n'est pas toujours (voire pas souvent possible) d'avoir un seul annuaire LDAP. Certains outils ne supportent pas ce protocole.
|
||||
|
||||
On va donc avoir besoin d'un mécanisme de synchro de référentiels d'identités basés sur des technos hétérogènes.
|
||||
|
||||
// TODO Réorganisation des h3, ce n'est pas très clair
|
||||
### Authentication methods for LDAP (RFC2829)
|
||||
#### Motivations de la RFC
|
||||
Les différentes considérations entrant en compte dans la pertinence de l'authentification à un annuaire sont les suivantes :
|
||||
- Un accès frauduleux en lecture, ce qui revient à un vol de données (potentiellement sensibles)
|
||||
- Le *Session hijacking* par vol des données d'authentification d'un client légitime obtenues sur l'annuaire //TODO pas très clair...
|
||||
- Un accès frauduleux en écriture, c'est-à-dire la corruption des données de l'annuaire
|
||||
- Une attaque de type 'déni de service' (DoS) sur l'annuaire
|
||||
- Et plus généralement, une attaque de type *Man-in-the-middle*, avec tout cela que ça implique (Dégâts côté client et/ou côté serveur...)
|
||||
|
||||
#### Moyens mis en place
|
||||
Le mécanisme principal assuré par les implémentations LDAPv3 est une politique de sécurité contrôle par d'accès (*access control policy*).
|
||||
Derrière ce nom barbare se trouvent avant tout des règles d'accès au ressources, généralement sous forme de liste (ACL)
|
||||
Une telle politique nécessite la définition d'attributs d'accès //TODO
|
||||
|
||||
### Implémentations
|
||||
#### OpenLDAP
|
||||
OpenLDAP est l'implémentation UNIX de référence des annuaires compatibles LDAPv3.
|
||||
Cette implémentation est disponible dans les dépôts de la plupart des distributions standard.
|
||||
Sous Debian, le paquet à installer est `slapd`.
|
||||
|
||||
Certaines distributions proposent des *LDAP scripts* censés faciliter l'administration du serveur d'annuaire.
|
||||
//Compatibility avec les LDAP scripts ?
|
||||
|
||||
TODO Ecrire un slapd.conf pour le convertir à la nouvelle syntaxe ?
|
||||
BLOCKER Quels credentials par défaut ? DONE
|
||||
|
||||
Les différents fichiers de configuration et fichiers binaires de OpenLDAP sont répartis dans le système suivant la convention ci-dessous (cf tutoriels.meddeb.net) :
|
||||
- /usr/lib/ldap/ : librairies des modules (overlay), fichiers binaires natifs
|
||||
- /etc/ldap/schema/ : Schémas disponibles par défaut, fichiers texte.
|
||||
- /etc/ldap/slap.d/ : Configuration dynamique, fichiers texte.
|
||||
- /var/lib/ldap/ : Données, fichiers de la base de données installée.
|
||||
- /var/run/slapd/ : Paramètres d’exécution, fichiers texte.
|
||||
|
||||
Une fois l'annuaire installé, le serveur dispose d'une configuration minimale, dont le dn est dérivé du hostname de la machine :
|
||||
```
|
||||
paul@spare:~$ ldapsearch -Y external -H ldapi:/// -b dc=entrouvert,dc=lan -LLLSASL/EXTERNAL authentication started
|
||||
SASL username: gidNumber=1003+uidNumber=1003,cn=peercred,cn=external,cn=auth
|
||||
SASL SSF: 0
|
||||
dn: dc=entrouvert,dc=lan
|
||||
objectClass: top
|
||||
objectClass: dcObject
|
||||
objectClass: organization
|
||||
o: entrouvert.lan
|
||||
dc: entrouvert
|
||||
|
||||
dn: cn=admin,dc=entrouvert,dc=lan
|
||||
objectClass: simpleSecurityObject
|
||||
objectClass: organizationalRole
|
||||
cn: admin
|
||||
description: LDAP administrator
|
||||
```
|
||||
Nous possédons maintenant les informations nécessaires pour paramétrer Apache Directory Studio afin de naviguer (à l'aide de la GUI) dans l'annuaire nouvellement installé.
|
||||
|
||||
L'exécutable binaire ApacheDirectoryStudio pour Linux est disponible sur le site du projet Apache.
|
||||
|
||||
Le fichier Example.ldif, utilisé en local seulement, et obtenu sur `mcraig.org/ldif/Example.ldif` (license CDDL), permet de peupler l'annuaire pour refléter une structure organisationnelle générique.
|
||||
|
||||
Nous aurions tout aussi pu utiliser la fonction *populate* des ldap-scripts disponible pour Linux. [//]: <> (Retrouver ceux du cours réseau ? ldappopulate)
|
||||
|
||||
##### Sources
|
||||
Le code source d'OpenLDAP étant ouvert, il est possible d'étudier certains aspects de l'implémentation. OpenLDAP définit sa couche 5 (du modèle OSI), y compris tous les message qui vont circuler sur le flux TCP.
|
||||
|
||||
Commençons par obtenir de code source :
|
||||
`$ git clone git://git.openldap.org/openldap.git`
|
||||
|
||||
[//]: <> (<OpenLDAP directory>ldap/libraries/libldap/ldap-int.h)
|
||||
|
||||
Ligne ~ 145 :
|
||||
```C
|
||||
/*
|
||||
* This structure represents both ldap messages and ldap responses.
|
||||
* These are really the same, except in the case of search responses,
|
||||
* where a response has multiple messages.
|
||||
*/
|
||||
|
||||
struct ldapmsg {
|
||||
ber_int_t lm_msgid; /* the message id */
|
||||
ber_tag_t lm_msgtype; /* the message type */
|
||||
BerElement *lm_ber; /* the ber encoded message contents */
|
||||
struct ldapmsg *lm_chain; /* for search - next msg in the resp */
|
||||
struct ldapmsg *lm_chain_tail;
|
||||
struct ldapmsg *lm_next; /* next response */
|
||||
time_t lm_time; /* used to maintain cache */
|
||||
};
|
||||
```
|
||||
|
||||
Déduit plusieurs caractéristiques sur l'implémentation :
|
||||
Présence d'un cache des messages LDAP.
|
||||
Messages typés
|
||||
ber encoded ?
|
||||
Maintient une liste chaînée de messages (une liste par échange cli-serv ?)
|
||||
|
||||
#### ApacheDS (Apache Directory Server)
|
||||
ApacheDS est une autre implémentation LDAPv3, créée par Alex Karasulu.
|
||||
Nous pouvons aussi utiliser Apache Directory Studio en tant qu'implémentation LDAP ou simplement en tant qu'interface frontend. Dans la section précédente, nous l'utilisions simplement en tant qu'interface graphique de navigation dans un annuaire OpenLDAP.
|
||||
Pour des raisons de stabilité constatée, nous privilégions ici une installation à l'aide du paquet Debian (fichier .deb) plutôt que du fichier binaire Java.
|
||||
|
||||
Le site Apache fait volontairement l'amalgame avec leur autre outil associé, nommé lui aussi ApacheDS (pour Directory Studio)
|
||||
|
||||
Nous pouvons toutefois émettre une première critique de l'outil ApacheDS, utilisé en tant que navigateur graphique d'annuaires: l'interface utilisateur, dérivée de l'IDE Eclipse, est difficile à manipuler. Comme Eclipse, les différentes procédures pour parvenir à ses fins dans l'IDE sont lourdes et peu intuitives.
|
||||
|
||||
Nous rappelons au lecteur que l'objectif ici est de mettre en place en parallèle plusieurs annuaires hétérogènes sur la machine locale, ceci dans le but de tester les fonctionnalités d'approvisionnement et de synchronisation de plusieurs gestionnaires d'identités.
|
||||
|
||||
La synchronisation de ces référentiels présente par ailleurs la difficulté de devoir fonctionner à partir de référentiels d'identités hétérogènes.
|
||||
|
||||
[//]: <> (BLOCKER : apacheds console default admin password ? pas grave, pas utile ici)
|
||||
|
||||
En tant qu'implémentation ouverte, alternative, d'un serveur LDAP, cette fois-ci écrite en Java, ApacheDS respecte les normes imposées par la RFC LDAPv3.
|
||||
|
||||
Par ailleurs, et outre les fonctionnalités client/serveur de la RFC, ApacheDS expose sa propre API. Le composant jar se comporte comme un module standard Java, c'est-à-dire embarquable dans tout type type d'appli Java.
|
||||
|
||||
A titre d'exemple, ApacheDS est implémenté nativement dans le projet Apache Geronimo (serveur d'application J2E de la fondation Apache, certifié Java EE 6). Il est aussi embarqué dans WildFly (anciennement JBoss).
|
||||
|
||||
En tant qu'implémentation compatible avec les RFC LDAPv3, le serveur LDAP ApacheDS écoute par défaut sur les ports 10389 (en clair ou chiffré avec StartTLS) et 10636 (SSL) (OpenLDAP -> 389 et 636 ?)
|
||||
Suivant les mécanismes de sécurité réseau standard sous Unix/Linux, le port 389 laissé par convention au serveur LDAP est inférieur en valeur à 1024. Il s'agit donc d'un port système réservé, et il faut disposer es droits *root* pour écouter sur ce port.
|
||||
C'est par ailleurs sur ce port standard LDAP qu'écoute le serveur `slapd`, disponible dans les dépôts apt Debian.
|
||||
|
||||
ApacheDS implémente un mécanisme de distribution des données : la répartition des entrées se fait dans des partitions, chacune contenant un *Directory Information Tree* (TODO ref necessaire)
|
||||
|
||||
Nous pouvons, à titre indicatif, donner la procédure d'ajout d'une partition dans l'annuaire :
|
||||
Ici en utilisant JDBM B+Trees [//]: <> (Et Mavibot ? TODIG)
|
||||
|
||||
Apache Mavibot MVCC BTree
|
||||
Successeur de JDBM pour l'implémentation des arbres de recherche balancés (*Balanced binary search trees*)
|
||||
|
||||
Le stockage dans des fichiers binaires est utilisé à des fins backup //Très brouillon, aller voir la doc TODOTODO
|
||||
|
||||
Le backup se fait par lecture des entrées de configuration de l'annuaire, au format LDIF (LDAP Data Interchange Format, comme ci--dessous :
|
||||
`$ ldapsearch -D "uid=admin,ou=system" -w secret -p 10389 -h localhost -b "dc=example,dc=com" -s sub "(ObjectClass=*)" * + > backup.ldif`
|
||||
|
||||
//TODO : Expliquer la syntaxe d'une requête de base. Expliquer en quoi on est loin du SQL, par exemple. Cf requête tuto officiel :
|
||||
`ldapsearch -h localhost -p 10389 -b "o=sevenSeas" -s sub "(cn=James Hook)" +`
|
||||
|
||||
[//]: <> (TODIG Onglet Replication de la config du server apacheDS en GUI client lourd)
|
||||
|
||||
Quels mécanismes assurant la sécurité des données de l'annuaire, des échanges clients/serveur ?
|
||||
Contrôle d'accès ? -> Standardisé par la RFC LDAPv3 ?
|
||||
La configuration est manipulable par écriture/lecture de fichiers LDIF dans <apacheds_base>/conf/../\*.ldif
|
||||
|
||||
### LDAP Synchronization Connector (LSC)
|
||||
Il s'agit d'un connecteur permettant la synchronisation entre ApacheDS et OpenLDAP TODIG
|
||||
//Lire la doc, quelle configuration ? Quels cas d'usages ? Quelles limites ? Quels partis pris pour l'implémentation du connecteur ?
|
||||
|
|
|
|||
|
|
@ -257,10 +257,363 @@ La synchronisation peut aussi donner lieu à la création d'un référentiel cen
|
|||
## Explications techniques
|
||||
|
||||
### Annuaires
|
||||
Le premier concept étudié ici est le mécanisme d'annuaire, largement répandu dans les systèmes d'information.
|
||||
On utilise le terme *directory* en anglais, et il faut comprendre cet outil comme un répertoire où les données sont structurées de façon à refléter l'organisation des entités qu'elles représentent.
|
||||
Cette structuration passe par la hiérarchisation des hiérarchisation des données d'identités. Lors de la phase de conception de l'annuaire, il est par exemple possible de déduire la hiérarchisation des données d'identités par la structure organisationnelle des entités stockées dans l'annuaire.
|
||||
|
||||
Les annuaires numériques sont apparus parallèlement à l'apparition des réseaux privés, afin de recenser les différentes entités et ressources présente sur le réseau, ainsi que proposer un moyen d'identification de ces ressources (qui sont-elles ? comment les contacter ?).
|
||||
|
||||
Le premier système de service d'annuaire, toujours utilisé aujourd'hui, est DNS (*Domain Name Service*). Toutes les propriétés fondamentales de l'annuaire y sont déjà présentes : structuration arborescente des données, accès en lecture plus souvent qu'en écriture, architecture centralisée localement mais distribuée d'un point de vue global, possibilité d'étendre la structure de base pour prendre en charge de nouveaux cas d'utilisation, utilisation de protocoles réseaux standardisés.
|
||||
|
||||
Par la suite, Sun Microsystems a mis aussi point le protocole Yellow Pages, devenu par la suite NIS (Network Information Service). Outre la prise en charge des données relatives au réseau, NIS étend le principe d'annuaire aux mécanismes d'authentification sur une architecture client-serveur. Aux fichiers d'identités usuels des systèesm UNIX (`/etc/{passwd,shadow,group,...}`) viennent s'ajouter des données présentes sur un serveur NIS. Les principes de délégation de l'authentification à une autorité tierce sont introduits : on parle alors de fournisseur d'identité (ou IdP). NIS définit aussi les protocoles de communication client-serveur pour accéder à l'annuaire.
|
||||
|
||||
La capacité des annuaires à décrire des structures de nature vaste et complète est réalisée par la mise en place des annuaires X.500 par la CCITT/UIT-T (Union Internationale des Télécommunications). Les différents protocoles de communication client-serveur de X.500 sont normalisés par l'OSI.
|
||||
|
||||
Plus généralement, la question de la pertinence de l'utilisation d'un annuaire en fonction des cas d'utilisation se pose. En effet, les données d'identités peuvent tout aussi bien être stockées sur une base de données. Plusieurs critères de choix de la technologie utilisée entrent alors en jeu :
|
||||
* Si les données sont plus souvent lues qu'écrites, alors un annuaire peut être plus pertinent.
|
||||
* S'il est nécessaire de rendre compte de relations entre entités stockées, il peut être préférable de recourir à une BdD.
|
||||
* S'il est nécessaire de standardiser la structuration des données de façon à garantir l'interopérabilité des services, ou bien de d'utiliser des protocoles de consultation du support de stockage standardisés, alors un annuaire est plus adapté qu'une SGBD.
|
||||
|
||||
Nous remarquerons toutefois que le mode d'accès aux différentes ressources du réseau peut être défini au cas par cas à l'aide d'outils tels que NSS (*Name Service Switch*). Ainsi, le fichier `/etc/nsswitch.conf` défini un ordre de priorité pour les différentes méthodes d'accès aux ressources telles que *passwd*, *shadow*, *group*, *hosts*, *aliases*.
|
||||
|
||||
La prochaine section de ce document traite du standard d'annuaire le plus utilisé actuellement, LDAP (*Lightweight Directory Accès Protocol*). Différentes implémentation de cette RFC seront ensuite présentés.
|
||||
|
||||
|
||||
#### X.500
|
||||
|
||||
#### LDAP
|
||||
##### Présentation générale
|
||||
Il convient tout d'abord d'expliquer en quoi LDAP se démarque des technologies d'annuaire précédentes.
|
||||
|
||||
LDAP se veut une simplification de X.500, par définition d'une structure arborescente minimale relativement simple à déployer (et cependant largement extensible).
|
||||
Ainsi, si LDAP et X.500 ont de nombreux points communs (par exemple les attributs et objets typés de façon similaire, ou encore les mêmes opérations d'accès à l'annuaire), leur fonctionnement diverge en de nombreux points :
|
||||
- les premières versions de LDAP supportaient déjà TCP/IP, tandis que X.500 n'a longtemps supporté que ses propres protocoles réseau.
|
||||
- LDAP définit un mécanisme de duplication des annuaires selon plusieurs cas d'usage (Cf paragraphe suivant consacré à LDUP).
|
||||
- LDAP allège le nombre de fonctions présentes dans X.500, proposant ainsi un standard plus facilement implémentable (justifiant ainsi le plus grand nombre d'implémentations LDAP disponibles par rapport à X.500).
|
||||
|
||||
[//]: <> (clairement les tenants et aboutissants d'une telle standardisation pour description organisationnelle, à l'aide des schémas couramment utilisés nis, inetorg ?)
|
||||
|
||||
Etudions par exemple le schéma InetOrgPerson fourni par l'IETF. Ce schéma décrit la façon dont un employé est défini dans l'annuaire.
|
||||
Ce schéma, défini de façon exhaustive par la RFC2798, reste bien évidemment extensible (afin de répondre à des besoins spécifiques, non-couverts par la RFC).
|
||||
Au total, 27 attributs permettent de définir une InetOrgPerson : carLicense, departmentNumber, displayName, employeeNumber, employeeType, jpegPhoto, etc.
|
||||
|
||||
Une fois déclarés tous les types mis en jeu pour la défini d'une InetOrgPerson, la définition de cet objet peut avoir lieu :
|
||||
|
||||
`# inetOrgPerson`
|
||||
`# The inetOrgPerson represents people who are associated with an`
|
||||
`# organization in some way. It is a structural class and is derived`
|
||||
`# from the organizationalPerson which is defined in X.521 [X521].`
|
||||
` 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 )`
|
||||
` )`
|
||||
|
||||
Deux choses importantes sont à remarquer pour cette définition.
|
||||
|
||||
Tout d'abord, et de façon similaires à tous les types utilisés dans les schémas standard, les objet (*objectClass*) possèdent un OID (ou *Object IDentifier*). Les OID standard, délivrés par l'IANA, permettent d'identifier de façon univoque un élément (objet, attribut, ou type) intervenant dans la définition d'un schéma LDAP.
|
||||
|
||||
[//]: <> (chaque OID correspond à la standardisation d'un attribut)
|
||||
[//]: <> ( LDAP reprend le format de la norme X500 mais propose une spécification plus légère et plus facile à mettre en place. "L" pour *Lightweight* Fonctionne sur TCP/IP contrairement DAP/X.500)
|
||||
|
||||
Ensuite, la définition des *objectClass* se fait à l'aide de mot-clés indiquant à l'administrateur système quels attributs peuvent entrer en jeu pour l'objet donné.
|
||||
Les différents mot-clés, à savoir MUST et MAY, permettent de déterminer le caractère optionnel ou obligatoire de chacun des attributs.
|
||||
Un objet peut comporter un ensemble d'attributs obligatoires (i.e. qui doivent être présents pour chacun occurrence de l'objet dans l'annuaire) et un ensemble d'attributs optionnels seulement.
|
||||
La RFC4519 (*LDAP: Schema for user applications*) donne l'exemple de l'*objectClass* `groupOfNames` qui possède ces deux ensembles d'attributs obligatoires et facultatifs :
|
||||
` ( 2.5.6.9 NAME 'groupOfNames'`
|
||||
` SUP top`
|
||||
` STRUCTURAL`
|
||||
` MUST ( member $`
|
||||
` cn )`
|
||||
` MAY ( businessCategory $`
|
||||
` seeAlso $`
|
||||
` owner $`
|
||||
` ou $`
|
||||
` o $`
|
||||
` description ) )`
|
||||
|
||||
|
||||
[//]: <> ( Les données sont organisées selon un schéma.)
|
||||
LDAP spéficie aussi une interface de consultation de l'annuaire pour les clients autorisés (voir les outils client de type `ldap-utils`)
|
||||
Par définition, les accès les plus fréquents se font en lecture plutôt qu'en écriture. On parle d'annuaire car ce référentiel est plus souvent consulté que modifié.
|
||||
Il est important de remarquer qu'à travers les schémas, LDAP standardise la structure et l'organisation des données stockées dans l'annuaire. Cette standardisation a pour but de garantir l'interopérabilité entre structures organisationnelles.
|
||||
|
||||
Le stockage des données de l'annuaire peut se faire sur une BDD ou simplement sur un fichier.
|
||||
|
||||
On distingue quatre composantes - ou quatre modèles (cf *Understanding and deploying LDAP Directory Services*) :
|
||||
- le modèle de nommage
|
||||
- le modèle fonctionnel
|
||||
- le modèle d'information
|
||||
- le modèle de sécurité
|
||||
|
||||
##### Modèle de nommage
|
||||
Ce modèle consiste en une convention de formation des DC (*Domain Components*)
|
||||
Identification univoque par utilisation d'un DN (Distinguished Name), ou utilisation du RDN si pas besoin d'identifiant unique.
|
||||
|
||||
Attributs de base des entrées LDAP [//]: <> (TODO Courte présentation de ces différents attributs)
|
||||
* dn (*Distinguished Name*)
|
||||
* rdv (*Relative Distinguished Name*)
|
||||
* objectClass
|
||||
* dc (*Domain Component*)
|
||||
* o (*Organization*)
|
||||
* ou (*Organizational Unit*)
|
||||
* cn (*Common Name*)
|
||||
* sn (*Surname*)
|
||||
* uid (*User IDentifier*)
|
||||
|
||||
Structure arborescente de représentation des données.
|
||||
|
||||
|
||||
##### Modèle fonctionnel
|
||||
Le modèle fonctionnel de la RFC LDAP se base sur les mécanismes de portées et de filtres pour les opérations CRUD.
|
||||
La recherche d'entrées dans un annuaire se fait selon une portée (*scope*) :
|
||||
- **base** : recherche seulement sur l'entrée LDAP mentionné dans la recherche
|
||||
- **sub** : recherche récursive complète
|
||||
- **one** : un seul niveau de profondeur à partir de l'élément mentionné dans la requête
|
||||
|
||||
Les filtres définissent leur propre syntaxe d'expressions régulières et d'expressions booléennes pour imposer des conditions logiques sur les attributs des entrées recherchées.
|
||||
|
||||
Prenons par exemple la requête suivante :
|
||||
```
|
||||
"(|(telephoneNumber=*)(mail=*)(street=*))"
|
||||
```
|
||||
|
||||
La RFC stipule que le symbole `|` désigne l'opérateur logique OU. Ainsi, la recherche ci-dessus renvoie toutes les entrées (à partir du DN définissant le sous-arbre de recherche) dont l'un des trois champs `telephoneNumber`, `mail` ou `street` est désigné.
|
||||
|
||||
De façon similaire, l'opérateur logique ET est représenté par le symbole `&`.
|
||||
|
||||
On remarquera par ailleurs que la RFC standardise une syntaxe de requêtes étendue permettant d'exprimer des conditions logiques plus complexes que ce qui est présenté ici. Nous renvoyons le lecteur à la documentation en ligne abordant la notions de filtres étendus, notamment les paragraphes 2 et 3 de la RFC4515 (String representation of LDAP Search Filters).
|
||||
|
||||
|
||||
Les filtres ne prennent sens que par association aux différentes opérations effectuable sur l'annuaire . Elles sont au nombre de 11 : *abandon*, *add*, *bind*, *compare*, *delete*, *extended*, *modify*, *modify DN*, *rename*, *search*, *unbind*. Ces opérations appartiennent chacunes à l'une des quatre catégories CRUD (Create,Read, Update, Delete).
|
||||
De par la nature-même de la structure d'annuaire, les développeurs de OpenLDAP ont pris le parti de proposer une implémentation optimisant les opérations de lecture au détriment des opérations d'écriture.
|
||||
|
||||
Enfin, il est important de noter que LDAP s'appuie sur les propriétés modulaires de SASL, lesquelles permettent délégation de l'authentification à un mécanisme tiers, spécialisé dans cette tâche.
|
||||
|
||||
//
|
||||
//URLs Echappement par caractères hexadécimal préfixé par %
|
||||
//`ldap[s]://<hostname>:<port>/<base_dn>?<attributes>?<scope>?&<filter>?<extensions>`
|
||||
//
|
||||
//Opérations côté client de type CRUD
|
||||
//
|
||||
//
|
||||
|
||||
##### Modèle d'information
|
||||
Le modèle d'information de LDAP introduit deux notions importantes:
|
||||
- Le DIT (*Directory Information tree*) est la structure de données adoptées par le protocole. Cette structure arborescente, en pratique souvent peu profonde (beaucoup de noeuds sont des feuilles), permet de représenter un vaste ensemble de structures de données.
|
||||
- Le DSE (*Directory Service Entry*) est une entrée du serveur, associée à une chaîne de caractère de longueur zéro. L'entrée DSE contient les méta-données de l'annuaire, telles que les `namingContexts`, le `vendorName`, les `supportedAuthPasswordSchemes` ou encore les `supportedSASLMechanisms`.
|
||||
|
||||
En fonction des schémas utilisés, certaines entrées peuvent contenir des attributs multivalués (une même personne peut posséder plusieurs adresses, être associées à plusieurs unités d'affectation, etc). On notera néanmoins que la RFC impose l'absence d'ordre dans la déclaration des attributs multivalués.
|
||||
|
||||
// La définition des schémas standard se fait par recours aux OIDs , attributeType et et OIDs // Redite...
|
||||
|
||||
##### Modèle de sécurité
|
||||
On peut aussi choisir de mettre en place une authentification anonyme (en général ce mode d'authentification présente des droits d'accès moindres par rapport à une authentification identifiée).
|
||||
|
||||
Deux protocoles principaux pour assurer la sécurité par chiffrement des échanges client-annuaire :
|
||||
- LADPS a recours a SSL // obsolète, non ?
|
||||
- StartTLS, qui utilise TLS (successeur de SSL)
|
||||
|
||||
Le serveur peut avoir recours à des ACLs pour restreindre les droits d'accès du client après authentification de ce dernier.
|
||||
Nous renvoyons le lecteur de ce document aux *man pages* de *slapd.conf(5)*, fichier de configuration du serveur OpenLDAP.
|
||||
La syntaxe des ACL y est assurée par une gestion de droits de façon déclarative, sous la forme :
|
||||
`access to <what> [ by <who> <access> <control> ]+`
|
||||
|
||||
//Finalement, l'authentification peut-être laissée à un mécanisme d'authentification forte ou du moins renforcée, à l'aide du protocole SASL. //Redite
|
||||
|
||||
##### Fonctionnnalités annexes
|
||||
###### Réplication
|
||||
// cf plus bas LDUP -> TODO reorganiser, expliquer les différentes raisons pour instaurer une redondance de l'annuaire sur plusieurs serveurs
|
||||
|
||||
###### Distribution
|
||||
La distribution introduit un concept similaire, à des fins différentes.
|
||||
Cette fois-ci il n'y a pas de redondance, mais éclatement de l'annuaire en plusieurs parties sur différents serveurs.
|
||||
On parle de *referrals* (càd de référencement), c'est à dire que les entrées de l'annuaire sont réparties sur plusieurs sites logiques.
|
||||
|
||||
###### Liens symboliques
|
||||
En lien avec le concept de distribution, l'introduction du mécanisme de liens symboliques dans la RFC permet d'éviter la redondance des données.
|
||||
La mise en place d'alias au sein d'un même annuaire permet d'éviter cette redondance.
|
||||
La RFC parle d'*aliasedObjectName* (RFC4512LDAP Directory Information Models - Section 2.6 : Alias Entries)
|
||||
|
||||
##### Schémas
|
||||
Un schéma de données LDAP est défini au format LDIF. Certains standards sont définis par la IETF et disposent d'OID approuvés par l'IANA //a vérifier
|
||||
Les fichiers LDIF d'un serveur LDAPv3 sont en général disponibles en tant que fichier texte sur le serveur.
|
||||
Il y a alors la possibilité de modifier (déconseillé) ou d'étendre (préférable) des schémas existant pour les adapter au scenario d'utilisation du serveur d'annuaire.
|
||||
|
||||
##### LDAP Duplication/Replication/Update Protocols (ldup)
|
||||
Le WG LDUP définit un mécanisme de duplication pour les annuaires LDAPv3.
|
||||
Il ne s'agit pas de synchronsation à proprement parler (l'annuaire, l'implémentation, les schémas, les données sont identiques).
|
||||
*LDAP Duplication/Replication/Update* -- LDAPv3
|
||||
|
||||
Différentes configurations prises en charge pour la réplication des données de l'annuaire :
|
||||
- plusieurs maîtres (multi-master)
|
||||
- maître - esclave
|
||||
|
||||
Cependant, LDUP concerne un seul annuaire, selon un modèle distribué master*s*/slaves, pas forcément centralisé.
|
||||
Mais en pratique, il n'est pas toujours (voire pas souvent possible) d'avoir un seul annuaire LDAP. Certains outils ne supportent pas ce protocole.
|
||||
|
||||
On va donc avoir besoin d'un mécanisme de synchro de référentiels d'identités basés sur des technos hétérogènes.
|
||||
|
||||
// TODO Réorganisation des h3, ce n'est pas très clair
|
||||
|
||||
##### LDAPv3 Replication requirements (RFC3384)
|
||||
Concepts fondamentaux :
|
||||
* Réplication anonyme (*anonymous replication*) : source et cible sont identifiées mais pas authentifiées
|
||||
* Zone de réplication (*area of replication*) : sous-partie de l'arborescence qui subit réplication. (=> Cette réplication ne concerne pas toujours la totalité de l'annuaire)
|
||||
* Opération atomique : cf théorie de la synchro entre différents process
|
||||
* Conflits : sur les informations répliquées (par ex deux changements non conciliables concernant la même sous-partie des données répliquées)
|
||||
* OID Critique : Critique au sens de la réplication. Synchronicité entre modification d'un OID critique et propagation des modifications sur tous les réplicats.
|
||||
* Mise-à-jour incrémentale (*incremental update*) : Mise à jour dont le contenu ne concerne que ce qui a été modifié, et non pas les données restées identiques entre les deux modifications
|
||||
* Réplication à sens unique (*one-way replication*) -> par opposition à :
|
||||
* Réplication bidirectionnelle (*two-way replication*) : changements locaux appliqués dans les deux sens pour parvenir à un état identique ~> 'LDAP merge'
|
||||
* Réplicat esclave (*Slave replica*) : exemplaire du LDAP disponible en lecture seule seulement. Ne peut être instigateur de modifications sur son exemplaire local de l'annuaire.
|
||||
|
||||
##### Authentication methods for LDAP (RFC2829)
|
||||
###### Motivations de la RFC
|
||||
Les différentes considérations entrant en compte dans la pertinence de l'authentification à un annuaire sont les suivantes :
|
||||
- Un accès frauduleux en lecture, ce qui revient à un vol de données (potentiellement sensibles)
|
||||
- Le *Session hijacking* par vol des données d'authentification d'un client légitime obtenues sur l'annuaire //TODO pas très clair...
|
||||
- Un accès frauduleux en écriture, c'est-à-dire la corruption des données de l'annuaire
|
||||
- Une attaque de type 'déni de service' (DoS) sur l'annuaire
|
||||
- Et plus généralement, une attaque de type *Man-in-the-middle*, avec tout cela que ça implique (Dégâts côté client et/ou côté serveur...)
|
||||
|
||||
###### Moyens mis en place
|
||||
Le mécanisme principal assuré par les implémentations LDAPv3 est une politique de sécurité contrôle par d'accès (*access control policy*).
|
||||
Derrière ce nom barbare se trouvent avant tout des règles d'accès au ressources, généralement sous forme de liste (ACL)
|
||||
Une telle politique nécessite la définition d'attributs d'accès //TODO
|
||||
|
||||
##### Implémentations
|
||||
###### OpenLDAP
|
||||
OpenLDAP est l'implémentation UNIX de référence des annuaires compatibles LDAPv3.
|
||||
Cette implémentation est disponible dans les dépôts de la plupart des distributions standard.
|
||||
Sous Debian, le paquet à installer est `slapd`.
|
||||
|
||||
Certaines distributions proposent des *LDAP scripts* censés faciliter l'administration du serveur d'annuaire.
|
||||
//Compatibility avec les LDAP scripts ?
|
||||
|
||||
TODO Ecrire un slapd.conf pour le convertir à la nouvelle syntaxe ?
|
||||
BLOCKER Quels credentials par défaut ? DONE
|
||||
|
||||
Les différents fichiers de configuration et fichiers binaires de OpenLDAP sont répartis dans le système suivant la convention ci-dessous (cf tutoriels.meddeb.net) :
|
||||
- /usr/lib/ldap/ : librairies des modules (overlay), fichiers binaires natifs
|
||||
- /etc/ldap/schema/ : Schémas disponibles par défaut, fichiers texte.
|
||||
- /etc/ldap/slap.d/ : Configuration dynamique, fichiers texte.
|
||||
- /var/lib/ldap/ : Données, fichiers de la base de données installée.
|
||||
- /var/run/slapd/ : Paramètres d’exécution, fichiers texte.
|
||||
|
||||
Une fois l'annuaire installé, le serveur dispose d'une configuration minimale, dont le dn est dérivé du hostname de la machine :
|
||||
```
|
||||
paul@spare:~$ ldapsearch -Y external -H ldapi:/// -b dc=entrouvert,dc=lan -LLLSASL/EXTERNAL authentication started
|
||||
SASL username: gidNumber=1003+uidNumber=1003,cn=peercred,cn=external,cn=auth
|
||||
SASL SSF: 0
|
||||
dn: dc=entrouvert,dc=lan
|
||||
objectClass: top
|
||||
objectClass: dcObject
|
||||
objectClass: organization
|
||||
o: entrouvert.lan
|
||||
dc: entrouvert
|
||||
|
||||
dn: cn=admin,dc=entrouvert,dc=lan
|
||||
objectClass: simpleSecurityObject
|
||||
objectClass: organizationalRole
|
||||
cn: admin
|
||||
description: LDAP administrator
|
||||
```
|
||||
Nous possédons maintenant les informations nécessaires pour paramétrer Apache Directory Studio afin de naviguer (à l'aide de la GUI) dans l'annuaire nouvellement installé.
|
||||
|
||||
L'exécutable binaire ApacheDirectoryStudio pour Linux est disponible sur le site du projet Apache.
|
||||
|
||||
Le fichier Example.ldif, utilisé en local seulement, et obtenu sur `mcraig.org/ldif/Example.ldif` (license CDDL), permet de peupler l'annuaire pour refléter une structure organisationnelle générique.
|
||||
|
||||
Nous aurions tout aussi pu utiliser la fonction *populate* des ldap-scripts disponible pour Linux. [//]: <> (Retrouver ceux du cours réseau ? ldappopulate)
|
||||
|
||||
Le code source d'OpenLDAP étant ouvert, il est possible d'étudier certains aspects de l'implémentation. OpenLDAP définit sa couche 5 (du modèle OSI), y compris tous les message qui vont circuler sur le flux TCP.
|
||||
|
||||
Commençons par obtenir de code source :
|
||||
`$ git clone git://git.openldap.org/openldap.git`
|
||||
|
||||
[//]: <> (<OpenLDAP directory>ldap/libraries/libldap/ldap-int.h)
|
||||
|
||||
Ligne ~ 145 :
|
||||
```C
|
||||
/*
|
||||
* This structure represents both ldap messages and ldap responses.
|
||||
* These are really the same, except in the case of search responses,
|
||||
* where a response has multiple messages.
|
||||
*/
|
||||
|
||||
struct ldapmsg {
|
||||
ber_int_t lm_msgid; /* the message id */
|
||||
ber_tag_t lm_msgtype; /* the message type */
|
||||
BerElement *lm_ber; /* the ber encoded message contents */
|
||||
struct ldapmsg *lm_chain; /* for search - next msg in the resp */
|
||||
struct ldapmsg *lm_chain_tail;
|
||||
struct ldapmsg *lm_next; /* next response */
|
||||
time_t lm_time; /* used to maintain cache */
|
||||
};
|
||||
```
|
||||
|
||||
Déduit plusieurs caractéristiques sur l'implémentation :
|
||||
Présence d'un cache des messages LDAP.
|
||||
Messages typés
|
||||
ber encoded ?
|
||||
Maintient une liste chaînée de messages (une liste par échange cli-serv ?)
|
||||
|
||||
###### ApacheDS (Apache Directory Server)
|
||||
ApacheDS est une autre implémentation LDAPv3, créée par Alex Karasulu.
|
||||
Nous pouvons aussi utiliser Apache Directory Studio en tant qu'implémentation LDAP ou simplement en tant qu'interface frontend. Dans la section précédente, nous l'utilisions simplement en tant qu'interface graphique de navigation dans un annuaire OpenLDAP.
|
||||
Pour des raisons de stabilité constatée, nous privilégions ici une installation à l'aide du paquet Debian (fichier .deb) plutôt que du fichier binaire Java.
|
||||
|
||||
Le site Apache fait volontairement l'amalgame avec leur autre outil associé, nommé lui aussi ApacheDS (pour Directory Studio)
|
||||
|
||||
Nous pouvons toutefois émettre une première critique de l'outil ApacheDS, utilisé en tant que navigateur graphique d'annuaires: l'interface utilisateur, dérivée de l'IDE Eclipse, est difficile à manipuler. Comme Eclipse, les différentes procédures pour parvenir à ses fins dans l'IDE sont lourdes et peu intuitives.
|
||||
|
||||
Nous rappelons au lecteur que l'objectif ici est de mettre en place en parallèle plusieurs annuaires hétérogènes sur la machine locale, ceci dans le but de tester les fonctionnalités d'approvisionnement et de synchronisation de plusieurs gestionnaires d'identités.
|
||||
|
||||
La synchronisation de ces référentiels présente par ailleurs la difficulté de devoir fonctionner à partir de référentiels d'identités hétérogènes.
|
||||
|
||||
[//]: <> (BLOCKER : apacheds console default admin password ? pas grave, pas utile ici)
|
||||
|
||||
En tant qu'implémentation ouverte, alternative, d'un serveur LDAP, cette fois-ci écrite en Java, ApacheDS respecte les normes imposées par la RFC LDAPv3.
|
||||
|
||||
Par ailleurs, et outre les fonctionnalités client/serveur de la RFC, ApacheDS expose sa propre API. Le composant jar se comporte comme un module standard Java, c'est-à-dire embarquable dans tout type type d'appli Java.
|
||||
|
||||
A titre d'exemple, ApacheDS est implémenté nativement dans le projet Apache Geronimo (serveur d'application J2E de la fondation Apache, certifié Java EE 6). Il est aussi embarqué dans WildFly (anciennement JBoss).
|
||||
|
||||
En tant qu'implémentation compatible avec les RFC LDAPv3, le serveur LDAP ApacheDS écoute par défaut sur les ports 10389 (en clair ou chiffré avec StartTLS) et 10636 (SSL) (OpenLDAP -> 389 et 636 ?)
|
||||
Suivant les mécanismes de sécurité réseau standard sous Unix/Linux, le port 389 laissé par convention au serveur LDAP est inférieur en valeur à 1024. Il s'agit donc d'un port système réservé, et il faut disposer es droits *root* pour écouter sur ce port.
|
||||
C'est par ailleurs sur ce port standard LDAP qu'écoute le serveur `slapd`, disponible dans les dépôts apt Debian.
|
||||
|
||||
ApacheDS implémente un mécanisme de distribution des données : la répartition des entrées se fait dans des partitions, chacune contenant un *Directory Information Tree* (TODO ref necessaire)
|
||||
|
||||
Nous pouvons, à titre indicatif, donner la procédure d'ajout d'une partition dans l'annuaire :
|
||||
Ici en utilisant JDBM B+Trees [//]: <> (Et Mavibot ? TODIG)
|
||||
|
||||
Apache Mavibot MVCC BTree
|
||||
Successeur de JDBM pour l'implémentation des arbres de recherche balancés (*Balanced binary search trees*)
|
||||
|
||||
Le stockage dans des fichiers binaires est utilisé à des fins backup //Très brouillon, aller voir la doc TODOTODO
|
||||
|
||||
Le backup se fait par lecture des entrées de configuration de l'annuaire, au format LDIF (LDAP Data Interchange Format, comme ci--dessous :
|
||||
`$ ldapsearch -D "uid=admin,ou=system" -w secret -p 10389 -h localhost -b "dc=example,dc=com" -s sub "(ObjectClass=*)" * + > backup.ldif`
|
||||
|
||||
//TODO : Expliquer la syntaxe d'une requête de base. Expliquer en quoi on est loin du SQL, par exemple. Cf requête tuto officiel :
|
||||
`ldapsearch -h localhost -p 10389 -b "o=sevenSeas" -s sub "(cn=James Hook)" +`
|
||||
|
||||
[//]: <> (TODIG Onglet Replication de la config du server apacheDS en GUI client lourd)
|
||||
|
||||
Quels mécanismes assurant la sécurité des données de l'annuaire, des échanges clients/serveur ?
|
||||
Contrôle d'accès ? -> Standardisé par la RFC LDAPv3 ?
|
||||
La configuration est manipulable par écriture/lecture de fichiers LDIF dans <apacheds_base>/conf/../\*.ldif
|
||||
|
||||
|
||||
### Schéma SUPANN2009
|
||||
|
||||
|
|
|
|||
Reference in New Issue