Groupe de travail Réseau |
K. Zeilenga, éditeur |
Request for Comments : 4524 |
OpenLDAP Foundation |
RFC rendue obsolète : 1274 |
Juin 2006 |
RFC mises à jour : 2247, 2798 |
Traduction Claude Brière de L’Isle |
Catégorie : Standards Track |
Juin 2007 |
Statut du présent mémo
Le présent document spécifie un protocole de normalisation Internet pour la communauté de l'Internet, qui appelle à la discussion et à des suggestions pour son amélioration. Prière de se reporter à l'édition en cours des "Normes de protocole officielles de l'Internet" (STD 1) sur l'état de la normalisation et le statut de ce protocole. La distribution du présent mémo n'est soumise à aucune restriction.
Notice de copyright
Copyright (C) The Internet Society (2006).
Résumé
Le présent document fournit une collection d’éléments de schéma à utiliser avec le Protocole léger d’accès à un répertoire (LDAP) à partir des projets pilotes COSINE et X.500 Internet.
Ce document rend obsolète la RFC 1274 et met à jour les RFC 2247 et 2798.
Table des matières
1. Introduction
1.1 Relations avec les autres documents
1.2 Terminologie et conventions
2. Types d’attributs COSINE
2.1 associatedDomain
2.2 associatedName
2.3 buildingName
2.4 co
2.5 documentAuthor
2.6 documentIdentifier
2.7 documentLocation
2.8 documentPublisher
2.9 documentTitle
2.10 documentVersion
2.11 drink
2.12 homePhone
2.13 homePostalAddress
2.14 host
2.15 info
2.16 mail
2.17 manager
2.18 mobile
2.19 organizationalStatus
2.20 pager
2.21 personalTitle
2.22 roomNumber
2.23 secretary
2.24 uniqueIdentifier
2.25 userClass
3. Classes d’objet COSINE
3.1 account
3.2 document
3.3 documentSeries
3.4 domain
3.5 domainRelatedObject
3.6 friendlyCountry
3.7 rFC822LocalPart
3.8 room
3.9 simpleSecurityObject
4. Considérations sur la sécurité
5. Considérations relatives à l’IANA
7. Références
7.1. Références normatives
7.2 Références informatives
Appendice A. Changements depuis la RFC 1274
A.1 Noms abrégés LDAP
A.2 pilotObject
A.3 pilotPerson
A.4 dNSDomain
A.5 pilotDSA and qualityLabelledData
A.6 Syntaxes d’attribut
Appendice B. Changements depuis la RFC 2247
À la fin des années 1980, les services d’annuaire X.500 ont été normalisés par le CCITT (Comité Consultatif International Télégraphique et Téléphonique), section de l’UIT (Union Internationale des Télécommunications). Ceci a conduit le Service de l’annuaire à piloter des activités au début des années 1990, qui incluaient les projets pilotes COSINE (Coopération et interconnexion des systèmes ouverts en Europe) et PARADISE [COSINEpilot] en Europe. Motivée par le besoin de pilotes de répertoires à grande échelle, la RFC 1274 a été publiée pour normaliser l’architecture de schéma et de dénomination de répertoire à utiliser dans le projet pilote COSINE et d’autres pilotes Internet X.500 [RFC1274].
Dans les années suivantes, les services d’annuaire X.500 ont évolué pour incorporer de nouvelles capacités et même de nouveaux protocoles. En particulier, le Protocole léger d’accès à un répertoire (LDAP) [RFC4510] a été introduit au début des années 1990 [RFC1487], avec la version 3 de LDAP introduite à la fin des années 1990 [RFC2251] révisée ensuite en 2005 [RFC4510].
Bien que beaucoup des matériaux de la RFC 1274 aient été supplantés par les Recommandations de l’UIT-T et les RFC de l’IETF publiées ultérieurement, beaucoup des éléments de schéma manquent de descriptions de schéma normalisées à utiliser dans les services modernes de répertoires X.500 et LDAP en dépit du fait que ces éléments de schéma sont largement utilisés de nos jours. Comme les vieilles descriptions de schéma ne peuvent pas être utilisées sans adaptation, des problèmes d’interopérabilité peuvent survenir du fait de l’absence de descriptions de schémas modernes normalisés.
Le présent document traite cette question en proposant des descriptions de schéma normalisées, lorsqu’il en est besoin, pour les éléments de schéma COSINE les plus utilisés.
Le présent document, conjointement avec la [RFC4519] et la [RFC4517], rend obsolète la RFC 1274 dans sa totalité. La [RFC4519] remplace les paragraphes 9.3.1 (Userid) et 9.3.21 (Composant de domaine) de la RFC 1274. La [RFC4517] remplace le paragraphe 9.4 (Syntaxe généralement utiles) de la RFC 1274.
Le présent document remplace le reste de la RFC 1274. L’appendice A expose les changements survenus depuis la RFC 1274, ainsi que la raison pour laquelle certains éléments de schéma n’ont pas été repris dans la présente révision du schéma COSINE. Tous les éléments non repris sont a considérer comme dépassés.
La description de la classe d’objet 'domain' fournie dans le présent document subroge celle qui se trouve dans la RFC 2247. C’est-à-dire que le paragraphe 3.4 du présent document remplace le paragraphe 5.2 de la [RFC2247].
Certains des éléments de schéma spécifiés ici étaient décrits dans la RFC 2798 (schéma inetOrgPerson). Le présent document se substitue à ces descriptions. Le présent document, conjointement avec la [RFC4519], remplace le paragraphe 9.1.3 de la RFC 2798.
Les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans le BCP 14 [RFC2119].
DIT (Directory Information Tree) signifie arbre d’information de répertoire.
DN (Distinguished Name) signifie nom distinctif.
DSA (Directory System Agent) agent système de répertoire, est un serveur.
DSE (DSA-Specific Entry) signifie entrée spécifique de DSA.
DUA (Directory User Agent) agent d’utilisateur de répertoire, est un client.
Ces termes sont expliqués dans la [RFC4512].
Les définitions de schéma sont fournies en utilisant les formats de description LDAP [RFC4512]. Les définitions fournies ici sont formatées (avec des coupures de ligne) pour en faciliter la lecture.
La présente section détaille les types d’attributs COSINE à utiliser dans LDAP.
L’attribut 'associatedDomain' spécifie les noms d’hôte DNS [RFC1034][RFC2181] [RFC1123] qui sont associés à un objet. C’est-à-dire que les valeurs de cet attribut devraient être conformes à l’ABNF suivant :
domain = root / label *( DOT label )
root = SPACE
label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ]
LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z"
SPACE = %x20 ; espace (" ")
HYPHEN = %x2D ; trait d’union ("-")
DOT = %x2E ; point (".")
Par exemple, l’entrée dans le DIT avec un DN <DC=example,DC=com> pourrait avoir un domaine associé de "example.com".
( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
La syntaxe IA5String (1.3.6.1.4.1.1466.115.121.1.26) et les règles 'caseIgnoreIA5Match' et 'caseIgnoreIA5SubstringsMatch' sont décrites dans la [RFC4517].
Noter que le répertoire ne garantira pas que les valeurs de cet attribut se conforment à la production <domain> fournie ci-dessus. Il est de la responsabilité de l’application de s’assurer que les domaines qu’elle mémorise dans cet attribut sont représentés de façon appropriée.
Noter aussi que les applications qui prennent en charge les noms de domaine internationalisés DOIVENT utiliser la méthode ToASCII [RFC3490] pour produire les composants <label> de la production <domain>.
L’attribut 'associatedName' spécifie les noms des entrées dans le DIT organisationnel associé à un domaine DNS [RFC1034][RFC2181].
( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
La syntaxe DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) et la règle 'distinguishedNameMatch' sont décrites dans la [RFC4517].
L’attribut 'buildingName' spécifie les noms des constructions où une organisation ou unité organisationnelle est localisée, par exemple, "L’Élysée".
( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'co' (diminutif de nom de pays) spécifie les noms des pays en format lisible par l’homme, par exemple, "Allemagne" et "République fédérale d’Allemagne". Il est communément utilisé en conjonction avec l’attribut 'c' (Nom de pays) [RFC4519] (dont les valeurs sont restreintes au code à deux lettres défini dans [ISO3166]).
( 0.9.2342.19200300.100.1.43 NAME 'co'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'documentAuthor' spécifie les noms distinctifs des auteurs (ou éditeurs) d’un document. Pa r exemple,
( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
La syntaxe DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) et la règle 'distinguishedNameMatch' sont décrites dans la [RFC4517].
L’attribut 'documentIdentifier' spécifie des identifiants uniques pour un document. Un document peut être identifié par plus d’un identifiant unique. Par exemple, la RFC 3383 et le BCP 64 sont les identifiants uniques qui (pour l’instant) se réfèrent au même document.
( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'documentLocation' spécifie les localisations du document original.
( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntacx DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règle 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'documentPublisher' désigne les personnes et/ou organisations qui ont publié le document. Les documents qui font l’objet d’une publication conjointe ont une valeur pour chaque éditeur.
( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'documentTitle' spécifie les titres d’un document. Plusieurs valeurs sont permises pour s’accommoder à la fois des titres longs et courts, ou d’autres situations où un document a plusieurs titres, par exemple, "Spécification technique du protocole léger d’accès à un répertoire" et "Spécification technique LDAP".
( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'documentVersion' spécifie les informations de version d’un document.
( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'drink' (favoriteDrink) spécifie les boissons favorites d’un objet (ou personne), par exemple, "cola" et "bière".
( 0.9.2342.19200300.100.1.5 NAME 'drink'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'homePhone' (Numéro de téléphone personnel) spécifie les numéros de téléphone personnels (par exemple, "+1 775 555 1234") associés à une personne.
( 0.9.2342.19200300.100.1.20 NAME 'homePhone'
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
La syntaxe telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) et les règles 'telephoneNumberMatch' et 'telephoneNumberSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'homePostalAddress' spécifie les adresses postales personnelles d’un objet. Chaque valeur devrait être limitée à six chaînes de répertoire de 30 caractères chacune. (Note : Il n’est pas prévu que le service de répertoire mette en application ces limites.)
( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
La syntaxe PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) et les règles 'caseIgnoreListMatch' et 'caseIgnoreListSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'host' spécifie les ordinateurs hôtes, généralement par leur nom de domaine pleinement qualifié principal (par exemple, my-host.example.com).
( 0.9.2342.19200300.100.1.9 NAME 'host'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'info' spécifie toutes les informations générales pertinentes pour un objet. Ces informations ne sont pas nécessairement descriptives de l’objet.
Les applications ne devraient pas lier une sémantique spécifique aux valeurs de cet attribut. L’attribut 'description' [RFC4519] est disponible pour spécifier des informations descriptives pertinentes pour un objet.
( 0.9.2342.19200300.100.1.4 NAME 'info'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
Le type d’attribut 'mail' (rfc822mailbox) détient les adresses de messagerie Internet sous forme Mailbox [RFC2821] (par exemple, user@example.com).
( 0.9.2342.19200300.100.1.3 NAME 'mail'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
La syntaxe IA5String (1.3.6.1.4.1.1466.115.121.1.26) et les règles 'caseIgnoreIA5Match' et 'caseIgnoreIA5SubstringsMatch' sont décrites dans la [RFC4517].
Noter que le répertoire ne va pas s’assurer que les valeurs de cet attribut se conforment à la production <Mailbox> [RFC2821]. Il est de la responsabilité de l’application de s’assurer que les domaines qu’elle mémorise dans cet attribut sont correctement représentés.
De plus, le répertoire va comparer les valeurs selon les règles de correspondance nommées dans la description de type d’attribut ci-dessus. Comme ces règles diffèrent des règles qui s’appliquent normalement aux comparaisons <Mailbox>, des questions de fonctionnement peuvent survenir. Par exemple, l’assertion (mail=joe@example.com) va correspondre à "JOE@example.com" mêms si les <local-parts> diffèrent. Aussi, lorsque un utilisateur a deux <Mailbox> dont les adresses ne diffèrent que par la casse de la <local-part>, elles ne peuvent pas être listées comme valeurs de l’attribut mail de l’utilisateur (car elles sont considérées comme égales par la règle 'caseIgnoreIA5Match').
Noter aussi que les applications qui prennent en charge les noms de domaine internationalisés DOIVENT utiliser la méthode ToASCII [RFC3490] pour produire les composants <sub-domain> de la production <Mailbox>.
L’attribut 'manager' spécifie les gestionnaires, par nom distinctif, de la personne (ou entité).
( 0.9.2342.19200300.100.1.10 NAME 'manager'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
La syntaxe DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) et la règle 'distinguishedNameMatch' sont décrites dans la [RFC4517].
L’attribut 'mobile' (mobileTelephoneNumber) spécifie les numéros de téléphone mobile (par exemple, "+1 775 555 6789") associés à une personne (ou entité).
( 0.9.2342.19200300.100.1.41 NAME 'mobile'
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
La syntaxe telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) et les règles 'telephoneNumberMatch' et 'telephoneNumberSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'organizationalStatus' spécifie les catégories par lesquelles une personne est souvent rapportée à une organisation. Des exemples d’utilisation dans le domaine universitaire comportent "étudiant de première année", "chercheur", "professeur", et "employé". Plusieurs valeurs sont permises lorsque la personne entre dans plusieurs catégories.
Les administrateurs de répertoire et les concepteurs d’application DEVRAIENT considérer avec attention les distinctions entre cet attribut et les attributs 'title' et 'userClass'.
( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'pager' (pagerTelephoneNumber) spécifie les numéros de téléphone de radiomessagerie (par exemple, "+1 775 555 5555") pour un objet.
( 0.9.2342.19200300.100.1.42 NAME 'pager'
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
La syntaxe telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) et les règles 'telephoneNumberMatch' et 'telephoneNumberSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'personalTitle' spécifie les titres personnels pour une personne. "Mme", "Dr.", "Mr.", et "Professeur" sont des exemples de titres personnels.
( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'roomNumber' spécifie le numéro de pièce d’un objet. Durant les périodes de renumérotation, ou dans d’autres circonstances où une pièce a plusieurs numéros de pièce valides qui lui sont associés, plusieurs valeurs peuvent être fournies. Noter que le type d’attribut 'cn' (commonName) DEVRAIT être utilisé pour la dénomination d’objets de pièces.
( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
L’attribut 'secretary' spécifie les secrétaires et/ou assistants administratifs, par nom distinctif.
( 0.9.2342.19200300.100.1.21 NAME 'secretary'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
La syntaxe DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) et la règle 'distinguishedNameMatch' sont décrites dans la [RFC4517].
L’attribut 'uniqueIdentifier' spécifie un identifiant unique pour un objet représenté dans le répertoire. Le domaine au sein duquel l’identifiant est unique et la sémantique exacte de l’identifiant sont définis localement. Pour une personne, cela peut être un numéro d’enrôlement au niveau de l’institution. Pour une unité organisationnelle, cela peut être un code de département.
( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
Note : X.520 décrit aussi un attribut appelé 'uniqueIdentifier' (2.5.4.45), qui est appelé 'x500UniqueIdentifier' dans LDAP [RFC4519]. L’attribut précisé ici ne devrait pas être confondu avec 'x500UniqueIdentifier'.
L’attribut 'userClass' spécifie les catégories d’utilisateur d’ordinateur ou d’application. La sémantique de cet attribut est d’interprétation locale. Des exemples d’utilisation courante de cet attribut dans le domaine universitaire sont "étudient", "employé", et "faculté". Noter que le type d’attrinbut 'organizationalStatus' est maintenant souvent préféré, car il ne fait pas de distinction entre personnes et utilisateurs.
( 0.9.2342.19200300.100.1.8 NAME 'userClass'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) et les règles 'caseIgnoreMatch' et 'caseIgnoreSubstringsMatch' sont décrites dans la [RFC4517].
La présente section précise les classes d’objet COSINE à utiliser dans LDAP.
La classe d’objet 'account' est utilisée pour définir les entrées représentant des comptes d’ordinateur. L’attribut 'uid' DEVRAIT être utilisé pour nommer les entrées de cette classe d’objets.
( 0.9.2342.19200300.100.4.5 NAME 'account'
SUP top STRUCTURAL
MUST uid
MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
La classe d’objet 'top' est décrite dans la [RFC4512]. Les types d’attribut 'description', 'seeAlso', 'l', 'o', 'ou', et 'uid' sont décrits dans la [RFC4519]. Le type d’attribut 'host' est décrit à la Section 2 du présent document.
dn: uid=kdz,cn=Accounts,dc=Exemple,dc=COM
objectClass: account
uid: kdz
seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Exemple,dc=COM
La classe d’objet 'document' est utilisée pour définir des entrées qui représentent des documents.
( 0.9.2342.19200300.100.4.6 NAME 'document'
SUP top STRUCTURAL
MUST documentIdentifier
MAY ( cn $ description $ seeAlso $ l $ o $ ou $
documentTitle $ documentVersion $ documentAuthor $
documentLocation $ documentPublisher ) )
La classe d’objet 'top' est décrite dans la [RFC4512]. Les types d’attribut 'cn', 'description', 'seeAlso', 'l', 'o', et 'ou' sont décrits dans la [RFC4519]. Les types d’attribut 'documentIdentifier', 'documentTitle', 'documentVersion', 'documentAuthor', 'documentLocation', et 'documentPublisher' sont décrits dans la Section 2 du présent document.
Exemple :
dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM
objectClass: document
documentIdentifier: RFC 4524
documentTitle: Schéma COSINE LDAP/X.500
documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt
documentPublisher: Internet Engineering Task Force
description: Collection d’éléments de schéma à utiliser dans LDAP
description: Rend obsolète la RFC 1274
seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM
seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM
La classe d’objet 'documentSeries' est utilisée pour définir une entrée qui représente une série de documents (par exemple, les mémos de Request For Comments).
( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
SUP top STRUCTURAL
MUST cn
MAY ( description $ l $ o $ ou $ seeAlso $
telephonenumber ) )
La classe d’objet 'top' est décrite dans la [RFC4512]. Les types d’attribut 'description', 'l', 'o', 'ou', 'seeAlso', et 'telephoneNumber' sont décrits dans la [RFC4519].
Exemple
dn: cn=RFC,dc=Exemple,dc=COM
objectClass: documentSeries
cn: Request for Comments
cn: RFC
description: série de mémos sur l’Internet
La classe d’objet 'domain' est utilisée pour définir les entrées qui représentent les domaines DNS pour les objets qui ne sont pas des organisations, des unités organisationnelles, ou autres sortes d’objets définis de façon plus appropriée en utilisant une classe d’objets spécifique de la sorte d’objet définis (par exemple, 'organization', 'organizationUnit').
L’attribut 'dc' devrait être utilisé pour dénommer les entrées de la classe d’objets 'domain'.
( 0.9.2342.19200300.100.4.13 NAME 'domain'
SUP top STRUCTURAL
MUST dc
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationaliSDNNumber $ facsimileTelephoneNumber $ street $
postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l $ description $ o $
associatedName ) )
La classe d’objet 'top' et les types 'dc', 'userPassword', 'searchGuide', 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress', 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', 'teletexTerminalIdentifier', 'telephoneNumber', 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', 'postOfficeBox', 'postalCode', 'postalAddress', 'physicalDeliveryOfficeName', 'st', 'l', 'description', et 'o' sont décrits dans la [RFC4519]. Le type d’attribut 'associatedName' est décrit à la Section 2 du présent document.
Exemple:
dn: dc=com
objectClass: domain
dc: com
description: the .COM TLD
La classe d’objet 'domainRelatedObject' est utilisée pour définir les entrées qui représentent les domaines DNS qui sont "équivalents" à un domaine X.500, par exemple, une organisation ou unité organisationnelle.
( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
SUP top AUXILIARY
MUST associatedDomain )
La classe d’objet 'top' est décrite dans la [RFC4512]. Le type d’attribut 'associatedDomain' est décrit à la Section 2 du présent document.
Exemple:
dn: dc=example,dc=com
objectClass: organization
objectClass: dcObject
objectClass: domainRelatedObject
dc: example
associatedDomain: example.com
o: Exemple Organization
Les classes d’objet 'organization' et 'dcObject' et les types d’attribut 'dc' et 'o' sont décrits dans la [RFC4519].
La classe d’objet 'friendlyCountry' est utilisée pour définir les entrées qui représentent les pays dans le DIT. La classe d’objet est utilisée pour permettre une dénomination plus lisible des payx que ce qui est permis par la classe d’objet 'country' [RFC4519].
( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
SUP country STRUCTURAL
MUST co )
La classe d’objet 'country' est décrite dans la [RFC4519]. Le type d’attribut 'co' est décrit à la Section 2 du présent document.
Exemple:
dn: c=DE
objectClass: country
objectClass: friendlyCountry
c: DE
co: Deutschland
co: Germany
co: Federal Republic of Germany
co: FRG
Le type d’attribut 'c' est décrit dans la [RFC4519].
La classe d’objet 'rFC822LocalPart' est utilisée pour définir les entrées qui représentent la partie locale des adresses de messagerie Internet [RFC2822]. Elle traite la partie locale de l’adresse comme un objet 'domain'.
( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart'
SUP domain STRUCTURAL
MAY ( cn $ description $ destinationIndicator $
facsimileTelephoneNumber $ internationaliSDNNumber $
physicalDeliveryOfficeName $ postalAddress $ postalCode $
postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
seeAlso $ sn $ street $ telephoneNumber $
teletexTerminalIdentifier $ telexNumber $ x121Address ) )
La classe d’objet 'domain' est décrite au paragraphe 3.4 du présent document. Les types d’attribut 'cn', 'description', 'destinationIndicator', 'facsimileTelephoneNumber', 'internationaliSDNNumber, 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode', 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress', 'seeAlso', 'sn, 'street', 'telephoneNumber', 'teletexTerminalIdentifier', 'telexNumber', et 'x121Address' sont décrits dans la [RFC4519].
Exemple :
dn: dc=kdz,dc=example,dc=com
objectClass: domain
objectClass: rFC822LocalPart
dc: kdz
associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Exemple,dc=COM
Le type d’attribut 'dc' est décrit dans la [RFC4519].
La classe d’objet 'room' est utilisée pour définir les entrées qui représentent les pièces. L’attribut 'cn' (commonName) DEVRAIT être utilisé pour nommer les entrées de cette classe d’objet.
( 0.9.2342.19200300.100.4.7 NAME 'room'
SUP top STRUCTURAL
MUST cn
MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
La classe d’objet 'top' est décrite dans la [RFC4512]. Les types d’attribut 'cn', 'description', 'seeAlso', et 'telephoneNumber' sont décrits dans la [RFC4519]. La type d’attribut 'roomNumber' est décrit à la Section 2 du présent document.
dn: cn=conference room,dc=example,dc=com
objectClass: room
cn: conference room
telephoneNumber: +1 755 555 1111
La classe d’objet 'simpleSecurityObject' est utilisée pour demander à une entrée d’avoir un attribut 'userPassword' lorsque la classe d’objet structurelle de l’entrée n’exige pas (ou permet) le 'userPassword attribute'.
( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
SUP top AUXILIARY
MUST userPassword )
La classe d’objet 'top' est décrit dans la [RFC4512]. Le type d’attribut 'userPassword' est décrit dans la [RFC4519].
dn: dc=kdz,dc=Exemple,dc=COM
objectClass: account
objectClass: simpleSecurityObject
uid: kdz
userPassword: My Password
seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Exemple,dc=COM
Les considérations générales sur la sécurité de LDAP [RFC4510] sont applicables à l’utilisation de ce schéma. Des considérations supplémentaires sont notées ci-dessus aux endroits appropriés.
Les administrateurs de répertoires devraient s’assurer que l’accès aux informations sensibles est réservé aux entités autorisées et que les services appropriés de sécurité des données, y compris l’intégrité des données et la confidentialité des données, sont utilisés comme protection contre l’espionnage.
Les mécanismes de simple authentification (par exemple, les mots de passe de texte en clair) ne devraient être utilisés que lorsque sont en place des services adéquats de sécurité des données. LDAP offre des services d’authentification et de sécurité des données raisonnablement forts [RFC4513].
L’Autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Numbers Authority) a mis à jour le registre des descripteurs LDAP [RFC4520] comme indiqué dans le modèle suivant :
Sujet : Demande de mise à jour d’enregistrement de descripteur LDAP
Descripteur (nom abrégé) : voir les commentaires
Identifiant d’objet : voir les commentaires
Personne & adresse de messagerie à contacter pour des précisions : Kurt Zeilenga kurt@OpenLDAP.org
Usage : voir les commentaires
Spécification : RFC 4524
Auteur/Contrôleur des modifications : IESG
Commentaires :
Les descripteurs suivants ont été mis à jour pour se référer à la RFC 4524.
NOM |
Type |
OID |
account |
O |
0.9.2342.19200300.100.4.5 |
associatedDomain |
A |
0.9.2342.19200300.100.1.37 |
associatedName |
A |
0.9.2342.19200300.100.1.38 |
buildingName |
A |
0.9.2342.19200300.100.1.48 |
co |
A |
0.9.2342.19200300.100.1.43 |
document |
O |
0.9.2342.19200300.100.4.6 |
documentAuthor |
A |
0.9.2342.19200300.100.1.14 |
documentIdentifier |
A |
0.9.2342.19200300.100.1.11 |
documentLocation |
A |
0.9.2342.19200300.100.1.15 |
documentPublisher |
A |
0.9.2342.19200300.100.1.56 |
documentSeries |
O |
0.9.2342.19200300.100.4.8 |
documentTitle |
A |
0.9.2342.19200300.100.1.12 |
documentVersion |
A |
0.9.2342.19200300.100.1.13 |
domain |
O |
0.9.2342.19200300.100.4.13 |
domainRelatedObject |
O |
0.9.2342.19200300.100.4.17 |
drink |
A |
0.9.2342.19200300.100.1.5 |
favouriteDrink |
A* |
0.9.2342.19200300.100.1.5 |
friendlyCountry |
O |
0.9.2342.19200300.100.4.18 |
friendlyCountryName |
A* |
0.9.2342.19200300.100.1.43 |
homePhone |
A |
0.9.2342.19200300.100.1.20 |
homePostalAddress |
A |
0.9.2342.19200300.100.1.39 |
homeTelephone |
A* |
0.9.2342.19200300.100.1.20 |
host |
A |
0.9.2342.19200300.100.1.9 |
info |
A |
0.9.2342.19200300.100.1.4 |
A |
0.9.2342.19200300.100.1.3 |
|
manager |
A |
0.9.2342.19200300.100.1.10 |
mobile |
A |
0.9.2342.19200300.100.1.41 |
mobileTelephoneNumber |
A* |
0.9.2342.19200300.100.1.41 |
organizationalStatus |
A |
0.9.2342.19200300.100.1.45 |
pager |
A |
0.9.2342.19200300.100.1.42 |
pagerTelephoneNumber |
A* |
0.9.2342.19200300.100.1.42 |
personalTitle |
A |
0.9.2342.19200300.100.1.40 |
rFC822LocalPart |
O |
0.9.2342.19200300.100.4.14 |
rfc822Mailbox |
A* |
0.9.2342.19200300.100.1.3 |
room |
O |
0.9.2342.19200300.100.4.7 |
roomNumber |
A |
0.9.2342.19200300.100.1.6 |
secretary |
A |
0.9.2342.19200300.100.1.21 |
simpleSecurityObject |
O |
0.9.2342.19200300.100.4.19 |
singleLevelQuality |
A |
0.9.2342.19200300.100.1.50 |
uniqueIdentifier |
A |
0.9.2342.19200300.100.1.44 |
userClass |
A |
0.9.2342.19200300.100.1.8 |
où le type A est Attribut, le type O est ObjectClass, et * indique que l’enregistrement est intrinsèquement dépassé.
Le présent document est fondé sur la RFC 1274, par Paul Barker et Steve Kille, ainsi que sur la RFC 2247, par Steve Kill, Mark Wahl, Al Grimstad, Rick Huber, et Sri Satulari.
[RFC1034] Mockapetris, P., "Noms de domaines - concepts et facilitées", STD 13, novembre 1987.
[RFC1123] Braden, R., "Exigences pour les hôtes Internet -Application et prise en charge", STD 3, octobre 1989.
[RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigences", BCP 14, mars 1997.
[RFC2181] Elz, R. et R. Bush, "Précisions sur le spécification DNS", juillet 1997.
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., et S. Sataluri, "Utilisation des domaines dans les noms distinctifs LDAP/X.500", janvier 1998.
[RFC2821] Klensin, J., éditeur, "Protocole simple de transfert de messagerie", avril 2001.
[RFC2822] Resnick, P., "Format de message Internet", avril 2001.
FC3490] Faltstrom, P., Hoffman, P., et A. Costello, "Internationalisation des noms de domaines dans les applications (IDNA)", mars 2003.
[RFC4510] Zeilenga, K., éditeur, "Protocole léger d’accès à un répertoire (LDAP) : Descriptif des spécifications techniques", juin 2006.
[RFC4512] Zeilenga, K., "Protocole léger d’accès à un répertoire (LDAP) : Modèles d’information des répertoires", juin 2006.
[RFC4513] Harrison, R., "Protocole léger d’accès à un répertoire (LDAP) : Méthodes d’authentification et mécanismes de sécurité", juin 2006.
[RFC4517] Legg, S., éditeur, "Protocole léger d’accès à un répertoire (LDAP) : Syntaxes et règles de correspondance", juin 2006.
[RFC4519] Sciberras, A., éditeur, "Protocole léger d’accès à un répertoire (LDAP) : Schéma pour les applications d’utilisateur", juin 2006.
[X.501] Union Internationale des Télécommunications – Secteur de la normalisation des Télécommunications, "L’annuaire -- Modèles," (1993) (aussi ISO/CEI 9594- 2:1994).
[COSINEpilot] Goodman, D., "PARADISE" section de mars 1991 INTERNET MONTHLY REPORTS (p. 28-29), http://www.iana.org/periodic-reports/imr-mar91.txt
[ISO3166] Organization International de normalisation, "Codes pour la représentation de noms de pays", ISO 3166.
[RFC1274] Barker, P. et S. Kille, "Le schéma COSINE et Internet X.500", novembre 1991.
[RFC1279] Hardcastle-Kille, S., "X.500 et les domaines", novembre 1991.
[RFC1487] Yeong, W., Howes, T., et S. Kille, "Protocole léger d’accès à un répertoire X.500", juillet 1993.
[RFC2251] Wahl, M., Howes, T., et S. Kille, "Protocole léger d’accès à un répertoire (v3)", décembre 1997.
[RFC2798] Smith, M., "Définition de la classe d’objet LDAP inetOrgPerson", avril 2000.
[RFC3494] Zeilenga, K., "Vers le dépassement du Protocole léger d’accès à un répertoire version 2 (LDAPv2)", mars 2003.
[RFC4520] Zeilenga, K., "Considérations de l’Autorité d’allocation des numéros de l’Internet (IANA) sur le Protocole léger d’accès à un répertoire (LDAP)", BCP 64.
Le présent document représente une réécriture substantielle de la RFC 1274. Les paragraphes suivants résument les changements de substance.
Un certain nombre de types d’attribut COSINE ont des noms abrégés dans LDAP.
Nom X.500 |
Nom abrégé LDAP |
domainComponent |
dc |
favoriteDrink |
drink |
friendCountryName |
co |
homeTelephoneNumber |
homePhone |
mobileTelephoneNumber |
mobile |
pagerTelephoneNumber |
pager |
rfc822Mailbox |
|
userid |
uid |
Alors que les noms abrégés LDAP sont généralement utilisés dans LDAP, certaines mises en oeuvre peuvent (par habitude [RFC3494]) reconnaître le type d’attribut par son nom X.500. Et donc, les noms X.500 ont été réservés à cette seule fin.
Note : 'uid' et 'dc' sont décrits dans la [RFC4519].
La classe d’objet 'pilotObject' n’a pas été reprise car sa fonction est largement remplacée par des attributs de fonctionnement introduits dans X.500 (93) [X.501] et dans la version 3 de LDAP [RFC4512]. Par exemple, la fonction des types d’attribut 'lastModifiedBy' et 'lastModifiedTime' est maintenant remplie par les attributs de fonctionnement 'creatorsName', 'createTimestamp', 'modifiersName', et 'modifyTimestamp' [RFC4512].
La classe d’objet 'pilotPerson' n’a pas été reprise car sa fonction est largement remplacée par la classe d’objet 'organizationalPerson' [RFC4512] et ses sous-classes, comm 'inetOrgPerson' [RFC2798].
La plupart des types d’attribut qui s’y rapportent (par exemple, 'mail', 'manager') ont été repris car ils sont utilisés dans d’autres classes d’objet.
La classe d’objet 'dNSDomain' et les types d’attribut qui s’y rapportent n’a pas été reprise car son utilisation était principalement expérimentale [RFC1279].
Les classes d’objet 'pilotDSA' et 'qualityLabelledData', ainsi que les types d’attribut qui s’y rapportent, n’ont pas été reprises car leur utilisation était principalement expérimentale [QoS].
La RFC 1274 définissait et utilisait la syntaxze d’attribut caseIgnoreIA5StringSyntax. Ceci a été remplacé par la syntaxe IA5String et des règles de correspondance appropriées dans 'mail' et 'associatedDomain'.
La RFC 1274 contraignait 'mail' à avoir des valeurs de longueur différente de zéro. Cette restriction n’est pas reflétée dans la syntaxe IA5String utilisée dans les définitions fournies dans la présente spécification. Cependant, comme les valeurs doivent se conformer à la production <Mailbox>, 'mail' ne devrait pas contenir de valeurs de longueur zéro. Malheureusement, le service de l’annuaire ne met pas cette restriction en application.
La forme de nom 'domainNameForm' n’a pas été reprise car la spécification des formes de nom utilisées dans LDAP fera l’objet d’une future spécification.
Adresse de l'éditeur
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Déclaration de copyright
Copyright (C) The Internet Society (2006).
Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.
Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.
Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.
Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.
L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.
Remerciement
Le financement de la fonction d’édition des RFC est fourni par la Administrative Support Activity (IASA) de l'IETF.