Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
01 octobre 2014

htmlpdflatexmanmd




draft-armijo-ldap-treedelete-02

draft-armijo-ldap-treedelete-02

Contrôle de suppression d'arborescence

   Le contrôle est inclu dans un message DelRequest comme partie du champ controls. Le controlType est 1.2.840.113556.1.4.805, la criticité peut être TRUE ou FALSE, et controlValue est absent.

   Ce contrôle permet à un client de supprimer un subtree complet. Cela peut être fait seulement si l'utilisateur authentifié a les permissions pour compléter l'opération. Le serveur doit vérifier pour voir si l'utilisateur authentifié a les permissions appropriées pour supprimer l'objet et tous ses descendants. Ce contrôle doit seulement être utilisé avec un message DelRequest. Un serveur doit ignorer le contrôle s'il est utilisé avec un autre message sauf si la criticité est spécifiée. Dans ce cas, toute l'opération doit échouer avec le resultCode unsupportedCriticaleExtension. Les serveur prenant en compte ce contrôle doivent le lister dans supportedControl dans le rootDSE.

Sémantique

   Le demande tree delete peut être traitée comme une simple transaction atomique ou comme une séquence de transaction atomique. Dans le dernier cas, tous les états visible par le client produit par l'opération sont consistant avec l'exécution d'une séquence de demande delete normale. Le serveur ne devrait pas laisser traiter les objets d'un manière qui puisse laisser les objets orphelins.

   Si une demande tree delete échoue pour une quelconque raison, il peut être retenté et, si la nouvelle tentative réussi, le résultat est le même que si la demande initiale avait réussi. Le client devrait ré-émettre le delRequest jusqu'à ce que le serveur retourne un succès.

   Si un client émet une demande pour déplacer un objet dans ( ou créer un objet dans ) ou hors du subtree, en concurrence avec l'exécution d'une demande tree delete, l'effet est indéfinis. Le serveur n'est pas obligé de bloquer de telles requêtes.

   Le serveur ne doit pas poursuivre les références stockées dans l'arborescence. Si l'information sur les référants est stocké dans cet section, ce pointeur est supprimé.

Messages d'erreur

   Quand le contrôle tree delete est invoqué, le serveur doit vérifier pour voir si l'utilisateur authentifié a les permissions appropriées pour supprimer l'objet et toutes ses descendances. Si l'utilisateur n'a pas les permissions appropriées, un insufficientAccessRights(50) est retourné.

   Le serveur doit identifier tous les objets à supprimer avant que la suppression commence. Si le serveur a un problème à identifier les objets à supprimer, il peut retourner un operationsError(1). L'opération peut être re-tentée si cette erreur est retournée. Si le serveur n'a pas autorité sur des objets dans le subtree, le serveur devrait retourner unwillingToPerform(53).

   Les implémentation de serveurs peuvent avoir d'autres restriction sur quels conteneurs peuvent ou ne peuvent pas utiliser le contrôle Tree Delete. Si vous tentez de supprimer un conteneur qui ne peut pas être supprimé du à une restriction spécifique à la plate-forme, le serveur doit retourner unwillingToPerform(53). Le contrôle Tree Delet ne devrait par être re-tenté sur ce conteneur.

   Si la limite du nombre d'objets qui peuvent être supprimés en une opération est atteinte, le serveur devrait retourner adminLimitExceeded(11). Les objets traités jusqu'à ce point de limite devraient être supprimés. la demande DelRequest avec le contrôle Tree Delete devrait être ré-émis jusqu'à ce qu'une réponse success soit retourné par le serveur.
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-automounter-04

draft-bannister-dbis-automounter-04

dbis: maps d'auto-montage

   Ce document étends DBIS pour supporter les bases automount. Le schéma de base automount devrait être compatible avec NIS, mais stocké dans des entrées X.500 pour qu'ils puissent être résolus via LDAP. Une base automount contient les informations sur les points de montage du système qui sont mappés par l'automonteur.

Maps de configuration

La base automount utilise les maps de configuration standard définis dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les base automount devraient avoir la classe dbisAutomountConfig. Il est recommandé que l'entrée dbisMapConfig pour une base automount ai d'attribut dbisMapFilter définis en accord avec la table suivante:
- - - - - - - - - - - - - - - - - - - - - - -
Database- - - dbisMapFilter
- - - - - - - - - - - - - - - - - - - - - - -
automount- -- objectClass=automountMapObject
- - - - - - - - - - - - - - - - - - - - - - -

Exemple d'entrée de map de configuration

L'exemple suivant donne un exemple d'une entrée de map de configuration pour une base automount:
dn: cn=automount,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisAutomountConfig
cn: automount
dbisMapDN: cn=automount,ou=dbis,o=infra
dbisMapFilter: objectClass=automountMapObject
profileTTL: 900
description: Primary automount database

Base de données

   Une base automount contient 3 types d'entrées différentes:

- Des entrées de map master
- Des entrées de map Direct
- Des entrées de map Indirect

   Une entrée master contient les informations suivantes:

- Le chemin à monter, ou /- pour les maps directs
- Le nom de map contenant les informations de montage pour ce chemin
- Les options de montage

   Une entrée directe contient:

- Le nom complet du point de montage
- Les options de montage
- Un ou plusieurs emplacement de système de fichier

   Une entrée indirecte contient:

- La clé utilisé pour déterminer le nom de la feuille de point de montage
- Les options de montage
- Un ou plusieurs emplacement de système de fichier

   Les maps directe et indirecte peuvent également inclure des entrées d'autre maps nommées. Une entrée à montage multiple définis plusieurs points de montage pour une seule clé dans une map indirect.

   Les options de montage, les symboles de substitution et wildcard peuvent être supportés par une implémentation mais sont au-delà du scope de ce document. Ce schéma n'applique aucune restriction sur l'utilisation d'options ou de symboles spéciaux, ni ne tente de les définir. À la place, ce document recherche à décrire un schéma et une structure qui supporte toute implémentation.

ObjectClass

   Une entrée dbisMapConfig pour une base automount devrait avoir la classe dbisAutomountConfig. Une entrée de map master devrait être définie par une entrée avec la classe automountMaster, qui est un sous-classe de automountMapObject. Une map directe ou indirecte devrait être identifiée par la classe automountMapObject. Les entrées dans une map donnée doivent être des objets enfant dans le DIT de la map à laquelle elle appartient et utiliser la classe automountEntry. Il n'y a pas de telles restriction d'emplacement sur les entrées automountMapObject, qui peuvent être localisées n'importe où dans le DIT tant qu'ils sont localisé par dbisMapDN et dbisMapFilter.

   La classe automountMulti devrait être utilisée pour identifier l'objet top-level dans une entrée de montage multiple. Chaque entrée dans le montage multiple devrait être un objet enfant dans le DIT avec la classe automountEntry. Un DUA peut choisir de ne pas supporter les entrées de montage multiples.

   Une map directe ou indirecte peut inclure les entrées d'une autre map par une entrée avec la classe automountInclude, qui devrait être un objet enfant dans le DIT d'un automountMapObject ou un automountMulti.

dbisAutomountConfig

La classe dbisAutomountConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.27 NAME 'dbisAutomountConfig' DESC 'DBIS automount configuration map' SUP dbisMapConfig STRUCTURAL )

automountMapObject

La classe automountMapObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.28 NAME 'automountMapObject' DESC 'Top-level of an automount map, entries are child nodes' SUP top STRUCTURAL MUST en MAY ( description $ manager $ disableObject ) )

automountMaster

La classe automountMaster est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.29 NAME 'automountMaster' DESC 'Automounter master map entry' SUP automountMapObject STRUCTURAL MUST automountUseMap MAY automountOption )

automountEntry

La classe automountEntry est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.31 NAME 'automountEntry' DESC 'Automounter direct or indirect map entry' SUP top STRUCTURAL MUST ( en $ automountLocation ) MAY ( automountOption $ description $ manager $ disableObject ) )

   Les entrées de cette classe devraient être des objets enfant dans le DIT de l'automountMapObject auquel il appartient, sauf si elles font partie d'une montage multiple auquel cas elles doivent être enfant de leur entrée automountMulti correspondante.

automountInclude

La classe automountInclude est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.32 NAME 'automountInclude' DESC 'Include another map within an automounter direct map, indirect map or multiple mount entry' SUP top STRUCTURAL MUST en MAY ( description $ manager $ disableObject ) )

   Le nom de la map à inclure devrait être fournie dans l'attribut en. Les règles pour localiser une entrée automountInclude dans le DIT sont les mêmes que pour une entrée automountEntry.

Attributs

en

   Le chemin à monter, la clé utilisée dans la map indirecte, ou le nom d'une map à inclure lorsqu'utilisé avec la classe automountInclude, est stocké dans l'attribut en, qui est définis dans draft-bannister-dbis-mapping. Ce attribut doit être associé avec les entrées automountMapObject, automountMaster, automountMulti, automountEntry et automountInclude et devrait former le RDN dans tous les cas.

automountUseMap

Le nom de la map d'auto-montage à utiliser avec l'entrée de map master est stocké dans l'attribut automountUseMap qui doit être assigné à une entrée automountMaster:
attributetype ( 1.3.6.1.4.1.23780.219.2.31 NAME 'automountUseMap' DESC 'Name of automount map associated with master map entry' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

automountOption

Chaque option d'auto-montage est stocké dans un ou plusieurs attributs automountOption qui peuvent être assignés à une entrée automountMaster, automountEntry ou automountMulti:
attributetype ( 1.3.6.1.4.1.23780.219.2.32 NAME 'automountOption' DESC 'Automounter option' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Les options disponibles sont spécifique à l'implémentation. Les options d'auto-montage ne sont pas additifs, par exemple, les options d'un automountEntry, si fournis, devraient écraser les options dans une entrée automountMulti ou automountMaster. Les options d'une entrée automountMulti devraient écraser les options d'une entrée automountMaster.

automountLocation

Le serveur de fichier et le chemin sont fournis dans un ou plusieurs attributs automountLocation qui doivent être assignés à un automountEntry:
attributetype ( 1.3.6.1.4.1.23780.219.2.33 NAME 'automountLocation' DESC 'Automounter location e.g. server:path' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Le format est spécifique à l'implémentation, mais typiquement "server:path". Le composant serveur peut être optionnel mais l'option (:) et le composant chemin ne le sont pas. Certaines implémentations supportent également plusieurs serveurs séparés par des virgules, ex, serverA,serverB:path, et des options de poids, ex, serverA(2),serverB(1):path, pour spécifier une préférence pour le second serveur dans la liste.

description

   L'attribut description peut être associé avec une entrée pour fournir une description arbitraire de l'entrée.

manager

   L'attribut manager peut être associé avec une entrée pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsables de la maintenance de l'entrée.

disableObject

   Une entrée peut être désactivée en définissant disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si l'entrée n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivé, mais doivent les marquer clairement comme désactivé pour éviter toute confusion.

Exemple d'entrées d'auto-montage

L'exemple suivant montre des entrées automountMaster au format LDIF:
dn: en=/home,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /home
automountOption: nobrowse
automountUseMap: auto_home
description: Master entry for /home, see auto_home map
    
dn: en=/qa,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /qa
automountUseMap: qa
description: Master entry for /qa, see qa map
    
dn: en=/media,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /media
automountUseMap: media
description: Master entry for /media, see media map
    
dn: en=/-,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /-
automountUseMap: auto_direct
description: Master entry for direct maps, see auto_direct

L'exemple suivant montre des entrées de map direct:
dn: en=auto_direct,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: auto_direct
description: auto_direct map entries are child objects
    
dn: en=/usr/install,en=auto_direct,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /usr/install
automountOption: ro
automountLocation: esher,kingston(1):/export/install
automountLocation: hampton(3):/usr/install
description: Mount /usr/install from three possible servers

L'exemple suivant montre des entrées de map indirect:
dn: en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: auto_home
description: auto_home map entries are child objects
    
dn: en=fred,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: fred
automountLocation: surbiton:/export/home/&
description: /home/fred
    
dn: en=sheila,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: sheila
automountLocation: surbiton:/export/home/&
description: /home/sheila
    
dn: en=*,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en:    *
automountLocation: ditton:/export/home/&
description: Catch-all for user home directories not listed
    
dn: en=surrey_home,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountInclude
en: surrey_home
description: Include entries from surrey_home map

L'exemple suivant montre un autre entrée de map indirect:
dn: en=media,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: media
description: media map entries are child objects
    
dn: en=cdrom,en=media,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: cdrom
automountOption: fstype=hsfs
automountOption: ro
automountLocation: :/dev/sr0
description: /media/cdrom

L'exemple suivant montre une entrée à montage multiple:
dn: en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: qa
description: qa map entries are child objects
    
dn: en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMulti
en: qa_root
automountOption: ro
description: qa_root multi-mount entries are child objects
    
dn: en=/,en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /
automountLocation: esher:/export/qa
description: /qa
    
dn: en=/docs,en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /docs
automountLocation: surbiton:/export/qa/docs
description: /qa/docs
    
dn: en=/tmp,en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /tmp
automountOption: rw
automountLocation: surbiton:/export/qa/tmp
description: /qa/tmp

Syntaxe d'attributs

Les syntaxes d'attribut suivant sont utilisés par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax OID - - - - - - - - - -Value - - - - - - Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.12 DN - - - - - - - -[RFC4517]
1.3.6.1.4.1.1466.115.121.1.26 IA5 String - - - -[RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Mappage des champs NIS

   Tous les champs qui sont requis pour générer des format de base d'auto-montage NIS existent dans ce schéma et peuvent être mappés en utilisant les production ABNF décrites dans draft-bannister-dbis-netgroup.

Les champs de map master sont mappés comme suit:
mount-point = en
map-name = automountUseMap
mount-option = automountOption
    
master-entry = mount-point SPACE map-name *(SPACE mount-option)

Les champs de map directe sont mappés comme suit:
mount-point = en ; from automountEntry
mount-option = automountOption ; from automountEntry
location = automountLocation ; from automountEntry
include-map = en ; from automountInclude
    
mount = mount-point *(SPACE mount-option)
     1*(SPACE location)
include = PLUS include-map
    
direct-entry = mount / include

Les champs de map indirecte sont mappés comme suit:
mount-point = en ; from automountEntry
mount-option = automountOption ; from automountEntry
location = automountLocation ; from automountEntry
multi-key = en ; from parent automountMulti
multi-option = automountOption ; from parent automountMulti
include-map = en ; from automountInclude
    
mount = mount-point *(SPACE mount-option) 1*(SPACE location)
multi-mount = multi-key *(SPACE multi-option) 1*(LF SPACE mount-point *(SPACE mount-option) 1*(SPACE location))
include = PLUS include-map
    
direct-entry = mount / multi-mount / include

Filtres de recherche communs

   Cette section fournis des exemples de filtre de recherche pour obtenir des entrées de base avec des critères communément utilisés.

   Pour simplifier les exemples, toutes les base sont assumées être définies avec une simple map de configuration. Cependant, dbis permet plusieurs entrées, donc une implémentation doit le supporter, augmentant le nombre de recherches nécessaires pour localiser toutes les entrées de base.

   Le DN de base utilisé dans les opérations de recherche décrites dans cette section provient de l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter qu'une entrée dbisMapConfig peut en avoir plus d'une.

   Quand il apparaît dans les filtres de recherche ci-dessous, le texte "dbisMapFilter" réfère à la valeur assignée à l'attribut de même nom dans l'entrée dbisMapConfig correspondante. Les noms de classe et attribut utilisés dans ces filtres de recherche peuvent être modifiés par dbisMapClass et dbisMapAttr assignés à l'entrée dbisMapConfig.

Pour localiser la map de configuration d'un domaine DBIS:
(&(objectClass=dbisAutomountConfig)(!(disableObject=TRUE)))
Les maps master sont énumérées en appliquant le dbisMapFilter comme suit:
(&(dbisMapFilter)(objectClass=automountMaster)(!(disableObject=TRUE)))
Les maps directes et indirectes sont énumérées par le filtre suivant:
(&(dbisMapFilter)(!(objectClass=automountMaster))(!(disableObject=TRUE)))
Les entrées de map sont énumérée par le filtre suivant:
(&(objectClass=automountEntry)(!(disableObject=TRUE)))

   Pour différencier entrée une entrée de map simple et une entrée à montage multiple, l'objectClass dans l'entrée parent doit être testée. Si la classe est automountMulti, alors cette entrée fait partie d'une entrée à montage multiple. Dans ce cas, le DUA devrait tester disableObject=TRUE sur l'objet automountMulti. Si cet objet est marqué désactivé, les entrées enfant devraient également être traités comme désactivés.

Les entrées à montage multiples sont énumérées par le filtre suivant:
(&(objectClass=automountMulti)(!(disableObject=TRUE)))
Pour localiser une map spécifique appelée "name", utiliser le filtre suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name))
Pour lister toutes les maps à inclure par une map spécifique appelée "name", utiliser le filtre précédent pour localiser le DN de la map, puis utiliser sur tous les objets enfants:
(&(objectClass=automountInclude)(!(disableObject=TRUE)))
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-custom-03

draft-bannister-dbis-custom-03

dbis: maps custom

   Ce document étend DBIS pour supporter des bases custom. Le schéma de base custom devrait être compatible avec NIS mais stocké dans des entrées X.500 pour qu'ils puissent être résolus avec LDAP. Une base custom contient des paires de clé/valeurs arbitraires.

Maps de configuration

   Une base custom utilise les maps de configuration standard définies dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les bases custom devraient avoir la classe dbisCustomConfig pour identifier qu'ils sont liés à une base custom.

Il est recommandé que l'entrée dbisMapConfig pour une base custom ait l'attribut dbisMapFilter définis en accord avec la table suivante:
- - - - - - - - - - - - - - - - - - - - -
Database- - - dbisMapFilter
- - - - - - - - - - - - - - - - - - - - -
custom- - - - objectClass=customMapEntry
- - - - - - - - - - - - - - - - - - - - -

Exemple d'entrée de map de configuration

L'exemple suivant montre une entrée de map de configuration pour une base custom appelée "console":
dn: cn=cons,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisCustomConfig
cn: cons
customMapName: console
dbisMapDN: ou=console,ou=dbis,o=infra
dbisMapFilter: objectClass=customMapEntry
profileTTL: 900
description: Primary console database (custom map)

Base de données

   Une entrée de base de données custom contient les informations suivantes:

- Un nom de clé
- Une valeur

ObjectClass

   Une entrée dbisMapConfig pour une base custom devrait avoir la classe dbisCustomConfig. Les entrées de map custom devraient avoir la class customMapEntry

dbisCustomConfig

La classe dbisCustomConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.33 NAME 'dbisCustomConfig' DESC 'DBIS custom database configuration map' SUP dbisMapConfig STRUCTURAL MUST customMapName )

customMapEntry

La classe customMapEntry est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.35 NAME 'customMapEntry' DESC 'DBIS custom map entry' SUP top STRUCTURAL MUST ( en $ customMapValue ) MAY ( description $ disableObject ) )

Attributs

customMapName

Le nom de la map custom est stockée dans l'attribut customMapName qui doit être assigné à une entrée dbisCustomConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.34 NAME 'customMapName' DESC 'Name of DBIS custom map' EQUALITY caseExactMatch SINGLE-VALUE SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

en

   Chaque clé de l'entrée de map custom est stockée dans l'attribu en qui doit être associé avec des entrées customMapEntry et devrait former le RDN.

customMapValue

Chaque valeur de l'entrée est stockée dans l'attribut customMapValue qui doit être assigné à un customMapEntry:
attributetype ( 1.3.6.1.4.1.23780.219.2.35 NAME 'customMapValue' DESC 'DBIS custom map value' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

description

   L'attribut description peut être associé avec une entrée pour fournir une description arbitraire de l'entrée

manager

   L'attribut manager peut être associé avec une entrée pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsables de la maintenance de l'objet.

disableObject

   Une entrée peut être désactivé en définissant disableObject à TRUE. Si une entrée est désactivé, le DUA devrait se comporter comme si l'entrée n'existe pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les objets désactivé, mais doivent les marquer clairement comme tels pour éviter toute confusion.

Exemple d'entrées de map custom

L'exemple suivant montre des entrées de map custom au format ldif:
dn: ou=console,ou=custom,o=infra
objectClass: top
objectClass: organizationalUnit
ou: console
    
dn: en=kirk,ou=console,ou=custom,o=infra
objectClass: top
objectClass: customMapEntry
en: kirk
customMapValue: 2079 ssh
    
dn: en=spock,ou=console,ou=custom,o=infra
objectClass: top
objectClass: customMapEntry
en: spock
customMapValue: 53179 telnet

Syntaxe d'attributs

Les syntaxes suivante sont utilisées par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax OID- - - - - - - - - - - Value - - - - Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.26 - IA5 String - [RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - -

Filtres de recherche communs

   Ce section fournis des exemples de filtre de recherche pour obtenir des entrées de base avec des critère communément utilisé. Pour simplifier les exemples, toutes les bases sont assumé avoir été définis avec une seule entrée de map de configuration. Cependant, draft-bannister-dbis-mapping permet plusieurs entrées et les implémentation doivent le supporter, augmentant le nombre de recherche nécessaire pour localiser toutes les entrées.

   Le DN de base utilisé dans les opérations de recherche dans cette section vient de l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter que l'entrée dbisMapConfig peut en avoir plusieurs.

   Quand il apparaît dans les filtres de recherche ci-dessous, le texte "dbisMapFilter" réfère à la valeur de l'attribut de même nom de l'entrée dbisMapConfig. Les noms de classe et attributs utilisés dans ces filtres de recherche peuvent être modifiés par les attributs dbisMapClass et dbisMapAttr assignés à l'entrée dbisMapConfig.

Pour localiser la map de configuration:
(&(objectClass=dbisCustomConfig)(!(disableObject=TRUE)))
Les maps custom sont énumérés avec le dbisMapFilter comme ceci:
(&(dbisMapFilter)(!(disableObject=TRUE)))
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-devices-04

draft-bannister-dbis-devices-04

dbis: devices

   Ce document étends DBIS pour supporter les bases ethers et bootparams. Les schémas de base de données devraient être compatible avec NIS, mais stockés dans les entrées X.500 pour pouvoir être résolus avec LDAP.

   Une base ethers map les adresses Ethernet 48bits à des adresses IP ou des noms d'hôte, et bootparams map les hôte aux paramètres de boot du kernel.

   Ce document décris les classes et attributs LDAP requis pour étendre les entrée hosts pour supporter les paramètres pour les map ethers et bootparams.

Maps de configuration

   Les bases ethers et bootparams utilisent les maps de configuration standard définies dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les bases ethers devraient avoir la classe dbisEtherConfig, et les entrées pour les bases bootparams devraient avoir la classe dbisBootConfig.

Il est recommandé que l'entrée dbisMapConfig pour une base ethers ou bootparams ait l'attribut dbisMapFilter définis en accord avec la tables suivante:
- - - - - - - - - - - - - - - - - - - - - - -
Database- - - dbisMapFilter
- - - - - - - - - - - - - - - - - - - - - - -
ethers- - - - objectClass=ieee802Device
bootparams- - objectClass=bootableDevice
- - - - - - - - - - - - - - - - - - - - - - -

Exemple d'entrée de map de configuration

L'exemple suivant montre une entrée de map de configuration pour une base ethers
dn: cn=ethers,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisEtherConfig
cn: ethers
dbisMapDN: ou=hosts,o=infra
dbisMapDN: ou=lab,ou=hosts,o=infra
dbisMapFilter: objectClass=ieee802Device
profileTTL: 900
description: Primary ethers database

L'exemple suivant montre en entrée de map de configuration pour une base bootparams
dn: cn=bootparams,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisBootConfig
cn: bootparams
dbisMapDN: ou=hosts,o=infra
dbisMapDN: ou=lab,ou=hosts,o=infra
dbisMapFilter: objectClass=bootableDevice
profileTTL: 900
description: Primary bootparams database

Base ethers

   Une base ethers contiens les champs suivants:

- Adresse ethernet 48-bits
- Un nom d'hôte

ObjectClass

   Une entrée dbisMapConfig pour une base ethers devrait avoir la class dbisEtherConfig. Une entrée host, définie par la classe ipv4HostObject ou ipv6HostObject, peut être augmentée par la classe ieee802Device pour ajouter des informations pour la map ethers.

dbisEtherConfig

La classe dbisEtherConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.37 NAME 'dbisEtherConfig' DESC 'DBIS ethers configuration map' SUP dbisMapConfig STRUCTURAL )

ieee802Device

La classe ieee802Device est définie comme suit:
objectclass ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' DESC 'A device with a 48-bit Ethernet address' SUP top AUXILIARY MAY macAddress )

   C'est une class auxiliaire et il est recommandé qu'elle soit associé avec des entrées ipv4HostObject ou ipv6HostObject. Cependant, il est préférable de conserver les adresses Ethernet dans des entrées séparée qui peuvent être associés avec des classe device à la place.

Attributs

  

macAddress

L'adresse 48-bits est stockée dans l'attribut macAddress qui peut être associé avec une entrée ieee802Device
attributetype ( 1.3.6.1.1.1.1.22 NAME ('macAddress') DESC 'MAC address in maximal, colon separated hex notation, eg. 00:00:92:90:ee:e2' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Exemple d'entrée ieee802Device

L'exemple suivant est un exemple d'une entrée ipv4HostObject au format ldif avec une class ieee802Device:
dn: rn=kilcher,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv4HostObject
objectClass: ieee802Device
rn: kilcher
ipv4Address: 10.11.12.13
macAddress: 08:00:27:00:50:f2

base bootparams

   Une base bootparams contient les champs suivants:

- Un nom d'hôte
- Des paramètres de boot

   Les paramètres de boot sont interprétés par le kernel et varie d'une plate-forme à l'autre. Ce schéma ne tente pas de définir des attributs unique pour chaque paramètre.

ObjectClass

   Une entrée dbisMapConfig pour une base bootparams devrait avec la class dbisBootConfig. Une entrée host, définie par la classe ipv4HostObject ou ipv6HostObject, peut être augmentée par la classe bootableDevice pour ajouter des informations pour la map de bootparams, qui fournis des informations de configuration pour rpc.bootparamd.

dbisBootConfig

La classe dbisBootConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.38 NAME 'dbisBootConfig' DESC 'DBIS bootparams configuration map' SUP dbisMapConfig STRUCTURAL )

bootableDevice

La classe bootableDevice est définie comme suit:
objectclass ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' DESC 'A device with boot parameters' SUP top AUXILIARY MAY ( bootFile $ bootParameter ) )

   C'est une classe auxiliaire et il est recommandé qu'elle soit associée avec des entrée ipv4HostObject ou ipv6HostObject. Cependant, il est préférable de conserver les adresses Ethernet dans des entrées séparée qui peuvent être associés avec des classe device à la place.

Attributs

bootFile

Nom de l'image de boot est stocké dans l'attribut bootFile qui peut être associé avec une entrée bootableDevice:
attributetype ( 1.3.6.1.1.1.1.24 NAME 'bootFile' DESC 'Boot image name' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

bootParameter

Les paramètres de boot sont stockés comme "clé=valeur" dans l'attribut bootParameter qui peut être associé avec une entrée bootableDevice:
attributetype ( 1.3.6.1.1.1.1.23 NAME 'bootParameter' DESC 'rpc.bootparamd parameter' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Exemple d'entrée avec bootableDevice

L'exemple suivant montre une entrée ipv4HostObject au format ldif avec une classe bootableDevice:
dn: rn=kilcher,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv4HostObject
objectClass: ieee802Device
objectClass: bootableDevice
rn: kilcher
ipv4Address: 10.11.12.13
macAddress: 08:00:27:00:50:f2
bootParameter: root=alaska:/export/client/root
bootParameter: domain=country.music.edu

Syntaxe d'attribut

Les syntaxes suivante sont utilisée par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax OID- - - - - - - - - - -Value- - - - - - -Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.26 -IA5 String - - - -[RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Mappage de champs NIS

   Tous les champs qui sont requis pour générer des formats de base ether et bootparams NIS existent dans ce schéma et peut être mappés aux types d'attribut en utilisant les production ABNF décrites dans draft-bannister-dbis-netgroup.

ethers

Les champs de base ethers NIS sont mappés comme suit:
ether-addr = macAddress
hostname = rn / en ; depending on class, see below
    
ethers-entry = ether-addr SPACE hostname

   - hostname vient de l'attribut rn si la classe ipv4HostObject ou ipv6HostObject est utilisée. Si la classe ieee802Device est associée avec un objet avec la classe device, le nom d'hôte vient de l'attribut cn.

bootparams

Les champs de base bootparams NIS sont mappés comme suit:
hostname = rn / en ; depending on class, see below
params = bootParameter *(SPACE bootParameter)
    
bootparams-entry = hostname SPACE params

   - hostname vient de l'attribut rn si la classe ipv4HostObject ou ipv6HostObject est utilisée. Si la classe bootableDevice est associée avec un objet avec la classe device, le nom d'hôte vient de l'attribut cn.

Filtres de recherche communs

   Cette section fournis des exemples de filtre de recherche ldap pour obtenir des entrées de base avec des critères communément utilisés.

Si une entrée hosts a une adresse ethernet "ether", sa définition est localisée en utilisant le filtre de recherche suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(objectClass=ieee802Device)(macAddress=ether))
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-hosts-06

draft-bannister-dbis-hosts-06

dbis: hosts

   Ce document étends DBIS pour supporter les hôtes, réseaux, masques de sous-réseaux, protocoles, rpc et services. Les schémas de base devraient être compatible avec NIS, mais stockés dans des entrées X.500 pour qu'ils puissent être résolus avec LDAP. Une base hosts mappe des noms d'hôte à des adresses IP, les réseaux mappent des noms réseaux à des numéros de réseaux, les netmask mappent des numéros de réseaux à des masques réseaux, les protocoles mappent des noms de protocole réseaux à des numéros de protocole réseaux, rpc mappent les noms de programmes RPC à des numéros de programme RPC et les services mappent des noms de service réseaux à des numéros de ports et protocoles.

   Toutes les bases de données décrites dans ce document utilise les maps de configuration définis dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les base de données décrites dans ce document devraient avoir les objectClass décris ci-dessous. Il est recommandé que l'entrée dbisMapConfig pour une base hosts ait l'attribut dbisMapFilter définis en accord avec la tables suivante:


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Database___Configuration Class___dbisMapFilter
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
hosts______dbisHostConfig________objectClass=ipHostObject
networks___dbisNetworkConfig_____objectClass=ipNetworkObject
protocols__dbisProtocolConfig____objectClass=ipProtocolObject
rpc________dbisRpcConfig_________objectClass=rpcObject
services___dbisServiceConfig_____objectClass=ipServiceObject

Exemple d'entrées de map de configuration

L'exemple suivante montre une entrée de map de configuraion pour une base hosts:
dn: cn=hosts,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisHostConfig
cn: hosts
dbisMapDN: cn=hosts,ou=dbis,o=infra
dbisMapFilter: objectClass=ipHostObject
profileTTL: 900
description: Primary hosts database

Base hosts

   Une base host contient les champs suivants:

- Une adresse IPv4 ou IPv6
- Un nom d'hôte canonique
- Des alias

ObjectClass

   Une entrée dbisMapConfig pour une base hosts devrait avoir l'objectClass dbisHostConfig. Une entrée host devrait être définis par une entrée LDAP avec l'objectClass ipv4HostObject ou ipv6HostObject.

dbisHostConfig

La classe dbisHostConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.15 NAME 'dbisHostConfig' DESC 'DBIS hosts configuration map' SUP dbisMapConfig STRUCTURAL )

ipHostObject

La classe ipHostObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.16 NAME 'ipHostObject' DESC 'An IP address and associated host name' SUP top ABSTRACT MUST rn MAY ( authPassword $ userPassword $ description $ manager $ l $ disableObject ) )

ipv4HostObject

La classe ipv4HostObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.17 NAME 'ipv4HostObject' DESC 'An IPv4 address' SUP ipHostObject STRUCTURAL MUST ipv4Address )

ipv6HostObject

La classe ipv6HostObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.18 NAME 'ipv6HostObject' DESC 'An IPv6 address' SUP ipHostObject STRUCTURAL MUST ipv6Address )

attributs

rn

   Le nom canonique pleinement qualifié de l'hôte est stocké dans l'attribut rn qui est définis dans draft-bannister-dbis-mapping. L'attribut rn doit être associé avec une entrée ipHostObject et devrait former le RDN. Si requis, des entrées alias peuvent être définis.

authPassword

   Un mot de passe chiffré peut être stocké dans l'attribut authPassword assigné à une entrée ipHostObject.

userPassword

   Pour des raisons de compatibilité, un mot de passe chiffré peut être stocké dans l'attriut userPassword

ipv4Address

L'adresse IPv4 est stocké dans l'attribut ipv4Address qui doit être associé avec une entrée ipv4HostObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.27 NAME 'ipv4Address' DESC 'An IPv4 address in dotted decimal format' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{15} )

ipv6Address

L'adresse ipv6 est stockée dans l'attribut ipv6Address qui doit être associé avec une entrée ipv6HostObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.28 NAME 'ipv6Address' DESC 'An IPv6 address [RFC2373]' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{45} )

Exemple d'entrée host

L'exemple suivant est une entrée ipv4HostObject au format LDIF:
dn: rn=picard,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv4HostObject
rn: picard
ipv4Address: 10.11.12.13

L'exemple suivant est une entrée ipv6HostObject:
dn: rn=picard-hive,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv6HostObject
rn: picard-hive
ipv6Address: 0:1:2:3:4:5:6:7

L'exemple suivant est une entrée alias d'hôte:
dn: rn=picard-eth0,ou=hosts,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
rn: picard-eth0
aliasedObjectName: rn=picard,ou=hosts,o=infras

Base networks

   Une base networks contient les champs suivants:

- Le nom d'un réseaux
- Le numéro de réseau IP
- Des alias

objectClass

   une entrée dbisMapConfig pour une base réseaux devait être assigné à l'objectClass dbisNetworkConfig. Une entrée network devrait être définie dans une entrée LDAP avec l'objectClass ipNetworkObject.

dbisNetworkConfig

La classe dbisNetworkConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.19 NAME 'dbisNetworkConfig' DESC 'DBIS networks configuration map' SUP dbisMapConfig STRUCTURAL )

ipNetworkObject

La classe ipNetworkObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.20 NAME 'ipNetworkObject' DESC 'An IP network entry' SUP top STRUCTURAL MUST ipNetworkNumber MAY ( en $ ipNetmaskNumber $ description $ manager $ l $ disableObject ) )

en

   Le nom du réseau est stocké dans l'attribut en. Cet attribut peut être associé avec une entrée ipNetworkObject, et si fournis, devrait former le RDN. Si besoin des entrées alias peuvent être définies.

ipNetworkNumber

L'adresse IP réseau est stocké dans l'attribut ipNetworkNumber qui doit être associé avec une entrée ipNetworkObject:
attributetype ( 1.3.6.1.1.1.1.20 NAME 'ipNetworkNumber' DESC 'IP network as a dotted decimal, eg. 192.168, omitting leading zeros' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   Si l'attribut en n'est pas fournis, ipNetworkNumber devrait former le RDN.

ipNetmaskNumber

Le masque de réseau est stocké dans l'attribut ipNetmaskNumber qui peut être associé avec une entrée ipNetworkObject
attributetype ( 1.3.6.1.1.1.1.21 NAME 'ipNetmaskNumber' DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, omitting leading zeros' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Exemple d'entrée network

L'exemple suivant montre une entrée ipNetworkObject au format LDIF:
dn: en=lab,ou=networks,o=infra
objectClass: top
objectClass: ipNetworkObject
en: lab
ipNetworkNumber: 10.23.10
ipNetmaskNumber: 255.255.255.0

L'exemple suivant montre une entrée alias:
dn: en=testnet,ou=networks,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
en: testnet
aliasedObjectName: en=lab,ou=networks,o=infra

Base protocols

   Une base protocols contient les champs suivants:

- Le nom du protocole
- Le numéro du protocole
- Des alias

ObjectClass

   Une entrée dbisMapConfig pour une base protocols devrait avoir l'objectClass dbisProtocolConfig. Une entrée protocol devrait être définis dans une entrée avec la classe ipProtocolObject.

dbisProtocolConfig

La classe dbisProtocolConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.21 NAME 'dbisProtocolConfig' DESC 'DBIS protocols configuration map' SUP dbisMapConfig STRUCTURAL )

ipProtocolObject

La classe ipProtocolObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.22 NAME 'ipProtocolObject' DESC 'An IP protocol entry' SUP top STRUCTURAL MUST ( en $ ipProtocolNumber ) MAY ( description $ manager $ disableObject ) )

Attribut

en

   Le nom du protocole est stocké dans l'attribut en qui doit être associé avec une entrée ipProtocolObject et devrait former le RDN. Si besoin, des alias peuvent être définis.

ipProtocolNumber

Le numéro de protocole est stocké dans l'attribut ipProtocolNumber qui doit être assigné à une entrée ipProtocolObject:
attributetype ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber' DESC 'IP protocol number' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

Exemples d'entrée protocol

L'exemple suivant montre une entrée ipProtocolObject au format LDIF:
dn: en=ip,ou=protocols,o=infra
objectClass: top
objectClass: ipProtocolObject
en: ip
ipProtocolNumber: 0

L'exemple suivant montre une entrée alias:
dn: en=IP,ou=protocols,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
en: IP
aliasedObjectName: en=ip,ou=protocols,o=infra

base rpc

   Une base RPC contient les champs suivants:

- Le nom du programme RPC
- Le numéro du programme RPC
- Les alias

ObjectClass

   Une entrée dbisMapConfig pour une base rpc devrait avoir la clé dbisRpcConfig. Une entrée rpc devrait être définie dans une entrée avec la classe rpcObject.

dbisRpcConfig

La classe dbisRpcConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.23 NAME 'dbisRpcConfig' DESC 'DBIS rpc configuration map' SUP dbisMapConfig STRUCTURAL )

rpcObject

La classe rpcObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.24 NAME 'rpcObject' DESC 'An rpc entry [RFC1057]' SUP top STRUCTURAL MUST ( en $ rpcNumber ) MAY ( description $ manager $ disableObject ) )

en

   Le nom du programme rpc est stocké dans l'attribut en qui doit être associé avec une entrée rpcObject et devrait former le RDN. Si besoin, des entrées alias peuvent être définies.

rpcNumber

Le numéro de programme RPC est stocké dans l'attribut rpcNumber qui doit être associé avec une entrée rpcObject
attributetype ( 1.3.6.1.4.1.23780.219.2.29 NAME 'rpcNumber' DESC 'RPC program number [RFC1057]' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

Exemple d'entrée RPC

L'exemple suivant montre une entrée rpcObject au format ldif:
dn: en=rpcbind,ou=rpc,o=infra
objectClass: top
objectClass: rpcObject
en: rpcbind
rpcNumber: 100000

L'exemple suivant montre une entrée alias:
dn: en=portmap,ou=protocols,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
en: portmap
aliasedObjectName: en=rpcbind,ou=rpc,o=infra

base services

   Une base services contient les champs suivants:

- Nom du service
- Numéro de port et nom du protocole
- alias

   Le RDN peut être constitué de l'attribut en, cependant, où une entrée ne peut pas être identifiée de manière unique dûe à la présente d'autres services qui utilisent le même nom de service et numéro de port mais avec un nom de protocole différent, un RDN multi-valué devrait être utilisé à la place.

ObjectClass

   Une entrée dbisMapConfig pour une base service devait avoir l'objectClass dbisServiceConfig. Une entrée service devrait être définie par une entrée avec la classe ipServiceObject.

dbisServiceConfig

La classe dbisServiceConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.25 NAME 'dbisServiceConfig' DESC 'DBIS services configuration map' SUP dbisMapConfig STRUCTURAL )

ipServiceObject

La classe ipServiceObject est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.26 NAME 'ipServiceObject' DESC 'An IP service entry' SUP top STRUCTURAL MUST ( en $ ipServicePort $ ipProtocolName ) MAY ( description $ manager $ disableObject ) )

en

   Le nom du service est stocké dans l'attribut en qui doit être associé avec une entrée ipServiceObject et devrait former le RDN.

ipServicePort

Le numéro de port IP du service est stocké dans l'attribut ipServiceport qui doit être associé avec une entrée ipServiceObject:
attributetype ( 1.3.6.1.1.1.1.15 NAME ( 'ipServicePort' ) DESC 'IP port number' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

ipProtocolName

Le nom du protocole du service est stocké dans l'attribut ipProtocolName qui doit être associé avec une entrée ipServiceObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.30 NAME 'ipProtocolName' DESC 'IP protocol name' EQUALITY caseExactMatch SINGLE-VALUE SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

Exemples d'entrée service

L'exemple suivant montre une entrée ipServiceObject au format LDIF:
dn: en=smtp,ou=services,o=infra
objectClass: top
objectClass: ipServiceObject
en: smtp
ipServicePort: 25
ipProtocolName: tcp

L'exemple suivant est un exemple d'une entrée alias de service:
dn: en=mail,ou=services,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
en: mail
aliasedObjectName: en=smtp,ou=services,o=infra

L'exemple suivant montre des entrées services multi-valués:
dn: en=rpcbind+ipProtocolName=udp,ou=services,o=infra
objectClass: top
objectClass: ipServiceObject
en: rpcbind
ipServicePort: 111
ipProtocolName: udp
    
dn: en=rpcbind+ipProtocolName=tcp,ou=services,o=infra
objectClass: top
objectClass: ipServiceObject
en: rpcbind
ipServicePort: 111
ipProtocolName: tcp

Attributs communs

   Ce document utilise les attributs communs suivant.

description

   L'attribut description peut être associé avec une entrée pour fournir une description arbitraire de l'entrée

manager

   L'attribut manager peut être associé avec une entrée pour fournir un ou plusieurs dn des individus, groupes ou systèmes qui sont responsable pour maintenir l'entrée.

l

   L'attribut l peut être associé avec une entrée pour fournir des détails de localisation.

disableObject

   Une entrée peut être désactivée en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si l'entrée n'existait pas. Le DUA peut optionnellement fournir un mécanisme pour lister les entrées désactivées, mais ils doivent être clairement marqués comme désactivés pour qu'aucune confusion ne se produise.

Syntaxe d'attributs

Les syntaxes suivante sont utilisée par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Syntax OID - - - - - - - - - - Value - - - - - - Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- 1.3.6.1.4.1.1466.115.121.1.15 -Directory String -[RFC4517]
- 1.3.6.1.4.1.1466.115.121.1.26 -IA5 String - - - -[RFC4517]
- 1.3.6.1.4.1.1466.115.121.1.27 -Integer - - - - - [RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Mappage des champs NIS

   Tous les champs qui sont requis pour générer des bases correspondante dans NIS existent dans ce schéma et peuvent être mappé aux types d'attributs en utilisant les productions ABNF décrites dans draft-bannister-dbis-netgroup.

hosts

Les champs de base hosts sont mappés comme suit:
ipaddr = ipv4Address / ipv6Address
hostname = rn
alias = rn ; dérivé, voir plus bas
    
hosts-entry = ipaddr SPACE hostname *(SPACE alias)

   Alias est dérivé de l'attribut rn utilisé avec les entrées qui référencent celle-ci via aliasedObjectName.

networks

Les champs de base networks sont mappés comme suit:
network-name = en
network-number = ipNetworkNumber
alias = en ; dérivé, voir plus bas
    
networks-entry = network-name SPACE network-number *(SPACE alias)

   Alias est dérivé de l'attribut en utilisé avec les entrées qui référencent celle-ci via aliasedObjectName.

netmasks

Les champs de base netmasks sont mappés comme suit:
network-number = ipNetworkNumber
netmask = ipNetmaskNumber
    
netmasks-entry = network-number SPACE netmask

protocols

Les champs de base protocols sont mappés comme suit:
proto-name = en
proto-number = ipProtocolNumber
alias = en ; dérivé, voir plus bas
    
protocols-entry = proto-name SPACE proto-number *(SPACE alias)

rpc

Les champs de base rpc sont mappés comme suit:
rpc-name = en
rpc-number = rpcNumber
alias = en ; dérivé, voir plus bas
    
rpc-entry = rpc-name SPACE rpc-number *(SPACE alias)

   Alias est dérivé de l'attribut en utilisé avec les entrées qui référencent celle-ci via aliasedObjectName

services

Les champs de base services sont mappés comme suit:
service-name = en
service-port = ipServicePort
service-protocol = ipProtocolName
alias = en ; dérivé, voir plus bas
    
services-entry = service-name SPACE service-port SLASH service-protocol *(SPACE alias)

   Alias est dérivé de l'attribut en utilisé avec les entrées qui référencent celle-ci via aliasedObjectName .

Filtres de recherches communs

   Cette section fournis des exemples de filtre de recherche LDAP pour obtenir les entrées de base avec des critères d'entrée communément utilisés.

   Pour simplifier les exemples, toutes les bases sont supposés avoir été définis avec seulement une entrée de map de configuration. Le DN de base utilisé dans les opérations de recherche décris dans cette section vient le l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter qu'une entrée dbisMapConfig peut en avoir plusieurs.

   Quand il apparaît dans les filtres de recherche, le texte "dbisMapFilter" réfère à la valeur assignée dans l'attribut de même nom dans l'entrée dbisMapConfig correspondante. Les noms d'attributs utilisé dans les filtres de recherche peuvent être modifiés par l'attribut dbisMapAttr assigné à l'entrée dbisMapConfig.

Trouver la map de configuration pour un domaine

   Pour localiser la map de configuration pour un domaine dbis donné, rechercher les entrées sous l'entrée dbisDomainObject:

Les maps d'hôte peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisHostConfig)(!(disableObject=TRUE)))
Les maps réseaux peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisNetworkConfig)(!(disableObject=TRUE)))
Les maps protocols peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisProtocolConfig)(!(disableObject=TRUE)))
Les maps rpc peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisRpcConfig)(!(disableObject=TRUE)))
Les maps services peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisServiceConfig)(!(disableObject=TRUE)))

Lister toutes les entrées

Les entrées pour une base donnée sont énumérées en appliquant le filtre suivant:
(&(dbisMapFilter)(!(disableObject=TRUE)))

Trouver des entrées spécifiques

Une entrée hôte nommé "name", sa définition est localisé en utilisant:
(&(dbisMapFilter)(!(disableObject=TRUE))(rn=name))
Une entrée networks, protocols, rpc ou services nommé "name", sa définition est localisée en utilisant:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name))

Trouver un hôte par adresse

Une entrée d'hôte ayant une IPv4, sa définition est localisée en utilisant:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipv4Address=ipv4))
Avec une IPv6:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipv6Address=ipv6))

Trouver un réseau par adresse

Pour localiser une entrée réseau par son adresse, utiliser:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipNetworkNumber=netip))

Trouver par numéro

La définition du protocole de numéro "protonum" est localisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipProtocolNumber=protonum))
Pour localiser une entrée rpc pas son numéro de programme "rpcnum", utiliser:
(&(dbisMapFilter)(!(disableObject=TRUE))(rpcNumber=rpcnum))

Autres exemples

Pour trouver l'entrée service nommé "servname" et le protocole "servproto", utiliser:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=servname)(ipProtocolName=servproto))
Pour trouver l'entrée de service pour le port "servport" et les protocole "servproto", utiliser:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipServicePort=servport)(ipProtocolName=servproto))
^
15 juin 2015

htmlpdflatexmanmd




draft-bannister-dbis-mapping-06

draft-bannister-dbis-mapping-06

Directory-Based Information Services

   Ce document fait partie de la série de documents qui décrivent les composants dans DBIS (Directory-Based Information Services). DBIS fournis un framework pour la représentation des données lié à TCP/IP et le système UNIX dans des entrées X.500 qui ont été précédemment stockés dans NIS; pour qu'ils puissent être résolus avec le protocole LDAP.

   Le but de DBIS est d'étendre, et remplacer le protocole NIS et expérimental pour utiliser LDAP comme service d'information réseaux,.

   DBIS consiste d'un schéma LDAP, de conventions de nommage et de protocoles pour décrire son utilisation par les DUA nécessitant des informations de service réseaux. La communication client/serveur et les opérations côté serveur sont entièrement contenus dans le domaine de LDAP.

   Les aspects clé de DBIS et des amélioration par rapport à RFC2307 sont:

- le schéma est compatible avec NIS, incluant la sensibilité à la casse des noms clé.
- Standardisation des information de mappage pour augmenter la portabilité des implémentation DUA et pour réduire la duplication des informations de configuration du client.
- Fonctionnalités ajoutées pour augmenter la flexibilité dans de grands environnements:

        - les maps peuvent être jointes depuis les données localisée dans différents endroits du DIT.
        - Les groupes de DUA peuvent avoir de variations dans leur données en fonction de leur appartenance aux netgroup d'hôte.

- Conception modulaire pour permettre de séparer les parties du système à remplacer, améliorer et augmenter séparément dans le future.
- Support ajouté pour les maps d'automontage

   Ce document décris le mappage d'objets utilisés par DBIS pour localiser et transformer les informations de service stockés dans le DIT.

Databases

   Le rôle de DBIS est de fournir un framework qui fournis des informations de configuration, principalement des services de nom tel que les comptes, groupes et hôtes/réseaux, et toutes les informations traditionnellement fournies par NIS. Chaque type d'information est appelée une base de donnée, vu que c'est une collection d'entrées liées dans le DIT. Le format des entrées est spécifique à chaque type de base et n'est pas définis dans ce document. Chaque base est configurée séparément en utilisant des maps de configuration qui décrivent où localiser les entrées concernées dans le DIT. Le format des map de configuration est définie dans ce document, bien qu'il peut être étendus par d'autres documents.

Alias

   Quand une base supporte les entrées alias, ils doivent être configuré comme décris dans la rfc4512. Un DUA devrait effectuer le déréférencement d'alias dans ces bases.

Domaine: définition

   Le mappage d'objets définis les composants qui font un domaine DBIS. Un domain DBIS, est un groupement logique de services d'informations requis par une collection commune de DUA, de la même manière qui domaine NIS contient toutes les maps NIS requises pour les opérations d'un groupe de machines. Un domaine DBIS devrait être identifiié par une entrée LDAP avec l'objectClass dbisDomainObject. Les maps de configuration pour le domaine sont contenus dans les entrées qui devraient être localisés sous l'entrée dbisDomainObjet dans le DIT.

dbisDomainObject

Cette classe est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.1 NAME 'dbisDomainObject' DESC 'Defines a top-level mapping object for a DBIS domain' SUP top STRUCTURAL MUST en MAY ( profileTTL $ negativeTTL $ description $ manager ) )

Attributs de domaine

en Le nom du domain, identique au format dans un domaine NIS, qui doit être associé avec une entrée dbisDomainObject et devrait former le RDN.
profileTTL Valeur TTL par défaut pour la pertinence des données de configuration (définis dans la rfc4876) qui peut être associé avec une entrée dbisDomainObject. Les DUA devraient conserver une copie locale des données obtenues. Si profileTTL vaut 0, les DUA peuvent conserver les copies locales indéfiniment. Si profileTTL n'est pas présent, les DUA devraient se comporter comme s'il était définis à 0.
negativeTTL Identique à profileTTL, excepté pour les entrées qui n'existent pas. Les DUA devraient conserver une copie local des recherches qui n'existent pas mais ne doivent pas utiliser cette donnée après le nombre de secondes spécifiée.


attributetype ( 1.3.6.1.4.1.23780.219.2.36 NAME 'negativeTTL' DESC 'Time to live, in seconds, for missing entries' EQUALITY integerMatch ORDERING integerOrderingMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

description L'attribut description peut être associé avec une entrée dbisDomainObject pour fournir une description arbitraire de l'entrée.
manager L'attribut manager peut être associé avec une entrée dbisDomainObject pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsable de la maintenance de l'entrée.

Alias de domaine

   Si les alias noms de domaine sont requis ils doivent être configurés comme décris dans la rfc4512. Un DUA doit déréférencer les alias.

Exemple d'entrée de domaine

L'exemple suivant est une entrée dbisDomainObject:
dn: en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisDomainObject
en: sales.corp
profileTTL: 900
negativeTTL: 300
description: Sales Workforce

Maps de configuration

   Une map de configuration DBIS instruit un DUA sur l'emplacement des entrées dans le DIT pour une base particulière. Elle décris comment trouver les entrées et optionnellement quel sous-jeu de DUA devraient utiliser ces entrées (basé sur l'appartenance de netgroup). Ce document ne définis aucune map de configuration spécifique, mais un framework qui doit être suivi pour la spécification de tels maps. Les maps de configuration devraient être évaluées par un DUA dans l'ordre lexicographique de leur attribut cn. L'ordre d'évaluation de ces entrées de configuration déterminent également l'ordre dans lequel les entrées de base apparaissent si plusieurs emplacements sont trouvés. L'ordre est également important pour s'assurer que les netgroups corrects sont disponibles pou tester si la configuration est restreinte par l'appartenance à un netgroup en utilisant soit l'attribut exactNetgroup ou notNetgroup.

dbisMapConfig

Une map pour une base est optionnelle et devrait être identifiée par une ou plusieurs entrées LDAP localisées sous l'entrée dbisDomainObject dans le DIT. Le comportement du DUA si une entrée depuis une base est demandée et n'a pas de map de configuration correspondant est indéfinie. Les entrées de map de configuration assignées, ou une sous-classe:
objectclass ( 1.3.6.1.4.1.23780.219.1.2 NAME 'dbisMapConfig' DESC 'DBIS configuration map for a specific database' SUP top STRUCTURAL MUST ( cn $ dbisMapDN ) MAY ( dbisMapFilter $ dbisMapClass $ dbisMapAttr $ dbisTransAttr $ exactNetgroup $ notNetgroup $ profileTTL $ negativeTTL $ description $ manager $ disableObject ) )

   Un DUA devrait supporter plusieurs entrées de map de configuration pour une simple base. Une base devrait nécessiter au moins un objectClass additionnel assigné à sa configuration, qui est utilisé pour identifier de manière unique le type de base pour lequel les entrées appartiennent.

cn

   L'attribut cn doit être utilisé pour former le RDN d'une entrée dbisMapConfig. C'est un nom arbitraire qui n'a pas de signification spéciale dans DBIS, mais qui identifie de manière unique l'entrée dbisMapConfig. Comme vu plus haut, les entrées sont évaluées dans l'ordre lexicographique de leur attribut cn.

dbisMapDN

Un ou plusieurs DNs localisant la base de recherche des entrées de la base dans le DIT sont donnés dans l'attribut dbisMapDN qui doit être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.1 NAME 'dbisMapDN' DESC 'DN of search base for DBIS database entries' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

dbisMapFilter

Un filtre de recherche LDAP utilisé pour localiser les entrées de la base sous lequel chaque dbisMapDN est donné dans l'attribut dbisMapFilter qui peut être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.2 NAME 'dbisMapFilter' DESC 'LDAP search filter for DBIS database entries' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dbisMapClass

Les objectClass utilisés pour identifier les entrées pour une base peut être changé du défaut par l'attribut dbisMapClass qui peut être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.3 NAME 'dbisMapClass' DESC 'LDAP class mapping for DBIS database entries' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

La représentation chaîne de l'attribut dbisMapClass est définie par la grammaire suivante, qui utilise la notation ABNF. Les productions utilisées qui ne sont pas définies ici sont définies dans la rfc4512.
from_class = keystring
to_class = keystring
dbisMapAttr = to_class EQUALS from_class

   Si l'attribut dbisMapClass est manquant de l'entrée dbisMapConfig, le DUA devrait continuer avec les classes par défaut pour la base. Changer cet attribut n'a pas d'effet sur le dbisMapFilter, qui doit être ajusté indépendamment.

dbisMapAttr

Les attributs utilisé pour stocker les clés et valeurs de l'entrée de la base peuvent être changés par l'attribut dbisMapAttr qui peut être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.4 NAME 'dbisMapAttr' DESC 'LDAP attribute mapping for DBIS database entries' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

La représentation chaîne de l'attribut dbisMapAttr est définie par la grammaire suivante, qui utilise la notation ABNF. Les productions utilisées qui ne sont pas définies ici sont définies dans la rfc4512.
from_attr = keystring
to_attr = keystring
dbisMapAttr = to_attr EQUALS from_attr

   L'attribut utilisé dans la base est identifiée par from_attr et devrait être ré-écrit par le DUA à l'attribut to_attr. Si l'attribut dbisMapAttr est manquant de l'entrée dbisMapConfig, le DUA devrait continuer avec les attributs par défaut pour la base. Changer cet attribut n'a pas d'effet sur le dbisMapFilter ni dbisTransAttr, qui doivent être ajustés indépendamment.

dbisTransAttr

Les valeurs d'attribut utilisés par les entrées de base peuvent être transformés par l'attribut dbisTransAttr qui peut être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.4.1 NAME 'dbisTransAttr' DESC 'LDAP attribute transformation for DBIS database entries' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

La représentation chaîne de dbisTransAttr est définie par la grammaire suivante, qui utilise la notation ABNF. Les productions qui ne sont pas définies ici sont définies dans draft-bannister-dbis-netgroup-XX:
attrname = keystring
prefix = keystring
suffix = SLASH keystring
incr = PLUS number
decr = HYPHEN number
trans = prefix / suffix / incr / decr
dbisTransAttr = attrname EQUALS trans

   La valeur de l'attribut attrname apparaissant dans les entrées de base devraient être ré-écris par le DUA tel sorte qu'il porte le nouveau préfix et/ou suffix. Alternativement, si la valeur de l'attribut est numérique, il doit être incrémenté ou décrémenté en ajoutant ou supprimant le nombre donné. Si l'attribut dbisTransAttr est manquant, le DUA devrait continuer avec les valeurs non-éditées pour la base.

exactNetgroup

   Un ou plusieurs noms netgroup identifiant les noms d'hôte des DUA qui devraient appliquer la map de configuration donnée dans l'attribut exactNetgroup qui peut être assigné à une entrée dbisMapConfig. Si l'attribut exactNetgroup est manquant, le DUA devrait appliquer cette entrée de map de configuration. Si l'attribut existe, le DUA devrait appliquer l'entrée seulement si l'hôte sur lequel il tourne est membre du netgroup donné. Si une entrée matchant est trouvée, le DUA devrait utiliser cette configuration, sinon le DUA doit ignorer cette entrée. La seule exception à ces règles est si le DUA est membre d'un netgroup identifié par l'attribut notNetgroup, qui a précédence.

noNetgroup

   Un ou plusieurs noms netgroup identifiant les noms d'hôte des DUA qui ne devraient pas appliquer la map de configuraion sont donnés dans l'attribut notNetgroup qui peut être assigné à une entrée dbisMapConfig. Cela permet aux entrées de map de configuration d'être exclus d'un groupe d'hôtes particuliers. Le DUA devrait exclure cette entrée de map de configuration si le DUA est membre du netgroup donné, même s'il est également membre d'une attribut exactNetgroup.

profileTTL

   Une valeur TTL peut être assignée à une entrée dbisMapConfig dans l'attribut profileTTL définis dans la rfc4876. Les DUA devraient considérer cet attribut comme ayant précédence au profileTTL fournis dans l'entrée dbisMapConfig, avec le scope limité à cette entrée et toutes entrées qu'elle référence. Si profileTTL est à 0, le DUA peut conserver les copies indéfiniment ou jusqu'à ce que d'autre périodes localement définies soient passées. Si profileTTL est omis de dbisMapConfig, le profileTTL par défaut fournis dans le dbisDomainObject devrait prévaloir.

negativeTTL

   Identique à profileTTL, excepté qu'il est utilisé pour les entrées qui n'existent pas.

description

   L'attribut description peut être associé avec une entrée dbisMapConfig pour fournir une description arbitraire de l'entrée

manager

   L'attribut manager peut être associé avec une entrée dbisMapConfig pour fournir un ou plusieurs DN des individus, groupes ou systèmes qui sont responsable pour maintenir l'entrée.

disableObject

L'attribut disableObject peut être associé avec une entrée dbisMapConfig pour désactiver ce composant de configuration, et est définis comme suit:
attributetype ( 1.3.6.1.4.1.23780.219.2.5 NAME 'disableObject' DESC 'TRUE if the entry is disabled' EQUALITY booleanMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

   Un DUA devrait ignorer les entrées qui ont l'attribut disableObject mis à TRUE.

Attributs communs

   Les attribut additionnels qui sont soit utilisés dans ce document ou requis par d'autres documents en utilisant le shéma de mappage DBIS sont définis ou référencé ci-dessous.

en (exactName)

L'attribut en peut être utilisé à la place de cn où la sensibilité à la casse est requise, et est définie comme suit:
attributetype ( 1.3.6.1.4.1.23780.219.2.6 NAME ( 'en' 'exactName' ) DESC 'Exact name by which the entity is known' EQUALITY caseExactMatch SINGLE-VALUE SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

   L'attribut en est identique à l'attribut cn à l'exception qu'il est sensible à la casse et est SINGLE-VALUE.

rn (regularName)

L'attribut rn peut être utilisé à la place du cn où la casse n'est pas importante mais une seule valeur est permise:
attributetype ( 1.3.6.1.4.1.23780.219.2.7 NAME ( 'rn' 'regularName' ) DESC 'Regular name by which the entity is known' EQUALITY caseIgnoreMatch SINGLE-VALUE SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

   L'attribut rn est identique à l'attribut cn à l'exception qu'il est SINGLE-VALUE.

Syntaxe d'attribut

Les syntaxes suivantes sont utilisée par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax_OID_____________________Value_____________Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.7___Boolean___________[RFC4517]
1.3.6.1.4.1.1466.115.121.1.12__DN________________[RFC4517]
1.3.6.1.4.1.1466.115.121.1.15__Directory_String__[RFC4517]
1.3.6.1.4.1.1466.115.121.1.26__IA5_String________[RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Caches

   Il est commun pour les systèmes d'exploitation d'implémenter leur propres algorithmes de cache de service de noms, par exemple nscd, qui a sont propre TTL. Tou DUA implémentant DBIS devrait honorer le profileTTL et negativeTTL au niveau du domanie et des entrées de map de configuration qui doivent avoir précédence sur les paramètres locaux. Cela peut résulter en différents TTL pas seulement pour les base individuelles mais potentiellement pour les sous-jeux des entrées dans une simple base.
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-netgroup-04

draft-bannister-dbis-netgroup-04

dbis: netgroup

   Ce document étend DBIS pour supporter les bases de données se service réseaux et groupes réseaux. Un schéma de base de netgroup devrait être compatible avec NIS mais stocké dans des entrées X.500 pour qu'ils puissent être résolus via lDA. Une base de netgroup représente des groupes d'hôtes, d'utilisateurs et de domaines.

Domaine

   Le terme "domaine" utilisé dans ce document ne réfère pas aux domaines DBIS mais aux domaines DNS.

scope

   Toutes les bases décrites dans ce document utilise les maps de configuration standard définies dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les bases netgroup et netservice devraient être assignés aux objectClass dbisNetGroupConfig et dbisNetserviceConfig, respectivement.

Il est recommandé que l'entrée dbisMapConfig pour un netgroup ou une base netservice ait l'attribut dbisMapFilter mis en accord avec la table suivante:
- - - - - - - - - - - - - - - - - - - - - - - - - -
Database                        dbisMapFilter
- - - - - - - - - - - - - - - - - - - - - - - - - -
netgroup                        objectClass=netgroupObject
netservice                objectClass=netserviceDescriptor
- - - - - - - - - - - - - - - - - - - - - - - - - -

Exemple

Exemple de configuration d'une entrée de map de configuration pour une base netgroup:
dn: cn=netgroup,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisNetgroupConfig
cn: netgroup
dbisMapDN: cn=netgroup,ou=dbis,o=infra
dbisMapFilter: objectClass=netgroupObject
profileTTL: 900
description: Primary netgroup database

Exemple de configuration d'une entrée de map de configuration pour une base netservice:
dn: cn=netservice,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisNetserviceConfig
cn: netservice
dbisMapDN: cn=netservice,ou=dbis,o=infra
dbisMapFilter: objectClass=netserviceDescriptor
profileTTL: 900
description: Primary netservice database

netgroup - définition

   Une base netgroup contient les entrées qui représente les hôtes, les utilisateurs et les domaines et qui sont associés avec une nom netgroup sensible à la casse. les netgroups DBIS permettent aux groupes d'utilisateurs et aux hôtes d'être définis avec les variances de scope suivant:

- Tous les utilisateurs dans tous les hôtes d'un domaine donné
- Tous les utilisateurs dans des hôtes spécifiques
- Les utilisateurs nommés sans regarder l'hôte
- Les utilisateurs nommés dans tous les hôtes dans un domaine donné
- Les utilisateurs nommés dans des hôtes spécifiques.

objecClass

   Une entrée dbisMapConfig pour une base netgroup devrait avoir l'objectClass dbisNetgroupConfig. Un netgroup devrait être définis par une entrée LDAP avec l'objectClass netgroupObject.

dbisNetgroupConfig

dbisNetgroupConfig est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.3 NAME 'dbisNetgroupConfig' DESC 'DBIS netgroup configuration map' SUP dbisMapConfig STRUCTURAL )

netgroupObject

netgroupObject est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.4 NAME 'netgroupObject' DESC 'DBIS netgroup entry' SUP top STRUCTURAL MUST en MAY ( netgroupHost $ netgroupUser $ netgroupTriple $ exactNetgroup $ description $ manager $ disableObject ) )

en

   Le nom du netgroup est stocké dans l'attribut en qui est définis dans draft-bannister-dbis-mapping. L'attribut en doit être associé avec l'entrée netgroupObject et devrait former le RDN. Si requis, des entrées alias peuvent être définies.

netgroupHost

Un hôte qui est membre d'un netgroup est stocké dans l'attribut netgroupHost qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.8 NAME 'netgroupHost' DESC 'Host or domain that is assigned to a netgroup' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Le représentation chaîne de l'attribut netgroupHost devrait matcher la grammaire suivante, qui utilise les productions ABNF:
host = keyname-low
domain = keyname-low *(DOT keyname-low)
host-domain = host DOT domain
all-domain = ASTERISK DOT domain
    
netgroupHost = host / host-domain / all-domain

   Un DUA devrait dé-référencer les alias et convertir les composants de nom d'hôte et de domaine en caractères minuscule avant de former un attribut netgroupHost ou un filtre.

netgroupUser

Un utilisateur qui est un membre d'un netgroup est stocké dans l'attribut netgroupUser qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.9 NAME 'netgroupUser' DESC 'User who is assigned to a netgroup' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

La représentation chaîne de l'attribut netgroupUser devrait matcher la grammaire suivante, qui utilise les production ABNF:
user = keyname
user-host = user ATSIGN host
user-host-domain = user ATSIGN host-domain
user-all-domain = user ATSIGN all-domain
    
netgroupUser = user / user-host
netgroupUser =/ user-host-domain / user-all-domain

   Un DUA devrait convertir les composants de nom d'hôte et de domaine en caractères minuscule avant de former un attribut netgroupUser ou un filtre.

netgroupTriple

Pour compatibilité avec la rfc2307, DBIS permet aux membre des netgroup d'être exprimés sous la forme de triplets netgroup en fournissant un ou plusieurs attributs netgroupTriple qui peuvent être assignés à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.37 NAME 'netgroupTriple' DESC 'Case exact netgroup triple' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   Un DUA devrait convertir les composants de nom d'hôte et de domaine en caractères minuscule avant de former un attribut netgroupTriple ou un filtre.

exactNetgroup

Les membres d'autres netgroups peuvent être hérités par ce netgroup en fournissant des noms de netgroup additionnels dans un ou plusieurs attributs exactNetgroup qui peut être assigné avec une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.10 NAME 'exactNetgroup' DESC 'Case exact netgroup name associated with this entry' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

   Les DUA devraient valider qu'un netgroup référencé par cet attribut existe et est actif. Si le netgroup n'est pas définis, ou s'il a été désactivé avec l'attribut disableObject, il ne devrait pas être inclus dans la réponse au client.

description

   L'attribut description peut être associé avec une entrée netgroupObject pour fournir une description arbitraire de l'entrée

manager

   L'attribut manager peut être associé avec une entrée netgroupObject pour fournir un ou plusieurs DN d'individus, de groupes ou systèmes qui sont responsable de la maintenance de cette entrée.

disableObject

   Une entrée netgroup peut être désactivé en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA se comporte comme si le netgroup n'existe pas. Le DUA peut optionnellement fournir un mécanisme séparé pour les entrées désactivées, mais elles doivent être clairement marquées comme désactivées pour qu'aucune confusion ne se produise.

Exemple d'entrée netgroup


dn: en=sales-mgmt,ou=netgroup,ou=sales,o=infra
objectClass: top
objectClass: netgroupObject
en: sales-mgmt
netgroupHost: picard.sales.corp
netgroupHost: *.fleet.sales.corp
netgroupUser: mark@riker.sales.corp
netgroupUser: julie@*.market.sales.corp
exactNetgroup: board-mgmt
exactNetgroup: board-mgmt-remote
description: Sales Management Privileges

Déterminer les hôtes membres

   Un DUA devrait effectuer une recherche DNS inversée de l'adresse IP primaire de l'hôte pour déterminer le nom fqdn à utiliser pour le netgroup correspondant. Un hôte doit rencontrer un des conditions suivantes pour être considéré un memre d'un netgroup:

a) Un nom d'hôte non qualifié convertis en minuscule correspond exactement à l'attribut netgroupHost. Dans ce scénario l'attribut netgroupHost est également non qualifié.
b) Le nom d'hôte pleinement qualifié convertis en minuscule correspond exactement à l'attribut netgroupHost.
c) L'attribut netgroupHost utilise le motif all-domain, et le nom de domaine pleinement qualifié convertis en minuscule correspond à cet attribut quand le préfix est supprimé.

Déterminer les utilisateurs membres

   Un utilisateur doit rencontrer un des conditions suivantes pour être considéré un membre d'un netgroup:

a) L'attribut netgroupUser ne contient pas le ATSIGN et le nom d'utilisateur correspond exactement à l'attribut netgroupUser
b) Le nom d'utilisateur matche exactement le composant user de l'attribut netgroupUser, et le nom d'hôte non qualifié du DUA qui est obtenu comme décris précédemment et convertis en minuscule correspond exactement au composant hôte de l'attribut netgroupUser
c) Le nom d'utilisateur correspond exactement au composant utilisateur de l'attribut netgroupUser, et le nom d'hôte pleinement qualifié du DUA correspond exactement au composant domain d'hôte de l'attribut netgroupUser.
d) Le nom d'utilisateur correspond exactement au composant utilisateur de l'attribut netgroupUser qui utilise le motif all-domain et le nom de domaine pleinement qualifié du DUA correspond à cet attribut quand le préfix est supprimé.

netservice

   Une base netservice mappe les netgroups aux services et privilèges. Les netservices peuvent être utilisé pour déterminer quelles applications devraient fonctionner sur un hôte, comment ils devraient être configurés, et quelles actions les utilisateurs peuvent ou non effectuer.

La représentation chaîne d'un nom netservice pleinement qualifié devrait correspondre à la grammaire suivante, qui utilise les production ABNF:
service-name = keyname
service-descriptor = keyname *(SLASH keyname)
en = service-name COLON service-descriptor

   Le composant service-name identifie le service, et le service-descriptor est un chemin délimité par des slash qui identifie un sous-composant ou un sous-système dans le service. Une application est libre d'interpréter le nom d'un netservice de la manière qui lui convient, bien qu'il est suggéré qu'un netservice identifie soit un privilège soit une configuration qui peut être application au niveau de l'hôte ou utilisateur.

   Le service-name est représenté dans LDAP par une entrée avec l'objectClass netserviceObject. Chaque composant délimité par un slash du service-descriptor sont des objets enfants dans LDAP avec l'objectClass netserviceDescriptor.

ObjectClass

   Une entrée dbisMapConfig pour une base netservice devrait avoir l'objectClass dbisNetserviceConfig. Un netservice devrait être définis par une entrée LDAP avec l'objectClass netserviceObject.

dbisNetserviceConfig

La classe dbisNetserviceConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.5 NAME 'dbisNetserviceConfig' DESC 'DBIS netservice configuration map' SUP dbisMapConfig STRUCTURAL )

netserviceObject

La classe netserviceObject devrait être assigné à l'entrée qui représente un service-name et est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.6 NAME 'netserviceObject' DESC 'DBIS netservice top-level entry' SUP netserviceDescriptor STRUCTURAL MUST en MAY ( description $ manager $ disableObject ) )

netserviceDescriptor

La classe netserviceDescriptor devrait être assigné à chaque entrée qui représente les composants service-descriptor et est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.7 NAME 'netserviceDescriptor' DESC 'DBIS netservice descriptor entry' SUP top STRUCTURAL MUST en MAY ( exactNetgroup $ exactNetservice $ description $ manager $ disableObject ) )

Attributes

en

   Le nom du netgroup est stocké dans l'attribut LDAP en qui est définis dans draft-bannister-dbis-mapping. L'attribut en doit être associé avec une entrée netgroupObject et devrait former le RDN. Si requis, des entrées alias peuvent être définies.

netgroupHost

Un hôte qui est membre d'un netgroup est stocké dans l'attribut netgroupHost qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.8 NAME 'netgroupHost' DESC 'Host or domain that is assigned to a netgroup' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Un hôte qui est membre d'un netgroup est stocké dans l'attribut netgroupHost qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.8 NAME 'netgroupHost' DESC 'Host or domain that is assigned to a netgroup' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

La représentation chaîne de l'attribut netgroupHost devrait matcher la grammaire suivante, qui utilise les productions ABNF:
host = keyname-low
domain = keyname-low *(DOT keyname-low)
host-domain = host DOT domain
all-domain = ASTERISK DOT domain
    
netgroupHost = host / host-domain / all-domain

   Un DUA devrait déréférencer tout alias et convertir les composant nom d'hôte et nom de domaine en minuscule avant de traiter l'attribut netgroupHost ou un filtre le contenant.

netgroupUser

Un utilisateur qui est membre d'un netgroup est stocké dans l'attribut netgroupUser qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.9 NAME 'netgroupUser' DESC 'User who is assigned to a netgroup' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

La représentation chaîne de l'attribut netgroupUser devrait matcher la grammaire suivante, qui utilise les production ABNF:
user = keyname
user-host = user ATSIGN host
user-host-domain = user ATSIGN host-domain
user-all-domain = user ATSIGN all-domain
    
netgroupUser = user / user-host
netgroupUser =/ user-host-domain / user-all-domain
La représentation chaîne de l'attribut netgroupUser devrait matcher la grammaire suivante, qui utilise les production ABNF:
user = keyname
user-host = user ATSIGN host
user-host-domain = user ATSIGN host-domain
user-all-domain = user ATSIGN all-domain
    
netgroupUser = user / user-host
netgroupUser =/ user-host-domain / user-all-domain

   Un DUA devrait convertir les composant nom d'hôte et nom de domaine en minuscule avant de traiter un attribut netgroupUser ou un filtre le contenant.

netgroupTriple

Pour compatibilité avec la rfc2307, DBIS permet également l'appartenance exprimé sous la forme de triplet netgroup en fournissant un ou plusieurs attributs netgroupTriple qui peuvent être assignés à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.37 NAME 'netgroupTriple' DESC 'Case exact netgroup triple' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   Un DUA devrait convertir les composant nom d'hôte et nom de domaine en minuscule avant de traiter un attribut netgroupTriple ou un filtre le contenant.

exactNetgroup

   Les membres d'autres netgroup peuvent être hérités par ce netgroup en fournissant des noms de netgroup additionnels dans un ou plusieurs attributs exactNetgroup qui peuvent être assignés à une entrée netgroupObject:

   Le DUA devrait valider qu'un netgroup référencé par cet attribut existe et est activé. Si le netgroup n'est pas définis, ou s'il a été désactivé avec l'attribut disableObject, il ne doit pas être inclus dans la réponse au client.

manager

   L'attribut manager peut être associé avec une entrée netgroupObject pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsable de la maintenance de l'entrée.

disableObject

   Une entrée netgroup peut être désactivée en définissant l'attribut disableObject à TRUE.

Exemple d'entrée Netgroup


dn: en=sales-mgmt,ou=netgroup,ou=sales,o=infra
objectClass: top
objectClass: netgroupObject
en: sales-mgmt
netgroupHost: picard.sales.corp
netgroupHost: *.fleet.sales.corp
netgroupUser: mark@riker.sales.corp
netgroupUser: julie@*.market.sales.corp
exactNetgroup: board-mgmt
exactNetgroup: board-mgmt-remote
description: Sales Management Privileges

dn: en=sales-mgmt,ou=netgroup,ou=sales,o=infra
objectClass: top
objectClass: netgroupObject
en: sales-mgmt
netgroupHost: picard.sales.corp
netgroupHost: *.fleet.sales.corp
netgroupUser: mark@riker.sales.corp
netgroupUser: julie@*.market.sales.corp
exactNetgroup: board-mgmt
exactNetgroup: board-mgmt-remote
description: Sales Management Privileges

Déterminer les hôtes membre

   Un utilisateur doit rencontrer un des conditions suivantes pour être considéré un membre d'un netgroup:

        a) L'attribut netgroupUser ne contient pas de ATSIGN et le nom d'utilisateur correspond exactement à l'attribut netgoupUser
        b) Le nom d'utilisateur correspond au composant user de l'attribut netgroupUser, et le nom d'hôte non-qualifié du DUA convertis en minuscule correspond au composant hôte de l'attribut netgroupUser.
        c) Le nom d'utilisateur correspond au composant user de netgroupUser, et le nom d'hôte pleinement qualifié du DUA convertis en minuscule correspond au composant de domaine hôte de l'attribut netgroupUser.
        d) Le nom d'utilisateur correspond au composant user de l'attribut netgroupUser, l'attribut netgroupUser utilise le motif all-domain et le nom de domaine pleinement qualifié du DUA convertis en minuscule correspond à cet attribut quand le préfix ASTERISK DOT est supprimé.

netservice

   Une base netservice mappe les netgroups à des services et privilèges. Les netservices peuvent être utilisé pour déterminer quelles applications devraient fonctionner sur un hôte, comment ils devraient être configurés, et quelles actions les utilisateurs peuvent faire ou non.

La représentation chaîne d'un nom netservice pleinement qualifié devrait suivre la grammaire suivante, qui utilise les production ABNF:
service-name = keyname
service-descriptor = keyname *(SLASH keyname)
    
en = service-name COLON service-descriptor

   Le composant service-name identifie le service, alors que le service-descriptor est un chemin délimité par les anti-slash qui identifie un sous-composant ou un sous-système dans le service. Une application est lible d'interpréter le nom d'un netservice de la manière qui lui convienne, bien qu'il soit suggéré qu'un netservice identifie soit un privilège ou une configuration qui peut être appliqué au niveau de l'hôte ou utilisateur.

   service-name est représente dans LDAP par une entrée avec l'objectClass netserviceObject. Chaque composant délimité de service-descriptor sont des objets enfants dans LDAP avec l'objetClass netserviceDescriptor.

Classes d'objet

   Une entrée dbisMapConfig pour une base netservice devrait être assignée avec l'objectClass dbisNetserviceConfig

dbisNetserviceConfig

La classe dbisNetserviceConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.5 NAME 'dbisNetserviceConfig' DESC 'DBIS netservice configuration map' SUP dbisMapConfig STRUCTURAL )
La classe dbisNetserviceConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.5 NAME 'dbisNetserviceConfig' DESC 'DBIS netservice configuration map' SUP dbisMapConfig STRUCTURAL )

netserviceObject

La classe netserviceObject devrait être assignée à l'entrée qui représente le service-name et est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.6 NAME 'netserviceObject' DESC 'DBIS netservice top-level entry' SUP netserviceDescriptor STRUCTURAL MUST en MAY ( description $ manager $ disableObject ) )

netserviceDescriptor

La classe netserviceDescriptor devrait être assignée à chaque entrée qui représente des composants service-descriptor et est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.7 NAME 'netserviceDescriptor' DESC 'DBIS netservice descriptor entry' SUP top STRUCTURAL MUST en MAY ( exactNetgroup $ exactNetservice $ description $ manager $ disableObject ) )

Attributs

en

   Le service-name de netservice et chaque service-descriptor sont stockés dans des attributs LDAP de type en qui est définis dans draft-bannister-dbis-mapping. L'attribut en doit être associé avec une entrée netserviceObject et netserviceDescriptor, et devrait former le RDN. Si requis, des entrées alias peuvent être définies.

exactNetgroup

   Les utilisateurs et les hôtes bénéficient d'un netservice s'ils sont membre d'un ou plusieurs netgroups identifiés par les attributs exactNetgroup qui peuvent être assignés à une entrée netserviceDescriptor.

exactNetservice

d'autres netservices peuvent être hérités en utilisant un ou plusieurs attributs exactNetservice qui peuvent être assignés à une entrée netserviceDescriptor:
attributetype ( 1.3.6.1.4.1.23780.219.2.11 NAME 'exactNetservice' DESC 'Case exact netservice name associated with this entry' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

   Chaque netservice identifié par l'attribut exactNetservice devrait être un nom netservice pleinement qualifié. Le DUA devrait valider qu'un netservice référencé par cet attribut existe et est activé. Si le netservice n'est pas définis, ou s'il n'a pas été désactivé avec l'attribut disableObject, il ne devrait pas être considéré.

description

   L'attribut description peut être associé avec une entrée netserviceObject ou netserviceDescriptor pour fournir une description arbitraire de l'entrée.

manager

   L'attribut manager peut etre associé avec un netserviceObject ou netserviceDescriptor pour fournir un ou plusieurs DN des individus, groupes ou systèmes qui sont responsables de la maintenance de l'object.

disableObject

   Une entrée netservice peut être désactivée en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si l'entrée n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivées, mais doit les marquer clairement comme désactivés. L'attribut disableObject peut être définis sur soit dans l'entrée netserviceObject soit netserviceDescriptor. Si définis dans l'entrée netserviceObject, le DUA devrait traiter toutes les entrées netserviceDescriptor présents comme désactivés également.

Exemple d'entrées netservice

L'exemple suivante montre des entrées netservice au format ldif:
dn: en=ssh,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
objectClass: netserviceObject
en: ssh
description: Secure Shell Service
    
dn: en=login,en=ssh,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
en: login
exactNetgroup: all-hosts
exactNetservice: ftp:login
exactNetservice: web:login/anonymous
    
dn: en=ftp,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
objectClass: netserviceObject
en: ftp
description: FTP Service
    
dn: en=login,en=ftp,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
en: login
    
dn: en=web,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
objectClass: netserviceObject
en: web
description: Web Service
    
dn: en=login,en=web,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
en: login
    
dn: en=anonymous,en=login,en=web,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
en: anonymous

   Ces entrées exemple définissent un netservice appelé ssh:login qui est permis aux membres de du netgroup all-hosts. Si ce netservice est activé, les netservices ftp:login et web:login, également définis, seront activés automatiquement.

Attributs communs

   Des attributs additionnels qui sont soit utilisés dans ce document ou requis par d'autres documents en utilisant les netgroups sont définis ou référencés ci-dessous.

notNetgroup

Un ou plusieurs netgroups qui sont exclus d'une entrée de configuration particulière sont fournis dans les attributs notNetgroup:
attributetype ( 1.3.6.1.4.1.23780.219.2.12 NAME 'notNetgroup' DESC 'Case exact netgroup name NOT to be associated with this entry' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

Syntaxe d'attribut

Les syntaxes suivantes sont utilisées par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax OID Value Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.15 Directory String [RFC4517]
1.3.6.1.4.1.1466.115.121.1.26 IA5 String [RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Notes d'implémentation

netgroups NIS

   les netgroups DBIS diffèrent des netgroups NIS et des netgroups définis dans la rfc2307, qui utilise des triplets au format: (host,user,domain), où "host" est le nom d'hôte canonique du système client demandant un service, "user" est le nom d'utilisateur qui demande un service, et "domain" est le nom de domaine du service demandé. Il les champs host, user et domain sont vides, alors le netgroup NIS s'applique à tous les hôtes, utilisateurs, ou domaines respectivement.

   L'utilisation la plus commune des netgroups NIS est pour définir des groupes d'hôte et d'utilisateurs alors que le domaine est généralement laissé vide.

   DBIS sépare le triplet en 2 attributs séparés, netgroupHost et netgroupUser, et redéfinis également le composant domaine à utiliser pour représenter tous les hôtes dans un domaine donné. Un jeu de règles de mappage peut être utilisé pour convertir la représentation chaîne de netgroup DBIS et une liste de triplets netgroup NIS. Dans la grammaire suivante, la règle commençant par t- est sélectionnée en fonction de l'information fournie dans l'attribut netgroupHost ou netgoupUser. En supprimant le t- on peut déduire le nom de la règle de correspondance:


t-host = LPAREN host COMMA COMMA RPAREN
t-host-domain = LPAREN host-domain COMMA COMMA RPAREN
t-all-domain = LPAREN COMMA COMMA domain RPAREN
t-user = LPAREN COMMA user COMMA RPAREN
t-user-host = LPAREN host COMMA user COMMA RPAREN
t-user-host-domain = LPAREN host-domain COMMA user COMMA RPAREN
t-user-all-domain = LPAREN COMMA user COMMA domain RPAREN
    
triple-any = t-host / t-host-domain / t-all-domain
triple-any =/ t-user / t-user-host / t-user-host-domain
triple-any =/ t-user-all-domain
    
triples = t-any *(SPACE t-any)

Former les entrées netgroupHost ou netgroupUser

   L'appartenance à un netgroup devrait être exprimé en termes de noms canoniques uniquement. Vu que le composant username de l'attribut netgroupUser est sensible à la casse alors que les autres composants ne le sont pas, un DUA devrait convertir les composants nom d'hôte et nom de domaine en minuscule avant de former un attribut netgroupHost ou netgroupUser ou un filtre le contenant. C'est pour s'assurer que la correspodance effectuée sur ces attributs n'échoueront pas sur le nom d'hôte ou le nom de domaine sur à une problème de casse.

Paramètres de recherche

   Cette section fournis des exemples de filtres de recherche pour obtenir des entrées de base avec les critères communément utilisés.

   Pour simplifier les exemples, on assume que toutes les base ont une seul entrée de map de configuration (dbisMapConfig). Cependant, le draft-bannister-dbis-mapping permet d'utiliser plusieurs entrées, donc pour qu'une implémentation le supporte, le nombre d'opérations de recherche nécessaire pour localiser toutes les entrées de base doit être augmenté.

   Ce document ne considère pas comment incorporer les entrées de base hosts ou passwd qui utilisent l'attribut exactNetgroup comme moyen alternatif pour spécifier les membre de netgroup.

   Le DN de base utilisé dans les opérations de recherche décris dans cette section vient de l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter qu'une entrée dbisMapConfig peut en avoir plusieurs.

   Quand il apparaît dans les filtres de recherche ci-dessous, le texte "dbisMapFilter" réfère à la valeur assignée à l'attribut de même nom dans l'entrée dbisMapConfig correspondante. Noter que les base netgroup et netservice utilisé dans ces filtres de recherche peuvent être modifiés par l'attribut dbisMapClass et dbisMapAttr assigné à l'entrée dbisMapConfig. Dans tous les filtres ci-dessous, les noms de domaine DNS pleinement qualifiés sont obtenus comme décris dans la section "Déterminer les hôtes membre".

Trouver la Map de configuration pour le domaine

   Pour localiser la map de configuration pour un domaine DBIS donné, recherche les entrées sous l'entrée dbisDomainObject

Les maps netgroup peuvent être trouvés avec le filtre de recherche suivant
(&(objectClass=dbisNetgroupConfig)(!(disableObject=TRUE)))
Les maps netservice avec:
(&(objectClass=dbisNetserviceConfig)(!(disableObject=TRUE)))

Lister toutes les entrées

Les netgroup et netservices sont énumérés en appliquant le dbisMapFilter comme suit:
(&(dbisMapFilter)(!(disableObject=TRUE)))

Trouver un netgroup ou netservice particulier

Is un netgroup ou netservice est connu par "nom", sa définition est localisée en utilisant le filtre de recherche suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name))

   Si c'est un netservice et que l'entrée retournée est un netserviceDescriptor et pas un netserviceObject, alors un test additionnel devrait être effectué sur l'attribut disableObject sur le netserviceObject parent pour déterminer si le netservice est désactivé.

   En recherchant des netservice spécifiques par nom, ce filtre peut retourner plus d'un résultat, vu que l'unicité de l'espace de nom est déterminé par le chemin et non par le nom dans une entrée LDAP.

Trouver des netgroup par membership

Pour obtenir une liste de tous les netgroups qu'un utilisateur avec le nom de login "user", qui est connecté sur un hôte nommé "host" avec le domaine DNS "domain" est un membre, le filtre de recherche suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(|(netgroupUser=user)(netgroupUser=user@host.domain)(netgroupUser=user@\2a.domain)))

Pour obtenir une liste de tous les netgroups qu'un système nommé "host" avec le nom dns "domaine" est un membre, le filtre suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(|(netgroupHost=host)(netgroupHost=host.domain)(netgroupHost=\2a.domain)))

   Si l'utilisateur ou l'hôte n'est pas un membre explicite du netgroup, le membreship implicite doit être déterminé en examinant récursivement chaque attribut exactNetgroup dans le jeu de résultat. Pour empêcher les boucles infinies, un DUA ne devrait pas tester un netgroup plus d'une fois durant une opération de membership.

Membre d'un netgroup spécifique

Pour déterminer si un utilisateur avec un nom "user", qui est loggé sur un hôte nommé "host", avec un nom de domaine "domain" est un membre d'un netgroup spécifique appelé "name", le filtre de recherche suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name)(|(netgroupUser=user)(netgroupUser=user@host.domain)(netgroupUser=user@\2a.domain)))

Pour déterminer si un système nommé "host" avec le nom de domaine "domain" est un membre d'un netgroup spécifique appelé "name", le filtre de recherche suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name)(|(netgroupHost=host)(netgroupHost=host.domain)(netgroupHost=\2a.domain)))

   Si l'utilisateur ou l'hôte n'est pas un membre explicite du netgroup, un membership implicite doit être détermineé en examinant récursivement chaque attribut exactNetgroup dans le jeu de résultat.

Quels Netgroups sont activés

   parfois il est nécessaire de déterminer depuis une liste de netgroups quels sont ceux qui sont activés. Cela peut être effectués en utilisant une opération de recherche. Dans cet exemple les netgroups testés sont appelés "netgr1", "netgr2" et "netgr3".

Pour déterminer si une système nommé "host" avec le nom de domaine "domaine" est un membre d'un netgroup spécifique appelé "name", le filtre suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(|(en=netgr1)(en=netgr2)(en=netgr3)))

Trouver des netservices par membership

Pour obtenir une liste de tous les netservices qui sont assignés au netgroup appelé "netgroup", le filtre suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(exactNetgroup=netgroup))

   Le nom netservice peut être dérivé du DN des entrées retournées. Par exemple, "en=anonymous,en=login,en=web,dbisMapDN" représente le netservice web:login/anonymous.

   Chaque entrée retournée peut lister des netservices additionnels assignés par l'attribut exactNetservice

   Si une entrée netservice trouvé est un netserviceDescriptor et non un netserviceObject, un test supplémentaire devrait être effectué pour l'attribut disableObject sur le netserviceObject parent pour déterminer si le netservice est désactivé.

Membre d'un netservice spécifique

   Pour déterminer si un netgroup a été assigné à un netservice spécifique, le nom netservice doit être splitté en un nom de chemin consistant de 'en=...,en=...' pour qu'une entrée spécifique avec l'objectClass netserviceDescriptor puisse être recherchée sous dbisMapDN. Si cette entrée a un attribut exactNetgroup correspondant au nom de membre désiré, une correspondance est trouvée.

   Par exemple, le netservice web:login/anonymous devient le chemin 'en=anonymous,en=login,en=web' sous dbisMapDN. Le netserviceDescriptor correspondant à ce DN contient la définition du netservice donné. L'attribut exactNetgroup associé avec cette entrée contient la liste des netgroups assignés au netservice web:login/anonymous.

De plus, le filtre de recherche suivant peut être utilisé pour localiser les netservices qui incluent en netservice appelé "netservice" dans leur définitions et qui sont assignés au netgroup nommé "netgroup":
(&(dbisMapFilter)(!(disableObject=TRUE))(exactNetservice=netservice)(exactNetgroup=netgroup))

   Si une entrée est retournée par une recherche avec ce filtre alors une correspondance a été trouvée.
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-passwd-05

draft-bannister-dbis-passwd-05

dbis: passwd et group

   Ce document étend DBIS pour supporter les bases passwd et group. Ces schémas de base devraient être compatible avec NIS, mais stockés dans des entrées X.500 pour qu'ils puissent être résolus avec le protocole LDAP. Une base passwd représente les comptes de connexion utilisateurs sur les systèmes UNIX et dérivés et une base group représente des groupes d'utilisateurs.

   Ce document décris les maps de configuration pour les bases de données passwd et group, et les entrées de base référencée par ces maps.

Maps de configuration

   Toutes les base décrites dans ce document utilisent les maps de configuration standard définies dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les bases passwd et group devraient être assignées avec l'objectClass dbisPasswdConfig et dbisGroupConfig, respectivement.

Il est recommandé que l'entrée dbisMapConfig pour une base passwd ou group ait l'attribut dbisMapFilter définis en accord avec la table suivante:
Database______dbisMapFilter
passwd________objectClass=posixUserAccount
group_________objectClass=posixGroupAccount

Exemple d'entrées de map de configuration

L'exemple suivant donne un exemple d'entrée de map de configuration pour une base passwd:
dn: cn=passwd,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisPasswdConfig
cn: passwd
dbisMapDN: cn=passwd,ou=dbis,o=infra
dbisMapFilter: objectClass=posixUserAccount
dbisMapGecos: displayName
profileTTL: 900
description: Primary passwd database

L'exemple suivant donne un exemple d'entrée de map de configuration pour une base group:
dn: cn=group,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisGroupConfig
cn: group
dbisMapDN: cn=group,ou=dbis,o=infra
dbisMapFilter: objectClass=posixGroupAccount
profileTTL: 900
description: Primary group database

base passwd

   Une base de données passwd contient les champs suivants:

- Nom d'utilisateur
- Mot de passe de l'utilisateur
- Identifiant numérique de l'utilisateur
- Identifiant numérique du groupe primaire de l'utilisateur
- description de l'utilisateur
- Chemin du répertoire personnel de l'utilisateur
- Chemin du shell de connexion de l'utilisateur.

ObjectClass

   Une entrée dbisMapConfig pour une base passwd devrait avoir l'objectClass dbisPasswdConfig. Une entrée passwd devrait être définie par une entrée LDAP avec l'objectClass posixUserAccount. Vu que c'est une classe auxiliaire, elle doit également avoir une classe structurelle assignée qui n'est pas définis dans ce document, par exemple inetOrgPerson.

dbisPasswdConfig

La classe dbispasswdConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.8 NAME 'dbisPasswdConfig' DESC 'DBIS passwd configuration map' SUP dbisMapConfig STRUCTURAL MUST dbisMapGecos MAY dbisOverlayDN )

posixUserAccount

La classe posixUserAccount est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.9 NAME 'posixUserAccount' DESC 'User account with POSIX attributes' SUP top AUXILIARY MUST ( en $ uidNumber $ gidNumber $ homeDirectory ) MAY ( authPassword $ userPassword $ loginShell $ disableObject ) )

Attributs

  

dbisMapGecos

le champ gecos maintient traditionnellement le nom complet de l'utilisateur et parfois d'autres informations descriptive sur le compte. informations qui sont mieux stockées dans des attributs nommés plus spécifiquement. Vu qu'il y a une variété de manière de stocker ces informations déjà disponibles, ce document ne définis pas de champs additionnel pour les informations gecos, mais l'attribut dbisMapGecos doit être assigné à une entrée dbisPasswdConfig et qui maintient le nom de l'attribut à utiliser pour fournir les informations gecos. Il est définis:
attributetype ( 1.3.6.1.4.1.23780.219.2.13 NAME 'dbisMapGecos' DESC 'Source attribute for gecos field' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   L'objectClass posixUserAccount est auxiliaire et doit toujours être associé avec une autre classe structurelle. Une telle classe est inetOrgPerson. Si les comptes utilisateurs on la class inetOrgPerson, le displayName peut être une valeur approprié pour l'attribut dbisMapGecos.

dbisOverlayDN

Un ou plusieurs DN identifiant la base de recherche pour les entrées overlay sont stockés dans l'attribut dbisOverlayDN qui peut être assigné à une entrée dbisPasswdConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.14 NAME 'dbisOverlayDN' DESC 'DN of search base for DBIS overlay entries' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

en

   Le nom du compte utilisateur est stocké dans l'attribut en qui est définis dans draft-bannister-dbis-mapping. L'attribut en doit être associé avec une entrée posixUserAccount et devrait former le RDN.

uidNumber

L'UID est stocké dans l'attribut uidNumber qui doit être assigné à l'entrée posixUserAccount:
attributetype ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' DESC 'An integer uniquely identifying a user in an administrative domain' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

gidNumber

Le GID primaire est stocké dans l'attribut gidNumber qui doit être assigné à une entrée posixGroupAccount:
attributetype ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' DESC 'An integer uniquely identifying a group in an administrative domain' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

homeDirectory

Le chemin du répertoire personnel de l'utilisateur est stocké dans l'attribut homeDirectory qui doit être assigné à une entrée posixUserAccount:
attributetype ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' DESC 'The absolute path to the home directory' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

authPassword

   Le mot de passe chiffré de l'utilisateur est stocké dans l'attribut authPassword qui est définis dans la rfc3112, et qui peut être assigné à une entrée posixUserAccount.

   Bien qu'un DUA peut implémenter tout schéma de mot de passe d'authentification supporté par le DSA, il doit supporter le schéma CRYPT pour la compatibilité, qui est une implémentation de l'algorithme de chiffrement traditionnel UNIX. Cependant, il est recommandé qu'un schéma plus sécurisé soit utilisé.

   Si l'attribut authPassword a plusieurs valeurs, le DUA devrait sélectionner un mot de passe basé sur le schéma d'authentification le plus fort qu'il supporte et l'utiliser pour l'authentification. Si l'authentification échoue, le DUA ne devrait pas tenter d'utiliser d'autres valeurs. Si l'attribut n'utilise pas de schéma supporté par le DUA, alors le DUA ne devrait pas réussir l'authentification.

   Si une entrée posixUserAccount n'a pas d'attribut authPassword ou userPassword, le compte est blocké. Un DUA ne devrait pas réussir une authentification sur un compte blocké.

   Le transfert des valeurs authPassword est fortement découragé quand le service de transport sous-jacent ne peut pas garantir la confidentialité.

userPassword

   Pour des raisons de compatibilité, le mot de passe chiffré de l'utilisateur peut alternativement être stocké dans l'attribut userPassword qui peut être assigné à une entrée posixUserAccount.

   Il est prévu pour supporter les configurations existantes uniquement et ne devrait pas être utilisé pour les nouvelles entrées, qui devraient utiliser authPassword.

La représentation chaîne de l'attribut userPassword devrait matcher la grammaire suivante, spécifiée en notation ABNF:
scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme
altscheme = "x-" keystring
userPassword = LCURLY scheme RCURLY cryptpass

   où "cryptpass" représente le mot de passe hashé par l'algorithme spécifié. Si le schéma est "sha", le SHA-1 du mot de passe est calculé, et le mot de passe chiffré devrait être encodé en base64.

   Bien qu'un DUA peut implémenter n'importe quel schéma supporté par le DSA, il doit supporter le schéma "crypt" pour des raisons de compatibilité. Cependant, il est recommandé qu'un schéma plus sécurisé soit utilisé.

   Si l'attribut userPassword a plus d'un seul valeur, le DUA devrait sélectionner un mot de passe basé sur le schéma d'authentification le plus fort qu'il supporte. Si l'authentification échoue, le DUA ne devrait pas tenter d'utiliser d'autres valeurs. Si l'attribut n'utilise pas de schéma supporté par le DUA, l'authentification doit échouer.

loginShell

Le chemin du répertoire personnel de l'utilisateur est stocké dans l'attribut loginShell qui peut être assigné à une entrée posixUserAccount:
attributetype ( 1.3.6.1.1.1.1.4 NAME 'loginShell' DESC 'The path to the login shell' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   Si le loginShell est manquant, cet utilisateur ne sera pas capable de se connecter sur un hôte ou un service qui nécessite un shell unix.

disableObject

   Un compte utilisateur peut être désactivé en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si cet utilisateur n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivées, mais elles doivent être clairement marquées désactivées pour ne pas créer de confusion.

Exemple d'entrée passwd

L'exemple suivant est un exemple d'entrée posixUserAccount au format LDIF:
dn: en=mark,ou=passwd,ou=sales,o=infra
objectClass: top
objectClass: inetOrgPerson
objectClass: posixUserAccount
cn: Mark
sn: Bannister
displayName: Bannister, Mark
en: mark
uidNumber: 101
gidNumber: 900
homeDirectory: /home/mark
loginShell: /bin/bash

groupes

   Une base group contient les détails suivants:

- Le nom du groupe
- Le mot de passe du groupe
- Un identifiant numérique pour le groupe
- La liste des membres

ObjectClass

   Une entrée dbisMapConfig pour une base group devrait avoir l'objectClass dbisGroupConfig. Une entrée group devrait être définie par une entrée avec l'objectClass posixGroupAccount.

dbisGroupConfig

La classe dbisGroupConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.11 NAME 'dbisGroupConfig' DESC 'DBIS group configuration map' SUP dbisMapConfig STRUCTURAL MAY dbisOverlayDN )

posixGroupAccount

La classe posixGroupAccount est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.12 NAME 'posixGroupAccount' DESC 'Group account with POSIX attributes' SUP top STRUCTURAL MUST ( en $ gidNumber ) MAY ( authPassword $ userPassword $ exactUser $ uniqueMember $ description $ manager $ disableObject ) )

en

   Le nom du compte groupe est stocké dans l'attribut en. Cet attribut doit être associé avec une entrée posixGroupAccount et devrait former le RDN.

gidNumber

   Le GID est socké dans l'attribut gidNumber qui doit être assigné à une entrée posixGroupAccount

authPassword

   Le mot de passe chiffré du groupe est stocké dans l'attribut authPassword qui peut être assigné à une entrée posixGroupAccount. Toutes les considérations liées à l'attribut authPassword données dans la section de même nom pour la base passwd s'applique également aux entrées posixGroupAccount. Si un attribut authPassword est définis, l'utilisateur doit fournir le bon mot de passe avant que le DUA autorise la bascule dans ce groupe

userPassword

   Pour des raisons de compatibilité, le mot de passe chiffré du groupe peut alternativement être stocké dans l'attribut userPassword et peut être assigné à une entrée posixGroupAccount. Toutes les considérations liées à l'attribut userPassword données dans la section de même nom pour la base passwd s'applique également aux entrées posixGroupAccount.

exactUser

Une liste d'un ou plusieurs noms de comptes qui sont membres du groupe sont stockés dans les attributs exactUser qui peuvent être assignés à une entrée posixGroupAccount:
attributetype ( 1.3.6.1.4.1.23780.219.2.26 NAME 'exactUser' DESC 'One or more user account names' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

uniqueMember

   Pour des raisons de compatibilité, les membres du groupe peuvent alternativement être stockés dans l'attribut uniqueMember et peut être assigné à une entrée posixGroupAccount. Il est prévu pour supporter les configurations existantes uniquement et ne devrait pas être utilisé pour les nouvelles entrées. Un DUA doit supporter les 2 format.

   Les membres référés par l'attribut uniqueMember devrait être assumés avoir été présentés via la map de configuration existante, même s'ils sont présentés dans un DN de base différent. L'attribut uniqueMember n'est donc pas prévu pour référencer les utilisateurs ou groupes qui sont définis avec un schéma différent. L'attribut exactUser ne souffre pas de ce problème.

description

   L'attribut description peut être associé avec une entrée posixGroupAccount pour fournir une description arbitraire de l'entrée.

manager

   L'attribut manager peut être associé avec une entrée posixGroupAccount pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsables de la maintenance de l'entrée.

disableObject

   Un goupe peut être désactivé en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si le groupe n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivées, mais doivent les marquer clairement comme désactivé pour éviter toute confusion.

Exemple d'entrée groupe

L'exemple suivant est une entrée posixGroupAccount au format LDIF:
dn: en=finance,ou=group,ou=sales,o=infra
objectClass: top
objectClass: posixGroupAccount
en: finance
gidNumber: 152
exactUser: mark
exactUser: julie
exactUser: stephen
exactUser: nathan

Overlays

   Les overlays fournissent les entrées passwd et group alternatifs qui peuvent écraser l'UID, GID, Home ou shell pour les groupes d'hôtes qui partagent une map de configuration. C'est utile pour fusionner 2 domaines DBIS avec des ID qui se chevauchent en permettant une période de transition quand les hôtes et services du domaine d'origine peut continuer à utiliser leur ID et shell originaux. Un DUA devrait implémenter les overlays.

   Considérons l'exemple où UserA et UserB ont les UID 100 et 101, et le shell /bin/sh sur HostA et HostB, mais nécessitent les UID 1000 et 1001 et le shell /bin/csh sur HostC et HostD. Les 4 hôtes sont membre du même domaine DBIS. Les overlays permettent ce type de configuration. Un DUA devrait traiter les overlays après toute transformation définie dans la map de configuration.

ObjectClass

   Le DN top-level sous lequel rechercher les entrées overlay devraient être définis par l'attribut dbisOverlayDN qui est associé avec une entrée dbisPasswdConfig ou dbisGroupConfig. Les entrées overlay doivent résider sous ce DN s'ils sont utilisé par un DUA.

   Les entrées overlay pour la base passwd sont identifiées par l'objectClass dbisPasswdOverlay. Les entrées overlay pour la base group sont identifiés par l'objectClass dbisGroupOverlay.

dbisPasswdOverlay

La classe dbisPasswdOverlay est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.13 NAME 'dbisPasswdOverlay' DESC 'User account overlay entry' SUP top STRUCTURAL MUST en MAY ( uidNumber $ homeDirectory $ loginShell $ description $ disableObject ) )

dbisGroupOverlay

La classe dbisGroupOverlay est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.14 NAME 'dbisGroupOverlay' DESC 'Group account overlay entry' SUP top STRUCTURAL MUST en MAY ( gidNumber $ description $ disableObject ) )

Attributs

en

   L'attribut en doit être assigné à une entrée dbisPasswdOverlay ou dbisGroupOverlay et est utilisé pour identifier l'entrée posixUserAccount ou posixGroupAccount. Si les attributs en correspondent exactement, ou si c'est un dbisPasswdOverlay et qu'il n'y a pas de correspondance exacte mais une entrée pas défaut existe identifié par un attribut en contenant un asterisk, les attributs fournis par l'overlay devraient remplacer ceux dans l'entrée originale.

   Quand un DUA recherche une entrée posixUserAccount ou posixGroupAccount qui a une configuration d'overlay, il devrait également rechercher une entrée dbisPasswdOverlay ou dbisGroupOverlay.

   Si une entrée par défaut est trouvée (par ex: en=*), l'attribut uidNumber est ignoré s'il est assigné à l'objet dbisPasswdOverlay.

uidNumber

   Un UID alternatif à utiliser pour un compte utilisateur correspondant peut être stocké dans l'attribut uidNumber qui peut être associé avec une entrée dbisPasswdOverlay

gidNumber

   Un GID alternatif à utiliser pour un groupe correspondant peut être stocké dans l'attribut gidNumber qui peut être associé avec une entrée dbisGroupOverlay

HomeDirectory

   Un répertoire personnel alternatif à utiliser pour un compte utilisateur correspondant est stocké dans l'attribut homeDirectory qui peut être associé avec une entrée dbisPasswdOverlay.

loginShell

   Un shell de connexion alternatif à utiliser pour un compte utilisateur correspondante est stocké dans l'attribut loginShell qui peut être associé avec une entrée dbisPasswdOverlay.

description

   L'attribut description peut être associé avec une entrée dbisPasswdOverlay ou dbisGroupOverlay pour fournir une description arbitraire de l'entrée.

disableObject

   Une entrée overlay peut être désactivée en définissant l'attribut disableObject à TRUE. Si une entrée est désactivé, le DUA devrait se comporter comme si l'overlay n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivées, mais ils doivent les marquer clairement comme désactivé pour éviter toute confusion.

Exemple d'entrées overlay

L'exemple suivant montre un entrée dbisPasswdOverlay au format ldif, et les entrée dbisMapConfig correspondantes. Dans cet exemple, l'utilisateur "julie" qui se log sur des hôtes qui font partie du netgroup "sales-merger" aura un UID alternatif 5001 et un shell "/bin/sh". Si "julie" se logs sur un autre hôte, elle aura son UID et loginShell normal:
dn: cn=passwd,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisPasswdConfig
cn: passwd
dbisMapDN: cn=passwd,ou=dbis,o=infra
dbisMapFilter: objectClass=posixUserAccount
dbisMapGecos: displayName
notNetgroup: sales-merger
profileTTL: 900
description: Primary passwd database
    
dn: cn=passwd2,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisPasswdConfig
cn: passwd2
dbisMapDN: cn=passwd,ou=dbis,o=infra
dbisMapFilter: objectClass=posixUserAccount
dbisMapGecos: displayName
dbisOverlayDN: ou=passwd,ou=overlays,ou=sales-merger,o=infra
profileTTL: 900
description: Primary passwd database for Sales merger
    
dn: en=julie,ou=passwd,ou=overlays,ou=sales-merger,o=infra
objectClass: top
objectClass: dbisPasswdOverlay
en: julie
uidNumber: 5001
loginShell: /bin/sh

L'exemple suivant montre un dbisGroupOverlay qui modifie le GID pour le groupe "finance" quand il est utilisé dans une entrée de map de configuration:
dn: en=finance,ou=group,ou=overlays,ou=sales-merger,o=infra
objectClass: top
objectClass: dbisGroupOverlay
en: finance
gidNumber: 7308

Syntaxe d'attributs

Les syntaxes suivantes sont utilisée par les attributs définis dans ce document:
Syntax OID - - - - - - - - - - Value - - - - - - Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.12 DN - - - - - - - - [RFC4517]
1.3.6.1.4.1.1466.115.121.1.15 Directory String -[RFC4517]
1.3.6.1.4.1.1466.115.121.1.26 IA5 String - - - -[RFC4517]
1.3.6.1.4.1.1466.115.121.1.27 Integer - - - - - [RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Notes d'implémentation

  

Mappage des champs compatibles NIS

   Tous les champs requis pour le format des bases NIS passwd et group existent dans ce schéma et peuvent être mappés aux types d'attribut en utilisant les production ABNF décrites dans draft-bannister-dbis-netgroup.

passwd

Les champs de la base passwd sont mappés comme suit:
user = en
password = %x78 ; lowercase "x", see below
uid = uidNumber
gid = gidNumber
gecos = dbisMapGecos ; derived, see below
homedir = homeDirectory
loginshell = loginShell
    
passwd-entry = user COLON password COLON uid COLON gid COLON gecos COLON homedir COLON loginshell

- password vaux "x" qui signifie traditionnellement que le mot de passe est stocké dans la base shadow. Cependant, c'est dûs aux permission plus stricts du fichier shadow, rendant les mots de passe plus sécurisés. LDAP n'a pas ce problème, l'attribut authPassword est associé avec l'objectClass posixUserAccount. Un implémenteur peut cependant optionnellement reporter le mot de passe chiffré dans les entrées passwd NIS, ou pas du tout. Pour des raisons de sécurité il est recommandé que les utilisateurs ne puissent pas afficher leur mot de passe chiffré à d'autres utilisateurs ou groupe.
- gecos est déterminé en recherchant l'attribut définis par l'attribut dbisMapGecos donné dans l'entrée de map de configuration.

group

Les champs de la base group sont mappés comme suit:
group = en
password = %x2a ; asterisk "*", see below
gid = gidNumber
users = exactUser ; derived, see below
    
group-entry = group COLON password COLON gid COLON users

- Pour des raisons de sécurité il est recommandé que le mot de passe soit mis à "*" et pas de authPassword.
- La liste des utilisateur est une liste séparé par des virgules d'attributs exactUser.

Filtres de recherche communs

   Cette section fournis des exemples de filtres de recherche LDAP pour obtenir des entrées de base avec des critères d'entrée communément utilisés.

   Pour simplifier les exemples, toutes les base sont assumée être définis avec seulement une entrée de map de configuration. Cependant, une implémentation doit le supporter, augmentant le nombre d'opérations nécessaires pour localiser les entrées de base dans le scope.

   Le DN de base utilisé dans les opérations de recherche décrites dans cette section viennent de l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter qu'une entrée dbisMapConfig peut en avoir plusieurs.

   Quand il apparaît dans les filtres de recherche ci-dessous, le texte "dbisMapFilter" réfère à la valeur assignée à l'attribut de même nom dans l'entrée dbisMapConfig correspondante. Noter que les bases passwd et group ont des entrées dbisMapConfig différentes. Les noms d'attributs utilisés dans ces filtres de recherche peuvent être modifiés par l'attribut dbisMapAttr assignés à l'entrée dbisMapConfig.

Pour localiser la map de configuration pour un domain DBIS donné, rechercher les entrées sous l'entrée dbisDomainObject:
(&(objectClass=dbisPasswdConfig)(!(disableObject=TRUE)))
(&(objectClass=dbisGroupConfig)(!(disableObject=TRUE)))
Les entrées passwd et group sont énumérées en appliquant le filtre dbisMapFilter suivant:
(&(dbisMapFilter)(!(disableObject=TRUE)))
Si une entrée passwd et group est connue pas "name", sa définition est localisée en utilisant le filtre de recherche suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name))
Si une entrée passwd a l'uid "uid", sa définition est localisée en utilisant le filtre suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(uidNumber=uid))
Si une entrée group a le gid "gid", sa définition est localisée en utilisant le filtre suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(gidNumber=gid))
^
15 septembre 2014

htmlpdflatexmanmd




draft-behera-ldap-password-policy-10

draft-behera-ldap-password-policy-10

Stratégie de mot de passe pour les annuaires LDAP

   La stratégie de mot de passe comme décrit dans ce document est un jeu de règles qui contrôle comment les mots de passes sont utilisés et administrés dans les annuaires basés sur LDAP. Pour améliorer la sécurité les annuaires LDAP et rendre la tâche des programmes de cracking de mot de passe plus difficile. Cet règles sont faites pour s'assurer que les utilisateurs changent leur mot de passe périodiquement, et que ces mots de passe soient soumis à des obligations, et une restriction sur la réutilisation des anciens mots de passe.

Application des stratégies de mot de passe

   La stratégie de mot de passe définie dans ce document peut être appliquée à tout attribut maintenant un mot de passe utilisateur utilisé pour les opérations de bind LDAP. Dans ce document, le terme utilisateur représente toute application LDAP cliente qui a une identité dans l'annuaire.

   Cette stratégie est typiquement appliquée à l'attribut userPassword dans le cas de la méthode d'authentification simple bind ou dans le cas d'un mot de passe basé sur une authentification SASL tel que CRAM-MD5 et DIGEST-MD5.

   La stratégie décrite dans ce document assume que l'attribut du mot de passe maintient une simple valeur. Aucune considération n'est faite pour les annuaires ou systèmes qui permettent à un utilisateur de maintenir des attributs de mot de passe multi-valués.

   Les implémentations de serveur peuvent inclure une stratégie interne où certaines identités (tels que les administrateurs d'annuaire) ne soient pas soumis à une stratégie de mot de passe. Dans ce cas, le mot de passe pour un administrateur d'annuaire n'expire jamais; le compte n'est jamais bloqué, etc.

Stratégie d'utilisation de mot de passe

   Cette section décris la stratégie utilisée quand un mot de passe est utilisée. L'objectif général de cette stratégie est de réduire au minimum la menace d'intrus une fois un mot de passe utilisé.

Stratégie de validité de mot de passe

   Ces mécanismes permettent de contrôler l'utilisation de compte indépendemment de toute stratégie d'expiration de mot de passe. La stratégie définis la période de temps absolue pour lequel un compte peut être utilisé. Cela permet à un administrateur de définir une date de début après laquelle un mot de passe devient valide, et une date de fin après laquelle le mot de passe est désactivé. Un mécanisme est également fournis pour définir la période de temps pour laquelle un compte peut rester non-utilisé avant d'être désactivé.

Limiter les mots de passe devinés

   Pour empêcher un intrus de deviner le mot de passe d'un utilisateur, un mécanisme existe pour traquer le nombre de tentative d'authentification échouées, et agir lorsque la limite est atteinte. Cette stratégie consiste de nombreuses parties:

        - Un compteur pour suivre le nombre de tentative d'authentification échouées.
        - La quantité de temps à attendre dans la première authentification échouée.
        - La quantité maximum de temps à attendre pour les échecs suivants
        - Un timeframe dans lequel la limite de tentative d'authentification échouées doit être atteinte avant qu'une action soit prise.
        - Une limite configurable de tentative d'authentification échouées.
        - L'action a prendre quand la limite est atteinte. L'action sera soit "rien", ou le compte sera bloqué.
        - Une quantité de temps durant lequel le compte est bloqué.

   Noter qu'utiliser la fonctionnalité de blocage de compte est une aide précieuse pour les attaques DOS sur les comptes utilisateurs. Cette fonctionnalité est découragée en faveur d'un délai entre les différentes tentatives. Le délai va doubler à chaque tentative, "x‹int›" pour les multiplicateurs constant, "^‹int›" pour les géométriques.

Stratégie de modification de mot de passe

   Cette section décris la stratégie appliquée quand un utilisateur modifie son mot de passe. Le focus général est de s'assurer que lorsqu'un utilisateur ajoute ou change son mot de passe, la sécurité et l'efficacité de ce mot de passe est maximisé. Dans ce document, le terme "opération de modification de mot de passe" réfère à toute opération qui est utilisée pour ajouter ou modifier un attribut de mot de passe. Souvent cela est fait en mettant à jours l'attribut du mot de passe durant une opération d'ajout ou de modification, mais peut être faite par d'autres moyens tels que les opérations étendues.

Expiration, alerte et période de grâce

   Si un mot de passe est fréquemment changé, les chances que le compte de cet utilisateur soit cassé sont minimisés. Les administrateurs de stratégie de mot de passe peuvent déployer une stratégie de mot de passe qui force les mots de passe à expirer après un temps donné, ce qui force les utilisateurs à changer leur mot de passe périodiquement.

   Il doit cependant y avoir un moyen par lequel les utilisateurs soient informés de cette nécessité de changer leur mot de passe avant d'être effectivement bloqué. Une ou les deux méthodes suivantes le gère:

        - Un message d'alerte peut être retourné à l'utilisateur quelques temps avant que son mot de passe n'expire.
        - L'utilisateur peut s'authentifier auprès de l'annuaire un certain nombre de fois après que son mot de passe ait expiré.

Historique de mot de passe

   Quand la stratégie d'expiration de mot de passe est utilisée, un mécanisme additionnel est utilisé pour empêcher les utilisateurs de ré-utiliser leur précédent mot de passe. Pour cela, un historique les mots de passe est conservé. L'administrateur peut définir le nombre de mots de passe à conserver. Les utilisateurs n'ont pas le droit d'utiliser un mot de passe présent dans cette liste.

Âge minimum de mot de passe

   Les utilisateurs peuvent outrepasser le mécanisme d'historique de mot de passe en effectuant une série de changement de mot de passe, jusqu'à ce que leur mot de passe favoris soit disponible. Pour empêcher cela, l'âge minimum d'un mot de passe peut être forcés.

Longueur minimum et qualité de mot de passe

   Pour empêcher les utilisateurs de créer ou mettre à jours les mots de passe qui sont facile à deviner, une stratégie de qualité de mot de passe peut être employée. Cette stratégie consiste de 2 mécanismes généraux - s'assurer que le mot de passe est conforme aux critères de qualité et s'assurer qu'ils ont une longueur minimale. Forcer un mot de passe à être conforme avec une stratégie peut impliquer divers choses, incluant:

        - Interdire les mots triviaux et bien connus
        - Forcer un certain nombre de chiffres à utiliser
        - Interdire les anagrammes du nom de l'utilisateur

   L'implémentation de cette stratégie rencontre les problèmes suivants:

        - Si le mot de passe à ajouter ou mettre à jours est chiffré par le client avant d'être envoyé, le serveur ne peut pas forcer cette stratégie.
        - Il n'y a pas de définition spécifique de ce que signifie une vérification de gualité. Cela peut poser problèmes dans des milieux hétérogènes.

Mots de passes définis par les utilisateurs

   Dans certains cas, il est désirable d'interdire les utilisateur d'ajouter ou modifier leur propres mots de passe. Cette stratégie rend cela possible.

Changement de mot de passe après réinitialisation

   Cette stratégie force l'utilisateur à mettre à jours son mot de passe après qu'il ait été définis pour la première fois, ou a été réinitialisé.

Modification sûre

   Vu que les annuaires sont communément utilisés, il devient fréquent que les clients se connecte à l'annuaire et laissent la connexion ouverte pour une période étendue. Cela permet à un attaquant d'effectuer des modifications sur un mot de passe utilisateur pendant que la machine de l'utilisateur est connectée. Cette stratégie force l'utilisateur à prouver son identité en spécifiant l'ancien mot de passe durant l'opération de modification de mot de passe.

Restriction de la stratégie de mot de passe

   La stratégie de mot de passe définie dans ce document peut s'appliquer à tout attribut contenant un mot de passe. Les informations d'état de stratégie de mot de passe est maintenu dans l'entrée de l'utilisateur. Un serveur doit donc s'assurer que l'attribut du mot de passe est sujet à la stratégie de mot de passe, qu'il contient une et une seule valeur de mot de passe.

ObjectClass

pwdPolicy Contient les attributs définissant une stratégie de mot de passe pour un jeu d'utilisateur.

Attributs

pwdAttribute Maintient le nom de l'attribut auquel la stratégie de mot de passe s'applique
pwdMinAge Nombre de secondes entre chaque changement de mot de passe. Si non présent, assume 0
pwdMaxAge Nombre de secondes avant qu'un mot de passe n'expire. Si vide ou 0, le mot de passe n'expire jamais.
pwdInHistory Spécifie le nombre maximum de mot de passes stoqués dans l'attribut pwdHistory
pwdCheckQuality !!! Indique comment la qualité de mot de passe est vérifié lors d'un ajout ou d'une modification. Si non présent ou 0, aucune vérification n'est faite. 1, indique que le serveur vérifie la qualité, et s'il n'est pas capable de le faire, le mot de passe est accepté. 2 vérifie la qualité, et s'il n'est pas capable de le faire, retourne une erreur.
pwdMinLengh Quand la vérification de mot de passe est actif, cet attribut maintient le nombre de caractères minimum à utiliser dans un mot de passe.
pwdMaxLengh Quand la vérification de mot de passe est actif, cet attribut maintient le nombre de caractères maximum à utiliser dans un mot de passe.
pwdExpireWarning Spécifie le nombre maximum de secondes avant qu'un mot de passe soit près d'expirer et qu'un message d'alerte soit retourné à l'utilisateur. La valeur doit être plus petite que la valeur de pwdMaxAge.
pwdGraceAuthNLimit Spécifie le nombre de fois qu'un mot de passe expiré peut être utilisé pour s'authentifier. Si non présent ou à 0, l'authentification échoue.
pwdGraceExpiry Spécifie le nombre de secondes de la validité de la période de grâce.
pwdLockout À TRUE, indique que le mot de passe ne peut plus être utilisé pour s'authentifier après le nombre de tentative spécifié dans pwdMaxFailure.
pwdLockoutDuration Maintient le nombre de secondes que le mot de passe ne peut être utilisé pour s'authentifier due à trop grand nombre d'échec. À 0,le mot de passe ne peut plus être utilisé jusqu'à un reset administratif.
pwdMaxFailure Spécifie le nombre maximum d'authentification consécutives échouées.
pwdFailureCountInterval Maintient le nombre de secondes après lesquel le compteur d'échec est purgé, même quand aucune authentification réussie ne s'est produite. Si non présent ou à 0, ne peut être ré-initialisé qu'avec une authentification réussie.
pwdMustChange À TRUE, les utilisateurs doivent changer leur mot de passe la prochaine fois qu'ils s'authentifie.
pwdAllowUserChange Indique si les utilisateurs peuvent changer leur propre mot de passe, bien que cette opération reste sujette à contrôle d'accès. Cet attribut est conçus pour être utilisé en l'absence de mécanisme de contrôle d'accès.
pwdSafeModify Spécifie si le mot de passe existant doit être envoyé avec le nouveau lors du changement de mot de passe.
pwdMinDelay Spécifie le nombre de secondes d'attente après la première tentative d'authentification échouée. Si définis, pwdMaxDelay doit l'être également.
pwdMaxDelay Délai maximum après une authentification échouée. Ce temp est spécifié en pwdMinDelay utilisé comme point de départ et est doublé à chaque tentative jusqu'à atteindre pwdMaxDelay.
pwdMaxIdle Nombre de secondes qu'un compte peut rester non-utilisé avant d'être bloqué.

   Les informations d'état de stratégie de mot de passe peuvent être maintenus pour chaque utilisateur. Ces informations sont localisées dans chaque entrée de l'utilisateur comme jeu d'attributs opérationnels. Ces attributs opérationnels sont: décris ci-dessous.

   Vu que les stratégies de mot de passe peuvent s'appliquer à de nombreux attributs utilisés pour stocker les mots de passe, chaque attribut opérationnel doit avoir une option pour spécifier à quel pwdAttribute il s'applique. L'option est définie comme suit:

  pwd-‹passwordAttribute

  où passwordAttribute est le nom court de l'attribut

  pwdChangedTime;pwd-userPassword: 20000103121520Z

Attributs Opérationnels

pwdChangedTime Spécifie la date du dernier changement de mot de passe. Utilisé par la stratégie d'expiration du mot de passe. Si non présent, le mot de passe n'expire jamais.
pwdAccountLockedTime Maintient la date à laquelle le compte utilisateur a été bloqué. Une valeur 000001010000Z signifie que le compte a été bloqué de manière permanente, et que seul un reset administratif peut débloquer le compte.
pwdFailureTime Maintient les date des derniers échec d'authentification.
pwdHistory Maintient l'historique des précédents mots de passe. Les valeurs de cet attribut sont au format (ABNF):


pwdHistory = time "#" syntaxOID "#" length "#" data
time = GeneralizedTime
syntaxOID = numericoid ; the string representation of the
        ; dotted-decimal OID that defines the
        ; syntax used to store the password.
length = number ; the number of octets in data.
data = ‹octets representing the password in the format specified by syntaxOID›.

pwdGraceUseTime Maintient les périodes de grâce après qu'un mot de passe a expiré.
pwdReset Maintient un flag pour indiquer (à TRUE) que le mot de passe a été mis à jours par un administrateur et doit être changé par l'utilisateur.
pwdPolicySubentry Pointe vers une subentry pwdPolicy effectif sur l'objet.
pwdStartTime Spécifie la date à laquelle le mot de passe devient valide pour l'authentification.
pwdEndTime Spécifie la date après laquelle le mot de passe devient invalide pour l'authentification.
pwdLastSuccess Maintient la date de la dernière authentification réussie

ObjectClass


( 1.3.6.1.4.1.42.2.27.8.2.1
    NAME 'pwdPolicy'
    SUP top
    AUXILIARY
    MUST ( pwdAttribute )
    MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
    pwdMinLength $ pwdMaxLength $ pwdExpireWarning $
    pwdGraceAuthNLimit $ pwdGraceExpiry $ pwdLockout $
    pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
    pwdMustChange $ pwdAllowUserChange $ pwdSafeModify $
    pwdMinDelay $ pwdMaxDelay $ pwdMaxIdle ) )

Attributs


( 1.3.6.1.4.1.42.2.27.8.1.1
    NAME 'pwdAttribute'
    EQUALITY objectIdentifierMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
    
( 1.3.6.1.4.1.42.2.27.8.1.2
    NAME 'pwdMinAge'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.3
    NAME 'pwdMaxAge'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.4
    NAME 'pwdInHistory'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.5
    NAME 'pwdCheckQuality'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.6
    NAME 'pwdMinLength'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.31
    NAME 'pwdMaxLength'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.7
    NAME 'pwdExpireWarning'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.8
    NAME 'pwdGraceAuthNLimit'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.30
    NAME 'pwdGraceExpire'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.9
    NAME 'pwdLockout'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.10
    NAME 'pwdLockoutDuration'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.11
    NAME 'pwdMaxFailure'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    ORDERING integerOrderingMatch
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.12
    NAME 'pwdFailureCountInterval'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    ORDERING integerOrderingMatch
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.13
    NAME 'pwdMustChange'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.14
    NAME 'pwdAllowUserChange'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.15
    NAME 'pwdSafeModify'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.24
    NAME 'pwdMinDelay'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.25
    NAME 'pwdMaxDelay'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.26
    NAME 'pwdMaxIdle'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )

Attributs opérationnels


( 1.3.6.1.4.1.42.2.27.8.1.16
    NAME 'pwdChangedTime'
    DESC 'The time the password was last changed'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.17
    NAME 'pwdAccountLockedTime'
    DESC 'The time an user account was locked'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.19
    NAME 'pwdFailureTime'
    DESC 'The timestamps of the last consecutive authentication
    failures'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.20
    NAME 'pwdHistory'
    DESC 'The history of user s passwords'
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.21
    NAME 'pwdGraceUseTime'
    DESC 'The timestamps of the grace authentication after the
    password has expired'
    EQUALITY generalizedTimeMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.22
    NAME 'pwdReset'
    DESC 'The indication that the password has been reset'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.23
    NAME 'pwdPolicySubentry'
    DESC 'The pwdPolicy subentry in effect for this object'
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.27
    NAME 'pwdStartTime'
    DESC 'The time the password becomes enabled'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.28
    NAME 'pwdEndTime'
    DESC 'The time the password becomes disabled'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.29
    NAME 'pwdLastSuccess'
    DESC 'The timestamp of the last successful authentication'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )

Contrôles utilisés pour la stratégie de mot de passe

   Cette section détaille les contrôles utilisés lors de l'application des stratégies de mot de passe. Un contrôle de request est définie et est envoyé par un client avec une opération request pour déclencher un contrôle de réponse. Cette réponse contient diverses alertes et erreurs associés avec une stratégie de mot de passe.

Request Control

   Ce contrôle peut être envoyé avec tout message de demande LDAP pour transmettre au serveur est prêt et peut traiter le contrôle de réponse décris dans ce document. Le controlType est 1.3.6.1.4.1.42.2.27.8.5.1. Il n'y a pas de controlValue.

Response Control

   Si le client a envoyé un contrôle passwordPolicyRequest, le serveur envoie ce contrôle avec les opérations de réponses suivantes: bindResponse, modifyResponse, addResponse, compareResponse et extendedResponse, pour informer des divers conditions, et peut l'envoyer avec d'autres opérations (dans le cas de l'erreur changeAfterReset). Le controlType est 1.3.6.1.4.1.42.2.27.8.5.1 et controlValue est le BER du type:


PasswordPolicyResponseValue ::= SEQUENCE {
    warning [0] CHOICE {
        timeBeforeExpiration [0] INTEGER (0 .. maxInt),
        graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
    error [1] ENUMERATED {
        passwordExpired (0),
        accountLocked (1),
        changeAfterReset (2),
        passwordModNotAllowed (3),
        mustSupplyOldPassword (4),
        insufficientPasswordQuality (5),
        passwordTooShort (6),
        passwordTooYoung (7),
        passwordInHistory (8) } OPTIONAL }

timeBeforeExpiration spécifie le nombre de secondes avant qu'un mot de passe n'expire.
graceAuthNsRemaining spécifie le nombre restant de fois qu'un utilisateur sera autorisé à s'authentifier une fois le mot de passe expiré.
passwordExpired signifie que le mot de passe a expiré et qu'il doit être changé.
passwordModNotAllowed est définis quand un utilisateur ne peut pas changer son mot de passe.
insufficientPasswordQuality est définis quand un mot de passe ne passe pas la vérification de la qualité
passwordTooYoung Définis si l'âge du mot de passe à modifier n'est pas suffisamment ancien

Stratégie de points de décision

   La suite est une série de procédure utilisées pour effectuer des décisions de stratégie. Ces procédures sont généralement effectués par le serveur durant le traitement d'une opération.

Vérification de compte bloqué

   Un statut TRUE est retourné pour indiquer que le compte est bloqué si une de ces conditions est rencontrée:

- La valeur de pwdAccountLockedTime est 000001010000Z
- L'heure courante est antérieure à pwdStartTime
- L'heure courante est postérieure à pwdEndTime
- L'heure courante est supérieur ou égal à la valeur de pwdLastSuccess ajouté à la valeur de pwdMaxIdle
- L'heure courante est inférieure à la valeur de pwdAccountLockedTime ajouté à la valeur de pwdLockoutDuration

   Sinon un statut FALSE est retourné.

Vérification de changement de mot de passe

   Un statut TRUE est retourné pour indiquer que le mot de passe doit être changé si toutes les conditions suivantes sont rencontrées:

- L'attribut pwdMustChange est à TRUE
- l'attribut pwdReset est à TRUE

Vérification d'expiration de mot de passe

   Un statut de TRUE est retourné indiquant que le mot de passe a expiré si l'heure courante moins la valeur de pwdChangedTime est supérieur à la valeur de pwdMaxAge. Sinon, un statut de FALSE est retourné.

Vérification de AuthN Grace restant

   Si l'attribut pwdGraceExpiry est présent, et que la date courante est supérieur au temps d'expiration du mot de passe plus la valeur pwdGraceExpiry, 0 est retourné. Si l'attribut pwdGraceUseTime est présent, le nombre de valeurs dans cet attribut soustrait de la valeur de pwdGraceAuthNLimit est retourné. Un résultat positif spécifie le nombre d'authentifications de grâce restant.

Vérification de date avant expiration

   Si l'attribut pwdExpireWarning n'est pas présent un statut de 0 est retourné. Sinon, soustrait le temp stocké dans pwdChangedTime de l'heure courante pour arriver à l'âge du mot de passe. Si l'âge du mot de passe est supérieur à la valeur de pwdMaxAge, un status 0 est retourné. Soustrait la valeur de pwdExpireWarning de la valeur de pwdMaxAge pour arriver à l'âge d'alerte, la valeur de pwdMaxAge moins l'âge du mot de passe est retourné.

Vérification de blocage d'intrus

   Un statut de TRUE indiquant qu'un intrus a été détecté est retourné si les conditions suivantes sont rencontrées:

- L'attribut pwdLockout est TRUE
- Le nombre de valeurs dans pwdFailureTime qui sont plus récent que pwdFailureCountInterval est supérieur ou égal à pwdMaxFailure.

   Sinon, un statut de FALSE est retourné. Tout en effectuant cette vérification, les valeurs de pwdFailureTime qui sont maintenus par plus d'un pwdFailureCountInterval sont purgés et non comptés.

Vérification de délai d'intrusion

   Si l'attribut pwdMinDelay est 0 ou non définis, 0 est retourné. Sinon, un délai est calculé basé sur le nombre de valeurs dans l'attribut pwdFailureTime. Si la valeur calculée est supérieur à pwdMaxDelay, la valeur pwdMaxDelay est retournée. Tout en effectuant cette vérification, les valeurs de pwdFailureTime qui sont maintenus par plus d'un pwdFailureCountInterval sont purgé et non comptés.

Vérification de mot de passe trop jeune

   Si la vérification de changement de mot de passe retourne TRUE, cette vérifiction retourne FALSE, pour permettre le changement de mot de passe. Un statut de TRUE indique qu'il ne s'est pas écoulé suffisamment de temps depuis le dernier changement de mot de passe. TRUE est retourné si:

- La valeur de pwdMinAge est non-zéro et pwdChangedTime est présent
- La valeur de pwdMinAge est supérieur à l'heure courante moins la valeur de pwdChangedTime.

   Sinon, un statut de FALSE est retourné.

Points de renforcements de stratégies du serveur

   Le serveur devrait forcer l'attribut du mot de passe sujet à une stratégie de mot de passe tel que définis dans ce document, contenant une et une seule valeur. Note: Dans le cas où un seul mot de passe est stocké dans plusieurs formats est considéré comme une seule valeur de mot de passe.

   Les scénarios dans les opérations suivantes assument que le client a attaché un contrôle passwordPolicyRequest à la demande. Dans le cas où passwordPolicyRequest n'a pas été envoyé, aucun contrôle passwordPolicyResponse n'est retourné. Toutes les autres instructions restent les même.

Authentification basé sur un mot de passe

   Cette section contient les règles de stratégie utilisé pour valider un mot de passe. Les opérations qui valident les mots de passe incluent, entre autre, l'opération Bind et l'opération Compare où l'attribut à comparer contient un mot de passe. Noter que l'opération Compare n'authentifie pas un utilisateur, mais peut être utilisé par une application externe pour authentification.

Echec en cas de compte bloqué

   Si le compte est bloqué, le serveur échoue l'opération avec le code 49 invalidCredentials dans le cas d'une opération Bind, le code 5 compareFalse dans le cas d'une opération Compare, etc. Le serveur peut définir cette erreur: accountLocked (1) dans le passwordPolicyResponse dans le champ contrôle du message.

Procédures de mot de passe validé

   Si l'opération de validation indique que le mot de passe est validé, cet procédures sont suivie dans l'ordre:

- Supprime les attributs pwdFailureTime et pwdAccountLockedTime.
- Définis la valeur de pwdLastSuccess à l'heure courante

Mot de passe à changer

   Si le mot de passe doit être changé, le serveur envoie au client une réponse avec un resultCode success (0), compareTrue (6), etc. Et inclus le passwordPolicyResponse dans le champ controls du message bindResponse avec l'alerte: changeAfterReset spécifié. Pour un bind, le serveur doit interdir toutes les autres opérations fournies par cet utilisateur excepté la modification du mot de passe, bind, unbind, abandon et StartTLS.

Mot de passe expiré

   Si le mot de passe a expiré, le serveur retourne soit un succès ou un échec en fonction de l'état des authentification de grâce.

Authentification de grâce restant

   S'il reste les authentification de grâce, le serveur ajoute une nouvelle valeur avec l'heure courante dans pwdGraceUseTime. Puis il envoie au client une réponse avec un succès, et inclus le passwordPolicyResponse dans la réponse avec l'alerte graceAuthNsRemaining définis au nombre d'authentification restante.

Plus d'authentification de grâce restante

   S'il ne reste plus d'authentification de grâce, le serveur échoue l'opération, et inclus le passwordPolicyResponse dans controls avec l'erreur passwordExpired.

Alerte d'expiration

   Si la vérification d'expiration de mot de passe réussie, le serveur envoie au client une réponse avec un resultCode approprié, et inclus le message timeBeforeExpiration.

Procédures d'échec AuthN

   Si le processus d'authentification indique que le mot de passe échoue la validation du à des accréditifs invalides, ces procédures sont suivies:

Mise à jour d'état de stratégie Ajoute l'heure courant comme valeur de pwdFailureTime.
Détection d'intrusion Si la vérification d'intrus retourne TRUE, le serveur bloque le compte en définissant la valeur de pwdAccountLockedTime à l'heure courante. Une fois le compte bloqué, le serveur échoue l'opération avec l'erreur accountLocked.

Opérations de mise à jour du mot de passe

   Parce que le mot de passe est stocké dans un attribut, divers opérations peuvent être utilisées pour créer ou modifier un mot de passe. Mais certains mécanismes ont été définis ou peuvent être définis tel que la rfc3062 ( LDAP Password Modify). Tout en traitant une mise à jour d'un mot de passe, le serveur effectur les étapes suivantes:

Modification sûre Si pwdSafeModify est à TRUE et qu'il existe un mot de passe, le serveur s'assure que l'opération de mise à jour inclus le mot de passe existant de l'utilisateur. Si le mot de passe n'est pas fournis, le serveur échoue avec l'erreur mustSupplyOldPassword.
Changement après reset Si la vérification de changement de mot de passe à changer retourne true, le serveur s'assure que l'opération de mise à jours ne contient rien d'autre que la modification du mot de passe. Si d'autres modification existent, le serveur envoie un message avec le resultCode insufficientAccessRights avec l'erreur changeAfterReset.
Vérification des droits Vérifie si l'identité a les droits suffisants pour mettre à jours le mot de passe. Si l'utilisateur n'a pas les droits suffisants, le serveur retourne un resultCode insufficientAccessRights avec l'erreur passwordModNotAllowed.
Trop tôt pour la mise à jour Si la vérification d'âge minimum du mot de passe retourne true, le serveur envoie un resultCode constraintViolation avec l'erreur passwordTooYoung.
Qualité du mot de passe Vérifier la valeur de l'attribut pwdCheckQuality. Si la valeur est non zéro, le serveur:

        - S'assure que le mot de passe respecte les critères de qualité définis par le serveur. Si le serveur ne peut pas vérifier la qualité du mot de passe, la valeur de pwdCheckQuality est évalué. Si le serveur peut vérifier la qualité du mot de passe et que la vérification échoue, le serveur envoie un constraintViolation avec l'erreur insufficientPasswordQuality.
        - Vérifie la valeur de pwdMinLengh. Si la valeur est non zéro, il s'assure que le nouveau mot de passe a au moins cette longueur minimum. Si le serveur n'est pas capable de vérifier la longueur, la valeur de pwdCheckQuality est évaluée. Si le serveur peut vérifier la longueur, et qu'il échoue, retourne un constraintViolation avec l'erreur passwordTooShort.

Réutilisation invalide Si pwdInHistory est présent et sa valeur est non-zéro, le serveur vérifie si le mot de passe existe dans pwdHistory ou dans l'attribut du mot de passe. S'il est trouvé, le serveur envoie un constraintViolation avec une erreur passwordInHistory.
Mise à jours d'état de stratégie Si les étapes ont été complétés sans erreur, le serveur effectue les étapes suivantes sur l'entrée à l'heure courante:

        - Si la valeur de pwdMaxAge ou pwdMinAge est non zéro, le serveur ajoute le précédent mot de passe (s'il en existait un) à l'attribut pwdHistory. Si le nombre de valeurs dans pwdHistory excède la valeur de pwdInHistory, le serveur supprime le mot de passe le plus ancien.
        - Si la valeur dans pwdMustChange est TRUE et que la modification est effectuée par un administateur, l'attribut pwdReset est mis à TRUE. Sinon, pwdReset est supprimé de l'entrée.
        - Les attributs pwdFailureTime et pwdGraceUseTime sont supprimés de l'entrée de l'utilisateur s'ils existent.

Autres opérations

   Pour les opérations autre que bind, password update, unbind, abandon ou StartTLS, si la vérification de mot de passe à changer retourne true, le serveur envoie un insufficientAccessRights avec l'erreur changeAfterReset.

Client Policy Enforcement Points

   Ces sections illustrent les scénarios possibles pour chaque opération LDAP et définis les types de réponses qui identifient cet scénarios. Les scénarios dans les opérations suivantes assument que le client a attaché un contrôle passwordPolicyRequest au message de demande de l'opération, et peut recevoir un contrôle passwordPolicyResponse dans le message de réponse. Dans le cas où le contrôle passwordPolicyRequest n'a pas été envoyé, aucun contrôle passwordPolicyResponse n'est retourné. Toutes les autres instructions restent les même.

bind

   Pour chaque réponse bind reçus, le client vérifie le resultCode de bindResponse et recherche un contrôle passwordPolicyResponse pour déterminer si une des conditions est vrai et peut demander à l'utilisateur:

bindResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = accountLocked (1)
La limite d'échec a été atteinte et le compte est bloqué. L'utilisateur doit retenter plus tard ou contacter un administrateur.
bindResponse.resultCode = success (0), passwordPolicyResponse.error = changeAfterReset (2):
L'utilisateur s'authentifie pour la première fois depuis que l'administateur a définis le mot de passe et l'utilisateur doit changer son mot de passe.
bindResponse.resultCode = success (0), passwordPolicyResponse.warning = graceAuthNsRemaining:
Le mot de passe a expiré mais il reste des authentification de grâce. L'utilisateur doit le changer.
bindResponse.resultCode = invalidCredentials (49), passwordPolicyResponse.error = passwordExpired (0):
Le mot de passe a expiré et il n'y a plus d'authentification de grâce. L'utilisateur doit contacter un administrateur pour réinitialiser son mot de passe.
bindResponse.resultCode = success (0), passwordPolicyResponse.warning = timeBeforeExpiration:
Le mot de passe de l'utilisateur va expirer dans n secondes

modify

   Si l'application ou le client chiffre le mot de passe avant de l'envoyer dans une opération de modification ( soit dans une opération modifyRequest ou un autre mécanisme de modification de mot de passe ), il devrait vérifier les valeur de pwdMinLengh, pwdCheckQuality et devrait imposer ces stratégies.

   Si l'opération medifyRequest a été utilisée pour changer le mot de passe, ou si un autre mécanisme est utilisé - tel que extendedRequest - la réponse peut contenir des informations pertinente pour la stratégie de mot de passe. Le client vérifie le resultCode de la réponse et vérifie que les conditions suivantes sont vraie et optionnellement notifie l'utilisateur des conditions.

pwdModResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = mustSupplyOldPassword (4):
L'utilisateur a tenté de changer son mot de passe sans spécifier l'ancien mot de passe et c'est requis par la stratégie.
pwdModResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = changeAfterReset (2):
L'utilisateur doit changer son mot de passe avant d'envoyer une autre demande LDAP
pwdModResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = passwordModNotAllowed (3):
L'utilisateur n'a pas les droit suffisants pour changer son mot de passe
pwdModResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = passwordTooYoung (7):
Il est trop tôt pour changer le mot de passe
pwdModResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = insufficientPasswordQuality (5):
La vérification de la qualité du mot de passe a échoué
pwdModResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = passwordTooShort (6):
La longueur du mot de passe est trop courte
pwdModResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = passwordInHistory (8):
Le mot de passe a déjà été utilisé, l'utilisateur doit en choisir un différent

add

   Si un mot de passe est spécifié dans un addRequest, le client vérifie le resultCode de addResponse et vérifie le contrôle passwordPolicyResponse pour déterminer si une des conditions est vrai et pour notifier l'utilisateur en conséquence:

addResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = passwordModNotAllowed (3):
L'utilisateur n'a pas les droits suffisants pour ajouter son mot de passe
addResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = insufficientPasswordQuality (5):
Le mot de passe a échoué la vérification de la qualité
addResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = passwordTooShort (6):
La longueur du mot de passe est trop courte

compare

   Quand une opération compare est utilisée pour comparer un mot de passe, le client vérifie le resultCode de compareResponse et vérifie le passwordPolicyResponse pour déterminer si une des conditions suivantes est vrai et peut notifier l'utilisation en conséquence. Ces conditions assument que le résultat de la comparaison était vrai:

compareResponse.resultCode = compareFalse (5), passwordPolicyResponse.error = accountLocked (1):
La limite du nombre d'échec a été atteinte et le compte a été bloqué. L'utilisateur doit retenter plus tard ou contacter un administrateur.
compareResponse.resultCode = compareTrue (6), passwordPolicyResponse.warning = graceAuthNsRemaining:
Le mot de passe a expiré mais il reste des authentifications de grâce. L'utilisateur doit le changer
compareResponse.resultCode = compareFalse (5), passwordPolicyResponse.error = passwordExpired (0):
Le mot de passe a expiré et il ne reste plus d'authentification de grâce. L'utilisateur doit contacter un administrateur
compareResponse.resultCode = compareTrue (6), passwordPolicyResponse.warning = timeBeforeExpiration:
Le mot de passe de l'utilisateur va expirer dans n secondes

Autres opérations

   Pour les opérations autres que bind, unbind, abandon ou StartTLS, le client vérifie le resultCode et de contrôle pour déterminer si l'utilisateur doit changer le mot de passe immédiatement.

‹Response›.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = changeAfterReset (2):
L'utilisateur doit changer son mot de passe immédiatement

Administation des stratégies de mot de passe

   Une stratégie de mot de passe est définie pour une sous-arborescence du DIT en ajoutant une subentry dont le supérieur immédiat est la racine de la sous-arborescence, l'objectclass auxiliaire pwdPolicy. Le scope de la stratégie est définie par l'attribut SubtreeSpecification.

   Il est possible de définir des stratégies de mot de passe pour différents attributs de mot de passe dans la même entrée pwdPolicy, en spécifiant plusieurs valeurs de pwdAttribute. Les stratégies de mot de passe peuvent également être dans les subentry séparés.

   Seul une stratégie ne peut être effectif pour un attribut de mot de passe dans une entrée. Si plusieurs stratégies existent, qui se chevauchent dans un scope, le résultat est indéfinis.

   Il devrait être possible d'écraser une stratégie de mot de passe pour un utilisateur en définissant une nouvelle stratégie dans une subentry de l'entrée de l'utilisateur.

   Chaque objet qui est contrôlé par une stratégie de mot de passe annonce le subentry à utiliser pour contrôler sa stratégie dans son attribut pwdPolicySubentry. Les clients qui souhaitent examiner ou gérer une stratégie de mot de passe peuvent interroger le pwdPolicySubentry pour cet objet pour connaître le subentry pwdPolicy.

Stratégie de mot de passe et la réplication

   l'objet pwdPolicy définis la stratégie de mot de passe pour une portion du DIT et doit être répliqué dans tous les répliquas de cette sous-arborescence. Les éléments de la stratégie de mot de passe qui sont liés aux utilisateurs sont stockés dans les entrées elles-même en tant qu'attributs opérationnels. Vu que ces attributs sont sujets à modification même sur un répliqua lecture seule, leur réplication doit être considéré avec attention.

   l'attribut pwdChangedTime doit être répliqué sur tous les répliquas, pour permettre l'expiration du mot de passe. L'attribut pwdReset doit être répliqué sur tous les répliquas, pour refuser l'accès aux opérations autre que bind et modify. L'attribut pwdHistory doit être répliqué auprès des répliquas en écriture. Il n'a pas à être répliqué sur un répliqua lecture seul vu que le mot de passe ne sera jamais modifié sur ce serveur.

   Les attribut pwdAccountLockedTime, pwdFailureTime et pwdGraceUseTime devraient être répliqués sur les répliquas en écriture, rendant la stratégie de mot de passe global à tous les serveurs. Quand l'entrée utilisateur est répliquée sur un répliqua lecture-seul, ces attributs ne devraient pas être répliqués. Celà signifie que le nombre d'échec, d'authentification de grâce et de blocage sont dans chaque serveur répliqué. Par exemple, le nombre effectif de tentatives échoués sur un mot de passe utilisateur sera N x M ( où N est le nombre de serveurs et M la valeur de pwdMaxFailure ). Répliquer ces attributs à un répliqua lecture seule peut réduire le nombre de tentatives global mais peut aussi introduire certaines inconsistances dans la manière dans la stratégie est appliquée.

   Note: Il y a certaines situations où la réplication globale de ces attributs d'état peuvent être non-désirable. Par exemple, si 2 clusters de répliquas sont distants géographiquement et joins par un lien lent, et leur utilisateurs se loggent seulement sur un des 2 emplacement, il peut être préférable de ne pas propager tous les changements d'état entre les clusters. Les serveurs devraient permettre aux administrateurs de contrôler quels attributs sont répliqués au cas-par-cas.

   Les serveurs participant à une réplication multi-master devaient employer un mécanisme qui s'assure de l'unicité des valeurs en populant les attributs pwdFailureTime et pwdGraceUseTime. Pour faire ça, c'est un problème locat et peut consister en l'utilisation d'un simple source autoritative pour la génération de valeurs de temps unique, ou peut consister de l'utilisation de la partie fractionnelle des secondes pour maintenir un identifiant de répliqua.

Considérations de sécurité

   Ce document définis un jeu de règles à implémenter dans un serveur LDAP. Pour mitiger certains risques de sécurité associés avec l'utilisation de mots de passe et augmenter la difficulté de crackage de mot de passe.

- L'authentification avec un mot de passe doit suivre les recommandations de la rfc4513
- Les modifications de mot de passe devraient être se produire seulement quand la connexion est protégées pour la confidentialité et une authentification sécurisée.
- Les contrôles d'accès devraient être utilisés pour restreindre l'accès aux attribut de stratégie de mot de passe. Les attributs définis pour maintenir les information de stratégie de mot de passe devaient seulement être modifiable pas l'administrateur de mot de passe ou par une haute autorité.
- Vu qu'il est possible de définir une stratégie de mot de passe pour un utilisateur spécifique en ajoutant un subentry immédiatement sous l'entrée de l'utilisateur, les contrôles d'accès devraient être utilisés pour restreindre l'utilisation de l'objet pwdPolicy ou du subentry.
- Quand une stratégie de mot de passe à détection d'intrus est appliquée, l'annuaire LDAP est sujet aux attaques DOS. Un utilisateur malicieux peut délibérément bloquer le compte d'un utilisateur ( ou tous ) en envoyant des bind avec de faux mots de passe. Il n'y a aucun mécanisme pour parer ces attaques. Le serveur LDAP devraie logger autant d'informations qu'il peut ( tel que les adresses IP ) quand un compte est bloqué, pour être capable d'identifier l'origine de l'attaque. Refuser les accès anonymes à l'annuaire permet de réduire ce genre d'attaque. Utiliser un délai d'authentification à la place aide à éviter ces attaques DOS.
- En retournant certains codes de status ( tel que passwordPolicyResponse.error=accountLocked) permet à un attaquant DOS de savoir qu'il a réussit à bloquer le compte. Les serveurs devraient implémenter des vérifications additionnelles qui retournent le même statut quand il est détecté qu'un certain nombre de demandes d'authentification échoué s'est produit sur une simple connexion, ou depuis une adresse client.
^
10 juin 2014

htmlpdflatexmanmd




draft-chu-ldap-kdc-schema-00

draft-chu-ldap-kdc-schema-00

LDAP KDC Schema

Introduction

  

Motivations

   Kerberos et LDAP sont fréquemment utilisés séparément pour une authentification distribuée. Ils peuvent également être utilisé conjointement, mais leur base de données restent généralement séparées. Ces bases séparées implique une duplication de données et sont source de charge d'administation supplémentaire. Il est donc préférable de partager la même base de données. Un certain nombre d'implémentations Kerberos supportent déjà l'utilisation de LDAP comme stockage du KDC. Cependant, chaque implémentation utilise son propre schéma.

Terminologie

Les OID définis ci-dessous sont dérivés de TBD.OID:
KRBSYN = TBD.OID.0
KRBATTR = TBD.OID.1
KRBOC = TBD.OID.2

Attributs

   Les attributs et classes définies dans ce document sont (additionnellement, certains attributs définis dans LDAP Password Policy sont requis):

krbPrincipalName Nom canonique du principal
krbPrincipalAliases Alias du nom du principal. Vu que cet attribut est un sous-type de krbPrincipalName, une recherche sur krbPrincipalName va également rechercher les alias.
krbTicketMaxLife Maintient le maximum ticket lifetime, en secondes pour un principal.
krbTicketMaxRenewal Maintient la durée maximal de renouvellement d'un ticket
krbEncSaltTypes Maintient les combinaisons chiffrement/salt permis pour ce principal
krbRealmName Nom du domaine Kerberos
krbPrincipalRealm DN de l'entrée krbRealm
krbKeySet Maintient les clés du principal, optionnellement chiffrés avec la clé maître. l'attribut est encodé en utilisant ASN.1


        Le format de la valeur pour cet attribut est:
KrbKeySet ::= SEQUENCE {
    kvno [0] UInt32,
    mkvno [1] UInt32 OPTIONAL,
    keys [2] SEQUENCE OF KrbKey,
    ...
}
    
KrbKey ::= SEQUENCE {
    salt [0] KrbSalt OPTIONAL,
    key [1] EncryptionKey,
    s2kparams [2] OCTET STRING OPTIONAL,
    ...
}
    
KrbSalt ::= SEQUENCE {
    type [0] Int32,
    salt [1] OCTET STRING OPTIONAL
}
    
EncryptionKey ::= SEQUENCE {
    keytype [0] Int32,
    keyvalue [1] OCTET STRING
}

krbKeyVersion Stocke le numéro de version de la clé courante
krbTicketPolicy Définis les flags qu'un utilisateur peut utiliser ou demander à utiliser dans une demande de ticket


       
krb5KDCFlagsSyntax SYNTAX ::= {
    WITH SYNTAX INTEGER
        initial(0), -- require as-req
        forwardable(1),-- may issue forwardable
        proxiable(2), -- may issue proxiable
        renewable(3), -- may issue renewable
        postdate(4), -- may issue postdatable
        server(5), -- may be server
        client(6), -- may be client
        invalid(7), -- entry is invalid
        require-preauth(8), -- must use preauth
        change-pw(9), -- change password service
        require-hwauth(10), -- must use hwauth
        ok-as-delegate(11), -- as in TicketFlags
        user-to-user(12), -- may use user-to-user auth
        immutable(13) -- may not be deleted
    ID { 1.3.6.1.4.1.5322.10.0.1 }
}

krbExtraData Maintient des données arbitraires qui peuvent être utilisés par certaines implémentations. la valeur est encodée en DER ASN.1


       
ExtraData ::= SEQUENCE {
    tag [0] OCTET STRING,
    data [1] OCTET STRING
}

krbPrincNamingAttr Enregistre que attributs sont utilisés pour nommer les nouvelles créations de principal
krbPrincContainer Pointe vers un conteneur sous lequel les nouvelles entrées de principaux sont créés.
krbPwdPolicy Point vers une subentry de stratégie de mot de passe contenant la stratégie qui sera appliquée aux principaux Kerberos. Noter que pour les serveur avec le support complet des subentry, cet subentry définissent à quelles entrée elles s'applique. Donc cet attribut n'est pas nécessaire.
krbLDAPURI URI ldap que le KDC utilise pour localiser les principaux.

Classes d'objets

krbKDCInfo
krbPrincipal
krbRealm

Définition des attributs


( KRBATTR.1 NAME 'krbPrincipalName' DESC 'Canonical principal name' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
( KRBATTR.2 NAME 'krbPrincipalAliases' SUP krbPrincipalName )
( KRBATTR.3 NAME 'krbTicketMaxLife' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( KRBATTR.4 NAME 'krbTicketMaxRenewal' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( KRBATTR.5 NAME 'krbEncSaltTypes' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( KRBATTR.6 NAME 'krbRealmName' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
( KRBATTR.7 NAME 'krbPrincipalRealm' DESC 'DN of krbRealm entry' SUP distinguishedName )
( KRBATTR.8 NAME 'krbKeyVersion' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( KRBATTR.9 NAME 'krbKeySet' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
( KRBATTR.10 NAME 'krbTicketPolicy' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( KRBATTR.11 NAME 'krbExtraData' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
( KRBATTR.12 NAME 'krbPrincNamingAttr' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE )
( KRBATTR.13 NAME 'krbPrincContainer' DESC 'DN of container entry for principals' SUP distinguishedName SINGLE-VALUE )
( KRBATTR.14 NAME 'krbPwdPolicy' DESC 'DN of password policy subentry' SUP distinguishedName SINGLE-VALUE )
( KRBATTR.15 NAME 'krbLDAPURI' DESC 'LDAP search parameters for locating principals' SUP labeledURI )

Définitions des classes d'objet

( KRBOC.1 NAME 'krbKDCInfo' SUP top AUXILIARY MAY ( krbTicketMaxLife $ krbTicketMaxRenewal $ krbEncSaltTypes $ krbTicketPolicy $ krbKeySet $ krbKeyVersion ) )
( KRBOC.2 NAME 'krbPrincipal' SUP krbKDCInfo AUXILIARY MUST ( krbPrincipalName ) MAY ( krbPrincipalAliases $ krbPrincipalRealm $ krbExtraData ) )
( KRBOC.3 NAME 'krbRealm' SUP krbKDCInfo AUXILIARY MUST ( krbRealmName ) MAY ( krbPrincNamingAttr $ krbPrincContainer $ krbPwdPolicy $ krbLDAPURI ) )

Détails de l'implémentation

   Vu que le LDAP Password Policy est intimement lié à la sécurité de ce draft, l'annuaire devrait être traité en conséquence Cela signifie que pour toute authentification Kerberos déservis, une opération LDAP correspondante est également effectuée, pour permettre au mécanisme de stratégie de mot de passe d'opérer.

   Le mécanisme dessiné ici assume que les accréditifs LDAP et les accréditifs Kerberos sont unifiés (ou au moins synchronisés). Dans ce cas, pour toute requête d'authentification Kerberos entrante, le KDC peut fournir une requête ldap compare en utilisant les accréditifs connus de l'utilisateur et le contrôle ldap Password Policy. Le résultat de la requête va s'occuper de tout code d'erreur si le compte est désactivé, le mot de passe a expiré, ou divers autres échecs. Si la pré-authentification est utilisée et que la requête est invalide, un compare avec des accréditifs invalides connus peuvent être utilisés pour mettre à jours l'état de la stratégie de mot de passe.

Détails du modèle

   Un nombre d'éléments de données décris dans le modèle d'information sont délégués pour LDAP DSA pour la gestion. Les détails de leurs utilisation sont décrites ici.

principalNotUsedBefore

   Correspond à l'attribut pwdStartTime. Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement.

principalNotUsedAfter

   Correspond à l'attribut pwdEndTime. Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement.

principalIsDisabled

   Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement. Sinon cet effet est contrôlé par le paramètrage de pwdStartTime à une valeur supérieur ou égale à pwdEndTime

principalNumberOfFailedAuthenticationAttempts

   Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement. Sinon, cette valeur est obtenue en comptant le nombre de valeurs stockées dans pwdFailureTime

principalLastFailedAuthentication

   Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement. Sinon, cette valeur est obtenue en récupérant les valeur stockées dans pwdFailureTime et en sélectionnant la valeur la plus récente.

principalLastSuccessfulAuthentication

   Correspond à l'attribut pwdLastSuccess. Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement.

principalLastCredentialChangeTime

   Correspond à l'attribut pwdChangedTime Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement.

principalCreateTime

   Correspond à l'attribut createTimestamp. Le KDC n'a pas besoin de référencer ou manipuler cet attribut directement.

principalModifyTime

   Correspond à l'attribut modifyTimestamp. Le KDC n'a pas besoin de référencer ou manipuler cet attribut directement.

Détail de KeySet

   L'attribut krbKeySet est multi-valué mais il est attendu qu'il ait une seule valeur. Durant une opération de changement de mot de passe le KDC peut choisir de conserver une valeur précédente pour permettre aux clients actifs de continuer à opérer en utilisant la clé précédente. La durée de rétention de cet ancien mot de passe n'est pas spécifié ici. Noter également que le mécanisme ldap Password Policy a déja une gestion d'historique de mot de passe, donc krbKeySet ne devrait pas être utilisé pour l'historique des mots de passe.

Considérations de sécurité

   Tout ce document est conserné par l'implémentation d'un mécanisme d'authentification distribué sécurisé. Il faut bien comprendre que les divers clé utilisée ici sont des données sensible et doivent être protégés en conséquence en utilisant les ACL et autres mécanismes. Également, toutes les communications entre le KDC et le DSA doivent être protégés quand des données sensible sont référencées.

   En pratique, le KDC et le DSA sont hébergés sur un serveur hôte et communiquent via ldapi. Celà implique que l'hôte soit également sécurisé, et un canal sécurisé doit être utilisé pour la session LDAP.
^
09 juin 2014

htmlpdflatexmanmd




draft-chu-ldap-ldapi-00

draft-chu-ldap-ldapi-00

LDAP over IPC

Introduction

   Bien que LDAP soit un protocole d'accès distribué, il est courant que des clients soient déployés sur la même machine que le serveur. De nombreuses applications embarquent un client et un serveur. Dans ces déploiements intégrés, où il n'y a pas de trafic réseau, l'utilisation de TCP/IP est inutile. Les systèmes type UNIX offrent des mécanismes IPC natives qui fournissent des sémantiques orienté flux d'une session TCP, mais avec une plus grande efficacité.

   Depuis Janvier 2000, OpenLDAP fournis la possibilité d'établir des sessions LDAP au travers de sockets Unix aussi bien qu'au travers de TCP/IP. De telles sessions sont aussi sécurisée que les sessions TCP sur la boucle local,, mais elles consomment moins de ressources, sont plus rapide à établir, et fournissent une identification sécurisé du client sans nécessiter de mot de passe additionnel ou autres accréditations.

Motivations

   De nombreuses sessions LDAP consistent seulement en une ou 2 requêtes. L'initialisation et la fermeture des connections deviennent une portion significative du temps nécessaire à traiter ces sessions. Également lors de fortes charges, la contrainte de la limite 2MSL dans TCP devient problématique. Par exemple, un processeur moderne AMD64 dual-core qui fait tourner OpenLDAP peut manipuler 32000 authentification par secondes sur un réseau 100Mbps, avec une connection par requête. Connecté via une interface loopback, le taux est plus élevé, mais les connections sont complètement étranglées en moins d'une seconde à cause de tous les numéros de port utilisés et maintenus à l'état TIME_WAIT. Donc même quand le traitement de la charge TCP est insignifiante, la contrainte imposée par la RFC793 crée une limite artificielle. De telles contraintes n'existent pas avec IPC.

Spécification visible à l'utilisateur

   Le seul changement nécessaire des clients pour implémenter cette fonctionnalité est d'utiliser une URL spéciale au lieu de ldap:// pour spécifier le serveur cible. Également, le serveur a besoin d'inclure cette URL dans le liste des adresses d'écoute.

Schéma d'URL

   Le schéma d'URL ldapi: est utilisé pour dénoter une session LDAP sur IPC. La portion d'adresse de l'URL est le nom d'un socket unix, qui est géneralement un chemin complet Unix. les "/" dans le chemin doivent être encodés comme décrit dans la rfc3986. exemple: pour un socket nommé: /var/run/ldapi, l'url du serveur sera ldapi://%26var%26run%26ldapi/. Tous les autres aspects de l'URL sont conformes à la rfc4516.

   Si aucune adresse n'est spécifiée, une adresse par défaut peut être utilisée implicitement. Dans OpenLDAP, l'adresse par défaut est une constante spécifiée à la compilation.

Détails de l'implémentation

   Le transport basique utilise un socket unix orienté flux. Les sémantiques de communication dans un tel socket sont essentiellement identiques à utiliser une session TCP. À part l'établissement de la connexion, aucune considération spéciale n'est nécessaire dans le client, les librairies, ou le serveur.

Authentification Client

   Depuis leurs introduction dans BSD 4.2, les sockets Unix permettent également de passer des accréditifs d'un processus à un autre. Les systèmes moderne peuvent fournir un serveur avec un moyen plus simple.pour obtenir l'identité du client. L'implémentation d'OpenLDAP exploite plusieurs méthodes pour acquérir l'identité du client. La discussion qui suit est nécessairement spécifique à la plateforme.

- La librairie OpenLDAP fournis getpeereid() pour encapsuler tous les mécanismes utilisé pour acquérir l'identité.
- Sur FreeBSD et MacOsX, getpeereid() natif est utilisé
- Sur les systèmes Solaris modernes, getpeerucred() est utilisé
- Sur les systèmes Linux qui supportent l'option SO_PEERCRED de getsockopt() est utilisé
- Sur les systèmes qui n'ont pas ces méthodes, le passeur de descripteur est utilisé. Dans ce cas, le client doit envoyer un message contenant le descripteur comme toute première action immédiatement après la connction du socket. Le descripteur est attaché à une requête LDAP Abandon avec le message ID 0, sont le paramètre a également le message ID à 0. Cette requête est un pure no-op, et sera simplement ignoré par tout serveur n'implémentant pas ce protocole.

   Pour des raisons de sécurité, le descripteur passé doit être contrôlé. Le client crée un pipe et envoie le descripteur de pipe dans le message. Le serveur reçois de descripteur et fait un fstat() dessus pour déterminer l'identité du client. Le descripteur reçu doit être un pipe, et ses permissions doivent permettre l'accès à son propriétaire. L'uid et gid sont ainsi utilisé comme identité du client.

   Noter que ces mécanismes sont simplement utilisés pour que l'identité du client sont disponible au serveur. Le serveur n'utilise pas les informations d'identité sauf si le client fait un Bind SASL en utilisant le mécanisme EXTERNAL.

Autres Plateformes

   Il est possible d'implémenter une fonctionnalité correspondante sur les systèmes basés sur Microsoft Windows en utilisant les pipes nommés, mais il n'y a pas de demande pour celà, et l'implémentation n'a pas été écrite. Le pipe devrait être créé en mode byte-read, et le client doit spécifier l'accès SECURITY_IMPERSONATION quand il ouvre le pipe. Le serveur peut ainsi retrouver l'identité du client en utilisant la fonction GetNamePipeHandleState(). Vu que les sockets Windows ne sont pas interchangeable avec IPC, un event handler alternatif devra être fournis au lieu d'utiliser select().
^
19 mai 2014

htmlpdflatexmanmd




draft-chu-ldap-logschema-00

draft-chu-ldap-logschema-00

Schéma de log du protocol LDAP

   Pour faciliter l'administration distante et l'audit des opérations serveurs LDAP, il est désirable de fournir les logs opérationnels du serveur eux-même comme annuaire LDAP. Ces logs peuvent être également utilisés comme log de changements persistants pour supporter divers mécanismes de réplication. Ce document définis un schéma qui peut être utilisé pour représenter toutes les requêtes qui sont traitées par un serveur LDAP.

Control Syntax

   Une valeur de Control syntax représente un contrôle LDAP tel qu'utilisé par un client ou un serveur. Il consiste de l'OID numérique du contrôle, le flag de criticité, et d'un OctetString optionnel contenant la valeur du contrôle.

La notation ASN.1 est:
Control ::= SEQUENCE {
    controlType LDAPOID,
    criticality BOOLEAN DEFAULT FALSE,
    controlValue OCTET STRING OPTIONAL }

La description de syntaxe ldap est:
( LOG_SCHEMA_SYN.1 DESC 'Control' )

Types d'attributs Généraux

These attributes are common to all of the LDAP request records
( LOG_SCHEMA_AT.1 NAME 'reqDN'
DESC 'Target DN of request'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .2 NAME 'reqStart'
DESC 'Start time of request'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .3 NAME 'reqEnd'
DESC 'End time of request'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .4 NAME 'reqType'
DESC 'Type of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .5 NAME 'reqSession'
DESC 'Session ID of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .6 NAME 'reqAuthzID'
DESC 'Authorization ID of requestor'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .7 NAME 'reqResult'
DESC 'Result code of request'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .8 NAME 'reqMessage'
DESC 'Error text of request'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .9 NAME 'reqReferral'
DESC 'Referrals returned for request'
SUP labeledURI )
    
( LOG_SCHEMA_AT .10 NAME 'reqControls'
DESC 'Request controls'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX LOG_SCHEMA_SYN.1 X-ORDERED 'VALUES' )
    
( LOG_SCHEMA_AT .11 NAME 'reqRespControls'
DESC 'Response controls of request'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX LOG_SCHEMA_SYN.1 X-ORDERED 'VALUES' )

Types d'attributs spécifiques aux requêtes

Ces attributs sont spécifiques à un simple type de requêtes ldap:
( LOG_SCHEMA_AT .12 NAME 'reqId'
DESC 'ID of Request to Abandon'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .13 NAME 'reqVersion'
DESC 'Protocol version of Bind request'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .14 NAME 'reqMethod'
DESC 'Bind method of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .15 NAME 'reqAssertion'
DESC 'Compare Assertion of request'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .16 NAME 'reqMod'
DESC 'Modifications of request'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
EQUALITY octetStringMatch
SUBSTR octetStringSubstringsMatch )
    
( LOG_SCHEMA_AT .17 NAME 'reqOld'
DESC 'Old values of entry before request completed'
EQUALITY octetStringMatch
SUBSTR octetStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
( LOG_SCHEMA_AT .18 NAME 'reqNewRDN'
DESC 'New RDN of request'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .19 NAME 'reqDeleteOldRDN'
DESC 'Delete old RDN'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .20 NAME 'reqNewSuperior'
DESC 'New superior DN of request'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .21 NAME 'reqScope'
DESC 'Scope of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .22 NAME 'reqDerefAliases'
DESC 'Disposition of Aliases in request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .23 NAME 'reqAttrsOnly'
DESC 'Attributes and values of request'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .24 NAME 'reqFilter'
DESC 'Filter of request'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .25 NAME 'reqAttr'
DESC 'Attributes of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
( LOG_SCHEMA_AT .26 NAME 'reqSizeLimit'
DESC 'Size limit of request'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .27 NAME 'reqTimeLimit'
DESC 'Time limit of request'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .28 NAME 'reqEntries'
DESC 'Number of entries returned'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .29 NAME 'reqData'
DESC 'Data of extended request'
EQUALITY octetStringMatch
SUBSTR octetStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
SINGLE-VALUE )

Classes d'objets d'audit de base

Cette classe contient les attributs communs à toutes les requêtes ldap. Les autres classe héritent toutes de cette classe:
( LOG_SCHEMA_OC .1 NAME 'auditObject' DESC 'OpenLDAP request
auditing' SUP top STRUCTURAL MUST ( reqStart $ reqType $ reqSession )
MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls $ reqEnd $
reqResult $ reqMessage $ reqReferral ) )

Ces classes d'objet sont utilisées pour agréger les opérations de lecture et d'écriture sous des classes parent communs:
( LOG_SCHEMA_OC .2 NAME 'auditReadObject' DESC 'OpenLDAP read request
record' SUP auditObject STRUCTURAL MUST reqDN )
    
( LOG_SCHEMA_OC .3 NAME 'auditWriteObject' DESC 'OpenLDAP write
request record' SUP auditObject STRUCTURAL MUST reqDN )

Classes d'objets spécifiques aux requêtes

Chaque requête ldap a sa propre classe d'objet contenant tous les attributs nécessaire pour représenter une instance de cette requête:
( LOG_SCHEMA_OC .4 NAME 'auditAbandon' DESC 'Abandon operation' SUP
auditObject STRUCTURAL MUST reqId )
    
( LOG_SCHEMA_OC .5 NAME 'auditAdd' DESC 'Add operation' SUP
auditWriteObject STRUCTURAL MUST reqMod )
    
( LOG_SCHEMA_OC .6 NAME 'auditBind' DESC 'Bind operation' SUP
auditObject STRUCTURAL MUST ( reqDN $ reqMethod $ reqVersion ) )
    
( LOG_SCHEMA_OC .7 NAME 'auditCompare' DESC 'Compare operation' SUP
auditReadObject STRUCTURAL MUST reqAssertion )
    
( LOG_SCHEMA_OC .8 NAME 'auditDelete' DESC 'Delete operation' SUP
auditWriteObject STRUCTURAL MAY reqOld )
    
( LOG_SCHEMA_OC .9 NAME 'auditModify' DESC 'Modify operation' SUP
auditWriteObject STRUCTURAL MUST reqMod MAY reqOld )
    
( LOG_SCHEMA_OC .10 NAME 'auditModRDN' DESC 'ModRDN operation' SUP
auditWriteObject STRUCTURAL MUST ( reqNewRDN $ reqDeleteOldRDN ) MAY
( reqNewSuperior $ reqOld ) )
( LOG_SCHEMA_OC .11 NAME 'auditSearch' DESC 'Search operation' SUP
auditReadObject STRUCTURAL MUST ( reqScope $ reqDerefAliases $
reqAttrsonly ) MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit
$ reqTimeLimit ) )
    
( LOG_SCHEMA_OC .12 NAME 'auditExtended' DESC 'Extended operation'
SUP auditObject STRUCTURAL MAY reqData )

Classe conteneur générique

Cette classe d'objet peut être utilisée pour l'entrée parent des enregistrements:
( LOG_SCHEMA_OC .0 NAME 'auditContainer' DESC 'AuditLog container'
SUP top STRUCTURAL MAY ( cn $ reqStart $ reqEnd ) )

Discussion du schéma - AuditObject

   1. reqDN: le DN de l'entrée à laquelle le requête s'applique. Dans le cas d'une requête ModRDN, le reqDN donne le DN de l'entrée avant qu'elle ait été modifiée. Dans le cas d'un requête Search, le reqDN est le DN de base de la recherche. Syntaxe: DN.

   2. reqStart: la date du début de la requête sur le serveur. reqEND: la date de la fin de la requête sur le serveur. Les timestamps doivent avoir une résolution suffisante pour s'assurer que les valeur de reqStart et reqEnd sont uniques. Les serveurs devraient utiliser reqStart ou reqEnd comme RDN de l'enregistrement. Ce choix permettra de les les enregistrements dans l'ordre ascendant, bien que les 2 alternatives peuvent produire des résultats différents. Dans le cas où l'horloge du serveur ne fournir pas de temps suffisamment précis, une simple compteur peut être utilisé dans la partie fractionnelle des secondes. Syntaxe: generalizedTime.

   3. reqType: le type de la requête: abandon, add, bind, compare, delete, modify, modrdn, search ou extended{OID}. Pour les requêtes étendues, d'OID de la requête est inclue dans la chaîne. Syntaxe: DirectoryString

   4. reqSession: une valeur qui est une constante pour toutes les opérations se produisant dans une séquence bind/unbind. Syntaxe: DirectoryString

   5. reqAuthzID: L'identité d'authorisation utilisé pour effectuer la requête. Généralement la même que reqDN de la requête bind ayant le même reqSession, mais peut être altéré par divers contrôles et autres traitements. Syntaxe: DN

   6. reqResult: Le code de résultat LDAP de la requête complétée. Cette valeur peut être omise pour les requêtes qui n'ont pas de résultat définis (ex: abandon et unbind) et pour les requêtes qui ont été abandonnées. Syntaxe: Integer

   7. reqMessage: Le message d'erreur textuel accompagnant le résultat, s'il y'en a un. Syntaxe: DirectoryString

   8. reqReferral: Les référants qui ont accompagné le résultat, au format URI LDAP. Syntaxe: DirectoryString

   9. reqControls: le jeu de contrôles de requête accompagnant une requête. seqRespControls: le jeu de contrôles de réponse accompagnant le résultat de la requête. Chaque valeur représente un seul contrôle. l'ordre est préservé en utilisant l'extension de schéma X-ORDERED 'VALUES'. Syntaxe: Control

AuditContainer

   reqStart: le timestamp du premier enregistrement dans le log. reqEnd: le timestamp du dernier enregistrement dans le log. Syntaxe: generalizedTime

Abandon

   reqId: l'ID d'une requête à abandonner. Syntaxe: Integer

Bind

   reqVersion: La version du protocol du la requête. Syntaxe: Integer

  reqMethod: La méthode bind. Soit Simple, soit SASL/mécanisme. Syntaxe: DirectoryString

Compare

   reqAssertion: L'AVA de la requête. Syntaxe: DirectoryString

Rename

   reqNewRDN: Le nouveau rdn de la requête. Syntaxe: DN

  reqDeletedOldRDN: le deleteOldRDN de la requête. Syntaxe: Boolean

  reqNewSuperior: le nouveau DN supérieur de la requête. Syntaxe: DN.

Add et Modify

   reqMod: Les modifications de la requête. L'encodage est définis par la grammaire suivante (ABNF):


mod = attr ":" modop
attr = AttributeDescription from [RFC2251]
modop = add / delete / replace / increment
add = "+" sp value
delete = "-" [ sp value ]
replace = "=" [ sp value ]
increment = "#" sp value
sp = " "
value = AttributeValue from [RFC2251]

   Note que les requêtes Add utilisent uniquement le format add modop. Syntaxe: OctetString

  reqOld: Les valeurs précédente d'un attribut modifié. L'encodage est sous la forme attr ":" sp value, en utilisant la même forme que reqMod. Syntaxe: OctetString

Delete

   reqOld: le valeurs précédente d'une entrée supprimée. L'encodage est le même que plus haut. Syntaxe: OctetString
   reqScope: le scope de la recherche. base, one, sub ou subord. Syntaxe: DirectoryString

  reqDerefAliases: le paramètre derefAliases de la recherche. never, searching, finding, ou always. Syntaxe: DirectoryString

  reqAttrsOnly: le paramètre typesOnly de la requête. Syntaxe: Boolean

  reqFilter: Le filtre de la recherche. Syntaxe: DirectoryString

  reqSizeLimit: La limite de taille de la requête

  reqTimeLimit: Le limite de temps de la requête. Syntaxe: Integer

  reqAttr: Les attributs spécifiquement demandés. Syntaxe: DirectoryString

  reqEntries: Le nombre total d'entrées retournées pour cet requête. Syntaxe: Integer

Extended

   reqData: Les données accompagnant le requête. Syntaxe: OctetString

Exemples

   Dans les exemples suivants les enregistrements résident sous "cn=log" et sont nommés par leur attribut "reqStart"

dn: reqStart=20051017081049.000000Z,cn=log
objectClass: auditBind
reqStart: 20051017081049.000000Z
reqEnd: 20051017081049.000001Z
reqType: bind
reqSession: 0
reqAuthzID:
reqDN: cn=manager,dc=example,dc=com
reqResult: 0
reqVersion: 3
reqMethod: SIMPLE
    
dn: reqStart=20051017081049.000002Z,cn=log
objectClass: auditSearch
reqStart: 20051017081049.000002Z
reqEnd: 20051017081049.000003Z
reqType: search
reqSession: 0
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: dc=example,dc=com
reqResult: 0
reqScope: one
reqDerefAliases: never
reqAttrsOnly: FALSE
reqFilter: (objectClass=*)
reqSizeLimit: -1
reqTimeLimit: -1
reqEntries: 3
    
dn: reqStart=20051017081049.000004Z,cn=log
objectClass: auditObject
reqStart: 20051017081049.000004Z
reqEnd: 20051017081049.000005Z
reqType: unbind
reqSession: 0
reqAuthzID: cn=Manager,dc=example,dc=com

requête Add

Enregistrement issue de l'ajout d'une entrée dans l'annuaire:
dn: reqStart=20051017083706.000001Z,cn=log
objectClass: auditAdd
structuralObjectClass: auditAdd
reqStart: 20051017083706.000001Z
reqEnd: 20051017083706.000002Z
reqType: add
reqSession: 4
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: ou=People,dc=example,dc=com
reqResult: 0
reqMod: objectClass:+ organizationalUnit
reqMod: ou:+ People
reqMod: description:+ A bunch of people will be here
reqMod: structuralObjectClass:+ organizationalUnit
reqMod: entryUUID:+ f16734aa-d334-1029-9290-cd8deceec6b0
reqMod: creatorsName:+ cn=Manager,dc=example,dc=com
reqMod: createTimestamp:+ 20051017083706Z
reqMod: entryCSN:+ 20051017083706Z#000000#00#000000
reqMod: modifiersName:+ cn=Manager,dc=example,dc=com
reqMod: modifyTimestamp:+ 20051017083706Z

   Notez que les attributs opérationnels écrits avec la requête sont inclus dans le log. Toutes les statistiques associées avec une entrée seront exposées, permettant à un client de réplication d'avoir une copie complète de l'entrée.

Requête Modify

Enregistrement issue d'une entrée modifiée dans l'annuaire
dn: reqStart=20051017083734.000010Z,cn=log
objectClass: auditModify
reqStart: 20051017083734.000010Z
reqEnd: 20051017083734.000011Z
reqType: modify
reqSession: 1
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: ou=People,dc=example,dc=com
reqResult: 0
reqMod: description:-
reqMod: entryCSN:= 20051017083734Z#000003#00#000000
reqMod: modifiersName:= cn=Manager,dc=example,dc=com
reqMod: modifyTimestamp:= 20051017083734Z
reqOld: description: A bunch of people will be here

   Dans cet exemple, l'attribut description a été supprimé de l'entrée. Sa valeur original est enregistrée dans l'attribut reqOld.

Requête Rename

Enregistrement issue du renommage d'une entrée dans l'annuaire
dn: reqStart=20051017083734.000018Z,cn=log
objectClass: auditModRDN
reqStart: 20051017083734.000018Z
reqEnd: 20051017083734.000019Z
reqType: modrdn
reqSession: 1
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: ou=People,dc=example,dc=com
reqResult: 0
reqNewRDN: ou=Populi
reqDeleteOldRDN: TRUE

Requête Delete

Enregistrement issue de la suppression d'une entrée dans l'annuaire
dn: reqStart=20051017083734.000020Z,cn=log
objectClass: auditDelete
reqStart: 20051017083734.000020Z
reqEnd: 20051017083734.000021Z
reqType: delete
reqSession: 1
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: ou=Populi,dc=example,dc=com
reqResult: 0
reqOld: ou: Populi
reqOld: objectClass: organizationalUnit
reqOld: structuralObjectClass: organizationalUnit
reqOld: entryUUID: f16734aa-d334-1029-9290-cd8deceec6b0
reqOld: creatorsName: cn=Manager,dc=example,dc=com
reqOld: createTimestamp: 20051017083706Z
reqOld: entryCSN: 20051017083734Z#000007#00#000000
reqOld: modifiersName: cn=Manager,dc=example,dc=com
reqOld: modifyTimestamp: 20051017083734Z

Notes d'usage

   Les serveurs peuvent implémenter seulement un sous-jeu de ces attributs, ou fournir des mécanismes de configuration pour réduire la plage d'opération couverte dans les logs. Les clients de réplication travaillant depuis un log complet peuvent utiliser un filtre de recherche avec les termes "(&(objectClass=AuditWriteObject)(reqResult=0))" pour filtrer les enregistrements peut utile.

Considérations IANA

En accord avec la rfc3383:
OpenLDAP_Experimental = 1.3.6.1.4.1.4203.666
LOG_SCHEMA = OpenLDAP_Experimental.11.5
LOG_SCHEMA_AT = LOG_SCHEMA.1
LOG_SCHEMA_OC = LOG_SCHEMA.2
LOG_SCHEMA_SYN = LOG_SCHEMA.3

^
12 mai 2014

htmlpdflatexmanmd




draft-chu-ldap-xordered-00

draft-chu-ldap-xordered-00

Extension de schéma X-ORDERED

   Ce document décrit un schéma pour attacher des informations ordonnées aux attributs dans un annuaire pour que l'ordre puisse être préservé et propagé aux autres applications LDAP.

   L'extension de schéma X-ORDERED est ajouté à un AttributeTypeDescription pour signifier l'utilisation de ce mécanisme d'ordonnancement. L'extension a 2 variantes. En général cette extension est uniquement compatible avec AttributeType qui a une syntaxe orienté chaîne.

   La variante VALUES est utilisée avec les attributs multi-valués pour maintenir l'ordre des valeurs. Par exemple, cette fonctionnalité est utile pour stocker des données telles que les ACL, qui doivent être évaluées dans un ordre spécifique.

   La variante SIBLINGS est utilisée avec les attributs mono-valués pour maintenir l'ordre de tous les enfants onelevel de l'entrée parent. L'ordre sera ainsi maintenu pour toutes les entrées enfants dont le RDN est de même AttributeType. Par exemple, on pourrait stocker une liste prioritisée de serveurs en tant que jeu d'entrées séparées, chaque entrée contenant les attributs séparés pour une URL, un jeu d'accréditation et divers autres paramètres.

Encodage

L'information d'ordonnancement est encodée en préfixant un index ordinal à chaque valeur, entre accolade:
d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
numericstring = 1*d
ordering-prefix = "{" numericstring "}"
value = ‹any sequence of octets›
ordered-value = ordering-prefix value

   Ils sont basés sur 0 et incrémentés de 1 à chaque valeur. Noter qu'en stockant les valeurs ordonnancées dans un annuaire, le préfixe pour généralement être omis vu qu'il sera généré automatiquement. Mais si la valeur original commence avec une séquence de caractères dans la forme d'un préfixe d'ordonnancement, le préfixe devra être fournis. Utiliser cette extension dans un attribut qui nécessite ce préfixe est une valeur de syntaxe LDAP légal de cet attribut.
   [SECTION] name="Propriété d'ordonnancement" table="paragraphes" imbrication="0"

- Quand présenté avec une AssertionValue qui n'a pas de préfixe d'ordonnancement, le préfixe dans l'AttributeValue est ignoré.
- Quand présenté avec une AssertionValue qui consiste uniquement de ce préfixe, seul le préfixe de cet AttributeValue est comparé, le reste de la valeur est ignoré
- Quand présenté avec une AssertionValue contenant le préfixe et une valeur, les 2 composants sont comparés pour déterminer le match.

   Un effet de bord de ces propriétés et que même les attributs qui normalement n'ont pas de règle de correspondance d'égalité peuvent être matchés par un préfixe d'ordonnancement.

   Le préfixe d'ordonnancement peut être également utilisé dans les requêtes de modification pour spécifier quelles valeur supprimer, et à quelle position devrait les valeurs devraient être ajoutées. Si une valeur ajoutée n'a pas de préfixe, elle est simplement ajoutée à la liste avec un préfixe automatiquement généré.

Exemple de schéma

Ce schéma est utilisé pour tous les exemples:
( EXAMPLE_AT.1 NAME 'olcDatabase'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORDERED 'SIBLINGS' )
    
( EXAMPLE_AT.2 NAME 'olcSuffix'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
X-ORDERED 'VALUES' )
    
( EXAMPLE_OC.1 NAME 'olcDatabaseConfig'
SUP top STRUCTURAL
MAY ( olcDatabase $ olcSuffix ) )

Values ordonnées

En donnant cette entrée:
dn: olcDatabase={1}bdb,cn=config
olcDatabase: {1}bdb
objectClass: olcDatabaseConfig
olcSuffix: {0}dc=example,dc=com
olcSuffix: {1}o=example.com
olcSuffix: {2}o=The Example Company
olcSuffix: {3}o=example,c=us

1. On peut effectuer les opérations Modify suivantes:
dn: olcDatabase={1}bdb,cn=config
changetype: modify
delete: olcSuffix
olcSuffix: {0}
-

Cette opération supprime le premier olcSuffix, Sans regardes sa valeur. Toutes les autres valeurs sont remotées d'un position. L'attribut olcSuffix contiendra au final:
olcSuffix: {0}o=example.com
olcSuffix: {1}o=The Example Company
olcSuffix: {2}o=example,c=us

2. En commançant depuis l'entrée originale, on pourrait fournir ce changement à la place:
delete: olcSuffix
olcSuffix: o=example.com
-

Cette oppération supprime le olcSuffix qui matche la valeur, sans regarder sont préfixe. L'attribut olcSuffix va contenir:
olcSuffix: {0}dc=example,dc=com
olcSuffix: {1}o=The Example Company
olcSuffix: {2}o=example,c=us

3. Également, en commançant depuis l'entrée originale, on pourrait effectuer ce changement:
delete: olcSuffix
olcSuffix: {2}o=The Example Company
-

Ici, le préfixe et la valeur doivent correspondre, sinon l'opération échoue:
olcSuffix: {0}dc=example,dc=com
olcSuffix: {1}o=example.com
olcSuffix: {2}o=example,c=us

4. Ajouter une nouvelle valeur sans préfixe l'ajoute simplement:
add: olcSuffix
olcSuffix: o=example.org
-

L'attribut résultant est:
olcSuffix: {0}dc=example,dc=com
olcSuffix: {1}o=example.com
olcSuffix: {2}o=The Example Company
olcSuffix: {3}o=example,c=us
olcSuffix: {4}o=example.org

5. Ajouter une nouvelle valeur avec un préfixe l'insert à la position spécifiée:
add: olcSuffix
olcSuffix: {0}o=example.org
-

Le résultat est:
olcSuffix: {0}o=example.org
olcSuffix: {1}dc=example,dc=com
olcSuffix: {2}o=example.com
olcSuffix: {3}o=The Example Company
olcSuffix: {4}o=example,c=us

6. Modifier plusieurs valeur en une opération:
add: olcSuffix
olcSuffix: {0}ou=Dis,o=example.com
olcSuffix: {0}ou=Dat,o=example,com
-
delete: olcSuffix:
olcSuffix: {2}
olcSuffix: {1}
-

Le résultat est:
olcSuffix: {0}ou=Dat,o=example,com
olcSuffix: {1}dc=example,dc=com
olcSuffix: {2}o=example.com
olcSuffix: {3}o=The Example Company
olcSuffix: {4}o=example,c=us

7. Si les add et delete de l'exemple précédent étaient fait dans l'ordre inversé:
opposite order:
delete: olcSuffix:
olcSuffix: {2}
olcSuffix: {1}
-
add: olcSuffix
olcSuffix: {0}ou=Dis,o=example.com
olcSuffix: {0}ou=Dat,o=example,com
-

Le résultat serait:
olcSuffix: {0}ou=Dat,o=example,com
olcSuffix: {1}ou=Dis,o=example.com
olcSuffix: {2}o=example.org
olcSuffix: {3}o=The Example Company
olcSuffix: {4}o=example,c=us

   Noter que matcher avec un préfixe d'ordonnancement peut aussi être fait dans les opération compare et dans les filtres de recherche. Par exemple, le filtre "(olcSuffix={4})" va matcher toutes les entrées avec au moins 5 valeurs olcSuffix

Siblings ordonnées

   Les règles pour le siblings ordonnées sont basiquement les même que pour les values ordonnées, excepté qu'au lieu de travailler principalement avec des opération modify, les opérations intéressantes sont add, delete et modrdn

En donnant l'entrée suivante:
dn: olcDatabase={0}config,cn=config
olcDatabase: {0}config
objectClass: olcDatabaseConfig
olcSuffix: {0}cn=config
    
dn: olcDatabase={1}bdb,cn=config
olcDatabase: {1}bdb
objectClass: olcDatabaseConfig
olcSuffix: {0}dc=example,dc=com

1. Ajouter une nouvelle entrée sans préfixe d'ordonnancement:
dn: olcDatabase=hdb,cn=config
changetype: add
olcDatabase: hdb
objectClass: olcDatabaseConfig
olcSuffix: {0}dc=example,dc=org

Le résultat sera:
dn: olcDatabase={2}hdb,cn=config
olcDatabase: {2}hdb
objectClass: olcDatabaseConfig
olcSuffix: {0}dc=example,dc=org

2. En continuant avec ces 3 entrées, on peut ajouter une autre entrée avec un préfixe d'ordonnancement
dn: olcDatabase={1}ldif,cn=config
changetype: add
olcDatabase: {1}ldif
objectClass: olcDatabaseConfig
olcSuffix: {0}o=example.com

Ce qui nous donnera 4 entrées, dont les DN sont:
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}ldif,cn=config
dn: olcDatabase={2}bdb,cn=config
dn: olcDatabase={3}hdb,cn=config

3. Fournir une requête modrdn va renommer plusieurs entrées:
dn: olcDatabase={1}ldif,cn=config
changetype: modrdn
newrdn: olcDatabase={99}ldif,cn=config
deleteoldrdn: 1

Les entrées résultante seront nommées:
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}bdb,cn=config
dn: olcDatabase={2}hdb,cn=config
dn: olcDatabase={3}ldif,cn=config

4. Une opération delete va également renommer les entrées restantes:
dn: olcDatabase={1}bdb,cn=config
changetype: delete

Donne:
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}hdb,cn=config
dn: olcDatabase={2}ldif,cn=config

^
07 août 2015

htmlpdflatexmanmd




draft-findlay-ldap-groupofentries

draft-findlay-ldap-groupofentries

ObjectClass groupOfEntries

   Une classe objet groupOfNames existe depuis le standard X.521. Il a une définition identique dans LDAP (rfc4519). La classe est utilisée pour définir des entrées contenant des attributs de DN de membres, chaque valeur pointant vers une entrée qui représente un simple membre du groupe décris, ou vers une autre entrée de type groupOfNames.

   groupOfNames est une classe structurelle, donc elle est souvent la seulement utilisé dans la définition des objets groupes.

   L'expérience a montré que la définition des groupOfNames créé des difficultés en pratique. En particulier, le fait que 'member' est un attribut mandatoire signifie qu'il n'est pas possible de créer un groupe vide ou de supprimer le dernier membre d'un groupe. Cela impose certains artifices tels que créer un groupe membre de lui-même, ou d'ajouter un faux membre quand un groupe est créé. Cela rend la gestion des groupes plus complexe et sujet à erreurs. Les groupes sont communément utilisés pour contrôler l'accès aux ressources, dont les erreurs de gestion peuvent conduire à des risques de sécurité.

   Il n'y a pas de raison apparente pour que l'attribut 'member' soit mandatoire. Ce mémo décris une nouvelle classe appelée groupOfEntries qui est équivalent à groupOfNames à l'exception de l'attribut 'member' qui est optionnel.

Définition

La classe groupOfEntries est la base d'une entrée qui représente un jeu d'objets nommés incluant des informations liées à l'objectif ou la maintenance du jeu. Elle devrait être utilisée de préférence à groupOfNames:
( 1.2.826.0.1.3458854.2.1.1.1 NAME 'groupOfEntries' SUP top STRUCTURAL MUST ( cn ) MAY ( member $ businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

Effets sur d'autres documents

   Ce draft déprécie l'utilisation de groupOfNames dans la rfc4519 et le remplace par la classe groupOfEntries.
^
24 septembre 2014

htmlpdflatexmanmd




draft-haripriya-dynamicgroup-02

draft-haripriya-dynamicgroup-02

Groupes dynamiques pour LDAPv3

   Ce document décris les pré-requis, les sémantiques, les éléments du schéma, et les opérations nécessaires pour une fonctionnalité de groupe dynamique dans LDAP. Un groupe dynamique est définis ici comme un objet groupe avec une liste de dn qui est dynamiquement générée en utilisant un critère de recherche LDAP. La liste des membres dynamique peut ainsi être interrogée par une opération search ou compare, et peut également être utilisée pour trouver les groupes dont un objet est membre. Cette fonctionnalité élimine une grande quantité d'effort administratif pour maintenir l'appartenance à des groupes et les opérations basées sur les rôles dans une grande entreprise.

   Le schéma décris dans ce document définis 2 classes d'objet: 'groupOfNames', et 'groupOfUniqueNames', qui maintiennent une liste statique de DN dans leur attribut member et uniqueMember, respectivement, et sont typiquement utilisés pour décrire un groupe d'objets pour diverses fonctions. Les groupes dynamique sont des groupes normaux, mais permettent de spécifier des critères à utiliser pour évaluer les membres. Cela peut également être un supplément aux groupes statiques dans LDAP pour fournir de la flexibilité.

Pré-requis

   Les pré-requis suivants devraient être en place:

1. La création et l'administration des groupes dynamique devraient être fait en utilisant des opérations LDAP normales
2. Les applications doivent être capable d'utiliser les groupes dynamique de la même manière qu'avec les groupes statiques pour lister les membres et l'évaluation des membres
3. L'interrogation des membre d'un groupe dynamique devrait être fait en utilisant des opérations LDAP normales, et devraient être consistants.

Définition et sémantique du schéma

   Les classes des groupes dynamique sont définis par le schéma suivant:

ObjectClasses

dynamicGroup Cette objet structurel est utilisé pour créer un objet de groupe dynamique. Il est dérivé de groupOfNames
dynamicGroupOfUniqueNames Cette objet structurel est utilisé pour créer un objet de groupe dynamique dont la liste des membres sont maintenus dans un attribut uniqueMember. Il est dérivé de groupOfUniqueNames
dynamicGroupAux Cette classe auxiliaire est utilisée pour convertir un objet existant en un groupe dynamique. Il est dérivé de groupOfNames
dynamicGroupOfUniqueNamesAux Cette classe auxiliaire est utilisée pour convertir un objet existant en un groupe dynamique de membres uniques. Il est dérivé de groupOfUniqueNames

Attributes

memberQueryURL Décris les membres de la liste une utilisant un LDAPURL
excludedMember Utilisé pour exclure les entrées d'un groupe dynamique.
member il est surchargé lorsqu'utilisé avec un groupe dynamique. Il est utilisé pour lister les membres statiques d'un groupe dynamique. Si la même entrée est listée dans les attributs member et excludedMember, cet attribut a précédence
uniqueMember fonctionne de manière similaire à member. Il a également précédence sur excludedMember
dgIdentity Pour fournir des résultat consistants en traitant les critères de recherche, le serveur doit utiliser une simple identité d'autorisation. Si l'autorisation de l'identité est liée, la liste des membres va varier. Cette identité peut servir pour effectuer la recherche.

format LDAPURL

la notation BNF est listée ici pour référence
ldapurl = scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION extensions]]]]]
scheme = "ldap"
dn = distinguishedName
attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector)
selector = attributeSelector
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid
exvalue = LDAPString
EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")

schéma


( ‹OID.TBD› NAME 'memberQueryURL' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( ‹OID.TBD› NAME 'excludedMember' SUP distinguishedName )
( 2.5.4.31 NAME 'member' SUP distinguishedName )
( 2.5.4.32 NAME 'uniqueMember' SUP distinguishedName )
( ‹OID.TBD› NAME 'identity' SUP distinguishedName SINGLE-VALUE )
    
( ‹OID.TBD› NAME 'dynamicGroup' SUP groupOfNames STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity ))
( ‹OID.TBD› NAME 'dynamicGroupOfUniqueNames' SUP groupOfUniqueNames STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity ))
( ‹OID.TBD› NAME 'dynamicGroupAux' SUP groupOfNames AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity ))
( ‹OID.TBD› NAME 'dynamicGroupOfUniqueNamesAux' SUP groupOfUniqueNames AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity ))

Extension x-chain

   Une nouvelle extension est définie pour utilise memberQueryURL dans les groupes dynamiques, appelé 'x-chain'. Elle ne prend pas de valeur. Si présent, le serveur doit suivre toute référence de continuation de recherche sur d'autres serveurs lors de la recherche de membres.

Multiple valeurs

   memberQueryURL peut avoir plusieurs valeurs, et dans ce cas, les membres du groupe dynamique sera l'union de ces membres calculés.

Condition des membres

Un objet O est un membre d'un groupe dynamique G si et seulement si:
(( O is a value of the 'member' or 'uniqueMember' attribute of G)
OR
(( O is selected by the membership criteria specified in the 'memberQueryURL' attribute values of G)
AND
( O is not listed in the 'excludedMember' attribute of G) ))

   Si un membre M d'un groupe dynamique G apparaît être un groupe dynamique ou statique, les membres statiques et dynamique de M ne devraient pas être considérés membre de G. M est un membre de G cependant. La dernière condition est imposée parce que:

- les membre évalués récursivement peuvent dégrader les performances du serveur
- Des boucles peuvent se produire dans des situations particulières
- L'affirmation des membres dynamique ne peut pas être optimisée si le membership récursif est permis.

dgIdentity - implication de sécurité

   Parce que cet attribut donne indirectement, mais effectivement accès à tout le monde avec les opération read ou compare sur les attributs member ou uniqueMember avec les permissions suffisantes pour obtenir un résultat DN depuis memberQueryURL, les implémentation de serveur ne devraient pas autoriser de populer cet attribut avec le DN de n'importe quel objet qui n'est pas administré par l'identité faisant le changement de cet attribut.

Opérations sur les groupes dynamiques

   Les opérations suivantes devraient exposer la fonctionnalité de groupe dynamique. Cet opérations ne nécessitent pas de changement dans l'annuaire, lorsque le sujet est un objet dynamique, et tous les membres du groupe, incluant les membres dynamiques, auront les mêmes permissions sur l'entrée cible.

Lire un objet dynamique

   Quand les attributs member d'un groupe dynamique est listé par le client en utilisant une opération de recherche, les valeurs de member retournés devraient contenir les membres statiques et dynamiques. Cette fonctionnalité ne nécessite pas de changement au protocole, et les client n'ont pas à se préoccuper des groupes dynamiques pour exploiter cette fonctionnalité. Cette fonctionnalité est utile pour les client qui déterminent les accès privilégiés à une ressource par eux-même, en lisant les membres d'un objet groupe.

   Par exemple: les client qui lisent l'attribut member d'un objet groupe dynamique et tentent de supprimer des valeurs qui sont dynamiquent peuvent reçevoir une erreur spécifiant qu'un telle valeur n'existe pas.

le groupe dynamique cn=dg1,o=myorg avec les attributs suivant:
member: cn=admin,o=myorg
excludedMember: cn=guest,ou=finance,o=myorg
excludedMember: cn=robin,ou=finance,o=myorg
memberQueryURL: ldap:///ou=finance,o=myorg??sub?(objectclass=organizationalPerson)
S'il y a 5 organizationalPerson sous ou=finance,o=myorg avec les noms commun bob, alice, john, robin, et guest, la sortie d'une recherche LDAP sur cn=dg1,o=myorg, avec l'attribut listé contenant 'member' sera la suivante:
dn: cn=dg1,o=myorg
member: cn=admin,o=myorg
member: cn=bob,ou=finance,o=myorg
member: cn=alice,ou=finance,o=myorg
member: cn=john,ou=finance,o=myorg

Fonctionnalité Is Member Of

   L'opération de comparaison LDAP permet de découvrir si un DN est membre d'un groupe dynamique. De même, le serveur devrait produire des résultats consistants avec différentes identités d'autorisation lorsqu'il traite cette requête, tant que ces identités ont le même accès à l'attribut member ou uniqueMember. En utilisant les données de l'exemple plus haut, une comparaison dur cn=dg1,o=myorg, pour l'AVA member=cn=bob,ou=finance,o=myorg va résulter en une réponse compareTrue.

Membres statiques

   Parce qu'un groupe dynamique surcharge la sémantique des attributs member et uniqueMember, un mécanisme est nécessaire pour récupérer les valeurs statiques trouvées dans ces attributs dans un but de gestion. Une nouvelle option d'attribut est définie, appelée 'x-static' qui devrait être spécifié uniquement avec les attributs member et uniqueMember.

Exemples

1. La valeur memberQueryURL spécifie le critère d'appartenance pour une entrée de groupe dynamique comme "toutes les entrée inetOrgPerson qui ont leur attribut title à manager, et sont sous ou=hr,o=myorg":
memberQueryURL: ldap:///ou=hr,o=myorg??sub?(&(objectclass=inetorgperson)(title=manager))?x-chain
2. Cet valeur laisse l'utilisateur spécifier le critère d'appartenance pour une entrée de groupe dynamique comme "toutes les entrées sur le serveur local, qui a soit un compte unix ou appartient au département unix, et sous le conteneur engineering":
memberQueryURL: ldap:///ou=eng,o=myorg??sub?(|(objectclass=posixaccount)(department=unix))
3. Ces valeurs laissent l'utilisateur spécifier le critère de membership comme "toutes les entrées inetOrgPerson sur le serveur local, soit sous ou=eng,o=myorg soit sous ou=support,o=myorg"
memberQueryURL: ldap:///ou=eng,o=myorg??sub?(objectclass=inetorgperson)
memberQueryURL: ldap:///ou=support,o=myorg??sub?(objectclass=inetorgperson)
^
15 septembre 2014

htmlpdflatexmanmd




draft-ietf-ldapext-acl-model-08

draft-ietf-ldapext-acl-model-08

Modèle de contrôle d'accès

   La capacité d'accéder aux informations de manière sûre via le réseau est nécessaire pour un déploiement réussi. Actuellement, LDAP ne définis pas de modèle de contrôle d'accès, mais il est nécessaire pour assurer un accès sécurisé conforme, réplication et gestion via des implémentations LDAP hétérogènes. L'objectif majeur est de fournir un modèle de contrôle d'accès simple, exploitable, implémentable et sécurisé pour l'accès au contenu des annuaires LDAP tout en fournissant la flexibilité appropriée pour les besoins de l'Internet et des environnements d'entreprise. Ce document définis le modèle, le schéma, et le contrôle LDAP.

   Ce modèle ne ( et ne peut pas ) spécifie pas pleinement le fonctionnement du modèle dans un environnement distribué ( ex: propager les informations de contrôle d'accès entre les serveurs ).

   Les mécanismes de contrôle d'accès évaluent les demandes pour accéder aux ressources protégées et prend des décisions d'autoriser ou non l'accès. Pour faire ces décisions, pour une demande, un mécanisme de contrôle d'accès doit évaluer des données de stratégie. Cette stratégie décris des caractéristiques de sécurité requises par le sujet et des règles qui gouvernent l'utilisation le l'objet cible.

   Aucun mécanisme n'est définis dans ce document pour stocker les informations de contrôle d'accès. Le modèle de contrôle d'accès définis:

- Les flux de protocole LDAP existant pour les opérations ldap sont utilisés pour manipuler les informations de contrôle d'accès. Ces même flux s'appliquent quand des ACI sont transmis durant la réplication. Un jeu de permission et leur sémantique est définis. Il y a une contrôle définis, GetEffectiveRights que les clients utilisent pour gérer et administrer les contrôles d'accès des serveurs.
- Les attributs et classes pour la portabilité des informations de contrôle d'accès aux applications. Les applications ldap portables devraient seulement utiliser ce modèe d'ACI. 2 attributs de contrôle d'accès ( entryACI et subtreeACI ) sont utilisé comme entrée à l'API ldap pour que les informations de contrôle d'accès puisse être adressés uniformément et indépendamment de la manière dont ces informations sont accédés et stockés dans le serveur. Une classe subentry ( ldapACISubEntry ) et un jeu d'attributs ( supportedAccessControlSchemes, accessControlSchemes ) sont utilisés pour identifier les mécanismes de contrôle d'accès supportés par un serveur.
- Un mécanisme pour contrôler l'accès aux ACI: les attributs opérationnel entryACI et subtreeACI sont utilisés pour contrôler les accès aux ACI.

   Les serveurs peuvent supporter plusieurs mécanismes de contrôle d'accès, mais doivent être capable de supporter le mécanisme LDAP dans le DIT scopé par les rootDSE ( tout de DIT du serveur ) et devrait être capable de supporter le mécanisme ldap dans une portion arbitraire (subtree) de ce DIT.

   L'attribut accessControlSchemes dans le ldapACISubEntry indique quels mécanisme de contrôle d'accès sont effectifs pour le scope de ce subentry. L'attribut supportedAccessControlSchemes dans le rootDSE indique quels mécanismes de contrôle d'accès sont supportés par le serveur. Ces mécanismes sont effectifs dans le DIT du serveur sauf s'il sont remplacés par un mécanisme définis dans un ldapACISubEntry quelque part dans le DIT.

   Changer les valeurs de supportedAccessControlSchemes ou accessControlSchemes change les mécanismes actifs pour le scope de ces attributs. Via l'utilisation de supportedAccessControlSchemes dans le rootDSE et accessControlSchemes dans ldapACISubEntry, il est possible de lancer plusieurs mécanismes dans le même subtree ou des subtree séparés.

Attributs de mécanisme de contrôle d'accès

   2 attributs sont définis pour identifier quels mécanismes sont supportés par un serveur donné et par un subtree donné: supportedAccessControlSchemes et accessControlSchemes.

Attribut RootDSE pour les mécanismes

   Le serveur utilise supportedAccessControlSchemes dans le rootDSE pour difuser les mécanismes supportés. Cet attribut est une liste d'OID, chacun identifiant un mécanisme de contrôle d'accès supporté par le serveur. Par défaut, il y a également les mécanismes actifs dans les subtrees.


(‹OID to be assigned›
    NAME 'supportedAccessControlSchemes'
    DESC list of access control mechanisms supported by this directory server
    EQUALITY objectIdentifierMatch
    SYNTAX OID
    USAGE dSAOperation
)

Mécanisme de contrôle d'accès subentry

   Un contexte de nommage doit fournir des informations sur les mécanismes de contrôle d'accès qui sont actifs pour la portion de l'espace de nom. Cette information est contenue dans un subentry ( ldapACISubEntry ). Il peut être utilisé pour définir le scope d'un mécanisme de contrôle d'accès. Les valeurs maintenus dans le rootDSE, sont les mécanismes actifs dans les subtrees sous le root à moins d'être substitué dans un ldapACISubEntry plus bas dans l'arborescence maintenue par le serveur. Le scope de cet ldapACISubEntry est à la fin du subtree maintenu par ce serveur ou jusqu'à ce qu'un autre ldapACISubEntry soit rencontré. la classe ldapACISubEntry est définis:


( ‹OID to be assigned›
    NAME 'ldapACISubEntry'
    DESC 'LDAP ACI Subentry class'
    SUP ldapSubEntry STRUCTURAL
    MUST ( accessControlSchemes )
)

   accessControlSchemes doit être dans chaque ldapACISubEntry associé avec un contexte de nommage dont le mécanisme de contrôle d'accès est différent des contextes de nommage adjacents supportés par ce serveur. accessControlSchemes liste les valeurs qui définissent les mécanismes de contrôle d'accès effectifs pour le scope de ce subentry. Bien qu'en général cet attribut définis un seul mécanisme, il peut en contenir plusieurs.


(‹OID to be assigned›
    NAME 'accessControlSchemes'
    DESC list of access control mechanisms supported in this subtree
    EQUALITY objectIdentifierMatch
    SYNTAX OID
    USAGE dSAOperation
)

Définitions

La syntaxe et attributs pour les informations de contrôle d'accès, entryACI et subtreeACI, sont définis:
(‹OID-aci-syntax›
    DESC 'attribute syntax for LDAP access control information'
)
    
(‹OID to be assigned›
    NAME 'entryACI'
    DESC 'ldap access control information, scope of entry'
    EQUALITY directoryComponentsMatch
    SYNTAX ‹OID-aci-syntax›
    USAGE directoryOperation
)
    
(‹OID to be assigned›
    NAME 'subtreeACI'
    DESC 'ldap access control information, scope of subtree'
    EQUALITY directoryComponentsMatch
    SYNTAX ‹OID-aci-syntax›
    USAGE directoryOperation
)

   Le but de ces définitions d'attribut est de définir un format commun et d'avoir une séparation des responsabilités pour permettre à différentes personnes d'administrer des différents types d'attributs. Tout serveur LDAP devrait être capable de traduire l'attribut définis en requêtes significatives. Chaque serveur devrait être capable de comprendre l'attribut; Il ne devrait pas y avoir d'ambiguïté dans aucune partie de la syntaxe.

   Alors que le but final est d'avoir un modèle commun entre différentes implémentations de serveur LDAP, les définitions d'attribut seul n'auront pas forcement un traitement d'ACL identique entre les serveurs. Les règles d'applicabilité et de précédence pour prendre les décisions d'accès sont définis plus bas dans cette section. Les sémantiques sur la manière dont un serveur interprète da syntaxe ACI sont définis plus bas dans ce document. Additionnellement, tandis que le serveur doit reconnaître et agir sur l'attribut quand il reçoit de flux, il n'y a aucun requis pour le serveur pour stocker physiquement ces attributs sous cette forme.

   Les définitions d'attribut maintiennent une hypothèse selon laquelle le serveur de réception supporte l'héritage d'ACI dans le modèle de sécurité. Si le serveur ne supporte pas l'héritage, le serveur de réception doit étendre toute information d'héritage basé dur le flag de scope.

   Les attributs sont définis pour que les ACI puissent être adressés dans un serveur d'une manière indépendante de l'implémentation. Ces attributs sont utilisés dans les API LDAP, dans la sortie LDIF de l'ACI et en transfert d'ACI durant la réplication. Ces attributs peuvent être requêtés ou définis dans tous les objets de l'annuaire. Les définitions et notation ABNF sont donnés ci-dessous.

Représentation de chaîne UTF-8

L'encodage des chaînes LDAP des valeur de la syntaxe ACI est décrite:
ACI = rights "#" attr "#" generalSubject
    
rights = (("grant:" / "deny:") permissions) /
    ("grant:" permissions ";deny:" permissions)
    
permissions = 1*(permission)
permission = "a" / ; add
    "d" / ; delete
    "e" / ; export
    "i" / ; import
    "n" / ; renameDN
    "b" / ; browseDN
    "v" / ; view (entry level read permission)
    "t" / ; returnDN
    "r" / ; read
    "s" / ; search filter
    "p" / ; search filter (presence only)
    "w" / ; write (mod-add)
    "o" / ; obliterate (mod-del)
    "c" / ; compare
    "m" / ; make
    "u" / ; unveil (disclose on error permission)
    "g" ; getEffectiveRights
    
; les permissions r, w, o, s, p, c, m fonctionnent sur les attributes
; les permissions a, d, e, i, n, b, v, t, u, g fonctionnent sur les entrées
; les permissions pour les attributs et permissions pour les entrées ne sont jamais trouvés dans un simple ACI
    
attr = "[all]" / "[entry]" / (attribute *("," attribute))
    
attribute = AttributeDescription
    
generalSubject = context pureSubject
    
context = "authnLevel:" authnLevel ":"
    
pureSubject = anySubject / machineSubject / idBasedSubject
    
anySubject = "public:"
    
machineSubject = "ipAddress:" ipAddressRange *( "," ipAddressRange ) /
    "dns:" partialdomainname *( "," partialdomainname )
    
partialdomainname = [ "*." ] domainname
    
idBasedSubject = thisSubject /
    oneSubject /
    setOfSubjects
    
thisSubject = "this:"
oneSubject = ( "authzId-" authzId )
setOfSubjects = ( "role:" dn ) /
    ( "group:" dn ) /
    ( "subtree:" dn )
    
authnLevel = "none" /
    "weak" /
    "limited" /
    "strong"
    
authzId = dnAuthzId / uAuthzId
    
; distinguished-name-based authz id.
dnAuthzId = "dn:" dn
    
dn = utf8string
    
; unspecified userid, UTF-8 encoded.
uAuthzId = "u:" userid
userid = utf8string ; syntax unspecified
; A utf8string is defined to be the UTF-8 encoding of
; one or more ISO 10646 characters.
    
ipAddress = IPv6address
    
; following is excerpted from [IPV6]
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
    
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
    
ipAddressRange = ipAddress [ HYPHEN ipAddress ] ; IPv6 address range
    
domainname = domaincomponent *( "." domaincomponent )
    
OUTER = ALPHA / DIGIT
INNER = ALPHA / DIGIT / HYPHEN
HYPHEN = %x2D
domaincomponent = OUTER [ *61( INNER ) OUTER ]

   Noter que les virgules suivant "public" et "this" existent seulement pour simplifier le parsing des chaînes. Si on tente d'ajouter un ACI avec un authz qui n'est pas supporté, le serveur doit rejeter cette valeur entryACI ou subEntryACI. Voir la section "Examples d'ACI" pour les examples de représentation de chaîne.

Représentation binaire


LDAP-Access-Control-Model
DEFINITIONS EXTENSIBILITY IMPLIED ::=
BEGIN
    
IMPORTS
    AttributeType, DistinguishedName, CONTEXT
        FROM InformationFramework; -- from [X501]
    
ACI ::= SEQUENCE {
    rights SEQUENCE {
        grant Permissions OPTIONAL,
        deny [1] Permissions OPTIONAL }
            (WITH COMPONENTS { ..., grant PRESENT } |
            WITH COMPONENTS { ..., deny PRESENT }),
            -- at least one of grant or deny must be present --
    attr CHOICE {
        all NULL,
        entry [1] NULL,
        attributes SET (1..MAX) OF AttributeTypeAndOptions },
    authnLevel ::= ENUMERATED {
        none (0),
        weak (1),
        limited (2),
        strong (3)}
    subject GeneralSubject
}


--Une représentation X.500 pour une description d'attribut LDAP
AttributeTypeAndOptions ::= SEQUENCE {
    type AttributeType,
    type-name UTF8String OPTIONAL,
options SEQUENCE SIZE (1..MAX) OF CONTEXT.&Assertion OPTIONAL
}
GeneralSubject ::= CHOICE {
    anySubject NULL,
    machineSubject [1] MachineSubject,
    idBasedSubject [2] IDBasedSubject
}
    
MachineSubject ::= CHOICE {
    ipAddress IPAddress,
    dns [1] DomainName
}
    
IPAddress ::= UTF8String
    
DomainName ::= UTF8String
    
IDBasedSubject ::= CHOICE {
    thisSubject NULL,
    oneSubject [1] OneSubject,
    setOfSubjects [2] SetOfSubjects
}
    
OneSubject ::= CHOICE {
    dn DistinguishedName,
    user UTF8String
}
    
SetOfSubjects ::= CHOICE {
    role DistinguishedName,
    group [1] DistinguishedName,
    subtree [2] DistinguishedName
}


Permissions ::= BIT STRING {
    add (0),
    delete (1),
    export (2),
    import (3),
renameDN (4),
    browseDN (5),
    viewEntry (6),
    returnDN (7),
    read (8),
    search (9),
    searchPresence (10),
    write (11),
    obliterate (12),
    compare (13),
    make (14),
    unveil (15),
    getEffectiveRights (16)
    (CONSTRAINED BY { -- at least one bit must be set -- })
}

   Les permissions read, write, obliterate, search, searchPresence, compare, make fonctionnent sur les permissions d'attributs. add, delete, export, import, renameDN, browseDN, viewEntry, returnDN, unveil, getEffectiveRights fonctionnent sur les entrées.

Les composants des attributs entryACI et subtreeACI

   Cette section définis les composants qui comprennent les attributs d'informations de contrôle d'accès, entryACI et subtreeACI. Les information dans entryACI s'appliquent seulement à l'entrée dans laquelle elle est contenue. Les informations dans subtreeACI s'appliquent à chaque entrée sous le subtree sauf si un entryACI spécifique ou un subtreeACI est rencontré. L'utilisation des ACI prescritives et le scoping via l'utilisation d'un ldapACISubEntry n'est pas décris dans ce document.

Droits d'accès et permissions

   Les droits d'accès peuvent être appliqués à tout un object ou à des attributs de l'objet. L'accès peut être donné ou refusé. Une ou les deux actions "grant" | "deny" peuvent être utilisé en créant ou mettant à jour un entryACI et subtreeACI.

Permissions que s'appliquent aux attributs:
r Read - Lire les valeurs de l'attribut
w Write - Modifier-Ajouter des valeurs
o Obliterate - Modifier-Suprimer des valeurs
s Search - Rechercher des entrées avec les attributs spécifiés
p SearchPresence - Filtres de présence uniquement
c Compare - Comparer des attributs
m Make - Créer des attributs sous une nouvelle entrée sous cette entrée

Permissions que s'appliquent aux entrées:
a Add - Ajouter une entrée sous cette entrée
d Delete - Supprimer cette entrée
e Export - Exporter l'entrée et ses subordonnées à un nouvel emplacement
i Import - Importer une entrée et ses subordonnées sous cette entrée depuis un autre emplacement
n RenameDN - Renommer un DN de l'entrée
b BrowseDN - Parcourir un DN de l'entrée
v ViewEntry - Une permission de lire au niveau de l'entrée
t ReturnDN - Permet au DN de l'entrée d'être inclus dans le résultat de l'opération.
u Unveil - Permission discloseOnError
g GetEffectiveRights - permet de lire les Permissions effectives

Attributs

   Un attribut décrit un nom d'attribut sous la forme d'un OID pour cet ‹attr›. Si l'OID réfère à un attribut non définis dans le schéma du serveur, le serveur devrait reporter une erreur. L'utilisation de "[entry]" ou "[all]" aide à focaliser sur les permissions de l'entrée ou de l'attribut facilement.

   "[entry]" signifie que les permissions s'appliquent à tout l'objet. Peut être utilisé par exemple pour supprimer ou ajouter un objet. Quand utilisé dans un subtreeACI, les permissions spécifiées s'appliquent à chaque entrée dans le subtree.

   "[all]" signifie que le jeu de permissions d'applique à tous les attributs de l'entrée. Quand utilisé dans un subtreeACI, "[all]" s'applique à tous les attributs de chaque entrée dans le subtree. Si le mot clé "[all]" et un autre attribut sont spécifiés dans une ACI, le jeu de permission de plus spécifique pour l'attribut écrase le jeu de permission le moins spécifique pour "[all]".

Sujets et authentification associé

Les sujets suivants sont définis et doivent être supportés:
- authzId
- group, définis comme DN d'une entrée groupOfNames ou groupOfUniqueNames
- role, affirme la position de l'organisation d'un sujet et le droit d'un sujet à effectuer les opérations nécessaires à cette position dans l'organisation. Cette implémentation définis comment l'association entrée un authorization id et le dn du role est faite
- subtree, définis comme DN d'un nœud non-terminal dans le DIT
- ipAddress, au format texte IPv6
- dnsName, un nom de domaine ou un nom de domaine wildcard
- public, définis comme accès publique
- this, définis comme l'utilisateur dont le nom match l'entrée accédé

   D'autres parties peuvent définir d'autres sujets. Il est de la responsabilité de ces parties de fournir la définition. Ajouter de nouveaux sujets peut inhiber d'interopérabilité.

   Un sujet peut être qualifié par le niveau d'authentification requis pour accéder à un attribut ou une entrée donnée. authnLevel définis le niveau d'authentification minimum du demandeur requis pour un ACI donné. Les niveaux d'authentification définis, dans l'ordre croissants d'authentification sont:

none Aucun nom et aucun mot de passe, ou un nom mais pas de mot de passe.
weak Les mécanismes d'authentification qui sont considéré vulnérables aux attaques passives et actives. Ex: l'authentification simple.
limited Les mécanismes d'authentification qui sont protégés contre les attaques passives mais pas les attaques actives. Ex: DIGEST-MD5
strong Les mécanismes d'authentification qui sont protégés contre les attaques passives et actives. Ex: Kerberos.

   Le authnLevel s'applique à un sujet comme suit:

- Si l'ACI est donné, authnLevel s'applique si le sujet est authentifié à ce niveau ou plus
- Si l'ACI est refusé, authnLevel s'applique à ce sujet s'il est authentifié à ce niveau et à tous les autres sujets authentifiés avec les niveaux inférieurs.

   Le niveau d'authentification est toujours spécifié dans un ACI. Pour grant, celà signifie que l'accès est donné si vous prouvez votre authentification via un mécanisme d'authentification fort, tel que la signature numérique. Pour deny, cela signifie que l'accès est refusé si vous êtes Mr. X et que vous le prouvez avec une signature numérique. Si vous n'êtes pas Mr. X votre accès n'est pas refusé seulement si vous pouvez le prouver avec une signature numérique. En d'autres termes, toute personne qui s'authentifie avec une signature numérique gagne l'accès excepté Mr. X.

   Une catégorisation recommandée des mécanismes d'authentification par niveau peut être offert séparément. Pour chaque mécanisme catégorisé dans les recommandations, les implémentations ne devraient pas assigner un niveau d'authentification supérieur, mais peuvent assigner un niveau d'authentification inférieurs. Pour les mécanismes non couverts par les recommandations, l'implémentation devrait spécifier un niveau conservateur. Les implémentations devraient fournir un moyen pour les administrateurs de désactiver et/ou abaisser le niveau d'authentification associé avec un mécanisme.

   2 sujets intéressant non explicitement inclus, mais peuvent être composés en utilisant le sujet et authnLevel associé avec un mécanisme.

anonymous authnLevel=none + anySubject(public)
authenticated authnLevel=weak + anySubject(public)

Décision de contrôle d'accès

   Le but ultime du modèle de contrôle d'accès est de définir la manière dans laquel un serveur LDAP détermine une décision de contrôle d'accès pour une opération LDAP donnée. En fait, un demandeur peut nécessiter de nombreuses permissions individuelles pour être autorisé à effectuer l'opération LDAP. Dans cette section on introduit les concepts et algorithmes qui permettent au serveur de décider si un demandeur à une permission individuelle sur un ressource individuelle. Les concepts nécessaires sont premièrement, les paramètres qui doivent être fournis dans l'ordre pour l'algorithme de décision de contrôle d'accès. pour déterminer si l'accès est permis ou non.

   Deuxièmement, on définis précisément quand un ACI donné sera impliqué dans une décision de contrôle d'accès. Troisièmement, ce modèle définis certaines règles de précédence que l'algorithme utilisant lorsqu'il a plus d'un ACI. Finalement, on peut définir l'algorithme de décision de contrôle d'accès qui va déterminer la décision d'accès.

Les paramètres de l'algorithme

   L'algorithme de décision répond à la question "est-ce que le demandeur a la permission spécifiée sur la ressource spécifée?". La ressource peut être une entrée ou un attribut dans une entrée, donc on caractérise la ressource comme ceci: targetEntry, targetAttribute OPTIONAL.

   Le demandeur est identifié principalement par son authorization ID ( qui peut être omis si le demandeur est anonyme ), mais inclus également les informations de contexte sur le demandeur pour qu'il soit représenté comme ceci: authzId OPTIONAL, ipAddress, dnsName, authnLevel.

   La permission est une des permissions définis par le modèle. Donc les paramètres de l'algorithme de décision de contrôle d'accès, que nous appelons les paramètres de décision sont:

ressource (targetEntry, targetAttribute OPTIONAL)
permission permissionParameter
requestorSubject (authzId OPTIONAL, ipAddress, dnsName, authnLevel)

   Si permissionParameter est un paramètre de niveau attribut, alors targetAttribute doit être spécifié; s'il c'est une permission de niveau entrée, targetAttribute est ignoré.

  La sortie est soit "Access Allowed" soit "Access Denied".

Règles d'applicabilité

   Les règles d'applicabilité définissent si une valeur d'ACI donné, ou des portions, s'applique à certains paramètres de décision.

Règles d'applicabilité pour le type de scope

   Ces règles détermine si un ACI spécifique d'applique à la partie targetEntry des paramètres de décision.

- Si l'ACI en question est un entryACI, alors l'ACI s'applique à la ressource si l'ACI est un attribut de l'entrée targetEntry.
- Si l'ACI en question est un subtreeACI, alors l'ACI s'applique à la ressource si targetEntry fait partie du subtree définis par l'entrée contenant l'ACI.

Règles d'applicabilité pour les permissions

- Si permissionParameter est une permission au niveau entrée, alors l'ACI en question s'applique si permissionParameter est mentionné dans la liste des permissions de l'ACI.
- Si permissionParameter est une permission au niveau attribut, alors l'ACI en question s'applique si permissionParameter est mentionné dans la liste des permissions et la liste des attributs de l'ACI s'applique à l'attribut cible par "règle d'applicabilité pour les attributs".
- Noter que pour un ACI qui contient à la fois des listes grant est deny, la liste de permission grant peut ne pas être disponible pou cette règle d'applicabilité (voir plus bas )

Règles d'applicabilité pour les attributs

   Si un attribut n'est pas spécifié comme partie de la ressource, alors cette règle ne s'applique pas. Si un attribut est spécifié, alors l'ACI en question s'applique si sa liste d'attribut est [all] ou si targetAttribute est explicitement mentionné dans la liste d'attribut de l'ACI.

   Dans le cas où targetAttribute est un type d'attribut avec des options (ex: sn;lang-en;lang-uk), il est applicable si la liste d'attribut de l'ACI mentionne une forme moins spécifique de targetAttribute. Par exemple, si la liste contient "sn;lang-en", alors la liste s'applique à l'attribut "sn;lang-en;lang-uk", mais pas l'attribut "sn".

Règles d'applicabilité pour les sujets

   Appelons la portion sujet de l'ACI en question aciSubject. Pour déterminer si aciSubject s'applique au requestorSubject ou applique les règles suivantes:

1. L'ACI en question est un ACI grant. Alors l'ACI s'applique si les portions context et pureSubject de aciSubject s'applique, comme définis dans les règles d'applicabilité pour le contexte et les règles d'applicabilité pour pureSubject.
2. L'ACI en question est un ACI deny. Il y a 3 possibilité:

        a. La partie pureSubject s'applique ( en accord avec les règles d'applicabilité pour pureSubject ). Donc l'ACI s'applique au requestorSubject.
        b. La partie pureSubject ne s'applique pas. Donc l'ACI s'applique à tout requestorSubject avec un authnLevel inférieurs au authnLevel de l'ACI.
        c. Sinon l'ACI ne s'applique pas.

3. L'ACI en question est à la fois grant est deny. Il y à 3 possibilités:

        a. aciSubject s'applique quand évalué comme ACI grant. Les permissions grant et deny de l'ACI sont dispoible pour les règles d'applicabilité pour les attributs et les permissions.
        b. aciSubject ne s'applique pas comme ACI grant mais s'applique comme ACI deny. Les permissions deny de l'ACI sont disponibles pour les règles d'applicabilité pour les attributs et les permissions.
        c. aciSubject ne s'applique pas quand évalué soit à grant ou deny. L'ACI ne s'applique pas au requestorSubject.

   Note: le mode deny avec authnLevel sert d'explication. Dans le cas où un ACI refuse d'accès à un sujet donné avec un authnLevel donné, alors naturellement il va refuser l'accès à ce subjet authentifié à un authnLevel ou supérieur. Similairement, un autre utilisateur authentifié au authnLevel ou supérieur, pour lequel la partie pureSubject ne s'applique pas, ne sera pas refusé les droits par cet ACI.

   Le cas intéressant est un utilisateur authentifié à un niveau inférieur à authnLevel. Pour un tel utilisateur l'ACM considère que cet utilisateur n'a pas été prouvé au système, à un niveau de confiance suffisant, la partie pureSubject ne s'applique pas à lui, donc par sécurité, il se verra refuser les droits.

   Donc si vous refusez l'accès à un authzId particulier avec authnLevel à "none", cet authzId aura l'accès refusé à tous les niveaux d'authentification, mais n'affectera pas d'autre demandeurs. D'une autre manière, si vous refusez l'accès à un authzId particulier avec un authnLevel "strong", celà va refuser l'accès à cet utilisateur quand il est authentifié "fort" et refusera l'accès à tout utilisateur authentifié avec des niveau d'authentification inférieurs.

Règles d'applicabilité pour pureSubject

   Si aciSubject est de type anySubject, alors il s'applique au requestorSubject.

   Si aciSubject est de type machineSubject, alors si ipAddress ou le nom dns de requestorSubject matche l'ipAddress ou la plage de nom dns dans aciSubject, alors l'ACI s'applique au requestorSubject si ce n'est pas un ACI deny ou la partie deny d'un ACI grant/deny. Un ACI grant ne s'applique jamais si le sujet est ipAddress: ou dns:. La note à la fin de "Précédence des sujets dans un scope" explique le raisonnement derrière cette règle.

Règles d'applicabilité pour le contexte

   Le contexte d'un aciSubject s'applique au requestorSubject si authnLevel du requestorSubject est supérieur ou égal au authLevel spécifié dans la partie contexte de aciSubject.

Règles d'applicabilité pour idBasedSubject

   si idBasedSubject est de type thisSubject, alors il s'applique au requestorSubject si authzId du requestorSubject est de type "dn" et est égal au DN de la ressource.

   Si idBasedSubject est de type oneSubject, alors il s'applique au requestorSubject si authzId du requestorSubject est égal au authzId spécifié dans aciSubject.

   Si idBasedSubject est de type setOfSubjects, alors il s'applique au requestorSubject si authzId du requestorSubject est définis dans le set spécifié dans aciSubject ( ex: est dans ce groupe, rôle ou subtree ). Le "Précédence des sujets dans un scope" inclus les règles pour déterminer le membership dans un setOfSubjects.

Règles de précédence

   Les règles de précédences permetten à l'algorithme de décision de contrôle d'accès de déterminer quelles valeurs d'ACI ont précédence sur les autres.

Précédence des type de scope

1. Entry
2. Subtree

Précédence de position dans le DIT

   Pour un DN sujet donné (incluant le niveau d'authentification) et un DN cible, subtreeACI plus bas dans l'arborescence prend précédence sur ceux plus haut.

Précédence de sujets dans un scope

1. ipAddress ou dns dans un ACI deny pour la partie deny d'un ACI grant/deny
2. authzId dn ( authzId-dn: ) ou authzId userid ( authzId-u: )
3. this
4. role

           Si le DN d'un rôle ou d'un groupe apparaît dans un rôle (ex: qui apparaît comme valeur de roleOccupant dans un organizationalRole), il est étendu récursivement. Pour déterminer la précédence, la collection de noms résultante de l'expansion est considéré venir d'un rôle sans regarder la source originale.

5. group

           Si le DN d'un rôle ou d'un groupe apparaît dans un groupe, il est étendu récursivement. Pour déterminer la précédence, la collection de noms résultante de l'expansion est considéré venir d'un groupe sans regarder la source originale.

6. subtree

           Les subtrees peuvent contenir les groupes et/ou des rôles. Ils peuvent être récursivement étendus. Pour déterminer la précédence, les membres des groupes ou occupants de rôles qui s'appliquent parce que le groupe ou le rôle est contenus dans un subtree sont considérés venir du subtree sans regarder la source originale.

7. public

           La précédence de idAddress et des noms dns sont traités spécialement, et dépendent du type d'ACI. Typiquement les situations sont:

                - Si une ACL dit d'autoriser sur la base de l'adresse IP mais refuse sur la base de certains autres attributs, alors, la méthode qu'on veut est "deny". ex: l'utilisateur est refusé, sans regarder où il réside.
                - Si une ACL des de refuser sur la base d'adresse IP mais autorise sur la base d'autres attributs, la méthode qu'on veut est également "deny". ex: L'utilisateur est accepté, mais pas d'où il réside.

   En plus, un grant à un ipAddress sans autre ACI applicable est très dangereux d'un point de vue sécuritaire, vu que cela donne accès a tout utilisateur qui a accès à cet ordinateur avec cette adresse donnée. Ainsi les sujets ipAddress et dns peuvent être utilisés seulement pour refuser les permissions, pas les accepter.

Spécifications de précédence d'attribut

   Les contrôles d'accès spécifiant les attributs "[all]" ont une précédence plus faible que les listes spécifiques.

Précédence de grant/deny

   Deny prend précédence sur grant.

Default

   Deny est le défaut quand il n'y a pas d'information de contrôle d'accès ou quand l'évaluation des informations de contrôle d'accès ne fournis aucun résultat qui autorise d'accès.

Algorithme de décision de contrôle d'accès

   L'algorithme prend en entrée les paramètres de décision définis plus haut et produit une décision grant ou deny. Dans le cas où on est intéressé dans le jeu de permission pour un jeu d'entrée et d'attributs (comme dans le cas de l'évaluation des droits effectifs), alors on doit appliquer l'algorithme pour chaque entrée/attribut et paire de permission qui nous intéresse. Naturellement les implémenteurs sont libre d'implémenter un algorithme qui produis la même décision sur une entrée et les valeurs d'ACI dans les DIT.

   L'algorithme a 2 phases. D'abord, toutes les valeurs d'ACI potentiellement applicable sont triés en une liste ordonnée de jeu de valeurs d'ACI de la même précédence. Puis cette liste est scannée dans l'ordre pour trouver le jeu d'ACI qui va déterminer la décision d'accès.

   Phase 1: Ordonner les valeurs d'ACI potentiellement applicables

1. Détermine toutes les valeurs entryACI et subtreeACI qui s'appliquent au targetEntry, en accord avec les règles d'applicabilité pour les type de scope.
2. Trie ces ACI en une liste de jeux d'ACI de précédence égales, en accord avec les règles de précédence du type de scope. et la précédence de position dans le DIT.
3. Détermine quelles valeurs d'ACI collectée de l'étape 1 s'appliquent au requestorSubject en utilisant les règles d'applicabilité pour les sujets. Toutes les valeurs d'ACI qui ne s'appliquent pas à ce sujet sont éliminés.
4. La liste de jeux est triée en accord avec le type de sujet depuis les règles de précédence des sujets dans un scope.
5. Maintenant on split la liste en 2 listes conservant le même ordre relatif, une liste qui réfère au permissions au niveau entrée, et l'autre au niveau attributs.
6. Chaque jeu dans la liste de niveau attribut et ensuite divisée en une liste de jeux de précédence égale en accord avec la spécification de précédence d'attribut.

   Note: à ce point on a 2 listes de jeux de valeurs d'ACI. Cette liste a été triée en accord avec les scope, la position, le sujet et ( pour la liste au niveau attribut ) les règles de spécification de précédence d'attribut.

   Phase2: Scanne les liste pour déterminer la décision d'accès:

   1. Si permissionParameter est une permission au niveau entrée ( donc le champ optionnel targetAttribute n'est pas spécifié ), scanne la liste de niveau entrée dans l'ordre. Le premier jeu dans la liste qui contient un ACI qui s'applique au permissionParameter détermine la décision d'accès si un ACI dans le jeu autorise permissionParameter et aucun autre le refuse, alors l'accès est donné, sinon l'accès est refusé.

   2. Si permissionParameter est une permission au niveau attribut, scanne la liste des jeux au niveau attribut dans l'ordre. Le premier jeu dans la liste qui contient un ACI qui s'applique au permissionParameter et s'applique à targetAttribute détermine la décision d'accès. Si un ACI dans le jeu autorise permissionParameter et aucun autre le refuse, l'accès est donné, sinon l'accès est refusé.

Exemple de précédence/héritage de décision d'accès

L'exemple dans cette section réfère à l'arborescence suivante:
___________dc=com
_____________|
____+--------+---------------+
____|________________________|
dc=tivoli__________________dc=sun
____|________________________|
_cn=ellen__________________cn=rob

   L'ACI à dc=com:

1. subtreeACI:grant:rsc#[all]#authnLevel:none:public:
2. subtreeACI:deny:rsc#userPassword,subtreeACI,entryACI,salary#authnLevel:none:public:
3. subtreeACI:grant:bvt#[entry]#authnLevel:none:public:
4. subtreeACI:grant:rscmow#[all]#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com
5. subtreeACI:grant:bvtugeinad#[entry]#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com

   L'ACI à dc=tivoli,dc=com:

6. subtreeACI:grant:rsc;deny:mow#[all]#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com
7. subtreeACI:deny:einad#[entry]#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com

   L'ACI à cn=ellen,dc=tivoli,dc=com:

8. entryACI:grant:wo#[all]#authnLevel:strong:authz-ID-dn:cn=ellen,dc=tivoli,dc=com
9. entryACI:deny:wo#entryACI,subtreeACI,salary#authnLevel:strong:authz-ID-dn:cn=ellen,dc=tivoli,dc=com

Exemple 1

subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, strong):
resource: ("cn=ellen,dc=tivoli,dc=com", salary)
permission: "w"

Phase 1: Touver tous les ACI applicables dans l'applicabilité des types de scope: {1, 2, 3, 4, 5, 6, 7, 8, 9}
Trier par précédence de type de scope et précédence de position dans le DIT: {8, 9}, {6, 7}, {1, 2, 3, 4, 5}
Détermine quels ACI sont applicable basé sur le sujet: {6, 7}, {1, 2, 3, 4, 5}
Trier par précédence de sujets dans le scope: {6, 7}, {4, 5}, {1, 2, 3}
Séparer les permissions applicables à l'entrée et ceux applicable aux attributs: Entry: {7}, {5}, {3}, Attr: {6}, {4}, {1, 2}
Trier les permissions applicable aux attributs par précédence de spécification d'attribut: Entry: {7}, {5}, {3}, Attr: {6}, {4}, {2}, {1}
Phase 2: Vu que "w" est une permission attribut, recherche dans la liste Attr l'ACI 6 dans la première sous-liste mentionnant "w" et salary (via [all]) pour définir l'accès, qui est deny.

Exemple 2

subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
resource: ("cn=ellen,dc=tivoli,dc=com", salary)
permission: "w"

Phase 1: Les ACI sont ordonnés dans les jeux suivant sont les sujets matchent le sujet: Entry: {7}, {3}, Attr: {6}, {2}, {1}
Phase 2: Pour l'ACI 6 dans le premier jeu, qui matchait le sujet par la portion deny et limitée à ‹ strong, les permissions disponibles sont "mow". Donc, cet ACI applique à "w" et salary (via [all]) et l'accès est deny.

Exemple 3

subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
resource: ("cn=ellen,dc=tivoli,dc=com", salary)
permission: "r"

Phase 1: Les ACI sont ordonnés dans les jeux suivant sont les sujets matchent le sujet: Entry: {7}, {3}, Attr: {6}, {2}, {1}
Phase 2: Vu que la portion grant de l'ACI 6 n'est pas active, le premier jeu qui contient un ACI qui s'applique à "r" et salary est {2}. Comme 2 deny l'accès, l'accès est refusé.

Exemple 4

subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
resource: ("cn=ellen,dc=tivoli,dc=com", cn)
permission: "r"

Phase 1: Les ACI sont ordonnés dans les jeux suivant sont les sujets matchent le sujet: Entry: {7}, {3}, Attr: {6}, {2}, {1}
Phase 2: Vu que la portion grant de l'ACI 6 n'est pas active, le premier jeu qui contient un ACI qui s'applique à "r" et cn est {1}. Vu que 1 grant l'accès, l'accès est donné.

Permissions requises pour chaque opération LDAP

   Cette section définis les permissions requises pour chaque opération LDAP. Même si ces requis sont satisfaits, le serveur peut refuser l'opération dû à d'autres considérations de sécurité spécifique à l'implémentation. Par exemple, un serveur peut refuser de modifier une entrée parce que la base où réside l'entrée est en lecture seule. Un autre exemple peut être qui le contrôle d'accès LDAP a été spécifié sur l'attribut userPassword, mais un serveur peut refuser les modifications dû à certaines gouvernances de stratégie d'accès spécifique aux mots de passe.

   Ici, on spécifie les droits requis par un utilisateur en effectuant un opération LDAP en termes de permissions LDAP spécifiés plus haut. Rappelons que les permissions "a, d, e, i, n, b, v, t, u" s'appliquent aux entrées et les permissions "r, s, p, w, o, c, m, g" s'appliquent aux attributs dans les entrées.

   Les permissions requises pour les opérations étendues LDAP et les contrôles LDAP devraient être définis avec leurs spécification. Ces requis peuvent être définis en terme de ce modèle, par exemple en nécessitant une des permissions existante sur certaines entrées ou attributs particulier. Cette version du modèle de contrôle d'accès n'offre pas de mécanisme pour étendre le jeu de permissions ou la syntaxe d'ACI pour convenir aux opérations étendues ou aux contrôles.

   Pour la suite, on assume que l'authorization ID de l'utilisateur faisant l'opération est authzId.

Opération Bind

   Ce modèle ne nécessite pas de permission pour permettre de traiter une opération bind.
Rappelons que les paramètres de l'opération search sont:
SearchRequest ::= [APPLICATION 3] SEQUENCE {
    baseObject LDAPDN,
    scope ENUMERATED {
        baseObject (0),
        singleLevel (1),
        wholeSubtree (2) },
    derefAliases ENUMERATED {
        neverDerefAliases (0),
        derefInSearching (1),
        derefFindingBaseObj (2),
        derefAlways (3) },
    sizeLimit INTEGER (0 .. maxInt),
    timeLimit INTEGER (0 .. maxInt),
    typesOnly BOOLEAN,
    filter Filter,
    attributes AttributeDescriptionList }

   Supposons qu'un serveur traite une recherche de l'utilisateur authzId avec les paramètres comme précédent et traite l'entrée avec le dn candidateDN pour décider s'il peut le retourner ou non, alors les permissions requises par authzId qui doivent être évaluées sont les suivantes:

1. Permission "b" sur l'entrée candidateDN si l'entrée est dans le scope de recherche mais n'est pas l'entrée de base. Si cette permission n'est pas donnée alors le dn candidateDN ne doit pas être retourné ni un type d'attribut ni une valeur d'attribut de cette entrée. Note: la permission b est incluse pour permettre différents droits de découverte et de parcours à être assigné à différentes classes d'utilisateurs.
2. Permission "v" sur l'entrée candidateDN. Si cette permission n'est pas donnée alors de dn candidateDN ne doit pas être retourné, ni un type d'attribut ni une valeur d'attribut de cette entrée. La permission v est une permission de lecture au niveau de l'entrée.
3. Permission "p" ou "s" pour chaque attribut apparaissant dans un filtre de recherche de test de présence. "s" est requis sur les attributs apparaissant dans les tests de non-présence ( equalityMatch, substrings, greaterOrEqual, lessOrEqual, present, approxMatch, extensibleMatch). La déclaration plus haut couvre le cas où les attributs sont évalués dans un extensibleMatch qui apparaît dans le filtre. Dans le cas où le champ dnAttributes de l'extensibleMatch est vrai il ne requière pas de vérification d'accès aux attributs du dn vu que l'accès est donné par la permission "v".

           S'il y a un attribut dans un élément de filtre pour lequel la permission n'est pas donnée alors cet élément de filtre s'évalue à "Undefined" du three-valued-logic de X.511. Note: la motivation pour la permission "p" est que si vous avez un filtre de droits sur un attribut alors dans certains cas il pourrait être opérationnellement le même que la permission read. par ex. vous pouvez déterminer rapidement la valeur de l'attribut, et cela n'est pas forcément désirable. Par exemple, si le type de l'attribut est un entier alors avec les permissions du filtre vous pouvez rapidement déterminer la valeur en faisant une séquence de recherche en utilisant "›" et "‹". Alors qu'avec la capacité de test de présence, vous pouvez empêcher ce genre de recherche, mais vous être capable de tester la présence de cet attribut.

4. Permission "r" pour chaque attribut dans la liste d'attribut AttributeDescriptionList ( ou tous les attributs dans l'entrée candidateDN si AttributeDescriptionList est * ) dont le type et/ou la valeur sera retournée. Note: la présence d'un attribut dans une entrée n'est jamais volontaire par le serveur si l'autorisation "r" lui est accordée, si un utilisateur peut déduire la présence d'un attribut avec "s" ou la permission "p" en utilisant un test de présence sur cet attribut dans le filtre de recherche. Note: bien que "r" et "s" sont typiquement donnés aux attributs on conserve les 2 permissions vu qu'il y a des cas où le distinction est utile. Une recherche de téléphone inversée est un exemple d'accès "r" mais pas "s".
5. Permission "t" à l'entrée candidateDN. Si cette permission n'est pas donnée alors le dn candidateDN ne doit pas être retourné. Si le serveur connais un alias pour l'entrée, cet alias peut être retourné à la place. Si aucun alias n'est disponible alors l'entrée candidateDN doit être omise du résultat de recherche.
6. Disclose on error pour l'opération de recherche. S'il n'y a pas d'entrée dans le scope de recherche qui satisfait l'item 1 (voir les droit sur l'entrée candidate) et l'item 2 (permission read sur l'entrée) alors la permission "u" sur l'entrée de base doit être évaluée. Si "u" n'est pas donné alors l'opération doit échouer avec un "no such object error" et le matchedDN de LDAPResult doit être définis à "". Si "u" est donné au baseObject alors le jeu vide de résultat est retourné.

Protéger le nommage des attributs du DN

   Protéger le nommage d'attribut dans le dn d'une entrée présente un problème pour le contrôle d'accès. Le problème est que si l'accès est donné au dn d'une entrée donnée, alors via le nommage d'attribut que ce dn contient, l'accès est également donné aux valeurs d'attribut dans les autres entrées. En plus, la connaissance de l'existence les entrées parent d'une entrée donnée est également fournie par le dn de l'entrée.

Opération modify

Rappelons que les paramètres de l'opération Modify sont:
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
    object LDAPDN,
    modification SEQUENCE OF SEQUENCE {
        operation ENUMERATED {
            add (0),
            delete (1),
            replace (2) },
        modification AttributeTypeAndValues } }
    
AttributeTypeAndValues ::= SEQUENCE {
    type AttributeDescription,
    vals SET OF AttributeValue }

   Les permissions requises par authzId qui doivent être évaluées sont:

1. Permissions "w" pour chaque attribut à ajouter à l'object
2. Permission "o" pour chaque attribut pour lequel une valeur est supprimée de l'objet
3. permission "o" et "w" à chaque attribut remplacé dans l'objet.

Opération Add

Rappelons que les paramètres de l'opération Add sont:
AddRequest ::= [APPLICATION 8] SEQUENCE {
    entry LDAPDN,
    attributes AttributeList }
    
AttributeList ::= SEQUENCE OF SEQUENCE {
    type AttributeDescription,
    vals SET OF AttributeValue }

1. Permission "a" au parent de l'entrée
2. Permission "m" au parent de l'entrée pour chaque attribut à ajouter à l'entrée

Opération Delete

Rappelons que les paramètres de l'opération Delete sont:
DelRequest ::= [APPLICATION 10] LDAPDN

1. Permission "d" sur l'entrée

   Note: on pourrait ajouter la permission "o" pour autoriser l'opération, mais l'expérience a montré que cette permission additionnelle n'est pas aussi utile que ça, et X.500 ne nécessite que la permission "d"

Opération Modify DN

Rappelons que les paramètres de l'opération Modify DN sont:
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
    entry LDAPDN,
    newrdn RelativeLDAPDN,
    deleteoldrdn BOOLEAN,
    newSuperior [0] LDAPDN OPTIONAL }

   Les variantes de l'opération ModifyDN sont listés ci-dessous. Les combinaisons des permissions write, obliterate, import, export et renameDN sont nécessaire pour chaque variante.

1. Renommer une entrée en déplaçant le flag RDN entrée 2 valeurs d'attributs existant, sans altérer de valeur d'attribut. Les permissions nécessaires sont renameDN.
2. Renommer une entrée en ajoutant une nouvelle valeur d'attribut, les permissions nécessaires sont renameDN et write
3. Renommer une entrée en utilisant une valeur d'attribut existant et en supprimant la valeur d'attribut courante. Les permissions nécessaires sont renameDN, write et obliterate.
5. Renommer une entrée en ajoutant une nouvelle valeur d'attribut et en supprimant la valeur courante. Les permissions nécessaires sont renameDN, write et obliterate.
5. Déplacer une entrée à un nouvel endroit dans le DIT, en gardant son RDN. Les permissions nécessaires sont import et export
6. Déplacer une entrée à un nouvel endroit couplé avec 1. Les permissions nécessaires sont import, export et renameDN
7. Déplacer une entrée couplé avec 2. Les permissions nécessaires sont import, export, renameDN, et write.
8. Déplacer une entrée couplé avec 3. Les permissions nécessaires sont import, export, renameDN, et obliterate.
9. Déplacer une entrée couplé avec 4. Les permissions nécessaires sont import, export, renameDN, write et obliterate.

   Pour un cas donné, si les permissions requises sont données, alors l'opération est permise par le modèle de contrôle d'accès. Si, pour un cas donné, les permissions ne sont pas données, alors l'opération doit échouer. Si le contrôle d'accès échoue à cause d'une permission d'attribut ou sur l'entrée manquante, alors si "u" est donné à l'entrée, le code d'erreur et matchedDN peuvent être retournés. Si "u" n'est pas donné à l'entrée, alors nosuchObject doit être retourné et matchedDN définis à "". Une logique similaire s'applique si l'échec du contrôle d'accès est dûe a une permission manquante sur newSuperior.

Opération Compare

Rappelons que les paramètres de l'opération Compare sont:
CompareRequest ::= [APPLICATION 14] SEQUENCE {
    entry LDAPDN,
    ava AttributeValueAssertion }

1. Permission "c" sur l'attribut dans l'entrée sur lequel la comparaison est faite.

Opération Abandon

Rappelons que les paramètres de l'opération Abandon sont:
AbandonRequest ::= [APPLICATION 16] MessageID

   authzId a toujours les droits d'envoyer l'opération Abandon pour une opération précédemment initiée.

Opération Extended

Rappelons que les paramètres de l'opération Exended sont:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
    requestName [0] LDAPOID,
    requestValue [1] OCTET STRING OPTIONAL }

   L'accès requis pour une opération étendue est au delà du scope de ce document. L'accès requis sera normalement définis par l'implémenteur de la requête étendue.

Permissions requises pour manipuler les alias et les références

   L'utilisation d'alias et le réferrants font partie de LDAPv3. Cependant, ils ne sont pas particulièrement bien définis. Les objets et attributs alias sont définis dans la rfc2256 comme dérivé de X.500, mais ne définis pas leur sémantique. X.500 définis les sémantiques des alias avec le respect du contrôle d'accès. On définis ce principe dans LDAPv3 basé sur X.511. Les référrants sont définis dans X.500, mais ne définis par leur sémantique avec le respect des contrôles d'accès.

ACI Distribution

   Actuellement il n'y a pas de standard LDAP définissant comment distribuer les données d'annuaire entre les serveur LDAP. En conséquence ce modèle ne peut pas spécifier pleinement le fonctionnement du modèle de contrôle d'accès dans un environnement distribué. Le cas de distribution via des référants est traité plus bas. Dans le cas du chaînage ( où un serveur LDAP renvoie une requête à un autre pour le compte d'un client ) alors le fonctionnement du modèle de contrôle d'accès est spécifique à ce serveur. Similairement, la manière dont un serveur détermine si le chaînage d'une opération est permise est spécifique au serveur. Par exemple, l'implémentation peut choisir de regarder le contexte de nommage local et le contexte de nommage subordonné distant comme aire de contrôle d'accès spécifique séparé, ou peut regarder le DIT comme une aire spécifique de contrôle d'accès et d'implémenter les mécanismes pour propager les aci entre les 2 serveurs. Ceci est hors du scope de ce modèle.

Alias

   Il y a 2 choses pour protéger avec les alias: le vrai nom des objets aliasés et l'emplacement du serveur le maintenant. Si le dé-référencement d'alias est requis dans le processus de localisation d'une entrée cible, aucune permissions spécifique n'est nécessaire pour le dé-référencement de l'alias. Le contrôle d'accès est forcé sur l'objet pointé par l'alias. Si le dé-référencement d'alias résulte en un continuationReference (ex: depuis une opération de recherche), alors la permission browse est requise sur l'alias et la permission read est requise sur l'attribut.

Référants

   Si un référant doit être suivi, aucune permission spécifique n'est nécessaire pour le client ldap pour suivre le référant. Le contrôle d'accès est forcé sur l'objet référencé. Si un référant est retourné, alors browse est requis sur l'entrée et read est requis sur l'attribut contenant le référant. Si le serveur implémente un référant par défaut, il n'y a pas de permission spécial.

Contrôler l'accès aux ACI

   Les attributs entryACI et subtreeACI sont utilisé pour spécifier le contrôle pour qui a la permission de définir/changer l'ACI. Les attributs entryACI et subtreeACI sont juste un autre attribut décrit avec un jeu de droits et permissions, et des sujets comme valeur de entryACI et subtreeACI. Si la stratégie pour contrôler entryACI et subtreeACI n'est pas spécifiée pour les objets dans l'arborescence, le mode est définis par l'implémentation. Par exemple, si aucun objet dans l'arborescence ne définis l'accès pour entryACI/subtreeACI dans les attributs entryACI/subtreeACI, alors le serveur pourrai simplement affirmer que le root DN est considéré comme propriétaire des stratégies pour tous les objets.

Exemples d'ACI

   Noter que dans les exemples, la forme "OID.‹attrname›" réfère à l'OID sous la forme décimale pour l'attribut ‹attrname›. Cette notation est utilisée uniquement pour les exemples.

Définitions d'attribut

   L'exemple suivant montre l'accès requis pour contrôler l'accès aux attributs entryACI et subtreeACI. Le premier exemple montre le contrôle sur une entrée individuelle et ses attributs. Le second exemple montre le contrôle d'accès sur un subtree. Le authnLevel est définis pour être raisonnablement sécurisé.

entryACI: grant:rwo#OID.entryACI#authnLevel:limited:role:cn=aciAdmin
subtreeACI: grant:rwo#OID.subtreeACI#authnLevel:limited:role:cn=aciAdmin

   L'exemple suivant montre un attribut subtreeACI où un groupe "cn=DeptXYZ,c=US" a les permissions read,search et compare sur l'attribut attr1. Les permissions s'appliquent à tout le subtree sous le nœud contenant l'aci.

subtreeACI: grant;rsc#OID.attr1#authnLevel:weak:group:cn=Dept XYZ,c=US

   L'exemple suivant montre un attribut ACI où un rôle "cn=SysAdmins,o=Company" a les permissions browseDN, viewEntry, et returnDN pour les objets sous ce nœud. Le rôle a également les droits read, search, et compare sur l'attribut attr2 et read, search, compare, write et obliterate sur attr3.

subtreeACI: grant:bvt#[entry]#authnLevel:weak:role:cn=SysAdmins,o=Company
subtreeACI: grant:rsc#OID.attr2#authnLevel:weak:role:cn=SysAdmins,o=Company
subtreeACI: grant:rscwo#OID.attr3#authnLevel:weak:role:cn=SysAdmins,o=Company

Modifier les valeurs entryACI et subtreeACI

   Modify-Replace fonctionne comme définis dans l'opération ldap modify. Si la valeur d'attribut n'existe pas, il créé la valeur. Si l'attribut existe, il remplace la valeur. Si les valeurs entryACI/subtreeACI sont remplacées, toutes les valeurs entryACI/subtreeACI sont remplacées. Modifier les attributs entryACI/subtreeACI nécessite d'avoir les permissions "w" et "o" sur entryACI/subtreeACI. Les exemples dans cette section assument que vous avez les accès pour contrôler entryACI/subtreeACI.

Un subtreeACI donnée pour une entrée:
subtreeACI: deny:rw#[all]#authnLevel:weak:group:cn=Dept ABC
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
Effectue le changement suivant:
dn: cn=someEntry
changetype: modify
replace: subtreeACI
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN
L'ACI résultante est:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN
Les valeurs subtreeACI pour Dept XYZ et ABC sont perdues durant le remplacement

   Durant un ldapmodify-add, si l'ACI n'existe pas, créé l'ACI avec les valeurs spécifique entryACI/subtreeACI. Si l'ACI existe, ajoute les valeurs spécifiées à l'entryACI/subtreeACI donné.

Par exemple un ACI donné:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
Avec une modification:
dn: cn=someEntry
changetype: modify
add: subtreeACI
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
Va donner un ACI multi-valué:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
Pour supprimer une valeur d'ACI particulière, utiliser la syntaxe ldapmodify-delete. Un ACI donné de:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
dn: cn = some Entry
changetype: modify
delete: subtreeACI
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
Va donner un ACI restant:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
Avec l'opération ldapmodify-delete, toute l'acl peut être supprimée en spécifiant:
dn: cn = some Entry
changetype: modify
delete: entryACI
dn: cn = some Entry
changetype: modify
delete: subtreeACI

   Dans ce cas, l'entrée va hériter son ACI d'autres nœuds dans l'arborescence. Similairement, si toutes les valeurs d'entryACI et subtreeACI sont supprimées, alors les informations de contrôle d'accès pour cette entrée sont définis par le modèle d'héritage.

Évaluation

   Ces exemples assument que les entrées ACI listées dans chaque exemple sont les seuls ACI qui s'appliquent à l'entrée en question. On assume cn=jsmith est membre du groupe cn=G1 et du groupe cn=G2.

Exemple 1:
dn: o=XYZ, c=US
subtreeACI: grant:r#attr2#authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
subtreeACI: grant:w#attr2#authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US
cn=jsmith a les droits rw sur attr2; l'ACI est combinées parce que les sujets (groupes) ont la même précédence.
Exemple 2:
dn: o=XYZ, c=US
subtreeACI: grant:rw#OID.attr3#authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
subtreeACI: deny:w#OID.attr3#authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US
cn=jsmith a l'accès read sur attr3; write est refusé puisque deny a précédence sur grant.
Exemple 3:
dn: o=XYZ, c=US
subtreeACI: grant:m#OID.attr5#authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
SubtreeACI: grant:m#OID.cn#authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
subtreeACI: grant:m#OID.sn#authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
subtreeACI: grant:a#[entry]#authnLevel:weak:authzID-dn:#cn=jsmith,o=ABC,c=US
cn=jsmith a le droit make sur attr5, cn et sn, et add sur l'entrée qui lui permet de créer un nouvel objet, cn=New,oXYZ,c=US avec des valeurs pour attr5, cn et sn. Cet exemple illustre comment la permission "m" peut être utilisée pour limiter les attributs qui peuvent être créés sur une nouvelle entrée.
Exemple 4:
dn: c=US
subtreeACI: grant:m#[all]#authnLevel:weak:subtree:c=US
dn: o=XYZ, c=US
subtreeACI: grant:a#[entry]#authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
cn=jsmith a le droit make sur tous les attributs et add sur l'entrée. Il y'a suffisamment de permissions pour créer un nouvel objet, cn=New,oXYZ,c=US avec les valeurs pour n'importe quel attribut. Pour les administrateurs qui ne souhaitent par limiter les attributs qui peuvent être créés sur les nouvelles entrées, cet exemple montre comment un simple ldapACI au niveau du domaine résout le problème.
Exemple 5:
dn: dc=com,dc=demo
subtreeACI: grant:rw#description;lang-en#authnLevel:weak:authzID-dn:cn=rvh,dc=att,dc=com
subtreeACI: grant:rw#description;lang-en,description;lang-fr#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Dans cet exemple, cn=rvh,dc=att,dc=com a l'accès "rw" à la langue anglaise de l'attribut Description sur les entrée sous dc=com,dc=demo. cn=rob,dc=sun,dc=com a les droits "rw" sur les versions française et anglaise de l'attribut Description. L'exemple démontre que "Attribute Descriptions", pas seulement "Attribute Types", peut être utilisé dans le champ attr d'un ACI.

ModDN

   Il y a de nombreuses actions différentes qui peuvent se produire quand la commande modDN est utilisée. La suite illustre les permissions nécessaires pour exécuter chaque scénario. Pour tous les exemples, on assume que le rôle cn=Admins fonctionne avec l'entrée suivante:

dn: cn=personA,o=Company
cn: personA
cn: FirstName
sn: LastName
objectclass: person

Exemples 1:
Effectuer un modRDN uniquement, utilisant une valeur d'attribut existante. Dans ce cas, on effectue un modRDN et on renomme cn=personA,o=Company en cn=FirstName,o=Company. La valeur d'entryACI pour cette entrée doit donner la permission rename sur l'entrée.
entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
Exemple2:
Effectuer un modRDN et ajouter une nouvelle valeur d'attribut. Dans ce cas on renomme cn=personA,o=Company en cn=newFirstName,o=Company. La valeur entryACI doit donner la permission rename sur l'entrée et w sur l'attribut cn.
entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:w#cn#authnLevel:weak:role:cn=Admin
Exemple 3:
Effectuer un modRDN, en utilisant un attribut existant, mais en supprimant l'ancienne valeur RDN. On renomme cn=personA,o=Company en cn=FirstName,o=Company avec le flag deleteOldRdn à true. On doit avoir les permissions de renommer l'entrée, et de supprimer une valeur cn
entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:o#OID.cn#authnLevel:weak:role:cn=Admin
Exemple 4:
Effectuer un modRDN, en utilisant une nouvelle valeur d'attribut, et en supprimant l'ancienne valeur. dans ce cas on renomme cn=personA,o=Company en cn=newFirstName,o=Company avec le flag deleteOldRdn. On doit avoir les permissions de renommer l'entrée, et de supprimer et écrire l'attribut cn
entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:w,o#OID.cn#authnLevel:weak:role:cn=Admin
Exemple 5:
On veut changer l'emplacement de l'entrée et conserver le même RDN. Dans ce cas, on déplace cn=personA,o=Company vers cn=personA,o=CompanyB. On doit avoir les permissions d'export sur l'entrée originale, et import dur le nouvel objet supérieur.
l'entryACI de cn=personA,o=Company est:
entryACI: grant:e#[entry]#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
Exemple 6:
On veut changer l'emplacement de l'entrée et changer la valeur RDN à une valeur existante. Dans ce cas on déplace cn=personA,o=Company vers cn=FirstName,o=CompanyB. On doit avoir les premissions rename et export sur l'objet, et import sur le nouvel objet supérieur.
l'entryACI de cn=personA,o=Company est:
entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
Exemple 7:
Changer l'emplacement de l'entrée et changer le RDN avec une nouvelle valeur. Dans ce cas, on déplace cn=personA,o=Company vers cn=newFirstName,o=CompanyB. On doit avoir les droits rename et export sur l'entrée originale, write sur cn et import sur le nouveau supérieur.
l'entryACI de cn=personA,o=Company est:
entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:w#OID.cn#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
Exemple 8:
Changer l'emplacement de l'entrée et changer de RDN avec une valeur existante, en supprimant l'ancienne valeur. Dans ce cas, on déplace cn=personA,o=Company vers cn=FirstName,o=CompanyB. On doit avoir les droits rename et export sur l'entrée originale, delete sur cn et import sur le nouveau supérieur.
l'entryACI de cn=personA,o=Company est:
entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:o#cn#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
Exemple 9:
Changer l'emplacement de l'entrée et changer de RDN avec une nouvelle valeur d'attribut, en supprimant l'ancienne valeur. Dans ce cas, on déplace cn=personA,o=Company vers cn=newFirstName,o=CompanyB. On doit avoir les droits rename et export sur l'objet original, write et delete sur cn, et import sur le nouveau supérieur
l'entryACI de cn=personA,o=Company est:
entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:wo#OID.cn#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin

Intéraction entre les ACI

   Ces exemples montrent comment les ACI dans différentes parties de l'arborescence intéragissent. Les exemples avec divers authnLevel sont donnés dans la section suivante.

Les exemples réfèrent à ce fragment de l'arborescence:
__________dc=com
____________|
___+--------+---------------+
___|________________________|
dc=tivoli_________________dc=sun
___|________________________|
cn=ellen__________________cn=rob

Exemple 1: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#[all]#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:grant:r#[all]#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Alors les droits effectifs de cn=rob,dc=sun,dc=com sur tous les attributs de l'objet cn=ellen,dc=tivoli,dc=com sont "rw". L'ACI au niveau de dc=tivoli,dc=com est redondante.
Exemple 2: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:r#[all]# authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:grant:w#OID.uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" sur tous les attributs de l'objet cn=ellen,dc=tivoli,dc=com, et les droits "rw" sur l'uid de ce même objet. Également, cn=rob,dc=sun,dc=com a les droits "r" sur tous les attributs de cn=rob,dc=sun,dc=com
Exemple 3: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#[all]#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:deny:w#[all]#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" (mais pas "w") sur tous les attributs de cn=ellen,dc=tivoli,dc=com et "rw" sur tous les attributs de cn=rob,dc=sun,dc=com.
Exemple 4: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:r#OID.uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:grant:w#OID.sn#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" sur uid et "w" sur sn de cn=ellen,dc=tivoli,dc=com
Exemple 5: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:r#OID.uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À cn=rob,dc=sun,dc=com: entryACI:grant:rw#[all]#authnLevel:weak:this:
Alors cn=rob,dc=sun,dc=com a des droits "rw" sur tous les attributs de cn=rob,dc=sun,dc=com.
Exemple 6: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:deny:w#uid#authnLevel:weak:subtree:dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" sur l'uid de cn=ellen,dc=tivoli,dc=com. En vérifiant la permission "w", dc=tivoli,dc=com est inférieur à dc=com, donc sont subtreeACI a précédence.
Exemple 7: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=com: subtreeACI:deny:w#OID.uid#authnLevel:weak:subtree:dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "rw" sur uid de cn=ellen,dc=tivoli,dc=com. en vérifiant la permission "w", les 2 subtreeACI sont au même niveau dans l'arborescence et le type de sujet dn a précédence sur le type subtree, donc le premier aci a précédence sur le second.
Exemple 8: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak:subtree:dc=sun,dc=com
À dc=com: subtreeACI:deny:w#OID.uid#authnLevel:weak:subtree:dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" sur uid de cn=ellen,dc=tivoli,dc=com. En vérifiant la permission "w", les 2 subtreeACI sont au même niveau et ont le même type de sujet, donc deny a précédence sur grant dans le facteur de décision.
Exemple 9: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak:subtree:dc=sun,dc=com
À dc=com: subtreeACI:deny:w#[all]#authnLevel:weak:subtree:dc=com
Alors cn=rob,dc=sun,dc=com a les droits "rw" sur uid de cn=ellen,dc=tivoli,dc=com. En vérifiant la permission "w", les 2 subtreeACI sont au même niveau et ont le même type de sujet, donc la précédence d'une liste spécifique d'attributs sur [all] est le facteur de décision.

Utilisation de ipAddress dans les ACI

Exemple 1: Si l'ACI est le suivant:
À dc=com: subtreeACI: deny:adeinbvtug#[entry]#authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255
subtreeACI: deny:rwospcm#[all]#authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255
subtreeACI: grant:rscp#[all]#authnLevel:none:public:
subtreeACI: grant:btv#[entry]#authnLevel:none:public:
Alors tout utilisateur n'a de permission s'ils se connectent depuis un réseau 10/. S'ils se connectent depuis un autre réseau, ils auront les permissions "rscp" pour tous les attributs, et "btv" pour toutes les entrées dans dc=com.
Exemple 2: Si l'ACI est le suivant:
À dc=com: subtreeACI: grant:adeinbvtug#[entry]#authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255
subtreeACI: grant:rspwocm#[all]#authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255
Cela n'aura pas d'effet. Alors que cela semble donner un accès total aux utilisateurs dans le réseau 10/, les règles spéciales les idAddress et dns comme sujet les rendes utiles seulement pour les ACI deny. Les effets d'un grant sur une plage réseau mal formé ou un DNS wildcardé peut être très sérieux.
Un Administrateur qui veut vraiment donner un accès total à tout le monde dans 10/ devra spécifier:
À dc=com: subtreeACI: grant:adeinbvtug#[entry]#authnLevel:weak:public:subtreeACI:deny:adeinbvtug#[entry]#authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255,11.0.0.0-255.255.255.255
subtreeACI: grant:rspwocm#[all]#authnLevel:weak:public:
subtreeACI: deny:rspwocm#[all]#authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255,11.0.0.0-255.255.255.255

Utilisation de authnLevel dans les ACI

Exemple 1: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#OID.sn#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:grant:r#OID.sn#authnLevel:limited:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits effectifs "rw" sur l'attribut sn de l'objet cn=ellen,dc=tivoli,dc=com si le bind pour cette session a utilisé une authentification forte. Si le bind a utilisé une authentification limitée, il n'a que le droit "r". Si le bind pour cette session a uilisé une authentification faible, ou aucune authentification, il n'a aucun droit.
Exemple 2: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#sn#authnLevel:limited:subtree:dc=sun,dc=com
À dc=tivoli,dc=com:subtreeACI:grant:c;deny:w#sn#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits effectifs "rc" sur l'attribut sn de l'objet cn=ellen,dc=tivoli,dc=com si le bind était fort. La permission "r" vient du fait que la partie grant du premier ACI s'applique au bind limité et supérieur. La partie deny du 2ème ACI s'applique aux cas où authnLevel est inférieur à "strong", donc il a précédence sur la permission "w" dans le premier ACI.
Exemple 3: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rs#sn#authnLevel:none:public
À dc=com: subtreeACI:grant:w#sn#authnLevel:strong:subtree:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits effectifs "rsw" sur l'attribut sn de l'objet cn=ellen,dc=tivoli,dc=com si le bind a utilisé une authentification forte, et "rs" si le bind a utilisé une autre forme d'authentification. Le grant dans le premier ACI s'applique aux bind au niveau "none" et supérieur.
Exemple 4: Si l'ACI est le suivant:
Au root: subtreeACI:grant:ps#[all]#authnLevel:none:public:subtreeACI:grant:cr#[all]#authnLevel:weak:subtree:
Alors tout utilisateur (incluant les anonymes) ont les droits "ps" sur toutes les entrées sur le serveur, et tout utilisateur avec un ID sur le serveur dont le bind a utilisé weak ou mieux a les permissions "pscr".
Exemple 5: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#[all]#authnLevel:limited:cn=ellen,dc=tivoli,dc=com
À dc=tivoli,dc=com: subtreeACI:deny:w#[all]#authnLevel:strong:cn=rob,dc=sun,dc=com
Alors si le bind était fort, cn=ellen,dc=tivoli,dc=com a les permissions "rw" sur tous les attributs de l'objet cn=ellen,dc=tivoli,dc=com, et les permissions "rw" sur tous les attributs de cn=rob,dc=sun,dc=com. Si le bind est limité, cn=ellen,dc=tivoli,dc=com n'a plus que le droit "r" sur lui-même.
C'est une conséquence de la manière dont deny est traité avec authnLevel. Vu que cn=rob,dc=sun,dc=com n'a pas "w" quand il s'authentifie en strong, tous les utilisateurs n'auront pas ce droit quand ils s'authentifient à un niveau inférieur.

Contrôle GetEffectiveRights

   Les contrôles d'aci fournissent une manière de manipuler les informations de contrôle d'accès, en conjonction avec une opération ldap. Un contrôle LDAP est définis. Ce contrôle permet de récupérer les informations de contrôle d'accès. Le contrôle est GetEffectiveRights. Son but est de permettre à un administrateur ou une application de demander au serveur les droits d'un autre utilisateur de l'annuaire. Cela permet à un administrateur de vérifier les droits d'un utilisateur, ou une application peut proposer à un utilisateur les attributs sur lequel il a des droits de modification ou de lecture.

Request Control

Ce contrôle peut être inclus uniquement dans un message ldap_search. Le controlValue est un OCTET STRING, dont la valeur est la valeur encodée BER:
GetEffectiveRightsRequest ::= SEQUENCE{
    gerSubject [0] GERSubject
}
    
GERSubject ::= SEQUENCE {
    gerOneSubject [0] OneSubject -- from 4.1.2 , OPTIONAL
    germachineSubject [1] GERMachineSubject,
    gerAuthnLEvel [2] AuthnLevel, -- from 4.1.2
}
    
GERMachineSubject ::= SEQUENCE{
    gerOneIPAddress [0] IPAddress, -- from 4.1.2
    gerOneDNSName [1] DomainName -- from 4.1.2
}

   Le getEffectiveRightsRequest spécifie un sujet, gerSubject, sur quelles informations de contrôle d'accès sont demandées. Le contrôle demande au serveur d'évaluer et retourner les droits au niveau de l'entrée possédée par le gerSubject pour chaque entrée qui est retournée dans le résultat de recherche et pour chaque attribut spécifiquement demandé. Le serveur va utiliser l'algorithme de décision d'accès pour déterminer les droits effectifs.

Response Control

Ce contrôle est inclus dans un message de réponse ldap_search. Le contrôleValue est un OCTET STRING dont la valeur est encodée BER:
GetEffectiveRightsResponse ::= {
    result ENUMERATED {
        success (0),
        operationsError (1),
        unavailableCriticalExtension (12),
        noSuchAttribute (16),
        undefinedAttributeType (17),
        invalidAttributeSyntax (21),
        insufficientRights (50),
        unavailable (52),
        unwillingToPerform (53),
        other (80)
    }
}

Les droits effectifs sont retournés avec chaque entrée retournée par le résultat de la recherhe. Le contrôle de réponse pour ldap_search est:
PartialEffectiveRightsList ::= SEQUENCE {
    entryLevelRights [0] EffectiveRights,
    attributeLevelRights [1] AttributeLevelRights
}
    
EffectiveRights ::= CHOICE {
    rights [0] Permissions -- from 4.1.2,
    noRights [1] NULL,
    errorEvaluatingRights [2] GerError
}
    
GerError ::= ENUMERATED
    {generalError(0),insufficientAccess(1)}
    
    AttributeLevelRights ::= SEQUENCE OF {
    attr [0] SEQUENCE OF Attribute,
    rights [1] EffectiveRights
}

   Pour une entrée donnée, le champ entryLevelRights du contrôle de réponse contient les droits effectifs au niveau de l'entrée qui gerSubject a sur cette entrée. Le champ attributeLevelRights contient la liste des attributs et les droits effectifs que gerSubject a pour chacun de ces attributs. La liste des attributs consiste de ceux retournés dans l'opération de recherche et les attributs explicitement demandés. Un attribut explicitement demandé dans une recherche peut ne pas être retournée parce que l'entrée n'est pas présent dans l'entrée, mais on peut être intéressé par les permissions sur cet attribut.

   Le contrôle retourne les permissions que gerSubject a sur l'entrée donnée et ses attributs. Pour déterminer si ces permissions suffisent pour permettre à gerSubject d'effectuer une opération LDAP donnée sur l'entrée, le demandeur va déterminer si ces permissions satisfont les permissions requises pour cette opération LDAP. Noter que dans le cas où les permissions ne sont pas suffisantes pour une acction, ce contrôle ne permet pas de déterminer si c'est parce que la permission n'a pas été donnée, ou si c'est à cause d'un deny explicit.

Contrôle d'accès pour le contrôle GetEffectiveRights

Exemples

Supposons que l'on a un DIT avec les entrées et contrôles d'accès suivant:
o=sun.com
objectclass: top
objectclass: organization
o: sun.com
subtreeACI: grant:rsc#[all]#authnLevel:none:public:
subtreeACI: deny:rsc#[userPassword,subtreeACI,entryACI,salary]#authnLevel:none:public:
subtreeACI: grant:bvt#[entry]#authnLevel:none:public:
subtreeACI: grant:g#[entry]#authnLevel:limited:this:
subtreeACI: grant:worsc#[all]#authnLevel:limited:this:
subtreeACI: deny: wo[entryACI, subtreeACI, salary]#this
subtreeACI: grant:rscmo,w#[all]#authnLevel:strong:group:cn=adminGroup,ou=Groups,o=sun.com
subtreeACI: grant:bvtugeinad#[entry]#authnLevel:stronggroup: cn=adminGroup,ou=Groups,o=sun.com
    
cn=admin,o=sun.com
objectclass: top
objectclass: person
cn: admin
sn: admin
userPassword: secret
salary: 10000
    
ou=Groups,o=sun.com
objectclass: top
objectclass: organizationalUnit
ou: Groups
    
cn=adminGroup,ou=Groups,o=sun.com
objectclass: top
objectclass: groupOfUniqueNames
uniquemember: cn=admin,o=sun.com
    
ou=Eng,o=sun.com
objectclass: top
objectclass: organizationalUnit
ou: Eng
    
cn=Joe Engineer,ou=Eng,o=sun.com
objectclass: top
objectclass: person
cn: Joe Engineer
sn: Engineer
userPassword: secret
salary: 10000
    
ou=Sales,o=sun.com
objectclass: top
objectclass: organizationalUnit
    
cn=Joe Sales,ou=Sales,o=sun.com
objectclass: top
objectclass: person
cn: Joe Sales
sn: Sales
userPassword: secret
salary: 100000000000

   La stratégie de contrôle d'accès dans ce DIT peut être décrite comme suit:

1. Les utilisateurs anonymes peuvent lire, rechercher et comparer les droits dans tout de DIT, excepté pour les attributs userPassword,subtreeACI,entryACI, et salary.
2. Tout utilisateur authentifié avec un mécanisme limité peut modifier les attributs de son entrée, excepté subtreeACI, entryACI, et salary.
3. Tous les utilisateurs peuvent lire tous les attributs dans son entrée.
4. Tout utilisateur authentifié avec un mécanisme limité peut récupérer les droits effectifs de sa propre entrée.
5. Les utilisateurs, authentifiés avec un mécanisme fort, dans le groupe cn=adminGroup,ou=Groups,o=sun.com peuent récupérer les droits effectifs dans tout de DIT.

   Quelques exemples de requêtes pour obtenir les droits effectifs et les réponses:

   Exemple 1: Supposons que l'on fait une demande, authentifié au niveau strong, en tant que cn=admin,o=sun.com, avec comme base o=sun.com, un filtre "objectclass=*", et les attributs demandés "* entryACI", avec le contrôle getEffectiveRights et le sujet est cn=Joe Sales,ou=Sales,o=sun.com, et le MachineSubject spécifiant l'ipAddress et dnsName de la machine client et le authnLevel à limité.

Le résultat de recherche et les droits effectifs que l'on verra sont:
o=sun.com
objectclass: top
objectclass: organization
o: sun.com
    
entryLevelRights: bvt
attributeLevelRights: objectclass,o:rsc,entryACI:none
---
cn=admin,o=sun.com
objectclass: top
objectclass: person
cn: admin
sn: admin
userPassword: secret
salary: 10000

entryLevelRights: bvt
attributeLevelRights: objectclass,cn,sn:rsc,userPassword,salary,entryACI:none
---
ou=Groups,o=sun.com
objectclass: top
objectclass: organizationalUnit
ou: Groups

entryLevelRights: bvt
attributeLevelRights: objectclass,ou:rsc,entryACI:none
---
ou=Eng,o=sun.com
objectclass: top
objectclass: organizationalUnit

entryLevelRights: bvt
attributeLevelRights: objectclass,ou:rsc,entryACI:none
---
cn=Joe Engineer,ou=Eng,o=sun.com
objectclass: person
cn: Joe Engineer
sn: Engineer
userPassword: secret
salary: 10000

entryLevelRights: bvt
attributeLevelRights: objectclass,cn,sn:rsc,userPassword,salary,entryACI:none
---
ou=Sales,o=sun.com
objectclass: top
objectclass: organizationalUnit

entryLevelRights: bvt
attributeLevelRights: objectclass,ou:rsc,entryACI:none
---
cn=Joe Sales,ou=Sales,o=sun.com
objectclass: person
cn: Joe Sales
sn: Sales
userPassword: secret
salary: 100000000000

entryLevelRights: bvtg
attributeLevelRights: objectclass,cn,sn,userPassword:rscow,salary,entryACI:rsc

Interaction Client-Serveur

   Le contrôle GetEffectiveRights demande les droits effectifs pour l'entrée/attribut demandé basé sur le sujet spécifié. Il y a 6 scénarios possibles qui peuvent se produire en résultat de ce contrôle:

1. Si le serveur ne supporte pas ce contrôle et que le client a spécifié la criticité, le serveur doit retourner unavailableCriticalExtension.
2. Si le serveur ne supporte pas ce contrôle et que le client n'a pas spécifié la criticité, le serveur doit ignorer le processus et traiter la recherche normalement.
3. Si le serveur supporte ce contrôle mais que pour une quelconque raison il ne peut le traiter et que le client a spécifié la criticité, le serveur devrait retourner unavailableCriticalExtension.
4. Si le serveur supporte ce contrôle mais que pour une quelconque raison il ne peut le traiter et que le client n'a pas spécifié la criticité, le serveur devrait retourner "no rights returned" et inclure "Unavailable" dans le contrôle GetEffectiveRightsResponse.
5. Si le serveur supporte ce contrôle et peut retourner les droits, il devrait inclure le contrôle GetEffectiveRightsResponse dans le message searchResult avec un code de résultat success.
6. Si la recherche échoue pour une quelconque raison, alors le serveur devrait omettre le contrôle GetEffectiveRightsResponse dans le searchResult.

   L'application cliente est assurée que les droits correct sont retournés pour le scope de l'opération de recherche si et seulement si le contrôle GetEffectiveRightsResponse retourne les droits. Si le serveur omet ce contrôle, le client devrait assumer que le contrôle a été ignoré par le serveur.

   Le contrôle GetEffectiveRightsResponse, si inclus par le serveur dans le searchResponse, devrait avoir le GetEffectiveRightsResult mis à "success" si les droits sont retournés ou à un code d'erreur approprié. Le serveur peut ne pas être en mesure de retourner un droits parce qu'il peut ne pas exister; dans ce cas, la demande de droits est ignoré avec succès.
^
02 novembre 2013

htmlpdflatexmanmd




draft-ietf-ldapext-c-api-vlv-01

draft-ietf-ldapext-c-api-vlv-01

Contrôle Virtual List View

   Ce document décrit les fonctions pour créer des contrôles de requête de listes virtuelles. Cette extension consiste de 2 contrôles LDAP: un contrôle de requête Virtual List View qui est envoyé par un client à un serveur avec une recherche LDAP et un contrôle de réponse.

La structure LDAPVirtualList est passé à la fonction ldap_create_virtuallist_control() pour créer le contrôle:
typedef struct ldapvirtuallist {
    unsigned long ldvlist_before_count ;
    unsigned long ldvlist_after_count ;
    char *ldvlist_attrvalue ;
    unsigned long ldvlist_index ;
    unsigned long ldvlist_size ;
    void *ldvlist_extradata ;
} LDAPVirtualList ;
int ldap_create_virtuallist_control(
LDAP *ld,
LDAPVirtualList *ldvlistp,
LDAPControl **ctrlp
) ;
#define LDAP_CONTROL_VLVREQUEST "2.16.840.1.113730.3.4.9"

ld Un handle de session LDAP
ldvlistp L'adresse d'une structure LDAPVirtualList dont le contenu est utilisé pour construire le contrôle
ctrlp Un paramètre de résultat qui aura l'adresse d'une structure LDAPControl qui contient le contrôle VLV créé.

   Les membres d'une structure LDAPVirtualList sont:

ldvlist_before_count Nombre d'entrées avant l'entrée cible que le client demande
ldvlist_after_count Nombre d'entrées après l'entrée cible
ldvlist_attrvalue Si non NULL, indique que le choix byValue dans VirtualListViewRequest est utilisé et correspond à l'élément assertionValue de la valeur du contrôle VirtualListViewRequest encodé en BER lui-même. Cette valeur est comparée par le serveur avec les valeurs des attributs spécifiés par la clé de trie pour déterminer l'entrée cible.
ldvlist_index Utilisé si ldvlist_attrvalue est NULL. Permet de déterminer l'entrée cible.
ldvlist_size Utilisé si ldvlist_attrvalue est NULL. Permet de déterminer l'entrée cible.
ldvlist_extradata Réservé. n'a pas d'effet sur le contrôle

Réponse


int ldap_parse_virtuallist_control(
    LDAP *ld,
    LDAPControl **ctrls,
    unsigned long *target_posp,
    unsigned long *list_sizep,
    int *errcodep
) ;
#define LDAP_CONTROL_VLVRESPONSE "2.16.840.1.113730.3.4.10"
#define LDAP_SORT_CONTROL_MISSING 0x3C /*    60    */
#define LDAP_INDEX_RANGE_ERROR 0x3D /*    61    */

ld Un handle de session LDAP
ctrls L'adresse d'un tableaux de structures LDAPControl.
target_posp l'index de l'entrée cible dans la liste
list_sizep Taille de la liste estimée par le serveur
errcodep Code de résultat VLV, devrait avoir les valeurs suivantes:


LDAP_SUCCESS (0)
LDAP_OPERATIONS_ERROR (1)
LDAP_UNWILLING_TO_PERFORM (53)
LDAP_INSUFFICIENT_ACCESS (50)
LDAP_BUSY (51)
LDAP_TIMELIMIT_EXCEEDED (3)
LDAP_ADMINLIMIT_EXCEEDED (11)
LDAP_SORT_CONTROL_MISSING (60)
LDAP_INDEX_RANGE_ERROR (61)
LDAP_OTHER (50)

^
09 octobre 2014

htmlpdflatexmanmd




draft-ietf-ldapext-ldapv3-dupent-08

draft-ietf-ldapext-ldapv3-dupent-08

Contrôle pour une représentation d'entrée dupliquée

   Ce document décrit les contrôles qui permettent aux entrées dupliquées d'être retournées dans un jeu de résultat de l'opération de recherche. Chaque entrée dupliquée représente une valeur distinct (ou une combinaison de valeurs) du jeu d'attribut multi-valué spécifié.

   Par exemple, une application peut nécessiter de produire une liste ordonnées d'entrées, triée par un attribut multi-valué, où chaque valeur d'attribut est représentée dans la liste. Le contrôle SSS permet au serveur d'ordonner les entrées du résultat de recherche basé sur les valeurs d'attribut. Mais il ne permet pas de spécifier le comportement quand un attribut contient plusieurs valeurs. Le contrôle ldap pour la représentation des résultats de recherche, comme définis dans X.511, est d'utiliser la valeur d'ordre la plus petite comme clé de tri.

   Pour produire une liste ordonnée, où chaque valeur d'un attribut multi-valué est trié dans la liste, un contrôle séparé est nécessaire qui étend suffisamment le jeu d'entrée pour représenter chaque valeur attribut avant le trie.

   Par exemple, une liste triée de tous les numéros de téléphone dans une organisation. Parce qu'une entrée peut avoir plusieurs numéros de téléphone, et la liste doit être triée par numéro de téléphone, la liste doit être capable de contenir des entrées dupliquées, chacun avec son propre numéro de téléphone unique.

   Autre exemple, une application qui a besoin d'afficher une liste ordonnée de tous les membres d'un groupe. Il utiliserai ce contrôle pour créer un jeu de résultat d'entrée groupOfNames dupliquées, chacun avec une simple, valeur unique dans son attribut member.

Contrôles

Ce contrôle est inclus dans le message searchRequest dans le champ controls du LDAPmessage. controlType est 2.16.840.1.113719.1.27.101.1 et controlValue est définis comme suit:
DuplicateEntryRequest ::= SEQUENCE {
    AttributeDescriptionList, -- from [RFC2251]
    PartialApplicationAllowed BOOLEAN DEFAULT TRUE }

AttributeDescriptionList

Le type de données AttributeDescriptionList décris une liste de 0 ou plusieurs types AttributeDescription. Les définitions, issues de la rfc2251 sont répétées ici:
AttributeDescriptionList ::= SEQUENCE OF AttributeDescription
AttributeDescription ::= LDAPString
Une valeur de AttributeDescription est basé sur le BNF suivant:
attributeDescription = AttributeType [ ";" ‹options› ]

   En traitant une requête search, un serveur examine cette liste. Si un attribut spécifié ou un sous-type d'attribut existe dans une entrée à retourner par l'opération de recherche, et que cet attribut maintient plusieurs valeurs, le serveur traite l'entrée comme si c'était de multiple, entrées dupliquées -- les attributs spécifiés maintenant une seule et unique valeur du jeu original de valeurs de cet attribut. Noter qu'il peut en résulter des entrées qui ne matchent plus le filtre de recherche.

   Spécifier un supertype d'attribut a l'effet de traiter toutes les valeurs des sous-types de cet attribut comme si c'était des valeurs de ce supertype.

   Quand des descriptions d'attribut contiennent des options de sous-typage, elle sont traitées de la même manière que décris dans la rfc2251. Les sémantiques sont indéfinies si une description d'attribut contient une option de non sous-typage, et ne devrait pas être spécifié par les clients.

   Quand 2 attributs ou plus sont spécifiés par ce contrôle, le nombre d'entrées dupliquées est la combinaison de toutes les valeurs dans chaque attribut. À cause de la complexité potentielle à desservir plusieurs attribut, les implémentations de serveur peuvent choisir de supporter un nombre limité d'attributs dans le contrôle.

   Il y a un cas spécial où il n'y a pas d'attributs spécifié, ou un description d'attribut a la valeur '*'. Dans ce cas, tous les attributs sont utilisé. Si un attribut n'est pas reconnu, cet attribut est ignoré en traitant le contrôle.

PartialApplicationAllowed

   Le champ PartialApplicationAllowed est utilisé pour spécifier si le client va permettre au serveur d'appliquer ce contrôle à un sous-jeu du jeu de résultat de recherche. À TRUE, le serveur est libre d'appliquer arbitrairement ce contrôle à aucun, n'importe lequel, ou tous les résultats de recherche ou échoue à supporter le contrôle.

   Les implémentations client utilisent le contrôle DuplicateSearchResult pour découvrir que résultats de recherche ont été affectés par ce contrôle.

Contrôles de réponse

   2 contrôles de réponse sont définis pour fournir un retour durant les résultats de recherche; DuplicateSearchResult et DuplicateEntryResponseDone.

DuplicateSearchResult est envoyé avec toutes les opérations SearchResultEntry qui contiennent des résultats de recherche qui ont été modifiés par le contrôle DuplicateEntryRequest.
DuplicateEntryResponseDone est envoyé avec l'opération SearchResultDone pour compléter les informations.

DuplicateSearchResult

   Ce contrôle est inclus dans le message SearchResultEntry d'un résultat de recherche qui maintient un entry qui a été modifiée par le contrôle DuplicateEntryRequest. Ce contrôle est absent des résultat de recherche qui ne sont pas affectés par le contrôle DuplicateEntryRequest. controlType vaut 2.16.840.1.113719.1.27.101.2. controlValue n'est pas inclus.

DuplicateEntryResponseDone

Ce contrôle est inclus dans le message searchResultDone. controlType vaut 2.16.840.1.113719.1.27.101.3, controlValue est définis comme suit:
DuplicateEntryResponseDone ::= SEQUENCE {
    resultCode, -- From [RFC2251]
    errorMessage [0] LDAPString OPTIONAL,
    attribute [1] AttributeDescription OPTIONAL }

   Un resultCode est fournis ici pour permettre au serveur de prévenir le client qu'une erreur s'est produite à cause de ce contrôle. Par exemple, une recherche qui aurait du se compléter avec succès peut échouer avec un sizeLimitExceede à cause de ce contrôle. errorMessage peut être utilisé avec une chaîne human-readable dans le cas d'un resultCode indiquant une erreur. Le champ attribute peut être définis à la valeur du premier attribut spécifié par le DuplicateEntryRequest qui à généré l'erreur. Le client doit ignorer le champ attribut si le résultat est success.

Exemple simple

Cet exemple montre l'utilisation de ce contrôle pour produire une liste de tous les numéros de téléphone dans dc=example,dc=net. Partant des 3 entrées suivantes:
dn: cn=User1,dc=example,dc=net
telephoneNumber: 555-0123
dn: cn=User2,dc=example,dc=net
telephoneNumber: 555-8854
telephoneNumber: 555-4588
telephoneNumber: 555-5884
dn: cn=User3,dc=example,dc=net
telephoneNumber: 555-9425
telephoneNumber: 555-7992
D'abord une recherche LDAP est spécifiée avec un baseDN à "dc=example,dc=net", un scope subtree, un filtre "(telephoneNumber=*)". Un contrôle DuplicateEntryRequest est attaché à la recherche, spécifiant "telephoneNumber" comme description d'attribut. Le jeu de résultat sera:
dn: cn=User1,dc=example,dc=net
telephoneNumber: 555-0123
‹no DuplicateSearchResult control sent with search result›
dn: cn=User2,dc=example,dc=net
telephoneNumber: 555-8854
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
telephoneNumber: 555-4588
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
telephoneNumber: 555-5884
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User3,dc=example,dc=net
telephoneNumber: 555-9425
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User3,dc=example,dc=net
telephoneNumber: 555-7992
control: 2.16.840.1.113719.1.27.101.2

   Toutes les entrées sauf la première seront accompagnées par le contrôle DuplicateSearchResult. Noter qu'il n'est pas nécessaire d'utiliser un attribut dans ce contrôle qui est spécifié dans le filtre de recherche.

Spécifier plusieurs attributs

Un exemple plus compliqué utilise plusieurs attributs. Assumant les entrées suivantes dans l'annuaire:
dn: cn=User1,dc=example,dc=net
cn: User1
givenName: User One
mail: user1@example.net
dn: cn=User2,dc=example,dc=net
cn: User2
givenName: User Two
mail: user2@example.net
mail: usertwo@example.net
Dans cet exemple, on spécifie mail et name dans la liste des attributs. En spécifiant name, tous les sous-type de name seront également considérés. Le résultat sera:
dn: cn=User1,dc=example,dc=net
cn: User1
mail: user1@example.net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User1,dc=example,dc=net
givenName: User One
mail: user1@example.net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
cn: User2
mail: user2@example.net
control: 2.16.840.1.113719.1.27.101.2
cn: User2
mail: usertwo@example.net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
givenName: User Two
mail: user2@example.net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
givenName: User Two
mail: usertwo@example.net
control: 2.16.840.1.113719.1.27.101.2

Lister les membres d'un groupOfNames

Cet exemple moutre comment les contrôles peuvent être utilisés pour retourner plusieurs entrées depuis une entrée groupOfNames. Considérant l'entrée suivante:
dn: cn=Administrators,dc=example,dc=net
cn: Administrators
member: cn=aBaker,dc=example,dc=net
member: cn=cDavis,dc=example,dc=net
member: cn=bChilds,dc=example,dc=net
member: cn=dEvans,dc=example,dc=net
un searchBase à "cn=Administrators,dc=example,dc=net", un filtre à "(objectClass=*)", un scope base et le contrôle duplicateEntryRequest avec la valeur d'attribut "member":
dn: cn=Administrators,dc=example,dc=net
member: cn=aBaker,dc=example,dc=net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=Administrators,dc=example,dc=net
member: cn=cDavis,dc=example,dc=net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=Administrators,dc=example,dc=net
member: cn=bChilds,dc=example,dc=net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=Administrators,dc=example,dc=net
member: cn=dEvans,dc=example,dc=net
control: 2.16.840.1.113719.1.27.101.2

   Cette liste peut être ainsi triée par membre et affichée dans une liste.

Relation avec d'autres contrôles

   Ce contrôle est conçus pour être utilisé avec le contrôle Server Side Sorting. En couplant ces 2 contrôles, on peut produire un jeu d'entrées triées par valeurs d'attribut, où chaque valeur d'attribut est représentée dans le jeu trié. Les implémentations de serveur doivent s'assurer que ce contrôle est traité avant de trier le résultat d'une recherche, vu que ce contrôle altère le jeu de résultat.

   Ce contrôle peut également être utilisé avec le contrôle Virtual List View. La nature de dépendance entre VLV est SSS est telle que le trie est fait en premier. À cause de cela, l'impact de ce contrôle sur le contrôle VLV est minimale.
^
27 octobre 2013

htmlpdflatexmanmd




draft-zeilenga-ldap-noop-12

draft-zeilenga-ldap-noop-12

Contrôle LDAP no-op

   Le contrôle no-op peut être utilisé pour désactiver l'effet normal d'une opération. Le contrôle peut être utilisé pour découvrir comment un serveur peut réagir à une requête update particulière sans mettre à jours l'annuaire. Le contrôle no-op est un contrôle dont controlValue est absent. Les clients doivent fournis la criticité pour empêcher toute modification. Un resultCode autre que noOperation signifie que le serveur n'est pas capable de compléter le traitement. Les serveurs devrait indiquer le support pour ce contrôle en fournissant l'OID dans supportedControl.

^
27 octobre 2013

htmlpdflatexmanmd




draft-zeilenga-ldap-relax-03

draft-zeilenga-ldap-relax-03

Contrôle relax

   Le contrôle de règle relax permet à un DUA de demander au service d'annuaire un relâchement temporaire de diverses données et règles de modèle de service. Un serveur LDAP empêche la modification de la classe d'objet structurelle d'un objet. Les modèles x.500 ne permettent pas à un objet person d'être transformés en un objet organizationalPerson. Cette approche est problématique pour plusieurs raisons. D'abord, vu que LDAP n'a pas de méthode standardisé pour effectuer 2 opérations en une seule transaction, l'état intermédiaire de l'annuaire (après le delete, avant le add) est visible aux autres clients. Ensuite, les attributs tels que entryUUID vont refléter que l'objet a été remplacé, pas transformé.

   Un serveur LDAP empêche les clients de modifier les valeurs des attributs NO-USER-MODIFICATION. Cependant, quand un administrateur restaure un objet, en repartitionnant les données entre des serveurs d'annuaire, ou en migrant d'un serveur à un autre, il peut être désirable de permettre au client d'assigner ou modifier la valeur de entryUUID.

   Ce contrôle peut être attaché aux requêtes LDAP pour mettre à jours le DIT pour demander à divers règles de données et services d'être relaxé durant l'exécution de la mise à jours. Le serveur s'assure que l'état de l'annuaire résultant reste valide.

   L'utilisation de cette extension est restreinte par acl et est principalement utilisé pour les administrateurs de l'annuaire.

Pour changer un objet organization en organizationalUnit, un client pourrait utiliser la requête suivante:
dn: o=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
delete: objectClass
objectClass: organization
-
add: objectClass
objectClass: organizationalUnit
-

   Le contrôle relax permet d'ajouter ou modifier des valeurs d'attributs marqué inactifs.

Ajouter un entryUUID:
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: add
objectClass: organizationalUnit
ou: Unit
entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14

Modifier l'entryUUID:
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
replace: entryUUID
entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
-

createTimestamp
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: add
objectClass: organizationalUnit
ou: Unit
createTimestamp: 20060101000000Z
    
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
replace: createTimestamp
createTimestamp: 20060101000000Z
-

modifyTimestamp
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: add
objectClass: organizationalUnit
ou: Unit
modifyTimestamp: 20060101000000Z
    
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
replace: modifyTimestamp
modifyTimestamp: 20060101000000Z
-

creatorsName et modifiersName
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: add
objectClass: organizationalUnit
ou: Unit
creatorsName: cn=Jane Doe,dc=example,net
modifiersName: cn=Jane Doe,dc=example,net
    
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
replace: creatorsName
creatorsName: cn=Jane Doe,dc=example,net
-
replace: modifiersName
modifiersName: cn=Jane Doe,dc=example,net
-

^
12 octobre 2013

htmlpdflatexmanmd




ldap.conf

ldap.conf, .ldaprc

Fichier de configuration LDAP

   ldap.conf est utilisé pour définir les paramètres LDAP par défaut pour les clients. les utilisateurs peuvent créer un fichier ldaprc ou .ldaprc dans leur répertoire personnel. D’autres fichiers de configuration peuvent être spécifiés en utilisant les variables d’environnement LDAPCONF et LDAPRC. Les options peuvent être également définies par des variables d’environnement en les préfixant par "LDAP" (ex: pour BASE, LDAPBASE). Certaines options sont user-only et sont ignorés s’ils sont trouvés dans ldap.conf.

Les fichiers et variables sont lus dans cet ordre:
variable $LDAPNOINIT , et si non définie:
system file /usr/local/etc/openldap/ldap.conf,
user files $HOME/ldaprc, $HOME/.ldaprc, ./ldaprc,
system file $LDAPCONF,
user files $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,
variables $LDAP‹uppercase option name›.

OPTIONS

URI ‹ldap[si]://[name[:port]] ...› Spécifie les URI des serveurs LDAP.
BASE ‹base› Spécifie le DN de base pour les opérations de recherche
BINDDN ‹dn› Spécifie le Bind DN à utiliser (user-only)
DEREF ‹when› Spécifie comment les alias sont déréférencés. peut être: never Jamais déréférencés searching les alias sont déréférencés en subordonnés de l’objet de base, mais pas en localisant l’objet de base de la recherche finding Les alias sont déréférencés en localisant l’objet de base de la recherche always Les alias sont toujours déréférencés.
NETWORK_TIMEOUT ‹integer› Spécifie le timeout en seconde pour les connections
REFERRALS ‹on/true/yes/off/false/no› Spécifie si le client devrait automatiquement suivre les référant retournés par le serveur. Noter que ldapsearch n’utilise pas cette option.
SIZELIMIT ‹integer› Spécifie le nombre d’entrées à utiliser pour les recherches.
TIMELIMIT ‹integer› Spécifie une limite de temps en seconde pour les recherches.
TIMEOUT ‹integer› Spécifie un timeout en secondes après lesquels les appels LDAP sont annulés si aucune réponse n’est reçue.

Options SASL

SASL_MECH ‹mechanism› Spécifie le mécanisme SASL à utiliser (user-only)
SASL_REALM ‹realm› Royaume SASL
SASL_AUTHCID ‹authcid› Spécifie l’identité d’authentification (user-only)
SASL_AUTHZID ‹authcid› Spécifie l’identité d’authorisation (user-only)
SASL_SECPROPS ‹properties› Spécfie les propriétés de sécurité SASL. peut être:

        none seul, désactive ("noanonymous,noplain")
        noplain Désactive les mécanismes sujets à attaques simple
        noactive Désactive les mécanismes suet à attaques actives.
        nodict Désactive les mécanismes sujets à attaque passive par dictionnaire
        noanonymous Désactive les mécanismes qui supportent les logins anonymes
        forwardsec Nécessite de renvoye un secret entre les sessions
        passcred Nécessite des mécanismes qui passent les accréditations client.
        minssf=‹factor› Spécifie le facteur minimum à utiliser
        maxssf=‹factor› Spécifie le facteur maximum à utiliser
        maxbufsize=‹factor› Spécifie la taille de tampon maximum. (0 désactive)

Options GSSAPI

GSSAPI_SIGN ‹on/true/yes/OFF/false/no› Spécifie si GSS_C_INTEG_FLAG devrait être utilisé
GSSAPI_ALLOW_REMOTE_PRINCIPAL ‹on/true/yes/OFF/false/no› Spécifie si l’authentification devrait tenter de former le principal de l’attribut ldapServiceName ou dnsHostName des entrées RootDSE cibles.

Options TLS

TLS_CACERT ‹filename› Spécifie le fichier contenant les certficats des autorités reconnus par le client
TLS_CACERTDIR ‹path› Spécifie le répertoire contenant les certficats des autorités reconnus par le client
TLS_CERT ‹filename› Fichier contenant le certificat du client (user-only)
TLS_KEY ‹filename› Spécifie le fichier contenant la clé privée (user-only)
TLS_CIPHER_SUITE ‹cipher-suite-spec› Spécifie les suites de chiffrement accèptables, par ordre de préférence
TLS_PROTOCOL_MIN ‹major›[.‹minor›] Spécifie la version de protocol SSL/TLS minimum. (pour TLS v1.1 mettre 3.2)
TLS_RANDFILE ‹filename› Spécifie le fichier contenant des données aléatoires quand /dev/urandom n’est pas disponible.
TLS_REQCERT ‹level› Spécifie quels vérifications effectuer sur les certificats serveur dans une session TLS:

        never Ne vérifie rien
        allow Le certification serveur est requis. S’il n’est pas fournis, ou s’il n’est pas valide, la session procède normalement
        try Le certificat serveur est requis. si le certificat n’est pas fournis, la session continue normalement. Si le certificat n’est pas valide, termine la session.
        demand|hard Le certificat serveur est obligatoire et doit être valide.
        TLS_CRLCHECK ‹level› Spécfie si la CRL doit être vérifiée : none
        Pas de vérification peer
        Vérifie la CRL du certificat du partie all
        Vérifie la CRL pour toute la chaîne de certificat

TLS_CRLFILE ‹filename› Spécifie le fichier contenant la CRL.

Variables d'environnement

LDAPNOINIT Désactive tous les paramètres par défaut
LDAPCONF Chemin du fichier de configuration
LDAPRC Fichier de configuration dans $HOME ou $CWD
LDAP‹option-name› Options comme dans ldap.conf
^
08 septembre 2013

htmlpdflatexmanmd




ldapcompare

ldapcompare

Outil de comparaison ldap

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-z Mode silencieux

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]

Exemples

ldapcompare "uid=babs,dc=example,dc=com" sn:Jensen
ldapcompare "uid=babs,dc=example,dc=com" sn ::SmVuc2Vu
^
08 septembre 2013

htmlpdflatexmanmd




ldapdelete

ldapdelete

Outil de suppression d’entrées LDAP

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-c Mode continue, les erreurs sont reportées, mais la requête continue
-f file Lit une série de DN depuis le fichier
-r Suppression récursivement
-z sizelimit Limite en recherchant le DN à supprimer

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapexop

ldapexop

Fournis des opérations étendues LDAP par oid ou un des mot clé spécial whoami, cancel ou refresh.

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité
-f file Lit les opérations depuis le fichier

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapmodify

ldapmodify, ldapadd

Ajouter/modifier des entrées dans LDAP

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-a Ajoute une nouvelle entrée. défaut pour ldapadd
-c Mode continue, les erreurs sont reportées, mais la requête continue
-f file Lit les entrées depuis le fichier
-S file Reporte les enregistrements qui ont été skippés à cause d’une erreur dans le fichier spécifié

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapmodrdn

ldapmodrdn

Outil de renommage LDAP

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité
-c Mode continue, les erreurs sont reportées, mais la requête continue
-s newsup Spécifie un nouveau supérieur de l'entrée (ldapv3 uniquement)
-r Supprime les anciennes valeurs RDN de l'entrée
-f file Lis les informations de modification depuis le fichier

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]

Exemples

on assume que le fichier /tmp/entrymods existe et a le contenu :
cn=Modify Me,dc=example,dc=com
cn=The New Me
la commande :
ldapmodrdn -r -f /tmp/entrymods
va changer le RDN de l’entrée "Modify Me" depuis "Modify ME" vers "The New Me" et l’ancien cn "Modify Me" sera supprimé.
^
08 septembre 2013

htmlpdflatexmanmd




ldappasswd

ldappasswd

Change le mot de passe d’une entrée LDAP

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité
-A Demande l’ancien mot de passe. Évite de spécifier le mot de passe sur la ligne de commande
-a oldpasswd Spécifie l’ancien mot de passe
-t oldPasswdFile Spécifie le fichier contenant l’ancien mot de passe.
-S Demande le nouveau mot de passe. Évite de spécifier le mot de passe sur la ligne de commande
-s newpasswd Définit le nouveau mot de passe.
-T newPasswdFile Définit le fichier contenant le nouveau mot de passe.

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapsearch

ldapsearch

Outil de recherche ldap

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité
-c Mode continue, les erreurs sont reportées, mais la requête continue
-u Inclus la forme User Friendly Name des DN dans la sortie
-t[t] -t écrit les valeurs non-imprimables dans un jeu de fichiers temporaires. -tt écrit toutes les valeurs retournées dans les fichiers.
-T path Ecrit les fichiers temporaires dans ce répertoire
-F prefix Préfix URL des fichiers temporaires (défaut : file ://‹path›)
-A Récupère les attributs uniquement
-L Affiche le résultat au format LDIF. -L utilise le format LDIFv1, -LL désactive les commentaires, -LLL n’affiche pas la version LDIF.
-S attribute Trie les entrées retournée basé sur l’attribut spécifié.
-b searchbase Point de départ pour la recherche
-s base|one|sub|children Scope de recherche
-a never|always|search|find Spécifie le mode de déréférencement des alias.
-l timelimit temps d’attente max en seconde pour qu’une recherche se complète
-z sizelimit Nombre d’entrées max pour qu’une recherche se complète.
-f file Pour chaque ligne dans le fichier, effectue une recherche. Dans ce cas, le filtre spécifié sur la ligne de commande est traité comme pattern où la première occurence de %s est remplacée par la ligne.

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapurl

ldapurl

Outil de formatage d’URL LDAP

OPTIONS

-a attrs Liste de sélecteur d’attributs
-b searchbase Point de départ pour la recherche
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-H ldapuri URI du serveur LDAP
-S scheme Schema d’URL
-s base|one|sub|children Scope de recherche

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]

Exemples

ldapurl -h ldap.example.com -b dc=example,dc=com -s sub -f "(cn=Some One)"
retourne:
ldap ://ldap.example.com:389/dc=example,dc=com ??sub ?(cn=Some%20One)
ldapurl -H ldap ://ldap.example.com:389/dc=example,dc=com ??sub ?(cn=Some%20One)
retourne :
scheme : ldap
host : ldap.example.com
port : 389
dn : dc=example,dc=com
scope : sub
filter : (cn=Some One)
^
08 septembre 2013

htmlpdflatexmanmd




ldapwhoami

ldapwhoami

Outil pour l'opération WhoAmI

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
26 septembre 2013

htmlpdflatexmanmd




OpenLDAP - Limites

OpenLDAP - Limites

configuration des limites de slapd

   Il est généralement préférable de limiter les ressources du serveur pour qu'il soit accessible à tous les clients. OpenLDAP fournit 2 type de limites : un limite de taille, qui peut être restreinte par le nombre d'entrées qu'un client peut récupérer en une seule opération, et une limite de temps, qui restreint le temps qu'une opération peut se poursuivre.

Limites Soft et Hard

   L'administrateur du serveur peut limiter les limites hard et soft. Les limites soft sont les valeurs de limite par défaut, les limites hard sont les limites qui ne peuvent pas être dépassée par les utilisateurs LDAP.

  Les clients LDAP peuvent spécifier leur propre limites de taille et de temps pour les opérations de recherche.

  Si le client spécifie une limite alors la plus faible des valeurs entre celle-ci et la hard limit sera choisie. Si le client ne spécifie pas de limite, la soft limit s'applique.

Le rootdn n'est pas sujet à ces limites.
sizelimit {‹integer›|unlimited} # défaut 500
timelimit {‹integer›|unlimited} # défaut 3600
Une forme étendue permet aux limites soft et hard d'être séparés.
sizelimit size[.{soft|hard|unchecked}]=‹integer› [...]
timelimit time.{soft=‹integer›} [...]
exemple
sizelimit size.soft=10 size.hard=75

   Le mot clé unchecked spécifie une limite du nombre d'entrées que le serveur va examiner une fois qu'il a crée un lot de résultats candidat en utilisant les indices. Ça peut être très important dans les gros annuaires, quand une recherche qui ne peut pas être satisfaite depuis un index peut nécessiter d'examiner des millions d'entrées.

Limites par base

   Chaque base de donnée peut avoir ses propres limites. La syntaxe est plus flexible, et permet différentes limites à appliquer à différentes entités. le terme entité est utilisé pour indiquer l'ID de la personne ou du processus qui a initié l'opération LDAP. Dans slapd.conf le mot clé est limits. En utilisant le backend slapd config, l'attribut correspondant est olcLimits. La syntaxe est la même dans les 2 cas.

limits ‹who› ‹limit› [‹limit› [ ... ]]

   la clause limits peut être spécifiée plusieurs fois. Le serveur examine chaque clause jusqu'à ce qu'il en trouve une qui corresponde à l'ID qui a requis l'opération. Si aucune correspondante n'est trouvée, les limites globales sont utilisées.

Spécifier à qui s'applique les limites

La partie ‹who› peut prendre les valeurs suivante:
*____________________________All, including anonymous and authenticated users
anonymous____________________Anonymous (non-authenticated) users
users________________________Authenticated users
self_________________________User associated with target entry
dn[.‹basic-style›]=‹regex›___Users matching a regular expression
dn.‹scope-style›=‹DN›________Users within scope of a DN
group[/oc[/at]]=‹pattern›____Members of a group

Spécifier des limites de temps

time.soft=‹integer›
où integer est la durée en seconde.
si soft ou hard ne sont pas spécifiés, la valeur est utilisée pour les 2:
limits anonymous time=27
la valeur unlimited peut être utilisé pour supprimer la limite de temps hard :
limits dn.exact="cn=anyuser,dc=example,dc=org" time.hard=unlimited
spécifier des tailles limites.
size[.soft|hard|unchecked]=integer›
où integer est le nombre d'entrée maximum que slapd va retourner.

Limites de taille et résultats paginés

   Si le client LDAP ajoute le pagedResultsControl pour les opérations de recherche, la limite de taille hard est utilisée par défaut, parce que la requête pour une taille de page spécifique est considérée comme une requête explicite pour une limitation sur un nombre d'entrée à retourner. Cependant, la taille limite s'applique au compteur total des entrées retournées dans la recherche, et pas dans une simple page.

size.pr={‹integer›|noEstimate|unlimited}

integer est la taille de page maximum si aucune taille implicite n'est donnée. noEstimate n'a pas d'effet dans l'implémentation courante vu que le serveur ne retourne pas une estimations de taille de résultat. unlimited indique qu'aucune limite n'est appliquée à la taille de page maximum.
size.prtotal contrôle le nombre total d'entrées qui peuvent être retournés par une recherche paginée. Par défaut la limite est la même que la limite size.hard.
size.prtotal={‹integer›|unlimited|disabled}
unlimited supprime la limite sur le nombre d'entrée qui peuvent être retournés par une recherche paginée. disabled peut être utilisé pour désactiver sélectivement les recherche de résultat paginés.

Exemples

cet exemple applique des limites de temps et de taille pour toutes les recherche par les utilisateurs, excepté rootdn.
sizelimit 50
timelimit 10
Limites hard et soft global: Il est parfois utile de limiter la taille des résultats mais de permettre aux clients de demander une limite plus élevée si nécessaire. Cela peut être fait en définissant des limites soft et hard séparés:
sizelimit size.soft=5 size.hard=100
Pour se prémunir des clients qui font des recherches non-indexées inefficaces, ajouter la limite unchecked:
sizelimit size.soft=5 size.hard=100 size.unchecked=100
Donner des limites plus grandes pour des utilisateurs spécifiques.
limits dn.exact="cn=anyuser,dc=example,dc=org" size=100000
limits dn.exact="cn=personnel,dc=example,dc=org" size=100000
limits dn.exact="cn=dirsync,dc=example,dc=org" size=100000
Il est généralement mieux d'éviter de mentionner des utilisateurs spécifiques dans la configuration serveur. Une meilleur manière est de donner des limites supérieurs à un groupe:
limits group/groupOfNames/member="cn=bigwigs,dc=example,dc=org" size=100000
Limiter qui peut faire des recherche paginées
limits group/groupOfNames/member="cn=dirsync,dc=example,dc=org" size.prtotal=unlimited
limits users size.soft=5 size.hard=100 size.prtotal=disabled
limits anonymous size.soft=2 size.hard=5 size.prtotal=disabled
^
19 octobre 2013

htmlpdflatexmanmd




OpenLDAP - Sécurité

OpenLDAP - Sécurité

Considérations de sécurité

Écoute sélective: Par défaut, slapd écoute sur toutes les adresses IPv4 et IPv6. Pour spécifier les ip sur lesquelles slapd écoute: slapd -h ldap://127.0.0.1
Firewall IP: Les capacités de firewalling IP du système peuvent être utilisées pour restreindre l'accès. Généralement, slapd écoute sur le port 389/tcp pour ldap:// et le port 636/tcp pour ldaps://. slapd peut être configuré pour écouter sur d'autres ports.
TCP Wrappers: TCP wrappers fournis un système de contrôle d'accès basé sur des règles pour contrôler les accès TCP/IP sur le serveur. Par exemple: slapd: 10.0.0.0/255.0.0.0 127.0.0.1: ALLOW, slapd ALL: DENY
Protection de confidentialité et d'intégrité de données: TLS peut être utilisé pour fournir une protection de confidentialité et d'intégrité de données. OpenLDAP supporte la négociation de TLS (SSL) via StartTLS et ldaps://. Des mécanismes SASL (Simple Authentication and Security Layer) comme DIGEST-MD5 et GSSAPI sont également disponible.
Facteurs de sécurité forte: Le serveur utilise SSF pour indiquer la force du mécanisme. Un SSF de 0 spécifie aucune protection, à 1 des protections d'intégrité sont en place. un SSF › 1 indiquent la longueur de clé de cryptage. par exemple: DES fait 56, 3DES fait 112, AES fait 128, 192 ou 256.

        'security' contrôle les opérations de restriction quand les protections appropriées ne sont pas en place. Exemple:
        security ssf=1 update_ssf=112
        requière une protection d'intégrité pour toutes les opérations et une protection 3DES ou équivalent, pour les opérations de mise à jour (add, delete, modify, etc.)

Méthodes d'authentification

   La méthode simple a 3 modes d'opération: anonyme, non-authentifié, authentifié par user/password.

  L'accès anonyme est requis en ne fournissant pas de nom et de mot de passe pour une simple opération. l'accès non authentifié est requis en fournissant un nom, mais pas de mot de passe. L'accès authentifié requière un nom valide et un mot de passe.

  le mécanisme anonyme est activé par défaut, il peut être désactivé par "disallow bind_anon".

  note: désactiver le mécanisme anonyme n'empêche pas les accès anonymes à l'annuaire. Pour exiger une authentification pour accéder à l'annuaire, utiliser "require authc"

   L'accès non-authentifié est désactivé par défaut et peut être activé par "allow bind_anon_cred"

  L'accès authentifié est activé par défaut. Cependant les mots de passe sont stockés en clair, il est recommandé de l'utiliser uniquement avec des session chiffrées. Il est recommandé que toutes les authentifications non protégées soient désactivées en utilisant par ex: security simple_bind=56 qui exige les simple_bind d'utiliser le cryptage DES ou meilleur.

  Le mécanisme d'authentification user/password peut être complètement désactivé en utilisant "disallow bind_simple".

Stockage des mots de passe

   Les mots de passe LDAP sont normalement stockés dans l'attribut userPassword. la RFC4519 spécifie que les mots de passe ne sont pas stockés sous forme chiffrée. Cela permet d'utiliser une grande quantité de mécanismes basés sur les mots de passe, comme DIGEST-MD5.

  Cependant, il peut être préférable de stocker un hash des mots de passe. slapd supporte plusieurs schémas de stockage.

  L'attribut userPassword peut avoir une ou plusieurs valeurs, et il est possible pour chaque valeur d'être stockées sous une forme différente. durant l'authentification, slapd va chercher un des mots de passe qui correspondrai. Le schéma de stockage est stocké comme préfixe dans la valeur, donc un hash utilisant SHA1 ressemblera à:

  userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3

Schéma de stockage de mot de passe SSHA

ces valeurs sont représentée sous la forme:
userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3
schéma de stockage de mot de passe CRYPT
Ce schéma utilise la fonction système crypt(3). Il produit le hash traditionnel à 13 caractères, mais peut également générer le hash MD5 34 octets de glibc2.
userPassword: {CRYPT}aUihad99hmev6
userPassword: {CRYPT}$1$czBJdDqS$TmkzUAb836oMxg/BmIwN.1

Schéma de stockage de mot de passe MD5

Ce schéma prend simplement le hash md5 et le stocke sous la forme base64:
userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
schéma de stokage de mot de passe SMD5
Il améliore le schéma MD5
userPassword: {SMD5}4QWGWZpj9GCmfuqEvm8HtZhZS6E=
schéma de stockage de mot de passe SHA
SHA est plus sécurisé que MD5
userPassword: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=

Schéma de stockage de mot de passe SASL

   Ce n’est pas vraiment un schéma de stockage de mot de passe. Il utilise l’attribut userPassword pour déléguer la vérification à un autre processus.

Schéma de stockage de mot de passe Kerberos

   Ce n’est pas un schéma de stockage de mot de passe, il utilise la valeur de l’attribut de userPassword pour déléguer la vérification à Kerberos

Authentification Externe

   Depuis OpenLDAP 2.0 slapd a la capacité de déléguer la vérification de mot de passe à un processus séparé. Il utilise la fonction sasl_checkpass(3). Le choix est très large, comme l’option d’utiliser saslauth(8) qui utiliser les fichiers local, kerberos, un serveur IMAP, un autre serveur LDAP ou tout ce qui peut supporter le mécanisme PAM.

  L’authentification externe fonctionne seulement avec les mots de passe en clair. ce système est sélectif, il utilise uniquement les utilisateurs dont l’attribut userPassword est marqué avec "SASL".

exemple:
userPassword: {SASL}username@realm

Configurer slapd pour l'utilisation d'un fournisseur d'authentification

   Quand une entrée a une valeur de mot de passe "{SASL}", OpenLDAP délègue tout le processus de validation à cyrus SASL. Tout la configuration est faite dans les fichiers de configuration de SASL.

  Un fichier nommé /usr/lib/sasl2/slapd.conf gouverne l’utilisation de SASL quand il communique avec slapd.

Simple exemple pour un serveur qui utilise saslauth pour vérifier les mots de passe:
mech_list: plain
pwcheck_method: saslauthd
saslauthd_path: /var/run/sasl2/mux

Configurer saslauth

saslauthd est capable d’utiliser différents services d’authentification, vois saslauthd(8). Exemple de saslauthd.conf qui utilise M$ Active Directory:
ldap_servers: ldap://dc1.example.com/ ldap://dc2.example.com/
ldap_search_base: cn=Users,DC=ad,DC=example,DC=com
ldap_filter: (userPrincipalName=%u)
ldap_bind_dn: cn=saslauthd,cn=Users,DC=ad,DC=example,DC=com
ldap_password: secret
dans ce cas, saslauthd est lancé avec le mécanisme d’authentification ldap et est définis pour combiner SASL avec le login:
saslauthd -a ldap -r
^
07 juillet 2013

htmlpdflatexmanmd




rfc2307-bis02

rfc2307-bis02

Mappage des entités unix et TCP/IP dans ldap

Attributs

uidNumber Identifiant Unique d’un utilisateur dans un domaine administratif
gidNumber Identifiant Unique d’un group dans un domaine administratif
gecos General Comprehensive Operating System
homeDirectory Chemin absolus du répertoire personnel
loginShell Chemin du shell de connection
shadowLastChange Jours depuis le 1er janvier 1970 que le mot de passe as été changé
shadowMin Nombre de jours minimum avant qu’un mot de passe puisse être changé
shadowMax Nombre de jours maximum avant qu’un mot de passe expire
shadowWarning Nombre de jours avant que l’utilisateur ne soit prévenus que son mot de passe va expirer
shadowInactive Nombre de jours après que le mot de passe ait expiré pour que le compte soit désactivé
shadowExpire Jours depuis le 1er Janvier 1970 que le compte est désactivé
shadowFlag Champ réservé
memberUid Nom de connexion appartenant au groupe
memberNisNetgroup Entité NIS appartenant au netgroup
nisNetgroupTriple triplet hostname/username/domainname
ipServicePort Numéro de port de service
ipServiceProtocol Nom du protocole de service
ipProtocolNumber Numéro de protocole IP
oncRpcNumber Numéro ONC RPC
ipHostNumber Adresse IP de l’hôte
ipNetworkNumber IP du réseau (sans les ’0’, ex 192.168)
ipNetmaskNumber Masque de sous réseau
macAddress Adresse MAC
bootParameter Paramètres de boot
bootFile Nom de l’image de boot
nisMapName Nom d’une map NIS générique
nisMapEntry Une entrée NIS générique
nisPublicKey Clé publique NIS
nisSecretKey Secret NIS
nisDomain Domaine NIS
automountMapName Nom d’une map d’automontage
automountKey Clé d’automontage
automountInformation Informations d’automontage

ObjectClass

posixAccount Compte avec des attributs POSIX
shadowAccount Attributs additionnels pour les mots de passe
posixGroup Groupe de comptes
ipService Service IP
ipProtocol Protocole IP
oncRpc Open Network Computing Remote Procedure Call
ipHost Un hôte, un périphérique IP
ipNetwork Un réseau
nisNetgroup Un netgroup
nisMap Une map NIS
nisObject Une entrée dans une map NIS
ieee802Device Un périphérique avec une adresse MAC
bootableDevice Un périphériques avec des paramètres de démarrage
nisKeyObject Un objet avec une clé publique et un secret
nisDomainObject Associe un domaine NIS avec un contecte de nommage
automountMap Une map d’automontage
automount Informations d’automontage
groupOfMembers Un groupe avec des membres

- Il est suggéré que uid et cn soient utilisés comme attributs de nommage des entrées posixAccount et posixGroup, respectivement.
- Les membres de groupe peuvent être des noms de connexion (valeurs de memberUid) ou des DN (valeurs de member)
- Le champ GECOS d’un compte est déterminé par l’attribut gecos. S’il n’est pas présent, le cn doit être utilisé.
- Une entrée de classe posixAccount, posixGroup ou shadowAccount sans authPassword ou userPassword ne devrait pas être utilisé pour l’authentification.

Si userPassword est utilisé, ses valeurs doivent être représentées par la syntaxe suivante:
passwordvalue = schemeprefix hashedpasswd
schemeprefix = "" scheme ""
scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme
altscheme = "x-" keystring
hashedpasswd = hashed password

Définition des attributs

attributetype ( 1.3.6.1.1.1.1.0 NAME ’uidNumber’
    DESC ’An integer uniquely identifying a user in an administrative domain’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.1 NAME ’gidNumber’
    DESC ’An integer uniquely identifying a group in an administrative domain’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.2 NAME ’gecos’
    DESC ’The GECOS field ; the common name’
    EQUALITY caseIgnoreMatch
    SUBSTRINGS caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.3 NAME ’homeDirectory’
    DESC ’The absolute path to the home directory’
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.4 NAME ’loginShell’
    DESC ’The path to the login shell’
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.5 NAME ’shadowLastChange’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.6 NAME ’shadowMin’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.7 NAME ’shadowMax’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.8 NAME ’shadowWarning’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.9 NAME ’shadowInactive’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.10 NAME ’shadowExpire’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.11 NAME ’shadowFlag’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.12 NAME ’memberUid’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 1.3.6.1.1.1.1.13 NAME ’memberNisNetgroup’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 1.3.6.1.1.1.1.14 NAME ’nisNetgroupTriple’
    DESC ’Netgroup triple’
    EQUALITY caseIgnoreMatch
    SUBSTRINGS caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 1.3.6.1.1.1.1.15 NAME ’ipServicePort’
    DESC ’Service port number’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.16 NAME ’ipServiceProtocol’
    DESC ’Service protocol name’
    EQUALITY caseIgnoreMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 1.3.6.1.1.1.1.17 NAME ’ipProtocolNumber’
    DESC ’IP protocol number’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.18 NAME ’oncRpcNumber’
    DESC ’ONC RPC number’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.19 NAME ’ipHostNumber’
    DESC ’IPv4 addresses as a dotted decimal omitting leading zeros or IPv6 addresses as defined in RFC2373’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
    
attributetype ( 1.3.6.1.1.1.1.20 NAME ’ipNetworkNumber’
    DESC ’IP network omitting leading zeros, eg. 192.168’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.21 NAME ’ipNetmaskNumber’
    DESC ’IP netmask omitting leading zeros, eg. 255.255.255.0’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.22 NAME ’macAddress’
    DESC ’MAC address in maximal, colon separated hex notation, eg. 00:00:92:90:ee:e2’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
    
attributetype ( 1.3.6.1.1.1.1.23 NAME ’bootParameter’
    DESC ’rpc.bootparamd parameter’
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
    
attributetype ( 1.3.6.1.1.1.1.24 NAME ’bootFile’
    DESC ’Boot image name’
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
    
attributetype ( 1.3.6.1.1.1.1.26 NAME ’nisMapName’
    DESC ’Name of a generic NIS map’
    EQUALITY caseIgnoreMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.1564 )
    
attributetype ( 1.3.6.1.1.1.1.27 NAME ’nisMapEntry’
    DESC ’A generic NIS entry’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.151024
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.28 NAME ’nisPublicKey’
    DESC ’NIS public key’
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.29 NAME ’nisSecretKey’
    DESC ’NIS secret key’
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.30 NAME ’nisDomain’
    DESC ’NIS domain’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26256 )
    
attributetype ( 1.3.6.1.1.1.1.31 NAME ’automountMapName’
    DESC ’automount Map Name’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.32 NAME ’automountKey’
    DESC ’Automount Key value’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.33 NAME ’automountInformation’
    DESC ’Automount information’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

Définition des Classe d’objets


objectclass ( 1.3.6.1.1.1.2.0 NAME ’posixAccount’ SUP top AUXILIARY
    DESC ’Abstraction of an account with POSIX attributes’
    MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
    MAY ( authPassword $ userPassword $ loginShell $ gecos $
    description ) )
    
objectclass ( 1.3.6.1.1.1.2.1 NAME ’shadowAccount’ SUP top AUXILIARY
    DESC ’Additional attributes for shadow passwords’
    MUST uid
    MAY ( authPassword $ userPassword $ description $
    shadowLastChange $ shadowMin $ shadowMax $
    shadowWarning $ shadowInactive $
    shadowExpire $ shadowFlag ) )
    
objectclass ( 1.3.6.1.1.1.2.2 NAME ’posixGroup’ SUP top AUXILIARY
    DESC ’Abstraction of a group of accounts’
    MUST gidNumber
    MAY ( authPassword $ userPassword $ memberUid $
    description ) )
    
objectclass ( 1.3.6.1.1.1.2.3 NAME ’ipService’ SUP top STRUCTURAL
    DESC ’Abstraction an Internet Protocol service. Maps an IP port and protocol (such as tcp or udp) to one or more names ; the distinguished value of the cn attribute denotes the service’s canonical name’
    MUST ( cn $ ipServicePort $ ipServiceProtocol )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.4 NAME ’ipProtocol’ SUP top STRUCTURAL
    DESC ’Abstraction of an IP protocol. Maps a protocol number to one or more names. The distinguished value of the cn attribute denotes the protocol canonical name’
    MUST ( cn $ ipProtocolNumber )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.5 NAME ’oncRpc’ SUP top STRUCTURAL
    DESC ’Abstraction of an Open Network Computing (ONC) [RFC1057] Remote Procedure Call (RPC) binding. This class maps an ONC RPC number to a name. The distinguished value of the cn attribute denotes the RPC service canonical name’
    MUST ( cn $ oncRpcNumber )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.6 NAME ’ipHost’ SUP top AUXILIARY
    DESC ’Abstraction of a host, an IP device. The distinguished value of the cn attribute denotes the host’s canonical name. Device SHOULD be used as a structural class’
    MUST ( cn $ ipHostNumber )
    MAY ( authPassword $ userPassword $ l $ description $
    manager ) )
    
objectclass ( 1.3.6.1.1.1.2.7 NAME ’ipNetwork’ SUP top STRUCTURAL
    DESC ’Abstraction of a network. The distinguished value of the cn attribute denotes the network canonical name’
    MUST ipNetworkNumber
    MAY ( cn $ ipNetmaskNumber $ l $ description $ manager ) )
    
objectclass ( 1.3.6.1.1.1.2.8 NAME ’nisNetgroup’ SUP top STRUCTURAL
    DESC ’Abstraction of a netgroup. May refer to other netgroups’
    MUST cn
    MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
    
objectclass ( 1.3.6.1.1.1.2.9 NAME ’nisMap’ SUP top STRUCTURAL
    DESC ’A generic abstraction of a NIS map’
    MUST nisMapName
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.10 NAME ’nisObject’ SUP top STRUCTURAL
    DESC ’An entry in a NIS map’
    MUST ( cn $ nisMapEntry $ nisMapName )
    
objectclass ( 1.3.6.1.1.1.2.11 NAME ’ieee802Device’ SUP top AUXILIARY
    DESC ’A device with a MAC address ; device SHOULD be used as a structural class’
    MAY macAddress )
    
objectclass ( 1.3.6.1.1.1.2.12 NAME ’bootableDevice’ SUP top AUXILIARY
    DESC ’A device with boot parameters ; device SHOULD be used as a structural class’
    MAY ( bootFile $ bootParameter ) )
    
objectclass ( 1.3.6.1.1.1.2.14 NAME ’nisKeyObject’ SUP top AUXILIARY
    DESC ’An object with a public and secret key’
    MUST ( cn $ nisPublicKey $ nisSecretKey )
    MAY ( uidNumber $ description ) )
    
objectclass ( 1.3.6.1.1.1.2.15 NAME ’nisDomainObject’ SUP top AUXILIARY
    DESC ’Associates a NIS domain with a naming context’
    MUST nisDomain )
    
objectclass ( 1.3.6.1.1.1.2.16 NAME ’automountMap’ SUP top STRUCTURAL
    MUST ( automountMapName )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.17 NAME ’automount’ SUP top STRUCTURAL
    DESC ’Automount information’
    MUST ( automountKey $ automountInformation )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.18 NAME ’groupOfMembers’ SUP top STRUCTURAL
    DESC ’A group with members (DNs)’
    MUST cn
    MAY ( businessCategory $ seeAlso $ owner $ ou $ o $
    description $ member ) )

^
24 août 2013

htmlpdflatexmanmd




rfc2589

rfc2589

Extensions pour les services d'annuaire dynamiques

   LDAP support les accès aux services d'annuaire statique, permettant d'effectuer des opérations relativement rapide. Les services d'annuaire dynamiques sont différents puisqu'ils stockent des informations qui ont une durée de vie. un cas typique est un client ou une personne qui est soit online, dans ce cas il a une entrée dans l'annuaire, soit offline et dans ce cas l'entrée disparait. Bien que les opérations du protocole et les attributs sont utilisés de la même manière que pour les services d'annuaires statiques, les clients qui stockent ces informations dans l'annuaire doivent périodiquement rafraîchir ces informations. Les entrées qui n'ont pas été rafraîchies après une période données sont supprimés par le serveur. Un mécanisme de contrôle de flux du serveur est aussi décrit et permet au serveur d'informer les clients de la fréquence de rafraîchissement.

Prérequis

   Les extension de protocole doivent permettre d'accéder aux informations dynamiques dans un annuaire de manière standard.

Entrées dynamiques et classes d'objet

   Une entrée dynamique est un objet dans l'annuaire qui a une durée de vie associée avec lui. Cette durée de vie est définie lors de la création de l'objet et quand il expire, l'objet est supprimé. En invoquant l'opération étendue refresh, le TTL est réinitialisé.

Requête de rafraichissement

Cette opération envoyée par un client indique au serveur de conserver l'entrée dynamique et de réinitialiser sa durée de vie. Un client peut demander cette opération en transmettant un PDU contenant un ExtendedRequest:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
    requestName [0] LDAPOID,
    requestValue [1] OCTET STRING OPTIONAL
    }

requestName doit être définis à: "1.3.6.1.4.1.1466.101.119.1"
requestValue va contenir le DER du type ASN.1 suivant:


SEQUENCE {
    entryName [0] LDAPDN,
    requestTtl [1] INTEGER
    }

entryName est le nom UTF8 de l'entrée dynamique. Cette entrée doit déjà exister.
requestTtl est le temps en secondes (1 à 31557600) du nouveau TTL à définir.

Réponse au rafraichissement

Si un serveur implémente cette extension, le serveur doit répondre un PDU contenant ExtendedResponse:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
    COMPONENTS OF LDAPResult,
    responseName [10] LDAPOID OPTIONAL,
    response [11] OCTET STRING OPTIONAL
    }

responseName contient la même chaîne que dans la demande. Le champ response va contenir un DER de la sequence ASN.1 suivante:


SEQUENCE {
    responseTtl [1] INTEGER
    }

   Le champ responseTtl est le temps en secondes que le serveur a choisi comme champ ttl pour cette entrée. Il ne doit pas être plus petit que le choix du client, mais il peut être plus grand. Cependant, pour éviter tout abus, les serveurs sont autorisés à raccourcir le TTL d'un client à un minimumde 86400 secondes.

Schéma

dynamicObject Cette classe définis une entrée dynamique
entryTtl Maintient le TTL de l'entrée
dynamicSubtrees dans le rootDSE, maintient les sous-arborescences où sont supportée les entrées dynamiques.


( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
DESC 'This class, if present in an entry, indicates that this entry has a limited lifetime and may disappear automatically when its time-to-live has reached 0. There are no mandatory attributes of this class, however if the client has not supplied a value for the entryTtl attribute, the server will provide one.'
SUP top AUXILIARY )
    
( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
DESC 'This operational attribute is maintained by the server and appears to be present in every dynamic entry. The attribute is not present when the entry does not contain the dynamicObject object class. The value of this attribute is the time in seconds that the entry will continue to exist before disappearing from the directory. In the absence of intervening refresh operations, the values returned by reading the attribute in two successive searches are guaranteed to be nonincreasing. The smallest permissible value is 0, indicating that the entry may disappear without warning. The attribute is marked NO-USER-MODIFICATION since it may only be changed using the refresh operation.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
NO-USER-MODIFICATION USAGE dSAOperation )
    
( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees'
DESC 'This operational attribute is maintained by the server and is present in the Root DSE, if the server supports the dynamic extensions described in this memo. The attribute contains a list of all the subtrees in this directory for which the server supports the dynamic extensions.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
USAGE dSAOperation )

Prérequis client

   Les clients peuvent vérifier si le serveur supporte les extensions dynamiques en vérifiant le champs supportedExtension dans le RootDSE. Les client doivent vérifier le dynamicSubtrees pour vérifier si les extensions dynamiques sont supportée sur une arborescence spécifique.

  Les client ne doivent pas s'attendre à ce qu'une entrée soit présente après que le TTL soit dépassé. Toutefois, les client ne doivent pas assumer que l'objet sera supprimé immédiatement après la durée de vie atteinte.

  le CRP (Client Refresh Period) est définis par le serveur, basé sur le entryTtl. Une fois une opération AddRequest effectuée, le client devrait immédiatement envoyer une opération étendue refresh pour récupérer le CRP dans la responseTtl.

  Les client ne doivent pas demander des refresh sur des entrées qui n'existent pas et devraient toujours être prêt à manipuler des cas d'entrées expirées. Les clients devraient également être préparés à des opération de refresh qui échouent (ex: un proxy down).

Prérequis serveur

   Les serveur sont responsables de la suppression des objets expirés, mais il n'est pas requis qu'ils le fasse immédiatement.
^
25 septembre 2013

htmlpdflatexmanmd




rfc2696

rfc2696

Extension de contrôle pour la manipulation des résultats paginés

   Ce contrôle permet à un client de contrôler la quantité de résultat retourné par le serveur lors d’une opération de recherche. Utile lorsqu’un client a des ressources limitées et peut ne pas être en mesure de traiter le résultat entièrement, ou lorsqu’un client est connecté sur un connection à faible bande passante.

  Ce contrôle est inclus dans les messages searchRequest et searchResultDone.

La structure de ce contrôle est la suivante:
pagedResultsControl ::= SEQUENCE {
    controlType 1.2.840.113556.1.4.319,
    criticality BOOLEAN DEFAULT FALSE,
    controlValue searchControlValue
}

searchControlValue est une chaîne encodée BER de la séquence suivante:
realSearchControlValue ::= SEQUENCE {
    size INTEGER (0..maxInt),
    -- requested page size from client
    -- result set size estimate from server
    cookie OCTET STRING
}

Intéraction client-serveur

   Un client peut spécifier un pagedResultsControl avec la taille de page et un cookie vide. La taille de page peut être supérieur à 0 et inférieur à sizeLimit.

   Si la taille de page est supérieur ou égale à sizeLimit, le serveur devrait ignorer ce contrôle. Si le serveur ne supporte pas ce contrôle le serveur doit retourner une erreur unsupportedCriticalExtension si le client a positionné criticality, sinon le serveur devrait ignorer le contrôle.

   Chaque fois que le serveur retourne un jeu de résultat au client, le serveur inclus le contrôle unsupportedCriticalExtension dans le message searchResultDone. Dans le contrôle retourné, la taille peut être définie à l’estimation du serveur du nombre total d’entrées à retourner. les serveurs qui ne peuvent pas l’estimer devraient retourner 0. Le cookie doit être mis à une valeur vide s’il n’y plus d’entrée à retourner.

   Le client doit considérer le cookie comme opaque et ne s’occupe pas de son contenu. Quand le client veut récupérer plus d’entrées, il doit envoyer une searchRequest avec toutes les valeurs identique à la requête initiale à l’exception du cookie, et optionnellement une taille de page modifiée. le cookie à fournir dans la requête est le dernier cookie reçu.

   Une séquence est abandonnée par une requête qui contient pagedResultsControl de 0 et le dernier cookie retourné par le client. Un client peut utiliser l’opération abandon pour abandonner la recherche, mais ce n’est pas encouragé et peut invalider le cookie du client.

   Si le serveur ne peut pas continuer une opération paginé, il devrait retourner l’erreur appropriée dans une entrée searchResultDone, le client et le serveur devraient considérer le jeu de résultat terminé et non-récupérable.

Exemples

le client envoie une requête avec une résultat paginé à 3:
C: SearchRequest + pagedResultsControl(3,"")
Le serveur répond avec 3 entrées et une indication du nombre total d’entrées (5) dans le résultat et un cookie à utiliser pour la suite
S: SearchResultEntry
S: SearchResultEntry
S: SearchResultEntry
S: SearchResultDone + pagedResultsControl(5, "opaque")
Le client envoie la même requête en changeant simplement le cookie, demande la page suivante:
C: SearchRequest + PagedResultsControl(3, "opaque")
Le serveur répond avec le 2 dernière entrées en indiquant qu’il n’y a plus d’entrées:
S: SearchResultEntry
S: SearchResultEntry
S: SearchResultDone + pagedResultsControl(5,"")
^
10 novembre 2013

htmlpdflatexmanmd




rfc2798

rfc2798

inetOrgPerson

Attributs

carLicense: licence ou pluque d'enregistrement associée à un individu
( 2.16.840.1.113730.3.1.1 NAME 'carLicense'
    DESC 'vehicle license or registration plate'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

departmentNumber: Code de département (ex: 1234 ou ABC/123)
( 2.16.840.1.113730.3.1.2
    NAME 'departmentNumber'
    DESC 'identifies a department within an organization'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

displayName: Identifie un nom à utiliser pour cette entrée
( 2.16.840.1.113730.3.1.241
    NAME 'displayName'
    DESC 'preferred name of a person to be used when displaying entries'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

employeeNumber: Id assigné à une personne.
( 2.16.840.1.113730.3.1.3
    NAME 'employeeNumber'
    DESC 'numerically identifies an employee within an organization'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

employeeType: Identifie la relation employeur/employé.
( 2.16.840.1.113730.3.1.4
    NAME 'employeeType'
    DESC 'type of employment for a person'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

jpegPhoto: Photos d'une personne
( 0.9.2342.19200300.100.1.60
    NAME 'jpegPhoto'
    DESC 'a JPEG image'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )

preferredLanguage: Langages préféré, parlé ou lu.
( 2.16.840.1.113730.3.1.39
    NAME 'preferredLanguage'
    DESC 'preferred written or spoken language for a person'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

userSMIMECertificate: certificat de la personne
( 2.16.840.1.113730.3.1.40
    NAME 'userSMIMECertificate'
    DESC 'PKCS#7 SignedData used to support S/MIME'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

userPKCS12: PFX qui identifie une personne
( 2.16.840.1.113730.3.1.216
    NAME 'userPKCS12'
    DESC 'PKCS #12 PFX PDU for exchange of personal identity information'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

ObjectClass


( 2.16.840.1.113730.3.2.2
NAME 'inetOrgPerson'
    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
    )
)

^
26 septembre 2013

htmlpdflatexmanmd




rfc2849

rfc2849

LDAP Data Interchange Format

Définition de la syntaxe formelle:
ldif-file = ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-changes = version-spec 1*(1*SEP ldif-change-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
ldif-change-record = dn-spec SEP *control changerecord
version-spec = "version:" FILL version-number
version-number = 1*DIGIT ; version-number MUST be "1" for the LDIF format described in this document.
dn-spec = "dn:" (FILL distinguishedName / ":" FILL base64-distinguishedName)
distinguishedName = SAFE-STRING ; a distinguished name
base64-distinguishedName = BASE64-UTF8-STRING ; a distinguishedName which has been base64 encoded
rdn = SAFE-STRING a relative distinguished name
base64-rdn = BASE64-UTF8-STRING an rdn which has been base64 encoded
control = "control:" FILL ldap-oid ; controlType
    0*1(1*SPACE ("true" / "false")) ; criticality
    0*1(value-spec) ; controlValue
    SEP
ldap-oid = 1*DIGIT 0*1("." 1*DIGIT) An LDAPOID
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" ( FILL 0*1(SAFE-STRING) /
    ":" FILL (BASE64-STRING) /
    "‹" FILL url)
url = ‹a Uniform Resource Locator
AttributeDescription = AttributeType [" ;" options]
AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
options = option / (option " ;" options)
option = 1*opt-char
attr-type-chars = ALPHA / DIGIT / "-"
opt-char = attr-type-chars
changerecord = "changetype:" FILL
    (change-add / change-delete /
    change-modify / change-moddn)
change-add = "add" SEP 1*attrval-spec
change-delete = "delete" SEP
change-moddn = ("modrdn" / "moddn") SEP
    "newrdn:" ( FILL rdn /
    ":" FILL base64-rdn) SEP
    "deleteoldrdn:" FILL ("0" / "1") SEP
    0*1("newsuperior:"
( FILL distinguishedName /
    ":" FILL base64-distinguishedName) SEP)
change-modify = "modify" SEP *mod-spec
mod-spec = ("add:" / "delete:" / "replace:")
    FILL AttributeDescription SEP
    *attrval-spec
    "-" SEP
SPACE = %x20 ; ASCII SP, space
FILL = *SPACE
SEP = (CR LF / LF)
CR = %x0D ; ASCII CR, carriage return
LF = %x0A ; ASCII LF, line feed
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F ; any value ‹= 127 decimal except NUL, LF, and CR
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
    %x21-39 / %x3B / %x3D-7F
    ; any value ‹= 127 except NUL, LF, CR,
    ; SPACE, colon (":", ASCII 58 decimal)
    ; and less-than ("‹" , ASCII 60 decimal)
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 /
    UTF8-4 / UTF8-5 / UTF8-6
UTF8-STRING = *UTF8-CHAR
BASE64-UTF8-STRING = BASE64-STRING ; MUST be the base64 encoding of a UTF8-STRING
BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A / %x61-7A ; +, /, 0-9, =, A-Z, and a-z
BASE64-STRING = [*(BASE64-CHAR)]

Notes sur la syntaxe LDIF

1 - Pour la version décrite dans ce document, la version est 1.
2 - toute ligne non vide, y compris les commentaires peuvent être coupé en insérant un SEP et un SPACE. Il ne doit pas se produire avant le premier caractère de la ligne.
3 - toute ligne qui commence par '#' est un commentaire et est ignoré.
4 - Tout dn ou rdn qui contient des caractères autre que ceux de SAFE-UTF8-CHAR, ou commençant avec un caractère autre que SAFE-INIT-UTF8-CHAR, doivent être encodé en base64.
5 - Quand une valeur d'attribut vide doit être inclus dans le fichier LDIF, elle doit être représenté comme attributeDescription ":" FILL SEP. 'ex: "seeAlseo:" suivie d'une nouvelle ligne)
6 - Quand une URL est spécifiée dans un attrval-spec, les conventions suivantes s'appliquent:

        -a- Les implémentations devraient supporter le format d'url file://
        -b- les implémentations peuvent supporter d'autre formats d'URL

7 - les DN, DN et valeurs d'attributs de syntaxe DirectoryString doivent être des chaîne UTF8 valides.
8 - Les valeurs ou DN qui se terminent avec SPACE devraient être encodée en base64.
9 - Quand les contrôles sont inclus dans un fichier LDIF, les implémentations peuvent choisir d'ignorer certains d'entre-eux. Si la criticité d'un contrôle est "true", l'implémentation doit soit inclure le contrôle, ou ne pas envoyer l'opération au serveur.
10 - Quand un attrval-spec, DN ou RDN est encodé base64, les règles d'encodage spécifiées en 5 sont utilisée avec les exceptions suivantes:

        -a- Il n'y a pas d'exigence que le flux de sortie soit être représenté en ligne de 76 caractère max
        -b- Les chaînes base64 peuvent contenir des caractères autre que BASE6-CHAR, mais sont ignorés

Exemples

Un simple LDIF avec 2 entrées:
version: 1
dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
telephonenumber: +1 408 555 1212
description: A big sailing fan.
    
dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bjorn Jensen
sn: Jensen
telephonenumber: +1 408 555 1212

Un fichier contenant un entrée avec une valeur coupée:
version: 1
dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
objectclass:top
objectclass:person
objectclass:organizationalPerson
cn:Barbara Jensen
cn:Barbara J Jensen
cn:Babs Jensen
sn:Jensen
uid:bjensen
telephonenumber:+1 408 555 1212
description:Babs is a big sailing fan, and travels extensively in sea
    rch of perfect sailing conditions.
title:Product Manager, Rod and Reel Division

Un fichier contenant une valeur encodée en base64:
version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
uid: gernj
telephonenumber: +1 408 555 1212
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
B3V0IG1vcmUu

Un fichier contenant un entrée avec des valeurs d'attribut encodés en UTF8, incluant un tag de langage.
version: 1
dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: ou=‹JapaneseOU›,o=Airius
objectclass: top
objectclass: organizationalUnit
ou:: 5Za25qWt6YOo
# ou:: ‹JapaneseOU›
ou ;lang-ja:: 5Za25qWt6YOo
# ou ;lang-ja:: ‹JapaneseOU›
ou ;lang-ja ;phonetic:: 44GI44GE44GO44KH44GG44G2
# ou ;lang-ja:: ‹JapaneseOU_in_phonetic_representation›
ou ;lang-en: Sales
description: Japanese office
    
dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: uid=‹uid›,ou=‹JapaneseOU›,o=Airius
userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: rogasawara
mail: rogasawara@airius.co.jp
givenname ;lang-ja:: 44Ot44OJ44OL44O8
# givenname ;lang-ja:: ‹JapaneseGivenname›
sn ;lang-ja:: 5bCP56yg5Y6f
# sn ;lang-ja:: ‹JapaneseSn›
cn ;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn ;lang-ja:: ‹JapaneseCn›
title ;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
# title ;lang-ja:: ‹JapaneseTitle›
preferredlanguage: ja
givenname:: 44Ot44OJ44OL44O8
# givenname:: ‹JapaneseGivenname›
sn:: 5bCP56yg5Y6f
# sn:: ‹JapaneseSn›
cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn:: ‹JapaneseCn›
title:: 5Za25qWt6YOoIOmDqOmVtw==
# title:: ‹JapaneseTitle›
givenname ;lang-ja ;phonetic:: 44KN44Gp44Gr44O8
# givenname ;lang-ja ;phonetic::
‹JapaneseGivenname_in_phonetic_representation_kana›
sn ;lang-ja ;phonetic:: 44GK44GM44GV44KP44KJ
# sn ;lang-ja ;phonetic:: ‹JapaneseSn_in_phonetic_representation_kana›
cn ;lang-ja ;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
# cn ;lang-ja ;phonetic:: ‹JapaneseCn_in_phonetic_representation_kana›
title ;lang-ja ;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
# title ;lang-ja ;phonetic::
# ‹JapaneseTitle_in_phonetic_representation_kana›
givenname ;lang-en: Rodney
sn ;lang-en: Ogasawara
cn ;lang-en: Rodney Ogasawara
title ;lang-en: Sales, Director

Un fichier contenant une référence à un fichier externe
version: 1
dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Horatio Jensen
    
cn: Horatio N Jensen
sn: Jensen
uid: hjensen
telephonenumber: +1 408 555 1212
jpegphoto:‹ file:///usr/local/directory/photos/hjensen.jpg

Un fichier contenant une série de changements et commentaires:
version: 1
# Ajouter une nouvelle entrée
dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Fiona Jensen
sn: Jensen
uid: fiona
telephonenumber: +1 408 555 1212
jpegphoto:‹ file:///usr/local/directory/photos/fiona.jpg
    
# Supprimer une entrée existante
dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
changetype: delete
    
# Modifier le rdn d'une entrée
dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
changetype: modrdn
newrdn: cn=Paula Jensen
deleteoldrdn: 1
    
# Renommer une entrrée et la déplacer
dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
changetype: modrdn
newrdn: ou=Product Development Accountants
deleteoldrdn: 0
newsuperior: ou=Accounting, dc=airius, dc=com
# Modifier une entrée. Ajouter une valeur, en supprimer une, en remplacer
une et supprimer une valeur spécifique.
dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
changetype: modify
add: postaladdress
postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
-
delete: description
-
replace: telephonenumber
telephonenumber: +1 408 555 1234
telephonenumber: +1 408 555 5678
-
delete: facsimiletelephonenumber
facsimiletelephonenumber: +1 408 555 9876
-
# autre exemple de modification: vider les valeurs d'un attribut, et
supprimer complètement un attribut
dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
changetype: modify
replace: postaladdress
-
delete: description
-

Un fichier LDIF contenant un changement avec un contrôle
version: 1
dn: ou=Product Development, dc=airius, dc=com
control: 1.2.840.113556.1.4.805 true
changetype: delete

^
25 septembre 2013

htmlpdflatexmanmd




rfc2891

rfc2891

Extension de contrôle pour le trie des résultats de recherche coté serveur

   Ces contrôles permettent à un client de spécifier les attributs et règles de correspondance qu'un serveur devrait utiliser pour retourner les résultats. Ces contrôles peuvent être utiles quand un client a des fonctionnalités limitées ou ne peuvent pas trier les résultats, mais nécessite que le résultat soit trié. Les contrôles de trie permettent de retourner un code de résultat pour le trie qui est indépendant du code de résultat retourné.

Requête

controleType vaut "1.2.840.113556.1.4.473"
controlValue vaut:


SortKeyList ::= SEQUENCE OF SEQUENCE
{ attributeType AttributeDescription,
    orderingRule [0] MatchingRuleId OPTIONAL,
    reverseOrder [1] BOOLEAN DEFAULT FALSE }

SortListKey est une séquence ordonnée pour le trie.
MatchingRuleId devrait être un valide pour le type d'attribut auquel il s'applique.

Réponse

Ce contrôle est inclus dans le message searchResultDone.
SortResult ::= SEQUENCE {
    sortResult ENUMERATED {
    success (0), — results are sorted
    operationsError (1), — server internal failure
    timeLimitExceeded (3), — timelimit reached before sorting was completed
    strongAuthRequired (8), — refused to return sorted results via insecure protocol
    adminLimitExceeded (11), — too many matching entries for the server to sort
    noSuchAttribute (16), — unrecognized attribute type in sort key
    inappropriateMatching (18), — unrecognized or inappropriate matching rule in sort key
    insufficientAccessRights (50), — refused to return sorted results to this client
    busy (51), — too busy to process
    unwillingToPerform (53), — unable to sort
    other (80)
},
attributeType [0] AttributeDescription OPTIONAL }

Intéraction Client-Serveur

   sortKeyRequestControl spécifie un ou plusieurs types d'attributs et de règles de correspondance pour les résultats retournés par une recherche.

  Le serveur devrait retourner tous les résultats dans l'ordre spécifié. Si reverseOrder est à TRUE le résultat sera inversé.

  Il y'a 6 scénarios possibles qui peuvent se produire en résultat au contrôle de trie inclue dans la requête:

1- Si le serveur ne supporte pas ce contrôle et que le client met le champs criticality, le serveur doit retourner unavailableCriticalExtension.
2- Si le serveur ne supporte par ce contrôle et que criticality est FALSE, le serveur doit ignorer le contrôle et traiter la requête.
3- Si le serveur supporte ce contrôle mais ne peut pas trier le résultat avec les clés spécifiées et que le champs criticality est mis, le serveur devrait retourner unavailableCriticalExtension
4- Si le serveur supporte ce contrôle mais ne peut pas trier le résultat avec les clés spécifiées et que le champs criticality est FALSE, le serveur devrait retourner tous les résultats non triés. et inclure sortKeyResponseControl dans searchResultDone.
5- Si le serveur supporte ce contrôle et peut trier le résultat en utilisant les clés spécifiées, il devrait inclure le sortKeyResponseControl dans searchResultDone avec sortResult à success.
6- Si la recherche échoue ou qu'il n'y a pas de résultat le serveur devrait omettre le sortKeyResponseControl du searchResultDone.

   Le client est assuré que le résultat est trié uniquement si le code de résultat dans sortKeyResponseControl est à success.

   Si un client demande un trie à un serveur qui chaîne la requête et récupère des entrées depuis plusieurs serveurs, et que criticality est positionné, le serveur doit fusionner le résultat avant de les retourner au client ou doit retourner unwillingToPerform

   Quand sortKeyRequestControl est utilisé avec pagedResultsControl , le serveur devrait envoyer les messages searchResultEntry triés avec les clés appliqués au résultat total, et non sur les pages. sortKeyList doit être présent sur chaque message searchRequest pour le résultat paginé. Il ne doit pas changer entre les searchRequests pour le même résultat.
^
03 novembre 2013

htmlpdflatexmanmd




rfc2985

rfc2985

PKCS#9: Définition des attributs et classes d'objets

objectClass

pkcsEntity general-purpose auxiliary obj for PKCS-related entities
( 1.2.840.113549.1.9.24.1 NAME 'pkcsEntity' SUP top AUXILIARY MAY ( pKCS7PDU & userPKCS12 & pKCS15Token & encryptedPrivateKeyInfo ) )
naturalPerson general-purpose auxiliary obj about human beings
( 1.2.840.113549.1.9.24.2 NAME 'naturalPerson' SUP top AUXILIARY MAY ( emailAddress $ unstructuredName $ unstructuredAddress $ dateOfBirth & placeOfBirth & gender & countryOfCitizenship & countryOfResidence & pseudonym & serialNumber ) )

Attributes

pKCS7PDU
( 1.2.840.113549.1.9.25.5 NAME 'pKCS7PDU' DESC 'PKCS #7 ContentInfo PDU' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
userPKCS12
( 2.16.840.1.113730.3.1.216 NAME 'userPKCS12' DESC 'PKCS #12 PFX PDU for exchange of personal information' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
pKCS15Token
( 1.2.840.113549.1.9.25.1 NAME 'pKCS15Token' DESC 'PKCS #15 token PDU' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
encryptedPrivateKeyInfo
( 1.2.840.113549.1.9.25.2 NAME 'encryptedPrivateKeyInfo' DESC 'PKCS #8 encrypted private key info' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
emailAddress
( 1.2.840.113549.1.9.1 NAME 'emailAddress' DESC 'Email address' EQUALITY pkcs9CaseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
unstructuredName
( 1.2.840.113549.1.9.2 NAME 'unstructuredName' DESC 'PKCS #9 unstructured name' EQUALITY pkcs9CaseIgnoreMatch SYNTAX 1.2.840.113549.1.9.26.1 )
unstructuredAddress
( 1.2.840.113549.1.9.8 NAME 'unstructuredAddress' DESC 'PKCS #9 unstructured address' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
dateOfBirth
( 1.3.6.1.5.5.7.9.1 NAME 'dateOfBirth' DESC 'Date of birth' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
placeOfBirth
( 1.3.6.1.5.5.7.9.2 NAME 'placeOfBirth' DESC 'Place of birth' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
gender
( 1.3.6.1.5.5.7.9.3 NAME 'gender' DESC 'Gender' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 SINGLE-VALUE )
countryOfCitizenship
( 1.3.6.1.5.5.7.9.4 NAME 'countryOfCitizenship' DESC 'Country of citizenship' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
countryOfResidence
( 1.3.6.1.5.5.7.9.5 NAME 'countryOfResidence' DESC 'Country of residence' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
pseudonym
( 2.5.4.65 NAME 'pseudonym' DESC 'Pseudonym' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
contentType
( 1.2.840.113549.1.9.3 NAME 'contentType' DESC 'PKCS #7 content type attribute' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE )
messageDigest
( 1.2.840.113549.1.9.4 NAME 'messageDigest' DESC 'PKCS #7 mesage digest attribute' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )
signingTime
( 1.2.840.113549.1.9.5 NAME 'signingTime' DESC 'PKCS #7 signing time' EQUALITY signingTimeMatch SYNTAX 1.2.840.113549.1.9.26.2 SINGLE-VALUE )
counterSignature
( 1.2.840.113549.1.9.6 NAME 'counterSignature' DESC 'PKCS #7 countersignature' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
challengePassword
( 1.2.840.113549.1.9.7 NAME 'challengePassword' DESC 'Challenge password for certificate revocations' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

Matching Rules

pkcs9CaseIgnoreMatch
( 1.2.840.113549.1.9.27.1 NAME 'pkcs9CaseIgnoreMatch' SYNTAX 1.2.840.113549.1.9.26.1 )
signingTimeMatch
( 1.2.840.113549.1.9.27.3 NAME 'signingTimeMatch' SYNTAX 1.2.840.113549.1.9.26.2 )
^
06 novembre 2013

htmlpdflatexmanmd




rfc3045

rfc3045

Sockage des informations de vendeur dans le root DSE

   Les clients LDAP découvrent des données spécifique au serveur tel que les contrôles et extensions en lisant le root DSE. Il est souhaitable de pouvoir découvrir le vendeur et la version du serveur.

Types d'attributs

vendorName
( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
vendorVersion
( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
^
27 octobre 2013

htmlpdflatexmanmd




rfc3062

rfc3062

Opération Password Modify

   L'intégration de LDAP et des services d'authentification externes a introduit des identités d'authentification non-DN et permis la décentralisation du stockage des mots de passe. Ainsi, les mécanismes de mise à jours de l'annuaire ne peuvent pas être utilisés pour changer les mots de passe.

Requête et réponse

L'opération étendue Password Modify est identifiée par l'OID passwdModifyOID:
passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.1
PasswdModifyRequestValue ::= SEQUENCE {
    userIdentity [0] OCTET STRING OPTIONAL
    oldPasswd [1] OCTET STRING OPTIONAL
    newPasswd [2] OCTET STRING OPTIONAL }
PasswdModifyResponseValue ::= SEQUENCE {
    genPasswd [0] OCTET STRING OPTIONAL }

   Une requête est une ExtendedRequest avec le champ requestName contenant le passwdModifyOID et fournis optionnellement un champs requestValue, qui devrait contenir un PasswdModifyRequestValue avec un ou plusieurs champs présents.

Le champ userIdentity, si présent, devrait contenir une chaîne représentant l'utilisateur associé avec la requête. Si ce champs n'est pas présent, la requête agis sur le mot de passe de l'utilisateur associé avec la session LDAP.
Le champ oldPasswd, si présent, devrait contenir le mot de passe courant de l'utilisateur
Le champ newPasswd, si présent, devrait contenir le nouveau mot de passe de l'utilisateur

Prérequis

   Les clients ne devraient pas envoyer de requête sans s'assurer d'une sécurité adéquate. Les serveurs devraient retourner une erreur si la protection n'est pas suffisante.

  Les serveurs devraient indiquer leur support pour cette opération étendu en fournissant PasswdModifyOID dans supportedExtension.

  Si le serveur ne reconnaît pas les champs ou ne supporte pas la combinaison des champs fournis, il ne devrait pas changer le mot de passe.

  Si oldPasswd est présent et que sa valeur ne peut être vérifiée ou est incorrect, le serveur ne devrait pas changer le mot de passe de l'utilisateur.

   Le serveur ne devrait pas générer un mot de passe si le client a fournis un nouveau mot de passe. Si un client ne fournis pas de nouveau mot de passe, le serveur devrait soit générer un mot de passe, ou retourner une erreur.

  Le serveur peut retourner adminLimitExceeded, busy, confidentialityRequirement, operationError, unavailable, unwillingToPerform, ou un autre resultCode s'il n'est pas en mesure de compléter l'opération.

  Les serveurs peuvent implémenter des stratégies administratives pour restreindre cette opération.
^
22 mai 2015

htmlpdflatexmanmd




rfc3088

rfc3088

OpenLDAP Root Service - Service de référencement LDAP expérimental

   Le projet OpenLDAP opère comme service de référencement d'accès aux annuaires LDAP, connu comme le "OpenLDAP Root Service". Le système Automatisé génère des références basée sur les informations d'emplacement de service publiées dans les enregistrement DNS SRV RR. Ce document décris ce service.

   Les annuaires LDAP utilisent un schéma de nommage hiérarchique hérité de X.500. Traditionnellement, les déploiements X.500 ont utilisé un schéma de nommage géo-politique. Cependant, l'infrastructure d'enregistrement et les services de localisation dans beaucoups de portions du nommage hiérarchique sont inadéquates ou non-existants.

   La construction d'un annuaire global nécessite une infrastructure d'enregistrement et un service de localisation robuste. L'utilisation du nommage basé sur le domaine internet permet aux services d'annuaire LDAP de faire un levier vers une infrastructure d'enregistrement DNS des enregistrement de ressource DNS SRV existants pouvant être utilisé pour localiser les services.

   La plupart des implémentations LDAP existantes ne supportent pas la localisation des services d'annuaires en utilisant les DNS SRV RR. Cependant, la plupart des serveurs supportent la génération de références vers des serveurs supérieurs. Ce service fournis un service LDAP root que les serveur peuvent utilisé comme leur service référant supérieur.

   Un client peut également utiliser le service directement pour localiser les services associés avec un DN arbitraire dans la hiérarchie.

   Note: les mécanismes utilisé par le service sont expérimentaux. Les descriptions fournies par ce document ne sont pas définitifs.

Générer des références basées sur les DNS SRV RR

Le service mappe un DN vers un fqdn en utilisant l'algorithme suivant:
domain = null;
foreach RDN left-to-right // [1]
{
    if not multi-valued RDN and RDN.type == domainComponent
    {
        if ( domain == null || domain == "." )
        { // start
            domain = "";
        }
        else
        { // append separator
            domain .= ".";
        }
        if ( RDN.value == "." )
        { // root
            domain = ".";
        }
        else
        { // append domainComponent
            domain .= RDN.value;
        }
        continue;
    }
    domain = null;
}

Exemples

Distinguished Name_________________Domain
----------------------------- ------------
DC=example,DC=net_______________example.net
UID=jdoe,DC=example,DC=net______example.net
DC=.____________________________. [2]
DC=example,DC=net,DC=.__________. [3]
DC=example,DC=.,DC=net__________net [4]
DC=example.net__________________example.net [5]
CN=Jane Doe,O=example,C=US______null
UID=jdoe,DC=example,C=US________null
DC=example,O=example,DC=net_____net
DC=example+O=example,DC=net_____net
DC=example,C=US+DC=net__________null

Notes

0) Une version ultérieur utilisera un mécanisme standardisé
1) Une version ultérieur de ce service peut utiliser un algorithme droit-à-gauche.
2) La rfc2247 ne statut pas sur la manière de mapper le domaine représentant là racine de l'arborescence vers un DN. On suggère que la racine du domaine soit mappé à "DC=." et qu'il soit inversable
3) La rfc2247 statut que le domaine "example.net" devrait être mappé au dn "DC=example,DC=net", et non "DC=example,DC=net,DC=.", ce n'est pas notre intention d'introduire ou supporter un domaine alternatif au mappage de DN.
4) La rfc2247 statut que le domaine "example.net" devrait être mappé au dn "DC=example,DC=net", et non "DC=example,DC=.,DC=net", ce n'est pas notre intention d'introduire ou supporter un domaine alternatif au mappage de DN.
5) La rfc2247 statut que la valeur d'un type d'attribut DC est un composant de domaine. Il ne devrait pas contenir plusieurs composants de domaine multiple. Une version ultérieur de ce service peut mapper ce domaine à null ou être encodé pour retourner un erreur de DN invalide.

   Si le domaine est null ou ".", le service stop tout traitement et retourne noSuchObject. Une version ultérieur de ce service peut annuler le traitement si le domaine résultant est un domaine top-level.

Localiser les services LDAP

   Le service root localise les services associés avec une nom de domaine pleinement qualifié en requêtant le DNS pour les enregistrements de ressoure LDAP SRV. Pour le domaine example.net, le service devrait émettre une demande SRV pour le domaine "_ldap._tcp.example.net". Une requête réussie va retourner un ou plusieurs enregistrements de ressources sous la forme:

  _ldap._tcp.example.net. IN SRV 0 0 389 ldap.example.net.

   Si aucun enregistrement de ressource LDAP SRV n'est retourné ou une erreur DNS se produit, le service annule tout traitement et retourne noSuchObject. Une version ultérieur de ce service gérera mieux les erreurs.

Construire les réferences LDAP

   Pour chaque DNS SRV RR retourné pour le domaine, une URL LDAP est construite. Pour l'enregistrement ci-dessus, l'url serait:

  ldap://ldap.example.net:389/

   Ces URL sont ainsi retournées dans le référant. Les URL sont actuellement retournés dans l'ordre du resolver.

Opérations du protocole

   Cette section décris comment le service effectue des opération LDAP de base. Le service supporte les opérations étendues prévues via certains contrôles.

Opérations de base

   Les opérations de base retournent un résultat référant si le DN cible peut être mappé à un jeu d'URLs LDAP comme décris ci-dessus. Sinon, une réponse noSuchObject ou autre réponse appropriée est retournée.

Opération Bind

   Ce service accepte le bind anonyme. Tous les autres bind retournent un code non 0. En particulier, les clients qui envoient des accréditifs en texte claire vont recevoir un unwillingToPerform avec un texte d'avertissement. Vu que ce service est en lecture seule, l'authentification lDAP v3 n'est pas supportée.

Unbind

   Une fois une demande unbind reçue, le serveur abandonne toutes requêtes faites par le client et déconnecte.

Extended

   Le service ne reconnaît actuellement aucune opération étendue.

Update

   Une version future de ce document peut retourner unwillingToPerform pour toutes les opérations de modification vu que c'est un service non authentifié.

Controle ManageDSAit

Le service supporte le contrôle ManageDSAit. Si les informations de l'emplacement DNS sont disponible pour de DN de base lui-même, le service retourne unwillingToPerform pour les opérations autre que de recherche. Pour les opérations de recherche, une entrée va être retourné si elle est dans le scope et correspond au filtre fournis. Par exemple:
c: searchRequest {
    base="DC=example,DC=net"
    scope=base
    filter=(objectClass=*)
    ManageDSAit
}
    
s: searchEntry {
    dn: DC=example,DC=net
    objectClass: referral
    objectClass: extensibleObject
    dc: example
    ref: ldap://ldap.example.net:389/
    associatedDomain: example.net
}
s: searchResult {
    success
}

Si les informations d'emplacement DNS sont disponible pour la portion DC d'une entrée subordonnée, le service retourne noSuchObject avec le matchedDN à la portion DC de la base pour la recherche et les opérations de mise à jours:
c: searchRequest {
    base="CN=subordinate,DC=example,DC=net"
    scope=base
    filter=(objectClass=*)
    ManageDSAit
}
    
s: searchResult {
    noSuchObject
    matchedDN="DC=example,DC=net"
}

Utiliser le service

   Les serveurs peuvent être configurés pour référer les requêtes à ‹ldap://root.openldap.org:389›. Bien que les clients peuvent utiliser le service directement, Ce n'est pas encouragé. Les clients devraient utiliser un service local et utiliser ce service seulement quand il est référencé. Le service supporte LDAPv3 et LDAPv2+ sur TCP/IPv4. Une version future de ce document supportera TCP/IPv6 ou d'autres protocoles de transport/internet.

Disponibilité

   Ce service fonctionne actuellement sur un seul hôte. Cet hôte et les ressources réseaux associées ne sont pas exhaustives. On peut facilement augmenter la disponibilité à la demande. Le service peut également être facilement dupliqué localement.

Interopérabilité du protocole

   Le serveur implémente toutes les fonctionnalités LDAPv3 nécessaire au service. LDAPv2 de supporte pas les referral et donc ne peut pas être utilisé par ce service. LDAPv2+ fournis des extensions à LDAPv2, incluant les référants. Une future version de ce document supprimera le support le LDAPv2+.

Considérations de sécurité

   Ce service fournis des informations aux clients anonymes. Cette information est dérivée des annuaires publiques, appelés DNS.

   L'utilisation de l'authentification nécessiterait aux clients de divulguer des informations au service. Cela serait une invasion non-nécessaire.

   Le manque de chiffrement permet l'écoute des demandes et réponses. Une version ultérieur de ce service pourrait supporter le chiffrement.

   La protection de l'intégrité des informations n'est pas fournie par le service. Le service est sujet à diverses formes d'attaques DNS. Une version ultérieur de ce document peut supporter DNSSEC et fournir une protection d'intégrité.

   Le service est sujet à diverses attaque DOS. Une version ultérieur de ce document nécessiterait une meilleur protection pour de tels attaques.
^
27 octobre 2013

htmlpdflatexmanmd




rfc3112

rfc3112

Schéma de mot de passe d'authentification

   L'attribut userPassword est conçu pour utiliser l'opération simple bind password. Cependant les valeurs de userPassword doivent être des mots de passe en texte clair. L'attribut authPassword est conçus pour stocker des informations utilisées pour implémenter une authentification par mot de passe simple. L'attribut supporte plusieurs schéma de stockage. Une règle de correspondance est fournie pour l'utilisation avec des filtres de recherche qui permettent aux clients d'affirmer qu'un mot de passe matche une des valeurs de l'attribut.

Définition du schéma


( 1.3.6.1.4.1.4203.1.1.2 DESC 'authentication password syntax' )

Les valeurs de cette syntaxe sont encodées en accord avec:
authPasswordValue = w scheme s authInfo s authValue w
scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F ; 0-9, A-Z, "-", ".", "/", or "_"
authInfo = schemeSpecificValue
authValue = schemeSpecificValue
schemeSpecificValue = *( %x21-23 / %x25-7E ) ; printable ASCII less "$" and " "
s = w SEP w
w = *SP
SEP = %x24 ; "$"
SP = %x20 ; " " (space)

   où scheme décrit le mécanisme et authInfo et authValue sont spécifique au schéma. authInfo est souvent un salt encodé en base64. authValue est souvent un dérivé de mot de passe encodé en base 64.

authPasswordExactMatch Règle de correspondance qui permet à un client d'affirmer une valeur authPasswordSyntax (règle d'égalité)
authPasswordMatch Règle de correspondance qui permet à un client d'affirmer qu'un mot depasse match un authPasswordSyntax en utilisant un filtre extensibleMatch.
supportedAuthPasswordSchemes Les valeurs de cet attribut sont des noms de schéma de mot de passe supportés par le serveur
authPassword Les valeurs de cet attribut représentent les mots de passe de l'utilisateur
authPasswordObject Les entrées de cet classe d'objet peuvent contenir un attribut authPassword

authPasswordExactMatch
( 1.3.6.1.4.1.4203.1.2.2
    NAME 'authPasswordExactMatch'
    DESC 'authentication password exact matching rule'
    SYNTAX 1.3.6.1.4.1.4203.1.1.2 )

authPasswordMatch
( 1.3.6.1.4.1.4203.1.2.3
    NAME 'authPasswordMatch'
    DESC 'authentication password matching rule'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )

supportedAuthPasswordSchemes
( 1.3.6.1.4.1.4203.1.3.3
    NAME 'supportedAuthPasswordSchemes'
    DESC 'supported password storage schemes'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
    USAGE dSAOperation )

authPassword
( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword'
    DESC 'password authentication information'
    EQUALITY 1.3.6.1.4.1.4203.1.2.2
    SYNTAX 1.3.6.1.4.1.4203.1.1.2 )

authPasswordObject
( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject'
    DESC 'authentication password mix in class'
    MAY 'authPassword'
    AUXILIARY )

schéma MD5

   authValue est le MD5 digest encodé base64 de la concaténation du mot de passe et du salt. L'encodage base 64 est fournis dans authInfo. Le salt doit faire 64 bits minimum.

schéma SHA1

   authValue est le digest SHA1 encodé base64 de la concaténation du mot de passe et du salt. L'encodage base 64 est fournis dans authInfo Le salt doit faire 64 bits minimum.

Problèmes d'implèmentation

   Les serveurs peuvent restreindre le schéma utilisé en conjonction avec un processus d'authentification particulier. Les serveurs peuvent utiliser d'autres mécanismes de stockage, tel que userPassword ou un stockage externe, en conjonction avec authPassword.

   Les serveurs qui supportent le simple bind doivent supporter SHA1 et devraient supporter MD5.

   Les serveurs ne devraient pas publier ou initier des opérations sur les valeurs de authPassword ni permettre des opérations qui exposent authPassword ou les assertions authPasswordMatch à moins qu'une protection de confidentialité soit en place.

   Les serveur ne devraient pas assumer qu'un AuthPasswordMatch réussi, soit par compare ou par search, est suffisant pour avoir accès à l'annuaire. L'opération bind doit être utilisé pour authentifier l'annuaire.
^
06 novembre 2013

htmlpdflatexmanmd




rfc3296

rfc3296

Named Subordinate References

objectClass

   Détail les éléments du schéma et du protocole pour représenter et gérer les références subordonnées nommées dans LDAP. un objet référant maintient une ou plusieurs URI contenus dans des valeurs de type d'attributs de référence et sont utilisé pour générer des références. Un contrôle, ManageDsaIT, est définis pour permettre de manipuler ces référants et autres objets spéciaux comme des objets spéciaux.

ObjectClass referral

Cette classe d'objet devrait être utilisé en conjonction avec la classe d'objet extensibleObject pour supporter les attributs de nommage utilisé dans le DN de l'entrée. Les objets référrant sont normalement instanciés aux DSE immédiatement subordonnés au entrées dans un contexte de nommage maintenu par le DSA.
( 2.16.840.1.113730.3.2.6 NAME 'referral' DESC 'named subordinate reference object' STRUCTURAL MUST ref )

Type d'attribut ref

Ce type d'attribut a une syntaxe directoryString sensible à la casse et multi-valué. Les valeurs placées dans cet attribut doivent être conforme à la spécification donnée pour l'attribut labeledURI. Si cet attribut réfère à un serveur LDAP, il doit être sous la forme d'URL LDAP. Cette URL LDAP ne devrait pas contenir de scope, filtre, liste d'attribut, ou extension et devrait contenir un DN on-vide.
( 2.16.840.1.113730.3.1.34 NAME 'ref' DESC 'named reference - a labeledURI' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE distributedOperation )

Contrôle ManageDsaIT

   Un client peut fournir le contrôle ManageDsaIT avec une opération pour indiquer que l'opération est de gérer des objets dans le DIT. Ce contrôle indique que les entrée spécifique sont traitées comme des entrées normales.

  Le controlType vaut 2.16.840.1.113730.3.4.2 et controlValue est absent.

Références des subordonnés nommés

   Une référence subordonnée nommée est construite en instançiant un objet referral dans le serveur dé-référençant avec les les valeurs de l'attribut ref. qui pointent vers le subtree correspondant maintenu dans le serveur référencié. En général, le nom de l'objet referral est le même que l'objet référencé et cet objet référencé est un préfixe de contexte.

   Si le serveur A maintient DC=example,dc=net et le serveur B maintient dc=sub,dc=example,dc=net, le serveur A peut contenir un objet referral nommé dc=sub,dc=example,dc=net qui contient un attribut ref avec la valeur ldap ://B/dc=sub,dc=example,dc=net


dn: DC=sub,DC=example,DC=net
dc: sub
ref: ldap://B/DC=sub,DC=example,DC=net
objectClass: referral
objectClass: extensibleObject

   Typiquement, le DN de l'objet referral et le DN de l'objet sur le serveur référencé sont les même. Si l'attribut ref a plusieurs valeurs, tous les DN contenus dans les URL LDAP devraient être équivalent. Les administrateurs devraient éviter de configurer des boucles en utilisant des référants. Les références nommées doivent être traitées comme des entrées normales si la requête inclus le contrôle manageDsaIT.

scénario

   Les sections suivante contiennent des spécifications sur l'utilisation des referral dans différent scénarios. Il est à noter que, dans ce document, une opération de recherche est conceptuellement divisée en 2 phases distincts : 1. trouver l'objet de base où la recherche commence, et 2. effectuer la recherche.

Exemple de configuration

Par exemple, supposons que le serveur contacté (hosta) maintient l'entrée O=MNN,C=WW" et l'entrée "CN=manager,O=MNN,C=WW" et les objets referral suivants:
dn: OU=People,O=MNN,C=WW
ou: People
ref: ldap://hostb/OU=People,O=MNN,C=US
ref: ldap://hostc/OU=People,O=MNN,C=US
objectClass: referral
objectClass: extensibleObject

dn: OU=Roles,O=MNN,C=WW
ou: Roles
ref: ldap://hostd/OU=Roles,O=MNN,C=WW
objectClass: referral
objectClass: extensibleObject

   Le premier referral indique que hostb et hostc maintiennent "OU=People,O=MNN,C=WW". Le second indique que hostd maintient "OU=Roles,O=MNN,C=WW".

Considérations de l'objet cible

   Cette section détail la manipulation des referral pour les opérations add, compare, delete, modify et modrdn. Si le client demande une de ces opérations, il y'a 4 cas que le serveur doit gérer.

   cas 1: l'objet cible n'est pas manipulé parle serveur et n'est pas dans ou subordonné à un contexte de nommage ni subordonné à un referral maintenu par le serveur.

   Le serveur devrait traiter la requête normallement comme approprié pour une base non-exsitante qui n'est pas dans un contexte de nommage du serveur. (retourne générallement noSuchObject ou un referral).

   cas 2: L'objet cible est maintenu par le serveur et est un objet referral.

   Le serveur devrait retourner l'URI contenu dans ref, modifié comme suit.

exemple: Si le client requête une opération modify pour l'objet cible "OU=People,O=MNN,C=WW", le serveur va retourner:
ModifyResponse (referral) {
    ldap ://hostb/OU=People,O=MNN,C=WW
    ldap ://hostc/OU=People,O=MNN,C=WW
}

   cas 3: L'objet cible n'est pas maintenu par le serveur, mais le contexte de nommage le plus proche ne contient pas de referral.

   Si le contexte de nommage le plus proche ne contient pas de referral auquel l'objet cible est subordonné, le serveur devrait traiter la requête de manière appropriée (généralement retourne noSuchObject)

   cas 4: L'objet cible n'est pas maintenu par le serveur, mais le contexte de nommage le plusproche contient un referral.

   Si le client demande une opération pour laquelle l'objet cible n'est pas maintenu par le serveur et que le contexte de nommage le plus proche contient un referral, le serveur devrait retourner une réponse referral contruite avec la portion URI de la valeur ref.

exemple: Si le client fournir une opération add où l'objet cible a un DN de "CN=Manager,OU=Roles,O=MNN,C=WW", le serveur va retourner:
AddResponse (referral) {
    ldap ://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
}

Considérations de l'objet de base

   Cette section détail la manipulation des referral pour le traitement de l'objet de base dans les opérations de recherche, il y'a 4 cas.

   Dans les cas où l'URI retourné est une URL LDAP, le serveur doit fournir un scope explicite avant de le retourner. En plus, la partie DN doit être modifiée de sorte qu'il réfère à la cible appropriée dans le serveur référencé.

   Si le dé-référencement d'alias est nécessaire pour trouver l'objet referral, la partie DN de l'URI doit être remplacée avec le DN de base comme modifié par le dé-référencement d'alias de sorte que l'URL réfère au nouvel objet cible.

   cas 1: L'objet de base n'est pas maintenu par le serveur et n'est pas dans ou subordonné à un contexte de nommage maintenu par le serveur.

   Le serveur devrait traiter la requête normalement comme approprié pour une base non-existante qui n'est pas dans un contexte de nommage du serveur (généralement retourne un referral supérieur ou noSuchObject).

   cas 2: L'objet de base est maintenu par le serveur et est un objet referral.

   Le serveur devrait retourner la valeur URI contenu dans ref, modifié comme indiqué plus haut.

exemple: Si le client requête un recherche subtree avec l'objet de base "OU=Roles,O=MNN,C=WW", le serveur va retourner:
SearchResultDone (referral) {
    ldap ://hostd/OU=Roles,O=MNN,C=WW??sub
}

   cas 3: L'objet de base n'est pas maintenu par le serveur, mais le contexte de nommage le plus proche ne contient pas de referral dont l'objet de base est subordonné. Le serveur devrait retourner noSuchObject

   cas 4: L'objet de base n'est pas maintenu par le serveur, mais le contexte de nommage le plus proche contient un objet referral dont l'objet de base est subordonné. Le serveur devrait retourner une réponse referral qui est construite depuis la portion URI de ref.

exemple: Si le client requête un search sur la base "CN=Manager,OU=Roles,O=MNN,C=WW", le serveur va retourner:
SearchResultDone (referral) {
    ldap ://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
}

Considérations de continuation de recherche

   Pour les opérations de recherche, une fois l'objet de base trouvé et qu'il n'est pas un objet referral, la recherche peut progresser.

   exemple: Si un client requête un search subtree de "O=MNN,C=WW", en plus de toute entrée dans le scope dont le filtre match, hosta va aussi retourner 2 références de recherche en tant que 2 objets referral dans le scope. Une réponse possible peut être :

SearchEntry for O=MNN,C=WW
SearchResultReference {
    ldap://hostb/OU=People,O=MNN,C=WW??sub
    ldap://hostc/OU=People,O=MNN,C=WW??sub
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
    ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
SearchResultDone (success)

exemple avec one level: Si le client effectue la recherche de scope OneLevel, une réponse possible peut être:
SearchResultReference {
    ldap://hostb/OU=People,O=MNN,C=WW??base
    ldap://hostc/OU=People,O=MNN,C=WW??base
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
    ldap://hostd/OU=Roles,O=MNN,C=WW??base
}
SearchResultDone (success)

BindRequest

   Les serveurs ne devraient pas retourner de resultCode referral si un nom bind (ou aun authentication identity ou une authorization identity) est ou est subordonné à un objet referral mais peut utiliser les informations connues pour traiter la requête bind. Si le serveur n'utilise par ces informations, il doit traiter la requête normallement (retourner un invalidCredentials)

Modify DN

   Si le newSuperior est un objet referral ou est subordonné à un objet referral, le serveur devrait retourner un affectsMultipleDSAs. si le newRDN existe déjà mais est un objet referral, le serveur devrait retourner affectsMultipleDSAs au lieu de entryAlreadyExists.
^
25 septembre 2013

htmlpdflatexmanmd




rfc3671

rfc3671

Attributs collectifs

   Les attributs collectifs X500 permettent de partager des caractéristiques communes sur des collections d'entrées. Une collection d'entrées est un groupement d'objets et alias basés sur des propriété communes. Une collection d'entrées consiste de toutes les entrées dans un scope d'atttribus subentry collectifs. Une entrée peut appartenir à plusieurs collections.

   Les attributs partagés par les entrées dans une collection d'entrées sont appelés des attributs collectifs. Les valeurs de ces attributs sont visibles mais non modifiables par les clients. Ils sont modifiable via leur collective attributes subentry associé.

   Les entrées peuvent spécifiquement exclure un attribut collectif particulier en listant l'attribut dans collectiveExclusions. Comme d'autres attributs utilisateurs, les attributs collectifs sont sujet un contrôles d'accès, administratifs et de contenu.

   Les attributs opérationnels suivant sont utilisés pour gérer les attributs collectifs. Les serveurs LDAP doivent agir en accord avec les modèles d'annuaire X500 lorsqu'ils fournissent ce service.

collectiveAttributeSubentry

   Les sous-entrées de cette classe d'objet sont utilisées pour administrer les attributs collectifs et sont référés à des collective attribute subentry.

  ( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY )

   Un collective attribute subentry devrait contenir au moins un attribut collectif. Ces attributs sont disponible pour les opérations de recherche, comparaison pour toutes les entrées dans le scope de la sous-entrée. Les attributs collectifs sont cependant administrés via la sous-entrée. Les implémentations de cette spécification devraient supporter les sous-entrées d'attribut collectif dans les aires administratifs collectiveAttributeSpecificArea (2.5.23.5) et collectiveAttributeInnerArea (2.5.23.6) (RFC3672)

collectiveAttributeSubentries

Identifie toutes les collective atribute subentries qui affectent l'entrée
( 2.5.18.12 NAME 'collectiveAttributeSubentries'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE directoryOperation NO-USER-MODIFICATION )

collectiveExclusions

Permet d'exclure des attributs collectifs d'une entrée
( 2.5.18.7 NAME 'collectiveExclusions'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE directoryOperation )

Collective Attribute Types

   Un type d'attribut utilisateur peut être définis comme collectif. Celà indique que ce même attribut va apparaitre dans les entrées d'une collection sujet à l'utilisation de l'attribut collectiveExclusions et autres contrôles administratifs. Les types d'attributs collectifs sont communément définis comme sous-type des types non collectifs. Par convention, les attributs collectifs sont nommés en préfixant le nom de leur supertype non collectif avec "c-". Par exemple, l'attribut telephoneNumber est nommé c-telephoneNumber.

   Les attributs collectifs ne devraient pas être SINGLE-VALUED et ne devraient pas apparaître dans les types d'attributs d'une définition de classe d'objet. Les attributs opérationnels ne devraient pas être définis comme collectif.


Collective Locality Name ( 2.5.4.7.1 NAME 'c-l' SUP l COLLECTIVE )
    
Collective State or Province Name ( 2.5.4.8.1 NAME 'c-st' SUP st COLLECTIVE )
    
Collective Street Address ( 2.5.4.9.1 NAME 'c-street' SUP street COLLECTIVE )
    
Collective Organization Name ( 2.5.4.10.1 NAME 'c-o' SUP o COLLECTIVE )
    
Collective Organizational Unit Name ( 2.5.4.11.1 NAME 'c-ou' SUP ou COLLECTIVE )
    
Collective Postal Address ( 2.5.4.16.1 NAME 'c-PostalAddress' SUP postalAddress COLLECTIVE )
    
Collective Postal Code ( 2.5.4.17.1 NAME 'c-PostalCode' SUP postalCode COLLECTIVE )
    
Collective Post Office Box ( 2.5.4.18.1 NAME 'c-PostOfficeBox' SUP postOfficeBox COLLECTIVE )
    
Collective Physical Delivery Office Name ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName' SUP physicalDeliveryOfficeName COLLECTIVE )
    
Collective Telephone Number ( 2.5.4.20.1 NAME 'c-TelephoneNumber' SUP telephoneNumber COLLECTIVE )
    
Collective Telex Number ( 2.5.4.21.1 NAME 'c-TelexNumber' SUP telexNumber COLLECTIVE )
    
Collective Facsimile Telephone Number ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber' SUP facsimileTelephoneNumber COLLECTIVE )
    
Collective International ISDN Number ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber' SUP internationalISDNNumber COLLECTIVE )

^
26 septembre 2013

htmlpdflatexmanmd




rfc3672

rfc3672

Subentries dans LDAP

   Dans les annuaires X500, les sous-entrées sont des entrées spéciales utilisées pour maintenir des informations associées avec une sous-arborescence. C’est un type d’entrée spécial subordonné à un point administratif. Il contient des attributs qui sont pertinents pour une sous-arborescence. Les sous-entrées et leur point administratif font partie du même contexte de nommage. Une simple sous-entrée peut servir de nombreux aspects de l’autorité administrative.

Subtree Specification Syntax

   Fournis un mécanisme général pour la spécification de jeu d’entrées dans une sous-arborescence du DIT. une sous-arborescence commence à une entrée de base et inclus tous les subordonnés. une subtree specification est toujours utilisée dans un contexte ou un scope qui détermine implicitement les limites de la sous-arborescence. Cette syntaxe correspond au type SubtreeSpecification (X501):


SubtreeSpecification ::= SEQUENCE {
    base [0] LocalName DEFAULT { },
    COMPONENTS OF ChopSpecification,
    specificationFilter [4] Refinement OPTIONAL }
    
LocalName ::= RDNSequence
ChopSpecification ::= SEQUENCE {
specificExclusions [1] SET OF CHOICE {
chopBefore [0] LocalName,
chopAfter [1] LocalName } OPTIONAL,
minimum [2] BaseDistance DEFAULT 0,
maximum [3] BaseDistance OPTIONAL }
    
BaseDistance ::= INTEGER (0 .. MAX)
    
Refinement ::= CHOICE {
item [0] OBJECT-CLASS.&id,
and [1] SET OF Refinement,
or [2] SET OF Refinement,
not [3] Refinement }

La syntaxe LDAP est :
( 1.3.6.1.4.1.1466.115.121.1.45 DESC ’SubtreeSpecification’ )

base Le composant base nomme l’entrée de base de la sous-arborescence. cette entrée peut être une sequence de RDN relatif à l’entrée root, ou vide si la base est le root lui-même.
Specific Exclusion Liste d’exclusion qui spécifie les entrées et leur subordonnés à exclure de l’arborescence. chaque entrée est une sequence de RDN relatif à l’entrée de base. Chaque exclusion est de forme chopBefore ou chopAfter. chopBefore exclue l’entrée et ses subordonnées, chopAfter exclue seulement les subordonnés.
Minimum est Maximum Permettent l'exclusion d'entrées basé sur leur profondeur dans le DIT
Specification Filter Expression booléenne sur l’assertion des valeurs de l’attribut objectClass de l’entrée de base et ses subordonnés. un élément d’assertion est évalué à TRUE pour une entrée si l’attribut objectClass de l’entrée contient l’OID nommé.

Types d'attributs de rôle administratif

L’attribut opérationnel administrativeRole est spécifié comme suit:
( 2.5.18.5 NAME ’administrativeRole’
    EQUALITY objectIdentifierMatch
    USAGE directoryOperation
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

Les valeurs possible pour cette attribut sont définis dans X.501:
2.5.23.1 autonomousArea
2.5.23.2 accessControlSpecificArea
2.5.23.3 accessControlInnerArea
2.5.23.4 subschemaAdminSpecificArea
2.5.23.5 collectiveAttributeSpecificArea
2.5.23.6 collectiveAttributeInnerArea

   L’attribut opérationnel administrativeRole est aussi utilisé pour réguler les sous-entrées qui ont le droit d’être subordonné à une entrée administrative. Une sous-entrée qui n’est pas d’une classe permise ne peut pas être subordonnée à cette entrée administrative.

Type d’attribut de spécification de sous-arborescence.
( 2.5.18.6 NAME ’subtreeSpecification’
    SINGLE-VALUE
    USAGE directoryOperation
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )

   Cet attribut est présent dans toutes les sous-entrées. nomme les collections d’entrées dans le DIT pour un ou plusieurs aspects de l’autorité administrative.

Classe d’objet subentry
( 2.5.17.0 NAME ’subentry’
    SUP top STRUCTURAL
    MUST ( cn $ subtreeSpecification ) )

Contrôle des sous-entrées

   Le contrôle des subentry peut être envoyé avec un searchRequest pour contrôler la visibilité des entrées qui sont dans le scope. Le contrôle est un contrôle LDAP dont controlType est 1.3.6.1.4.1.4203.1.10.1, et controlValue contient un booleen encodé BER indiquant la visibilité. Noter que la visibilité à true vaut { 01 01 FF } et FALSE vaut { 01 01 00 }.

Considérations de sécurité

   Les subentry maintiennent des informations administratives ou autre informations sensibles et devraient être protégés des accès non-autorisé.

Descripteurs
NAME Type OID
---- --------
accessControlInnerArea R 2.5.23.3
accessControlSpecificArea R 2.5.23.2
administrativeRole A 2.5.18.5
autonomousArea R 2.5.23.1
collectiveAttributeInnerArea R 2.5.23.6
collectiveAttributeSpecificArea R 2.5.23.5
subentry O 2.5.17.0
subschemaAdminSpecificArea R 2.5.23.4
subtreeSpecification A 2.5.18.6

A: Attribute
O: objectClass
R: Administrative Role

Subtree spécification ABNF:
SubtreeSpecification = "{" [ sp ss-base ]
    [ sep sp ss-specificExclusions ]
    [ sep sp ss-minimum ]
    [ sep sp ss-maximum ]
    [ sep sp ss-specificationFilter ]
    sp "}"
    
ss-base = id-base msp LocalName
ss-specificExclusions = id-specificExclusions msp
SpecificExclusions
ss-minimum = id-minimum msp BaseDistance
ss-maximum = id-maximum msp BaseDistance
ss-specificationFilter = id-specificationFilter msp Refinement
    
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
%x69.6F.6E.73 ; "specificExclusions"
id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
%x69.6C.74.65.72 ; "specificationFilter"
    
SpecificExclusions = "{" [ sp SpecificExclusion
*( "," sp SpecificExclusion ) ] sp "}"
SpecificExclusion = chopBefore / chopAfter
chopBefore = id-chopBefore " :" LocalName
chopAfter = id-chopAfter " :" LocalName
id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
Refinement = item / and / or / not
item = id-item " :" OBJECT-IDENTIFIER
and = id-and " :" Refinements
or = id-or " :" Refinements
not = id-not " :" Refinement
Refinements = "{" [ sp Refinement
*( "," sp Refinement ) ] sp "}"
id-item = %x69.74.65.6D ; "item"
id-and = %x61.6E.64 ; "and"
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
    
BaseDistance = INTEGER-0-MAX

^
03 novembre 2013

htmlpdflatexmanmd




rfc3712

rfc3712

Schéma pour les services d'impression

objectClass

slpServicePrinter
( 1.3.18.0.2.6.254 NAME 'slpServicePrinter' DESC 'Service Location Protocol (SLP) information.' AUXILIARY SUP slpService )
printerAbstract
( 1.3.18.0.2.6.258 NAME 'printerAbstract' DESC 'Printer related information.' ABSTRACT SUP top MAY ( printer-name $ printer-natural-language-configured $ printer-location $ printer-info $ printer-more-info $ printer-make-and-model $ printer-multiple-document-jobs-supported $ printer-charset-configured $ printer-charset-supported $ printer-generated-natural-language-supported $ printer-document-format-supported $ printer-color-supported $ printer-compression-supported $ printer-pages-per-minute $ printer-pages-per-minute-color $ printer-finishings-supported $ printer-number-up-supported $ printer-sides-supported $ printer-media-supported $ printer-media-local-supported $ printer-resolution-supported $ printer-print-quality-supported $ printer-job-priority-supported $ printer-copies-supported $ printer-job-k-octets-supported $ printer-current-operator $ printer-service-person $ printer-delivery-orientation-supported $ printer-stacking-order-supported $ printer-output-features-supported ) )
printerService
( 1.3.18.0.2.6.255 NAME 'printerService' DESC 'Printer information.' STRUCTURAL SUP printerAbstract MAY ( printer-uri $ printer-xri-supported ) )
printerServiceAuxClass
( 1.3.18.0.2.6.257 NAME 'printerServiceAuxClass' DESC 'Printer information.' AUXILIARY SUP printerAbstract MAY ( printer-uri $ printer-xri-supported ) )
printerIPP
( 1.3.18.0.2.6.256 NAME 'printerIPP' DESC 'Internet Printing Protocol (IPP) information.' AUXILIARY SUP top MAY ( printer-ipp-versions-supported $ printer-multiple-document-jobs-supported ) )
printerLPR
( 1.3.18.0.2.6.253 NAME 'printerLPR' DESC 'LPR information.' AUXILIARY SUP top MUST ( printer-name ) MAY ( printer-aliases) )

Attributes

printer-uri
( 1.3.18.0.2.4.1140 NAME 'printer-uri' DESC 'A URI supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
printer-xri-supported
( 1.3.18.0.2.4.1107 NAME 'printer-xri-supported' DESC 'The unordered list of XRI (extended resource identifiers) supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
printer-name
( 1.3.18.0.2.4.1135 NAME 'printer-name' DESC 'The site-specific administrative name of this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-natural-language-configured
( 1.3.18.0.2.4.1119 NAME 'printer-natural-language-configured' DESC 'The configured natural language in which error and status messages will be generated (by default) by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-location
( 1.3.18.0.2.4.1136 NAME 'printer-location' DESC 'The physical location of this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-info
( 1.3.18.0.2.4.1139 NAME 'printer-info' DESC 'Descriptive information about this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-more-info
( 1.3.18.0.2.4.1134 NAME 'printer-more-info' DESC 'A URI for more information about this specific printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
printer-make-and-model
( 1.3.18.0.2.4.1138 NAME 'printer-make-and-model' DESC 'Make and model of this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-ipp-versions-supported
( 1.3.18.0.2.4.1133 NAME 'printer-ipp-versions-supported' DESC 'IPP protocol version(s) that this printer supports.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-multiple-document-jobs-supported
( 1.3.18.0.2.4.1132 NAME 'printer-multiple-document-jobs-supported' DESC 'Indicates whether or not this printer supports more than one document per job.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
printer-charset-configured
( 1.3.18.0.2.4.1109 NAME 'printer-charset-configured' DESC 'The configured charset in which error and status messages will be generated (by default) by this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.1563 SINGLE-VALUE )
printer-charset-supported
( 1.3.18.0.2.4.1131 NAME 'printer-charset-supported' DESC 'Set of charsets supported for the attribute values of syntax DirectoryString for this directory entry.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.1563 )
printer-generated-natural-language-supported
( 1.3.18.0.2.4.1137 NAME 'printer-generated-natural-language-supported' DESC 'Natural language(s) supported for this directory entry.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.1563 )
printer-document-format-supported
( 1.3.18.0.2.4.1130 NAME 'printer-document-format-supported' DESC 'The possible source document formats which may be interpreted and printed by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-color-supported
( 1.3.18.0.2.4.1129 NAME 'printer-color-supported' DESC 'Indicates whether this printer is capable of any type of color printing at all, including highlight color.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
printer-compression-supported
( 1.3.18.0.2.4.1128 NAME 'printer-compression-supported' DESC 'Compression algorithms supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-pages-per-minute
( 1.3.18.0.2.4.1127 NAME 'printer-pages-per-minute' DESC 'The nominal number of pages per minute which may be output by this printer.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-pages-per-minute-color
( 1.3.18.0.2.4.1126 NAME 'printer-pages-per-minute-color' DESC 'The nominal number of color pages per minute which may be output by this printer.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-finishings-supported
( 1.3.18.0.2.4.1125 NAME 'printer-finishings-supported' DESC 'The possible finishing operations supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-number-up-supported
( 1.3.18.0.2.4.1124 NAME 'printer-number-up-supported' DESC 'The possible numbers of print-stream pages to impose upon a single side of an instance of a selected medium.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
printer-sides-supported
( 1.3.18.0.2.4.1123 NAME 'printer-sides-supported' DESC 'The number of impression sides (one or two) and the two-sided impression rotations supported by this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-media-supported
( 1.3.18.0.2.4.1122 NAME 'printer-media-supported' DESC 'The standard names/types/sizes (and optional color suffixes) of the media supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-media-local-supported
( 1.3.18.0.2.4.1117 NAME 'printer-media-local-supported' DESC 'Site-specific names of media supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-resolution-supported
( 1.3.18.0.2.4.1121 NAME 'printer-resolution-supported' DESC 'List of resolutions supported for printing documents by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-print-quality-supported
( 1.3.18.0.2.4.1120 NAME 'printer-print-quality-supported' DESC 'List of print qualities supported for printing documents on this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-job-priority-supported
( 1.3.18.0.2.4.1110 NAME 'printer-job-priority-supported' DESC 'Indicates the number of job priority levels supported by this printer.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-copies-supported
( 1.3.18.0.2.4.1118 NAME 'printer-copies-supported' DESC 'The maximum number of copies of a document that may be printed as a single job on this printer.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-job-k-octets-supported
( 1.3.18.0.2.4.1111 NAME 'printer-job-k-octets-supported' DESC 'The maximum size in kilobytes (1,024 octets actually) incoming print job that this printer will accept.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-current-operator
( 1.3.18.0.2.4.1112 NAME 'printer-current-operator' DESC 'The identity of the current human operator responsible for operating this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-service-person
( 1.3.18.0.2.4.1113 NAME 'printer-service-person' DESC 'The identity of the current human service person responsible for servicing this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-delivery-orientation-supported
( 1.3.18.0.2.4.1114 NAME 'printer-delivery-orientation-supported' DESC 'The possible delivery orientations of pages as they are printed and ejected from this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-stacking-order-supported
( 1.3.18.0.2.4.1115 NAME 'printer-stacking-order-supported' DESC 'The possible stacking order of pages as they are printed and ejected from this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-output-features-supported
( 1.3.18.0.2.4.1116 NAME 'printer-output-features-supported' DESC 'The possible output features supported by this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-aliases
( 1.3.18.0.2.4.1108 NAME 'printer-aliases' DESC 'List of site-specific administrative names of this printer in addition to the value specified for printer-name.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
^
17 septembre 2014

htmlpdflatexmanmd




rfc3829

rfc3829

Contrôles d'identité d'autorisation

   Ce document définis le support pour le contrôle de demande d'identité d'autorisation et le contrôle de réponse d'identité d'autorisation pour demander et retourner l'autorisation établie dans une opération bind. C'est utile quand il y a des étapes de mappage ou d'autre indirection durant le bind, le client peut savoir quelle identité a été autorisée. L'authentification client avec certificats est la principale situation où cela s'applique.

   Le support pour le contrôle de demande d'identité d'autorisation et le contrôle de réponse d'identité d'autorisation est indiqué par la présence de l'OID 2.16.840.1.113730.3.4.16 et 2.16.840.1.113730.3.4.15, respectivement, dans supportedControl du rootDSE.

Request

   Ce contrôle peut être inclus dans une demande bind dans le champ contrôles du LDAPMessage. Dans une opération bind a plusieurs étapes, le client doit fournir ce contrôle à chaque demande bind. controlType est 2.16.840.1.113730.3.4.16 et controlValue est absent.

Response

   Ce contrôle peut être inclus dans la réponse bind finale où la première demande bind a inclus de contrôle de demande. controlType est 2.16.840.1.113730.3.4.15. Si le bind a réussi et résulte en une identité ( non anonyme ), controlValue contient l'identité d'autorisation (authzId). Si le bind résulte en une association anonyme, controlValue est une chaîne vide. Si le bind résulte en plusieurs authzId, l'autzId primaire est retourné dans controlValue. Le contrôle est inclus uniquement dans une réponse bind dont le resultCode est success.

   Si le serveur nécessite des protections de confidentialité avant d'utiliser ce contrôle, le serveur reporte une erreur et retourne le code de retour confidentialityRequired.

   Si le client n'a pas les droits suffisants pour demander les informations d'autorisation, le serveur retourne le code insufficientAccessRights.

   Les identités présentés par un client comme partie du processus d'authentification peuvent être mappsé par le serveur à une ou plusieurs identités d'autorisation. Le contrôle de réponse bind peut être utilisé pour récupérer l'authzId primaire.

   Par exemple, durant l'authentification du client avec des certificats, un client peut posséder plus d'un certificat et ne peut pas être en mesure de déterminer lequel a été sélectionné pour l'authentification auprès du serveur. Le DN du champ sujet dans le certificat sélectionné peut ne pas correspondre exactement au DN dans l'annuaire, mais est passé par un processus de mappage dans le serveur. Une fois l'authentification par certificat complétée, le client peut fournir un bind SASL, spécifiant le mécanisme externe et incluant le contrôle de demande d'identité d'autorisation. La réponse peut inclure le contrôle de réponse d'identité d'autorisation indiquant le DN dans le DIT qui a été mappé.

Approche alternative

   L'opération étendue Who am I? fournis un mécanisme pour demander l'identité d'autorisation associée avec une connexion. Utiliser une opération étendue permet à un client d'apprendre d'identité d'autorisation après que le bind ait établis les protections d'intégrité et de confidentialité. Pour les environnements multithreadé ou à fort traffic, le contrôle étendu est préférable.
^
06 novembre 2013

htmlpdflatexmanmd




rfc3866

rfc3866

Language Tags and Ranges

   Il est souvent utile d'être capable d'indiquer le langage naturel associé avec les valeurs maintenus dans un annuaire et être capable de requêter l'annuaire sur des valeurs qui sont dans la langue que l'utilisateur demande.

Language Tags

   La section 2 de la BCP 47 (rfc 3066) décris le format de tag de langage qui est utilisé dans LDAP. brièvement, c'est une chaîne ASCII et '-'. ex: fr, en-US, ja-JP. ces tags sont insensible à la casse.

Language Ranges

   La section 2.5 de la BCP 47 (rfc 3066) décris les plages de langage. Un language range match un tag de langage s'il est égal à un préfix du tag. ex: la plage "de" match les tags "de" et "de-CH", mais pas "den". le range spécial "*" match tous les tags.

Attribute Descriptions

   Un attribut consiste d'un type, un jeu de 0 ou plusieurs options de tagging, et un jeu d'une ou plusieurs valeurs. Le type et les options sont combinés dans le AttributeDescription. AttributeDescription peut aussi contenir des options qui ne font pas partie de l'attribut, mais indiquent d'autres fonctions (tel que le range assertion ou le transfer encoding).

   Un AttributeDescription avec une ou plusieurs options de tagging est un sous-type direct de chaque AttributeDescription de même type avec toutes sauf une des options de tagging. Si le type d'AttributeDescription est un sous-type direct d'autres type, alors l'AttributeDescription est aussi un sous-type direct de l'AttributeDescription qui consiste du super-type et toutes les les options de tagging. donc, "CN;x-bar;x-foo" est un sous-type direct de "CN;x-bar", "CN;x-foo", et "name;x-bar;x-foo". Noter que "CN" est un sous-type de "name".

Utilisation des language tags dans LDAP

   Les serveurs qui supportent le stockage d'attributs avec des options de tag de langage dans le DIT devraient permettre à tout type d'attribut uns syntaxe chaîne d'avoir des options de tag de langage. Les serveurs peuvent permettre d'associer des options de langage avec d'autres type d'attributs.

  Les clients ne devraient pas assumer que les serveurs ont cette capacité.

  Les implémentations ne doivent pas interpréter la structure du tag en comparant 2 tags, et doivent les traiter simplement comme chaîne de caractère.

Options de tag de langage

   Un option de tag de langage associe un langage naturel avec des valeurs d'un attribut. Une description d'attribut peut contenir plusieurs attributs avec le même type d'attribut mais avec différentes combinaisons de tag de langage.

Une option de tag de langage en notation ABNF:
language-tag-option = "lang-" Language-Tag
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9

Exemples d'AttributeDescription valide:
givenName;lang-en-US
CN;lang-ja
SN;lang-de;lang-gem-PFL
O;lang-i-klingon;x-foobar
description;x-foobar
CN

Filtres de recherche

Par exemple, Un filtre d'égalité de type "name;lang-en-US" et une valeur d'assertion "Billy Ray", avec l'entrée suivante:
dn: SN=Ray,DC=example,DC=com
objectClass: person DOES NOT MATCH (wrong type)
objectClass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-)
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (no lang-, wrong value)

   Noter que "CN" et "SN" sont des sous-type de "name"

Exemple, un filtre d'égalité de type "name" et une valeur d'assertion "Billy Ray", avec l'entrée suivante:
dn: SN=Ray,DC=example,DC=com
objectClass: person DOES NOT MATCH (wrong type)
objectClass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray MATCHES
CN;x-foobar: Billy Ray MATCHES
name: Billy Ray MATCHES
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (wrong value)

Attributs demandés dans la recherche

   Les clients peuvent fournir des options de tag de langage dans chaque AttributeDescrition dans la liste des attributs demandés. Si les options de tag de langage sont fournis, seul les attributs ayant la description sont retournés

exemple, si le client demande un attribut description, et une entrée qui match contient les attributs suivants:
objectClass: top
objectClass: organization
O: Software GmbH
description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte

Le serveur devrait retourner:
description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte

Compare

   Les tag peuvent être utilisés dans une requête compare. Le serveur les traites de la même manière que pour les recherches.

exemple, un requête compare de type "name" et une valeur d'assertion "Johann" avec une entrée:
objectClass: top
objectClass: person
givenName;lang-de-DE: Johann
CN: Johann Sibelius
SN: Sibelius

   Le serveur devrait retourner compareTrue. Cependant, si le client demande un compare de type "name;lang-de", la requête échouera avec noSuchAttributeType.

Add

Les clients peuvent fournir ces tags dans AttributeDescription d'une nouvelle entrée à créer.exemple:
dn: CN=John Smith,DC=example,DC=com
objectClass: residentialPerson
CN: John Smith
CN;lang-en: John Smith
SN: Smith
SN;lang-en: Smith
streetAddress: 1 University Street
streetAddress;lang-en-US: 1 University Street
streetAddress;lang-fr: 1 rue Universite
houseIdentifier;lang-fr: 9e etage

Modify

   Un client peut fournir ces tags dans un AttributeDescription comme partie d'un élement de modification. Les types d'attibuts et les options doivent matcher exactement les valeurs stockées dans l'annuaire.Par exemple, si la modification est 'delete', et que les valeurs à supprimer ont un tag de langage, ces options doivent être fournis dans l'opération modify.

Utilisation des plages de langage dans LDAP

   Une plage de langage, en notation ABNF:

  language-range-option = "lang-" [ Language-Tag "-" ]

  où language-Tag et définis dans la BCP 47.

Exemple d'AttributeDescription contenant des options de plage de langage:
givenName;lang-en-
CN;lang-
SN;lang-de-;lang-gem-
O;lang-x-;x-foobar

   Une option de plage de langage n'est pas une option de tagging. les attributs ne peuvent pas être stockés avec des options de plage de langage.

Filtres de recherche

   Si une option de plage de langage est présente dans un AttributeDescription dans une assertion, alors pour chaque entrée dans le scope, les valeurs de chaque attribut dont AttributeDescription consistent du même type d'attribut ou ses sous-type et contiennent un option de tag de langage correspondant sont retournés

exemple, un filtre d'égalité de type "name;lang-en-" et une valeur d'assertion "Billy Ray", avec l'entrée suivante:
dn: SN=Ray,DC=example,DC=com
objectClass: person DOES NOT MATCH (wrong type)
objectClass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray MATCHES
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (no lang-, wrong value)

Attributs demandés dans les opérations de recherche

   Les clients peuvent fournir des options de plage de langage dans chaque AttributeDescription dans la liste des attributs demandés dans une opération de recherche. Si le client demande l'attribut "name;lang-en-", le serveur pourrait retourner "name;lang-en-US" et "CN;lang-en;lang-ja", mais pas "SN" ni "name;lang-fr".

Comparaison

exemple, une requête compare de type "name;lang-" et une valeur d'assertion "Johann", avec l'entrée suivante:
objectClass: top
objectClass: person
givenName;lang-de-DE: Johann
CN: Johann Sibelius
SN: Sibelius

   Le serveur devrait retourner compareTrue. Si le client avait fournis le type "name;lang-de", et la valeur d'assertion "Sibelius" avec l'entrée ci-dessus, la requête aurait échouée.

Découverte des options de langage

   Un serveur devrait indiquer qu'il supporte les options de tag de langage en publiant 1.3.6.1.4.1.4203.1.5.4 ( Language Tag Options ) et 1.3.6.1.4.1.4203.1.5.5 ( Language Range Options ) dans le rootDSE.
^
27 octobre 2013

htmlpdflatexmanmd




rfc3909

rfc3909

Opération Cancel

   L’opération étendue cancel (ou abandon), comme l’annuaire X.511 fournis une indication en retour. LDAP fournis l’opération Abandon qui permet d’annuler d’autres opérations. Cette opération n’a pas de réponse et ne nécessite pas de réponse de l’opération abandonnée. Cette sémantique ne fournis pas au client une indication claire de la sortie de l’opération Abandon. l’opération Cancel devrait être utilisé au lieu de l’opération Abandon quand le client a besoin d’une indication claire sur l’opération.

   l’opération Cancel est définie comme opération étendue, identifiée par l’OID 1.3.6.1.1.8

Requête Cancel

   La requête Cancel et une ExtendedRequest avec le champ requestName contenant 1.3.6.1.1.8 et un champ requestValue qui contient un valeur encodé BER cancelRequestValue.


cancelRequestValue::= SEQUENCE {
    cancelID MessageID }

   Le champs cancelID contient le message ID associé avec l’opération à annuler

Réponse Cancel

   Une réponse Cancel est une ExtendedResponseresponseName et les champs response sont absent

Codes de résultats additionnels

Les implémentations de cette spécification devraient reconnaitre les valeurs resultCode additionnels suivante:
canceled (118)
noSuchOperation (119)
tooLate (120)
cannotCancel (121)

Les classes d’opération suivante ne peuvent pas être annulées:
- les opérations qui n’ont pas de réponse
- les opérations qui établissent, altèrent ou détruisent des associations d’authentification et/ou d’authorisation
- les opérations qui établissent, altèrent ou détruisent des services de sécurité
- les opérations qui abandonnent ou annulent d’autres opérations

   Les serveurs devraient indiquer leur support pour cette extension en fournissant 1.3.6.1.1.8 dans supportedExtension.
^
08 novembre 2013

htmlpdflatexmanmd




rfc3928

rfc3928

LCUP: Client Update Protocol

   Ce protocole permet à un client LDAP de synchroniser le contenu d'un DIT et d'être notifié des changements du contenu. Il adresse les problèmes suivants:

   Lorsqu'un client utilise une copie local en lecture seul de l'annuaire et qu'il se connecte au réseau, il synchronise son contenu avec l'annuaire et peut optionnellement recevoir des notifications sur les changements qui se produisent pendant qu'il est en ligne. Par exemple, un client mail peut maintenir une copie local de l'adresse book qu'il synchronise avec la copie master quand le client est connecté au réseau de l'entreprise.

   Les applications qui synchronisent les données, une application meta-annuaire par exemple, va récupérer périodiquement une liste de modifications de l'annuaire, construire les changements, et les appliquer aux données stockées.

   Les clients qui ont besoin de prendre certaines actions quand une entrée d'annuaire est modifiée. Par exemple, un système de messagerie peut vouloir faire un 'create mailbox' quand une nouvelle personne est créée, et un 'delete mailbox' quand l'entrée est supprimée.

   Le problème suivant n'est pas adressé: La synchronisation entre serveurs d'annuaire.

   LCUP est conçus de telle sorte que le serveur n'a pas besoin de maintenir l'état des informations spécifique à chaque client. Le serveur peut maintenir des informations d'état additionnels sur la modification des attributs et autres. les clients sont responsable du stockage des informations sur la manière de mettre à jours leur données avec le contenu de l'annuaire. Le client décide quand et où récupérer les changements. LCUP nécessite que les clients initient la session update et "pull" les changements depuis le serveur.

applicabilité

   LCUP fonctionne mieux quand les conditions suivantes sont rencontrées:

1) le serveur stocke un certain degré d'informations d'état historique pour réduire la quantité de trafic requis pour les synchronisations incrémentales.
2) le client ne peut pas assumer comprendre le modèle d'information physique (attributs virtuels, opérationnels, subentries, etc.) implémentés par le serveur.

Spécification des éléments du protocole

Universally Unique Identifiers les DN peuvent changer, donc ils ne sont pas des identifiants fiables. Un UUID doit être utilisé avec LCUP. Le serveur doit fournir cet UUID en tant qu'attribut opérationnel single-value. (par exemple: entryUUID). LCUPUUID::= OCTET STRING
Schéma LCUP et cookie LCUP Le protocole LCUP utilise un cookie pour maintenir l'état des données client. Chaque format de cookie est identifié de manière unique avec son schéma. LCUPScheme::= LDAPOID. C'est l'OID qui identifie le format de la valeur du cookieLCUP. LCUPCookie::= OCTET STRING
contexte LCUP La partie du DIT qui est autorisé pour LCUP est appelé un contexte LCUP. Un serveur peut supporter un ou plusieurs contextes LCUP. Chaque contexte LCUP peut utiliser un schéma de cookie différent.

ResultCode additionnels

lcupResourcesExhausted (113) Le serveur n'a plus de ressources
lcupSecurityViolation (114) Le client est suspecté d'actions malicieuses
lcupInvalidData (115) Schéma ou cookie invalide
lcupUnsupportedScheme (116) Le schéma du cookie est un OID valide mais n'estpas supporté par ce serveur
lcupReloadRequired (117) Indique que les données client doivent être réinitialisées si le serveur ne contient pas suffisamment d'information pour synchroniser les données, ou si les données du serveur ont été rechargée depuis la dernière session de synchronisation.

Contrôle Sync Request

Ce contrôle a controlType à 1.3.6.1.1.7.1 et controlValue, un OCTET STRING contenant un syncRequestControlValue encodé BER:
syncRequestControlValue ::= SEQUENCE {
    updateType ENUMERATED {
        syncOnly (0),
        syncAndPersist (1),
        persistOnly (2) },
    sendCookieInterval [0] INTEGER OPTIONAL,
    scheme [1] LCUPScheme OPTIONAL,
    cookie [2] LCUPCookie OPTIONAL
}

   sendCookieInterval Le serveur devrait envoyer le cookie dans la valeur du contrôle Sync Update à chaque sendCookieInterval nombre de SearchResultEntry et SearchResultReference retourné au client. Par exemple, si la valeur est 5, le serveur devrait envoyer le cookie dans la valeur du contrôle Sync Update pour toutes les 5 recherches retournés au client. Si cette valeur est absente, 0 ou inférieur à 0, le serveur choisis l'interval.

  Ce contrôle est seulement applicable au message searchRequest.

Contrôle Sync Update

Ce contrôle a controlType à 1.3.6.1.1.7.2 et controlValue un OCTET STRING contenant le syncUpdateControlValue encodé BER:
syncUpdateControlValue ::= SEQUENCE {
    stateUpdate BOOLEAN,
    entryUUID [0] LCUPUUID OPTIONAL, — REQUIRED for entries —
    UUIDAttribute [1] AttributeType OPTIONAL,
    entryLeftSet [2] BOOLEAN,
    persistPhase [3] BOOLEAN,
    scheme [4] LCUPScheme OPTIONAL,
    cookie [5] LCUPCookie OPTIONAL
}

   UUIDAttribute contient le nom ou l'OID de l'attribut que le client devrait utiliser pour effectuer les recherches pour les entrées basée sur l'UUID. Le client devrait être capable de l'utiliser dans un filtre de recherche d'égalité, par exemple "(‹uuid attribute›=‹entry UUID value›)" et devrait être capable de l'utiliser dans la liste des attributs de requête search pour retourner ses valeurs. UUIDAttribute peut être omis si le serveur ne supporte pas les recherches sur les valeurs UUID.

Contrôle Sync Done

Ce contrôle a controlType à 1.3.6.1.1.7.3 et controlValue contenant un syncDoneValue encodé BER:
syncDoneValue ::= SEQUENCE {
    scheme [0] LCUPScheme OPTIONAL,
    cookie [1] LCUPCookie OPTIONAL
}
   Un client initie une synchronisation ou une session de recherche persistente avec un serveur en attachant un Sync Request à un message searchRequest. La spécification de recherche détermine le DIT, le jeu d'attributs et la quantité de données que le client veut recevoir. Le contrôle Sync Request contient la spécification de requête du client. S'il y'a une condition d'erreur, le serveur doit retourner SearchResultDone avec un resultCode approprié à l'erreur.

Synchronisation initiale et re-synchronisation complète

   Les champs du contrôle Sync Request doivent être spécifiés comme suit:

updateType Doit être mis à syncOnly ou syncAndPersist
sendCookieInterval Peut être définis
scheme Peut être définis. si définis, le serveur doit utiliser ce schéma ou retourner lcupUnsupportedScheme, sinon, le serveur peut utiliser tout schéma qu'il supporte
cookie Ne doit pas être définis.

Synchronisation incrémentale et de mise à jours

   Les champs du contrôle Sync Request doivent être spécifiés comme suit:

updateType Doit être à syncOnly ou syncAndPersist
sendCookieInterval Peut être définis
scheme Doit être définis
cookie Doit être définis

   Le client devrait toujours utiliser le dernier cookie reçu par le serveur.

Persistent Only

   Les champs de Sync Request doivent être spécifié comme suit:

updateType Doit être à persistOnly
sendCookieInterval Peut être définis
scheme Peut être définis
cookie Peut être définis, mais le serveur doit l'ignorer.
   Dans la réponse au client, le serveur retourne 0 ou plusieurs SearchResultEntry ou SearchResultReference, suivis par un SearchResultDone. Chaque SearchResultEntry ou SearchResultReference contient aussi un contrôle Sync Update qui décrit l'état LCUP de l'entrée retournée. SearchResultDone contient un contrôle Sync Done.

Réponses Sync Update Informational

   Le serveur peut utiliser le contrôle Sync Update pour retourner des informations non liées à une entrée particulière. Il peut le faire à tout moment pour retourner un cookie au client, ou pour informer le client que la phase de sync d'une recherche syncAndPersist est complète et que la phase persist a commencé. Il peut le faire durant la phase persist même quand aucune entrée n'a changé/ Pour faire çà, il faut retourner:

- un PDU SearchResultEntry avec objectName contenant le DN de baseObject de la requête de recherche et avec un attribut list vide.
- Un contrôle Sync Update avec les champs définis comme suit :

stateUpdape Doit être à TRUE
entryUUID Devrait être l'UUID du baseObject de la requête search
entryLeftSet Doit être à FALSE
persistPhase Doit être FALSE si la recherche est dans la phase sync et TRUE si elle est dans la phase persist.
UUIDAttribute Devrait seulement être définis si c'est soit le premier résultat retourné soit l'attribut a changé
scheme Doit être définis si le cookie est définis et que le format a changé, sinon il peut être omi.
cookie Devrait être définis

   Durant une requête SyncAndPersist, le serveur doit retourner immédiatement après que la dernière entrée de la phase sync ait été envoyée et avant que la première entrée de la phase persist ait été envoyée. Celà permet au client de savoir quand la phase sync se termine et quand la phase persist commence.
   Le champ cookie d'un contrôle Sync Update peut être définis dans tout résultat retourné, durant la phase sync et persist. Le serveur devrait retourner le cookie suffisamment souvent pour que le client resynchronise dans une période de temps raisonnable en cas de déconnections par ex. Le champ sendCookieInterval est une suggestion au serveur et il devrait respecter cette valeur.

  Le champ scheme doit être définis si le cookie est présent et que le format a changé, sinon il peut être omis.

Définition d'une entrée qui entre dans le jeu de résultat

   Une entrée doit être considérée rentrer dans le jeu de résultat de la recherche du client si un des conditions est rencontrée:

- Durant la phase sync pour une opération sync incrémentale, l'entrée est présent dans le jeu de résultat de la recherche mais n'était pas présente avant ; typiquement une entrée qui a été ajoutée ou déplacée dans l'annuaire.
- Durant la phase persist pour une opération de recherche persistante, l'entrée entre dans le jeu de résultat de recherche, typiquement une entrée qui a été ajoutée ou déplacée dans l'annuaire.

Définition d'une entrée qui a changé

   Une entrée doit être considérée changée si un ou plusieurs de ses attributs dans la liste des attributs de la recherche ont été modifiés.

Définition d'une entrée qui a quitté le jeu de résultat

   Une entrée doit être considérée sortie du jeu de résultat si elle rencontre une de ces conditions:

- Durant la phase sync, l'entrée n'est pas présente dans le jeu de résultat mais était présent avant.
- Durant la phase persist, l'entrée quitte le jeu de résultat.

Résultats pour les entrées présentes dans le jeu de résultat

   Une entrée devrait être retournée présente sous les conditions suivante:

- La requête est une synchronisation initiale pour une requête full resync et l'entrée est présent dans le jeu de résultat de la recherche du client.
- La requête est une synchronisation incrémentale et l'entrée a changé ou est entrée dans le jeu de résultat depuis la dernière synchronisation.
- La recherche est dans la phase persist et l'entrée entre dans le jeu de résultat ou change.

   Pour un retour SearchResultEntry, les champs du contrôle Sync Update doivent être définis comme suit:

stateUpdate Doit être FALSE
entryUUID Doit être l'UUID de l'entrée
entryLeftSet Doit être FALSE
persistPhase Doit être FALSE durant la phase sync, TRUE durant la phase Persist
UUIDAttribute Devrait être définis seulement si c'est le premier résultat retourné ou si l'attribut a changé
schema comme plus haut
cookie Comme plus haut

Résultat pour les entrées qui ont quitté le jeu de résultat

   Une entrée devrait être considéré ayant quitté le jeu de résultat si elle est dans les conditions suivantes:

- La requête est une synchronisation incrémentale durant la phase sync et l'entrée est sortie du jeu de résultat
- La recherche est dans la phase persist et l'entrée a quitté le jeu de résultat
- L'entrée a quitté le jeu derésultat suitte à un LDAP delte ou ldap ModifyDN

stateUpdate Doit être FALSE
entryUUID Doit être l'UUID de l'entrée qui a quitté le jeu de résultat
entryLeftSet Doit être TRUE
persistPhase Doit être FALSE durant la phase sync, TRUE durant la phase Persist
UUIDAttribute Devrait être définis seulement si c'est le premier résultat retourné ou si l'attribut a changé
schema comme plus haut
cookie Comme plus haut

Retourner les résultats durant la phase persistante

   Le serveur devrait retourner les entrées changées au client le plus rapidement possible

Pas de mixe de phase sync et persist

   Durant la phase sync, le serveur ne doit pas retourner d'entrée avec le flag persistPhase à TRUE et durant la phase persisit ce flag doit être à TRUE.

Retourner les résultats mis à jours durant la phase sync

   Il peut y avoir des mises à jours des entrées dans le jeu de résultats durant l'opération de recherche. Si le serveur est surchargé de mises à jours et qu'il tente d'envoyer toutes ces mises à jours, il peut ne jamais terminer la phase sync. C'est à la discretion de l'implémentation du serveur de décider quand le client est en "in sync", c'est à dire quand se termine un suncOnly ou quand envoyer la réponse Update Informational entre les phases sync et persist.

Attributs opérationnels et entrées administratives

   Ils devraient être retournés tels qu'il seraient retournés dans une recherche normal. Si le serveur ne supporte pas la synchronisation des attributs opérationnel, le serveur doit retourner SearchResultDone avec un result unwillingToPerform

Garantie de convergence

   Si durant une recherche LCUP soit durant la phase sync ou persist, le serveur détermine qu'il ne peut pas garantir la délivrance de la copie au client pour une éventuelle convergence, il devrait immédiatement terminer la recherche LCUP et retourner un resultCode lcupReloadRequired.

Fin de recherche LCUP

Fin initiée par le serveur Quand le serveur a terminé le traitement avec succès, il attache un contrôle Sync Done au message SearchResultDone et il l'envoie au client. Cependant, si le resultCode de ce message est différent de success ou canceled, le contrôle Sync Done peut être omis. Le cookie doit être présent si resultCode est success ou canceled. Il devrait être présent si le resultCode est lcupResourcesExhausted, timeLimitExceeded, sizeLimitExceeded, ou adminLimitExceeded. Celà permet au client de resynchroniser plus facilement.
Fin initiée par le client Si le client doit terminer la synchronisation et veut obtenir le cookie qui représente l'état courant, il fournis une opération LDAP Cancel. Le serveur répond immédiatement avec une réponse LDAP Cancel.
Limite de temps et de taille Le serveur doit supporter les limites de taille et de temps. Le serveur doit s'assurer que si l'opération est terminée dû à ces conditions, le cookie est renvoyé au client.
Opération sur la même connexion Il est permis au client de fournis des opérations LDAP sur la connexion utilisé par le protocole.
Intéraction avec d'autres contrôles LCUP ne définit pas de restriction ni ne garantie la capacité d'utiliser les contrôles de ce document avec d'autres contrôles.
Considérations de réplication L'utilisation d'un cookie LCUP avec plusieurs DSA dans un environnement répliqué n'estpas définis parLCUP. Une implémentation LCUP peut supporter la continuation de session avec un autre DSA. Les clients peuvent envoyer des cookies retournés par un DSA à un autre DSA.

Considérations côté client

Utiliser les cookies avec différents critères de recherche Le cookie reçu d'un serveur après une session de synchronisation devrait seulement être utilisé avec les même spécifications de recherche qui ont généré le cookie.
Manipulation de référrant Le client peut reçevoir un référrant quandla recherche de base est une référence subordonnées et va terminer l'opération.

Considération d'implémentation serveur

Support des UUID Les serveurs doivent supporter les UUID.
Exemple en utilisant un RUV comme valeur de cookie Par concept, le protocole supporte plusieurs schéma de cookie, ce qui permet à différentes implémentations la flexibilité du stockage des informations. Une implémentation raisonnable serait d'utiliser le ReplicaUpdate Vector. Pour chaque Master, RUV contient le plus grand CSN vu par ce master. En plus, RUV implémenté par certains serveurs contiennent une génération de réplica, un chaîne opaque qui identifie le stockage des données de réplica. La valeur change quand les données sont rechargées. La génération de réplica est utilisé pour signaler aux parties de réplication/synchronisation que les données de réplica ont été rechargée et que tous les autres réplica doivent être réinitialisées.
Support pour plusieurs schéma de cookie Un serveur doit publier les OID des schéma de cookie supportés
^
28 septembre 2013

htmlpdflatexmanmd




rfc4230

rfc4230

Attribut opérationnel entryUUID

   cet attribut maintient un Universally Unique IDentifier assigné par le serveur pour l'objet.

La syntaxe UUID telle que définie dans la rfc 4122:
UUID = time-low "-" time-mid "-"
    time-high-and-version "-"
    clock-seq-and-reserved
    clock-seq-low "-" node
time-low = 4hexOctet
time-mid = 2hexOctet
time-high-and-version = 2hexOctet
clock-seq-and-reserved = hexOctet
clock-seq-low = hexOctet
node = 6hexOctet
hexOctet = hexDigit hexDigit
hexDigit =
    "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
    "a" / "b" / "c" / "d" / "e" / "f" /
    "A" / "B" / "C" / "D" / "E" / "F"

Dans LDAP, les UUID sont encodés en utilisant la représentation de chaîne ASCII, par exemple: "597ae2f6-16a6-1027-98f4-d28b5365dc14"
La description LDAP pour UUID est: ( 1.3.6.1.1.16.1 DESC 'UUID' )

Règle de correspondance uuidMatch

   règle d'égalité. La sémantique est la même que octetStringMatch. La définition LDAP de cette règle est: ( 1.3.6.1.1.16.2 NAME 'uuidMatch' SYNTAX 1.3.6.1.1.16.1 )

uuidOrderingMatch

   Règle d'ordonnancement. La sémantique est la même que octetStringOrderingMatch. La définition LDAP pour uuidOrderingMatch est: ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch' SYNTAX 1.3.6.1.1.16.1 )

Attribut entryUUID


( 1.3.6.1.1.16.4 NAME 'entryUUID'
    DESC 'UUID of the entry'
    EQUALITY uuidMatch
    ORDERING uuidOrderingMatch
    SYNTAX 1.3.6.1.1.16.1
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )

   Les serveurs devraient générer et assigner un nouvel UUID à chaque entrée ajoutée. une entrée UUID est inchangeable.
^
28 septembre 2013

htmlpdflatexmanmd




rfc4231

rfc4231

Opération Turn

   Cette opération étendue inverse les rôles du client et du serveur pour des échanges de protocole dans la session, ou pour permettre à chaque parties d'agir en tant que client et serveur.

Requête Turn

   L'opération Turn est définie par l'OID 1.3.6.1.1.19. La requête Turn est une ExtendedRequestrequestName contient 1.3.6.1.1.19 et requestValue est une valeur turnValue encodée BER:


turnValue ::= SEQUENCE {
    mutual BOOLEAN DEFAULT FALSE,
    identifier LDAPString
}

Réponse Turn

   La réponse est une ExtendedResponse où les champs responseName et responseValue sont absent. un resultCode à success indique qu'il est capable d'inverser la sessions.

Authentification

   Le modèle d'authentification de cette extension assume une authentification séparée des parties dans chacun de leur rôle. Un échange Bind est attendue entre les parties et leur nouveau rôle pour établir les identités dans ces rôles.

   Une fois le Turn complété, le partie répondant dans son nouveau rôle client a une association anonyme au partie initiant son nouveau rôle serveur. Si le turn est mutuel, l'association d'authentification du partie initiant est laissé intacte.

   Le partie répondant peut établir son identité dans son rôle client en demandant et complétant une opération Bind.

   La suite discute de divers scénarios d'authentification. A réfère au partie initiant (le client à l'origine) et B réfère au partie répondant ( le serveur à l'origine)

Utilisation avec TLS et une authentification simple


A-›B: StartTLS Request
B-›A: StartTLS(success) Response
A-›B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
B-›A: Bind(success) Response
A-›B: Turn(TRUE,"XXYYZ") Request
B-›A: Turn(success) Response
B-›A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
A-›B: Bind(success) Response

   Dans ce scénario, TLS est initié et A établis son identité avec B avant de Turn en utilisant un mécanisme DN/password. après le Turn, B établis son identité avec A.

Utilisation avec TLS et SASL EXTERNAL


A-›B: StartTLS Request
B-›A: StartTLS(success) Response
A-›B: Bind(SASL(EXTERNAL)) Request
B-›A: Bind(success) Response
A-›B: Turn(TRUE,"XXYYZ") Request
B-›A: Turn(success) Response
B-›A: Bind(SASL(EXTERNAL)) Request
A-›B: Bind(success) Response

   Dans ce scénario, TLS est initié, et A établis son identité avec SASL avant de Turn. Après le Turn, B établis son identité avec A.

Utilisation de l'authentification mutuelle et SASL EXTERNAL


A-›B: Bind(SASL(GSSAPI)) Request
‹intermediate messages›
B-›A: Bind(success) Response
A-›B: Turn(TRUE,"XXYYZ") Request
B-›A: Turn(success) Response
B-›A: Bind(SASL(EXTERNAL)) Request
A-›B: Bind(success) Response

   Dans ce scénario, un échange d'authentification mutuel GSSAPI est complété entre A et B. après le Turn, B demande que A utilise une identité externe pour établir son identité d'authorisation LDAP.

Couches TLS et SASL

   La table suivante décris la relation entre la couche du message LDAP, SASL, TLS et la connection de transport dans une session LDAP.


- - - - - - -+- - - - - - - - - - - +
- - - - - - -| LDAP message layer _ |
- - - - - - -+- - - - - - - - - - - + › LDAP PDUs
- - - - - - -+- - - - - - - - - - - + ‹ data
- - - - - - -| ____ SASL layer ____ |
- - - - - - -+- - - - - - - - - - - + › SASL-protected data
- - - - - - -+- - - - - - - - - - - + ‹ data
- - - - - - -| _____ TLS layer ____ |
Application -+- - - - - - - - - - - + › TLS-protected data
- - - - - - -+- - - - - - - - - - - + ‹ data
- Transport -| transport connection |
- - - - - - -+- - - - - - - - - - - +

   Cette extension n'altère pas la relation, ni ne supprime les restriction générales des couches TLS et SASL multiples. StartTLS est utilisé pour initier la négociation TLS. si TLS est déjà établis, StartTLS peut échouer.
^
28 septembre 2013

htmlpdflatexmanmd




rfc4370

rfc4370

Contrôle d'autorisation proxifié

   Permet à un client de demander qu'une opération soit traitée sous l'identité d'autorisation fournie au lieu de l'identité d'autorisation associée avec la connexion.

   Les serveurs supportant cette fonctionnalité devrait publier l'OID 2.16.840.1.113730.3.4.18 dans supportedControl.

   La criticité doit être présente et doit être à TRUE. Les serveurs rejètent toute requête non critique. controlValue devrait être présent et devrait soit contenir l'authzId représentant l'identité d'autorisation pour la requête ou être vide si une association anonyme doit être utilisée.

   Le mécanisme pour déterminer les droit d'accès est spécifique à la stratégie d'autorisation proxifiée du serveur.

   Si l'identité d'autorisation demandée est reconnue par le serveur, et que le client est autorisé à adopter l'autorisation demandée, la demande sera exécutée comme si elle était envoyée par l'identité d'autorisation proxy, sinon, le code de retour est 123.

Considération d'implémentation

   Durant l'évaluation d'une requête de recherche, un entrée qui aurait été retournée pour la recherche si elle avait été envoyée par l'identité d'autorisation proxy directement peut ne pas être retournée si le serveur trouve que le demandeur n'a pas les droit d'emprunter cette identité, même si l'entrée est dans le scope de recherche sous un DN qui implique de tels droits. Cela signifie que moins de résultat ou aucun résultat peut être retournée.
^
08 novembre 2013

htmlpdflatexmanmd




rfc4373

rfc4373

Bulk Update/Replication Protocol

   LBURP permet à un client LDAP d’effectuer des modifications/réplications auprès d’un serveur LDAP. LBURP définis un jeu opérations de modification dans une paire d’opérations étendue. Ces opérations contiennent chacune un numéro de séquence et une liste d’une ou plusieurs opérations de modification à effectuer.

Initialisation

   Le protocole est initié quand un fournisseur envoie StartLBURPRequest à un consommateur, qui notifie qu’un flux de LBURPUpdateRequests va suivre. Le fournisseur associe les sémantiques avec ce flux de requêtes en incluant l’OID du style de mise à jours/réplication dans le StartLBURPRequest. Le consommateur répond avec un message StartLBURPResponse

flux de mise à jours

   Après qu’un consommateur a répondu avec un StartLBURPResponse, le fournisseur envoie un flux de messages LBURPUpdateRequest au consommateur. Les messages dans ce flux peuvent être envoyés de manière asynchrone pour maximiser l’efficacité du transfert. Le consommateur répond à chaque LBURPUpdateRequest avec un message LBURPUpdateResponse.

LBURPUpdateRequest

   Chaque LBURPUpdateRequest contient un numéro de séquence identifiant sa position relative dans le flux. et un UpdateOperationList contenant la liste ordonnée des opérations à appliquer au DIT.

LBURPUpdateResponse

   Quand un consommateur a traité les opérations d’une UpdateOperationList, il envoie un LBURPUpdateResponse au fournisseur indiquant le succès ou l’échec des opérations.

Fin de mise à jours

   Une fois que le fournisseur a envoyé tous ses LBURPUpdateRequest, il envoie un message EndLBURPRequest au consommateur pour terminer le flux. Une fois reçu toutes les requêtes LBURPOperation et après avoir reçu le EndLBURPRequest, le consommateur répond avec un EndLBURPResponse.

Applicabilité du protocole

   LBURP est conçu pour faciliter les mise à jours en masse des serveurs LDAP. Il peut aussi être utilisé pour synchroniser les annuaires maître et esclave. Il n’est pas conçus dans l’optique de fournir des réplication multi-master.

Description du flux

F = Fournisseur
C = Consommateur
F -› C StartLBURPRequest. Contient l’OID pour le stype d’updte LBURP
C -› F StartLBURPResponse. Contient une instruction optionnelle maxOperations
F -› C Un flux de mises à jours consistant de 0 ou plusieurs LBURPUpdateRequest. Les requêtes peuvent être envoyés de manière asynchrone. Contient le numéro de séquence, et un updateOperationList d’opérations de mises à jours.
C -› F LBURPUpdateResponse. Envoyé quand le consommateur à finit le traitement d’une updateOperationList
F -› C EndLBURPRequest. Envoyé par le fournisseur quand il a envoyé tous ses LBURPUpdateRequest. Contient un numéro de séquence supérieur au dernier LBURPUpdateRequest envoyé.
C -› F EndLBURPResponse. Envoyé par le consommateur une fois toutes les LBURPOperation terminées et après avoir reçu EndLBURPRequest.

Elements du protocole

   LBURP utilise 2 messages LDAP extendedRequest: StartLBURPRequest et EndLBURPRequest pour initier et terminer le protocole. Un troisième extendedRequest, LBURPUpdateRequest est utilisé pour envoyer les opérations au consommateur.


ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
    requestName [0] LDAPOID,
    requestValue [1] OCTET STRING OPTIONAL
}
    
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS of LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL
}

StartLBURPRequest

requestName vaut 1.3.6.1.1.17.1 et requestValue contient la valeur suivante encodé BER:
StartLBURPRequestValue ::= SEQUENCE {
    updateStyleOID LDAPOID
}

updateStyleOID

   Identifie de manière unique le style de mise à jours à utiliser. LBUPR Incremental Update vaut 1.3.6.1.1.17.7

StartLBURPResponse

responseName vaut 1.3.6.1.1.17.2 et response contient la valeur suivante encodé BER:
StartLBURPResponseValue ::= maxOperations
maxOperations ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 — (2^^31 - 1) —

maxOperations

   Instruit le fournisseur de ne pas envoyer plus d’opération que cette valeur par updateOperationList. Si le consommateur n’envoie pas cette valeur, il doit être préparé à accèpter toutes les opérations fournies.

LBURPUpdateRequest

requestName vaut 1.3.6.1.1.17.5, et requestValue contient la valeur suivante encodé BER:
LBURPUpdateRequestValue ::= SEQUENCE {
    sequenceNumber INTEGER (1 .. maxInt),
    updateOperationList UpdateOperationList
}

sequenceNumber

   Permet au consommateur de traiter les requête LBURPOperation dans l’ordre spécifié par le fournisseur. La première valeur doit être 1 et incrémenté à chaque LBURPUpdateRequest.

UpdateOperationList

Liste d’une ou plusieurs requête de mise à jours LDAP:
UpdateOperationList ::= SEQUENCE OF SEQUENCE{
    updateOperation CHOICE {
    addRequest AddRequest,
    modifyRequest ModifyRequest,
    delRequest DelRequest,
    modDNRequest ModifyDNRequest
    },
    controls [0] Controls OPTIONAL
}

LBURPUpdateResponse

   Envoyé au fournisseur pour signaler que toutes les opérations d’un UpdateOperationList ont été complétés et pour donner le résultat des opérations. responseName contient 1.3.6.1.1.17.6

OperationResults

Quand un élément de réponse est inclus dans un message LBURPUpdateResponse, il contient la valeur suivante encodé BER:
OperationResults ::= SEQUENCE OF OperationResult
    
OperationResult ::= SEQUENCE {
operationNumber INTEGER,
ldapResult LDAPResult
}

operationNumber

   Identifie l’opération de mise à jours LDAP dans une UpdateOperationList d’un LBURPUpdateRequest qui a échoué. Les opérations sont numérotées en commençant à 1.

EndLBURPRequest

requestName vaut 1.3.6.1.1.17.3 et requestValue contient la valeur suivante encodé BER:
EndLBURPRequestValue ::= SEQUENCE {
    sequenceNumber INTEGER (1 .. maxInt)
}

EndLBURPRequest.sequenceNumber

   Est supérieur au dernier LBURPUpdateRequest.sequenceNumber reçu

EndLBURPResponse

   responseName vaut 1.3.6.1.1.17.4 et ne possède pas de réponse
^
08 novembre 2013

htmlpdflatexmanmd




rfc4403

rfc4403

Universal Description, Discovery, and Integration version 3

Représentation des structures de données UDDI

   Les informations qui créent un enregistrement dans un registre UDDI consiste de ces types de structure de données. Cette division par type d'information fournis des partitions simple pour assister dans la localisation et la compréhension rapide des différentes informations qui créent un enregistrement.

   Les données d'instance individuels gérés par un registre UDDI est sensible à la relation Parent/enfant trouvé dans le schéma. Un objet businessEntity contient un ou plusieurs objets unique businessService. Similairement, les objets businessService individuels, qui contiennent des informations qui incluent des pointers vers des instances d'objets tModel.

businessEntity

   Représente toute information connue sur un business ou une entité qui publie des information descriptives sur l'entité et les services qu'il offre.

businessService

   Les instance businessService représentent un service business logique. Chaque objet businessService est un enfant logique d'un objet businessEntity. Chaque élément businessService contient des informations descriptives en terme de business décrivant le type de service technique dans chaque instance businessService.

bindingTemplate

   Les descriptions techniques des services web sont accommodés via des instances individuelle d'objet bindingTemplate. Ces instance fournissent un support pour déterminer un point d'entrée technique ou un support optionnel de services hébergés à distance, aussi bien qu'un facilité pour décrire des caractéristiques techniques unique d'une implémentation donnée. Le support pour des paramètres et fichier de configuration particulier à des applications ou technologies sont également supportés.

  Chaque instance bindingTemplate a un seul parent businessService logique, qui en retour a un seul parent businessEntity logique.

tModel

   Cet objet prend la forme de métadonnées clé (data about data). Dans un sens général, le but d'un tModel dans le registre UDDI est de fournir un système de référence basé sur l'abstraction. Donc, le type de donnée qui tModel représente et nébuleux. un enregistrement tModel peut définir pleins de choses, mais dans la révision courante, 2 conventions ont été appliquées pour utiliser les tModels: comme source pour déterminer la compatibilité et comme références d'espace de nom clé. Les informations qui constituent un tModel sont assez simple. Il y'a une clé, un nom, une description optionnelle, et uneURL qui pointe quelquepart, potentiellement où un curieux peut trouver plus sur le concept représenté par la métadonnée dans le tModel.

publisherAssertion

   Beaucoup de business, tels que de grandes entreprises, ne sont pas représentées effectivement par un seul businessEntity, puisque leur description et découverte sont susceptible d'être divers. En concéquence, plusieurs cas de businessEntity peuvent être publiés, représentant diverses filiales. Néanmoins, ils représentent toujours une communauté plus ou moins couplé et souhaient certaines relations visible dans leurs enregistrements UDDI.

Information opérationnelle

   Avec UDDIv3, les informations opérationnelles associées avec le coeur des structures de données UDDI sont mainteni dans une structure OperationalInfo séparée, la signature numérique spécifiée par le publieur reste valide.

   La structure operationalInfo est utilisée pour transmettre les informations opérationnelles pour les structures de données du coeur UDDIv3, qui sont, les structures businessEntity, businessService, bindingTemplate et tModel. UDDIv3 OperationalInfo consiste de 5 éléments: created, Modified, modifiedIncludingChildren, nodeId, et authorizedName.

   En fonction de la strcture des données de UDDIv3 core, l'operationalInformation est représenté dansl'annuaire comme combinaison d'attributs opérationnels standard LDAP implicit: createTimestamp et modifyTimestamp, et les attributs explicites suivant: uddiAuthorizedName, uddiv3EntityCreationTime, uddiv3EntityModificationTime, et uddiv3NodeId.

Définition

uddiBusinessKey ID unique pour une instance donnée d'un uddiBusinessEntity.
uddiAuthorizedName Nom enregistré de l'individu qui a publié l'uddiBusinessEntity ou uddiTModel.
uddiOperator (obsolète par uddiv3NodeId) Nom certifié de l'opérateur de l'enregistrement UDDI qui gère la copie maître.
uddiName Noms 'human-readable' enregistrés pour le uddiBusinessEntity, uddiBusinessService, ou uddiTModel, orné d'une valeur xml:lang unique pour indiquer la langue dans laquelle ils sont exprimés.
uddiDescription Elément optionnel d'une ou plusieurs descriptions.
uddiDiscoveryURLs Liste d'URL qui pointent vers des mécanismes de découverte de services basés dur des fichiers additionnels
uddiUseType Décrit le type de contact ou adresse sous forme de texte libre. ex: "technical questions", "technical contact", "establish account", "sales contact", "headquarters", "sales office", "billing department", etc.
uddiPersonName Devrait lister lenom de la personne ou le nom d'un job disponible derrière le contact. 'ex: "administrator", "webmaster".
uddiPhone Numéro de téléphone pour le contact. Peut être orné avec un uddiUseType. ex: "Work Number#123 456-7890"
uddiEMail Utilisé pour maintenir les adresses email pour le contatc. Peut être orné avec un attribut uddiUseType. ex: "President of the United States #president@whitehouse.gov"
uddiSortCode (déprécié) Utiliser pour piloter le mode d'affichage externe des mécanisme qui trient les adresses. (ex: 1, 2, 3 ou a, b, c)
uddiTModelKey Id unique pour l'instance donnée d'un uddiTModel
uddiAddressLine Contient l'adresse actuelle sous forme de texte libre. Peut être orné avec 2 attributs descriptif, keyName et keyValue.(ex: "#"‹keyName›"#"‹keyValue›"#"‹addressData›)
uddiIdentifierBag Permet aux structures uddiBusinessEntity ou uddiTModel d'inclure des informations sur les formes communes d'identification tels que les nombres D-U-N-S, identifiant de taxe, etc. Peut être ornés avec un keyName et un keyValue. ex: ‹tModel›"#"‹keyName›"#"‹keyValue›
uddiCategoryBag Permet aux structures allows uddiBusinessEntity, uddiBusinessService, et uddiTModel d'être catégorisés en accord à une des nombreuses classification basé sur la taxonomie disponible, les Operator Sites fournissent un support de catégorie validée pour 3 taxonomies qui couvrent mers codes de l'industrie (via NAICS), classification de produits et services (via UNSPC), et géographie ( via ISO 3166 ). ex: ‹tModel›"#"‹keyName›"#"‹keyValue›
uddiKeyedReference Attribut généraliste pour une pair nom/valeur, avec référence à un tModel. ex: ‹tModel›"#"‹keyName›"#"‹keyValue›, tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey
uddiServiceKey Clé unique pour un uddiBusinessService donné
uddiBindingKey Clé unique pour un uddiBindingTemplate donné
uddiAccessPoint Pointer vers un point d'entrée de service.
uddiHostingRedirector Utilisé pour désigner qu'une entrée uddiBindingTemplate est un pointeur vers une autre entrée uddiBindingTemplate.
uddiInstanceDescription Un ou plusieurs textes descriptifs qui désignent quel rôle une référence uddiTModel joue dans la description du service global. la valeur xml:lang précède le nom de la valeur avec le séparateur '#'
uddiInstanceParms Contient des paramètres requis pour l'utilisation d'une facette spécifique d'une description uddiBindingTemplate.
uddiOverviewDescription Courte description de lamnière dont un uddiTModel particulier doit être utilisé. la valeur xml:lang précède le nom de la valeur avec le séparateur '#'
uddiOverviewURL Maintient un URL vers une forme longue d'un document qui couvre la manière dont un uddiTModel particulier est utilisé comme composant d'une description de web service général. ex: Overview Description= "1#xml:lang#overviewDescription1", OverviewURL= "1#UseType#overviewURL"
uddiFromKey Clé unique qui référence le premier uddiBusinessEntity pour lequel l'assertion est faite.
uddiToKey Clé unique qui référence le second uddiBusinessEntity pour lequel l'assertion est faite
uddiUUID ID unique d'un objet uddiContact, uddiAddress, et uddiPublisherAssertion
uddiIsHidden Fournis un fonctionnalité pour l'opération delete_tModel.
uddiIsProjection Identifie un Business Service qui a un Service Projection
uddiLang modélise la structure sml:lang pour la strcucture Adderess dans UDDIv3.
uddiv3BusinessKey ID UDDIv3 unique pour une instance donnée de uddiBusinessEntity.
uddiv3ServiceKey ID UDDIv3 unique pour une instance donnée de uddiBusinessService.
uddiv3BindingKey ID UDDIv3 unique pour une instance donnée de uddiBindingTemplate.
uddiv3TModelKey ID UDDIv3 unique pour une instance donnée de uddiTModel.
uddiv3DigitalSignature Maintient la signature pour l'entité UDDI correspondante.
uddiv3NodeId Contient le Node Identity pour un noeud UDDIv3.
uddiv3EntityModificationTime Contient la date de dernière modification pour une entité UDDI
uddiv3SubscriptionKey ID UDDIv3 unique pour une instance donnée de uddiv3SubscriptionKey.
uddiv3SubscriptionFilter Filtre de souscription.
uddiv3NotificationInterval Chaîne d'interval de notification, de type xsd:duration et spécifie la fréquence de notification de changement asynchrone à fournir.
uddiv3MaxEntities Nombre maximum d'entité à retourner dans une notification de souscription.
uddiv3ExpiresAfter xsd:dateTime qui spécifie la date d'expiration associée avec une souscription
uddiv3BriefResponse Flag pour la réponse brève associée à une entité de souscription.
uddiv3EntityKey ID UDDIv3 unique pour une instance donnée d'une structure de données UDDI core.
uddiv3EntityCreationTime Permet de logger la date de création originale d'une entité UDDI
uddiv3EntityDeletionTime Permet de logger la date de suppression originale d'une entité UDDI

Schéma

Attributs
( 1.3.6.1.1.10.4.1 NAME 'uddiBusinessKey' DESC 'businessEntity unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.2 NAME 'uddiAuthorizedName' DESC 'businessEntity publisher name' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
# ( 1.3.6.1.1.10.4.3 NAME 'uddiOperator' DESC 'registry site operator of businessEntitys master copy' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.4 NAME 'uddiName' DESC 'human readable name' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.5 NAME 'uddiDescription' DESC 'short description' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.6 NAME 'uddiDiscoveryURLs' DESC 'URL to retrieve a businessEntity instance' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.7 NAME 'uddiUseType' DESC 'name of convention the referenced document follows' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.8 NAME 'uddiPersonName' DESC 'name of person or job role available for contact' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.9 NAME 'uddiPhone' DESC 'telephone number for contact' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.10 NAME 'uddiEMail' DESC 'e-mail address for contact' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# ( 1.3.6.1.1.10.4.11 NAME 'uddiSortCode' DESC 'specifies an external display mechanism' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.12 NAME 'uddiTModelKey' DESC 'tModel unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.13 NAME 'uddiAddressLine' DESC 'address' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.14 NAME 'uddiIdentifierBag' DESC 'identification information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.15 NAME 'uddiCategoryBag' DESC 'categorization information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.16 NAME 'uddiKeyedReference' DESC 'categorization information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.17 NAME 'uddiServiceKey' DESC 'businessService unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.18 NAME 'uddiBindingKey' DESC 'bindingTemplate unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.19 NAME 'uddiAccessPoint' DESC 'entry point address to call a web service' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.20 NAME 'uddiHostingRedirector' DESC 'designates a pointer to another bindingTemplate' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.21 NAME 'uddiInstanceDescription' DESC 'instance details description' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.22 NAME 'uddiInstanceParms' DESC 'URL reference to required settings' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.23 NAME 'uddiOverviewDescription' DESC 'outlines tModel usage' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.24 NAME 'uddiOverviewURL' DESC 'URL reference to overview document' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.25 NAME 'uddiFromKey' DESC 'unique businessEntity key reference' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.26 NAME 'uddiToKey' DESC 'unique businessEntity key reference' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.27 NAME 'uddiUUID' DESC 'unique attribute' EQUALITY caseIgnoreMatchc SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.28 NAME 'uddiIsHidden' DESC 'isHidden attribute' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
( 1.3.6.1.1.10.4.29 NAME 'uddiIsProjection' DESC 'isServiceProjection attribute' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
( 1.3.6.1.1.10.4.30 NAME 'uddiLang' DESC 'xml:lang value in v3 Address structure' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.31 NAME 'uddiv3BusinessKey' DESC 'UDDIv3 businessEntity unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.32 NAME 'uddiv3ServiceKey' DESC 'UDDIv3 businessService unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.33 NAME 'uddiv3BindingKey' DESC 'UDDIv3 BindingTemplate unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.34 NAME 'uddiv3TModelKey' DESC 'UDDIv3 TModel unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.35 NAME 'uddiv3DigitalSignature' DESC 'UDDIv3 entity digital signature' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.36 NAME 'uddiv3NodeId' DESC 'UDDIv3 Node Identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.37 NAME 'uddiv3EntityModificationTime' DESC 'UDDIv3 Last Modified Time for Entity' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
( 1.3.6.1.1.10.4.38 NAME 'uddiv3SubscriptionKey' DESC 'UDDIv3 Subscription unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.39 NAME 'uddiv3SubscriptionFilter' DESC 'UDDIv3 Subscription Filter' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.40 NAME 'uddiv3NotificationInterval' DESC 'UDDIv3 Notification Interval' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.41 NAME 'uddiv3MaxEntities' DESC 'UDDIv3 Subscription maxEntities field' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( 1.3.6.1.1.10.4.42 NAME 'uddiv3ExpiresAfter' DESC 'UDDIv3 Subscription ExpiresAfter field' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
( 1.3.6.1.1.10.4.43 NAME 'uddiv3BriefResponse' DESC 'UDDIv3 Subscription ExpiresAfter field' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
( 1.3.6.1.1.10.4.44 NAME 'uddiv3EntityKey' DESC 'UDDIv3 Entity unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.45 NAME 'uddiv3EntityCreationTime' DESC 'UDDIv3 Entity Creation Time' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
( 1.3.6.1.1.10.4.46 NAME 'uddiv3EntityDeletionTime' DESC 'UDDIv3 Entity Deletion Time' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )

Classes d'objet
uddiBusinessEntity
( 1.3.6.1.1.10.6.1 NAME 'uddiBusinessEntity' SUP top STRUCTURAL MUST ( uddiBusinessKey $ uddiName) MAY ( uddiAuthorizedName $ uddiOperator $ uddiDiscoveryURLs $ uddiDescription $ uddiIdentifierBag $ uddiCategoryBag $ uddiv3BusinessKey $ uddiv3DigitalSignature $ uddiv3EntityModificationTime $ uddiv3NodeId) )
uddiContact
( 1.3.6.1.1.10.6.2 NAME 'uddiContact' SUP top STRUCTURAL MUST ( uddiPersonName $ uddiUUID ) MAY ( uddiUseType $ uddiDescription $ uddiPhone $ uddiEMail ) )
uddiAddress
( 1.3.6.1.1.10.6.3 NAME 'uddiAddress' SUP top STRUCTURAL MUST ( uddiUUID ) MAY ( uddiUseType $ uddiSortCode $ uddiTModelKey $ uddiv3TmodelKey $ uddiAddressLine $ uddiLang) )
uddiBusinessService
( 1.3.6.1.1.10.6.4 NAME 'uddiBusinessService' SUP top STRUCTURAL MUST ( uddiServiceKey ) MAY ( uddiName $ uddiBusinessKey $ uddiDescription $ uddiCategoryBag $ uddiIsProjection $ uddiv3ServiceKey $ uddiv3BusinessKey $ uddiv3DigitalSignature $ uddiv3EntityCreationTime $ uddiv3EntityModificationTime $ uddiv3NodeId) )
uddiBindingTemplate
( 1.3.6.1.1.10.6.5 NAME 'uddiBindingTemplate' SUP top STRUCTURAL MUST ( uddiBindingKey ) MAY ( uddiServiceKey $ uddiDescription $ uddiAccessPoint $ uddiHostingRedirector $ uddiCategoryBag $ uddiv3BindingKey $ uddiv3ServiceKey $ uddiv3DigitalSignature $ uddiv3EntityCreationTime $ uddiv3NodeId) )
uddiTModelInstanceInfo
( 1.3.6.1.1.10.6.6 NAME 'uddiTModelInstanceInfo' SUP top STRUCTURAL MUST ( uddiTModelKey ) MAY ( uddiDescription $ uddiInstanceDescription $ uddiInstanceParms $ uddiOverviewDescription $ uddiOverviewURL $ uddiv3TmodelKey) )
uddiTModel
( 1.3.6.1.1.10.6.7 NAME 'uddiTModel' SUP top STRUCTURAL MUST ( uddiTModelKey $ uddiName ) MAY ( uddiAuthorizedName $ uddiOperator $ uddiDescription $ uddiOverviewDescription $ uddiOverviewURL $ uddiIdentifierBag $ uddiCategoryBag $ uddiIsHidden uddiv3TModelKey $ uddiv3DigitalSignature $ uddiv3NodeId) )
uddiPublisherAssertion
( 1.3.6.1.1.10.6.8 NAME 'uddiPublisherAssertion' SUP top STRUCTURAL MUST ( uddiFromKey $ uddiToKey $ uddiKeyedReference $ uddiUUID ) MAY ( uddiv3DigitalSignature $ uddiv3NodeId) )
uddiv3Subscription
( 1.3.6.1.1.10.6.9 NAME 'uddiv3Subscription' SUP top STRUCTURAL MUST ( uddiv3SubscriptionFilter $ uddiUUID) MAY ( uddiAuthorizedName $ uddiv3SubscriptionKey $ uddiv3BindingKey $ uddiv3NotificationInterval $ uddiv3MaxEntities $ uddiv3ExpiresAfter $ uddiv3BriefResponse $ uddiv3NodeId) )
uddiv3EntityObituary
( 1.3.6.1.1.10.6.10 NAME 'uddiv3EntityObituary' SUP top STRUCTURAL MUST ( uddiv3EntityKey $ uddiUUID) MAY ( uddiAuthorizedName $ uddiv3EntityCreationTime $ uddiv3EntityDeletionTime $ uddiv3NodeId) )

Name Forms
uddiBusinessEntityNameForm
( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm' OC uddiBusinessEntity MUST ( uddiBusinessKey ) )
uddiContactNameForm
( 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm' OC uddiContact MUST ( uddiUUID ) )
uddiAddressNameForm
( 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm' OC uddiAddress MUST ( uddiUUID ) )
uddiBusinessServiceNameForm
( 1.3.6.1.1.10.15.4 NAME 'uddiBusinessServiceNameForm' OC uddiBusinessService MUST ( uddiServiceKey ) )
uddiBindingTemplateNameForm
( 1.3.6.1.1.10.15.5 NAME 'uddiBindingTemplateNameForm' OC uddiBindingTemplate MUST ( uddiBindingKey ) )
uddiTModelInstanceInfoNameForm
( 1.3.6.1.1.10.15.6 NAME 'uddiTModelInstanceInfoNameForm' OC uddiTModelInstanceInfo MUST ( uddiTModelKey ) )
uddiTModelNameForm
( 1.3.6.1.1.10.15.7 NAME 'uddiTModelNameForm' OC uddiTModel MUST ( uddiTModelKey ) )
uddiPublisherAssertionNameForm
( 1.3.6.1.1.10.15.8 NAME 'uddiPublisherAssertionNameForm' OC uddiPublisherAssertion MUST ( uddiUUID ) )
uddiv3SubscriptionNameForm
( 1.3.6.1.1.10.15.9 NAME 'uddiv3SubscriptionNameForm' OC uddiv3Subscription MUST ( uddiUUID ) )
uddiv3EntityObituaryNameForm
( 1.3.6.1.1.10.15.10 NAME 'uddiv3EntityObituaryNameForm' OC uddiv3EntityObituary MUST ( uddiUUID ) )

DIT Structure Rules
uddiBusinessEntityStructureRule
( 1 NAME 'uddiBusinessEntityStructureRule' FORM uddiBusinessEntityNameForm )
uddiContactStructureRule
( 2 NAME 'uddiContactStructureRule' FORM uddiContactNameForm SUP ( 1 ) )
uddiAddressStructureRule
( 3 NAME 'uddiAddressStructureRule' FORM uddiAddressNameForm SUP ( 2 ) )
uddiBusinessServiceStructureRule
( 4 NAME 'uddiBusinessServiceStructureRule' FORM uddiBusinessServiceNameForm SUP ( 1 ) )
uddiBindingTemplateStructureRule
( 5 NAME 'uddiBindingTemplateStructureRule' FORM uddiBindingTemplateNameForm SUP ( 4 ) )
uddiTModelInstanceInfoStructureRule
( 6 NAME 'uddiTModelInstanceInfoStructureRule' FORM uddiTModelInstanceInfoNameForm SUP ( 5 ) )
uddiTModelStructureRule
( 7 NAME 'uddiTModelStructureRule' FORM uddiTModelNameForm )
uddiPublisherAssertion
( 8 NAME 'uddiPublisherAssertionStructureRule' FORM uddiPublisherAssertionNameForm )
uddiv3SubscriptionStructureRule
( 9 NAME 'uddiv3SubscriptionStructureRule' FORM uddiv3SubscriptionNameForm )
uddiv3EntityObituaryStructureRule
( 10 NAME 'uddiv3EntityObituaryStructureRule' FORM uddiv3EntityObituaryNameForm )

^
15 juillet 2013

htmlpdflatexmanmd




rfc4512

rfc4512

Directory Information Models

DIB Directory Information Base
DUA Directory User Agent
DSA Directory System Agent
DSE DSA-Specific Entry
DIT Directory Information Tree
RDN Relative Distinguished Name
AVA Attribute Value Assertions

   Le but d’un annuaire est de maintenir, et de fournir l’accès à des informations sur des objets d’interet. Un objet peut être tout ce qui peut être identifiable (peut être nommé). Certains attributs maintiennent des informations sur l’objet qu’ils représentent et sont appelés des attributs utilisateurs. D’autres attributs représentent des informations administratifs et/ou opérationnels et sont appelés des attributs opérationnels.

Classes d'objet abstraites

   Fournis une base de caractéristiques depuis lequel d’autres classes d’objet peuvent hériter. Une entrée ne peut pas appartenir à une classe abstraite à moins qu’elle appartiennent à une classe auxiliaire ou structurelle qui hérite de cette classe abstraite.

  Une classe abstraite ne peut pas dériver d’une classe auxiliaire ou structurelle. Toutes les classes d’objet structurelles dérivent directement ou indirectement de la classe objet 'top'. Une classe auxiliaire ne dérive pas nécessairement de top.

Classes d'objet structurelles

   Elles sont utilisées dans la définition de la structure des noms d’objets. Un objet ou alias est caractérisé par précisément une chaîne super-classe d’objet structurelle qui a une simple classe structurelle comme classe objet la plus subordonnée. Elle est appelée la classe objet structurelle de l’objet

Classes d'objet auxiliaires

   Elle sont utilisées pour augmenter les caractéristiques des entrées. Elle sont communément utilisées pour augmenter le jeu d’attributs requis et permit dans une entrée. Les classes auxiliaires ne peuvent pas être des sous-classes de classes structurelles

Types d'attributs

   Le type d’un attribut définis si il est multi-valué, la syntaxe et les règles de correspondance utilisées pour construire et comparer les valeurs de cet attribut, et d’autres fonctions. Si aucune correspondance d'égalité n'est spécifiée pour ce type d'attribut:

        - l’attribut ne peut pas être utilisé pour le nommage
        - 2 valeurs ne peuvent pas être équivalentes
        - les valeurs individuelles d’un attribut multi-valué ne peuvent pas être ajoutée/enlevées indépendamment
        - AVA (tels que la correspondance dans les filtres de recherche et de comparaisons) en utilisant les valeurs de cet attribut ne peuvent pas être effectuées

   Sinon, la règle de correspondance d’égalité spécifiée est utilisée pour évaluer l’AVA concernant le type d’attribut La règle d’égalité spécifiée doit être transitive et commutative.

  Le type d’attribut indique si l’attribut est un attribut utilisateur ou un attribut opérationnel. S’il est opérationnel, l’attribut indique l’usage opérationnel et si l’attribut est modifiable ou non par les utilisateurs.

  Un type d’attribut (un sous-type) peut dériver d’autres type d’attributs (un super-type). Les restrictions suivantes s’appliquent au sous-typage:

        - un sous-type doit avoir le même usage que son super-type direct la syntaxe du sous-type doit être la même, ou une re-définition de la syntaxe du super-type
        - un sous-type doit être collectif si son super-type est collectif.

   Chaque type d’attribut est identifié par un Object IDentifier (OID) et optionnellement d’un ou plusieurs noms cours (descripteurs)

Options d'attributs

   Toutes les options ne peuvent pas être associées avec des attributs maintenu dans l"annuaire. le tagging options le permet.

  Une description d’attribut peut être le sous-type direct de 0 ou plusieurs autres descriptions d’attributs. ces relations de sous-typage sont utilisées pour former une hiérarchie de description d’attributs et d’attributs.

  Les hiérarchies d’attribut permettent un accès à la DIB avec différents degré de granularité, grâce à la valeur des attributs qui sont accédés soit en utilisant leur description d’attribut direct ou une description d’attribut plus générique.

Alias

   Un alias, ou un nom alias, pour un objet est un nom alternatif qui est fournis par l’utilisation d’entrées alias. Chaque entrée alias contient dans l’attribut aliasedObjectName, le nom d’un objet.

Attributs opérationnels

   Il en existe 3 sortes:

        Directory operational attributes Est utilisé pour représenter une information opérationnelle et/ou administrative dans le Directory Information Model. Cela inclus les attributs opérationnels maintenus par le serveur (ex : createTimestamp), et les attributs opérationnels qui maintiennent des valeurs administrées par l’utilisateur (ex: ditContentRules)
        DSA-shared operational attributes Est utilisé pour représenter des information du DSA Information Model qui est partagé entre les DSA.
        DSA-specific operational attributes Est utilisé pour représenter des information sur le DSA Information Model qui est spécifique au DSA. ( bien que parfois peut être dérivé des informations partagées entres les DSA)

   Les attributs opérationnel ne sont normalement pas visible. Ils ne sont pas retournés dans les résultats de recherche à moins qu’ils aient été explicitement demandés Tous les attributs opérationnels ne sont pas modifiables.

Schéma

   Le schéma de l’annuaire est un jeu de définitions et de contraintes concernant la structure du DIT, les entrées possibles, etc.

Définition de schéma (ABNF)
oidlen = numericoid [ LCURLY len RCURLY ]
len = number
    
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )
    
extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
    
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE
    
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
    
QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
    
; Any UTF-8 encoded Unicode character
; except %x27 ("\’") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB
    
; Any ASCII character except %x27 ("\’") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F

Le champ NAME fournis un jeu de noms court qui sont utilisés comme alias pour l’OID
Le champs DESC est optionnel et apporte un description
Le champ OBSOLETE, si présent, indique que l’élément n’est pas actif

Définition de classe d'objet


ObjectClassDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    [ SP "SUP" SP oids ] ; superior object classes
    [ SP kind ] ; kind of class
    [ SP "MUST" SP oids ] ; attribute types
    [ SP "MAY" SP oids ] ; attribute types
    extensions WSP RPAREN
    
    kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"

‹numericoid› est l’OID assigné à cette classe d’objet
NAME ‹qdescrs› Sont des noms courts identifiant cette classe d’objet
DESC ‹qdstring› est une courte description
OBSOLETE indique que cette classe d’objet n’est pas active
SUP ‹oids› spécifie les super-classes directe de cette classe d’objet.
kind Spécifie le type de classe (ABSTRACT, STRUCTURAL ou AUXILIARY)
MUST et MAY spécifient les jeux d’attributs requis et permis
‹extensions› décrit les extensions

Définition des attributs


AttributeTypeDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    [ SP "SUP" SP oid ] ; supertype
    [ SP "EQUALITY" SP oid ] ; equality matching rule
    [ SP "ORDERING" SP oid ] ; ordering matching rule
    [ SP "SUBSTR" SP oid ] ; substrings matching rule
    [ SP "SYNTAX" SP noidlen ] ; value syntax
    [ SP "SINGLE-VALUE" ] ; single-value
    [ SP "COLLECTIVE" ] ; collective
    [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
    [ SP "USAGE" SP usage ] ; usage
    extensions WSP RPAREN ; extensions
    
    usage = "userApplications" / ; user
    "directoryOperation" / ; directory operational
    "distributedOperation" / ; DSA-shared operational
    "dSAOperation" ; DSA-specific operational

‹numericoid› est l’OID assigné à ce type d’attribut
NAME ‹qdescrs› sont des noms courts identifiant ce type d’attribut
DESC ‹qdstring› est une courte description
OBSOLETE Indique que cet attribut n’est pas actif
SUP oid Spécifie le supertype direct de ce type
EQUALITY, ORDERING, et SUBSTR Fournissent l’OID de l’égalité, l’ordonnancement et les règle de correspondance de chaîne, respectivement.
SYNTAX Identifie La syntaxe de la valeur par OID et peut suggérer une limite minimum
SINGLE-VALUE Indique que les attributs de ce type sont restreint à une seule valeur
COLLECTIVE Indique que cet attribut est collectif
NO-USER-MODIFICATION Indique que ce type d’attribut n’est pas modifiable par l’utilisateur
USAGE Indique l’application de ce type d’attribut
‹extensions› décrit les extensions

Chaque description de type d’attribut doit avoir au moins SUP ou SYNTAX.
Si SUP est fournis, SYNTAX, EQUALITY, ORDERING et SUBSTRING sont pris du super-type s’ils ne sont pas spécifié
COLLECTIVE nécessite un usage userApplications
NO-USER-MODIFICATION nécessite un usage opérationnel
AttributeTypeDescription ne liste pas les règles de correspondance utilisées avec ce type d’attribut dans un filtre de recherche extensibleMatch. C’est fait avec l’attribut matchingRuleUse.

Règles de correspondance

   Elles sont utilisée pour les opérations AVA tels que les opérations de comparaison ou les filtres de recherche, déterminant quelles valeurs individuelles sont ajoutée ou supprimée durant les opération de modification, et en comparant des DN.


MatchingRuleDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    SP "SYNTAX" SP numericoid ; assertion syntax
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID de la règle de correspondance
NAME ‹qdescrs› sont des noms cours décrivant la règle
DESC ‹qdstring› est une courte description
OBSOLETE Indique que cette règle n’est pas active
SYNTAX Identifie la syntaxe d’assertion par OID
‹extensions› Décris les extensions

Utilisation des règles de correspondance

   Une règle de correspondance liste les types d’attributs qui sont utilisables avec un filtre de recherche extensibleMatch


MatchingRuleUseDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    SP "APPLIES" SP oids ; attribute types
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID de la règle associée avec cette utilisation de règle
NAME ‹qdescrs› Sont des noms cours identifiant l’utilisation de règle
DESC ‹qdstring› est une courte description
OBSOLETE indique que cette utilisation de règle de correspondance est désactivée
APPLIES Fournis une liste de type d’attributs auxquel la règle s’applique
‹extensions› décrit les extensions

Syntaxes LDAP

   Les syntaxes LDAP de valeurs d’attribut et d’assertion sont décrites en ASN.1 et optionnellement, ont un encodage de chaîne (LDAP-specific encoding), généralement en UTF-8.


SyntaxDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "DESC" SP qdstring ] ; description
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID assignée à cette syntaxe LDAP
DESC ‹qdstring› est une courte description
‹extensions› Décris les extensions

Règles de contenu DIT

   Une DIT content rule est une règle régissant le contenu des entrées d’une classe d’objet structurelle particulière. Elle définissent quelles classes d’objets auxiliaires sont requis, permis on non permises dans l’entrée.


DITContentRuleDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    [ SP "AUX" SP oids ] ; auxiliary object classes
    [ SP "MUST" SP oids ] ; attribute types
    [ SP "MAY" SP oids ] ; attribute types
    [ SP "NOT" SP oids ] ; attribute types
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID de la classe structurelle associée avec ces DIT content rule
NAME ‹qdescrs› Sont des noms cours identifiant ce DIT content rule
DESC ‹qdstring› est une courte description
OBSOLETE Indique que ce DIT content rule est inactif
AUX Spécifie une liste de classes auxiliaires que les entrée sujettes à ce DIT content rules peuvent appartenir.
MUST, MAY, et NOT Spécifient les listes de type d’attributs qui sont requis, permis ou non-permis
‹extensions› décrit les extensions

Règles de structure DIT

   Une règle de structure DIT est une règle régissant la structure du DIT en spécifiant un supérieur autorisé à subordonner la relation d’entrée. une règle de structure concerne une forme de nom, et donc une classe structurelle, de structurer les règles supérieurs. Celà permet au entrées de la classe structurelle identifiées par la forme de nom d’exister dans le DIT comme subordonnée aux entrée régies par la règle structurelle supérieur.


DITStructureRuleDescription = LPAREN WSP
    ruleid ; rule identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    SP "FORM" SP oid ; NameForm
    [ SP "SUP" ruleids ] ; superior rules
    extensions WSP RPAREN ; extensions
    
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number

‹ruleid› est identifiant de règle de ce DIT structure rule
NAME ‹qdescrs› sont des noms identifiant ce DIT structure rule
DESC ‹qdstring› est une courte description
OBSOLETE indique que ce DIT structure rule use n’est pas actif
FORM spécifie le name form associé à ce DIT structure rule
SUP identifie les règles supérieurs (par rule id)
‹extensions› Décris les extensions

Formes de nom

   un name form spécifie un RDN permis pour les entrées d’une classe d’objet structurelle particulière. il identifie une classe nommée et un ou plusieurs types d’attributs pour le nommage (ex: le RDN). ce sont des pièces primitives de spécification utilisées dans la définition de règles de structures de DIT. Chaque name form indique la classe structurelle à nommer, un jeu de types d’attributs requis, et un autre pour les types permis.


NameFormDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    SP "OC" SP oid ; structural object class
    SP "MUST" SP oids ; attribute types
    [ SP "MAY" SP oids ] ; attribute types
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID du name form
NAME ‹qdescrs› sont des noms identifiant ce name form
DESC ‹qdstring› est une courte description
OBSOLETE indique que ce name form est inactif
OC identifie la classe structurelle à laquelle cette règle s’applique
MUST et MAY Spécifient les jeux d’attributs nommés requis et permis pour ce name form
‹extensions› Décris les extensions

Sous-entrées de sous-schéma

   Elles sont utilisée pour administrer les informations sur le schéma de l’annuaire. Une sous-entrée de sous-schéma contient toutes les définitions de schéma utilisées par les entrées dans une partie de l’arborescence. Les serveurs peuvent autoriser la modification du sous-schéma.

Découverte du sous-schéma

   Pour découvrir le DN du sous-schéma qui maintient le sous-schéma contrôlant une entrée particulière, un client lit l’attribut opérationnel subschemaSubentry de cet entrée. Pour lire cet attribut, le client doit fournir une opération de recherche où le baseObject est le DN de l’entrée de sous-schéma. Le scope est baseObject, le filtre est "(objectClass=subschema)" et le champs attributs liste les attributs désirés.

DSA Information Model

   Le protocole LDAP assume qu’il y’a un ou plusieurs serveurs qui fournissent conjointement accès au DIT. Le serveur maintenant l’information originale est appelée le master, ceux qui maintiennent une copie, des serveurs shadowing ou caching.

context prefix La séquence de RDN partant de la racine du DIT jusqu’au vertex initial d’un contexte de nommage, correspondant au DN de ce vertex
naming context Une sous-arborescence d’entrées maintenus dans un DSA master

   Un contexte de nommages est la plus grande collection d’entrées, commençant à une entrée master, et incluant tous ses subordonnés et leur subordonnés, jusqu’aux entrées qui sont master sur d’autres serveurs. Le Root d’un DIT est un DSE et ne fait pas partit d’un contexte de nommage (ou d’une sous-arborescence). Chaque serveur a des valeurs d’attribut différents dans le root DSE.

Server-Specific Data Requirements

   Un serveur LDAP devrait fournir des informations sur lui-même et d’autres informations qui sont spécifiques à d’autres serveurs. C’est représenté sous la forme d’un groupe d’attributs dans le root DSE, qui sont nommé avec un DN sans RDN.

Cache et Shadowing

   Certains serveurs maintiennent des copies des entrées, qui peuvent être utilisée pour répondre à des requêtes ou des comparaisons, mais vont retourner des referrals ou contacter d’autres serveur si des opérations de modification sont demandées. Ces serveurs doivent s’assurer qu’ils ne violent pas de contrôle d’accès.

Conduite des serveurs

- Les serveurs doivent reconnaître tous les noms des attributs et classes définis dans ce document, mais n’ont pas besoin de supporter les fonctionnalité associés (sauf mentionné).
- Les serveurs doivent s’assurer que les entrées sont conformes au règles de schéma et autres contraintes
- Les serveurs peuvent supporter: DIT Content Rules, DIT Structure Rules, Name Forms, alias, la classe object extensibleObject, les sous-entrées.
- Les serveurs peuvent implémenter des éléments de schéma additionnel.

Considération IANA

Les descripteurs suivant réfèrent à cette RFC :
NAME    Type    OID
    
alias O 2.5.6.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0

Description des attributs

aliasedObjectName Le DN de l’objet pointé
objectClass Chaque entrée dans le DIT a un attribut objectClass
creatorsName Créateur de l’entrée dans le DIT
createTimestamp Date et heure de la création de l’entrée
modifiersName Spécifie le DN du dernier modificateur de l’objet
modifyTimestamp Date et heure de la dernière modification de l’objet
structuralObjectClass Indique la classe objet structurelle de l’entrée
governingStructureRule Indique la règle gouvernante de l’entrée
subschemaSubentry Permet aux clients de découvrir les attributs et classes d’objet permis et présents dans l’arborescence
objectClasses Maintient les définitions des classes d’objet
attributeTypes Maintient les définitions des types d’attributs
matchingRules Maintient les définitions des règles de correspondance
matchingRuleUse Maintient les définitions des utilisations de règle de correspondance
ldapSyntaxes Maintient les définitions des syntaxes LDAP
dITContentRules Maintient les définitions des règles de contenu de DIT
dITStructureRules Maintient les définitions des règles de structure de DIT
nameForms Liste les Names Form qui sont forcés
altServer (Root DSE) Serveurs alternatifs
namingContexts (Root DSE) Contexte de nommage
supportedControl (Root DSE) Contrôles LDAP reconnus
supportedExtension (Root DSE) Opération étendues reconnus
supportedFeatures (Root DSE) fonctionnalités LDAP reconnus
supportedLDAPVersion (Root DSE) Versions LDAP supportées
supportedSASLMechanisms (Root DSE) Mécanismes SASL reconnus

Description des classes d'objet

alias Un objet alias
subschema Le sous-schéma est maintenu en sous-entrées appartenant à cette classe
extensibleObject Permet à des objets de maintenir des attributs utilisateur

Définition des attributs


attributeType ( 2.5.4.1 NAME ’aliasedObjectName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE )
    
attributeType ( 2.5.21.5 NAME ’attributeTypes’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
    USAGE directoryOperation )
    
attributeType ( 2.5.21.4 NAME ’matchingRules’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
    USAGE directoryOperation )
    
attributeType ( 2.5.21.8 NAME ’matchingRuleUse’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
    USAGE directoryOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.16 NAME ’ldapSyntaxes’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
    USAGE directoryOperation )
    
attributeType ( 2.5.4.0 NAME ’objectClass’
    EQUALITY objectIdentifierMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
    
attributeType ( 2.5.21.6 NAME ’objectClasses’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
    USAGE directoryOperation )
    
attributeType ( 2.5.18.3 NAME ’creatorsName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.18.1 NAME ’createTimestamp’
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.18.4 NAME ’modifiersName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.18.2 NAME ’modifyTimestamp’
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.21.9 NAME ’structuralObjectClass’
    EQUALITY objectIdentifierMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.21.10 NAME ’governingStructureRule’
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.18.10 NAME ’subschemaSubentry’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.21.2 NAME ’dITContentRules’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
    USAGE directoryOperation )
    
attributeType ( 2.5.21.1 NAME ’dITStructureRules’
    EQUALITY integerFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
    USAGE directoryOperation )
    
attributeType ( 2.5.21.7 NAME ’nameForms’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
    USAGE directoryOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.6 NAME ’altServer’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.5 NAME ’namingContexts’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.13 NAME ’supportedControl’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.7 NAME ’supportedExtension’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.4203.1.3.5 NAME ’supportedFeatures’
    EQUALITY objectIdentifierMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.15 NAME ’supportedLDAPVersion’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.14 NAME ’supportedSASLMechanisms’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    USAGE dSAOperation )

Définition des classes d'objet


objectClass ( 2.5.6.1 NAME ’alias’
    SUP top STRUCTURAL
    MUST aliasedObjectName )
    
objectClass ( 2.5.20.1 NAME ’subschema’ AUXILIARY
    MAY ( dITStructureRules $ nameForms $ ditContentRules $
    objectClasses $ attributeTypes $ matchingRules $
    matchingRuleUse ) )
    
objectClass ( 1.3.6.1.4.1.1466.101.120.111 NAME ’extensibleObject’
    SUP top AUXILIARY )

^
23 août 2013

htmlpdflatexmanmd




rfc4513

rfc4513

Mécanismes de sécurité et méthodes d'authentification

   LDAP offre les mécanismes de sécurité suivants :

- Authentification simple (Bind) fournis des mécanisme nom/mot de passe, et SASL.
- Des mécanismes pour supporter des contrôles d'accès spécifiques au vendeur
- Un service d'intégrité des données via TLS ou des mécanismes SASL
- Un service de confidentialité des données via TLS ou des mécanismes SASL
- Limitation de l'utilisation des ressources serveurs au moyen de limites administratives
- Authentification serveur via TLS ou des mécanismes SASL

   Il est désirable de permettre aux clients de s'authentifier en utilisant divers mécanismes où les identités sont représentées sous forme de DN (RFC4512), chaîne (RFC4514), ou un nom d'utilisateur simple (RFC4013). Un serveur LDAP doit supporter le mécanisme d'authentification anonyme (Bind). Les implémentations LDAP qui supportent un mécanisme d'authentification autre que l'authentification anonyme (Bind) doivent supporter le mécanisme d'authentification nom/mot de passe Bind et doivent être capable de protéger ces accréditifs en utilisant TLS

Opération StartTLS

   Le but d'utiliser TLS avec LDAP est de s'assurer de la confidentialité et de l'intégrité des données, et optionnellement fournir l'authentification. Les services d'authentification de TLS sont disponibles dans LDAP uniquement en combinaison avec la méthode d'authentification SASL externe.

StartTLS Request Sequencing

   Un client peut envoyer la requête étendue StartTLS n'importe quand après avoir établis une session LDAP, excepté:

- Quand TLS est actuellement établie dans la session
- Quand une négociation multi-niveau SASL est en cours
- Quand il y'a des réponse en attente pour des requêtes précédemment fournies dans la session

   Une violation de ces points résultent en code de retour operationsError

Certificat Client

   Si des requêtes ou des demandes LDAP qu'un client émet en fournissant un certificat durant la négociation TLS et que ce certificat n'est pas utilisable ou ne peut être validé, le serveur peut utiliser une stratégie de sécurité local pour déterminer si la négociation réussie ou non.

Vérification de l'identité du serveur

   Pour prévenir d'une attaque MITM, le client doit vérifier l'identité du serveur. L'identité du serveur est appelé l'identité de référence. Le client détermine le type de l'identité de référence (ex: nom DNS ou Address IP) et effectue une comparaison entre l'identité de référence et chaque subjectAltName. Différents subjectAltName sont matchés de différentes manière.

  Le client peut mapper l'identité de référence à un type différent avant d'effectuer une comparaison, mais devrait le mapper uniquement en types pour lesquels le mappage est soit inhérent à la sécurité (ex : extraire le nom DNS de l'URI), soit pour effectuer un mappage sécurisé (ex: DNSSEC)

  L'identité du serveur peut également être vérifié en comparant son cn dans le RDN du subjectName, bien que ce soit déprécié.

Comparaison des noms DNS

   Si l'identité de référence est un nom de domaine internationalisé, il doit être convertit en ACE (ASCII Compatible Encoding) (RFC3490) avant de le comparer au SAN, en type dNSName. Le caractère '*' est autorisé dans les valeurs SAN de type dNSName.

Comparaison des adresses IP

   Quand l'identité de référence est une adresse IP, l'identité doit être convertie en représentation "network byte order" (RFC791, RFC2460) La chaîne d'octets est comparée avec le SAN de type iPAddress.

Comparaison des autres types subjectName

   L'implémentation des clients peut supporter une comparaison avec d'autres types de valeurs dans le SAN.

Discovery of Resultant Security Level

   Une fois TLS établis dans une session LDAP, les 2 parties sont libre de continuer ou non, basé sur une stratégie local et sur le niveau de sécurité atteint. Les implémentations peuvent réévaluer le niveau de sécurité à tout moment, et si le niveau est inadéquat, devraient supprimer la couche TLS.

Refresh of Server Capabilities Information

   Une fois TLS établis dans une session LDAP, le client devrait supprimer ou rafraîchir toutes les informations sur le serveur obtenu avant l'initialisation de TLS. C'est une protection aux attaques MITM.

Suite de chiffrement TLS

   De nombreux problèmes devraient être considérés en sélectionnant la suite de chiffrement TLS:

- la capacité de la suite de chiffrement à fournir une protection de confidentialité des mots de passe et autre.
- la considération de la valeur du mot de passe et/ou données versus le niveau de confidentialité fournies par lasuite de chiffrement.
- Les vulnérabilités de la suite de chiffrement aux attaque MITM. Cette suite ne devrait pas être utilisé pour protéger les mots de passe et autres données sensibles.
- Après une négociation TLS, les 2 parties devraient vérifier que les services de sécurité fournis par la suite de chiffrement négociée sont adéquat pour la session LDAP. Si ce n'est pas le cas, TLS devrait être terminé.

Etat d'Authorisation

   Toute session LDAP a un état d'autorisation. cet état comprend de nombreux facteurs tels que l'authentification établie, comment elle a été établie, et quels services de sécurité sont en place. Certains facteurs peuvent être déterminés et/ou affectés par des évènements de protocole.

  une fois la session LDAP établie, la session a une identité d'autorisation anonyme. dès qu'une session BindRequest est reçue, le serveur place la session dans un état d'autorisation anonyme. Si la requête est réussie, la session est placée dans l'état authentification requise avec son état d'autorisation associée.

Bind Operation

   Cette opération permet d'échanger des informations d'authentification entre le client et le serveur pour établir un nouvel état d'autorisation. Si l'identité d'autorisation est spécifiée, le serveur doit vérifier que l'identité d'authentification de client est permises pour permettre l'identité d'autorisation. Le serveur doit rejeter l'opération Bind avec un code invalidCredentials si le client n'est pas autorisé.

Simple Authentication Method

   L'authentification simple fournis 3 mécanismes d'authentification:

- un mécanisme d'authentification anonyme
- un mécanisme d'authentification non-authentifié
- un mécanisme d'authentification DN/mot de passe

Anonymous Authentication Mechanism of Simple Bind

   Un client LDAP peut utiliser le mécanisme d'authentification anonyme de la méthode simple Bind pour établir une autorisation anonyme en envoyant un Bind Request avec un nom vide et en spécifiant l'authentification simple contenant un mot de passe vide.

Unauthenticated Authentication Mechanism of Simple Bind

   Un client LDAP peut utiliser le mécanisme d'authentification non-authentifié de la méthode simple Bind pour établir une autorisation anonyme en envoyant un Bind Request avec un nom (DN) et en spécifiant l'authentification simple contenant un mot de passe vide.

Name/Password Authentication Mechanism of Simple Bind

   Un client LDAP peut utiliser le mécanisme d'authentification nom/mot de passe de la méthode simple Bind pour établir une autorisation anonyme en envoyant un Bind Request avec un nom (DN) et en spécifiant l'authentification simple contenant un mot de passe non vide.

Méthode d'authentification SASL

   LDAP permet d'utiliser les mécanismes SASL. Vu que LDAP fournis nativement les méthodes d'authentification anonyme et nom/mot de passe, les mécanismes similaire SASL ne sont pas utilisés avec LDAP.

Initialisation de l'authentification SASL et échange du protocole

   Le mécanisme SASL est initié via un message BindRequest avec les paramètres suivants:

- la version est 3
- AuthenticationChoice est sasl
- l'élément mécanisme de la séquence SaslCredentials contient la valeur du mécanisme SASL voulu
- Les crédentials optionnels de la séquence SaslCredentials peuvent être utilisés pour fournir une réponse client initiale pour les mécanismes qui stipulent que le client envoie les données en premier.

   un challenge est indiqué par le serveur qui envoie un message BindResponse avec un resultCode de saslBindProgress.

   Au niveau du message LDAP, ces challenges et réponses sont des tokens binaires opaque de longueur arbitraire. les serveurs LDAP utilisent le champ serverSaslCreds dans un message BindResponse pour transmettre chaque challenge. Les clients LDAP utilisent le champ credentials dans la séquence SaslCredentials d'un message BindRequest pour transmettre chaque réponse.

   Les clients envoyant un message BindRequest avec le choix sasl devraient envoyer une valeurs vide dans le champs nom, et les serveurs recevant un tel message devraient ignorer la valeur du champ nom.

  Un client peut annuler une négociation SASL en envoyant un message BindRequest avec une valeur différente dans le champ mecanism de SaslCredentials ou avec AuthenticationChoice autre que sasl.

  Le serveur indique la fin d'un échange SASL en répondant avec un BindResponse avec une valeur resultCode qui n'est pas saslBindProgress.

  Le champ serverSaslCreds dans le BindResponse peut être utilisé pour inclure un challenge optionnel avec une notification success pour les mécanismes qui spécifient que le serveur envoie des données additionnelles avec l'indication de réussite.

Champs optionnels

   LDAP fournis un champ optionnel pour une réponse initial dans un échange SASL et un champ optionnel pour les données additionnelles indiquant la sortie de l'échange. Vu que le contenu de ces champs dépend du mécanisme utilisé, SASL nécessite que le protocole détail comment un champ vide est distingué d'un champ absent. Une réponse vide est distinguée par la présence de SaslCredentials.credentials OCTET STRING (de longueur 0) dans le PDU. Si le client ne fournis pas de données additionnelles, ce champs doit être omis.

Octet où La couche de sécurité négociée prend effet

   les couches SASL prennent effet suivant la transmission par le serveur et la réception par le client d'un BindResponse final dans l'échange avec un resultCode à Success. La couche reste effective jusqu'à ce qu'une nouvelle couche soit installée

Détermination des mécanismes SASL supportés

   Les clients peuvent déterminer les mécanismes SASL supportés par le serveur en lisant l'attribut supportedSASLMecanisms depuis le Root DSE. Le serveur devrait autoriser tous les clients à lire cet attribut.

Règles pour utiliser les couches SASL

   Une fois une couche SASL installée, le client devrait supprimer ou rafraîchir les informations sur le serveur obtenus avant la négociation SASL.

Identité d'autorisation SASL

   Certains mécanismes SASL permettent aux clients de demander une identité d'autorisation pour la session LDAP. La décision de permettre ou non à l'identité d'authentification courante d'avoir accès à l'identité d'authorisation demandée est une décision locale. l'identité d'autorisation est une chaîne UTF8 sous la forme:


authzId = dnAuthzId / uAuthzId
    ; distinguished-name-based authz id
dnAuthzId = "dn :" distinguishedName
    ; unspecified authorization id, UTF-8 encoded
uAuthzId = "u :" userid
userid = *UTF8 ; syntax unspecified

Mécanismes d'authentification SASL EXTERNAL

   Un client peut utiliser le mécanisme SASL EXTERNAL pour demander au serveur LDAP d'authentifier et établir une identité d'autorisation en utilisant des crédentials de sécurité échangés par une couche de sécurité tel que par l'authentification TLS.

Implicit Assertion

   Une identité d'autorisation implicite est effectuée en invoquant une requête Bind SASL utilisant le mécanisme EXTERNAL qui n'inclus pas le champ optionnel crédentials. Le serveur va dériver l'identité d'autorisation du client de l'identité d'authentification fournies par la couche de sécurité en accord avec la stratégie locale.

Explicit Assertion

   Une identité d'autorisation explicite est effectuée en invoquant une requête Bind SASL utilisant le mécanisme EXTERNAL qui inclus le champ credentials. La valeur de ce champs est l'identité d'autorisation.

Considérations de sécurité général

   LDAP lui-même ne fournis aucune sécurité ou protection pour l'accès à l'annuaire par des moyens autres que le protocole LDAP. Les données sensibles peuvent être transportés dans presque tous les messages DAP, et leur divulgation peuvent-être soumis aux lois et autres réglementations dans de nombreux pays.

   Une session dans laquelle le client n'a pas établit des services de protection et d'intégrité des données est sujet à des attaques MITM.

   L'expérience montre que les clients peuvent mal utiliser le mécanisme d'authentification non-authentifié. Par exemple, un client peut prendre la décision de demander accès à des informations une fois une requête Bind complétée. Le serveur LDAP peut induire le client en erreurs, le laissant penser qu'il a été authentifié avec succès.

   LDAP autorise des attributs de mot de passe multi-valués. Dans les systèmes où les entrées doivent avoir un seul mot de passe, les contrôles administratifs doivent être renforcés.
^
27 juillet 2013

htmlpdflatexmanmd




rfc4514

rfc4514

Représentation des Distinguished Names

   Les annuaires X.500 utilisent des DN comme clé primaire des entrées dans l'annuaire. La structure d'un DN (X.501) est décris en ASN.1 (X.680). Dans les DAP X.500, les DN sont encodé en utilisant BER (Basic Encoding Rules) (X.690). Dans LDAP, la représentation des DN est décrite dans ce document.

X.501 définis la structure ASN.1 (X.680) des DN:
DistinguishedName ::= RDNSequence
    
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
    
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue
    
AttributeTypeAndValue ::= SEQUENCE {
    type AttributeType,
    value AttributeValue }

Exemples

un nom contenant 3 RDN:
UID=jsmith,DC=example,DC=net
3 RDN, dont le permier est multi-valué:
OU=Sales+CN=J. Smith,DC=example,DC=net
Exemple avec des caractères échappés:
CN=James \"Jim\" Smith\, III,DC=example,DC=net
Exemple d'encodage du caractère retour chariot:
CN=Before\0dAfter,DC=example,DC=net
Exemple utilisant l'encodage BER d'une chaîne de 2 octets (0x48 et 0x69):
1.3.6.1.4.1.1466.0=#04024869
Un RDN dont le cn consiste de 5 lettres:
Unicode Character Code UTF-8 Escaped
------------------------------- ------ ------ --------
LATIN CAPITAL LETTER L U+004C 0x4C L
LATIN SMALL LETTER U U+0075 0x75 u
LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
LATIN SMALL LETTER I U+0069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
Peut être encodé:
CN=Lu\C4\8Di\C4\87
^
15 juillet 2013

htmlpdflatexmanmd




rfc4515

rfc4515

Représentation des chaînes dans le filtres de recherche

Définition d'un filtre de recherche


Filter ::= CHOICE {
    and [0] SET SIZE (1..MAX) OF filter Filter,
    or [1] SET SIZE (1..MAX) OF filter Filter,
    not [2] Filter,
    equalityMatch [3] AttributeValueAssertion,
    substrings [4] SubstringFilter,
    greaterOrEqual [5] AttributeValueAssertion,
    lessOrEqual [6] AttributeValueAssertion,
    present [7] AttributeDescription,
    approxMatch [8] AttributeValueAssertion,
    extensibleMatch [9] MatchingRuleAssertion }
    
SubstringFilter ::= SEQUENCE {
    type AttributeDescription, initial and final can occur at most once
    substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
        initial [0] AssertionValue,
        any [1] AssertionValue,
        final [2] AssertionValue } }
    
AttributeValueAssertion ::= SEQUENCE {
    attributeDesc AttributeDescription,
    assertionValue AssertionValue }
    
MatchingRuleAssertion ::= SEQUENCE {
    matchingRule [1] MatchingRuleId OPTIONAL,
    type [2] AttributeDescription OPTIONAL,
    matchValue [3] AssertionValue,
    dnAttributes [4] BOOLEAN DEFAULT FALSE }
    
AttributeDescription ::= LDAPString Constrained to ‹attributedescription› [RFC4512]
    
AttributeValue ::= OCTET STRING
    
MatchingRuleId ::= LDAPString
    
AssertionValue ::= OCTET STRING
    
LDAPString ::= OCTET STRING UTF-8 encoded, [Unicode] characters

AttributeDescription est une représentation chaîne d'une description d'attribut
AttributeValue et AssertionValue ont une forme définie dans la RFC4517

Définition des filtres de recherche

Un filtre LDAP est une chaîne UTF8 définis par la grammaire suivante (notation ABNF)
filter = LPAREN filtercomp RPAREN
filtercomp = and / or / not / item
and = AMPERSAND filterlist
or = VERTBAR filterlist
not = EXCLAMATION filter
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype assertionvalue
filtertype = equal / approx / greaterorequal / lessorequal
equal = EQUALS
approx = TILDE EQUALS
greaterorequal = RANGLE EQUALS
lessorequal = LANGLE EQUALS
extensible = ( attr [dnattrs]
    [matchingrule] COLON EQUALS assertionvalue )
    / ( [dnattrs]
    matchingrule COLON EQUALS assertionvalue )
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue
attr = attributedescription
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
    ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
    ; RPAREN, ASTERISK, and ESC.
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")

Exemples

cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)
utilisation du matching rule "caseExactMatch":
(cn:caseExactMatch:=Fred Flintstone)
utilisation d'un MatchingRuleAssertion sans matchingRule:
(cn:=Betty Rubble)
Utilisation de la notation :oid:
(sn:dn:2.4.6.8.10:=Barney Rubble)
equality match, excepté que le DN devrait faire partie de l'entrée:
(o:dn:=Ace Industry)
exemples de matching rules:
(:1.2.3:=Wilma Flintstone)
(:DN:2.4.6.8.10:=Dino)
utilisation du mécanisme d'échappement:
(o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)
^
15 juillet 2013

htmlpdflatexmanmd




rfc4516

rfc4516

Uniform Resource Locator

   Ce document décrit le format des URL LDAP v3, ainsi que les mécanismes d'extensions d'URL

Définition d'URL


ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
    [SLASH dn [QUESTION [attributes]
    [QUESTION [scope] [QUESTION [filter]
    [QUESTION extensions]]]]]
    
scheme = "ldap"
dn = distinguishedName
attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector)
selector = attributeSelector
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid
exvalue = LDAPString
EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
    
"ldap" indique une/des entrées accéssible depuis le serveur LDAP
‹dn› est un DN identifiant l'objet de base pour la recherche
‹attributes› indique quels attributs doivent être retournés
‹scope› spécifie le scope de la recherche
‹filter› spécifie le filtre de recherche
‹extensions› fournis un mécanisme d'extension, utilisé dans de futures extension des URL. préfix par '!' indique une extension critique

Percent-Encoding

une URL LDAP doit consister des jeux de caractères restreins dans une des production suivantes:(RFC3986)
‹reserved›
‹unpreserved›
‹pct-encoded›

Valeurs par défaut

‹port› 389
‹dn› DN vaut ''
‹attributes› renvois tous les attributs utilisateur
‹scope› base
‹filter› (objectClass=*)
‹extensions› par extensions

Exemples

Réfère à l'entrée université du Michigan, disponible sur un serveur LDAP
ldap:///o=University%20of%20Michigan,c=US
Idem, en précisant le serveur LDAP
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Idem en référant uniquement à l'attribut postalAddress
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US?postalAddress
spécifie le serveur:port et référant à toute entrée avec un cn="Babs Jensen" et récupérant tous les attributs
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
Réfère à tous les enfants de c=GB
LDAP://ldap1.example.com/c=GB?objectClass?ONE
Récupère le mail de l'entrée o=Question%3f,c=US
ldap://ldap2.example.com/o=Question%3f,c=US?mail
Illustre l'interaction entre les mécanismes de filters-quoting des chaînes LDAP et les mécanisme d'URL-quoting
ldap://ldap3.example.com/o=Babsco,c=US???(four-octet=%5c00%5c00%5c00%5c04)
Illustre l'interaction entre les macnismes de DN-quoting et d'URL-quoting
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
Les 3 requêtes suivantes sont identiques et pointent sur le root DSE de ldap.example.net
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
Utilisation d'une extension expérimentale et hypothétique:
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
^
28 septembre 2013

htmlpdflatexmanmd




rfc4517

rfc4517

Syntaxe et règles de correspondance

   Chaque attribut stocké dans un annuaire LDAP, dont les valeurs peuvent être transférés dans le protocole LDAP, a une syntaxe définie qui contraint la structure et le format de ces valeurs.

Productions ABNF communes:
keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
    
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
    
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0)
keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
    
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
    
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""")
SHARP = %x23 ; octothorpe (or sharp sign) ("#")
DOLLAR = %x24 ; dollar sign ("$")
SQUOTE = %x27 ; single quote ("'")
LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",")
HYPHEN = %x2D ; hyphen ("-")
DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (" ;")
LANGLE = %x3C ; left angle bracket ("‹")
EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket ("›")
ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace
RCURLY = %x7D ; right curly brace
    
; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0)
    
OCTET = %x00-FF ; Any octet (8-bit data unit) SPACE = %x20 ; space (" ")

Définitions communes
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (" :")
QUESTION = %x3F ; question mark (" ?")

Attribute Type Description

Définition d'un type d'attribut. ex:
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )

La définition LDAP pour la syntaxe de la description du type attribut est:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )

Bit String

séquence de chiffre binaire:
BitString = SQUOTE *binary-digit SQUOTE "B"
binary-digit = "0" / "1"

exemple:
'0101111101'B
La définition LDAP pour la syntaxe chaine de bits:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )

Boolean


Boolean = "TRUE" / "FALSE"

La définition LDAP pour la syntaxe booléen est:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )

Country String

Code de 2 caractèresISO 3166 pour représenter un pays:
CountryString = 2(PrintableCharacter)

exemple:
US
AU
La définition LDAP pour la syntaxe Country String est:
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )

Delivery Method

Séquence d'éléments qui indiquent, par ordre de préférence, les services par lesquels une entité est prête et/ou capable de recevoir des messages:
DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"

exemple:
telephone $ videotex
La définition LDAP pour la méthode de livraison est:
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )

Directory String

Chaîne de caractères arbitraire UCS (Universal Character Set). Une valeur nulle n'est pas permise:
DirectoryString = 1*UTF8

exemple:
This is a value of Directory String containing # !%#@.
La définition LDAP pour les chaînes d'annuaire est:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )

DIT Content Rule Description

   La syntaxe est décrite dans la rfc 4512

exemple:
( 2.5.6.4 DESC 'content rule for organization' NOT ( x121Address $ telexNumber ) )
La définition LDAP pour la syntaxe DIT Content Rule Description est:
( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' )

DIT Structure Rule Description

   La syntaxe est décrite dans la rfc 4512

exemple:
( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
La définition LDAP pour la DIT Structure Rule Description est:
( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description' )

DN

   La syntaxe est définie dans la rfc 4514

exemples:
UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net
CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87
La définition LDAP pour la syntaxe DN est:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )

Enhanced Guide

consiste de combinaison de types d'attributs et opérateurs de recherche; à utiliser dans la construction de filtres pour rechercher des entrées de classe d'objet particulier
EnhancedGuide = object-class SHARP WSP criteria WSP
    SHARP WSP subset
object-class = WSP oid WSP
subset = "baseobject" / "oneLevel" / "wholeSubtree"
    
criteria = and-term *( BAR and-term )
and-term = term *( AMPERSAND term )
term = EXCLAIM term / attributetype DOLLAR match-type / LPAREN criteria RPAREN / true / false
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
true = " ?true"
false = " ?false"
BAR = %x7C ; vertical bar ("|")
AMPERSAND = %x26 ; ampersand ("&")
EXCLAIM = %x21 ; exclamation mark (" !")

La définition LDAP de la syntaxe Enhanced Guide est:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
exemple:
person#(sn$EQ)#oneLevel

Facsimile Telephone Number


fax-number = telephone-number *( DOLLAR fax-parameter )
    telephone-number = PrintableString
    fax-parameter = "twoDimensional" / "fineResolution" / "unlimitedLength" / "b4Length" / "a3Width" / "b4Width" / "uncompressed"

La définition LDAP pour Facsimile Telephone Number est:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')

Fax

la définition LDAP de la syntaxe Fax est:
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )

Generalized Time

Chaîne représentant une date et heure. L'encodage LDAP est une restriction du format définis dans ISO8601
GeneralizedTime = century year month day hour
    [ minute [ second / leap-second ] ]
    [ fraction ]
    g-time-zone
    
century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09" / ( %x31 %x30-32 ) ; "10" to "12"
day = ( %x30 %x31-39 ) ; "01" to "09" / ( %x31-32 %x30-39 ) ; "10" to "29" / ( %x33 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-35 %x30-39 ; "00" to "59"
    
second = ( %x30-35 %x30-39 ) ; "00" to "59"
leap-second = ( %x36 %x30 ) ; "60"
    
fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z" / g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-")

exemple:
199412161032Z
199412160532-0500
La définition LDAP pour Generalized Time est:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )

Guide

consiste de combinaison de types d'attributs et opérateurs de recherche ; à utiliser dans la construction de filtres pour rechercher des entrées de classe d'objet particulier. Obsolète.
Guide = [ object-class SHARP ] criteria

La définition LDAP pour la syntaxe Guide est:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )

IA5 String

   Chaîne de 0, un ou plusieurs caractères de l'alphabet International 5 (IA5)

La définition LDAP pour la syntaxe IA5 String est:
( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )

Integer


Integer = ( HYPHEN LDIGIT *DIGIT ) / number

La définition LDAP pour la syntaxe Interger est:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )

JPEG

   Image au format JFIF (JPEG File Interchange Format)

La définition LDAP de la syntaxe JPEG est:
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )

LDAP Syntax Description

Description d'une syntaxe LDAP. La définition LDAP pour la syntaxe LDAP Syntaxe Description est:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )

Matching Rule Description

Définition d'un matching rule. La définition LDAP pour la syntaxe Matching Rule Description est:
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
exemple:
( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Matching Rule Use Description

La définition LDAP de la syntaxe Matching Rule Use Description est:
( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' )
exemple:
( 2.5.13.16 APPLIES ( givenName $ surname ) )

Name and Optional UID

DN d'une entité optionnellement accompagnée par un id unique qui sert à différentier l'entité des autres avec un dn identique :
NameAndOptionalUID = distinguishedName [ SHARP BitString ]

exemple:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
La définition LDAP pour la syntaxe Name and Optional UID est:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )

Name Form Description

La définition LDAP pour la syntaxe Name Form Description est:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
exemple:
( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )

Numeric String

Séquence d'un ou plusieurs numéraires et espaces
NumericString = 1*(DIGIT / SPACE)

exemple:
15 079 672 281
La définition LDAP pour la syntaxe Numeric String est:
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )

Object Class Description

exemple:
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) )
La définition LDAP pour la syntaxe Object Class Description est:
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )

Octet String

Séquence de 0, 1 ou plusieurs octets arbitraire.
OctetString = *OCTET

La définition LDAP pour la syntaxe Octet String est :
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )

OID

   Séquence de 2 ou plusieurs entiers non-négatifs qui identifie de manière unique certain objets ou spécifications.

exemple:
1.2.3.4
cn
La définition LDAP pour la syntaxe OID est:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )

Other Mailbox

Identifie une boite de messagerie électronique.
OtherMailbox = mailbox-type DOLLAR mailbox
    mailbox-type = PrintableString
    mailbox = IA5String

La définition LDAP pour la syntaxe Other Mailbox est:
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )

Postal Address

Séquence arbitraire d'un ou plusieurs caractères UCS, qui forment une adresse d'un système de messagerie physique
PostalAddress = line *( DOLLAR line )
line = 1*line-char
line-char = %x00-23
    / (%x5C "24") ; escaped "$"
    / %x25-5B
    / (%x5C "5C") ; escaped "\"
    / %x5D-7F
    / UTFMB

exemple:
1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
La définition LDAP pour la syntaxe Postal Address est:
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )

Printable String

   Chaîne d'un ou plusieurs caractères imprimable

exemple:
ceci est une chaîne imprimable
La définition LDAP pour la syntaxe Printable String est:
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )

Substring Assertion

Séquence de 0, 1 ou plusieurs caractères sous-chaîne utilisé comme argument pour les correspondance de sous-chaîne extensible.
SubstringAssertion = [ initial ] any [ final ]
    
initial = substring
any = ASTERISK *(substring ASTERISK)
final = substring
ASTERISK = %x2A ; asterisk ("*")
    
substring = 1*substring-character
substring-character = %x00-29
    / (%x5C "2A") ; escaped "*"
    / %x2B-5B
    / (%x5C "5C") ; escaped "\"
    / %x5D-7F
    / UTFMB

La définition LDAP pour la syntaxe Substring Assertion est:
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )

Telephone Number

exemple:
+1 512 315 0280
+1-512-315-0280
+61 3 9896 7830
La définition LDAP pour la syntaxe Telephone Number est:
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )

Teletex Terminal Identifier


teletex-id = ttx-term *(DOLLAR ttx-param)
ttx-term = PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = *ttx-value-octet
    
ttx-value-octet = %x00-23
    / (%x5C "24") ; escaped "$"
    / %x25-5B
    / (%x5C "5C") ; escaped "\"
    / %x5D-FF

La définition LDAP pour la syntaxe Teletex Terminal Identifier est:
( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )

Telex Number


telex-number = actual-number DOLLAR country-code
    DOLLAR answerback
actual-number = PrintableString
country-code = PrintableString
answerback = PrintableString

La définition LDAP pour la syntaxe Telex Number est:
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )

UTC Time

Chaîne représentant une date et heure à une précision d'une minute ou une seconde.
UTCTime = year month day hour minute [ second ]
    [ u-time-zone ]
u-time-zone = %x5A ; "Z"
    / u-differential
u-differential = ( MINUS / PLUS ) hour minute

La définition LDAP pour la syntaxe UTC Time est:
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )

Règles de correspondance

   Ces règles sont utilisées par les annuaires pour comparer des valeurs d'attribut avec des valeurs lors d'opérations de recherche et de comparaison. Elles sont utilisée également pour comparer un dn emprunté avec le nom d'une entrée. En modifiant des entrées, ces règles sont utilisées pour identifier des valeurs à supprimer et pour empêcher qu'un attribut ne contienne 2 valeurs égales.

   Un matching rule est appliqué à un attribut via un AttributeValueAssertion ou un MatchingRuleAssertion. Si une assertion est définie, le résultat de l'assertion est le résultat de l'application de la règle appliquée.

   La description de chaque règle indique si la règle est utilisable pour une égalité (EQUALITY), ordonnancement (ORDERING) ou sous-chaîne (SUBSTR) dans une définition de type d'attribut.

   Les serveurs doivent publier, dans l'attribut matchinRules, les définitions des règles référencées dans le même sous-schéma. Si le serveur supporte le filtre extensibleMatch, le serveur peut utiliser l'attribut matchingRuleUse pour indiquer cette capacité.

   Les comparaison de chaîne "caseIgnore" sont des comparaisons insensibles à la casse.

bitStringMatch

   Comparaison de chaîne de bits. (règle d'égalité)

La définition LDAP pour la règle bitStringMatch est:
( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

booleanMatch

   Comparer une valeur booléenne. (règle d'égalité)

La définition LDAP pour la règle booleanMatch est:
( 2.5.13.13 NAME 'booleanMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

caseExactIA5Match

   Comparaison d'une chaîne IA5. (règle d'égalité)

La définition LDAP pour la règle caseExactIA5Match est:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

caseExactMatch

   Comparaison de syntaxe Directory String. (règle d'égalité)

La définition LDAP pour la règle caseExactMatch est:
( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

caseExactOrderingMatch

   Comparaison d'une syntaxe Directory String. (règle d'ordonnancement)

La définition LDAP pour la règle caseExactOrderingMatch est:
( 2.5.13.6 NAME 'caseExactOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

caseExactSubstringsMatch

   Compare une syntaxe Substring Assertion. (règle de substring)

La définition LDAP pour la règle caseExactSubstringsMatch est:
( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

caseIgnoreIA5Match

   Comparaison de chaîne IA5 (règle d'égalité)

La définition LDAP pour la règle caseIgnoreIA5Match est:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

caseIgnoreIA5SubstringsMatch

   Comparaison de substring IA5. (règle de substring)

La définition LDAP pour la règle caseIgnoreIA5SubstringsMatch est:
( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

caseIgnoreListSubstringsMatch

   Comparaison de substring d'une syntaxe Directory String. (règle de substring)

La définition LDAP pour la règle caseIgnoreListSubstringsMatch est:
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

caseIgnoreMatch

   Comparaison de syntaxe Directory String. (règle d'égalité)

La définition LDAP pour la règle caseIgnoreMatch est:
( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

caseIgnoreOrderingMatch

   Comparaison de syntaxe Directory String. (règle d'ordonnancement)

La définition LDAP pour la règle caseIgnoreOrderingMatch est:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

caseIgnoreSubstringsMatch

   Comparaison de substring syntaxe Directory String. (règle de substring)

La définition LDAP pour la règle caseIgnoreSubstringsMatch est:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

directoryStringFirstComponentMatch

   Comparaison de syntaxe Directory String dont la syntaxe est une séquence avec un premier composant obligatoire. (règle d'égalité)

La définition LDAP pour la règle directoryStringFirstComponentMatch est:
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

distinguishedNameMatch

   Comparaison de DN. (règle d'égalité)

La définition LDAP pour la règle distinguishedNameMatch est:
( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

generalizedTimeMatch

   Comparaison de syntaxe Generalized Time. (règle d'égalité)

La définition LDAP pour la règle generalizedTimeMatch est:
( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

generalizedTimeOrderingMatch

   Comparaison d'ordre de temps de syntaxe Generalized Time. (règle d'ordonnancement)

La définition LDAP pour la règle generalizedTimeOrderingMatch est:
( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

integerFirstComponentMatch

   Comparaison de valeur Integer dont le type est une séquence avec un premier composant obligatoire. (règle d'égalité)

La définition LDAP pour la règle integerFirstComponentMatch est:
( 2.5.13.29 NAME 'integerFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

integerMatch

   Comparaison de valeur entière. (règle d'égalité)

La définition LDAP pour la règle integerMatch est:
( 2.5.13.14 NAME 'integerMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

integerOrderingMatch

   Comparaison d'ordre de valeur entière. (règle d'ordonnancement)

La définition LDAP pour la règle integerOrderingMatch est:
( 2.5.13.15 NAME 'integerOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

keywordMatch

   Comparaison de valeur de mot clé dans une syntaxe DirectoryString. (règle d'égalité)

La définition LDAP pour la règle keywordMatch est:
( 2.5.13.33 NAME 'keywordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

numericStringMatch

   Comparaison de chaîne numérique. (règle d'égalité)

La définition LDAP pour la règle numericStringMatch est:
( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

numericStringOrderingMatch

   Comparaison de syntaxe substring Assertion dans une valeur d'attribut de type NumericString. (règle d'égalité)

La définition LDAP pour la règle numericStringOrderingMatch est:
( 2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

objectIdentifierFirstComponentMatch

   Comparaison d'OID dont le type est une séquence avec un premier composant obligatoire. (règle d'égalité)

La définition LDAP pour la règle objectIdentifierFirstComponentMatch est:
( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

objectIdentifierMatch

   Comparaison d'OID. (règle d'égalité)

La définition LDAP pour la règle objectIdentifierMatch est:
( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

octetStringMatch

   Comparaison de syntaxe Octet String. (règle d'égalité)

La définition LDAP pour la règle octetStringMatch est:
( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

octetStringOrderingMatch

   Comparaison d'ordonnancement de chaîne d'octets. (règle d'ordonnancement)

La définition LDAP pour la règle octetStringOrderingMatch est:
( 2.5.13.18 NAME 'octetStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

telephoneNumberMatch

   Comparaison de syntaxe TelephoneNumber. (règle d'égalité)

La définition LDAP pour la règle telephoneNumberMatch est:
( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

telephoneNumberSubstringsMatch

   Comparaison de substring de syntaxe TelephoneNumber. (règle de substring)

La définition LDAP pour la règle telephoneNumberSubstringsMatch est:
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

uniqueMemberMatch

   Comparaison de syntaxe NameAndOptionalUID. (règle d'égalité)

La définition LDAP pour la règle uniqueMemberMatch est:
( 2.5.13.23 NAME 'uniqueMemberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

wordMatch

   Comparaison de mot dans une valeur de syntaxe DirectoryString.

La définition LDAP pour la règle wordMatch est:
( 2.5.13.32 NAME 'wordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
^
07 juillet 2013

htmlpdflatexmanmd




rfc4519

rfc4519

Schema pour les applications utilisateurs

Attributs

businessCategory Décrit le type de business de l’entreprise
c countryName dans x500 (code à 2 lettres du pays)
cn commonName dans x500. Nom d’un objet
dc domainComponent, chaîne contenant un composant du domaine DNS
description Description de l’objet
destinationIndicator Contient la ville et le pays associé avec un objet nécessaire pour fournir le Public Telegram Service (ex : AASD)
distinguisedName type de base depuis lequel les type d’attributs utilisateur avec une syntaxe DN peuvent hériter
dnQualifier Contient des informations non-ambiguës à ajouter au RDN d’une entrée
enhancedSearchGuide Jeu d’informations utilisés par les client LDAP pour construire des filtres de recherche (ex : "person#(sn$APPROX)#wholeSubtree", ex : "organizationalUnit#(ou$SUBSTR)#oneLevel")
facsimileTelephoneNumber Numéro de téléphone (et optionnellement, les paramètres) pour les terminaux de télécopie
generationQualifier Contient généralement un suffixe du nom d’une personne (ex : "III", "3rd", "Jr.")
givenName Prénom d’une personne
houseIdentifier Identifiant d’un immeuble
initials Initial du prénom
internationalISDNNumber Adresses Integrated Service Digital Network.
l localityName dans X500. nom d’emplacement tel qu’un ville, un pays, région...
member Liste de DN d’objets
name supertype d’attribut depuis lequel les types d’attribut utilisateurs avec une syntaxe de nom peuvent hériter
o organizationName dans x500, contient les nom d’une organisation ( ex : Widget", "Widget, Inc.", "Widget, Incorporated.")
ou organizationalUnitName dans x500, contient les noms d’une unité organisationnelle (ex : "Finance", "Human Resources", "Research et "Development")
owner Contient le DN des objets qui sont responsable de cet objet
physicalDeliveryOfficeName Contient les noms qu’un service postal utilise pour identifier un bureau de poste (ex : Bremerhaven, Main" et "Bremerhaven, Bonnstrasse")
postalAddress Contient les adresses utilisées par un service postal pour effectuer des services pour l’objet (ex : "15 Main St.$Ottawa$Canada")
postalCode Contient les codes utilisés par le service postal pour identifier les zones de service postal ( ex : "22180")
postOfficeBox Contient les identifiant de boite postal (ex : "Box 45")
preferredDeliveryMethod Contient une indication de la méthode préférée pour envoyer un message à l’objet (ex : "mhs $ telephone")
registeredAddress Contient l’adresse postal pour la réception de télégrammes ou documents expédiés (ex : "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada")
roleOccupant Contient les DN des objets qui sont responsable d’un objet rôle
searchGuide Contient des jeux d’information à utiliser par des clients pour construire des filtres de recherche (ex : "person#sn$EQ")
seeAlso Contient les DN des objets liés au sujet de l’objet
serialNumber Contient les numéros de série des périphériques
sn surname dans X500. Nom de famille d’une personne
st stateOrProvinceName dans X500. nom des états ou provinces
street streetAddress dans X500. Adresses postales
telephoneNumber Numéros de téléphone qui respectent la recommandation ITU E.123 (ex : "+1 234 567 8901")
teletexTerminalIdentifier Le retrait de la recommandation F.200 a résulté du retrait de cet attribut
telexNumber Contient des jeux de numéro telex (ex : "12345$023$ABCDE")
title Titre d’une personne (ex : "Vice President", "Software Engineer", and "CEO")
uid Nom de connexion asocié avec l’objet
uniqueMember Contient les DN d’un objet qui sont dans une liste ou dans un groupe
userPassword Contient une chaîne utilisée pour l’authentification d’un objet
x121Address Adresse réseau tel que définis par la recommandation X.121 (ex : "36111222333444555")
x500UniqueIdentifier Chaîne binaire utilisé pour distinguer des objets quand un DN a été réutilisé

ObjectClass

applicationProcess Base d’une entrée qui représente une application s’exécutant sur une machine
country Base d’une entrée qui représente un pays
dcObject Permet à une entrée de contenir une composante de domaine
device Base d’une entrée qui représente une appliance, ordinateur ou élément réseau
groupOfNames Base d’une entrée qui représente un jeu d’objets nommés
groupOfUniqueNames Idem à groupOfNames excepté que les noms ne sont pas répétés ou réassigné dans un scope
locality Base d’une entrée qui représente une place dans le monde physique
organization Base d’une entrée qui représente un groupe de personne structuré
organizationalPerson Base d’une entrée qui représente une personne en relation à une organisation
organizationalRole Base d’une entrée qui représente un job, fonction ou position dans une organisation
organizationalUnit Base d’une entrée qui représente un pièce dans une organisation
person Base d’une entrée qui représente une personne
residentialPerson Base d’une entrée qui représente la résidence d’une personne dans la représentation de la personne
uidObject Permet à une entrée de contenir des information d’identification d’un utilisateur

Définition des attributs


attributetype ( 2.5.4.15 NAME ’businessCategory’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.6 NAME ’c’
    SUP name
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
    SINGLE-VALUE )
    
attributetype ( 2.5.4.3 NAME ’cn’
    SUP name )
    
attributetype ( 0.9.2342.19200300.100.1.25 NAME ’dc’
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 2.5.4.13 NAME ’description’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.27 NAME ’destinationIndicator’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
    
attributetype ( 2.5.4.49 NAME ’distinguishedName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributetype ( 2.5.4.46 NAME ’dnQualifier’
    EQUALITY caseIgnoreMatch
    ORDERING caseIgnoreOrderingMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
    
attributetype ( 2.5.4.47 NAME ’enhancedSearchGuide’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
    
attributetype ( 2.5.4.23 NAME ’facsimileTelephoneNumber’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
    
attributetype ( 2.5.4.44 NAME ’generationQualifier’
    SUP name )
    
attributetype ( 2.5.4.42 NAME ’givenName’
    SUP name )
    
attributetype ( 2.5.4.51 NAME ’houseIdentifier’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.43 NAME ’initials’
    SUP name )
    
attributetype ( 2.5.4.25 NAME ’internationalISDNNumber’
    EQUALITY numericStringMatch
    SUBSTR numericStringSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
    
attributetype ( 2.5.4.7 NAME ’l’
    SUP name )
    
attributetype ( 2.5.4.31 NAME ’member’
    SUP distinguishedName )
    
attributetype ( 2.5.4.41 NAME ’name’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.10 NAME ’o’
    SUP name )
    
attributetype ( 2.5.4.11 NAME ’ou’
    SUP name )
    
attributetype ( 2.5.4.32 NAME ’owner’
    SUP distinguishedName )
    
attributetype ( 2.5.4.19 NAME ’physicalDeliveryOfficeName’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.16 NAME ’postalAddress’
    EQUALITY caseIgnoreListMatch
    SUBSTR caseIgnoreListSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
    
attributetype ( 2.5.4.17 NAME ’postalCode’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.18 NAME ’postOfficeBox’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.28 NAME ’preferredDeliveryMethod’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
    SINGLE-VALUE )
    
attributetype ( 2.5.4.26 NAME ’registeredAddress’
    SUP postalAddress
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
    
attributetype ( 2.5.4.33 NAME ’roleOccupant’
    SUP distinguishedName )
    
attributetype ( 2.5.4.14 NAME ’searchGuide’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
    
attributetype ( 2.5.4.34 NAME ’seeAlso’
    SUP distinguishedName )
    
attributetype ( 2.5.4.5 NAME ’serialNumber’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
    
attributetype ( 2.5.4.4 NAME ’sn’
    SUP name )
    
attributetype ( 2.5.4.8 NAME ’st’
    SUP name )
    
attributetype ( 2.5.4.9 NAME ’street’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.20 NAME ’telephoneNumber’
    EQUALITY telephoneNumberMatch
    SUBSTR telephoneNumberSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
    
attributetype ( 2.5.4.22 NAME ’teletexTerminalIdentifier’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
    
attributetype ( 2.5.4.21 NAME ’telexNumber’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
    
attributetype ( 2.5.4.12 NAME ’title’
    SUP name )
    
attributetype ( 0.9.2342.19200300.100.1.1 NAME ’uid’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.50 NAME ’uniqueMember’
    EQUALITY uniqueMemberMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
    
attributetype ( 2.5.4.35 NAME ’userPassword’
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
    
attributetype ( 2.5.4.24 NAME ’x121Address’
    EQUALITY numericStringMatch
    SUBSTR numericStringSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
    
attributetype ( 2.5.4.45 NAME ’x500UniqueIdentifier’
    EQUALITY bitStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

Définition des classes d’objets

objectclass ( 2.5.6.11 NAME ’applicationProcess’
    SUP top
    STRUCTURAL
    MUST cn
    MAY ( seeAlso $ ou $ l $ description ) )
    
objectclass ( 2.5.6.2 NAME ’country’
    SUP top
    STRUCTURAL
    MUST c
    MAY ( searchGuide $ description ) )
    
objectclass ( 1.3.6.1.4.1.1466.344 NAME ’dcObject’
    SUP top
    AUXILIARY
    MUST dc )
    
objectclass ( 2.5.6.14 NAME ’device’
    SUP top
    STRUCTURAL
    MUST cn
    MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
    
objectclass ( 2.5.6.9 NAME ’groupOfNames’
    SUP top
    STRUCTURAL
    MUST ( member $ cn )
    MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
    
objectclass ( 2.5.6.17 NAME ’groupOfUniqueNames’
    SUP top
    STRUCTURAL
    MUST ( uniqueMember $ cn )
    MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
    
objectclass ( 2.5.6.3 NAME ’locality’
    SUP top
    STRUCTURAL
    MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
    
objectclass ( 2.5.6.4 NAME ’organization’
    SUP top
    STRUCTURAL
    MUST o
    MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $
    destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
    telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $
    postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )
    
objectclass ( 2.5.6.7 NAME ’organizationalPerson’
    SUP person
    STRUCTURAL
    MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $
    telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $
    facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )
    
objectclass ( 2.5.6.8 NAME ’organizationalRole’
    SUP top
    STRUCTURAL
    MUST cn
    MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $
    teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $
    seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $
    physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
    
objectclass ( 2.5.6.5 NAME ’organizationalUnit’
    SUP top
    STRUCTURAL
    MUST ou
    MAY ( businessCategory $ description $ destinationIndicator $ facsimileTelephoneNumber $ internationalISDNNumber $ l $
    physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ preferredDeliveryMethod $
    registeredAddress $ searchGuide $ seeAlso $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ userPassword $ x121Address ) )
    
objectclass ( 2.5.6.6 NAME ’person’
    SUP top
    STRUCTURAL
    MUST ( sn $
    cn )
    MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
    
objectclass ( 2.5.6.10 NAME ’residentialPerson’
    SUP person
    STRUCTURAL
    MUST l
    MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $
    telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $
    facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $
    physicalDeliveryOfficeName $ st $ l ) )
    
objectclass ( 1.3.6.1.1.3.1 NAME ’uidObject’
    SUP top
    AUXILIARY
    MUST uid )

^
02 novembre 2013

htmlpdflatexmanmd




rfc4521

rfc4521

Extentions LDAP

Mécanisme de découverte

   LDAP ne fournis aucun mécanisme pour qu'un serveur découvre les capacité des clients. L'attribut supportedControl du RootDSE est utilisé pour avertir des opérations étendues supportées. l'attribut supportedFeatures est utilisé pour avertir des fonctionnalités. D'autres attributs du RootDSE peut être utilisés pour avertir d'autres capacités.

   LDAP est conçus pour supporter unicode. les options de tag de langue (rfc 3866) fournissent un mécanisme pour tag les valeurs avec des informations de langue.

Extensions d'opération LDAP

   Les extensions devraient utiliser les contrôles pour définir des extensions qui complémentent des opérations existantes, sinon, il est préférable de définir des opérations étendues.

Contrôles

   Les contrôles sont recommandés pour étendre de opérations existantes. Une opération existante peut être une opération de base, une opération étendue, une modification de mot de passe ou une opération définie comme extension d'une opération de base ou étendue.

   Les extensions ne devraient pas retourner de réponse à moins que le serveur sait que le client peut utiliser ce contrôle. Une opération existante peut être étendue pour retourner des messages IntermediateResponse. Les contrôles ne devraient pas définir de sémantique additionnelles à la criticité des contrôles.

Étendre l'opération Bind avec des contrôles

   Les contrôles attachés aux messages de requête et de réponse d'une opération Bind ne sont pas protégés par une couche de sécurité établie par l'opération bind.

Étendre l'opération StartTLS avec des contrôles

   Les contrôles attachés aux messages de requête et de réponse d'une opération StartTLS ne sont pas protégés par la couche de sécurité.

Étendre l'opération de recherche avec des contrôles

   L'opération de recherche a 2 phases:

- trouver l'objet de base
- Rechercher les objets à ou sous l'objet de base.

   Les contrôles étendant la recherche devraient clairement statuer sur quelle(s) phase(s) le contrôle s'applique.

Étendre les opérations update avec des contrôles

   Les opération update ont des propriétés d'atomicité, consistance, isolation et durabilité (ACID)

atomicité: tous ou aucun des changements demandés ont été fait
consistance: L'état DIT résultant doit être conforme au schéma et d'autres contraintes
isolation: les états intermédiaires ne sont pas exposés
durabilité: l'état DIT résultant est préservé jusqu'à une mise à jours ultérieure.

   En définissant un contrôle qui demande des changements additionnels, ces changements ne devraient pas être traités comme partie d'une transaction séparée

Réponses intermédiaires

   Les extensions devraient utiliser les messages IntermediateResponse au lieu des messages ExtendedResponse pour retourner des résultats intermédiaires.

Notifications non-sollicitées

   Les notifications non-sollicitées permettent à un serveur de notifier le client d'évènements non associés avec l'opération courante. Ces extensions doivent être conçues de manière à ce qu'un serveur n'envoie ces notification que s'il sait que le client peut utiliser ces notifications.

Code de résultat

   Les extensions qui spécifient de nouvelles opérations ou améliorent des opérations existantes ont souvent besoin de nouveaux code de résultat. L'extension doit être conçue de manière à ce qu'un client ait une indication clair de la nature du résultat.

Types de message LDAP

   Les extensions peuvent spécifier de nouveaux types de messages LDAP en étendant le choix protocolOp de la séquence LDAPMessage, mais c'est généralement inapproprié et non-nécessaire. Cependant, dans certains cas, de nouveaux mécanismes d'extensions devraient être définis.

Méthodes d'authentification

   Bind supporte 2 méthodes d'authentification, simple et SASL. Il est recommandé que les nouveau processus d'authentification soient définis comme mécanisme SASL.

Extension de schéma

   Les extensions définissant des éléments de schéma LDAP doivent fournir la définition de schéma conformément avec la syntaxe définie.

Syntaxes LDAP

   Chaque syntaxe LDAP est définie en terme d'ASN.1. Chaque extension détaillant une syntaxe LDAP doit spécifier les données ASN.1 associées avec la syntaxe.

Matching Rules

   3 types basique de règle de correspondance peuvent être associés avec un type d'attribut. En plus, LDAP fournis un mécanisme de règle extensible.

Autres mécanismes étendu

   Chaque option est identifiée par une chaîne de lettres, nombre et tirets. Cette chaîne devrait être courte.

   Les extensions interagissant avec des identité d'authorisation devraient supporter le format authzId. ce format est extensible.

   Les extensions d'URL LDAP sont identifiées par une chaîne courte, un descripteur, la chaîne devrait être courte.
^
03 novembre 2013

htmlpdflatexmanmd




rfc4523

rfc4523

Définition de schéma pour les certificats x.509

Syntaxes

certificate
( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
CertificateList
( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
CertificatePair
( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
SupportedAlgorithm
( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'X.509 Supported Algorithm' )
CertificateExactAssertion
( 1.3.6.1.1.15.1 DESC 'X.509 Certificate Exact Assertion' )
CertificateAssertion
( 1.3.6.1.1.15.2 DESC 'X.509 Certificate Assertion' )
CertificatePairExactAssertion
( 1.3.6.1.1.15.3 DESC 'X.509 Certificate Pair Exact Assertion' )
CertificatePairAssertion
( 1.3.6.1.1.15.4 DESC 'X.509 Certificate Pair Assertion' )
CertificateListExactAssertion
( 1.3.6.1.1.15.5 DESC 'X.509 Certificate List Exact Assertion' )
CertificateListAssertion
( 1.3.6.1.1.15.6 DESC 'X.509 Certificate List Assertion' )
AlgorithmIdentifier
( 1.3.6.1.1.15.7 DESC 'X.509 Algorithm Identifier' )

Matching Rules

certificateExactMatch
( 2.5.13.34 NAME 'certificateExactMatch' DESC 'X.509 Certificate Exact Match' SYNTAX 1.3.6.1.1.15.1 )
certificateMatch
( 2.5.13.35 NAME 'certificateMatch' DESC 'X.509 Certificate Match' SYNTAX 1.3.6.1.1.15.2 )
certificatePairExactMatch
( 2.5.13.36 NAME 'certificatePairExactMatch' DESC 'X.509 Certificate Pair Exact Match' SYNTAX 1.3.6.1.1.15.3 )
certificatePairMatch
( 2.5.13.37 NAME 'certificatePairMatch' DESC 'X.509 Certificate Pair Match' SYNTAX 1.3.6.1.1.15.4 )
certificateListExactMatch
( 2.5.13.38 NAME 'certificateListExactMatch' DESC 'X.509 Certificate List Exact Match' SYNTAX 1.3.6.1.1.15.5 )
certificateListMatch
( 2.5.13.39 NAME 'certificateListMatch' DESC 'X.509 Certificate List Match' SYNTAX 1.3.6.1.1.15.6 )
algorithmIdentifierMatch
( 2.5.13.40 NAME 'algorithmIdentifier' DESC 'X.509 Algorithm Identifier Match' SYNTAX 1.3.6.1.1.15.7 )

Attributes

userCertificate
( 2.5.4.36 NAME 'userCertificate' DESC 'X.509 user certificate' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
cACertificate
( 2.5.4.37 NAME 'cACertificate' DESC 'X.509 CA certificate' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
crossCertificatePair
( 2.5.4.40 NAME 'crossCertificatePair' DESC 'X.509 cross certificate pair' EQUALITY certificatePairExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
certificateRevocationList
( 2.5.4.39 NAME 'certificateRevocationList' DESC 'X.509 certificate revocation list' EQUALITY certificateListExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
authorityRevocationList
( 2.5.4.38 NAME 'authorityRevocationList' DESC 'X.509 authority revocation list' EQUALITY certificateListExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
deltaRevocationList
( 2.5.4.53 NAME 'deltaRevocationList' DESC 'X.509 delta revocation list' EQUALITY certificateListExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
supportedAlgorithms
( 2.5.4.52 NAME 'supportedAlgorithms' DESC 'X.509 supported algorithms' EQUALITY algorithmIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )

ObjectClass

pkiUser
( 2.5.6.21 NAME 'pkiUser' DESC 'X.509 PKI User' SUP top AUXILIARY MAY userCertificate )
pkiCA
( 2.5.6.22 NAME 'pkiCA' DESC 'X.509 PKI Certificate Authority' SUP top AUXILIARY MAY ( cACertificate $ certificateRevocationList $ authorityRevocationList $ crossCertificatePair ) )
cRLDistributionPoint
( 2.5.6.19 NAME 'cRLDistributionPoint' DESC 'X.509 CRL distribution point' SUP top STRUCTURAL MUST cn MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) )
deltaCRL
( 2.5.6.23 NAME 'deltaCRL' DESC 'X.509 delta CRL' SUP top AUXILIARY MAY deltaRevocationList )
strongAuthenticationUser (déprécié en faveur de pkiUser)
( 2.5.6.15 NAME 'strongAuthenticationUser' DESC 'X.521 strong authentication user' SUP top AUXILIARY MUST userCertificate )
userSecurityInformation
( 2.5.6.18 NAME 'userSecurityInformation' DESC 'X.521 user security information' SUP top AUXILIARY MAY ( supportedAlgorithms ) )
certificationAuthority (déprécié en faveur de pkiCA)
( 2.5.6.16 NAME 'certificationAuthority' DESC 'X.509 certificate authority' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair )
certificationAuthority-V2 (déprécié en faveur de pkiCA)
( 2.5.6.16.2 NAME 'certificationAuthority-V2' DESC 'X.509 certificate authority, version 2' SUP certificationAuthority AUXILIARY MAY deltaRevocationList )
^
07 juillet 2013

htmlpdflatexmanmd




rfc4524

rfc4524

Schéma pour les projets pilote X.500 Internet et COSINE

Attributs

associatedDomain Spécifie les noms d’hôte DNS associé à un objet
associatedName Spécifie les noms des entrées dans le DIT organisationnel associé avec un domaine DNS
buildingName Spécifie les noms des immeubles où un organisation ou unité d’organisation est basée
co Friendly Country Name, Spécifie les noms des pays (ex : "Germany", "Federal Republic of Germany")
documentAuthor Spécifie les DN des auteurs d’un document
documentIdentifier Spécifie les identifiants unique pour un document.
documentLocation Spécifie les emplacements du document original
documentPublisher Personnes et/ou organisations qui ont publiés le document
documentTitle Spécifie les titres d’un document
documentVersion Spécifie la version d’un document
drink (favoriteDrink) Spécifie la boisson favorite d’un objet
homePhone (HomeTelephoneNumber) Numéro de téléphone d’une personne
homePostalAddress Spécifie l’adresse postale du domicile de l’objet
host Spécifie le nom d’hôte des ordinateurs
info Spécifie des informations spécifiques à l’objet
mail (rfc822mailbox) Contient les addresse mail Internet
manager Spécifie les DN des responsables d’un objet
mobile (mobileTelephoneNumber) spécifie les numéros de téléphone portable
organizationalStatus Spécifie des catégories par lesquelles une personne est référée dans l’entreprise
pager (pagerTelephoneNumber)
personalTitle Titres personnels pour une personne
roomNumber Numéro de salle
secretary Spécifie les secrétaire et/ou assistantes administratives de l’objet
uniqueIdentifier Identifiant unique pour un objet représenté dans l’annuaire
userClass Spécifie les catégories de machine ou application utilisateur

Classes d'objets

account Définis des entrées représentant des comptes machine. l’uid devrait être utilisé pour nommer l’entrée.
document Définis des entrées qui représente des documents
documentSeries Définis une entrée qui représente une série de documents
domain Définis des entrées qui représente des domaines DNS.
domainRelatedObject Définis des entrées qui représentent des domaines DNS qui sont équivalent à un domaine X.500
friendlyCountry Définis des entrées représentant des pays dans le DIT
rFC822LocalPart Définis des entrées qui représentent lapartie local des adresses email Internet
room Définis des entrées représentant des salles
simpleSecurityObject Utilisé pour avoir userPassword

Définition des attributs


attributeType ( 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 )
    
attributeType ( 0.9.2342.19200300.100.1.38 NAME ’associatedName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributeType ( 0.9.2342.19200300.100.1.48 NAME ’buildingName’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 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 )
    
attributeType ( 0.9.2342.19200300.100.1.14 NAME ’documentAuthor’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributeType ( 0.9.2342.19200300.100.1.11 NAME ’documentIdentifier’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.15 NAME ’documentLocation’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 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 )
    
attributeType ( 0.9.2342.19200300.100.1.12 NAME ’documentTitle’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.13 NAME ’documentVersion’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.5 NAME ’drink’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 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 )
    
attributeType ( 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 )
    
attributeType ( 0.9.2342.19200300.100.1.9 NAME ’host’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.4 NAME ’info’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.152048 )
    
attributeType ( 0.9.2342.19200300.100.1.3 NAME ’mail’
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26256 )
    
attributeType ( 0.9.2342.19200300.100.1.10 NAME ’manager’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributeType ( 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 )
    
attributeType ( 0.9.2342.19200300.100.1.45 NAME ’organizationalStatus’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 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 )
    
attributeType ( 0.9.2342.19200300.100.1.40 NAME ’personalTitle’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.6 NAME ’roomNumber’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.21 NAME ’secretary’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributeType ( 0.9.2342.19200300.100.1.44 NAME ’uniqueIdentifier’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.8 NAME ’userClass’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )

Définition des classes d'objets


objectclass ( 0.9.2342.19200300.100.4.5 NAME ’account’
    SUP top STRUCTURAL
    MUST uid
    MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
    
objectclass ( 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 ) )
    
objectclass ( 0.9.2342.19200300.100.4.9 NAME ’documentSeries’
    SUP top STRUCTURAL
    MUST cn
    MAY ( description $ l $ o $ ou $ seeAlso $ telephonenumber ) )
    
objectclass ( 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 ) )
    
objectclass ( 0.9.2342.19200300.100.4.17 NAME ’domainRelatedObject’
    SUP top AUXILIARY
    MUST associatedDomain )
    
objectclass ( 0.9.2342.19200300.100.4.18 NAME ’friendlyCountry’
    SUP country STRUCTURAL
    MUST co )
    
objectclass ( 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 ) )
    
objectclass ( 0.9.2342.19200300.100.4.7 NAME ’room’
    SUP top STRUCTURAL
    MUST cn
    MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
    
objectclass ( 0.9.2342.19200300.100.4.19 NAME ’simpleSecurityObject’
    SUP top AUXILIARY
    MUST userPassword )

^
26 septembre 2013

htmlpdflatexmanmd




rfc4525

rfc4525

Extension Modify-Increment

   Définit une extension de l’opération modify pour supporter les capacités d’incrémentation. Cette fonctionnalité est prévue pour être utilisée avec les extensions de contrôle pre-read et post-read (rfc 4527), et peut aussi être utilisée avec l’extension de contrôle d’assertion (rfc4528).

   Les implémentations de cette extension devraient supporter les opérations d’énumération de valeur incrémentale de l’opération ModifyRequest. La valeur de l’opération increment spécifie que des modifications de valeurs d’incrément sont demandés. Toutes les valeurs existantes de l’attribut modification doivent être incrémentés par la valeur listée. L’attribut modification doit être approprié pour la requête, et la modification doit fournir une seul valeur. Si l’attribut n’est pas approprié, une erreur constrainViolation ou autre est retournée. Si plusieurs valeurs sont fournies, protocolError est retourné.

   Les serveurs supportant cette fonctionnalité devraient publier l’OID 1.3.6.1.1.14 dans supportedFeatures dans le rootDSE.

Support LDIF

Pour représenter les requêtes Modify-Increment dans le format LDIF, la production ABNF est étendue comme suit:
mod-spec =/ "increment :" FILL AttributeDescription SEP attrval-spec "-"
SEP

Exemples

Par exemple:
# Increment uidNumber
dn : cn=max-assigned uidNumber,dc=example,dc=com
changetype : modify
increment : uidNumber
uidNumber : 1
^
28 septembre 2013

htmlpdflatexmanmd




rfc4526

rfc4526

Filtres True et False Absolue

   Définis le support des filtres vrai et faux basé sur les capacités similaires aux annuaires X500. Ce document étend également la représentation des chaîne des filtres de recherche LDAP pour supporter ces filtres. Dans les annuaires DAP, un filtre 'and' sans éléments évalue toujours True, et un 'or' sans éléments évalue toujours False. Ces filtres sont communément utilisés pour requêter les DSE qui n'ont pas nécessairement d'attributs objectClass.

   Les implémentations de cette extensions devraient permettre les choix 'and' et 'or' sans éléments de filtre.

- un filtre 'and' constitué d'un jeu vide de filtres devrait s'évaluer à TRUE. le filtre s'écrit "(&)"
- un filtre 'or' constitué d'un jeu vide de filtres devrait s'évaluer à FALSE. Le filtre s'écrit "(|)"

   Les serveurs supportant cette fonctionnalité devraient publier l'OID 1.3.6.1.4.1.4203.1.5.3 dans supportedFeatures.

^
28 septembre 2013

htmlpdflatexmanmd




rfc4527

rfc4527

Contrôles de lecture d'entrée

   Permet à un client de lire l'entrée cible d'une opération de mise à jours. Le client peut demander de lire l'entrée avant et/ou après que les modifications aient été appliquées. Ces lectures sont des parties atomiques de l'opération de mise à jours.

   L'extension utilise les contrôles attachés aux requêtes de mise à jours pour demander des copies en retour. Un contrôle de requête, appelé Pre-Read, indique qu'une copie de l'entrée avant l'application de la modification doit être retournée. Un autre contrôle, appelé Post-Read, indique qu'une copie de l'entrée après l'application de la modification doit être retournée. Chaque contrôle a un contrôle de réponse utilisé pour retourner l'entrée.

Contrôle pre-Read

   les contrôle de requête et de réponse Pre-Read sont identifiés par l'OID: 1.3.6.1.1.13.1. Les serveurs implémentant ce contrôle devrait publier cet OID dans supportedControl. Un contrôle de requête Pre-Read a controlType à 1.3.6.1.1.13.1 et controlValue est un AttributeSelection encodé BER qui indique quels attributs sont retournées dans la copie.

Contrôle pre-Read

   les contrôle de requête et de réponse Post-Read sont identifiés par l'OID: 1.3.6.1.1.13.2. Les serveurs implémentant ce contrôle devrait publier cet OID dans supportedControl. Un contrôle de requête Post-Read a controlType à 1.3.6.1.1.13.2 et controlValue est un AttributeSelection encodé BER qui indique quels attributs sont retournées dans la copie.
^
28 septembre 2013

htmlpdflatexmanmd




rfc4528

rfc4528

Contrôle d'assertion

   Permet à un client de spécifier qu'une opération devrait seulement être traitée si une assertion appliquée à l'entrée cible est vraie. Cela permet de construire des opérations conditionnelles du type "test and set" ou "test and clear". Cela permet de spécifier une condition qui doit être vrai pour que l'opération soit effectuée.

   Pour les opérations Add, Compare et ModifyDN, la cible est indiquée par le champ entry dans la requête. Pour les opérations Modify, la cible est indiquée par le champ Object. Pour les opérations Delete, la cible est indiquée par le type DelRequest. Pour les opérations Compare et toutes les opérations update, l'évaluation de l'assertion doit être effectuée comme partie intégrale de l'opération. Pour les opérations de recherche, la cible est indiquée par le champ baseObject, et l'évaluation est faite après "finding", mais avant "searching".

   Les serveurs implémentant cette fonctionnalité devraient publier l'OID 1.3.6.1.1.12 dans supportedControl.

^
28 septembre 2013

htmlpdflatexmanmd




rfc4529

rfc4529

Requêter les attributs par classe d'objet

   LDAP permet aux clients de demander tous les attributs utilisateurs, tous les attributs opérationnels, et/ou tous les attributs sélectionné par leur description.

   2 descripteurs sont définis pour demander tous les attributs utilisateur "*", et tous les attributs opérationnels "+". Il n'y a cependant aucun mécanisme convenable pour demander un jeu d'attributs prédéfinis tel que le jeu d'attributs utilisé pour représenter une classe d'objet particulière. Le caractère '@' est utilisé pour distinguer un identifiant de classe d'objet des descriptions d'attributs.

Retour de tous les attributs d'une classe d'objet

Cette extension étend la production ‹attributeSelector›:
attributeSelector =/ objectclassdescription
objectclassdescription = ATSIGN oid options
ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)

   Les serveurs supportant cette fonctionnalité devraient publier l'OID 1.3.6.1.4.1.4203.1.5.2 dans supportedFeatures.
^
28 septembre 2013

htmlpdflatexmanmd




rfc4532

rfc4532

Opération Who Am I ?

   Remplace la RFC 3829. Définit un mécanisme pour les clients LDAP pour obtenir l'identité d'autorisation que le serveur a associé avec l'utilisateur. Who Am I ? peut être augmentée avec un Proxy Autorization Control pour déterminer l'identité d'autorisation que le serveur associe avec l'identité asséré dans le contrôle d'autorisation proxifié. Who Am I ? peut également être utilisé avant une opération Bind.

   Les serveurs associent souvent plusieurs identités d'autorisation avec le client, et chaque identité d'autorisation peut être représenté par plusieurs authzId. Cette opération retourne une authzId que le serveur considère comme principal. Dans cette spécification, l'identité d'autorisation et le authzId sont généralement l'identité d'autorisation principal et l'authzId principal, respectivement.

   L'opération étendue Who I Am ? est définie par l'OID 1.3.6.1.4.1.4203.1.11.3. Les serveur implémentant cette fonctionalité devrait le publier dans supportedExtension.

Request whoami

   La requête whoami est une extendedRequest avec requestName contenant 1.3.6.1.4.1.4203.1.11.3 et requestValue est absent.

Response whoami

   La réponse whoami est une ExtendedResponseresponseName est absent et le champ response, si présent, est un authzId.

Contrôle d'autorisation proxifié

   Ce contrôle est utilisé par les clients pour demander que l'opération soit attaché pour opérer sous l'autorisation d'une identité d'emprunt. Le client fournis l'identité d'emprunt dans le contrôle d'autorisation proxifié. Si le client est autorisé à emprunter l'identité demandée, le serveur exécute l'opération comme si l'identité demandée avait fournis l'opération.
^
05 octobre 2014

htmlpdflatexmanmd




rfc4533

rfc4533

LDAP Content Synchronization Operation

   Ce document définit l'opération lDAP Content Synchronization, ou Sync Operation, qui permet à un client de maintenir une copie synchronisée d'un fragment d'un DIT. Sync Operation est définis comme un jeu de contrôles et d'autres élément du protocole qui étendent l'opération de recherche.

   Pendant des années, plusieurs approches de synchronisation de contenu ont été suggérés pour utiliser les services d'annuaire LDAP. Ces approches sont inadéquates pour un ou plusieurs des raisons suivantes:

- Impossibilité de s'assurer d'un niveau de convergence raisonnable
- Impossibilité de détecter que la convergence ne peut pas être achevée (sans rechargement)
- Nécessite que le serveur maintienne un historique des changements passés dans le DIT et/ou les méta-informations
- Nécessite que le serveur maintienne un état de synchronisation sur un base par client; et/ou
- sont trop bavard

   Sync Operation fournis une convergence éventuelle du contenu synchronisé quand cela est possible et, sinon, une notification qu'un rechargement complet est nécessaire. Sync Operation ne nécessite par d'agrément pré-arrangé de synchronisation.

   Sync Operation ne nécessite pas que les serveurs maintiennent ou utilisent un historique des changements passés dans le DIT ou de méta-informations. Cependant, les serveurs peuvent maintenir et utiliser des historiques pour réduire le nombre de messages générés et pour réduire leur taille. Comme il n'est pas toujours faisable de maitenir et d'utiliser des historiques, l'opération peut être implémentée en utilisant un approche purement basé sur l'état. Sync Operation permet d'utiliser soit l'approche state-based, soit l'approche history-based pour balancer l'a taille de l'historique et la quantité du trafic. Sync Operation permet également de combiner l'utilisation de ces 2 approches.

   Sync Operation ne nécessite par que les serveur maintiennent d'état de synchronisation par client, cependant, les serveurs peuvent maitenir et utiliser un tel état d'information pour réduire le nombre de messages générés et la taille de tels messages.

   Un mécanisme de synchronisation peut être considéré trop bavard quand le trafic de synchronisation n'est pas raisonnable. Le trafic de Sync Operation est limité par la taille des mises à jours ou des nouvelles entrées et le nombre d'entrées inchangées dans le contenu. L'opération est conçue pour éviter des échanges complet de contenu, même quand les informations d'historique disponible au serveur est insuffisant pour déterminer l'état du client. L'opération est également conçue pour éviter la transmission d'information d'historique hors contenus, vu que sa taille n'est pas limitée par le contenu et il n'est pas toujours faisable de transmettre de telles informations d'historique dû à des raisons de sécurité.

Utilisation

   Sync Operation est conçu pour être utilisé dans les applications qui nécessitent une synchronisation de contenu éventuellement convergent. Une fois l'étape de chaque synchronisation de l'opération terminée, toutes les informations pour construire une copie client synchronisée a été fournie au client ou le client a été notifié qu'un rechargement complet est nécessaire. Excepté pour les incohérence transitoires dus au traitement simultané du serveur, la copie client est un reflet précis du contenu maintenu par le serveur. Les inconsistances transitoires seront résolues par des opérations de synchronisation ultérieurs.

  Des utilisations possibles incluent:

- Les applications de services page blanche
- Les moteurs de méta-informations
- Les services de proxy
- La réplication maître-esclave entre des serveurs d'annuaire hétérogènes.

   Ce protocole n'est pas conçus pour être utilisé avec des applications nécessitant une consistance de données transactionnelles. Vu que ce protocole transfère toutes les valeurs visibles des entrées appartenant au contenu courant au lieu d'un changement delta, ce protocole n'est pas approprié pour des applications à bande passante limitée ou des déploiements.

Vue d'ensemble

   Cette section fournie une vue d'ensemble sur la manière dont Sync Operation peut être utilisé pour maintenir une copie client synchronisée d'un fragment du DIT.

Polling for Changes (refreshOnly)

   Pour obtenir sa copie cliente initiale, le client envoie un requête Sync: une requête Search avec le contrôle Sync Request et mode à refreshOnly. Le serveur retourne le contenu correspondant au critère de recherche, Additionnellement, avec chaque entrée retournée, le serveur fournis un contrôle d'état de synchronisation indiquant l'état. Ce contrôle contient l'UUID de l'entrée. Le contenu initial est suivi par un SearchResultDone avec un contrôle Sync Done. Le Sync Done Contrôle fournis un syncCookie, qui représente un état de session.

   Pour interroger les mises à jours pour la copie client, le client renouvelle le Sync Operation avec le syncCookie précédemment retourné. Le serveur détermine quel contenu doit être à retourner comme si l'opération était une opération de recherche normale. Cependant, en utilisant le syncCookie, le serveur envoie les copies des entrées qui ont changé avec un Sync State Control indiquant l'état add. Pour chaque entrée changée, tous les attribut ( modifiés ou non ) appartenant au contenu sont envoyés.

   Le serveur peut effectuer une des 2 phases de synchronisations, ou les 2, qui sont distinguées par la manière de synchroniser les entrées supprimées du contenu: Les phases présent et delete. Quand le serveur utilise une seule phase pour l'étape de rafraîchissement, chaque phase est marquée comme terminée par un SearchResultDone avec un Sync Done Control. Une phase present est identifiée par une valeur refreshDeletes à FALSE dans le contrôle Sync Done. Une phase delete est identifiée par une valeur refreshDeletes à TRUE. La phase present peut être suivie par une phase delete. Les 2 phases sont délimitées par un message refreshPresent Sync Info avec la valeur refreshDone à FALSE. Dans le cas où les 2 phases sont utilisée, la phase present est utilisée pour apporte la copie client à jours après laquelle la phase delete peut commencer.

   Dans la phase present, le serveur envoie une entrée vide (ex: pas d'attributs) avec un Sync State Control indiquant l'état présent pour chaque entrée inchangée.

   La phase delete peut être utilisée quand le serveur peut déterminer avec certitude quelles entrées dans la précédente copie cliente ne sont plus présent dans le contenu et le nombre de telles entrées est inférieur ou égal au nombre d'entrées inchangées. Dans le mode delete, le serveur envoie une entrée vide avec un Sync State Control indiquant l'état delete pour chaque entrée qui n'est plus dans le contenu, au lieu de retourner une entrée vide avec l'état present pour chaque entrée présente.

   Le serveur peut envoyer des messages syncIdSet Sync Info Messages contenant le jeu d'UUID des entrées présentes non changées et les entrées supprimées, au lieu d'envoyer plusieurs messages individuels. Il refreshDeletes et syncIdSet sont FALSE, les UUID des entrées présente inchangées sont contenus dans le jeu syncUUID; si refreshDeletes de syncIdSet est à TRUE, l'UUID des entrées supprimées dans le contenu sont dans le jeu syncUUID. Un cookie optionnel peut être inclus dans le syncIdSet pour représenter l'état du contenu après avoir synchronisé la présence ou l'absence des entrées contenus dans le jeu syncUUID.

   La copie synchronisée du fragment du DIT est construit par le client.

   Si refreshDeletes de syncDoneValue est FALSE, la nouvelle copie inclue toutes les entrées changées retournées par le Sync Operation ré-émis, aussi bien que toutes les entrées non changées identifiée comme étant présentes par le Sync Operation ré-émis, mais dont le contenu est fournis par le Sync Operation précédent. Les entrées inchangées non identifiées qui sont présentées sont supprimées du contenu client. Ils ont été soit supprimés, déplacés, ou sortis du scope.

   Si refreshDeletes de syncDoneValue est TRUE, la nouvelle copie inclus toutes les entrées changées retournées par le Sync Operation ré-émis, aussi bien que toutes les autres entrées de la copie précédente excepté pour celles qui ont été identifiées comme ayant été supprimés du contenu.

   Le client peut, plus tard, re-demander les changements pour cette copie cliente synchronisée.

Listening for Changes (refreshAndPersist)

   Le Polling for changes peut être coûteux en terme de serveur, client et ressources réseaux. Le mode refreshAndPersist permet des mises à jours active des entrées changées dans le contenu.

   En sélectionnant le mode RefreshAndPersist, le client demande que le serveur envoie les mises à jours des entrées qui ont été changées après que le refresh initial aie été déterminé. Au lieu d'un SearchResultDone comme dans le polling, le serveur envoie un Sync Info Message au client indiquant que l'étape refresh est complet et qu'il peut ainsi entrer en mode persist. Une fois reçu ce Sync Info Message, le client va construire une copie synchronisée comme décris précédemment.

   Le serveur peut ainsi envoyer des notifications de changement en résultat de la requête de recherche Sync originale, qui maintenant reste persistante dans le serveur. Pour les entrées à ajouter au contenu retourné, le serveur envoie un SearchResultEntry ( avec les attributs ) avec un contrôle Sync State indiquant l'état add. Pour les entrées à supprimer du contenu, le serveur envoie un SearchResultEntry ne contenant aucun attribut et un contrôle Sync State indiquant l'état delete. Pour les entrées à modifier dans le contenu retourné, le serveur envoie un SearchResultEntry ( avec les attributs ) avec un contrôle Sync State indiquant l'état modify. Une fois la modification d'une entrée, tous les attributs (modifiés et non modifiés) appartenant au contenu sont envoyés.

   Noter que renommer une entrée du DIT peut causer en état add où l'entrée est renommée dans le contenu, un état delete où l'entrée est sortie du contenu, et un état modify où l'entrée reste dans le contenu. Noter également qu'une modification d'une entrée du DIT peut causer un état add, delete ou modify dans le contenu.

   Une fois une notification de changement reçue, le client met à jours sa copie du contenu.

   Si le serveur désire mettre à jours de syncCookie durant l'étape persist, il peut inclure le syncCookie et un Sync State Control ou un Sync Info Message retourné.

   L'opération persiste jusqu'à annulation par le client ou terminées par le serveur. Un contrôle Sync Done devrait être attaché au message SearchResultDone pour fournir un nouveau syncCookie.

Élements de Sync Operation

   Sync Operation est définis comme extension de l'opération ldap search où le DUA envoie un message SearchRequest avec un contrôle Sync Request et le DSA répond avec 0 ou plusieurs message SearchResultEntry, chacun avec un contrôle Sync State; 0 ou plusieurs messages intermédiaires Sync Info, et un message SearchResultDone avec un contrôle Sync Done.

   Pour permettre aux clients de découvrir le support pour cette opération, les serveurs implémentant cette opération devaient publier 1.3.6.1.4.1.4203.1.9.1.1 comme valeur dans supportedControl du rootDSE.

SyncUUID

Le type de données syncUUID est un OCTET STRING maintenant un identifiant unique 16-octets
syncUUID ::= OCTET STRING (SIZE(16))

syncCookie

   Le syncCookie est un outil de notation pour indiquer que, bien que le type syncCookie est encodé en OCTET STRING, sa valeur est une valeur opaque contenant des informations sur la session de synchronisation est son état. Généralement, les informations de session incluent un hash des paramètres de l'opération que le serveur impose de ne pas changer et les informations de synchronisation incluent un numéro de séquence d'envoie (log), un numéro de séquence de changement, ou un timestamp. Pour simplifier les descriptions, le term "aucun cookie" réfère soit à un cookie null, soit à un cookie avec un état de synchronisation pré-initialisé


syncCookie ::= OCTET STRING

Sync Request Control

Le contrôle Sync Request est un contrôle ldap où controlType est 1.3.6.1.4.1.4203.1.9.1.1 et controlValue, un OCTET STRING, contient un BER de syncRequestValue:
syncRequestValue ::= SEQUENCE {
    mode ENUMERATED {
        -- 0 unused
        refreshOnly (1),
        -- 2 reserved
        refreshAndPersist (3)
    },
    cookie syncCookie OPTIONAL,
    reloadHint BOOLEAN DEFAULT FALSE
}

Sync State Control

Le contrôle Sync State est un contrôle ldap où controlType est 1.3.6.1.4.1.4203.1.9.1.2 et controlValue, un OCTET STRING, contient un BER de syncStateValue:
syncStateValue ::= SEQUENCE {
    state ENUMERATED {
        present (0),
        add (1),
        modify (2),
        delete (3)
    },
    entryUUID syncUUID,
    cookie syncCookie OPTIONAL
}

   Le contrôle Sync State est seulement applicable aux messages SearchResultEntry et SearchResultReference.

Sync Done Control

Le contrôle Sync Done est un contrôle ldap où controlType est 1.3.6.1.4.1.4203.1.9.1.3 et controlValue, un OCTET STRING, contient un BER de syncDoneValue:
syncDoneValue ::= SEQUENCE {
    cookie syncCookie OPTIONAL,
    refreshDeletes BOOLEAN DEFAULT FALSE
}

   Le contrôle Sync Done est seulement applicable au message SearchResultDone.

Sync Info Message

Le message Sync Info est un message de réponse intermédiaire où responseName est 1.3.6.1.4.1.4203.1.9.1.4 et responseValue contient un BER de syncInfoValue:
syncInfoValue ::= CHOICE {
    newcookie [0] syncCookie,
    refreshDelete [1] SEQUENCE {
        cookie syncCookie OPTIONAL,
        refreshDone BOOLEAN DEFAULT TRUE
    },
    refreshPresent [2] SEQUENCE {
        cookie syncCookie OPTIONAL,
        refreshDone BOOLEAN DEFAULT TRUE
    },
    syncIdSet [3] SEQUENCE {
        cookie syncCookie OPTIONAL,
        refreshDeletes BOOLEAN DEFAULT FALSE,
        syncUUIDs SET OF syncUUID
    }
}

Sync Result Codes

Le resultCode ldap suivant est définis:
e-syncRefreshRequired (4096)

Content Synchronization

   Sync Operation est invoqué quand le client envoie un message SearchRequest avec un contrôle Sync Request.

   L'absence d'un cookie ou d'un état de synchronisation dans un cookie indique une requête pour un contenu initial, alors que la présence d'un cookie représentant un état d'une copie client indique un requête pour une mise à jours du contenu.

   Le mode est soit refreshOnly soit refreshAndPersist. refreshOnly consiste seulement d'une étape refresh, alors que refreshAndPersist consiste d'une étape refresh suivi d'une étape persist.

Synchronization Session

   Une séquence de Sync Operations où le dernier cookie retourné par le serveur pour une opération est fournie par le client dans la prochaine opération est dite appartenant à la même session de synchronisation.

   Le client doit spécifier les même paramètre de contrôle de contenu dans chaque Search Request de la session. Le client devrait également fournir chaque demande Sync d'une session sous la même association authentification et autorisation avec des des protections et intégrité équivalent. Si le serveur ne reconnaît pas le cookie ou si la requête est faite sous des associations différentes ou à des protections non-équivalentes, le serveur devrait retourner le contenu initial comme si aucun cookie n'avait été fournis ou retourner un contenu vide avec le code de résultat e-syncRefreshRequired. La décision entrée le retour du contenu initial et le retour du contenu vide avec le code de résultat e-syncRefreshRequired peut être basé sur le reloadHint dans le contrôle de requête Sync du client. Si le serveur reconnait le cookie comme représentant un état de synchronisation initial ou vide de la copie cliente, le serveur devrait retourner le contenu initial.

   Une session de synchronisation peut s'étendre sur plusieurs sessions entre le client et le serveur. Le client devrait fournir chaque demande Sync d'une session du même serveur.

Détermination du contenu

   Le contenu à fournir est déterminé par les paramètre de la requête search, comme décrit dans la rfc4511, et possiblement d'autres contrôles. Les même paramètres de contenu devraient être utilisés dans chaque requête Sync d'une session. Si un contenu différent est demandé et que le serveur n'est pas en mesure de traiter la requête, le serveur devrait retourner le contenu initial comme si aucun cookie n'avait été retourné ou retourner un contenu vide avec le code e-syncRefreshRequired. La décision entrée les 2 peut être basé sur reloadHint du contrôle Sync Request du client.

   Le contenu peut ne pas nécessairement inclure toutes les entrées ou références qui seraient retournées par une opération de recherche normale, ni, pour les entrées inclues, tous les attributs retournés par une recherche normale. Quand le serveur ne peut pas fournir de synchronisation pour un attribut pour un jeu d'entrées, le serveur doit traiter tous les composants de filtre qui matchent ces attributs comme indéfinis et ne doit pas retourner ces attributs dans les réponses SearchResultEntry.

   Les serveurs devraient supporter la synchronisation pour tous les attributs utilisateurs non-collectifs pour toutes les entrées. Le serveur peut également retourner des références de continuation aux autres serveurs et à lui-même. Ce dernier est permis vu que le serveur peut partitionner les entrées qu'il maintient dans des contextes de synchronisation séparés. Le client peut poursuivre toutes ou certaines continuations, chacune comme une session de synchronisation de contenu séparés.

Mode refreshOnly

   Une requête Sync avec le mode refreshOnly et sans cookie est un sondage pour un contenu initial. Une requête Sync avec le mode refreshOnly et avec un cookie représentant un état de synchronisation est un sondage pour une mise à jours de contenus.

Initial Content Poll

   Une fois reçu la requête, le serveur fournis le contenu initial en utilisant un jeu de 0 ou plusieurs messages SearchResultEntry et SearchResultReference suivs par un message SearchResultDone.

   Chaque message SearchResultEntry devrait inclure un contrôle Sync State avec l'état add, un entryUUID contenant l'UUID de l'entrée, et aucun cookie. Chaque message SearchResultReference devrait inclure un contrôle Sync State avec l'état add, un entryUUID contenant l'UUID associé avec là référence ( normalement l'UUID de l'objet référant nommé associé ), et aucun cookie. Le message searchResultDone devrait inclure un contrôle Sync Done avec refreshDeletes à FALSE.

   Une valeur resultCode à success indique que l'opération a été complétée avec succès. Sinon, le resultCode indique la nature de l'échec. Le serveur peut retourner le resultCode e-syncRefreshRequired dans le sondage de contenu initial s'il est sûre de le faire quand il n'est pas en mesure d'effectuer l'opération. reloadHint est mis à FALSE dans le message SearchRequest nécessitant l'initial content poll.

   Si l'opération est un succès, un cookie représentant l'état synchronisé de la copie cliente devrait être retournée pour être utilisé dans d'autres Sync Operations.

Content Update Poll

   Une fois la requête reçue, le serveur fournis la mise à jours du contenu en utilisant un jeu de 0 ou plusieurs messages SearchResultEntry et SearchResultReference suivi par un message SearchResultDone. Le serveur doit:

a) Fournir la séquence des messages nécessaire pour une convergence éventuelle de la copie cliente au contenu de la copie du serveur
b) Traiter la requête comme demande de contenu initial ( ignore le cookie ou l'état de synchronisation )
c) Indiquer que la convergence incrémentale n'est pas possible en retournant e-syncRefreshRequired
d) Retourner un resultCode autre que success ou e-syncRefreshRequired

   Un Sync Operation peut consister d'une simple phase present, une simple phase delete, ou une phase present suivi par une phase delete.

   Dans chaque phase, pour chaque entrée ou référence qui a été ajouté au contenu ou a été changé depuis le Sync Operation précédent indiqué par le cookie, le serveur retourne un message SearchResultEntry ou SearchResultReference, respectivement, chacun avec un contrôle Sync State consistant de l'état add, un entryUUID contenant l'UUID de l'entrée ou de la référence, et aucun cookie. Chaque message SearchResultEntry représente l'état courant d'une entrée changée. Chaque message searchResultReference représente l'état courant d'une référence changée.

   Dans la phase present, pour chaque entrée qui n'a pas été changée depuis le Sync Operation précédent, un SearchResultEntry vide est retourné dont l'objectName reflète le DN courant de l'entrée, dont le champ attributes est vide, et dont le contrôle Sync State consiste de l'état present, un entryUUID contenant l'UUID de l'entrée, et aucun cookie. Pour chaque référence qui n'a pas été changé depuis le Sync Operation précedent, un SearchResultReference vide contenant une sequence de LDAPURL vide est retournée avec un contrôle Sync State consistant le l'état present, un entryUUID contenant l'UUID de l'entrée, et aucun cookie. Aucun message n'est envoyé pour les entrées ou références qui ne sont plus dans le contenu.

   De multiples entrées vides avec un contrôle Sync State à l'état present devraient être fusionnés en un ou plusieurs message Sync Info de valeur syncIdSet avec refreshDeletes à FALSE. syncUUID contient un jeu d'UUID d'entrées et références inchangées depuis le dernier Sync Operation. syncUUID peut être vide. Le message Sync Info de syncIdSet peut contenir un cookie pour représenter l'état du contenu après avoir effectué la synchronisation des entrées dans le jeu.

   Dans la phase delete, pour chaque entrée qui n'est plus dans le contenu, le serveur retourne un SearchResultEntry dont l'objectName reflète un DN passé de l'entrée ou vide, dont le champ attributes est vide, et dont le contrôle Sync State a un état delete, un entryUUID contenant l'UUID de l'entrée supprimée, et aucun cookie. Pour chaque référence qui n'est plus dans le contenu, un SearchResultReference contenant une séquence de LDAPURL vide est retourné avec un contrôle Sync State à l'état delete, un entryUUID contenant l'UUID de la référence supprimée, et aucun cookie.

   De multiples entrées vides avec un contrôle Sync State à l'état delete devraient être fusionnés en un ou plusieurs message Sync Info de valeur syncIdSet avec refreshDelete à TRUE. syncUUID contient un jeu d'UUID d'entrées et références supprimées du contenu depuis le dernier Sync Operation. syncUUID peut être vide. Le message Sync Info de syncIdSet peut contenir un cookie pour représenter l'état du contenu après avoir effectué la synchronisation des entrées dans le jeu.

   Quand une phase present est suivie par une phase delete, le 2 phases sont délimitées par un message Sync Info contenant syncInfoValue de refreshPresent, qui peut contenir un cookie représentant l'état après avoir complété la phase present. Le refreshPresent contient refreshDone, qui est toujours FALSE dans le mode refreshOnly parce qu'il est suivi par une phase delete.

   Si un Sync Operation consiste en un simple phase, chaque phase et par conséquent le Sync Operation sont marqués comme terminés par un message SearchResultDone avec le contrôle Sync Done, qui devrait contenir un cookie représentant l'état du contenus après avoir complété le Sync Operation. Le contrôle Sync Done contient refreshDeletes, qui est à FALSE pour la phase present et à TRUE pour la phase delete.

   Si un Sync Operation consiste d'une phase present suivie par une phase delete, le Sync Operation est marqué comme terminé à la fin de la phase delete par un message SearchResultDone avec le contrôle Sync Done, qui devrait contenir un cookie représentant l'état du contenu après avoir complété le Sync Operation. Le contrôle Sync Done contient refreshDeletes, qui est à TRUE.

   Le client peut spécifier s'il préfère recevoir un contenu initial en fournissant reloadHint à TRUE ou recevoir un e-syncRefreshRequired en fournissant reloadHint à FALSE ( donc absent ), dans ce cas le serveur détermine s'il est impossible ou inéfficace d'achever la convergence éventuelle en continuant le thread de synchronisation incrémentale courant.

   Une valeur resultCode de success indique que l'opération est complétée avec succès. Un resultCode de e-syncRefreshRequired indique qu'un refresh complet ou partiel est nécessaire. Sinon, le resultCode indique la nature de l'erreur. Un cookie est fournis dans le contrôle Sync Done pour l'utiliser dans les Sync Operations suivantes pour une synchronisation incrémentale.

Mode refreshAndPersist

   Une requête Sync avec le mode refreshAndPersist demande le contenu initial ou la mise à jours courante (durant l'étape refresh) suivie par des notifications de changement (durant l'étape persist).

Étape refresh

   Le contenu refresh est fourni comme décris précédemment, excepté que le refresh du contenu complété avec succès est indiqué en envoyant un message Sync Info de refreshDelete ou refreshPresent avec une valeur refreshDone à TRUE au lieu d'un message SearchResultDone avec un resultCode success. Un cookie devrait être retourné dans le message Sync Info pour représenter l'état du contenu après avoir firi l'état refresh du Sync Operation.

Étape persist

   Des notifications de changement sont fournis durant l'étape persist. Lorsqu'un changement est fait dans le DIT, le serveur notifie le client des changements du contenu. Les mises à jours du DIT peut causer des entrées et références qui sont ajoutées, supprimées ou modifiées dans le contenu.

   Là où des mises à jours du DIT implique qu'une entrée a été ajoutée au contenu, le serveur fournis un message SearchResultEntry qui représente l'entrée telle qu'elle apparaît dans le contenu. Le message devrait inclure un contrôle Sync State avec l'état add, un entryUUID contenant l'UUID de l'entrée et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une référence est ajoutée au contenu, le serveur fournis un message SearchResultReference qui représente la référence dans le contenu. Le message devrait inclure un contrôle Sync State avec l'état add, un entryUUID contenant l'UUID associée avec la référence, et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une entrée a été modifiée dans le contenu, le serveur fournis un message SearchResultEntry qui représente l'entrée telle qu'elle apparaît dans le contenu. Le message devrait inclure un contrôle Sync State avec l'état modify, un entryUUID contenant l'UUID de l'entrée, et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une référence est modifiée dans le contenu, le serveur fournis un message SearchResultReference qui représente la référence dans le contenu. Le message devrait inclure un contrôle Sync State avec l'état modify, un entryUUID contenant l'UUID associée avec la référence, et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une entrée a été supprimée du contenu, le serveur fournis un message SearchResultEntry sans attributs. Le message devrait inclure un contrôle Sync State avec l'état delete, un entryUUID contenant l'UUID de l'entrée, et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une référence est supprimée du contenu, le serveur fournis un message SearchResultReference avec un LDAPURL vide. Le message devrait inclure un contrôle Sync State avec l'état delete, un entryUUID contenant l'UUID associée avec la référence, et un cookie optionnel.

   plusieurs entrées vides avec un contrôle Sync State delete devraient être fusionnés en un ou plusieurs message Sync Info de valeur syncIdSet avec refreshDeletes à TRUE. syncUUID contient un jeu d'UUID des entrées et références qui ont été supprimés du contenu. Le message Sync Info de syncIdSet peut contenir un cookie pour représenter l'état du contenu après avoir effectué la synchronisation des entrées dans le jeu.

   Avec chacun de ces messages, le serveur peut fournir un nouveau cookie pour être utilisé dans les Sync Operation suivants. Additionnellement, le serveur peut également retourner des messages Sync Info avec un newCookie pour fournir un nouveau cookie. Le client devrait utiliser le dernier cookie qu'il a reçu du serveur pour les Sync Operation suivants.

Paramètres de requête de recherche

   Comme vu plus haut, le client devrait spécifier les même paramètres de contrôle de contenu dans chaque requête de recherche de la session. Tous les champs du message SearchRequest sont considérés comme des paramètres de contrôle de contenu excepté pour sizeLimit et timeLimit.

baseObject

   Comme avec une opération de recherche normale, les étapes refresh et persist ne sont pas isolés des changement du DIT. Il est possible que l'entrée référé par le baseObject soit supprimé, renommé, ou déplacé. Il est également possible que l'objet alias utilisé pour trouver l'entrée référée par le baseObject soit changé de telle sorte que le baseObject réfère à une entrée différente.

   Si le DIT est mis à jours durant le traitement du Sync Operation d'une manière qui cause le baseObject à ne plus référer à une entrée ou dans une manière qui change l'entrée auquel il fait référence, le serveur devrait retourner un resultCode approprié, tel que noSuchObject, aliasProblem, aliasDereferencingProblem, referral, ou e-syncRefreshRequired.

derefAliases

   Cette opération ne supporte pas le déréférencement d'alias durant la recherche. Le client doit spécifier neverDerefAliases ou derefFindingBaseObj pour le paramètre derefAliases du SearchRequest. Le serveur devrait traiter les autres valeurs ( ex: derefInSearching, derefAlways) comme des erreurs de protocole.

sizeLimit

   sizeLimit s'applique seulement aux entrées (sans regarder leur état dans le contrôle Sync State) retourné durant l'opération refreshOnly ou l'étape refresh de l'opération refreshAndPersist.

timeLimit

   pour un Sync Operation, le timeLimit s'applique à toute l'opération. Pour une opération refreshAndPersist, e timeLimit s'applique seulement à l'étape refresh incluant la génération du message Sync Info avec une valeur refreshDone à TRUE.

filtre

   Le client devrait éviter les filtres qui s'appliquent aux valeurs des attributs utilisés par le serveur comme maintenant les meta-informations.

objectName

   Le Sync Operation utilise les valeurs entryUUID fournis dans le contrôle Sync State comme clé primaire aux entrées. Le client doit utiliser ces entryUUID pour corréler les messages de synchronisation.

   Dans certaines circonstances, le DN retourné peut ne pas refléter le DN courant de l'entrée. En particulier, quand l'entrée a été supprimée du contenu, le serveur peut fournir un DN vide si le serveur ne désire pas informer du DN courant de l'entrée( ou, si supprimé du DIT, le dernier DN de l'entrée).

   Noter également que le DN de l'entrée peut être vue comme une méta-information (voir plus bas).

Annuler le Sync Operation

   Les serveurs doivent implémenter l'opération ldap Cancel et supporter l'annulation des opérations de synchronisation. Pour annuler le Sync Operation en cour, le client fournis une opération ldap Cancel.

   Si à un moment le serveur n'est plus en mesure de continuer l'opération, le serveur devrait retourner un SearchResultDone avec un resultCode indiquant la raison de l'arrêt de l'opération

   Que ce soit le client ou le serveur qui initie la fin, le serveur peut fournir un cookie dans le contrôle Sync Done pour l'utiliser dans les Sync Operation suivants.

Refresh Required

   Pour accomplir la synchronisation à convergence éventuelle, le serveur peut terminer le Sync Operation dans les étapes refresh ou persist en retournant un resultCode e-syncRefreshRequired au client. Si aucun cookie n'est fournis, un refresh complet est nécessaire. Si un cookie représentant un état synchronisé est fournis dans cette réponse, un refresh incrémental est nécessaire.

   Le serveur peut choisir de fournir une copie complète dans l'étape refresh (ex: en ignorant le cookie ou l'état de synchronisation représenté dans le cookie) au lieu de fournir un refresh incrémentale pour accomplir la convergence éventuelle.

   La décision entre le retour du contenu initial et le retour du resultCode e-syncRefreshRequired peut être basé sur le reloadHint dans le contrôle Sync Request du client.

   Dans le cas de l'étape persist, le serveur retourne le resultCode e-syncRefreshRequired au client pour indiquer que le client doit ré-émettre un nouveau Sync Operation pour obtenir une copie synchronisée du contenu. Si aucun cookie n'est fournis, un refresh complet est nécessaire. Si un cookie représentant un état synchronisé est fournis, un refresh incrémental est nécessaire.

   Le serveur peut également retourner un e-syncRefreshRequired s'il détermine qu'un refresh serait plus efficace qu'envoyer tous les messages requis pour la convergence.

   Noter que le client peut recevoir un ou plusieurs messages SearchResultEntry, SearchResultReference, et/ou des Sync Info avant qu'il reçoive un message SearchResultDone avec le resultCode e-syncRefreshRequired.

Considérations diverses

   Le serveur doit s'assurer que le nombre de messages générés pour refresh le contenu client n'excède pas le nombre d'entrées présentes dans le contenu. Bien qu'il n'y ait pas de pré-requis pour les serveurs de maintenir des informations d'historique, si le serveur a un historique suffisant pour déterminer avec certitude quelles entrées dans la copie client ne sont plus présentes dans le contenu et que le nombre de telles entrées est inférieur ou égal au nombre d'entrées inchangées, le serveur devrait générer des messages delete au lieu de message d'entrées présentes.

   Quand la quantité d'historique maintenu dans le serveur n'est pas suffisant pour que les clients puissent les refreshOnly peut fréquents, c'est généralement que le serveur a des informations d'historique incomplets.

   Le serveur ne devrait pas recourir à un reload complet quand les informations d'historique ne sont pas suffisants pour générer des message d'entrées supprimées. Le serveur devrait générer soit des messages d'entrée présentes uniquement ou des messages d'entrées présentes suivis par les messages d'entrée supprimées pour ramener la copie client à l'état courant. Dans le dernier cas, les messages d'entrées présentes apporte la copie cliente à un état couvert par les informations d'historique maintenus dans le serveur.

   Le serveur devrait maintenir suffisamment (courant et historique) d'information d'état (tel qu'un horodatage de dernière modification à l'échelle du contexte) pour déterminer si aucun changement n'a été fait dans le contexte depuis que le refresh a été fournis et, quand aucun changement n'a été fait, ne génère aucun message d'entrée supprimée au lieu de messages présents.

   Le serveur ne devrait pas utiliser les informations d'historique quand son utilisation ne réduit pas le trafic de synchronisation ou quand sont utilisation peut exposer des informations sensibles non permises par le client.

   L'implémenteur du serveur devrait également considérer les problèmes de bavardage qui s'étendent sur plusieurs opérations de synchronisation d'une session. Comme noté plus haut, le serveur peut retourner e-syncRefreshRequired s'il détermine qu'un reload sera plus efficace que continuer l'opération courante. Si reloadHint dans le Sync Request est TRUE, le serveur peut initier un reload sans diriger le client pour demander un reload.

   Le serveur devrait transférer un nouveau cookie fréquemment pou éviter d'avoir à transférer des informations déjà fournies au client. Même où les changement du DIT n'impliquent pas de changements dans la synchronisation du contenu à transférer, il peut être avantageux de fournir un nouveau cookie en utilisant un message Sync Info. Cependant, le serveur devrait éviter de surcharger le client ou le réseau avec des messages Sync Info.

   Durant le mode persist, le serveur devrait fusionner les messages de mises à jours de la même entrée. Le serveur peut retarder la génération de la mise à jours d'une entrée en anticipation de changements ultérieurs que cette entrée qui pourraient être fusionnés. La longueur du delai devrait être suffisamment long pour permettre de fusionner les demandes de mises à jours émises mais suffisamment court pour que l'inconsistance transitoire induite par le délai soit corrigé.

   Le serveur devrait utilise le message Sync Info syncIdSet quand il y a plusieurs messages delete ou present pour réduire la quantité de trafic de synchronisation.

   Noter également qu'il peut y avoir plusieurs clients intéressés par le changement particulier, et que ces serveurs qui tentent de tous les desservir en même temps peuvent causer des congestion sur le réseau. Les problèmes de congestion sont intensifiés quand les changements nécessitent un gros transfert pour chaque client intéressé. Les implémenteurs et déployeurs de serveur devraient prendre en compte les étapes pour empêcher et gérer la congestion du réseau.

Multiplexer les opérations

   Le protocole LDAP permet de multiplexer les opérations dans une simple session LDAP. Les clients ne devraient pas maintenir plusieurs sessions LDAP avec le même serveur. Les serveurs devraient s'assurer que les réponses des opérations traité concurrentiellement sont entrelacés de façon équitable.

   Les clients devraient combiner les Sync Operation dont le jeu de résultat est largement chevauché. Les clients ne devraient pas combiner les Sync Operation dont les jeux de résultat sont largement non-chevauchés. Cela s'assure que dans le cas d'une réponse e-syncRefreshRequired peut être limitée à quelques jeux de résultats.

Entry DN

   Le DN de l'entrée est construite depuis son RDN et le DN de son parent, il est dont souvent vu comme une méta-information. renommer ou déplacer à un nouveau supérieur, le DN de l'entrée est changé, ce changement ne devrait pas, par lui-même, causer de message de synchronisation à envoyer pour cette entrée. Cependant, Si le renommage ou le déplacement ajoute ou supprime l'entrée du contenu, les messages de synchronisation appropriés devraient être générés pour l'indiquer au client.

   Quand un serveur traite le DN de l'entrée comme méta-information, le serveur devrait soit:

- Évaluer tous MatchingRuleAssertions à TRUE si matche une valeur d'un attribut de l'entrée, sinon Undefined, ou
- Évaluer tous MatchingRuleAssertions avec dnAttributes à TRUE comme Undefined.

   Le dernier choix est offert pour simplifier l'implémentation de serveurs.

Attributs Opérationnels

   Lorsque les valeurs d'un attribut opérationnel sont déterminés par les valeurs non maintenues dans l'entrée, l'attribut opérationnel ne devrait pas supporter la synchronisation de cet attribut.

   Les serveurs devraient supporter la synchronisation des attributs opérationnels suivants: createTimestamp, modifyTimestamp, creatorsName, modifiersName. Les serveurs peuvent supporter la synchronisation d'autres attributs opérationnels.

Attributs collectifs

   La modification d'un attribut collectif affecte généralement le contenu de plusieurs entrées, qui sont les membres de la collection. Il n'est pas efficace d'inclure les valeurs des attributs collectifs visible dans les entrées de la collection, vu que la modification d'un simple attribut collectif nécessite la transmission de plusieurs SearchResultEntry ( un pour chaque entrées dans la collection que la modification affecte )

   Les serveurs ne devraient pas synchroniser les attributs collectifs apparaissant dans les entrées d'une collection. Les serveur peuvent supporter la synchronisation des attributs collectifs apparaissant dans les attributs collectif des subentries.

Accès et autres contrôle administratifs

   Les entrées sont communément sujets à accès et autres contrôles administratifs. Bien que des portions d'information de stratégie gouvernant une entrée particulière peuvent être maintenus dans l'entrée, les informations de stratégies sont souvent maintenus ailleurs. À cause de cela, les changement d'information de stratégie rendent plus difficile la vérification de convergence éventuel durant la synchronisation incrémentale.

   Lorsqu'il n'est pas possible ou infaisable de générer des changement de contenu résultant d'un changement d'information de stratégie, les serveurs peuvent opter pour retourner e-syncRefreshRequired ou pour traiter le Sync Operation comme requête de contenu initial.

Intéraction avec d'autres contrôles

   Le Sync Operation peut être utilisé avec:

- ManageDsaIT
- Subentries Control

ManagesDsaIT

   Le Contrôle ManageDsaIT indique que l'opération agit sur le DIT et force les objets spéciaux à être traités comme des entrées.

Subentries Control

   Le contrôle Subentries est utilisé avec l'opération de recherche pour contrôler la visibilité des entrées et des subentries qui sont dans le scope. Quand utilisé avec le Sync Operation, le contrôle subentries et d'autres facteurs sont utilisés pour déterminer si une entrée ou un subentry apparait dans le contenu.

Shadowing

   Certains serveurs peuvent maintenir des copies shadow des entrées qui peuvent être utilisée pour répondre à des requêtes search et compare. De tels serveurs peuvent également supporter les requêtes de synchronisation de contenu.

Shadowing

   Bien qu'un client peut connaître plusieurs serveurs qui sont capables d'être utilisé pour obtenir un contenu d'annuaire particulier, un client ne devrait pas assumer qui chacun de ces serveurs est capable de continuer une session de synchronisation de contenu. Le client devrait fournir chaque requête Sync d'une session Sync au même serveur.

   Cependant, via le nom de domaine ou les redirections d'adresse IP ou d'autres techniques, plusieurs serveurs physiques peuvent être fait pour apparaître comme un serveur logique à un client. Seuls les serveurs qui sont également capable en ce qui concerne leur support de Sync Operation et qui maintienne également des copies complètes des entrées devraient être faits pour apparaître comme un serveur logique. En particulier, chaque serveur physique agissant comme un serveur logique devrait être également capable de continuer une synchronisation de contenu basé sur des cookies fournis par un autre serveur physique sans nécessiter un full reload. Parce qu'il n'y pas de mécanisme de shadowing ldap standard, la spécification de la manière d'implémenter cette capacité est laissé à de futures documents.

   Noter qu'il peut être difficile pour le serveur de déterminer avec certitude quel contenu a été fournis au client par un autre serveur, spécifiquement dans les environnement Shadowing qui permet aux évènements shadowing d'être fusionnés. Pour ces serveurs, l'utilisation de la phase delete peut ne pas être applicable.

Considérations de sécurité

   Pour maintenir une copie synchronisée du contenu, un client doit supprimer les informations de sa copie du contenu comme décris plus haut. Cependant, le client peut maintenir les connaissances des informations qui lui sont communiquées par le serveur séparé de sa copie du contenu utilisé pour la synchronisation. La gestion de ces connaissances est hors du scope de ce document. Les serveurs devraient faire attention à ne pas communiquer les informations du contenu que le client n'a pasle droit de connaître.

   Bien que les informations fournies par une série de Sync Operation refreshOnly est similaire à celles fournies par une série d'opération de recherche, l'étape persist peur communiquer des informations additionnelles. Un client peut être capable de discerner les informations sur la séquence d'opérations de mises à jours particulière qui à causé le changement de contenu.

   Les implémenteurs devraient prendre des précautions contre le contenu de cookie malicieux, incluant les cookies malformés ou les cookies valides utilisé avec différentes protections et/ou associations de sécurité pour tenter d'obtenir un accès non autorisé aux informations. Les serveurs peuvent inclure une signature numérique dans le cookie pour détecter la falsification.

   L'opération peut être la cible d'attaque DOS direct. Les implémenteurs devraient fournir des protections contre ça. Les serveurs peuvent placer le contrôle d'accès ou d'autres restrictions contre l'utilisation de cette opération.

   Noter que même les petites mises à jours peuvent causer une quantité significative de trafic. Un utilisateur pourrait abuser de ses privilèges de mise à jours pour monter un DOS indirecte.

Considérations d'implémentation basé sur CSN

   Cet appendix discute de l'implémentation de l'opération ldap de synchronisation de contenu associé avec l'approche basé sur le numéro de séquence de changement.

   Cet approche est ciblée pour l'utilisation dans des serveurs qui ne maintiennent pas d'information d'historique sur les changements faits dans le DIT et ainsi doit s'assurer de l'état de l'annuaire courant et un état de synchronisation minimal embraqué dans le Sync Cookie. Les serveurs qui implémentent des informations d'historique devraient considérer d'autres approches qui exploitent ces informations d'historique.

   Un CSN est effectivement un timestamp qui a la granularité suffisante pour s'assurer que la relation de précedence dans le temps de 2 mises à jours sur le même objet peut être déterminer. Les CSN ne doivent pas être confondus avec les Commit Sequence Number ou Commit Log Record Number. Un Commit Sequence Number permet de déterminer comment 2 envoies (sur le même objet ou différents) sont liés l'un à l'autre dans le temps. Un Change Sequence Number associé avec des entrées différentes pour être envoyés dans le désordre. Dans le reste de cet appendix, le terme CSN réfère toujours au Change Sequence Number.

   Dans ces approches, le serveur ne maintient pas seulement un CSN pour chaque entrée de l'annuaire mais maintient également une valeur qui l'on appel le context CSN. Ce context CSN est le plus grand entry CSN envoyé qui n'est pas supérieur à une entry CSN exceptionnelle (non validée) pour toutes les entrées dans le contexte de l'annuaire. Les valeurs du context CSN sont utilisée dans les valeurs syncCookie comme indicateurs d'état de synchronisation.

   Vu que les opérations de recherche ne sont pas isolées des mises à jours d'annuaire individuels et les opérations de mises à jours individuels ne peuvent pas assumer être sérialisés, on ne peut pas assumer que le contenu retourné incorpore chaque changement dont le CSN est inférieur ou égal au plus grand entryCSN dans le contenu. Le contenu incorpore tous les changements dont les CSN sont inférieurs ou égal au contextCSN avec de traiter la recherche. Le contenu peut également incorporer un sous-jeu de changements dont le CSN est supérieur au contextCSN avant chaque traitement de recherche mais inférieur ou égal au contextCSN après le traitement de la recherche. Le contenu n'incorpore pas les changements dont le CSN est supérieur au contextCSN après le traitement de la recherche.

   Une implémentation de serveur simple pourrait utiliser la valeur du contextCSN avec de traiter la recherche pour indiquer l'état. Une telle implémentation embarquerai cet valeur dans chaque syncCookie retourné. On appel çà le cookie CSN. Quant un refresh est demandé, le serveur va simplement générer des messages de mises à jours pour tous les entrées dans le contenu dont le CSN est supérieur au cookieCSN fournis et générer des messages present pour toutes les autres entrées dans le contenu. Cependant, si le contextCSN courant est le même que le cookieCSN, le serveur devrait générer 0 updates et 0 delete et indiquer un refreshDeletes à TRUE, vu que l'annuaire n'a pas changé.

   L'implémentation devrait également considérer l'impact des changements des méta-informations, tel que les contrôles d'accès, qui affecte la détermination du contenu. Un approche est pour le serveur de maitenir un CSN meta. Ce metaCSN serait mis à jours quand une méta-information affectant la détermination du contenu a été changée. Si la valeur du metaCSN est supérieur au cookieCSN, le serveur devrait ignorer le cookie et traiter la demande comme requête initial pour le contenu.

   Additionnellement, les serveurs peuvent vouloir maintenir des information d'historique par session pour réduire le nombre de messages nécessaires à transférer durant les refresh incrémentales. Spécifiquement, un serveur pourrait enregistrer les informations sur les entrées qui ont quitté le scope d'une session sync déconnectée et l'utiliser ultérieurement pour générer des informations delete au lieu de messages present.

   Quand les informations d'historique sont tronqués, le CSN de la dernière information d'historique tronquée peut être enregistrée comme CSN tronquée de l'information d'historique. Le CSN tronqué peut être utilisé pour déterminer si la copie client peut être couvert par les informations d'historique en les comparant à l'état de synchronisation contenu dans le cookie fournis par le client.

   quand il y a un grand nombre de sessions, il peut être censé de maintenir un tel historique seulement pour le clients sélectionnés. De même, les serveurs utilisant cette approche nécessitent de considérer les problèmes de consommation de ressource pour s'assurer de performance raisonnable et éviter les abus. Il peut être approprié de restreindre ce mode d'opération par stratégie.
^
06 novembre 2013

htmlpdflatexmanmd




rfc4876

rfc4876

Schéma de profile de configuration pour les agents basés sur LDAP

preferredServerList Liste d'adresses et ports de serveurs que le DUA doit contacter, dans l'ordre.
defaultServerList Doit être examiné seulement si preferredServerList n'est pas fournis.
defaultSearchBase Quand un DUA doit requêter le DSA pour des informations, cet attribut fournis la base de recherche.
authenticationMethod Liste par ordre de préférence de méthodes bind. (peut être none, simple, sasl et tls)


authMethod = method *(";" method)
method = none / simple / sasl / tls
none = "none"
simple = "simple"
sasl = "sasl/" saslmech [ ":" sasloption ]
sasloption = "auth-conf" / "auth-int"
tls = "tls:" (none / simple / sasl)
saslmech = SASL mechanism name

credentialLevel Type de crédentials que le DUA doit utiliser en contactant le DSA (anonymous, proxy, self)


credentialLevel = level *(SP level)
level = self / proxy / anonymous
self = "self"
proxy = "proxy"
anonymous = "anonymous"

serviceSearchDescriptor Définis comment et où un DUA devrait rechercher les informations pour un service particulier.


serviceSearchList = serviceID ":" serviceSearchDesc *(";" serviceSearchDesc)
serviceSearchDesc = confReferral / searchDescriptor
searchDescriptor = [base] ["?" [scopeSyntax] [" ?" [filter]]]
confReferral = "ref :" distinguishedName
base = distinguishedName / relativeBaseName
relativeBaseName = 1*(relativeDistinguishedName ",")
filter = UTF-8 encoded string

Exemple

defaultSearchBase: dc=mycompany,dc=com
serviceSearchDescriptor: email:ou=people,ou=org1,?
one;ou=contractor,?one;
ref:cn=profile,dc=mycompany,dc=com

   Dans cet exemple, le DUA doit rechercher dans "ou=people,ou=org1,dc=mycompany,dc=com" en premier. Ensuite il devrait rechercher dans "ou=contractor,dc=mycompany,dc=com", et finalement il devrait rechercher dans d'autres emplacement comme spécifié dans le profile décris à "cn=profile,dc=mycompany,dc=com"

attributeMap Mapping d'attributs pour toutes les opérations LDAP effectuées pour un service qui a une entrée attributeMap. Parce que le mapping est spécifique à chaque service dans le DUA, un serviceID est requis dans la syntaxe.


attributeMap = serviceID ":" origAttribute "=" attributes
origAttribute = attribute
attributes = wattribute *( SP wattribute )
wattribute = WSP newAttribute WSP
newAttribute = descr / "*NULL*"
attribute = descr

   exemple: supposons qu'un DUA agis comme un service mail. Par défaut, le service email utilise "mail", "cn" et "sn" pour découvrir les adresses emails. Cependant, le service email a été déployé dans un environnement qui utilise "employeeName" au lieu de "cn". également, au lieu d'utiliser "mail", l'attribut utilisé est "email":

attributeMap: email:cn=employeeName
attributeMap: email:mail=email

searchTimeLimit Définis le temps maximum en secondes que le DUA devrait permettre pour une requête search.
bindTimeLimit Définis le temps maximum en secondes que le DUA devrait permettre pour les opérations bind.
followReferrals à TRUE, le DUA devrait suivre les référants. a FALSE, ne doit pas les suivre.
dereferenceAliases à TRUE, le DUA devrait permettre le déréférencement d'alias. A FALSE, ne doit pas déréférencer les alias.
profileTTL Définis la fréquence à laquelle le DUA devrait recharger et se reconfigurer.
objectclassMap Un DUA peut effectuer un mappage de classe d'objet pour toutes les opérations LDAP effectuées pour un service


objectclassMap = serviceID ":" origObjectclass "=" objectclass
origObjectclass = objectclass
objectclass = keystring

   exemple: supposons qu'un DUA agit comme un service mail. Par défaut le service "email" utilise "mail", "cn" et "sn" pour découvrir les adresses email dans les entrées créée en utilisant la classe d'objet inetOrgPerson. Cependant, le service mail a été déployé dans un environnment qui utilise les entrées crééer en utilisant la classe d'objet "employee". Dans ce cas, "cn" peut être mappé à "employeeName", et "inetOrgPerson" peut être mappé à "employee":

attributeMap: email:cn=employeeName
objectclassMap: email:inetOrgPerson=employee

defaultSearchScope Fournis le scope de recherche pour le DUA. Peut être écrasé par serviceSearchDescriptor



scopeSyntax = "base" / "one" / "sub"

serviceAuthenticationMethod Définis par ordre de préférence de méthodes bind à utiliser pour contacter un DSA pour un service particulier.



svAuthMethod = serviceID ":" method *(";" method)

serviceCredentialLevel Définis quel types de crédentials le DUA devrait utiliser en contacta,t le DSA pour un service particulier.



svCredentialLevel = serviceID ":" level *(SP level)

Exemple

serviceCredentialLevel: email:proxy anonymous

Schéma


( 1.3.6.1.4.1.11.1.3.1.1.0 NAME 'defaultServerList' DESC 'List of default servers' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' DESC 'Default base for searches' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' DESC 'List of preferred servers' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.3 NAME 'searchTimeLimit' DESC 'Maximum time an agent or service allows for a search to complete' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.4 NAME 'bindTimeLimit' DESC 'Maximum time an agent or service allows for a bind operation to complete' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.5 NAME 'followReferrals' DESC 'An agent or service does or should follow referrals' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' DESC 'Identifies the types of authentication methods either used, required, or provided by a service or peer' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.7 NAME 'profileTTL' DESC 'Time to live, in seconds, before a profile is considered stale' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.9 NAME 'attributeMap' DESC 'Attribute mappings used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.11.1.3.1.1.10 NAME 'credentialLevel' DESC 'Identifies type of credentials either used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.11 NAME 'objectclassMap' DESC 'Object class mappings used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.11.1.3.1.1.12 NAME 'defaultSearchScope' DESC 'Default scope used when performing a search' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.13 NAME 'serviceCredentialLevel' DESC 'Specifies the type of credentials either used, required, or supported by a specific service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.11.1.3.1.1.14 NAME 'serviceSearchDescriptor' DESC 'Specifies search descriptors required, used, or supported by a particular service or agent' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.4.1.11.1.3.1.1.15 NAME 'serviceAuthenticationMethod' DESC 'Specifies types authentication methods either used, required, or supported by a particular service' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.4.1.11.1.3.1.1.16 NAME 'dereferenceAliases' DESC 'Specifies if a service or agent either requires, supports, or uses dereferencing of aliases.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )


( 1.3.6.1.4.1.11.1.3.1.2.5 NAME 'DUAConfigProfile'
    SUP top STRUCTURAL
    DESC 'Abstraction of a base configuration for a DUA'
    MUST ( cn )
    MAY ( defaultServerList $ preferredServerList $
    defaultSearchBase $ defaultSearchScope $
    searchTimeLimit $ bindTimeLimit $
    credentialLevel $ authenticationMethod $
    followReferrals $ dereferenceAliases $
    serviceSearchDescriptor $ serviceCredentialLevel $
    serviceAuthenticationMethod $ objectclassMap $
    attributeMap $ profileTTL ) )

Exemples

   Dans cette section, on décris un DUA fictif qui fournis un service appelé "email". Ce service est configuré de manière à trouver les utilisateurs avec un adresse email avec la classe d'objet inetOrgPerson, Le nom dans "cn" et le mail dans "mail"

   Le filtre de recherche par défaut pour le service email est "(objectclass=inetOrgPerson)". Le service email définis également que quand il effectue une découverte nom/adresse, il va construire le filtre avec:

  (&(‹filter›)(cn=‹name string›))

ou, si "cn" a été mappé vers d'autres attributs:
(&(‹filter›)(attr1=‹token1›)(attr2=‹token2›)...)

   L'exemple ci-dessous montre comment le service email construit sa recherche, basé sur un profile définis. Dans tous les cas, defaultSearchBase est "o=airius.com", et defaultSearchScope n'est pas définis.

exemple 1:
serviceSearchDescriptor:email:"ou=marketing,"
    
base: ou=marketing,o=airius.com
scope: sub
filter: (&(objectclass=inetOrgPerson)(cn=Jane Hernandez))

exemple 2:
serviceSearchDescriptor:email:"ou=marketing,"?one?(&(objectclass=inetOrgPerson)(c=us))
attributeMap:email:cn=2.5.4.42 sn

   Note: 2.5.4.42 est l'OID qui représente "givenName"

Dans cet exemple, le service email effectue une recherche ‹name string› comme décris plus haut pour générer un filtre de recherche complexe. L'exemple suivant résulte d'une recherche:
base: ou=marketing,o=airius.com
scope: one
filter: (&(&(objectclass=inetOrgPerson)(c=us))(2.5.4.42=Jane)(sn=Hernandez))

Exemple 3:
serviceSearchDescriptor: email:ou=marketing,"?base
attributeMap:email:cn=name

   Cet exemple est invalide parce que soit les guillemets devraient être échappé, soit il devrait y avoir des "

exemple 4:
serviceSearchDescriptor:email:ou=\\mar\\\\keting,\\"?base
attributeMap:email:cn=name
    
base:ou=\\mar\\keting,"
scope:base
filter: (&(objectclass=inetOrgPerson)(name=Jane Hernandez))

exemple 5:
serviceSearchDescriptor:email:ou="marketing",o=supercom

   Cet exemple est invalide parce que les " doivent être échappés

Exemple 6:
serviceSearchDescriptor:email:??(&(objectclass=person)(ou=Org1\\\\(temporary\\\\)))
base: o=airius.com
scope: sub
filter: (&((&(objectclass=person)(ou=Org1\\(Temporary\\)))(cn=Jane Henderson)))

Exemple 7:
serviceSearchDescriptor : email :"ou=funny ?org,"
    
base: ou=funny?org,o=airius.com
scope: sub
filter: (&(objectclass=inetOrgPerson)(cn=Jane Hernandez))

^
27 octobre 2013

htmlpdflatexmanmd




rfc5020

rfc5020

Attribut opérationnel entryDN

Cet attribut contient une copie du DN de l'entrée pour l'utiliser dans les assertions de valeur.
( 1.3.6.1.1.20 NAME 'entryDN'
    DESC 'DN of the entry'
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )

^
27 octobre 2013

htmlpdflatexmanmd




rfc5803

rfc5803

Schéma LDAP pour stocker les secrets SCRAM

   Ce mémo décris comment l'attribut LDAP authPassword peut être utilisé pour stocker des secrets utilisés par le mécanisme SCRAM dans SASL. La partie "scheme" de authPassword est le nom du mécanisme SCRAM. La partie "authInfo" est le compteur d'itération suivi par un ":" et un salt encodé base64. La partie "authValue" est la clé encodée en base64, suivi par ":" et la clé serveur encodé en base 64. La syntaxe de l'attribut peut être:


scram-mech = "SCRAM-SHA-1" / scram-mech-ext
scram-authInfo = iter-count ":" salt
scram-authValue = stored-key ":" server-key
iter-count = %x31-39 *DIGIT
salt = ‹base64-encoded value›
stored-key = ‹base64-encoded value›
server-key = ‹base64-encoded value›
scram-mech-ext = "SCRAM-" 1*9mech-char
mech-char = ‹Defined in RFC 4422›

   Noter que authPassword est multivalué

^
06 novembre 2013

htmlpdflatexmanmd




rfc5805

rfc5805

Transactions LDAP

   Les opérations de modifications LDAP tels que Add, Delete et Modify ont des propriétés ACID (Atomic, Consistency, Isolation, Durability). Chacune des ces modifications agissent sur une seule entrée à la fois. Il est souvent désirable de modifier plusieurs entrées en une seule unité d'intéraction, une transaction. Les transactions sont nécessaires pour supporter certaines applications, tel que le provisionning. Cette extension consiste de 2 opérations étendue, un contrôle, et une notification non-sollicitée. l'opération Start Transaction est utilisé pour obtenir un identifiant de transaction.

Requête et réponse Start Transaction

   Une requête Start Transaction est un LDAPMessage de CHOICE extendedReqrequestName est 1.3.6.1.1.21.1 et requestValue est absent.

  Une réponse Start Transaction est un LDAPMessage de CHOICE extendedRes envoyé en réponse à une requête Start Transaction avec responseName absent.

Contrôle Transaction Specification

   C'est un LDAPControl où controlType est 1.3.6.1.1.21.2, la criticité à TRUE, et controlValue est un ID de transaction. Ce contrôle est approprié pour les requêtes de modification tels que Add, Delete, Modify, ModifyDN et Password Modify.

Requête et réponse End Transaction

Une requête End Transaction est un LDAPMessage de CHOICE extendedReq où requestName est 1.3.6.1.1.21.3 et requestValue contient un txnEndReq encodé BER:
txnEndReq ::= SEQUENCE {
    commit BOOLEAN DEFAULT TRUE,
    identifier OCTET STRING }

   commit à TRUE, indiwue une requête pour envoyer la transaction identifiée par identifier. à FALSE indique une requête d'abandon de la transaction identifiée.

Une réponse End Transaction est un LDAPMessage envoyé en réponse à un requête End Transaction. Le nom de réponse est absent. responseValue si présent, contient un txEndRes encodé BER:
txnEndRes ::= SEQUENCE {
    messageID MessageID OPTIONAL,
    — msgid associated with non-success resultCode
    updatesControls SEQUENCE OF updateControls SEQUENCE {
    messageID MessageID,
    — msgid associated with controls
    controls Controls
    } OPTIONAL
}

   MessageID fournis l'id de message de la requête de mise à jours associée avec une réponse autre que success. messageID est absent quand un resulCode est success. updatesControls fournis une facilité pour retourner les contrôles de réponse qui normalement (en l'absence de transactions) seraient retournés dans une réponse de mise à jours.

Transaction annulée

   Le Aborted Transaction Notice est un message de notification non-sollicité où responseName est 1.3.6.1.1.21.4 et responseValue est présent et contient un id de transaction.

Découverte d'extension

   Les serveurs implémentant cette spécification devraient publier 1.3.6.1.1.21.1 et 1.3.6.1.1.21.3 dans supportedExtension et 1.3.6.1.1.21.2 dans supportedControl

Démarrer une transaction

   Un client qui souhaite effectuer une séquence de modifications dans l'annuaire envoie une requête Start Transaction. Le serveur envoie une réponse Start Transaction avec un ID de transaction et un resultCode success.

Spécifications d'une transaction

   Le client peut fournir une ou plusieurs requêtes de modifications, chacune avec un contrôle Transaction Specification contenant l'ID de transaction indiquant les modifications à traiter. Chacune de ces requêtes doivent avoir une valeur messageID différente. Si le serveur ne peut pas traiter l'opération demandée, il retourne immédiatement le resultCode adéquat, sinon il retourne success. Si le serveur ne peut plus continue la transaction, il fournis un Aborted Transaction Notice avec un resultCode adéquat.

Règlement de transaction

   Un client demande le règlement de la transaction en fournissant une requête End Transaction, indiquant son désire que la transaction soit traitée ou annulée.

  Une fois reçu une annulation de transaction, le serveur annule l'ID de transaction et abandonne toutes les opérations de la transaction.

  Une fois reçu une fin de transaction, le serveur traite toutes les opérations de la transaction. Le serveur retourne une réponse End Transaction avec resultCode à success et sans responseValue pour indiquer que toutes les modifications ont été appliquées. Sinon, le serveur retourne un resultCode adéquat. Si l'échec est associé avec un requête particulière, le txnEndRes.messageID dans responseValue est l'id de message de cette demande de modification. Si l'échec n'est pas associé à une requête de modification, aucun messageID n'est retourné.

Divers problèmes

   Les transactions ne peuvent pas être imbriquées. Chaque transaction doit être initiée, spécifiée et terminé avec un contexte de sécurité stable.

Intéraction avec d'autres extensions

Contrôle d'assertion Le contrôle Assertion est approprié pour les requête de modification dans une transaction. Il n'est pas approprié avec les opérations Start Transaction et End Transaction.
Contrôle ManageDsaIT Le contrôle ManageDsaIT est approprié pour les requête de modification dans une transaction. Il n'est pas approprié avec les opérations Start Transaction et End Transaction.
Contrôle d'autorisation proxifié Ce contrôle est approprié avec l'opération étendue Start Transaction, mais pas End Transaction.
Contrôle Read Entry Les contrôles Pre- et Post-Read sont appropriés avec des requêtes de modification dans une transaction. L'entrée est retournée dans txnEndRes.updatesControls et responseValue d'une réponse End Transaction.
^
02 novembre 2013

htmlpdflatexmanmd




rfc6171

rfc6171

Contrôle Don't Use Copy

   Cette extension peut être attachées au requêtes pour indiquer que les informations copiées (répliquées ou cachées) ne sont pas utilisés pour fournis des services. Il est principalement utilisé quand un client demande que le service soit fournis depuis la données originale (master).

   Ce contrôle est un contrôle LDAP dont controlType est 1.3.6.1.1.22 et controlValue est absent. La criticité doit est spécifiée. Le contrôle est approprié pour les opérations compare et search, mais pas pour les autres. Quand le contrôle est attaché à une requête, l'opération ne doit pas être effectuée sur une opération copiée. Si l'information originale n'est pas disponible, le serveur doit retourner un référant qui redirige le client vers un serveur capable de réponse à la requête ou retourner un code approprié (ex: unwillingToPerform).

   Quand un client est redirigé vers un référant, il doit fournir dontUseCopy avec la requête qu'il fait au référant.

^
08 septembre 2013

htmlpdflatexmanmd




slapacl

slapacl

Vérifie l’accès à une liste d’attributs en vérifiant dans la configuration de slapd

OPTIONS

-b DN Spécifie le DN dont l’accès est demandé.
-d debug_level Active le débug
-D authcDN Spécifie un DN à utiliser comme identité pour le test
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-o option[=value] Spécifie une option slapd ( syslog=‹subsystems›, syslog-level=‹level›, syslog-user=‹user›, et authzDN,domain,peername,sasl_ssf,sockname,sockurl,ssf,tls_ssf,transport_ssf)
-u Ne pas chercher l’entrée dans la base de données
-U authcID Spécifie un ID à mapper au DN comme par authz-regexp ou authz-rewrite.
-v mode verbeux
-X authzID Spécifie un ID d’autorisation à mapper au DN comme avec authz-regexp ou authz-rewrite.

Exemples

Test si bjorn peut accéder à l’attribut ’o’ de l’entrée o=University of Michigan,c=US en lecture
/usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -v -U bjorn -b "o=University of Michigan,c=US" "o/read:University of Michigan"
^
08 septembre 2013

htmlpdflatexmanmd




slapadd

slapadd

Ajouter des entrées dans une base slapd. toutes les entrées ajoutées appartiennent à l’identité sous laquelle slapadd fonctionne, il est donc nécessaire de l’exécuter sous la même identité que slapd

OPTIONS

-b suffix Utilise le suffix spécifié pour déterminer quelle base utiliser
-c Ignore les erreurs et continue
-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-g Désactive le gluing subordonné. Seul la base spécifiée sera traitée et non ses subordonnées attachés
-j lineno Saute à la ligne spécifiée dans le fichier LDIF avant de traiter les entrées.
-l ldif-file Fichier d’entrée
dbnum Ajoute des entrées dans la dbnum-ième base listée dans la configuration. Ne peut pas être utilisé avec -b
-o option[=value] Spécifie une option slapd
-q mode rapide (peut de vérifications)
-s Désactive la vérification du schéma
-S SID ID du serveur à utiliser en générant entryCSN. également pour contextCSN si -w.
-u dry-run n’écrit pas dans le backend
-v mode verbeux
-w Écrit les information de contexte syncrepl. après que les entrées soient ajoutées, met à jour le contextCSN

limitations

   slapd ne devrait pas être en cours de fonctionnement, ou au moins en lecture seule.
^
08 septembre 2013

htmlpdflatexmanmd




slapauth

slapauth

Vérifie une liste d’ID pour authc/authz

OPTIONS

-d debug-level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-M mech Spécifier un mécanisme
-o option[=value] Spécifie une option slapd ( syslog=‹subsystems›, syslog-level=‹level›, syslog-user=‹user›)
-R realm Spécifier un royaume
-U authcID Spécifier un ID à utiliser
-X authzID Spécifie un ID à utiliser
-v mode verbeux

Exemples

Test si l’utilisateur bjorn peut assumer l’identité de bjesen tel que définis par les directives
authz-policy from authz-regexp "^uid=([^,]+).*,cn=auth$" "ldap :///dc=example,dc=net ??sub ?uid=$1"
/usr/local/sbin/slapauth -f //usr/local/etc/openldap/slapd.conf -v -U bjorn -X u:bjensen
^
08 septembre 2013

htmlpdflatexmanmd




slapcat

slapcat

Utilitaire de génération de fichier LDIF

OPTIONS

-a filter Dump seulement les entrées correspondant au filtre
-b suffix Utilise le suffix spécifié pour déterminer quelle base utiliser
-c Ignore les erreurs et continue
-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-g Désactive le gluing subordonné. Seul la base spécifiée sera traitée et non ses subordonnées attachés
-H URI
-l ldif-file Écrit la sortie dans le fichier spécifié
dbnum Ajoute des entrées dans la dbnum-ième base listée dans la configuration. Ne peut pas être utilisé avec -b
-o option[=value] Spécifie une option slapd
-s subtree-dn Dump seulement les entrées dans la sous-arborescence spécifiée par ce DN

limitations

   slapd ne devrait pas être en cours de fonctionnement, ou au moins en lecture seule.
^
08 septembre 2013

htmlpdflatexmanmd




slapd

slapd

Serveur LDAP

OPTIONS

-4 IPv4 uniquement
-6 IPv6 uniquement
-T tool Mode tool. tool sélectionne s’il tourne en tant que : slapadd, slapcat, slapdn, slapindex, slappasswd, slapschema,slaptest. ces programmes sont généralement des liens symbolique vers slapd.
-d debug-level Active le débug
-s syslog-level niveau de debug à logger
service-name Nom du service (défaut : slapd)
-l syslog-local-user syslog facility (LOCAL0 à LOCAL7, USER, DAEMON)
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-h URLlist liste d’url d’écoute du serveur (défaut : ldap :///)
-r directory Répertoire où slapd va se chrooter
-u user Utilisateur du service
-g group Groupe du service
-c cookie Fournis un cookie pour la réplication syncrepl sous la forme d’une liste de nom=valeur (rid, sid, csn)
-o option[=value] Spécifie une option slapd (slp=on|off|slp-attrs gère le SLP. (ex : "slp=(tree=production),(server-type=OpenLDAP),(server-version=2.4.15)"
^
22 septembre 2013

htmlpdflatexmanmd




slapd-access

slapd-access

Configuration d'accès pour slapd

Structure

   access to ‹what› [ by ‹who› [ ‹access› ] [ ‹control› ] ]+

   Donne accès à un jeu d'entrées et/ou attributs (what) par des demandeurs (who). Les ACL sont évaluées dans l'ordre auxquelles elles apparaissent. lors qu'un what match, who est vérifié. puis les clauses access et control sont évaluées

Le champ WHAT

Spécifie l'entité à laquelle cette ACL s'applique. Il peut avoir les formes suivante:
dn[.‹dnstyle›]=‹dnpattern›
filter=‹ldapfilter›
attrs=‹attrlist›[ val[/matchingRule][.‹attrstyle›]=‹attrval›]

avec:
‹dnstyle›={{exact|base(object)}|regex|one(level)|sub(tree)|children}
‹attrlist›={‹attr›|[{!|@}]‹objectClass›}[,‹attrlist›]
‹attrstyle›={{exact|base(object)}|regex|one(level)|sub(tree)|children}

dn=‹dnpattern› Sélectionne les entrées basées sur leur contexte de nommage
‹dnstyle› (optionnel). Base (synonymes de baseObject) ou exact (alias de base) indique l'entrée dont le DN est égal à ‹dnpattern›. one (synonyme de onelevel) indique toutes les entrées immédiatement sous le ‹dnpattern›, sub (synonyme de subtree) indique toutes les entrées dans la sous-arborescence de ‹dnpattern›, children indique toutes les entrées subordonnées à ‹dnpattern› Si dnstyle est un regex, ‹dnpattern› est une expression étendue POSIX et match une représentation du DN.
filter=‹ldapfilter› Sélectionne les entrées basée sur un filtre LDAP
attrs=‹attrlist› sélectionne les attributs auxquels la règle s'applique. Le signe + indique l'accès à l'entrée elle-même. children indique l'accès à l'entrée de l'enfant. Les classes d'objet peuvent être spécifiés également. Les noms préfixés par '@' sont directement traités comme nom de classe d'objet. un nom préfixé par '!' et traité comme classe d'objet mais la règle affecte les attributs non requis ni permis. sans cette liste, assume attrs=@extensibleObject
attrs=‹attrlist›[ val[/matchingRule][.‹attrstyle›]=‹attrval›] Cette forme spécifie un accès à une valeur particulière d'un simple attribut. seul l'attribut est donnée.
dn, filter, attrs sont additifs. les sous-match résultant de regex peuvent être dé-référencés dans ‹who› avec la syntaxe ${v_n_} où _n_ est le numéro de sous-match.

Le champ WHO

Indique à qui la règle s'applique. Plusieurs who peuvent apparaîtrent dans l'acl. Il a la forme:
*    
anonymous
users
self[.‹selfstyle›]
    
dn[.‹dnstyle›[,‹modifier›]]=‹DN›
dnattr=‹attrname›
    
realanonymous
realusers
realself[.‹selfstyle›]
    
realdn[.‹dnstyle›[,‹modifier›]]=‹DN›
realdnattr=‹attrname›
    
group[/‹objectclass›[/‹attrname›]][.‹groupstyle›]=‹group›
peername[.‹peernamestyle›]=‹peername›
sockname[.‹style›]=‹sockname›
domain[.‹domainstyle›[,‹modifier›]]=‹domain›
sockurl[.‹style›]=‹sockurl›
set[.‹setstyle›]=‹pattern›
    
ssf=‹n›
transport_ssf=‹n›
tls_ssf=‹n›
sasl_ssf=‹n›
    
dynacl/‹name›[/‹options›][.‹dynstyle›][=‹pattern›]

avec:
‹style›={exact|regex|expand}
‹selfstyle›={level{‹n›}}
‹dnstyle›={{exact|base(object)}|regex|one(level)|sub(tree)|children|level{‹n›}}
‹groupstyle›={exact|expand}
‹peernamestyle›={‹style›|ip|ipv6|path}
‹domainstyle›={exact|regex|sub(tree)}
‹setstyle›={exact|expand}
‹modifier›={expand}
‹name›=aci ‹pattern›=‹attrname›]

Indique tout le monde
realanonymous Les mots clé préfixés par real agissent comme leur homologue non préfixés. La vérification se produit avec le DN authentification et le DN authorisation
anonymous référence les clients non authentifiés
users Références les clients authentifiés
self Référence l'entrée elle-même (l'entrée demandée et l'entrée qui requête doit correspondre). Accepte le style level{‹n›}, où _n_ indique que l'ancêtre du DN est utilisé dans le match. Une valeur positive indique que le ‹n›-ième ancêtre du DN de l'utilisateur est considéré; une valeur négative indique que le ‹n›-ième ancêtre de la cible doit être considéré. (ex: "by self.level{1} ..." matche quand l'objet "dc=example,dc=com" est accédé par cn=User,dc=example,dc=com") (ex: "by self.level{-1} ..." matche quand le même user accède à "ou=Address Book,cn=User,dc=example,dc=com"
dn=‹DN› L'accès est donnée au DN qui matche.
dnstyle (optionnel) autorise le même choix que pour WHAT. le style regex exploit la substitution de sous-match dans le dn.regex de WHAT en utilisant la forme $‹digit›, de 0 à 9 où 0 match toute la chaîne. ${‹digit›+} pour les sous-matches › 9, ${v‹digit›+} pour la substitution de chaîne de valeur d'attributs. le $ de fin de chaîne doit être spécifié par '$$'

access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$" by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$" by dn.exact,expand="uid=$2,dc=example,dc=com" write
access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$" by dn.exact,expand="uid=$2,dc=$3,dc=com" write

level{n} est une extension de la forme onelevel, où l'ancêtre n est le pattern. Donc level{1} est équivalent à onelevel et level{0} vaut base
dnattr=‹attrname› L'accès est donné aux requêtes dont le DN est listé dans l'entrée accédée sous l'attribut ‹attrname›
group=‹group› L'accès est donné aux requêtes dont le DN est listé dans l'entrée group dont le DN est donné par ‹group› ‹objectclass› et ‹attrname› donnent la classe objet et l'attribut des membres.(défaut: groupOfNames et member). ‹style› peut être expand qui signifie que ‹group› sera étendu comme remplacement (mais non comme expression régulière), et exact, qui signifie que le match exacte sera utilisé. Pour des groupes statiques, le type d'attribut spécifié doit avoir la syntaxe DN ou NameAndOptionalUID. pour les groupes dynamiques, le type d'attribut doit être un sous-type de labeledURI
peername=‹peername› L'IP de l'hôte contactant (sous la forme IP=‹ip›:‹port› ou IP=[‹ipv6›]:‹port›) ou le nom de l'hôte contactant (PATH=‹path›)
sockname=‹sockname› Le nom du fichier de pipe nommé
domain=‹domain› Le nom d'hôte du contactant
sockurl=‹sockurl› l'URL du contactant, sont comparés avec le pattern pour déterminer l'accès. Le style décrit pour group et regex s'appliquent. Le cas spécial pour ip: ‹peername›=‹ip›[%‹mask›][{‹n›}] où n est le nom du port optionnel (ex: peername.ip=192.168.1.16%255.255.255.240{9009}). (ex: domain.subtree=example.com match www.example.com)
set=‹pattern›
dynacl/‹name›[/‹options›][.‹dynstyle›][=‹pattern›] Indique que la vérification de l'accès est déléguée à une méthode définies indiquée par ‹name›, qui peut être enregistrée en temps réel au moyen de déclarations moduleload. ‹options›, ‹dynstyle› et ‹pattern› sont optionnels et sont passés directement à la routine de parsing enregistrée
dynacl/aci[=‹attrname›] Signifie que le contrôle d'accès est déterminé par les valeurs dans attrnames de l'entrée elle-même. ‹attrname› indique quel type d'attribut maintient l'ACI dans l'entrée. Par défaut, OpenLDAPaci est utilisé
ssf=‹n›
transport_ssf=‹n›
tls_ssf=‹n›
sasl_ssf=‹n› Définissent le SSF minimum pour obtenir l'accès

Le champ ACCESS

Optionnel. Détermine le niveau d'accès ou le privilège que who aura. Il a la forme:
‹access› ::= [[real]self]{‹level›|‹priv›}
où:
‹level› ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
‹priv› ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+

self Permet des opération spéciales pour le DN autorisé
realself Réfère au DN authentifié
level ce modèle d'accès s'assure d'une interprétation incrémentale des privilèges. Les niveaux possibles sont none (aucun accès, disclose ( divulgation d'information en cas d'erreur), auth (permettre l'authentification), compare, search, read, write (add+delete) et manage (inclus des accès administratifs).
priv le modèle d'accès priv se base sur des paramètres explicites de privilèges pour chaque clause. = réinitialise les accès définis précédemment, + et - ajoute/supprime des privilèges. m (manage), w (write), a (add), z (delete), r (read), s (search), c (compare), x (authentification), d (disclose), 0 ( aucun privilège) (défaut: +0)

Le champ Control

   Optionnel. Contrôle le flux de règles d'accès. Peut être:

stop Stop en cas de match
continue Permet à d'autres clause ‹who› dans le même ‹access› d'être considérés
break Permet à d'autres clauses ‹access› qui matchent la même cible d'être traités

exemple break:
access to dn.subtree="dc=example,dc=com" attrs=cn by * =cs break
access to dn.subtree="ou=People,dc=example,dc=com" by * +r
exemple continue:
access to dn.subtree="dc=example,dc=com" attrs=cn by * =cs continue by users +r

Scopes

base correspond seulement à l'entrée avec le DN fournit
one correspond aux entrées dont le parent est le DN fournit
subtree correspond à toutes les entrées dans l'arbre dont le root est le DN fournit
children correspond à toutes les entrées sous le DN (mais pas l'entrée nommée par le DN)

Par exemple, si l'annuaire contient les entrées nommées :
o=suffix
cn=Manager,o=suffix
ou=people,o=suffix
uid=kdz,ou=people,o=suffix
cn=addresses,uid=kdz,ou=people,o=suffix
uid=hyc,ou=people,o=suffix

alors:
dn.base="ou=people,o=suffix" match 2 ;
dn.one="ou=people,o=suffix match 3, and 5 ;
dn.subtree="ou=people,o=suffix match 2, 3, 4, and 5 ; and
dn.children="ou=people,o=suffix match 3, 4, and 5.

cibles


*__________________________All, including anonymous and authenticated users
anonymous__________________Anonymous (non-authenticated) users
users______________________Authenticated users
self_______________________User associated with target entry
dn[.‹basic-style›]=‹regex›_Users matching a regular expression
dn.‹scope-style›=‹DN›______Users within scope of a DN

Correspondance des droits

Level_____Privileges______Description
none______0_______________no access
disclose__d_______________needed for information disclosure on error
auth______dx______________needed to authenticate (bind)
compare___cdx_____________needed to compare
search____scdx____________needed to apply search filters
read______rscdx___________needed to read search results
write_____wrscdx__________needed to modify/rename
manage____mwrscdx_________needed to manage

Opérations requises

   Les opérations nécessitent différents privilèges sur différentes portions d'entrées.

add nécessite le privilège add sur le pseudo-attribut de l'entrée à ajouter, et add sur le pseudo-attribut children du parent de l'entrée.
bind quand les accréditifs sont stockés dans l'annuaire, nécessite les privilèges auth sur l'attribut où sont stockés ces accréditifs.
Compare nécessite compare sur l'attribut à comparer
delete nécessite delete sur le pseudo-attribut de l'entrée à supprimer et sur le pseudo-attribut children du parent de l'entrée
modify nécessite write (add pour ajouter, delete pour supprimer, les 2 pour modifier)
modrdn nécessite write sur le pseudo-attribut de l'entrée à supprimer, delete sur le pseudo-attribut Children de l'ancien parent de l'entrée, et add sur le pseudo-attribut Children du nouveau parent de l'entrée. delete est aussi requis sur les attributs qui sont présent dans l'ancien RDN si deleteoldrdn et à 1.
search nécessite search sur le pseudo-attribut entry du searchBase. Les entrées résultantes sont ensuite testé sur read sur le pseudo-attribut entry et sur chaque valeurs de chaque attribut demandé pour chaque referral utilisé pour générer des références continues, read sur le pseudo-attribut entry et les attributs du referral.
authzID, proxyAuthz necessitent auth sur tous les attributs présents dans la recherche et sur authzTo et/ou authzFrom de l'identité autorisant.

Exemples

Pour matcher la sous-arborescence désirée, la règle serait:
access to dn.regex="^(.+,)?dc=example,dc=com$" by ...
Pour des raisons de performance, il est mieux d'écrire:
access to dn.subtree="dc=example,dc=com" by ...
En écrivant des règles submatch, il peut être préférable d'éviter l'utilisation de ‹dnstyle›:
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
by dn.regex="^uid=$2,dc=example,dc=com$$" write
by ...
Cependant, c'est plus efficace:
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
by dn.exact,expand="uid=$2,dc=example,dc=com" write
by ...
^
19 octobre 2013

htmlpdflatexmanmd




slapd-bdb

slapd-bdb, slapd-hdb

Backend bdb,hdb

   S'appuie sur Oracle Berkeley DB. Il utilise intensivement le cache et l'indexation pour accélérer l'accès aux données. hdb est une variante de bdb qui utilise une base de données hiérarchique avec le support de renommage des sous-arborescences Il est plus rapide et nécessite moins d'espace pour stocker les données.

Configuration

   Ces options sont prévues pour complémenter le jeu d'options dans le fichier d'environnement DB_CONFIG

cachesize _integer_ Spécifie la taille du cache d'entrée en mémoire (défaut : 100 entrées)
cachefree _integer_ Spécifie le nombre d'entrées à libérer du cache quand la limite est atteinte (défaut 1)
checkpoint _kbyte_ _min_ Spécifie la fréquence de vérification des log transactionnels de la base. cette opération vide les tampons sur disques et écrit un enregistrement de checkpoint dans les logs Il se produit si _kbyte_ données on été écrits ou _min_ minutes se sont écoulés
checksum Active la validation de checksum des pages quand elles sont lues depuis le disque. Peut seulement être configuré avant la création des fichiers de la base
cryptfile _file_ Spécifie le chemin d'un fichier contenant la clé de chiffrement à utiliser
cryptkey _key_ Spécifie une clé de chiffrement à utiliser (si cryptfile _file_ n'est pas désiré)
dbconfig _Berkeley-DB-setting_ Spécifie une directive de configuration à placer dans le fichier DB_CONFIG de l'annuaire (ex: dbconfig set_cachesize 0 1048576 0, dbconfig set_lg_bsize 2097152 )
dbnosync Spécifie que le contenue de la base sur disque ne devrait pas être synchronisé immédiatement avec les changement en mémoire.
dbpagesize _dbfile_ _size_ Spécifie la taille de page à utiliser pour un fichier de base particulier en unité de 1024bits. défault pour id2entry est 16, pour les autres 4 ou 8. (max : 64)
directory _directory_ Spécifie le répertoire où réside les fichiers de la base et les index associés
dirtyread Permet la lecture des données modifiée mais non committed.
dncachesize _integer_ Spécifie le nombre max de DN en mémoire
idlcachesize _integer_ Spécifie la taille d'index en mémoire, en slot d'index
index {_attrlist_|default} [pres,eq,approx,sub,_special_] Spécifie les index à maintenir en mémoire pour certains attributs
linearindex Dit à slapindex d'indexer un attribut à la fois. Améliore les performances quand la base dépasse dbcache.
lockdetect {oldest|youngest|fewest|random|default} Spécifie quelle transaction annuler quand un deadlock est détecté (défaut : random)
mode _integer_ Spécifie le mode de protection des fichiers d'index nouvellement créés (défaut : 0600)
searchstack _depth_ Spécifie la profondeur de la pile utilisé pour les filtres de recherche. Chaque pile utilise 512 Ko. La pile par défaut est 16, donc 8Mo par thread.
shm_key _integer_ Spécifie une clé pour un environnement BDB à mémoire partagée.
^
22 septembre 2013

htmlpdflatexmanmd




slapd-config

slapd-config

Backend de configuration de slapd

Options de configuration globale

   Ces options sont spécifiées dans l'entrée cn=config. Elle doit avoir un objectClass olcGlobal.

cn =config
olcAllows Spécifie un jeu de fonctionnalités à autoriser. bind_anon_cred permet un bind anonyme quand les crédentials ne sont pas vide, bind_anon_dn permet un bind non-authentifié quand le DN n'est pas vide et proxy_authz_anon permet un contrôle d'autorisation proxy non-authentifié
olcArgsFile Chemin d'un fichier qui maintient la ligne de commande du serveur slapd
olcAttributeOptions Définis le tagging d'options d'attributs ou des préfixes tag/range. un préfixe se termine par '-'.
olcAuthIDRewrite Utilisé par le framework d'authentification pour convertir un simple nom en DN utilisé pour l'autorisation. Son but est analogue à olcAuthzRegexp. Ce jeu de règle est analogue à ceux décrit dans slapo-rwm
olcAuthzPolicy Spécifie quelles règles utiliser pour l'autorisation proxy. none désactive, from utilise les règles dans authzFrom, to utilise celles dans authzTo, any, et all (toutes les autorisations doivent réussir)
olcAuthzRegexp Utilisé par le framework d'authentification pour convertir un simple nom en DN utilisé pour l'autorisation.
olcConcurrency Spécifie un niveau de concurrence.
olcConnMaxPending Nombre maximum de requêtes en attente pour une session anonyme
olcConnMaxPendingAuth Spécifie le nombre maximum de requêtes en attente pour une session authentifiée.
olcDisallows Spécifie un jeu de fonctionnalités à désactiver. bind_anon n'accèpte plus les requêtes bind anonymes. bind_simple désactive le simple bind. tls_2_anon désactive les sessions forcées en status anonyme une fois l'opération StartTLS reçue. tls_authc désactive es opérations StartTLS si authentifié.
olcGentleHUP a TRUE, SIGHUP ne fait qu'une tentative d'arrêt. slapd n'accèpte plus les nouvelle connexions, mais attend que les connexions en cours se terminent.
olcIdleTimeout Nombre de secondes avant de fermer une session client non active. ( 0 désactive)
olcIndexIntLen Longueur de clé pour les indices entier ordonnés. Le MSB d'un binaire entier sera utilisé pour indexer les clés.
olcIndexSubstrIfMaxLen Longueur max des indices subinitial et subfinal.
olcIndexSubstrIfMinLen Longueur mini des indices subinitial et subfinal. Une valeur d'attribut doit avoir au moins cette longueur pour être traitée
olcIndexSubstrAnyLen Longueur utilisée pour les indices subany. Une valeur d'attribut doit avoir au moins cette longueur pour être traitée. est utilisé pour les indices subinitial et subfinal quand le filtre est supérieur à olcIndexSubstrIfMaxlen
olcIndexSubstrAnyStep Spécifie les étapes utilisée dans les recherchée d'index subany. définis l'offset pour les segments d'une chaîne de recherche
olcListenerThreads Spécifie le nombre de threads à utiliser pour le gestionnaire de connexion
olcLocalSSF Spécifie le Security Strength Factor (SSF) pour les sessions LDAP locales.
olcLogFile Fichier où enregistrer les logs
olcLogLevel Niveau de log
olcPasswordCryptSaltFormat Spécifie le format du salt passé à crypt(3) en générant les mots de passe {CRYPT}. Doit être au format sprintf(3) et peut inclure une conversion %s
olcPidFile Chemin absolu du fichier PID
olcPluginLogFile Chemin absolu d'un fichier contenant les logs pour le plugin SLAPI
olcReferral Spécifie les referrals à passer quand slapd ne peut pas trouver une base à utiliser pour une requête
olcReverseLookup Active/désactive la recherche inversée d'un nom de client
olcRootDSE Nom d'un fichier ldif contenant les attributs utilisateur pour le root DSE
olcSaslAuxprops Spécifie quels plugins auxprop utiliser pour les recherches d'authentification.
olcSaslHost fqdn utilisé pour le traitement SASL
olcSaslRealm Royaume SASL
olcSaslSecProps Spécifie les propriétés de sécurité pour cyrus SASL. none efface les flags "noanonymous,noplain". noplain désactive les mécanismes sujets à attaques passives. noactive désactive les mécanismes sujet à attaques actives. nodict désactive les mécanismes sujets à attaque passive par dictionnaire. noanonymous désactive le support des login anonymes. forwardsec nécessite un renvoie de secret entre les sessions. passcred nécessite un mécanisme qui passe les crédentials clients. minssf=‹factor› spécifie le SSF minimum acceptable. maxssf=‹factor› spécifie le SSF maximum acceptable. maxbufsize=‹size› spécifie la taille de tampon max.
olcServerID Spécifie un ID de 0 à 4096 pour ce serveur.
olcSockbufMaxIncoming Taille de PDU LDAP maximum entrante pour les sessions anonymes.
olcSockbufMaxIncomingAuth Taille de PDU LDAP maximum entrante pour les sessions authentifiées.
olcTCPBuffer Taille du tampon TCP. Une valeur globale est définie, et des valeur pour la lecture et l'écriture peuvent être spécifiés
olcThreads Taille maximum du pool de thread primaire.
olcToolThreads Nombre de thread maximum à utiliser en mode tool. ne devrait pas être supérieur au nombre de CPU.
olcWriteTimeout Nombre de secondes à attendre avant de fermer une connexion avec une écriture en cours. permet une récupération face à divers problèmes réseau

Options TLS

olcTLSCipherSuite Permet de configurer les chiffrement acceptés et l'ordre de préférence.
olcTLSCACertificateFile Fichier contenant les certificats pour toutes les CA que slapd reconnaît
olcTLSCACertificatePath Chemin d'un répertoire contenant les certificats CA
olcTLSCertificateFile Fichier contenant le certificat du server ldap
olcTLSCertificateKeyFile Fichier contenant la clé privée du serveur ldap
olcTLSDHParamFile Spécifie le fichier contenant les paramètres pour les échanges de clé Diffie-Hellman. "!AH" devrait être ajouté à la suite de chiffrements si des chiffrements sont spécifiés et utilisent les échanges de clé DH anonymes.
olcTLSRandFile Fichier pour obtenir des données aléatoires quand /dev/urandom n'est pas disponible
olcTLSVerifyClient Spécifie quelle vérification exécuter sur les certificats clients. never ne demande pas de certificat, allow nécessite un certificat. try le certificat est demandé, mais non obligatoire. demand|hard|true sont équivalent
olcTLSCRLCheck Spécifie si la CRL doit être utilisée pour vérifier les certificats clients. none ne vérifie pas la CRL. peer vérifie dans la CRL. all vérifie toute la chaîne dans le CRL.
olcTLSCRLFile Spécifie le fichier contenant la CRL à vérifier

Options de modules dynamique

   Chaque module a une entrée nommée cn=module{x},cn=config

olcModuleLoad Spécifie le nom d'un module dynamique
olcModulePath Spécifie une liste de répertoires où chercher les modules.

Options de schéma

   Les définitions de schéma sont créées en tant qu'entrée dans cn=schema,cn=config

olcAttributeTypes Spécifie une type d'attribut utilisant la syntaxe LDAPv3
olcDitContentRules Spécifie un DIT Content Rule utilisant la syntaxe LDAPv3
olcObjectClasses Spécifie une classe d'objet en utilisant la syntaxe LDAPv3
olcObjectIdentifier Définis une nom équivalent à l'OID donné

Options général de backend

   Chaque backend est définies dans une entrée nommée: olcBackend=‹databasetype›,cn=config

Options de base de données

   Les options de base de données sont définies dans des entrées nommées olcDatabase={x}‹databasetype›,cn=config. La base frontend spéciale est toujours numérotée {-1} et la base de configuration est toujours numérotée {0}

   Ces options peuvent être définies dans le frontend et doivent avoir l'objet olcFrontEndConfig

olcAccess Définis l'accès à une base de données
olcDefaultSearchBase Spécifie le dn de bas de recherche par défaut à utiliser quand les clients ne spécifient pas de base de recherche
olcExtraAttrs Liste les attributs devant être ajoutés aux requêtes de recherche. Les backend locaux retournent toute l'entrée, le frontend ne retourne que celles autorisées par les ACL.
olcPasswordHash Configure les hash à utiliser lors de la génération de mots de passe dans l'attribut userPassword. {SSHA}, {SHA}, {MD5}, {SMD5}, {CRYPT}, {CLEARTEXT}
olcReadOnly Place la base de donnée en lecture seule
olcRequires Spécifie un jeu de conditions requis. Peut être spécifié globalement et/ou par base de données (additive). authc nécessite une authentification avant toute opération, SASL nécessite une authentification SASL, strong nécessite une authentification forte. none ne spécifie aucune condition
olcRestrict Spécifie une liste d'opérations interdites. Peut être spécifié globalement et/ou par base de données (superseed). add, bind, compare, delete, extended[=‹OID›], modify, rename, search, read, write
olcSchemaDN Spécifie le DN de la sous-entrée du sous-schéma qui contrôle les entrées sur ce serveur.
olcSecurity Spécifie un jeu de SSF. Peut être spécifié globalement et/ou par base de données. ssf=‹n› Spécifie le SSF général. transport=‹cn› spécifie le transport SSF. tls=‹n› spécifie le TLS SSF. update_ssf=‹n› spécifie le SSF général pour les updates. update_transport=‹n› spécifie le transport SSF pour les updates. update_tls=‹n› spécifie les TSL SSF pour les updates. update_sasl=‹n› spécifie le SASL SSF pour les updates. simple_bind=‹n› requière une authentification simple
olcSizeLimit Spécifie le nombre maximum d'entrées à retourner lors d'une recherche.
olcSortVals Spécifie une liste d'attributs multi-valués qui seront toujours maintenus en ordre trié. Permet aux opération modify, compare et aux filtres d'évaluation d'être traités plus efficacement. frontend only.
olcTimeLimit Spécifie le temps maximum en secondes pour une réponse à une recherche

Options de base de données générales

olcAddContentAcl Contrôle si les opérations Add vont effectuer une vérification d'ACL sur le contenu de l'entrée ajoutée.
olcHidden Contrôle si la base sera utilisée pour répondre aux requêtes
olcLastMod Contrôle si slapd maintient automatiquement les attributs modifiersName, modifyTimestamp, creatorsName, et createTimestamp pour les entrées. Contrôle aussi entryCSN et entryUUID
olcLimits Spécifie les limites de temps et de taille basé sur l'initiateur de l'opération ou base DN.
olcMaxDerefDepth Nombre maximum d'aliase à déréférencer en essayant de résoudre une entrée.
olcMirrorMode à TRUE, place un réplica de base en mode mirroir. les updates sont accèptées par tout utilisateur. La base doit être en syncrepl
olcPlugin Configure le plugin SLAPI
olcRootDN Spécifie le DN qui n'est pas sujet à contrôle d'accès ou restrictions administratives
olcRootPW Mot de pas du RootDN
olcSubordinate Spécifie que le backend est subordonné à un autre backend. une base subordonnée peut avoir une seul suffix. Utile pour accoler plusieurs suffix dans un simple contexte de nommage. TRUE, FALSE, advertise (si spécifié, le contexte de nommage de cette base est indiquée dans le rootDSE)
olcSuffix Spécifie le suffix DN des requêtes passée au backend
olcSyncUseSubentry Stocke le contextCSN syncrepl dans une sous-entrée au lieu de l'entrée context de la base
olcSyncrepl Spécifie la base courante comme réplica d'un contenu master
olcUpdateDN applicable uniquement pour les base esclaves. Spécifie le DN autorisé à updater la base
olcUpdateRef Spécifie les référants à passer quand slapd reçoit le demande de modifier une base local répliquée.

Overlays

   Un overlay est une code qui intercepte les opérations de la base dans le but de les étendre ou les changer. Les overlays doivent être configurés comme entrées enfant d'une base spécifique le RDN de l'entrée doit avoir l'objectClass olcOverlayConfig

Exemple

L'exemple suivant, s'il est copié dans le fichier config.ldif, la commande suivante va initialiser la configuration:
slapadd -F /usr/local/etc/openldap/slapd.d -n 0 -l config.ldif


dn: cn=config
objectClass: olcGlobal
cn: config
olcPidFile: /usr/local/var/run/slapd.pid
olcAttributeOptions: x-hidden lang-
    
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
    
include: file:///usr/local/etc/openldap/schema/core.ldif
    
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
# Subtypes of "name" (e.g. "cn" and "ou") with the
# option ";x-hidden" can be searched for/compared,
# but are not shown. See slapd.access(5).
olcAccess: to attrs=name;x-hidden by    *    =cs
# Protect passwords. See slapd.access(5).
olcAccess: to attrs=userPassword by    *    auth
# Read access to other attributes and entries.
olcAccess: to    *    by    *    read
    
# set a rootpw for the config database so we can bind.
# deny access to everyone else.
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
olcAccess: to    *    by    *    none
    
dn: olcDatabase=bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: bdb
olcSuffix: "dc=our-domain,dc=com"
# The database directory MUST exist prior to
# running slapd AND should only be accessible
# by the slapd/tools. Mode 0700 recommended.
olcDbDirectory: /usr/local/var/openldap-data
# Indices to maintain
olcDbIndex: objectClass eq
olcDbIndex: cn,sn,mail pres,eq,approx,sub
    
# We serve small clients that do not handle referrals,
# so handle remote lookups on their behalf.
dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLdapConfig
olcDatabase: ldap
olcSuffix: ""
olcDbUri: ldap://ldap.some-server.com/

Limite de taille et de temps


olcLimits: ‹selector› ‹limit› [‹limit› [...]]
selector: anonymous|users|[‹dnspec›=]‹pattern›|group[/oc[/at]]=‹pattern›
‹dnspec› ::= dn[.‹type›][.‹style›]
‹type› ::= self | this
‹style› ::= exact | base | onelevel | subtree | children | regex | anonymous

unchecked définie une limite sur le nombre de candidats qu'une recherche est autorisé à examiner
size[.{soft|hard|unchecked}]=‹integer›
Contrôle pageResult total permis de retourner:
size.prtotal={‹integer›|unlimited|disabled}
contrôle pageResult:
size.pr={‹integer›|noEstimate|unlimited}

integer Taille de page maximum si aucune limite explicite n'est définies.
noEstimate ne retourne pas d'estimation du nombre d'entrée qui peuvent être retournées

olcSyncrepl

   olcSyncrepl: rid=‹replicaID› provider=ldap[s]://‹hostname›[:port] searchbase=‹baseDN› [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[‹retry interval› ‹# of retries›]+] [filter=‹filterstr›] [scope=sub|one|base|subord] [attrs=‹attrlist›] [exattrs=‹attrlist›] [attrsonly] [sizelimit=‹limit›] [timelimit=‹limit›] [schemachecking=on|off] [network-timeout=‹seconds›] [timeout=‹seconds›] [bindmethod=simple|sasl] [binddn=‹dn›] [saslmech=‹mech›] [authcid=‹identity›] [authzid=‹identity›] [credentials=‹passwd›] [realm=‹realm›] [secprops=‹properties›] [keepalive=‹idle›:‹probes›:‹interval›] [starttls=yes|critical] [tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›] [tls_reqcert=never|allow|try|demand] [tls_ciphersuite=‹ciphers›] [tls_crlcheck=none|peer|all] [suffixmassage=‹real DN›] [logbase=‹base DN›] [logfilter=‹filterstr›] [syncdata=default|accesslog|changelog]

rid ID qui identifie la directive syncrepl dans le site de réplication.
provider Spécifie le fournisseur de réplication contenant le contenu master
searchbase, scope, filter, attrs, attrsonly, sizelimit, timelimit servent de spécification pour filtrer le contenu du réplica
refreshOnly la prochaine opération de recherche de synchronisation est re-planifiée à intervalle définis par interval.
refreshAndPersist la synchronisation est persistante
retry Si la connexion est perdue, retente avec des pair de valeur ‹retry inval› et ‹# of retries›. ex: retry"60 10 300 3". + vaut indéfinis
schemachecking Force la vérification du schéma.
network-timeout Définis le temps d'établissement d'une connexion réseau avec le fournisseur
timeout Détermine le temps que le client attend que la requête Bind initiale soit complétée
bindmethod simple, sasl
binddn DN pour un simple bind
saslmech requis pour SASL
authcid Identité et/ou crédentials pour l'authentification sasl
authzid identité d'authorisation
credentials Crédentials pour le bind
realm Royaume SASL
secprops Définis les propriétés de sécurité spécifiques
keepalive Définis les valeurs de idle (temps avant un TCP keepalive), probes (nombre max de keepalive avant de fermer la connexion) et intervalles (temps entre les keepalive)
starttls Spécifie l'utilisation de l'opération étendue StartTLS pour établir une session TLS.
tls_cert Certificat pour la connexion TLS
tls_key Clé privée
tls_cacert Fichier contenant les certificats CA
tls_cacertdir Répertoire contenant les certificats CA
tls_reqcert Spécifie si le certificat est requis
tls_ciphersuite Spécifie la suite de chiffrement et l'ordre à utiliser
tls_crlcheck Vérifie les certificat dans la CRL
suffixmassage Permet au client de pousser des entrée depuis un annuaire distant dont le suffixe DN diffère de l'annuaire local Les entrée qui matche le searchbase seront remplacé avec ce DN
logbase Fichier où écrire les logs
logfilter Filtre pour les logs
syncdata accesslog, les logs sont conforme à slapo-accesslog. changelog les logs sont conforme au format changelog (obsolète). default, les paramètres de logs sont ignorés
^
19 octobre 2013

htmlpdflatexmanmd




slapd-dnssrv

slapd-dnssrv

Backend dnssrv

   Backend servant de référant basé sur des enregistrements SRV dans le DNS. Il n’a pas de backend, ni d’option spécifique. Il n’honore aucune ACL. Il n’implément que l’opération search quand le contrôle manageDSAit est utilisé.

^
19 octobre 2013

htmlpdflatexmanmd




slapd-ldap

slapd-ldap

Backend ldap

   Ce backend n'est pas une base, il agit comme proxy pour transférer des requêtes entrantes à un autre serveur LDAP. Les référants sont pleinement traités au lieu d'être retournés au client. Les sessions qui Bind explicitement avec ce backend créent toujours leur propre connexion privée au serveur LDAP distant. Les sessions anonymes vont partager une seule connexion anonyme. Pour les sessions liées avec d'autres mécanismes, toutes les sessions avec le même DN vont partager la même connexion. Celà permet d'améliorer l'efficacité du proxy.

   La base ldap peut aussi agir comme service d'information, par ex. l'identité des clients authentifiés localement est affirmé sur le serveur distant, possiblement sous une forme modifiée. Dans ce but, le proxy bind au serveur distant avec une identité administrative, et, si requis, authorise l'identité fournie.

   L'instance proxy de slapd doit contenir le schéma pour les attributs et les classes d'object utilisé dans les requêtes. slapd doit être configuré avec le support des threads, et le paramètre threads adapté.

Configuration

uri ‹ldapurl› Serveur LDAP à utiliser. Plusieurs URI peuvent être spécifiés (ex: uri "ldap://host/ ldap://backup-host/")
acl-bind bindmethod=simple|sasl [binddn=‹simple DN›] [credentials=‹simple password›] [saslmech=‹SASLmech›]
[secprops=‹properties›] [realm=‹realm›] [authcId=‹authenticationID›] [authzId=‹authorization ID›]
[starttls=no|yes|critical] [tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›]
[tls_reqcert=never|allow|try|demand] [tls_ciphersuite=‹ciphers›] [tls_protocol_min=‹version›] [tls_crlcheck=none|peer|all] Permet de définir les paramètres de la méthode d'authentification utilisé par le proxy pour collecter les informations liées au contrôle d'accès L'identité définie par cette directive doit avoir l'accès read sur le serveur cible aux attributs utilisés sur le proxy pour la vérification des ACL.
cancel {ABANDON|ignore|exop[-discover]} Définis comment manipuler les annulations d'opérations. abandon (abandonne immédiatement l'opération), ignore (aucune action et la réponse est ignorée), exop (une opération cancel est envoyée au serveur distant), exop-discover (supporte l'opération étendue cancel)
chase-referrals {YES|no} Active/désactive le repérage de référence automatique, qui est déléguée à libldap, avec un rebind éventuel si la directive rebind-as-user est utilisée défaut : yes
conn-ttl ‹time› Force la suppression d'une connexion en cache et la recrée après le ttl donné, sans regarder s'il elle est active ou non.
idassert-authzFrom ‹authz-regexp› Sélectionne quelles identités locales sont autorisées à exploiter la fonction d'assertion d'identité
idassert-bind bindmethod=none|simple|sasl [binddn=‹simpleDN›] [credentials=‹simple password›]
[saslmech=‹SASL mech›] [secprops=‹properties›] [realm=‹realm›] [authcId=‹authenticationID›]
[authzId=‹authorization ID›] [authz=native|proxyauthz] [mode=‹mode›] [flags=‹flags›] [starttls=no|yes|critical]
[tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›] [tls_reqcert=never|allow|try|demand]
[tls_ciphersuite=‹ciphers›] [tls_protocol_min=‹version›] [tls_crlcheck=none|peer|all] Permet de définir les paramètres de la méthode d'authentification utilisée en interne par le proxy pour autoriser les connexions qui sont authentifiées par d'autres bases de données. L'identité définie doit avoir l'accès auth sur le serveur cible sur les attributs utilisés et doit avoir le droit d'authoriser d'autres users (proxyAuth sur tout le DN, ex: authzTo=dn.subtree:"") et le serveur distant doit avoir authz-policy mis à to ou both.
‹mode› := {legacy|anonymous|none|self} legacy implique que le proxy va effectuer un simple bind (authcDN) ou SASL (authcID) et assert l'identité du client quand il n'est pas anonyme. Anonymous et self, assert une chaîne vide ou l'identité du client, respectivement.
‹flag› := {override|[non-]prescriptive|proxy-authz-[non-]critical} override, l'assertion de l'identité prend place même quand la base est autorisée pour l'identité du client. Quand prescriptive est utilisé, les opérations échouent avec inappropriateAuthentication pour les identités dont l'assertion n'est pas permise par le motif idassert-authzFrom. non-prescriptive, les opérations sont effectuées anonymement pour les identités dont l'assertion n'est pas permise par le pattern idassert-authzFrom. proxy-authz-non-critical, le contrôle proxyAuthz contrôle n'est pas marqué comme critique, en violation de la RFC 4370. il est recommandé d'utiliser proxy-authz-critical
idassert-passthru ‹authz-regexp› Si définis, sélectionne quelle identité local bypasse l'assertion d'identité. ces identités doivent être connues par l'hôte distant. la chaîne authz-regexp suit les règles définies pour authzFrom
idle-timeout ‹time› Force une connexion en cache à être supprimée puis recrée après une timeout
keepalive ‹idle›:‹probes›:‹interval› Définis les valeurs de idle, probes et interval utilisés pour certifier si un socket est actif. idle est le nombre de secondes avant qu'une connexion non-active reçoive un keepalive. probes et le nombre maximum de keepalive, et interval est le nombre de seconde entre chaque keepalive.
network-timeout ‹time› Définis la valeur timeout réseau après que poll(2)/select(2) suivant un retour connect(2) en cas d'inactivité, en seconde
norefs ‹NO|yes› à yes, ne retourne pas de réponse de référence de recherche. (défaut : NO, sauf si LDAPv2)
noundeffilter ‹NO|yes› à yes, retourne success au lieu de rechercher si un filtre est indéfinis ou contient des portions indéfinies. Par défaut, la recherche est propagée après avoir remplacé les portions indéfinies avec (!(objectClass=*)), qui correspond à un résultat vide.
onerr {CONTINUE|stop} Permet de sélectionner le mode en cas d'erreur retourné par le serveur distant durant une recherche. à Continue, retourne un success. à stop, l'erreur est retournée au client.
protocol-version {0,2,3} Indique quel protocole utiliser pour contacter le serveur distant (0, le protocole utilisé est le même que celui utilisé par le client)
proxy-whoami NO|yes Active le proxy de l'opération WhoAmI, back-ldap va remplacer la routine whoami de slapd avec le sien.
quarantine ‹interval›,‹num›[ ;‹interval›,‹num›[...]] Met en quarantaine les URI qui ont retourné LDAP_UNAVAILABLE. retente seulement à interval seconde depuis la dernière tentative, pour exactement num fois ; puis utilise le prochain pattern. si num vaut +, retente indéfiniment.
rebind-as-user {NO|yes} à yes, les crédential du client sont mémorisés pour rebind, en tentant de re-établir une connexion perdue, ou lors de la poursuite d'aiguillage si chase-referrals est à yes.
session-tracking-request {NO|yes} Ajoute un contrôle de traçage de session pour toutes les requêtes. l'IP/hostname du client et l'identité associée à chaque requête sont envoyés au serveur distant pour information. Est incompatible avec protocol-version 2.
single-conn {NO|yes} Annule toute connexion en cache si le client se rebind
t-f-support {NO|yes|discover} Active le support des filtres absolus des serveurs distant (RFC4526).
timeout [‹op›=]‹val› [...] Permet de définir des timeouts par opération. ‹op› ::= bind, add, delete, modrdn, modify, compare, search
tls {[try-]start|[try-]propagate|ldaps} [tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›]
[tls_reqcert=never|allow|try|demand] [tls_ciphersuite=‹ciphers›] [tls_crlcheck=none|peer|all] Spécifie l'utilisation de TLS pour l'initialisation des connexions.
use-temporary-conn NO|yes Créé une connexion temporaire en compétition avec d'autres threads pour une connexion partagée. Sinon, attent jusqu'à ce qu'une connexion partagée soit disponible.
^
19 octobre 2013

htmlpdflatexmanmd




slapd-ldif

slapd-ldif

Backend ldif

   Le backend LDIF est un backend basique qui stocke les entrées dans un fichier texte ldif, et exploite le système de fichier pour créer la structure de l’arborescence de la base de données.

Configuration

directory ‹dir› le Répertoire où placer la base de données. Le répertoire doit exister

ACL

   ce backend n’honore aucune acl. Seul read est honoré
^
19 octobre 2013

htmlpdflatexmanmd




slapd-mdb

slapd-mdb

Backend mdb

   Lightning Memory-Mapped DB est similaire au backend hdb.

Configuration

checkpoint _kbyte_ _min_ Spécifie la fréquence pour vider les tampons disque de la db.
dbnosync Spécifie que le contenu sur disque de la db ne devrait pas être immédiatement synchronisé avec les changements en mémoire
directory _directory_ Spécifie le répertoire où placer la db
envflags {nosync,nometasync,writemap,mapasync} Spécifie les flags opératoire:

        nosync idem à dbnosync
        nometasync Vide les données sur envoie, mais saute la synchro des page meta. légèrement plus rapide qu’un full sync
        writemap Utilise un map mémoire en écriture. accélère les opérations d’écriture, mais rend la base vulnérable aux corruptions
        mapasync En utilisant une map mémoire en écriture et en effectuant un flush sur chaque envoie, utilise un flush asynchrone

index {_attrlist_|default} [pres,eq,approx,sub,_special_] Spécifie les index à maintenir pour les attributs donnés
maxreaders _integer_ Spécifie le nombre maximum de threads concurrent en lecture sur la db. (défaut : 126)
maxsize _bytes_ Taille max de la db en octets. (défaut 10485760). Peut être augmenté ultérieurement
mode _integer_ Spécifie le mode de protect des fichiers (défaut : 0600)
searchstack _depth_ Spécifie la profindeur de la pile utiliséepour les évaluations de filtre de recherche, 512Ko par niveau. (défaut : 16, soit 8Mo par thread)
^
20 octobre 2013

htmlpdflatexmanmd




slapd-meta

slapd-meta

Backend meta

   Effectue un proxy LDAP en respectant un jeu de serveurs LDAP distant, appelés target. Les informations contenues par ces serveurs peuvent être présentés comme appartenant à un simple DIT. Il a été conçu comme un amélioration de slapd-ldap. Ces 2 backends partagent de nombreuses fonctionnalités. L'instance proxy doit contenir le schéma pour les attributs et objectClass utilisés dans les filtres. Il doit également avoir le schéma pour les données retournées par les serveurs proxifiés

Directives de configuration spécial

conn-ttl ‹time› Force la suppression d'une connexion en cache et la recrée après le ttl donné, sans regarder s'il elle est active ou non.
default-target none Force le backend à rejeter toutes les opérations qui doivent être résolues à un simple target dans le cas ou aucun ou plusieurs target sont sélectionnés. Cette directive permet également de marquer un target spécifique comme défaut.
dncache-ttl {DISABLED|forever|‹ttl›} Définis le TTL du cache de DN. (0 désactive le cache)
onerr {CONTINUE|report|stop} Mode en cas d'erreur retournée par une target durant un recherche. Continue, continue la recherche et tente de retourner le plus de données possible. Stop, stop la recherche et retourne une erreur. report, la recherche se poursuit mais si une target retourne une erreur, le premier code d'erreur retourné est envoyé au client.
norefs ‹NO|yes› à yes, ne retourne pas de référence de recherche
noundeffilter ‹NO|yes› à yes, retourne success au lieu de rechercher si un filtre est indéfinis ou contient des portions indéfinies. Par défaut, la recherche est propagée après avoir remplacée les portions indéfinies avec (!(objectClass=*)), qui correspond à un résultat vide.
protocol-version {0,2,3} Indique quel protocole utiliser pour contacter le serveur distant (0, le protocole utilisé est le même que celui utilisé par le client)
pseudoroot-bind-defer {YES|no} à yes, l'authentification sur le serveur distant avec une identité pseudo-root (idassert-bind) est déférée jusqu'à ce qu'il soit nécessaire. Sinon, tous les binds root sont propagés aux target.
quarantine ‹interval›,‹num›[ ;‹interval›,‹num›[...]] Met en quarantaine les URI qui ont retourné LDAP_UNAVAILABLE. retente seulement à interval seconde depuis la dernière tentative, pour exactement num fois ; puis utilise le prochain pattern. si num vaut +, retente indéfiniment.
rebind-as-user {NO|yes} à yes, les crédentials du client sont mémorisés pour rebind, en tentant de re-établir une connexion perdue, ou lors de la poursuite d'aiguillage si chase-referrals est à yes.
session-tracking-request {NO|yes} Ajoute un contrôle de traçage de session pour toutes les requêtes. l'IP/hostname du client et l'identité associée à chaque requête sont envoyés au serveur distant pour information. Est incompatible avec protocol-version 2.
single-conn {NO|yes} Annule toute connexion en cache si le client se rebind
use-temporary-conn {NO|yes} Créé une connexion temporaire en compétition avec d'autres threads pour une connexion partagée. Sinon, attend jusqu'à ce qu'une connexion partagée soit disponible.

Spécification de target

uri ‹protocol›://[‹host›]/‹naming context› [...] naming context est mandatoire pour la première uri, et omis pour les autres
acl-authcDN ‹administrative DN for access control purposes› DN utilisé pour requêter le serveur distant pour vérifier les ACL. Doit avoir les accès read sur le serveur cible sur les attributs utilisés dans le proxy pour la vérification des acl.
acl-passwd ‹password› Mot de passe utilisé avec acl-authcDN
bind-timeout ‹microseconds› Timeout en micro-secondes, utilisé lors du vote pour la réponse après une connexion bind asynchrone. L'appel initial à ldap_result(3) est effectué avec un timeout de 100000us. Si le résultat excède ce timeout, les appels suivants utilisent la valeur de bind-timeout.
chase-referrals YES|no Active/désactive le repérage de référence automatique, qui est déléguée à libldap, avec un rebinding éventuel si la directive rebind-as-user est utilisée. défaut: yes
client-pr {accept-unsolicited|DISABLE|‹size›} Permet d'utiliser le contrôle paged result en requêtant un target. Le client n'est pas soumis à ce contrôle.
default-target [‹target›] Sans argument, indique que le target courant est le défaut. target est un numéro du target par défaut.
filter ‹pattern› regex pour indiquer quels termes de filtre de recherche sont servis par le target.
idassert-authzFrom ‹authz-regexp› Sélectionne quels identités local sont autorisées à exploiter la fonctionnalité d'assertion d'identité. l'expressions suit la règle définis pour authzFrom
idassert-bind bindmethod=none|simple|sasl [binddn=‹simpleDN›] [credentials=‹simple password›]
[saslmech=‹SASL mech›] [secprops=‹properties›] [realm=‹realm›] [authcId=‹authenticationID›]
[authzId=‹authorization ID›] [authz=native|proxyauthz] [mode=‹mode›] [flags=‹flags›] [starttls=no|yes|critical]
[tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›] [tls_reqcert=never|allow|try|demand]
[tls_ciphersuite=‹ciphers›] [tls_protocol_min=‹version›] [tls_crlcheck=none|peer|all] Permet de définir les paramètres de la méthode d'authentification utilisée en interne par le proxy pour autoriser les connexions qui sont authentifiées par d'autres bases de données. L'identité définie doit avoir l'accès auth sur le serveur cible sur les attributs utilisés et doit avoir le droit d'authoriser d'autres users (proxyAuth sur tout le DN, ex : authzTo=dn.subtree :"") et le serveur distant doit avoir authz-policy mis à to ou both.
‹mode› := {legacy|anonymous|none|self} legacy implique que le proxy va effectuer un simple bind (authcDN) ou SASL (authcID) et assert l'identité du client quand il n'est pas anonyme. Anonymous et self, assert une chaîne vide ou l'identité du client, respectivement.
‹flag› := {override|[non-]prescriptive|proxy-authz-[non-]critical} override, l'assertion de l'identité prend place même quand la base est autorisée pour l'identité du client. Quand prescriptive est utilisé, les opérations échouent avec inappropriateAuthentication pour les identités dont l'assertion n'est pas permise par le motif idassert-authzFrom. non-prescriptive, les opérations sont effectuées anonymement pour les identité dont l'assertion n'est pas permise par le pattern idassert-authzFrom. proxy-authz-non-critical, le contrôle proxyAuthz contrôle n'est pas marqué comme critique, en violation de la RFC 4370. il est recommandé d'utiliser proxy-authz-critical
idle-timeout ‹time› Force une connexion en cache à être supprimée puis recrée après une timeout
keepalive ‹idle›:‹probes›:‹interval› Définis les valeurs de idle, probes et interval utilisés pour cérifier si un socket est actif. idle est le nombre de seconde avant qu'une connexion non-active reçoive un keepalive. probes et le nombre maximum de keepalive, et interval est le nombre de seconde entre chaque keepalive.
map {attribute|objectclass ‹local name› ‹foreign name›|*} Map des classes d'objet et des attributs comme dans le backend ldap
network-timeout ‹time› Définis la valeur timeout réseau après que poll(2)/select(2) suivant un retour connect(2) en cas d'inactivité, en seconde
nretries {forever|never|‹nretries›} Définis le nombre de fois qu'un bind doit être retenté en cas d'échec temporaire. (défaut : 3)
rewrite*... Permet de réecrire des requêtes
subtree-{exclude|include} ‹rule› Permet d'indiquer quels subtrees sont actuellement servis par un target. Peut être spécifié plusieurs fois. les syntaxes supportées sont:

        ‹rule›: [dn[.‹style›]:]‹pattern›
        ‹style›: subtree|children|regex style est soit subtree, children ou un regexp. pattern est un DN qui doit être dans le contexte de nommage servis par le target, ou un regex si style vaut regex. Si dn.‹style› est omis, dn.subtree est implicite
        Dans la forme subtree-exclude, si le DN demandé match au moins une règle, la cible n'est pas considérée pour remplir la requête.
        Dans la forme subtree-include, si le DN demandé match au moins une règle, la cible est considérée basée sur la valeur du request DN.

suffixmassage ‹virtual naming context› ‹real naming context› Toutes les directives commençant par "rewrite" obsolète par slapo-rwm.
t-f-support {NO|yes|discover} Permet le support des filtres absolus des serveur distant
timeout [‹op›=]‹val› [...] Définis un timeout par opération. Les opérations peuvent être : ‹op› ::= bind, add, delete, modrdn, modify, compare, search
tls {[try-]start|[try-]propagate} Exécute StartTls quand la connexion est initialisée. Ne fonctionne qu'avec ldaps://

scénarios

1. 2 serveurs partagent 2 niveaux de contexte de nommage, "dc=a,dc=foo,dc=com" et "dc=b,dc=foo,dc=com". Un meta annuaire peut être configuré comme:
database meta
suffix "dc=foo,dc=com"
uri "ldap://a.foo.com/dc=a,dc=foo,dc=com"
uri "ldap://b.foo.com/dc=b,dc=foo,dc=com"
Les opérations dirigées vers un target spécifique peuvent facilement être résolus parce qu'il n'y pas d'ambiguïté. La seule opération qui peut résoudre plusieurs target est une recherche avec une base "dc=foo,dc=com". qui résulte de 2 recherches dans les targets.

2. 2 serveurs ne partagent aucune portion du contexte de nommage, mais ils se présentent en un simple DIT. "dc=bar,dc=org" et "o=Foo,c=US" qui apparaissent comme des branches de "dc=foo,dc=com", disons "dc=a,dc=foo,dc=com" et "dc=b,dc=foo,dc=com". On doit configurer le backend meta comme suit:
database meta
suffix "dc=foo,dc=com"
uri "ldap ://a.bar.com/dc=a,dc=foo,dc=com"
suffixmassage "dc=a,dc=foo,dc=com" "dc=bar,dc=org"
uri "ldap ://b.foo.com/dc=b,dc=foo,dc=com"
suffixmassage "dc=b,dc=foo,dc=com" "o=Foo,c=US"
De même, les opérations peuvent être résolus sans ambiguïté, bien qu'une réécriture soit requise. Noter que le contexte de nommage de chaque cible est une branche du contexte de nommage de la base. lors d'une recherche avec la base "dc=foo,dc=com" et un scope base, une erreur no such object est générée. Si le scope est one, les 2 targets sont contactés.

3. En utilisant le scénario précédent avec 2 serveurs partageant le même contexte de nommage:
database meta
suffix "dc=foo,dc=com"
uri "ldap ://a.bar.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "dc=bar,dc=org"
uri "ldap ://b.foo.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "o=Foo,c=US"
Toutes les considérations précédente sont maintenues, excepté que maintenant il n'y a plus d'ambiguïté pour résoudre un DN

ACL

   Vous pouvez ajouter toutes les ACL au backend meta. Cependant, la signification d'un ACL sur un proxy peut nécessiter certaines considérations.

- Le serveur distant dicte les permissions ; le proxy passe simplement ce qu'il reçoit au serveur distant
- Le serveur distant dévoile tout, le proxy est responsable de la protection des accès non autorisés.

rewriting

   La syntaxe et le fonctionnement est le même que slapo-rwm
^
20 octobre 2013

htmlpdflatexmanmd




slapd-monitor

slapd-monitor

Backend monitor

   Ce backend n’est pas une base de données, il ne peut en exister qu’un seul sur un serveur. Il est automatiquement généré et maintenu par slapd. Pour inspecter toutes les informations monitorées, fournir une recherche dans un subtree avec la base cn=monitor. Il produit principalement des attributs opérationnels.

pour activer ce backend:
database monitor
Ajouter des acl à cette base:
access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=my,dc=org" write by users read by * none

   Monitor honore les acl. Il n’honore pas les limites dans les opérations de recherche

^
20 octobre 2013

htmlpdflatexmanmd




slapd-ndb

slapd-ndb

Backend ndb

   Backend utilisant l’API NDB de MySQL cluster

OPTIONS

dbhost ‹hostname› Nom du serveur MySQL
dbuser ‹username› User MySQL
dbpasswd ‹password› Mot de passe du compte MySQL
dbname ‹database name› Base de données à utiliser
dbport ‹port› Port d’écoute du serveur MySQL
dbsocket ‹path› Socket à utiliser pour se connecter à un serveur local
dbflag ‹integer› Flags client pour la session MySQL
dbconnect ‹connectstring› Nom du cluster manager
dbconnections ‹integer› Nombre de connections cluster à établir, jusqu’à 4 (défaut : 1)

Configuration du schéma

attrlen ‹attribute› ‹length› Spécifie la longueur de colonne à utiliser pour un attribut particulier (défaut : 128 octets). Max 1024
index ‹attr[,attr...]› Liste d’attributs pour lesquels maintenir un index
attrset ‹set› ‹attrs› Liste d’attributs à traiter comme jeu d’attributs. Créé une table set qui contiend tous ces attributs. Normalement, un attribut réside dans une table nommée par une classe d’objet qui utilise l’attribut. Cependant les attributs sont seulement permis dans une seule table. Ce jeu d’attribut permet de placer des attributs dans une table qui sont définis pour plusieurs classes d’objet.

ACL

   ndb honore la plupart des ACL
^
08 septembre 2013

htmlpdflatexmanmd




slapd-null

slapd-null

Backend null

   Backend conçus à des fins de test. Les recherches et les mises à jours retournent un success, les comparaison retournent compareFalse.

OPTIONS

bind Autorise les binds à ce backend.

Contrôle d'accès

   ce backend ne respecte aucune ACL
^
08 septembre 2013

htmlpdflatexmanmd




slapd-passwd

slapd-passwd

Backend passwd

   Backend /etc/passwd

OPTIONS

file ‹filename› Fichier passwd alternatif.

Contrôle d'accès

   ce backend ne respecte aucune ACL
^
20 octobre 2013

htmlpdflatexmanmd




slapd-perl

slapd-perl

Backend perl

   Backend embarquant un interpréteur perl. Il faut créer une méthode pour chacune de ces actions:

new Appelé quand le fichier de configuration rencontre une ligne perlmod. Plusieurs instances de cet objet peuvent être instanciés
search Ses arguments sont les suivants:

        référence objet
        base DN
        scope
        stratégie de déréférencement des alias
        size limit
        time limit
        Filtre
        Flag attribut uniquement
        liste des attributs à retourner

compare ses arguments sont: référence objet, dn, attribut assertion
modify ses arguments sont: référence objet, dn, une liste formatée comme suis : ({ "ADD" | "DELETE" | "REPLACE" }, attributetype, value...)...
add ses arguments sont: référence objet, Entrée au format chaîne
modrdn ses arguments sont: référence objet, dn, new rdn, flag delete old
delete ses arguments sont: référence objet, dn
config Appelé une fois pour chaque perlModuleConfig dans le fichier de configuration. ses arguments sont: référence objet, tableau des arguments
init Appelé après que le backend est été initialisé. ses arguments sont: référence objet

OPTIONS

perlModulePath /path/to/libs Ajouter le chemin de la variable @INC
perlModule ModName Utilise le module spécifié
filterSearchResults Les résultat de recherche sont candidats qui doivent être filtré (avec le filtre de la requête).
perlModuleConfig ‹arguments› invoque la méthode config du module avec les arguments donnés

ACL

   Ce backend n’honore aucune ACL. Seul read sur les attributs est géré par le frontend
^
20 octobre 2013

htmlpdflatexmanmd




slapd-relay

slapd-relay

Backend relay

   backend relay. Il permet de mapper un contexte de nommage, avec manipulation d'attributs et classes d'objet. Il nécessite l'overlay slapo-rwm

OPTIONS

relay ‹real naming context› Le contexte de nommage qui sera présenté sous un contexte de nommage virtuel.

ACL

   Un problème important est que les règles d'accès sont basés sur l'identité qui a soumis l'opération. Après le massaging du contexte de nommage, le frontend vois les opérations effectuées par l'identité du vrai contexte de nommage. En concéquence, le base doit fournir ses propre règles.

  relay n'honore aucune ACL, il délègue les règles aux bases distantes.

Exemples

Pour implémenter un mappage de contexte de nommage qui réfère à une simple base:
database relay
suffix "dc=virtual,dc=naming,dc=context"
relay "dc=real,dc=naming,dc=context"
overlay rwm
rwm-suffixmassage "dc=real,dc=naming,dc=context"
Pour implémenter un mappage de contexte de nommage qui recherche le vrai contexte de nommage pour chaque opération:
database relay
suffix "dc=virtual,dc=naming,dc=context"
overlay rwm
rwm-suffixmassage "dc=real,dc=naming,dc=context"
Une configuration identique mais en remplaçant suffixmassage par une réécriture explicite:
database relay
suffix "dc=virtual,dc=naming,dc=context"
relay "dc=real,dc=naming,dc=context"
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext default
rwm-rewriteRule "dc=virtual,dc=naming,dc=context" "dc=real,dc=naming,dc=context" ":@"
rwm-rewriteContext searchFilter
rwm-rewriteContext searchEntryDN
rwm-rewriteContext searchAttrDN
rwm-rewriteContext matchedDN
Configuration des règles d'accès:
database bdb
suffix "dc=example,dc=com"
# skip...
access to dn.subtree="dc=example,dc=com"
by dn.exact="cn=Supervisor,dc=example,dc=com" write
by * read
database relay
suffix "o=Example,c=US"
relay "dc=example,dc=com"
overlay rwm
rwm-suffixmassage "dc=example,dc=com"
# skip ...
access to dn.subtree="o=Example,c=US"
by dn.exact="cn=Supervisor,dc=example,dc=com" write
by dn.exact="cn=Relay Supervisor,dc=example,dc=com" write
by * read
^
20 octobre 2013

htmlpdflatexmanmd




slapd-shell

slapd-shell

Backend shell

   Backend qui exécute des programmes externe pour implémenter les opérations

OPTIONS

add ‹pathname› ‹argument›...
ADD
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
‹entry in LDIF format›

bind ‹pathname› ‹argument›...
BIND
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›
method: ‹method number›
credlen: ‹length of ‹credentials››
cred: ‹credentials›

compare ‹pathname› ‹argument›...
COMPARE
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›
‹attribute›: ‹value›

delete ‹pathname› ‹argument›...
DELETE
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›

modify ‹pathname› ‹argument›...
MODIFY
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›
‹repeat {
‹"add"/"delete"/"replace"›: ‹attribute›
‹repeat { ‹attribute›: ‹value› }›
-
}›

modrdn ‹pathname› ‹argument›...
MODRDN
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›
newrdn: ‹new RDN›
deleteoldrdn: ‹ 0 or 1 ›
‹if new superior is specified: "newSuperior: ‹DN›"›

search ‹pathname› ‹argument›...
SEARCH
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
base: ‹base DN›
scope: ‹ 0-2, see ldap.h ›
deref: ‹ 0-3, see ldap.h ›
sizelimit: ‹size limit›
timelimit: ‹time limit›
filter: ‹filter›
attrsonly: ‹ 0 or 1 ›
attrs: ‹"all" or space-separated attribute list›

unbind ‹pathname› ‹argument›...
UNBIND
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹bound DN›

ACL

   Ce backend n'honore pas toutes les ACL. en général les acl sur les objets sont vérifiés en utilisant un objet factice qui contient seulement le DN, donc les règles d'accès qui s'occupent du contenu de l'objet ne sont pas honorés

l'opération add ne nécessite pas write sur children de l'entrée parent.
l'opération bind nécessite auth sur entry
l'opération compare nécessite read sur entry
l'opération delete ne nécessite pas write sur children de l'entrée parent
l'opération modify nécessite write sur children de l'entrée parent
l'opération modrdn ne nécessite pas write sur children de l'entrée parent
l'opération search ne nécessite pas l'accès search sur entry

Limitations

   Ce backend ne supporte pas les environnement multi-threadés. slapd doit être construit avec --without-threads
^
27 octobre 2013

htmlpdflatexmanmd




slapd-sql

slapd-sql

Backend sql

   Backend SQL pour slapd. Il permet de présenter les informations stockées dans un RDBMS sous forme d’entrée LDAP.

options - Configuration de source de données

dbname ‹datasource name› Le nom de la source ODBC à utiliser
dbhost ‹hostname›
dbpasswd ‹password›
dbuser ‹username› Informations de connections à la source ODBC

options - Configuration de scope

subtree_cond ‹SQL expression› template where-clause pour former une condition de recherche de subtree (dn="(.+,) ?‹dn›$"). (ex: "‹upper_func›(ldap_entries.dn) LIKE CONCAT(’%’, ?)")
children_cond ‹SQL expression› template where-clause pour former une condition de recherche enfant (dn=".+,‹dn›$"). (ex: "‹upper_func›(ldap_entries.dn) LIKE CONCAT(’%,’, ?)")
use_subtree_shortcut YES Ne pas utiliser de condition de subtree quand la base de recherche est le suffix de la base.

options - Configuration de déclarations

oc_query ‹SQL expression› requête utilisée pour collecter le mapping des objectClass depuis la table ldap_oc_mappings. (défaut : "SELECT id, name, keytbl, keycol, create_proc, delete_proc, expect_return FROM ldap_oc_mappings")
at_query ‹SQL expression› requête utilisée pour collecter le mapping des attributeType depuis la table ldap_attr_mappings
id_query ‹SQL expression› requête utilisée pour mapper un DN à une entrée dans la table ldap_entries (défaut : "SELECT name, sel_expr, from_tbls, join_where, add_proc, delete_proc, param_order, expect_return FROM ldap_attr_mappings WHERE oc_map_id= ?") )
insentry_stmt ‹SQL expression› requête utilisée pour insérer une nouvelle entrée dans la table ldap_entries (défaut : "INSERT INTO ldap_entries (dn, oc_map_id, parent, keyval) VALUES (?, ?, ?, ?)" )
delentry_stmt ‹SQL expression› requête utilisée pour supprimer une entrée existante depuis la table ldap_entries (défaut : "DELETE FROM ldap_entries WHERE id= ?")
delobjclasses_stmt ‹SQL expression› requête utilisée pour supprimer l’ID d’une entrée dans la table ldap_objclasses. (défaut : "DELETE FROM ldap_entry_objclasses WHERE entry_id= ?"

options - Configuration helper

upper_func ‹SQL function name› Spécifie le nom d’un fonction qui convertit une valeur en majuscule (ex : UCASE, UPPER)
upper_needs_cast NO Définis si upper_func doit explicitement être utilisé sur des chaînes littérales.
strcast_func ‹SQL function name› Spécifie le nom d’une fonction qui convertis une valeur donnée en chaîne pour l’ordonnancement. Utilisé dans SELECT DISTINCT.
concat_pattern ‹pattern› Définis le pattern utilisé pour concaténer les chaînes. le pattern doit contenir 2 ’ ?’ qui seront remplacés par 2 chaînes à concaténer. (défaut : CONCAT(?, ?), PostfreSQL : ?|| ? )
aliasing_keyword ‹string› Définis le mot clé d’alias. défaut : AS
aliasing_quote ‹string› Définis le caractère de quoting pour les mots clé d’alias. défaut : aucun.
has_ldapinfo_dn_ru NO Informe explicitement le backend si la colonne dn_ru (DN sous forme majuscule inversé) est présent dans la table ldap_entries.
fail_if_no_mapping NO Force les opérations d’écriture d’attribut à échouer si aucun mapping approprié n’est disponible. uniquement pour les attributs. N’a pas d’impacte sur les classec d’objet.
allow_orphans NO Permet d’ajouter des entrées orphelines.
baseObject [ ‹filename› ] Instruit la base de créer et gérer une entrée baseObject en mémoire au lieu d’en chercher un dans le RDBMS. Si filename est fournis, l’entrée est lue depuis ce ldif. Utile quand les informations ldap_entries sont stockés dans une vue et union n’est pas supporté pour les vues
create_needs_select NO Instruit la base si la création d’entrée dans la table ldap_entries a besoin d’un select pour collecter l’ID assigné automatiquement, au lieu d’être retourné par une procédure stockée.
fetch_attrs ‹attrlist›
fetch_all_attrs NO Le premier état permet de fournir un liste d’attributs qui doivent toujours être remplis en plus de ceux requis par un opération spécifique. Pour l’instant, tous les attributs utilisés dans les ACL devraient être listés ici. Le second état est un raccourci pour tous les atributs
check_schema YES Instruit la base de vérifier l’adhérence des entrées au schéma après modification.
sqllayer ‹name› [...] Charge la couche name dans la pile d’helpers qui sont utilisés pour mapper les DN de LDAP vers la représentation SQL et inversement. Les arguments suivants sont passés à la routine de configuration.
autocommit NO Active l’autocommit. défaut : off

Exemples

Supposons que l’on stocke des informations sur des personnes travaillant dans notre organisation dans 2 tables:
PERSONS PHONES
-------------
id integer id integer
first_name varchar pers_id integer references persons(id)
last_name varchar phone
middle_name varchar
...
Une personne peut avoir plusieurs téléphones, phone peut contenir plusieurs enregistrements avec le pers_id correspondant, ou aucun. Une classe d’objet LDAP pourrait présenter de tels informations comme ceci:
person
MUST cn
MAY telephoneNumber $ firstName $ lastName
...
Pour renseigner toutes les valeurs cn, on construit la requête:
SELECT CONCAT(persons.first_name,’ ’,persons.last_name) AS cn FROM persons WHERE persons.id= ?
Pour telephoneNumber on peut utiliser:
SELECT phones.phone AS telephoneNumber FROM persons,phones WHERE persons.id=phones.pers_id AND persons.id= ?
Si on veut des requêtes LDAP avec des filtres tels que (telephoneNumber=123*), on peut construire :
SELECT ... FROM persons,phones WHERE persons.id=phones.pers_id AND persons.id= ? AND phones.phone like ’%1%2%3%’
On a donc les informations sur quelles tables contiennent les valeurs de chaque attribut, comment joindre ces tables et arranger les valeurs, on pourrait essayer de générer automatiquement de tels déclaration, et traduire les filtres de recherche en clause WHERE.
Pour stocker de tels informations, on ajoute 3 tables de plus à notre schéma:
ldap_oc_mappings (some columns are not listed for clarity)
^
26 septembre 2013

htmlpdflatexmanmd




slapd.conf

slapd.conf

Fichier de configuration de slapd (ancien format)

   Le fichier de configuration (slapd.conf) consiste de 3 types d'information de configuration: global, backend et database. Les informations globales sont spécifiées en premier, suivis par les informations associées avec un type de backend particulier, puis les informations associées avec un type particulier de base. Les directives globales peuvent être écrasées par des directives de base ou de backend, et les directives backend peuvent être écrasées par les directives de base de données.

  Les lignes blanches et les lignes de commentaire commençant par un # et sont ignorées. Si une ligne commence par un espace blanc, il est considéré comme la suite de la ligne précédente (même si la précédente ligne est un commentaire).

Format général


# Directives de configuration globale:
‹global config directives›
    
# backend definition
backend ‹typeA›
‹backend-specific directives›
    
# first database definition & config directives
database ‹typeA›
‹database-specific directives›
    
# second database definition & config directives
database ‹typeB›
‹database-specific directives›
    
# second database definition & config directives
database ‹typeA›
‹database-specific directives›
    
# subsequent backend & database definitions & config directives
...

Directives Global

   Les directives décrites dans cette section s'appliquent à tous les backend et bases.

access to ‹what› [ by ‹who› [‹accesslevel›][‹control›]]+ Cette directive donne accès spécifié par accesslevel à un set d'entrée et/ou d'attributs spécifiés par what, par un ou plusieurs utilisateurs spécifiés par who. note: si aucune directive access n'est spécifié, la politique est access to * by * read.
attributetype ‹rfc4512 Attribute Type Description› cette directive définit un type d'attribut.
idletimeout ‹integer› Spécifie le nombre de secondes à attendre avant de forcer la fermeture de la connexion d'un client. à 0, désactive la fonction.
include ‹filename› Spécifie une fichier à lire, contenant d'autres informations de configuration. Généralement utilisé pour inclure les spécification de schéma.
loglevel ‹integer› Cette directive spécifie le niveau de log (actuellement placé dans syslogd LOG_LOCAL4). Le loglevel peut être spécifié sous forme d'entier ou par mot clé.

level_keyword________Description
-1____any____________enable all debugging
0____________________no debugging
1_____(0x1 trace)____trace function calls
2_____(0x2 packets)__debug packet handling
4_____(0x4 args)_____heavy trace debugging
8_____(0x8 conns)____connection management
16____(0x10 BER)_____print out packets sent and received
32____(0x20 filter)__search filter processing
64____(0x40 config)__configuration processing
128___(0x80 ACL)_____access control list processing
256___(0x100 stats)__stats log connections/operations/results
512___(0x200 stats2)_stats log entries sent
1024__(0x400 shell)__print communication with shell backends
2048__(0x800 parse)__print entry parsing debugging
16384_(0x4000 sync)__syncrepl consumer processing
32____(0x8000 none)___only messages that get logged whatever log level is set

on peut additionner les valeurs:
loglevel 129
loglevel 0x81
loglevel 128 1
sont équivalent:
loglevel 0x80 0x1
et
loglevel acl trace

objectclass ‹rfc4512 Object Class Description› Cette directive définit une classe objet
referral ‹URI› Cette directive spécifie le référant quand slapd ne peut trouver une base locale pour manipuler les requêtes.
sizelimit ‹integer› Cette directive spécifie le nombre maximum d'entrée à retourner pour une opération de recherche. défaut: sizelimit 500
timelimit ‹integer› Cette directive spécifie le nombre maximum de seconde que slapd va passer à répondre à une requete. Au delà, il envoie un exceeded timelimit. defaut: timelimit 3600

Directives Backend

   Les directives dans cette section s'appliquent uniquement au backend dans lequel elles sont définies. Elles sont supportées par tous les types de backend. Les directives d'un backend s'appliquent à toutes les instances de base du même type.

backend ‹type› Cette directive marque le début d'une déclaration backend. ‹type› peut être un des types supportés:

Types___Description
bdb_____Berkeley DB transactional backend
dnssrv__DNS SRV backend
hdb_____Hierarchical variant of bdb backend
ldap____Lightweight Directory Access Protocol (Proxy) backend
meta____Meta Directory backend
monitor_Monitor backend
passwd__Provides read-only access to passwd(5)
perl____Perl Programmable backend
shell___Shell (extern program) backend
sql_____SQL Programmable backend

Directives générales de bases de données

   Les directives dans cette section s'appliquent uniquement à la base dans laquelle elles sont définies

database ‹type› Cette directive marque le début d'une déclaration d'instance de base. ‹type› doit être un des type de backend supporté.
limits ‹who›‹limit›[‹limit›[...]] spécifie les limites de temps et de taille sur qui initie une opération
readonly on|off Cette directive place la base en lecture seule
rootdn ‹DN› Cette directive spécifie le DN qui n'est pas sujet aux restriction de limites administratives et de contrôle d'accès pour les opérations sur cette base. le DN doit référer à une entrée dans l'annuaire. Le DN peut référer à une identité SASL. (ex: rootdn "cn=Manager,dc=example,dc=com", avec sasl: rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth")
rootpwd ‹password› Cette directive spécifie le mot de passe pour le rootdn. Il est possible d'utiliser slappasswd -s pour générer un hash.
suffix ‹dn suffix› Cette directive spécifie le suffixe DN des requêtes qui seront passé à cette base. Plusieurs lignes peuvent être spécifiées, et au moins une est requise pour chaque définition de base.(ex: suffix "dc=example,dc=com" # les requêtes avec un DN se terminant avec "dc=Example,dc=com" seront passées à ce backend)
syncrepl
syncrepl rid=‹replica ID›
provider=ldap[s] ://‹hostname›[:port]
type=refreshOnly
[interval=dd:hh:mm:ss]
[retry=[‹retry interval› ‹# of retries›]+]
searchbase=‹base DN›
[filter=‹filter str›]
[scope=sub|one|base]
[attrs=‹attr list›]
[attrsonly]
[sizelimit=‹limit›]
[timelimit=‹limit›]
schemachecking=on
bindmethod=simple
[binddn=‹DN›]
[saslmech=‹mech›]
[authcid=‹identity›]
[authzid=‹identity›]
[credentials=‹passwd›]
[realm=‹realm›]
[secprops=‹properties›]
starttls=yes
[tls_cert=‹file›]
[tls_key=‹file›]
[tls_cacert=‹file›]
[tls_cacertdir=‹path›]
[tls_reqcert=never|allow|try|demand]
[tls_ciphersuite=‹ciphers›]
[tls_crlcheck=none|peer|all]
[logbase=‹base DN›]
[logfilter=‹filter str›]
[syncdata=default|accesslog|changelog] Cette directive spécifie la base courante comme réplique du contenu d'un master en utilisant le moteur de réplication syncrepl.

provider indique le master. spécifie un schéma, un hôte et un port
rid est utilisé pour l'identification de la directive syncrepl courante dans le serveur de réplication.
searchbase n'a pas de valeur par défaut et doit toujours être spécifié.
scope est à sub par défaut
filter est à (objectclass=*) par défaut
attrs à "*,+" par défaut pour répliquer tous les utilisateurs et tous les attributs optionnels
attrsonly est désactivé par défaut
sizelimit est à unlimited par défaut
timelimit est à unlimited par défaut

   Le protocole de synchronisation de contenu LDAP à 2 types d'opérations: refreshOnly et refreshResultEntry. Avec RefreshOnly, la synchronisation est périodique. l'interval est spécifié par le paramètre interval. Par défaut il est à 1 jour. Avec refreshAndPersist, la synchronisation est persistante.

   Si une erreur se produit durant la réplication, le réplicateur tente de se reconnecter en accord avec le paramètre retry, qui est une liste de paire de paramètres ‹retry interval› et ‹# of retries›. Par exemple, retry "60 10 300 3" tente de se reconnecter toutes les 60 secondes, 10 fois, puis retente toutes les 300 secondes, 3 fois, avant de stopper la tentative de reconnexion.

   La vérification de schéma peut être renforcée avec le paramètre schemachecking. Activé, toute entrée répliquée sera vérifié pour ce schéma avant de le stocker. Le paramètre binddn donne le DN à lier pour la recherche syncrepl. Il doit être un DN qui a les droits d'accès en lecture.

   bindmethod est simple ou sasl, en fonction si l'authentification par mot de passe est simple pour sasl. L'authentification simple ne devrait pas être utilisé a moins que l'intégrité des données des protections de confidentialité soient en place (par exemple: TLS ou IPsec) L'authentification simple requière les paramètres binddn et credentials. L'authentification SASL requière la spécification d'un mécanisme utilisant le paramètre saslmech. authcid et credential peuvent être spécifiés pour l'identité d'authentification et le credential. authzid peut être utilisé pour spécifier l'identité d'autorisation.

   le paramètre realm spécifie un domaine. le paramètre secprops spécifie les propriétés de sécurité Cyrus SASL.

  starttls spécifie l'utilisation de TLS. Si l'argument critical est spécifié, la session sera abordée si la requête StartTLS échoue. Sinon la session SyncRepl continu sans TLS.

   Au lieu de répliquer toutes les entrées, le réplicateur peut chercher les logs de modification de données. Ce mode d'opération s'appel delta syncrepl. En plus des paramètres ci-dessus, les paramètres logbase et logfilter doivent être spécifiés pour les logs à utiliser. Le paramètre syncdata doit être soit à "accesslog" si le log est conforme au format slapo-accesslog ou "changelog". Si le paramètre syncdata est omis ou à "default", les paramètres de log seront ignorés. La réplication syncrepl est supportées par bdb et hdb.

updateref ‹URL› Cette directive est seulement applicable dans un slave. Il spécifie l'URL à retourner aux clients qui envoient des requêtes de mise à jours sur la réplique. Peut être spécifié plusieurs fois.
directives de base BDB et HDB Ces directives s'appliquent uniquement aux bases BDB et HDB.
directory ‹directory› Cette directive spécifie le dossier où les fichiers contenant la base et indices associés sont stockés.

Exemple de fichier de configuration

L'exemple suivant définit 2 bases pour manipuler différentes parties d'un arbre x500. Les 2 bases sont des instances BDB.
# example config file - global configuration section
include /usr/local/etc/schema/core.schema # inclue un fichier de définition de schéma
referral ldap ://root.openldap.org # les requêtes non local sur une des bases définies vont référer au server LDAP à l'hôte root.openldap.org
access to    *    by    *    read # Contrôle d'accès global.
    
# BDB definition for the example.com
database bdb
suffix "dc=example,dc=com" # suffix DN pour cette base
directory /usr/local/var/openldap-data # dossier où se trouve les fichiers de cette base.
rootdn "cn=Manager,dc=example,dc=com" # rootdn pour cette base
rootpw secret # mdp du rootdn
# indexed attribute definitions
index uid pres,eq # indique les indices pour maintenir divers attributs
index cn,sn,uid pres,eq,approx,sub
index objectClass eq
# database access control definitions
access to attrs=userPassword # Spécifier le controle d'accès pour les entrées dans cette base.
by self write
by anonymous auth
by dn.base="cn=Admin,dc=example,dc=com" write
by    *    none
access to    *
by self write
by dn.base="cn=Admin,dc=example,dc=com" write
by    *    read
    
# BDB definition for example.net
database bdb
suffix "dc=example,dc=net"
directory /usr/local/var/openldap-data-net
rootdn "cn=Manager,dc=example,dc=com"
index objectClass eq
access to    *    by users read

^
08 septembre 2013

htmlpdflatexmanmd




slapdn

slapdn

Vérifie une liste de DN basé sur une définition de schéma dans la configuration de slapd

OPTIONS

-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-N Affiche seulement une forme normalisée des DN, incompatible avec -P
-o option[=value] Spécifie une option slapd
-P Affiche seulement une forme édulcorée du DN
-v mode verbeux
^
08 septembre 2013

htmlpdflatexmanmd




slapindex

slapindex

Réindex les entrées dans une base slapd

OPTIONS

-b suffix Utilise le suffix spécifié pour déterminer quelle base utiliser
-c Ignore les erreurs et continue
-d debug-level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-g Désactive le gluing subordonné. Seul la base spécifiée sera traitée et non ses subordonnées attachés
dbnum Génère une sortie pour la dbnum-ième base listée dans la configuration. Ne peut pas être utilisé avec -b
-o option[=value] Spécifie une option slapd
-q mode rapide (peu de vérifications)
-t active le tronquage. uniquement en mode rapide
-v mode verbeux

limitations

   slapd ne devrait pas être en cours de fonctionnement, ou au moins en lecture seule.

Exemples

pour régénérer l’index pour un attribut spécifique
slapindex uid
^
28 septembre 2013

htmlpdflatexmanmd




slapo-accesslog

slapo-accesslog

Overlay accesslog

   Overlay de log des accès. Il permet d'enregistrer tous les accès à la base de données dans une autre base.

Configuration

logdb ‹suffix› Spécifie le suffix d'une base de données à utiliser pour stocker les enregistrements.
logops ‹operations› Spécifie quel types d'opérations logger. (abandon, add, bind, compare, delete, extended, modify, modrdn, search, unbind, et les alias writes (add, delete, modify, modrdn), reads (compare, search), session (abandon, bind, unbind) et all (toutes les opérations) )
logbase ‹operations›‹baseDN› Spécifie un jeu d'opérations qui seront loggés uniquement s'ils se produisent dans une arborescence spécifique de la base, et délimités par le caractère '|'
logold ‹filter› Spécifie un filtre pour matcher les entrées supprimées et modifiées. Si l'entrée match le filtre, l'ancienne entrée sera loggées avec la requête en cour.
logoldattr ‹attr› Spécifie une liste d'attributs loggés.
logpurge ‹age›‹interval› Spécifie la durée maximal pour les entrées à maintenir dans la base. et la fréquence de scan de la base pour les anciennes entrées. le format de date est [ddd+]hh:mm[:ss]. ex: logpurge 2+00:00 1+00:00 pour un scan quotidien avec suppression des entrées de plus de 2 jours.
logsuccess TRUE | FALSE à TRUE, les enregistrement seront loggés uniquement si la requête produit un succès. défaut : FALSE

Schéma

   accesslog utilise le schéma audit décrit ici. ce schéma est conçu spécifiquement pour cet overlay.

auditObject 2 classes en sont dérivés : auditReadObject et auditWriteObject.
reqStart
reqEnd Fournissent l'heure de début et de fin de l'opération.
reqType Décrit le type d'opération qui est loggée.
reqSession Identifiant commun à toutes les opérations associées avec la même session LDAP
reqDN DN de la cible de l'opération
reqAuthzID DN de l'utilisation qui a effectué l'action
reqControls
reqRespControls Gèrent les contrôles envoyés par le client dans la requête et retourné par le serveur.
reqResult Code de résultat LDAP de l'opération
reqMessage message d'erreur s'il y'en a un
reqReferral Gère les référrant qui ont été retournés avec le résultat de la requête.


( 1.3.6.1.4.1.4203.666.11.5.2.1 NAME 'auditObject' DESC 'OpenLDAP request auditing' SUP top STRUCTURAL MUST ( reqStart $ reqType $ reqSession ) MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls $ reqEnd $ reqResult $ reqMessage $ reqReferral ) )
    
( 1.3.6.1.4.1.4203.666.11.5.2.4 NAME 'auditAbandon' DESC 'Abandon operation' SUP auditObject STRUCTURAL MUST reqId )
    
( 1.3.6.1.4.1.4203.666.11.5.2.5 NAME 'auditAdd' DESC 'Add operation' SUP auditWriteObject STRUCTURAL MUST reqMod )
    
( 1.3.6.1.4.1.4203.666.11.5.2.6 NAME 'auditBind' DESC 'Bind operation' SUP auditObject STRUCTURAL MUST ( reqVersion $ reqMethod ) )
    
( 1.3.6.1.4.1.4203.666.11.5.2.7 NAME 'auditCompare' DESC 'Compare operation' SUP auditObject STRUCTURAL MUST reqAssertion )
    
( 1.3.6.1.4.1.4203.666.11.5.2.8 NAME 'auditDelete'
DESC 'Delete operation' SUP auditWriteObject STRUCTURAL MAY reqOld )
    
( 1.3.6.1.4.1.4203.666.11.5.2.9 NAME 'auditModify' DESC 'Modify operation' SUP auditWriteObject STRUCTURAL MAY reqOld MUST reqMod )
    
( 1.3.6.1.4.1.4203.666.11.5.2.10 NAME 'auditModRDN' DESC 'ModRDN operation' SUP auditWriteObject STRUCTURAL MUST ( reqNewRDN $ reqDeleteOldRDN ) MAY ( reqNewSuperior $ reqOld ) )
    
( 1.3.6.1.4.1.4203.666.11.5.2.11 NAME 'auditSearch' DESC 'Search operation' SUP auditReadObject STRUCTURAL MUST ( reqScope $ reqDerefAliases $ reqAttrsOnly ) MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit $ reqTimeLimit ) )
    
( 1.3.6.1.4.1.4203.666.11.5.2.12 NAME 'auditExtended' DESC 'Extended operation' SUP auditObject STRUCTURAL MAY reqData )

^
12 septembre 2014

htmlpdflatexmanmd




slapo-acl

slapo-acl

Module de contrôle d'accès

acl-posixgroup

   posixgroup est un exemple qui implémente un contrôle d'accès basé sur l'appartenance des posixGroup. Pour utiliser acl-posixgroup, charger le module puis créer une règle du type:

access to ‹what› by dynacl/posixGroup[.{exact,expand}]=‹dnpat› {‹level›|‹priv(s)}

acl-gssacl

   Exemple d'implémentation de contrôle d'accès basé sur les attributs d'extension de nommage GSS:

access to ‹what› by dynacl/gss/‹attribute›.[.{base,regex,expand}]=‹valpat› {‹level›|‹priv(s)›}
^
12 septembre 2014

htmlpdflatexmanmd




slapo-addpartial

slapo-addpartial

Module de contrôle d'opération Add

   addpartial intercepte les requêtes add, détermine si l'entrée existe, et détermine quels attributs, s'ils existent, ont changés, et modifie ces attributs. Si l'entrée n'existe pas, procède normalement. Si l'entrée existe mais qu'aucun changement n'a été détecté, le client reçoit LDAP_SUCCESS.

   Quand un changement est trouvé, toutes les valeurs de l'attribut sont remplacés (si un attribut n'existe pas dans la nouvelle entrée, mais existe dans l'entrée dans la base, une replace sera fait avec une liste vide de valeurs).

   Une fois qu'une modification est effectuée, l'overlay syncprov va traiter le changement si addpartial est le dernier overlay dans la liste pour être sûr qu'il sera le premier overlay à être traité.

   Le but de cet overlay est de faciliter les enregistrements répliqués depuis une source qui n'est pas une instance LDAP. L'overlay est également utile quand il est plus facile de créer des entrées complètes au lieu de comparer une entrée avec une entrée à retrouver depuis un base LDAP existant pour trouver les changements.

^
12 septembre 2014

htmlpdflatexmanmd




slapo-allop

slapo-allop

Module All Operational Attributes

   L'overlay All Operational Attributes est conçus pour retourner tous les attributs opérationnels pour les clients qui n'utilisent pas le '+' de la rfc3673 dans la liste des attributs demandés.

Exemple:
overlay allop
allop-URI "ldap:///??sub"

^
12 septembre 2014

htmlpdflatexmanmd




slapo-allowed

slapo-allowed

Ajoute des valeurs aux entrées retournées par les opérations de recherche

   Ajoute aux entrées retournées par les opérations de recherche la valeur des attributs allowedAttributes, allowedAttributesEffective, allowedChildClasses et allowedChildClassesEffective.

  Aucune autre utilisation n'est faite de ces attributs: Ils ne peuvent pas être comparés, utilisé dans des filtres de recherche, ou utilisé dans les ACL.

Exemples

dn: olcOverlay={0}allowed,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
olcOverlay: {0}allowed
^
12 octobre 2013

htmlpdflatexmanmd




slapo-auditlog

slapo-auditlog

Overlay auditlog

   Permet d’enregistrer tous les changements dans une base donnée dans un fichier de log. Les changements sont loggés au format LDIF.

Configuration

auditlog ‹filename› Chemin du fichier de log

Exemples


dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
olcAuditlogFile: /tmp/auditlog.ldif

^
12 septembre 2014

htmlpdflatexmanmd




slapo-autogroup

slapo-autogroup

Automatise l'appartenance aux groupes

   Permet d'automatiser les mises à jours de l'appartenance des groupes qui matche un filtre contenu dans la définition du groupe. À chaque fois qu'un objet est ajouté, supprimé ou modifié, il est testé avec les filtres et les appartenance de groupe sont mis à jours en conséquence. Si la partie attribut de l'URI est présente, l'entrée groupe est remplie avec les valeurs de cet attribut dans les entrées résultant de la recherche.

Configuration

Le schéma dyngroup doit être modifié, en ajoutant l'attribut member:
objectClass ( NetscapeLDAPobjectClass:33 NAME 'groupOfURLs' SUP top STRUCTURAL MUST cn MAY ( memberURL $ businessCategory $ description $ o $ ou $ owner $ seeAlso $ member) )
autogroup-attrset ‹group-oc› ‹URL-ad› ‹member-ad›
cette directive peut être spécifiée plusieurs fois. group-oc est le nom de la classe d'objet qui représente le groupe. URL-ad est le nom de attributeDescription qui contient l'URI qui est convertis en filtres. Doit être un sous-type de labeledURI. member-ad est le nom de l'attribut qui spécifie l'attribut de membre. La modification de cet attribut est désactivé.
autogroup-memberof-ad ‹memberof-ad›
Définis l'attribut memberOf utilisé par l'overlay memberOf pour stocker les noms des groupes dont l'entrée est membre. Doit être de type DN.

   Cet ovelay nécessite l'overlay memberof
^
12 octobre 2013

htmlpdflatexmanmd




slapo-chain

slapo-chain

Overlay chain

   Permet le repérage de références automatique. A chaque fois qu'un référant est retourné (excepté pour les opérations Bind), il est poursuivi en utilisant une instance du backend LDAP. Si les opérations sont effectués avec une identité, cette identité peut être affirmée tout en poursuivant les référants au moyen de l'identity assertion de back-ldap, qui est essentiellement basé sur le contrôle d'autorisation proxifié. la poursuite des référrant peut être contrôlée par le client en fournissant le contrôle chaining.

OPTIONS

overlay chain Ajoute l'overlay chain au backend courant
chain-cache-uri FALSE met en cache les connections des URIs utilisé pour les référants. ces URI héritent des propriétés configurées pour le backend slapd-ldap avant toute occurence de la directive chain-uri.
chain-chaining [resolve=‹r›] [continuation=‹c›] [critical] Active le contrôle chaining avec le mode de résolution et de continuation désiré. resolv réfère au mode de découverte d'une ressource, continuation réfère au comportement face aux réponses intermédiaires. les valeurs r et c peuvent être chainingPreferred, chainingRequired, referralsPreferred, referralsRequired. critical affecte la criticité du contrôle.
chain-max-depth ‹n› Si un référant est retourné durant la poursuite de référrant, indique la profondeur de poursuite.
chain-return-error FALSE|true Si une poursuite échoue, la vrai erreur est retournée au lieu du référrant orginal.
chain-uri ‹ldapuri› Instancie une nouvelle base ldap et instruit quels URI contacter pour poursuivre les référrants. Seul une URI peut apparaitre après cette directive. toutes les autres directives réfèrent à cette instance spécifique d'un serveur distant

Exemples


overlay chain
chain-rebind-as-user FALSE
    
chain-uri "ldap://ldap1.example.com"
chain-rebind-as-user TRUE
chain-idassert-bind bindmethod="simple"
    binddn="cn=Auth,dc=example,dc=com"
    credentials="secret"
    mode="self"
    
chain-uri "ldap://ldap2.example.com"
chain-idassert-bind bindmethod="simple"
    binddn="cn=Auth,dc=example,dc=com"
    credentials="secret"
    mode="none"

   Toute directive valide pour la base ldap peut être utilisée (voir slapd-ldap). plusieurs occurence de chain-uri peuvent être spécifiées. Toutes les URI non listées sont chaînées anonymement. Toutes les occurences slapd-ldap qui apparaissent avant la première occurence de chain-uri sont héritée par toutes les URI, moins de spécifiquement écraser dans chaque configuration d'URI.
^
12 septembre 2014

htmlpdflatexmanmd




slapo-cloak

slapo-cloak

Cacher des attributs non demandés

   Permet au serveur de cacher des attributs spécifiques sauf s'ils sont explicitement demandés par le client. Cela améliore les performances quand un client demande tous les attributs. Désactivé quand manageDSAit est utilisé.

Configuration

attribute est le nom de l'attribut qui sera caché, class restreint le masquage aux entrées de la classe spécifiée
cloak-attr ‹attribute› [‹class›]
^
12 octobre 2013

htmlpdflatexmanmd




slapo-collect

slapo-collect

Overlay collect

   Overlay d'Attributs collectifs.

OPTIONS

collectinfo ‹DN› ‹attrlist› Spécifie le DN de l'entrée de l'ancêtre et le jeu d'attributs collectifs.
^
12 septembre 2014

htmlpdflatexmanmd




slapo-comp_match

slapo-comp_match

Component Matching on X.509 certificates

Contient un module de correspondance. Exemple de filtre de recherche:
"(userCertificate:componentFilterMatch:=item:{ component\"toBeSigned.serialNumber\", rule integerMatch, value 2 })"
Configurer les index, vous pouvez générer des indices sur chaque composant d'un attribut dont les valeurs sont soit GSER soit BER. par exemple:
index userCertificate eq
index userCertificate.toBeSigned.issuer.rdnSequence eq
index userCertificate.toBeSigned.serialNumber eq
index userCertificate.toBeSigned.version eq

^
12 octobre 2013

htmlpdflatexmanmd




slapo-constraint

slapo-constraint

Overlay constraint

   Overlay de contrainte d'attributs. Permet de s'assurer que les valeurs d'attribut matchent certaines contraintes au-delà de la syntaxe de base LDAP. Les attributs peuvent avoir plusieurs contraintes et toute doivent être satisfaites.

OPTIONS

constraint_attribute ‹attribute_name›[,...] ‹type› ‹value› [‹extra›[...]] Spécifie la contrainte qui devrait s'appliquer à la liste d'attributs spécifiés dans le premier paramètre. 5 types de contraintes sont actuellement supportés: regex (regex unix), size (permet de forcer une limite de taille), count (nombre de valeurs max d'un attribut), uri ( uri évaluée en interne) et set (interprétée en accord avec le jeu d'acl). Le paramètre extra permet de restreindre l'application de la restriction à la partie base, scope et filter d'un URI)

Exemples

Rejète tout mail qui n'a pas le format ‹alpha-numeric string›@mydomain.com›. Rejète tout titre dont les valeurs ne sont pas listées dans l'attribut title d'une entrée titleCatalog dans le scope donné. Nécessite que les valeurs de cn soit construites avec sn et givenName séparés par un espace, mais uniquement pour les objets dérivés de la classe inetOrgPerson:
overlay constraint
constraint_attribute jpegPhoto size 131072
constraint_attribute userPassword count 3
constraint_attribute mail regex ^ [1]+@mydomain.com$
constraint_attribute title uri ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" restrict="ldap:///ou=People,dc=example,dc=com??sub?(objectClass=inetOrgPerson)"

^
12 octobre 2013

htmlpdflatexmanmd




slapo-dds

slapo-dds

Overlay dds

   Overlay de services d'annuaire dynamique. implémente la rfc 2589 et permet de définir des objets dynamique, caractérisés par la classe d'objet dynamicObject.

OPTIONS

dds-max-ttl ‹ttl› TTL max ( de 86400 à 31557600 )
dds-min-ttl ‹ttl› TTL minimum pour les opérations de refresh.
dds-default-ttl ‹ttl› TTL par défaut pour les nouveaux objets créés
dds-interval ‹ttl› Interval entre les vérifications d'expiration
dds-tolerance ‹ttl› Spécifie une durée suplémentaire à ajouter au timer qui attend pour supprimer les objets expirés
dds-max-dynamicObjects ‹num› Spécifie le nombre max d'objets dynamiques qui peuvent exister simultanément dans un contexte de nommage.
dds-state TRUE|false Spécifie si la fonctionnalité est activée ou non. Les proxy non pas besoin de gérer ces objets mais necessitent d'informer le frontend du support de ces objets.

Contrôle d'accès

   cet overlay restreint l'opération refresh en nécessitant l'accès manage sur l'attribut entryTtl. Vu que c'est un attribut NO-USER-MODIFICATION, aucune écriture directe n'est possible. l'overlay convertit donc l'opération refresh en une modification interne pour modifier entryTtl avec le jeu de contrôle relax.

La rfc 2589 recommande que les clients anonymes ne devraient pas être autorisés à refresh un objet dynamique:
access to attrs=entryTtl by users manage by * read
Restreindre refresh au créateur de l'objet:
access to attrs=entryTtl by dnattr=creatorsName manage by * read
Assument que Meetings est un attribut de DN valides, permettant aux utilisateurs de commencer une conférence et rafraîchir; empêcher les participant de refresh, et seul le créateur peut le supprimer:
access to dn.base="cn=Meetings" attrs=children by users write
access to dn.onelevel="cn=Meetings" attrs=entry by dnattr=creatorsName write by * read
access to dn.onelevel="cn=Meetings" attrs=participant by dnattr=creatorsName write by users selfwrite by * read
access to dn.onelevel="cn=Meetings" attrs=entryTtl by dnattr=participant manage by * read

Réplication

   Cette implémentation fournie une implémentation réduite de la réplication. Seul les masters peuvent manipuler l'expiration des objets. En répliquant ces objets, on peut explicitement inclure la classe dynamicObjet et l'attribut entryTtl. cette implémentation introduit un nouvel attribut opérationnel, entryExpireTimestamp, qui contient le timestamp d'expiration. Il doit être exclus de la réplication avec:

syncrepl ...
exattrs=entryTtl,entryExpireTimestamp
^
14 septembre 2014

htmlpdflatexmanmd




slapo-denyop

slapo-denyop

Refuser des opérations

   Cet overlay fournis une manière rapide de refuser des opérations. Il est moins consomateur que les ACL parce que son évaluation se produit avant tout backend.

^
14 septembre 2014

htmlpdflatexmanmd




slapo-dsaschema

slapo-dsaschema

Charger un schéma DSA depuis un fichier

   Ce module permet de charger un schéma DSA depuis des fichiers de configuration, incluant des attributs opérationnels.

^
14 septembre 2014

htmlpdflatexmanmd




slapo-dupent

slapo-dupent

LDAP Control for a Duplicate Entry Representation of Search Results

   Ce module implémente le draft LDAP Control for a Duplicate Entry Representation of Search Results

^
12 octobre 2013

htmlpdflatexmanmd




slapo-dyngroup

slapo-dyngroup

Overlay dyngroup

   Overlay de groupes dynamiques. Permet aux clients d'utiliser les opérations compare pour tester l'appartenance à un groupe dynamique.

OPTIONS

attrpair ‹memberAttr› ‹URLattr› Spécifie l'attribut à comparer. une opération de comparaison de memberAttr va évaluer URLattr

Exemples

database bdb
...
overlay dyngroup
attrpair member memberURL
^
12 octobre 2013

htmlpdflatexmanmd




slapo-dynlist

slapo-dynlist

Overlay dynlist

   Overlay de liste dynamique. Permet d'étendre les groupes dynamiques et plus. A chaque fois qu'une entrée avec une classe objet spécifique est retournée, les occurences de valeurs d'URI sont retournés et étendus en entrées correspondantes.

   Vu que le résultat est construit dynamiquement, il n'existe pas tant que la construction n'est pas retournée. En conséquence, les attributs ajoutés dynamiquement ne participent pas dans la partie de match des filtres de recherche. Filtrer des attributs dynamique échouent toujours.

dynlist-attrset ‹group-oc› [‹URI›] ‹URL-ad› [[‹mapped-ad› :]‹member-ad›...] group-oc est le nom de la classe d'objet pour l'extension dynamique. URI restreint l'expensions, URL-ad est l'attribut qui contient l'URI qui est étendue, doit être de type labeledURI. member-ad liste le DN des entrées resultant de la recherche Interne. Si présent la partie attrs des URI dans URL-ad doit être absent. mapped-ad peut être utilisé pour remapper les attributs obtenus.

Autorisation

   Par défaut les expansions sont effectuées en utilisant l'identité de l'utilisateur courant. Cette identité peut être remplacée avec l'attribut dgIdentity dans l'entrée du groupe. Dans ce cas, le dgIdentity sera utilisé. si dgItentity est vide, l'expansion est faite anonymement. Le schéma dyngroup doit être chargé avant d'utiliser cet attribut. si dgAuthz est présent dans l'entrée du groupe, ses valeurs sont utilisées pour déterminer quelles identités sont autorisées à utiliser le dgIdentity pour expandre le groupe.

Exemple

dynlist-attrset groupOfURLs memberURL
Ajouter une entrée:
dn: cn=Dynamic List,ou=Groups,dc=example,dc=com
objectClass: groupOfURLs
cn: Dynamic List
memberURL: ldap:///ou=People,dc=example,dc=com?mail?sub?(objectClass=person)
exemple avec dgIdentity:
dn: cn=Dynamic Group,ou=Groups,dc=example,dc=com
objectClass: groupOfURLs
objectClass: dgIdentityAux
cn: Dynamic Group
memberURL: ldap:///ou=People,dc=example,dc=com??sub?(objectClass=person)
dgIdentity: cn=Group Proxy,ou=Services,dc=example,dc=com
^
14 septembre 2014

htmlpdflatexmanmd




slapo-kinit

slapo-kinit

Demander un TGT

   Ce module permet à slapd de demander un TGT et de le conserver tant que le serveur fonctionne. Ce module accèpte 2 arguments, le principal pour lequel demander le TGT (défaut: ldap/‹hostname›@‹DEFAULTREALM›) et chemin du fichier keytab.

^
14 septembre 2014

htmlpdflatexmanmd




slapo-lastbind

slapo-lastbind

Enregistrer l'heure du dernier bind

   Permet d'enregistrer l'heure du dernier bind réussi des entrées dans l'annuaire, dans l'attribut authTimestamp. L'overlay peut être configuré pour mettre à jour ce timestamp seulement si sa valeur est supérieur à la valeur donnée. Cela réduit le nombre d'écritures.

Configuration

lastbind-precision ‹seconds› La valeur est le nombre de secondes après laquelle mettre à jours l'attribut dans une entrée.
^
14 septembre 2014

htmlpdflatexmanmd




slapo-lastmod

slapo-lastmod

Maintient une entrée de modifications

   Cet overlay crée une entrée de service au suffixe de la base de données, qui maintient le DN, le type de modification, le modifiersName et le modifyTimestamp de la dernière opération d'écriture dans la base. Toutes les opérations ciblant le DN de l'entrée est rejetée, excepté read.

Configuration

lastmod-rdnvalue ‹RDN value› Spécifie le RDN utilisé pour l'entrée de service
lastmod-enabled {yes|no} Active ou non l'overlay


objectClass:
( 1.3.6.1.4.1.4203.666.3.13 " NAME 'lastmod' DESC 'OpenLDAP per-database last modification monitoring' STRUCTURAL SUP top MUST ( cn $ lastmodDN $ lastmodType ) MAY ( description $ seeAlso ) )
attributes:
( 1.3.6.1.4.1.4203.666.1.30 NAME 'lastmodEnabled' DESC 'Lastmod overlay state' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE )
( 1.3.6.1.4.1.4203.666.1.28 NAME 'lastmodDN' DESC 'DN of last modification' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION USAGE directoryOperation )
( 1.3.6.1.4.1.4203.666.1.29 NAME 'lastmodType' DESC 'Type of last modification' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )

^
12 octobre 2013

htmlpdflatexmanmd




slapo-memberof

slapo-memberof

Overlay memberof

   Overlay de group membership.

OPTIONS

memberof-group-oc group-oc Nom de la classe d'objet contenant les members.
memberof-member-ad member-ad Nom de l'attribut contenant les members
memberof-memberof-ad memberof-ad Nom de l'attribut qui contiendra le groupes d'appartenance.
memberof-dn dn DN utilisé comme modifierName pour les modifications interne effectuées pour la mettre à jours le membership.
memberof-dangling [ignore, drop, error] Détermine l'action de l'overlay quand une référence non résolue est rencontrée.
memberof-dangling-error error-code si memberof-dangling est à error, permet de modifier le code de réponse retourné. (défaut: constraint violation)
memberof-refint true Détermine si l'overlay tente de préserver l'intégrité des référentiels. Quand une entrée contenant les valeurs de l'attribut "is member of" est modifié, les groupes correspondant son modifiés également.

   L'attribut "memberOf" n'est pas répliqué, chaque serveur doit configurer cet overlay pour maintenir cet attribut.
^
17 septembre 2014

htmlpdflatexmanmd




slapo-noopsrch

slapo-noopsrch

Implémente le contrôle noop

   Ce module implémente le contrôle no-op.

^
17 septembre 2014

htmlpdflatexmanmd




slapo-nops

slapo-nops

Suppression d'opérations null

   Overlay de suppression d'opération null. Certains clients implémentent les modifications comme opération de remplacement où tous les attributs sont remplacés, la plupart du temps par les même valeurs. Cela augmente la charge. Cet overlay détecte les opérations de ce type et les filtres. Cet overlay n'a pas de configuration.

^
17 septembre 2014

htmlpdflatexmanmd




slapo-nssow

slapo-nssow

Requêtes NSS et PAM via un socket unix

   Il utilise le même protocole IPC que nss-pam-ldapd de Arthur de Jong. Utiliser un protocole IPC séparé pour les demandes NSS et PAM élimine les dépendance libldap dont souffrent les solutions pam_ldap/nss_ldap. Cet overlay s'exécute dans slapd, profitant d'un cache sophistiqué, sans les faiblesses de nscd. Une base LDAP distante peut être accédée en utilisant back-ldap avec un proxy-cache. Un autre bénéfice est que toutes les stratégies de sécurité sont administrées centralement via LDAP.

Configuration

nssov-ssd ‹service› ‹url› Configure un Service Search Descriptor (SSD) pour chaque service NSS qui sera utilisée.
ldap:///[‹basedn›][??[‹scope›][?‹filter›]] Le suffixe de la base, scope et filtre de recherche.
nssov-map ‹service› ‹orig› ‹new› Si la base locale est un proxy, certains mappages du schéma peuvent être nécessaire. Cette directive permet une substitution d'attribut simple.
nssov-pam ‹option› [...] Détermine le nombre de mode PAN. Les options valides sont:

        userhost Vérifie l'attribut host dans l'entrée pour l'autorisation
        userservice Vérifie l'attribut authorizedService dans l'entrée pour l'autorisation
        usergroup Vérifie que l'utilisateur est membre d'un groupe spécifique pour l'autorisation.
        hostservice Vérifie l'attribut authorizedService dans l'entrée pour l'autorisation
        authz2dn Utilise authz-regexp pour mapper l'uid à un DN ldap.
        uid2dn Utilise le SSD passwd NSS pour mapper un uid à un DN ldap.

nssov-pam-defhost ‹hostname› Spécifie un hostname par défaut pour vérifier si une entrée ipHost pour le nom d'hôte courant ne peut pas être trouvé
nssov-pam-group-ad ‹attribute› Spécifie de DN d'un groupe LDAP pour vérifier l'autorisation. L'utilisateur LDAP doit être membre de ce group pour être autorisé à s'authentifier. Il n'y a pas de valeurs par défaut.
nssov-pam-group-ad ‹attribute› Spécifie l'attribut à utiliser pour la vérification au groupe.
nssov-pam-min-uid ‹integer› Spécifie un uid minimum autorisé au login
nssov-pam-max-uid ‹integer› Spécifie un uid maximum autorisé au login
nssov-pam-template-ad ‹attribute› Spécifie un attribut à vérifier dans l'entrée utilisateur pour un template de nom de login.
nssov-pam-template ‹name› Spécifie un nom d'utilisateur pas défaut si aucun attribut template n'est trouvé dans l'entrée utilisateur.
nssov-pam-session ‹service› Spécifie un nom de service PAM dont les sessions seront enregistrés.
nssov-pam-password-prohibit-message ‹message› Désactive le service de changement de mot de passe et retourne le message spécifié aux utilisateurs
nssov-pam-pwdmgr-dn ‹dn› Spécifie le dn du responsable des mots de passe
nssov-pam-pwdmgr-pwd ‹pwd› Spécifie le mot de passe du responsable des mots de passe

loginStatus

   Attribut opérationnel de l'entrée utilisateur. Les valeurs de l'attribut sont sous la forme ‹generalizedTime› ‹host› ‹service› ‹tty› (‹ruser@rhost›). À la déconnexion, la valeur correspondante est supprimée. Cela permet de vérifier si des utilisateur sont loggés sur tous les hôtes du réseau via un ldapsearch. Le rootdn de la base est utilisée pour effectuer les mises à jours de cet attribut, donc un rootdn doit toujours être configuré pour que cette fonctionnalité fonctionne.

  Les fonctions PAM supportent LDAP password Policy également. Si l'overlay password policy est utilisé, les informations de stratégie peuvent être retournés au client PAM en résultat de l'authentification, gestion du compte, et demande de changement de mot de passe.

Exemple:
dn: olcOverlay={0}nssov,ocDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcNssOvConfig
olcOverlay: {0}nssov
olcNssSsd: passwd ldap:///ou=users,dc=example,dc=com??one
olcNssMap: passwd uid accountName
olcNssPam: hostservice uid2dn
olcNssPamDefHost: defaulthost
olcNssPamMinUid: 500
olcNssPamMaxUid: 32000
olcNssPamSession: login
olcNssPamSession: sshd

^
12 octobre 2013

htmlpdflatexmanmd




slapo-pbind

slapo-pbind

Overlay pbind

   Permet de forwarder les simple binds sur une base local à un serveur LDAP distant au lieu de les traiter localement.

OPTIONS

uri ‹ldapurl› Serveur ldap à utiliser
tls ‹TLS parameters› Paramètres TLS à utiliser
network-timeout ‹time› Timeout en secondes
quarantine ‹quarantine parameters› met en quarantaine les URI qui ont retourné LDAP_UNAVAILABLE
^
12 octobre 2013

htmlpdflatexmanmd




slapo-pcache

slapo-pcache

Overlay pcache

   Overlay de proxy cache. Permet de mettre en cache les requêtes LDAP dans une base locale. Pour chaque requêtes, il détermine si elle correspond à un template.

OPTIONS

pcache ‹database› ‹max_entries› ‹numattrsets› ‹entry_limit› ‹cc_period› Active le proxy cache dans la base courante Un backend ‹database› sera utilisé en interne pour maintenir les entrées. ‹max_entries› écrase le cache quand le nombre d'entrées est atteint. numattrsets devrait être égal au nombre de directives pcacheAttrset. Les requêtes sont en cache uniquement si elles matchent un template et que le résultat retourné est inférieur à entry_limit. La vérification de consistance est effectuée toutes les cc_period en seconde.
pcacheAttrset ‹index› ‹attrs...› Utilisé pour associer un jeu d'attributs avec un index. Chaque jeu d'attribut est associé avec un entier de 0 à numattrsets-1. Ces indices sont utilisé par pcacheTemplate pour définir les templates cachable. (un jeu d'attribut de "1.1" spécifie que seul la présence de l'entrée en mise en cache)
pcacheMaxQueries ‹queries› Spécifie le nombre max de requêtes à mettre en cache.
pcacheValidate TRUE | FALSE Vérifie sur les résultats en cache peuvent être retournés du cache par le proxy. a TRUE, s'assure de la consistance avec le schéma connu du proxy.
pcacheOffline TRUE | FALSE Définis le cache en mode offline. La vérification de la consistance est stoppée et aucune expiration ne se produit.
pcachePersist TRUE | FALSE Spécifie si les résultats en cache devraient être sauvegardés entre les redémarrages.
pcacheTemplate ‹template_string› ‹attrset_index› ‹ttl› [‹negttl›[‹limitttl› [‹ttr›]]] Spécifie un template de mise en cache, et un TTL. negttl peut être utilisé pour spécifier que les résultats négatifs devraient également être mis en cache. limitttl peut être utilisé pour spécifier que les résultat qui atteignent le limitttl devraient aussi être mis en cache. un ttr optionnel peut être utilisé que les résultats en cache devraient seulement être rafraîchis après un certain temps. Les entrées sont rafraichis seulement s'ils n'ont pas expirés, dont ttl doit être plus grand que ttr.
pcacheBind ‹filter_template› ‹attrset_index› ‹ttr› ‹scope› ‹base› Spécifie un template pour cacher les crédentials simple bind basé sur un pcacheTemplate existant. filter_template est similaire à template_string excepté qu'il peut avoir certaines valeurs présentes.
pcachePosition head | tail Spécifie si la réponse devrait être placé en bas ou en haut de la liste d'appel. Celà affecte la manière dont cet overlay interagis avec d'autres.

Contraintes

   Toutes les valeurs doivent être positives entry_limit devrait être définies en utilisant la directive pcacheAttrset tous les jeux d'attributs devraient être référencés par au moins une directive pcacheTemplate.

Exemple

Ajouter un template avec une chaîne de recherche ($(sn=)(givenName=)) et les attributs mail, postalAddress, telephoneNumber et un TTL de 1 heure:
pcacheAttrset 0 mail postaladdress telephonenumber
pcacheTemplate (&(sn=)(givenName=)) 0 3600
^
12 octobre 2013

htmlpdflatexmanmd




slapo-ppolicy

slapo-ppolicy

Overlay ppolicy

   Overlay de stratégie de mot de passe. Il intercepte et applique des contrôles de mot de passe.

OPTIONS

ppolicy_default ‹policyDN› DN de l'objet pwdPolicy à utiliser quand aucune stratégie n'est définie dans l'entrée de l'utilisateur.
ppolicy_forward_updates Spécifie que les changements d'état de stratégie qui résultent des opérations bind devraient être forwardés à un master au lieu d'être écrit directement dans la base local.
ppolicy_hash_cleartext Spécifie que les mots de passe en clair devraient être hashés. celà viole le modèle d'information X500 mais peut être utile pour les clients qui n'utilisent pas l'opération étendue Password Modify.
ppolicy_use_lockout Un client reçoit toujours une réponse InvalidCredentials lors d'un bind avec un compte bloqué. Cette option change le code de réponse pour inclure AccountLocked. Noter que ce code fournis des informations à un attaquant.

Schéma

pwdPolicy utilisé par l'overlay
pwdPolicyChecker Utilisé pour vérifier la qualité des mots de passe.
pwdAttribute Contient le nom de l'attribut où la stratégie de mot de passe s'applique. (accèpte uniquement userPassword)
pwdMinAge Secondes minimum entre chaque modifications permises
pwdMaxAge Secondes maximum entre chaque modifications permises
pwdInHistory Nombre d'historique de mots de passe à conserver.
pwdCheckQuality Indique si et comment la syntaxe de mot de passe sera vérifiée. 0 pas de vérification, 2, vérifie la syntaxe et si le serveur ne peut pas le vérifier, dû à un mot de passe hashé, il sera accepté. 2 le serveur doit pouvoir vérifier la syntaxe.
pwdMinLength Nombre minimum de caractère du mot de passe
pwdExpireWarning secondes avant expiration où le serveur envoie un message d'avertissement
pwdGraceAuthnLimit Nombre de fois q'un mot de passe expiré peut être utilisé pour authentifier un utilisateur
pwdLockout Action à prendre quand un utilisateur a échoue l'authentification pwdMaxFailure fois. a TRUE, l'utilisateur ne pourra plus s'authentifier.
pwdLockoutDuration Durée en seconde pendant laquelle l'utilisateur ne peut pas s'authentifier après pwdMaxFailure échecs d'authentification.
pwdMaxFailure Nombre d'authentifications consécutives échouées.
pwdFailureCountInterval Secondes avant que le comptes d'échec d'authentification soit purgé.
pwdMustChange A TRUE, spécifie que l'utilisateur doit changer son mot de passe une fois authentifié.
pwdAllowUserChange Spécifie si l'utilisateur peut changer son mot de passe ou non. ( les ACL devraient être utilisés à la place de cet attribut)
pwdSafeModify a TRUE, le mot de passe et le nouveau mot de passe doivent être envoyés en même temps.
pwdCheckModule Nomme un module qui doit instancier la fonction check_password().
userPassword (opérationnel) Contient le mot de passe de l'utilisateur
pwdPolicySubentry (opérationnel) réfère directement à pwdPolicy
pwdChangedTime (opérationnel) Date de dernier changement de mot de passe
pwdAccountLockedTime (opérationnel) date à laquelle le compte a été bloqué. (000001010000Z indique que le compte est bloqué de manière permanente).
pwdFailureTime (opérationnel) Date de chaque échec d'authentification.
pwdHistory (opérationnel) Contient l'hitorique des derniers mots de passe utilisés.
pwdGraceUseTime (opérationnel) Date des logins effectués après que le mot de passe ait expiré.
pwdReset (opérationnel) Indique que le mot de passe a été réinitialisé par un administateur (il doit être changé à la prochaine authentification)


( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'pwdPolicy' AUXILIARY SUP top MUST ( pwdAttribute ) MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthnLimit $ pwdLockout $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) )
    
( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' AUXILIARY SUP top MAY ( pwdCheckModule ) )
    
( 1.3.6.1.4.1.42.2.27.8.1.1 NAME 'pwdAttribute' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
    
( 1.3.6.1.4.1.42.2.27.8.1.2 NAME 'pwdMinAge' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.3 NAME 'pwdMaxAge' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.4 NAME 'pwdInHistory' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.5 NAME 'pwdCheckQuality' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.6 NAME 'pwdMinLength' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.7 NAME 'pwdExpireWarning' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.8 NAME 'pwdGraceAuthnLimit' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.9 NAME 'pwdLockout' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.10 NAME 'pwdLockoutDuration' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.11 NAME 'pwdMaxFailure' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.12 NAME 'pwdFailureCountInterval' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.13 NAME 'pwdMustChange' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.14 NAME 'pwdAllowUserChange' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.15 NAME 'pwdSafeModify' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
    
( 1.3.6.1.4.1.4754.1.99.1 NAME 'pwdCheckModule' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.23 NAME 'pwdPolicySubentry' DESC 'The pwdPolicy subentry in effect for this object' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.16 NAME 'pwdChangedTime' DESC 'The time the password was last changed' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.17 NAME 'pwdAccountLockedTime' DESC 'The time an user account was locked' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.19 NAME 'pwdFailureTime' DESC 'The timestamps of the last consecutive authentication failures' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch NO-USER-MODIFICATION USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.20 NAME 'pwdHistory' DESC 'The history of user passwords' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 EQUALITY octetStringMatch NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.21 NAME 'pwdGraceUseTime' DESC 'The timestamps of the grace login once the passwordhas expired' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.22 NAME 'pwdReset' DESC 'The indication that the password has been reset' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation)

^
12 octobre 2013

htmlpdflatexmanmd




slapo-refint

slapo-refint

Overlay refint

   Overlay d'intégrité de référentiel. Permet de maintenir une cohérence d'un schéma avec des attributs référence. Il permet de mettre à jours la base lors d'opérations modrdn ou delete.

OPTIONS

refint_attributes ‹attribute› [...] Spécifie les attributs où l'intégrité doit être maintenue.
refint_nothing ‹string› Spécifie une valeur arbitraire à utiliser lors d'une suppression dans un attribut qui impose d'avoir une valeur.
refint_modifiersname ‹DN› DN à utiliser comme modifierName des modifications internes effectuées par l'overlay.
^
12 octobre 2013

htmlpdflatexmanmd




slapo-retcode

slapo-retcode

Overlay retcode

   Utile pour des tests, les réponses sont générées en accord avec différentes stratégies. Dans le premier cas, pour toutes les opérations ciblées dans une sous-arborecence, la recherche est effectuées et vérifiée pour le code de retour, plus un message textuel optionnel. Les codes de réponse connus sont fournis dans retcodes.conf. Dans le second cas, les classes d'objet qui héritent de errAbsObject comme errObject ou errAuxObject, retournent un code dicté par ce contenu. Un Troisième cas recherche l'objet dans une base pour découvrir si leur classe hérite de errAbsObject. Dans ce cas, leur contenu est utilisé pour calculer la réponse correspondante. Désactivé en utilisant le contrôle manageDSAit.

OPTIONS

retcode-parent ‹DN› Définis le DN parent où les entrées générées dynamiquement résident.
retcode-item ‹RDN› ‹errCode› [op=‹oplist›] [text=‹message›] [ref=‹referral›] md
[unsolicited=‹OID›[ :‹data›]] [flags=[pre|post-]disconnect[,...]] Une entrée générée dynamiquement sous retcode-parent. errCode est le numéro du code de réponse. oplist est une liste d'opérations qui génère la génération du code. matched est le DN matché qui est retourné avec l'erreur. text est le message optionnel, ref est permis pour le code referral. sleeptime secondes avant de traiter l'opération. unsolicited peut être utilisé pour forcer un message de réponse unsolicited rfc4511. OID si non 0, génère une réponse étendue avec data ajouté. flags contient disconnect ou pre-disconnect (fore la déconnection sans notification) ou post-disconnect (déconnection après avoir envoyé la réponse)
retcode-indir Active l'exploitation de errAbsObject.
retcode-sleep [-]‹n› Secondes d'attente avant de manipuler les opérations. une valeur négative indique une valeur aléatoire entre 0 et la valeur indiquée.

Schéma

Le code d'erreur:
( 1.3.6.1.4.1.4203.666.11.4.1.1 NAME ( 'errCode' ) DESC 'LDAP error code' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

L'opération qui déclenche le code de réponse:
( 1.3.6.1.4.1.4203.666.11.4.1.2 NAME ( 'errOp' ) DESC 'Operations the errObject applies to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

le message textuel:
( 1.3.6.1.4.1.4203.666.11.4.1.3 NAME ( 'errText' ) DESC 'LDAP error textual description' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

Temps d'attente avant de retourner la réponse:
( 1.3.6.1.4.1.4203.666.11.4.1.4 NAME ( 'errSleepTime' ) DESC 'Time to wait before returning the error' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

DN retourné au client:
( 1.3.6.1.4.1.4203.666.11.4.1.5 NAME ( 'errMatchedDN' ) DESC 'Value to be returned as matched DN' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )

OID retourné comme réponse étendue unsolicited responses:
( 1.3.6.1.4.1.4203.666.11.4.1.6 NAME ( 'errUnsolicitedOID' ) DESC 'OID to be returned within unsolicited response' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE )

Chaîne d'octet à retourner comme donnée de réponse étendue:
( 1.3.6.1.4.1.4203.666.11.4.1.7 NAME ( 'errUnsolicitedData' ) DESC 'Data to be returned within unsolicited response' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )

Mode de déconnexion:
( 1.3.6.1.4.1.4203.666.11.4.1.8 NAME ( 'errDisconnect' ) DESC 'Disconnect without notice' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )

Déclencheur de l'overlay:
( 1.3.6.1.4.1.4203.666.11.4.3.0 NAME ( 'errAbsObject' ) SUP top ABSTRACT MUST ( errCode ) MAY ( cn $ description $ errOp $ errText $ errSleepTime $ errMatchedDN ) )
    
( 1.3.6.1.4.1.4203.666.11.4.3.1 NAME ( 'errObject' ) SUP errAbsObject STRUCTURAL )
    
( 1.3.6.1.4.1.4203.666.11.4.3.2 NAME ( 'errAuxObject' ) SUP errAbsObject AUXILIARY )

Exemples

retcode.conf se trouve dans tests/data/
include ./retcode.conf
Attendre 10 secondes, puis retourner un succès (0x00)
retcode-item "cn=Success after 10 seconds" 0x00 sleeptime=10
Attendre 10 secondes, puis retouner timelimitExceeded (0x03)
retcode-item "cn=Timelimit after 10 seconds" 0x03 sleeptime=10
^
12 octobre 2013

htmlpdflatexmanmd




slapo-rwm

slapo-rwm

Overlay rwm

   Overlay rewrite/remap. Permet d'effectuer des réécritures basiques de DN données et des mapping d'attribut/classe d'objet.

Mapping

rwm-map {attribute | objectclass} ‹local name› {‹foreign name› | *} Map les attributeTypes et les objectClasse.
rwm-normalize-mapped-attrs {yes|no} à yes, rwm tente de normaliser les valeurs des attributs mappés (utile lors que les attributs distant sont inconnus du serveur)
rwm-drop-unrequested-attrs {yes|no} à yes, rwm drop les attributs qui ne sont pas explicitement demandés par une opération de recherche.

Suffix Massaging

   Permet de mapper un contexte de nommage réel et virtuel. Permet par exemple de créer des vues virtuelles.

rwm-suffixmassage [‹virtual naming context›] ‹real naming context› Réecriture de contexte de nommage.

Rewriting

   Une chaîne est réécrite en fonction d'un jeu de règles, appelé un contexte de réécriture. Les règles sont basé sur des expressions régulières étendue POSIX avec correspondance de sous-chaîne.

‹rewrite context›::= ‹rewrite rule› [...]
‹rewrite rule›::= ‹pattern› ‹action› [‹flags›]

Passes

   Une chaîne entrante est matchée avec un jeu de rewriteRules. Les règles sont faites de regex match pattern, un substitution pattern et un jeu d'actions, décris par un jeu de flags optionnels. En cas de correspondance, la réécriture de chaîne est effectuée en accord avec le motif de substitution qui permet de référer à une sous-chaîne matchée dans la chaîne. Chaque règle est exécutée récursivement Un mappage est un objet générique qui map un motif de substitution à une valeur. Les flags sont divisés en "Pattern Matching Flags" et en "Action Flags".

Pattern Matching Flags

C respecte la casse
R Utilise les expressions régulière POSIX standard.
M{n} Ne permet pas plus de n récursion pour un règle.

Action Flags

: Applique la règle une seule fois (pas de récursion)
@ Arrête d'appliquer une règle en cas de correspondance
# Stop l'opération courante si la règle correspond et retourne un unwilling to perform
G{n} Saute n règles en arrière
I Ignore les erreurs dans les règles
U{n} Utilise n comme code de retour si la règle match.

Substitution Pattern Syntax

   Tout ce qui commence avec '$' nécessite une substitution. La seule exception est '$$', qui est retourné en un simple '$'. La substitution de base est '$‹d›', où ‹d› est un chiffre; 0 signifie toute la chaîne, de 1 à 9 pour des submatch.

un '$' suivi d'un '{' invoque une substitution avancée:
'$' '{' [ ‹operator› ] ‹name› '(' ‹substitution› ')' '}'

‹name›::= [a-z][a-z0-9]* (case insensitive)
‹operator›::= '›' '|' '&' '&&' '*' '**' '$'

‹substitution› doit être un motif de substitution valide, sans limite de niveau d'imbrication. les opérateurs sont:

        Invocation de sous-contexte
        | Invocation de commande externe
        & Assignement de variable
        Déréferencement de variable
        $ Déréférencement de paramètre

Rewrite Context

   Un contexte de réécriture est un jeu de règles qui sont appliquées en séquence. Quand une réécriture de chaîne est requise, on invoque le contexte de réécriture appropriée. Chaque opération serveur de base est associée à un contexte de réécriture, ils sont divisés en 2 groupes principaux: client -› serveur et serveur -› client:

Client->serveur

(default) Si définis et sans contexte spécifique
bindDN bind
searchDN search
searchFilter search
searchFilterAttrDN search
compareDN compare
compareAttrDN compare AVA
addDN add
addAttrDN add AVA (DN portion of "ref" excluded)
modifyDN modify
modifyAttrDN modify AVA (DN portion of "ref" excluded)
referralAttrDN add/modify DN portion of referrals
renameDN modrdn (the old DN)
newSuperiorDN modrdn (the new parent DN, if any)
newRDN modrdn (the new relative DN)
deleteDN delete
exopPasswdDN password modify extended operation DN

Serveur->client

searchEntryDN search (seulement si défini, pas de défaut, agis sur le DN des entrées recherchées)
searchAttrDN search AVA (seulement si défini, défaut sur searchEntryDN, agis sur les attributs type DN des entrées recherchées)
matchedDN all ops (Seulement si applicable; défaut à searchEntryDN)
referralDN all ops (Seulement si applicable; défaut: none)

Basic Configuration Syntax

rwm-rewriteEngine { on | off } Autorise la réécriture
rwm-rewriteContext ‹context name› [ alias ‹aliased context name› ] ‹Context Name› est le nom qui identifie le contexte, par ex le nom utilisé par l'application pour référer au jeu de règles qu'il contient. Un contexte peut être un alias d'un autre. Dans ce cas il ne contient pas de règle.
rwm-rewriteRule ‹regex match pattern› ‹substitution pattern› [ ‹flags› ] Détermine comment une chaîne peut être réécrite si un motif est matché.

Additional Configuration Syntax

rwm-rewriteMap ‹map type› ‹map name› [ ‹map attrs› ] Permet de définir un map qui transforme des réécritures en quelque chose d'autre. Le map est référencé dans le motif de substitution d'une règle.
rwm-rewriteParam ‹param name› ‹param value› Définis une valeur avec un scope global, qui peut être dé-référencé par la commande ${$paramName}
rwm-rewriteMaxPasses ‹number of passes› [‹number of passes per rule›] Définis un nombre maximum de réécritures totales en une seul opération de réécriture.

Maps

   les mappages supportés sont:

LDAP ‹URI› [bindwhen=‹when›] [version=‹version›] [binddn=‹DN›] [credentials=‹cred›] Étend la valeur en effectuant une simple recherche LDAP. bindwhen détermine quand la connection est établie (now - créée au démarrage, later - quand nécessaire, everytime - a chaque fois).
slapd ‹URI› étend une valeur en effectuant une recherche LDAP interne.

Exemple

activer le rewriting
rwm-rewriteEngine on
Tous les flux de données du client vers le serveur référrant au DN
rwm-rewriteContext default
rwm-rewriteRule "(.+,)?‹virtualnamingcontext›$" "$1‹realnamingcontext›" ":"
Règle de filtre vide
rwm-rewriteContext searchFilter
Tous les flux de données du serveur vers le client
rwm-rewriteContext searchEntryDN
rwm-rewriteRule "(.+,)?‹realnamingcontext›$" "$1‹virtualnamingcontext›" ":"
rwm-rewriteContext searchAttrDN alias searchEntryDN
rwm-rewriteContext matchedDN alias searchEntryDN
Diverses règles vides
rwm-rewriteContext referralAttrDN
rwm-rewriteContext referralDN
Tout ce qui est définis ici va dans le contexte default. Change le contexte de nommage de tout ce qui est envoyé
rwm-rewriteRule "(.+,)?dc=home,[ ]?dc=net$" "$1dc=OpenLDAP, dc=org" ":"
Commence un nouveau contexte (termine l'entrée du précédent) Ajoute un blanc entre les parties du DN si non présent
rwm-rewriteContext addBlanks
rwm-rewriteRule "(.*),([^ ].*)" "$1, $2"
Celui-ci supprime les blanc:
rwm-rewriteContext eatBlanks
rwm-rewriteRule "(.*), (.*)" "$1,$2"
Chaque contrôle revient au context default, les règles sont ajoutée à celles existantes, et pipe dans addBlanks:
rwm-rewriteContext default
rwm-rewriteRule ".*" "${›addBlanks($0)}" ":"
Réecrit la base de recherche sur les règles default:
rwm-rewriteContext searchDN alias default
Les résultats de recherche avec un DN openldap sont réecris avec dc=home,dc=net.
rwm-rewriteContext searchEntryDN
rwm-rewriteRule "(.*[^ ],)?[ ]?dc=OpenLDAP,[ ]?dc=org$" "${›eatBlanks($1)}dc=home,dc=net" ":"
Bind avec le mail au lieu du DN. on fait un map ldap qui transforme les attributs en DN
rwm-rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub"
puis on détecte le DN fait d'un simple email.
rwm-rewriteContext bindDN
rwm-rewriteRule "^mail=[^,]+@[^,]+$" "${attr2dn($0)}" ":@I"
exemple plus sophistiqué
rwm-rewriteContext bindDN
rwm-rewriteRule ".+" "${&&binddn($0)}$0" ":"
# A search filter containing 'uid=' is rewritten only if an appropriate DN is bound. To do this, in the first rule the bound DN is
# dereferenced, while the filter is decomposed in a prefix, in the value of the 'uid=‹arg›' AVA, and in a suffix. A tag '‹›' is appended to the DN.
# If the DN refers to an entry in the 'ou=admin' subtree, the filter is rewritten OR-ing the 'uid=‹arg›' with 'cn=‹arg›'; otherwise it is left as is. This could be
# useful, for instance, to allow apache's auth_ldap-1.4 module to authenticate users with both 'uid' and 'cn', but only if the request comes from a possible
# 'cn=Web auth,ou=admin,dc=home,dc=net' user.
rwm-rewriteContext searchFilter
rwm-rewriteRule "(.*\\()uid=([a-z0-9_]+)(\\).*)" "${**binddn}‹›${&prefix($1)}${&arg($2)}${&suffix($3)}" ":I"
rwm-rewriteRule "^[^,]+,ou=admin,dc=home,dc=net$" "${*prefix}|(uid=${*arg})(cn=${*arg})${*suffix}" ":@I"
rwm-rewriteRule ".*‹›$" "${*prefix}uid=${*arg}${*suffix}" ":"
# This example shows how to strip unwanted DN-valued attribute values from a search result; the first rule matches DN values below "ou=People,dc=example,dc=com";
# in case of match the rewriting exits successfully. The second rule matches everything else and causes the value to be rejected.
rwm-rewriteContext searchEntryDN
rwm-rewriteRule ".+,ou=People,dc=example,dc=com$" "$0" ":@"
rwm-rewriteRule ".*" "" "#"

Exemple de mapping

map objectclass groupOfNames groupOfUniqueNames
map attribute uniqueMember member
Jeu d'attribut limité, map cn, sn, manager, description a eux-même, tous les autres sont supprimés.
map attribute cn *
map attribute sn *
map attribute manager *
map attribute description *
map attribute *
^
12 octobre 2013

htmlpdflatexmanmd




slapo-sssvlv

slapo-sssvlv

Overlay sssvlv

   Implémente la RFC2891 et le contrôle de liste virtuelle. Remplace également l'implémentation de la RFC2696 pour s'assurer qu'il fonctionne bien avec le trie.

OPTIONS

sssvlv-max ‹num› Nombre maximum de requêtes de trie simultané permis parmis toutes les connections
sssvlv-maxkeys ‹num› Nombre maximum de requêtes triées simultanées parmis toutes les connections.
sssvlv-maxperconn ‹num› Nombre maximum de recherche paginée simultanées par connection.
^
12 octobre 2013

htmlpdflatexmanmd




slapo-syncprov

slapo-syncprov

Overlay syncprov

   Implémente la RFC4533 et le support pour la réplication syncrepl. Peut être utilisé avec tout backend qui supporte entryCSN et entryUUID. Il créé également un attribut contextCSN dans l'entrée root de la base. le contextCSN est mis à jours à chaque opération d'écriture effectuée dans la base. Pour réduire les accès, la mise à jours n'est effectuée qu'en ram. des checkpoints peuvent être configurés pour écrire dans la base.

OPTIONS

syncprov-checkpoint ‹ops› ‹minutes› délay d'écriture du contextCSN au bout de ops opérations ou au bout de minutes écoulés
syncprov-sessionlog ‹ops› Configure un log de session en mémoire pour enregistrer les informations d'écriture faites dans la base. ops est le nombre d'opération enregistrées dans la base.
syncprov-nopresent TRUE | FALSE spécifie sie la phase Present du rafraichissement doit être ignorée. Utile seulement pour une instance syncprov au dessus d'une base de log.
syncprov-reloadhint TRUE | FALSE Spécifie que l'overlay devrait honorer le flag reloadHint dans le contrôle Sync.
^
12 octobre 2013

htmlpdflatexmanmd




slapo-translucent

slapo-translucent

Overlay translucent

   Proxy transparent. Les entrées récupérées depuis un serveur distant peuvent avoir certains attributs remplacés, ou ajoutés par des entrées dans la base locale avant d'être présentés au client. Une opération compare va effectuer une comparaison avec des attributs définis dans une base locale avant toute comparaison avec une donnée distante.

OPTIONS

translucent_strict par défaut, les tentatives de supprimer des attributs sont ignorés silencieusement. cette directive renvoie une constraint Violation
translucent_no_glue Désactive la création automatique des records "glue" pour une opération add ou modrdn tel que tous parents d'une entrée ajoutée à la base locale doit être créée à la main. ces enregistrements sont toujours créés pour une opération modify.
translucent_local ‹attr[,attr...]› Spécifie une liste d'attributs qui devraient être recherchés dans la base locale quand ils sont utilisés dans un filtre de recherche. par défaut, les filtres de recherche ne sont manipulés que par les serveurs distant.
translucent_remote ‹attr[,attr...]› Spécifie une liste d'attributs qui devraient être recherchés dans une base distante quand ils sont utilisés dans un filtre de recherche. par défaut, les filtres de recherche ne sont manipulés que par les serveurs distant
translucent_bind_local Permet de chercher les crédentials stockés localement pour les simple bind quand les bind distant échouent.
translucent_pwmod_local Permet les opérations étendu de modification de mot de passe sur les crédentials stockés localement. Ne s'applique qu'aux entrées présent dans la base distante.

Contrôle d'accès

   Le contrôle d'accès est délégué soit au DSA distant ou au backend local pour les opération auth et write. Il est délégué au DSA distant et au frontend pour les opérations read. Cet overlay va désactiver la vérification du schéma dans la base local, les entrées ayant des attributs d'overlay doivent adhérer au schéma complet.
^
12 octobre 2013

htmlpdflatexmanmd




slapo-unique

slapo-unique

Overlay unique

   Permet de forcer l'unicité de certains attributs dans un scope.

OPTIONS

unique_uri ‹[strict ][ignore ]URI[URI...]...› (olcUniqueURI) Configure la base, les attributs, scope et filtre pour la vérification de l'unicité. Plusieurs URI peuvent être spécifiés. ignore permet de vérifier l'unicité sur tous les attribut excepté ceux définis. strict force l'unicité, même pour les valeurs null. (ex: ldap:///?cn?sub?(sn=e*) vérifie l'unicité de cn pour tous les objets dont sn commence par un e)
^
12 octobre 2013

htmlpdflatexmanmd




slapo-valsort

slapo-valsort

Overlay valsort

   Permet de trier les valeurs des attributs multi-valués.

OPTIONS

valsort-attr ‹attribute› ‹baseDN› (‹sort-method› | weighted [‹sort-method›]) Configure une méthode de trie pour l'attribut spécifié. sort-method peut être alpha-ascend, alpha-descend, numeric-ascend ou numeric-descend. Si la methode spécial weighted est spécifiée, une 2eme méthode peut aussi être spécifiée.

Exemples

overlay valsort
valsort-attr member ou=groups,dc=example,dc=com alpha-ascend
Pour invoquer ldapsearch avec ce contrôle, la valeur doit être définie. Les octets suivant représentent l'encodage désiré:
0x30 0x03 0x01 0x01 0xff
le contrôle peut être envoyé en utilisant la valeur encodé en base 64:
ldapsearch -E 1.3.6.1.4.1.4203.666.5.14=::MAMBAf8=
^
08 septembre 2013

htmlpdflatexmanmd




slappasswd

slappasswd

Utilitaire de gestion de mot de passe openldap. Il permet de générer des valeurs userPassword, rootpw ou olcRootPW

OPTIONS

-v mode verbeux
-u Génère des valeurs RFC23077
-s secret Le secret à hasher
-g génère le secret
-T "file" Hash le contenu du fichier
-h "scheme" Si -h, un des schemas RFC2307 peut être utilisé: CLEARTEXT,CRYPT,MD5,SMD5,SSHA,etSHA
-c crypt-salt-format Spécifie le format du salt passé à crypt(3). Cette chaîne doit être au format sprintf(3) et peut inclure un %s. (ex : ’%.2s’ fournis un salt à 2 caractères, et ’$1$%.8s’ demande d’utiliser MD5 avec 8 caractères aléatoire.) défaut pour %s : 31 caractères de salt
-n  Omet les nouvelles lignes
-o option[=value] Spécifie une option slapd (module-path=‹pathspec› et module-load=‹filename›)

limitations

   Stocker les mots de passe dans userPassword viole la RFC4519. Utiliser authPassword (rfc3112).
^
08 septembre 2013

htmlpdflatexmanmd




slapschema

slapschema

Vérifie le schéma in-database de slapd

OPTIONS

-a filter Dump seulement les entrées correspondant au filtre
-b suffix Utilise le suffix spécifié pour déterminer quelle base utiliser
-c Ignore les erreurs et continue
-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-g Désactive le gluing subordonné. Seul la base spécifiée sera traitée et non ses subordonnées attachés
-H URI
-l ldif-file Écrit la sortie dans le fichier spécifié
dbnum Ajoute des entrées dans la dbnum-ième base listée dans la configuration. Ne peut pas être utilisé avec -b
-o option[=value] Spécifie une option slapd
-s subtree-dn Dump seulement les entrées dans la sous-arborescence spécifiée par ce DN
-v mode verbeux

limitations

   Pour certains types de backend, slapd ne devrait pas être en cours de fonctionnement, du moins en lecture seule.
^
08 septembre 2013

htmlpdflatexmanmd




slaptest

slaptest

Vérifie la configuration de slapd

OPTIONS

-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
dbnum Ajoute des entrées dans la dbnum-ième base listée dans la configuration.
-o option[=value] Spécifie une option slapd
-Q Mode très silencieux
-u dry-run n’échoue pas si la base ne peut pas être ouverte
-v mode verbeux
^
24 mars 2017

htmlpdflatexmanmd




ANSI-INCITS_359-2004

ANSI-INCITS_359-2004

Le modèle de contrôle d'accès basé sur des rôles

Scope

   Ce standard consiste de 2 parties - le modèle de référence RBAC, et la spécification fonctionnelle système et administrative de RBAC.

   Le modèle de référence RBAC définis un jeu d'éléments de base RBAC (par exemple, des utilisateurs, des rôles, des permissions, opérations et objets) et les relations comme les types et fonctions qui sont incluses dans ce standard. Le modèle de référence RBAC sert 2 buts. D'abord, il référence le périmètre des fonctionnalités RBAC qui sont incluses dans le standard. Il identifie le jeu minimum de fonctionnalités inclus dans tous les système RBAC, les aspects de la hiérarchie de rôle, de relations de contraintes statiques, et de relations de contraintes dynamiques. Ensuite, le modèle de référence fournis un langage précis et consistant, en termes de jeux d'éléments et de fonctions à utiliser pour la définition de spécification fonctionnelles.

   Le système RBAC et la spécification fonctionnelle système et administrative RBAC spécifient les fonctionnalités qui sont requises d'un système RBAC. Ces fonctionnalités remplissent 3 catégories, les opérations administratives, les revues administratives, et la fonctionnalité de niveau système. Les opérations administratives définissent les fonctions en terme d'interface administrative et un jeu associé de sémantiques qui fournissent la capacité de créer, supprime et maintenir des éléments RBAC et des relations (ex, pour créer et supprimer des assignements de rôle utilisateur). Les fonctionnalités de revue administratives définissent des fonction en terme d'interface administratives et un jeu associé de sémantiques qui fournissent la capacité d'effectuer des opérations de requêtes sur des éléments et des relations RBAC. La fonctionnalité niveau système définie les fonctionnalité pour la création de sessions utilisateurs pour inclure l'activation/désactivation de rôles, les contraintes forcées dans l'activation de rôle, et pour le calcul d'une décision d'accès.

Conformité

   Toutes les fonctionnalités RBAC ne sont pas appropriées pour toutes les applications. Ce standard fournis une méthode de packaging de fonctionnalité via la sélection de composants fonctionnels et optionnels dans un composant, commençant avec un jeu cœur des fonctionnalité RBAC qui doivent être inclus dans tous les packages.

Conformité

   Pour ce conformer à ce standard, un système RBAC doit être conforme avec tout le jeu core des spécification fonctionnelles RBAC dans la clause 6.1. La conformité d'un système RBAC à d'autres spécification fonctionnelles pour un composant particulier et options, trouvés dans les clauses 6.2 à 6.4, est optionnel et dépendent des exigences fonctionnelles d'une application particulière.

Termes et définitions

Composant réfère à un des blocks majeurs des fonctionnalités RBAC.
Objets Peut être une ressource système sujet à contrôle d'accès, tel qu'un fichier, une imprimante, etc.
Opérations image exécutable d'un programme, qui à l'invocation exécute une fonction pour l'utilisateur.
Permissions Approbation pour effectuer une opération dans un ou plusieurs objets Protégés par RBAC.
role job d'un humain. bien que le concept d'utilisateur peut être étendus pour inclure des machines, réseaux, etc., la définition est limitée à une personne dans ce document.

Le modèle de référence RBAC

   Il est définis en terme de 4 composants: le cœur RBAC, La hiérarchie RBAC, séparation statique des privilèges, et séparation dynamique des privilèges. Le cœur RBAC définis une collection minimum d'éléments RBAC, de jeux d'éléments, et des relations pour achever le système RBAC. Cela inclus l'assignement de rôle utilisateur et les relations d'assignement permission/rôle, considérés comme fondammental dans un système RBAC. De plus, le cœur RBAC introduit le concept d'activation de rôle comme faisant partie d'une session utilisateur. Le cœur RBAC est requis dans tout système RBAC, mais les autres composants sont indépendants des autres et peuvent être implémentés séparémments.

   La hiérarchie RBAC ajoute les relations pour supporter les hiérarchies de rôle. Une hiérarchie est mathématiquement un ordre partiel définissant une relation d'apparentée entre les rôles, où les rôles séniors acquièrent les permissions de leurs juniors et les rôles juniors acquièrent les utilisateurs de leurs sénior. De plus, la hiérarchie RBAC va au-delà du simple assignement utilisateur et permission en introduisant le concept de jeu de rôles d'utilisateurs autorisé et de permissions autorisées. La séparation statique des relations de privilège ajoute des relations exclusives avec les rôles en respect des assignements utilisateur. À cause de potentiels inconsistances d'un hiérarchie de rôle, le modèle de relation SSD définis les relations sur la présence et l'absence des hiérarchies de rôle. La séparation dynamique des relations de privilèges définis les relations exclusives en respect des rôles qui sont activés, faisant partie de la session utilisateur.

   Chaque composant est définis par les sous-composants suivants:

- Un jeu de jeux d'éléments de base
- Un jeu de relations RBAC impliquant ces éléments (contenant des sous-jeu de produits cartésiens dénotant une assignement valide)
- Un jeu de fonction de mappage, qui maintiennent des instances de membre d'un éléments, définis pour une instance donnée depuis un autre jeu d'élément.

   Il est important de notser que le modèle de référence RBAC définis une taxonomie des fonctionnalités RBAC qui peuvent être composés en un nombre de package de foncionnalités. Au lieu de tenter de définir un jeu complet de fonctionnalité RBAC, ce modèle de concentre à produire un jeu standard de termes pour définir les foncitonnalités les plus saillantes comme représenté dans les modèles existants et implémenté dans les produits commerciaux.

cœur RBAC

   Le cœur RBAC inclus les jeux de 5 éléments de données de base appelés des utilisateurs (USERS), des rôles (ROLES), des objets (OBS), des opérations (OPS), et des permissions (PRMS). Le modèle RBAC dans son ensemble est fondamentalement définis en terme d'utilisateurs individuels étant assignés aux rôles et de permissions étant assignés aux rôles. Ainsi, un rôle est un moyen de nommer des relations many-to-many entre des individus et des permissions. De plus, le modèle du cœur RBAC inclus un jeu de sessions (SESSIONS) où chaque session est un mappage entre un utilisateur et un sous-jeu activé de rôle qui sont assignés à l'utilisateur.

   Un utilisateur est définis comme une personne. Bien que le concept d'un utilisateur peut être étendus pour inclure des machines, réseaux, ou des agents autonomes intelligents, la définition est limitée à une personne dans ce document pour des raisons de simplicité. Un rôle est une fonction (job) dans le contexte de l'organisation avec des sémantiques associées avec l'autorité et la responsabilité conférée à l'utilisateur assigné au rôle. Les permissions sont une approbation pour effectuer une opération sur un ou plusieurs objets protégés par RBAC. Une opération est une image exécutable d'une programme, qui à l'invocation exécute certaines fonctions pour l'utilisateur. Les types d'opérations et objets que RBAC contrôle sont dépendant du type de systèmes dans lequel il est implémenté. Par exemple, dans un système de fichier, les opérations peuvent inclure lire, écrire, et exécuter; dans une base de données, les opérations peuvent inclure insert, delete, append, et update.

   Le but de tout mécanisme de contrôle d'accès est de protéger les ressources système. Consistant avec les anciens modèles de contrôle d'accès un objet est une entité qui contient ou reçois des informations. Pour un système qui implémente RBAC, les objets peuvent représenter des conteneurs d'informations (par exemple des fichiers, répertoires, un système d'exploitation, colonnes/lignes/tables/views dans une base de données), ou des objets qui représentent des ressources systèmes exhaustives, tels qu'une imprimante, espace disque, et cycles CPU. Le jeu d'objets couvert par RBAC inclus tous les objets listés dans les permissions qui sont assignés aux rôles.

   Le centre de RBAC est le concept de relation de rôle, autour duquel un rôle est une construction sémantique pour formuler des stratégies. La figure ci-dessous illustre les relations d''assignement utilisateur (UA) et d'assignement de permission (PA). Les flèches indiquent une relation many-to-many (ex: un utilisateur peut être assigné à un ou plusieurs rôles, et un rôle peut être assigné à un ou plusieurs utilisateurs. Cet arrangement fournis une grande flexibilité et granularité d'assignement des permissions aux rôles et des utilisateurs aux rôles. Sans cela il y a un risque qu'un utilisateur puisse obtenir plus d'accès aux ressources que nécessaire à cause du contrôle limité sur le type d'accès qui peut être associé avec les utilisateurs et les ressources. Les utilisateurs peuvent souhaiter lister les répertoires et modifier les fichiers existants, par exemple, sans créer de nouveaux fichiers, ou ils peuvent souhaiter ajouter des enregistrements à un fichier sant modifier d'enregistrements existants. Tout augmentation dans la flexibilité du contrôle d'accès aux ressources renforce également l'application du principe de moins de privilège.

Core RBAC
   Chaque session est un mappage d'un utilisateur à possiblement plusieurs rôles. Un utilisateur établis une session durant laquelle l'utilisateur active des sous-jeux de rôles auquel il est assigné. La fonction session_roles nous donne les rôle activés par la session et la fonction session_users nous donne l'utilisateur qui est associé avec une session. Les permissions disponibles à l'utilisateur sont les permissions assignées aux rôle qui sont actuellement actifs au travers de toutes les sessions utilisateur.

Hiérarchie RBAC

   Ce modèle introduit des hiérarchies de rôle (RH), communément inclus comme un aspect clé des modèles RBAC. Les hiérarchies sont un moyen naturel de structurer les rôles pour refléter les lignes d'autorité et de responsabilité d'une organisation.

   Les hiérarchies de rôle définissent une relation d'héritage avec les rôles. L'héritage a été décrit en terme de permission, par exemple, r1 hérite du rôle r2 si tous les privilèges de r2 sont également privilèges de r1. Pour certaines distribution de RBAC les permissions de rôle ne sont pas gérés centralement, bien que ces hiérarchies de rôle le soient. Pour ces systèmes, les hiérarchies de rôle sont gérés en terme de relations de contention utilisateur. Les rôle r1 contient le rôle r2 si tous les utilisateurs autorisés pour r1 sont également autorisés pour r2. Noter, cependant, que la contention d'utilisateur implique qu'un utilisateur de r1 ais (au moins) tous les privilèges de r2, alors que l'héritage de permissions pour r1 et r2 n'impliquent rient sur l'assignement de l'utilisateur.

hierarchical RBAC
   Ce standard reconnaît 2 types de hiérarchies de rôle - les hiérarchies de rôle générales et les hiérarchies de rôle limitées. Les hiérarchies de rôle générales fournissent un support pour un ordre arbitraire partiel pour servir de hiérarchie de rôle, pour inclure le concept d'héritage multiple des permissions et de membership via les rôles. Les hiérarchies de rôle limitées imposent des restrictions résultant en une structure plus simple (par exemple, un rôle peut avoir un ou plusieurs ascendants immédiats, mais est restreints à un seul descendant immédiat).

Hiérarchies de rôle générales

   Les hiérarchies de rôle générales supportent le concept d'héritage multiple, qui fournis la capacité d'hériter les permissions de 2 ou plusieurs rôles source et d'hériter des utilisateurs membre de 2 ou plusieurs rôles sources. l'héritage multiple fournis 2 propriétés de hiérarchie importantes. La première est la capacité de composer un rôle depuis plusieurs rôles subordonnés (avec moins de permissions) en définissant des rôles et relations qui sont caractéristiques de l'organisation et de structures métier, que ces rôle représentent. Ensuite, l'héritage multiple fournis un traitement uniforme des relations d'assignement utilisateur/rôle et des relations d'héritage rôle/rôle.

   Les rôle dans une hiérarchie de rôle limitée sont restreints à un simple descendant immédiat. Bien que les hiérarchies de rôle limités ne supportent pas l'héritage multiple, elles ne fournissent pas d'avantage administratif claire sur Core RBAC.

   Une hiérarchie de rôle générale peut être représenté en diagramme de Hasse. Les nœuds dans le graphique représent les rôles de la hiérarchie et il y a un ligne direct entre r1 et r2 si r1 est un descendant immédiat de r2.

Contraintes RBAC

   Les contraintes RBAC ajoute les relations de séparation des privilèges au modèle RBAC. Ces relation sont utilisées pour forcer un conflit d'interêt des stratégies que les organisations peuvent employer pour empêcher les utilisateurs d'excéder un niveau raisonnable d'autorité pour leur positions.

   Le conflit d'interêt dans un système basé sur les rôles peut se produire comme résultat d'un gain d'autorisation pour des permissions associés avec les rôles en conflit. Pour empêcher cette forme de conflit, la séparation de privilèges statique force les contraintes dans l'assignement des utilisateurs aux rôles. Les contraintes statiques peuvent prendre un variété de formes différentes.

   Les contraintes statiques définies dans ce modèle sont limitées à ces relations qui placent des restrictions dans les jeux de rôle et en particulier dans leur capacité à former les UA. Cela signifie que si un utilisateur est assigné à un rôle, l'utilisateur se voit refuser l'appartenance d'un second rôle. Une stratégie SSD peut être centralement spécifiée et imposée uniformément dans des rôles spécifiques.

   Les modèles RBAC ont définis des relations SSD en respect aux contraintes dans les assignements user-role sur des paires de rôles. Bien que dans le monde réel des stratégies SSD existent, cette définition est trop restrictive sous 2 aspects. D'abord, la taille du jeu de rôles dans le SSD et ensuit la combinaison des rôles dans le jeu pour lequel l'assignement utilisateur est restreint. Dans ce modèle, SSD est définis avec 2 arguments. Un jeu de rôle qui inclus 2 ou plusieurs rôles et une cardinalité supérieur à un indiquent une combinaison de rôle qui constiturait une violation de la stratégie SSD. Par exemple, une organisation peut exiger qu'aucun utilisateur ne puisse être assigné à 3 des 4 rôles qui représentent la fonction d'achat.

   Comme illustr ci-dessous, les relations SSD peuvent exister dans la hiérarchie RBAC. En appliquant des relations SSD dans la présence d'une hiérarchie de rôle, une attention particulière doit être appliquée pour s'assurer que l'héritage utilisateur n'amoindri pas les stratégies SSD. Ainsi, les hiérarchies de rôle ont été définis pour inclure l'héritage des contraintes SSD. Pour adresser cette inconsistance potentielle, SSD est définis dans les utilisateurs autorisés des rôles qui ont une relation SSD.

   Les relations SSD réduisent le nombre de permissions potentielles qui peuvent être faites à un utilisateur en plaçant des contraintes dans les utilisateurs qui peuvent être assignés à un jeu de rôles. Les relations de séparation de privilège dynamique (DSD), comme les relations SSD, sont prévues pour limiter les permissions qui sont disponibles à un utilisateur. Cependant, les relations DSD diffèrent des relations SSD par le contexte dans lequel ces limitations sont imposées. Les relations SSD définissent et placent les contraintes dans l'espace de permission total de l'utilisateur. Ce modèle définis les propriétés DSD qui limitent la capacité des permissions sur une espace de permission utilisateur en plaçant des contraintes dans les rôles qui peuvent être activés avec ou au travers d'une session utilisateur. Les propriétés DSD fournissent un support étendu pour le principe du moins de privilège dans cela que chaque utilisateur a différents niveaux de permissions à des moments différents, en fonction du rôle effectué. Ces propriétés s'assurent que les permissions ne persistent pas au-dela du temps requis pour la performance du privilège. Cet aspect du moins de privilège est sous réferré à une révocation en temps utile de privilège. La révocation dynamique des permissions peut être un problème plus complexe sans les facilités de la séparation dynamique de privilèges, et a été largement ignoré dans le passé.

   Ce modèle fournis la capacité de forcer une stratégie spécifique à une organisation de séparation dynamique des privilèges (DSD). Les relations SSD fournissent la capacité d'adresser de potentiels conflits d'interêt au moment où un utilisateur est assigné à un rôle. DSD permet à un utilisateur d'être autorisé pour 2 ou plusieurs rôles qui ne créent pas de conflit lorsqu'ils agissent indépendamment, mais produit un problème de stratégie quand activé simultanément. Par exemple, un utilisateur peut être autorisé pour les rôles de caissier et de contrôleur de caisse, RBAC exige que l'utilisateur abandonne le rôle de caissier et fermet son tirroir caisse avant de passer contrôleur. Tant que ce même utilisateur n'est pas autorisé à assumer ces 2 rôles simultanément, un conflit d'interêt ne peut pas se produire.

Dynamic Separation of Duty Relations

Système RBAC et spécification fonctionnelle administrative

   La spécification fonctionnelle RBAC spécifie les opérations administratives pour la création et la maintenance de jeux d'éléments et de relations RBAC; les fonctions administratives pour effectuer les requêtes administratives; et les fonctions système pour créer et gérer les attributs RBAC dans les sessions utilisateur et prendre les décisions de contrôle d'accès. Les fonctions sont définies avec une précision suffisante pour répondre aux besoins de conformité de test et d'assurance, tout en fournissant aux développeurs la capacité d'incorporer des fonctionnalités additionnelles pour répondre aux besoins des utilisateurs.

Commandes administratives pour Core RBAC

AddUser Cette commande créé un nouvel utilisateur RBAC. La commande est valide seulement si le nouvel utilisateur n'est pas déjà membre du jeu de données USERS. Ce jeu USERS est mis à jours. Le nouvel utilisateur ne possède pas de session au moment de sa création.
DeleteUser Cette commande supprime un utilisateur existant de la base RBAC. La commande est valide si et seulement si l'utilisateur à supprimer est un membre du jeu de données USERS. Les jeux de données USER et UA et la fonction assigned_users sont mis à jours. C'est une décision d'implémentation de savoir comment procéder avec les sessions possédés par l'utilisation à supprimer.
AddRole Cette commande crée un nouveau rôle. La commande est valide si et seulement si le nouveau rôle n'est pas déjà membre du jeu de données ROLES. Le jeu ROLES et les fonctions assigned_users et assigned_permissions sont mis à jours. Initialement, aucun utilisateur ou permission n'est assigné au nouveau rôle.
DeleteRole Cette commande supprime un rôle existant de la base RBAC. La commande est valide si et seulement si le rôle est membre du jeu de données ROLES. C'est une décision d'implémentation de décidé de la manière de procéder avec les sessions dans le rôle à supprimer sont actifs.
AssignUser Cette commande assigne un utilisateur à un rôle. La commande est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et le rôle est membre du jeu de données ROLES, et que l'utilisateur n'est pas déjà assigné au rôle. Le jeu de données UA et la fonction assigned_users sont mis à jours pour refléter l'assignement.
DeassignUser Cette commande supprime l'assignement d'un utilisareur à un rôle. Cette commande est valide si et seulement si le rôle est un des rôles actif de l'utilisateur.
GrantPermission Cette commande octroie à un rôle la permission d'effectuer une opération sur un objet à un rôle. La commande peut être implémentée pour octroyer les permissions à un groupe correspondant à ce rôle, par ex., en définissant la liste de contrôle d'accès à l'objet en question.
RevokePermission Cette commande révoque la permission d'effectuer une opération sur un objet depuis le jeu de permissions assignés à un rôle. La commande peut être implémentée pour révoquer les permissions d'un groupe correspondant à ce rôle, par ex., en définissant la liste de contrôle d'accès de l'objet en question.

Fonctions système pour Core RBAC

CreateSession(user,session) Cette fonction créé une nouvelle session avec un utilisateur donné comme propriétaire et un jeu de rôle actif. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS et que le jeu de rôle actif est un sous-jeu des rôles assignés à cet utilisateur.
DeleteSession(user,session) Cette fonction supprime une session données avec un utilisateur. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS, l'utilisateur est un membre du jeu de données USERS, et la session est possédée par l'utilisateur donné.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est l'utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS et le rôle est membre du jeu de données ROLES, et l'identifiant de session est membre du jeu de données SESSIONS, et le rôle est assigné à l'utilisateur, et la session est possédée par l'utilisateur.
DropActiveRole Cette fonction supprime un rôle du jeu de rôle actif d'une session possédé par un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS, l'identifiant de session est un membre du jeu de données SESSION, la session est possédées par l'utilisateur, et le rôle est un rôle actif de cette session.
CheckAccess Cette fonction retourne une valeur booléenne indiquant si le sujet d'une session données est autorisée ou non à effectuer l'opération données sur l'objet donné. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS, l'objet est un membre du jeu de données OBJS, et l'opération est un membre du jeu de données OPS. Le sujet de la session a la permission d'effectuer l'opération sur cet objet si et seulement si cette permission est assignée à (au moins) un des rôles actifs de la session. Une implémentation peut utiliser les groupes qui correspondent aux rôle actifs du sujet et leur permission comme enregistré dans la liste de contrôle d'accés de l'objet.

Fonctions d'examen pour Core RBAC

AssignedUsers Cette fonction retourne le je d'utilisateurs assignés à un rôle donné. La fonction est valide si et seulement si le rôle est un membre du jeu de données ROLES.
AssignedRoles Cette fonciton retourne le je de rôles assignés à l'utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS.

Fonctions d'examen avancé pour Core RBAC

RolePermissions Cette fonction retourne le jeu de permissions (op,obj) octroyés à un rôle donné. La fonction est valide si et seulement si le rôle est un membre du jeu de données ROLES.
UserPermissions Cette fonction retourne les permissions qu'un utilisateur obtient via ses rôles assignés. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS.
SessionRoles Cette fonction retourne les rôles actifs associés avec une session. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS.
SessionPermissions Cette fonction retourne les permissions de la session, par ex., les permission assignées à ses rôles actifs. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS.
RolesOperationsOnObject Cette fonction retourne le jeu d'opérations d'un rôle donné autorisé sur un objet donné. Cette fonction est valide seulement si le rôle est un membre du jeu de données OBJS
UserOperationsOnObject Cette fonction retourne le jeu d'opérations qu'un utilisateur donné est autorisé à effectuer sur un objet donné, obtenu soit directement ou via ses rôles assignés. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et l'objet est un membre du jeu de données OBJS.

Commandes administratives pour les hiérarchies de rôles générales

AddInheritance Cette commande établis une nouvelle relation d'héritage immédiat entre les rôle. La commande est valide si et seulement si les 2 rôles sont membres du jeu de données ROLES.
DeleteInheritance Cette commande supprime une relation d'héritage immédiat existante. Cette commande est valide si et seulement si les rôles sont membre du jeu de données ROLES.
AddAscendant Cette commande créé un nouveau rôle r_asc, et l'insert dans la hiérarchie de rôle comme ascendant immédiat du rôle existant r_desc. La commande est valide si et seulement si r_asc n'est pas membre du jeu de données ROLES, et r_desc est un membre du jeu de données ROLES.
AddDescendant Cette commande créé un nouveau rôle r_desc, et l'insert dans la hiérarchie de rôle comme descendant immédiat du rôle existant r_asc. La commande est valide si et seulement si r_desc n'est pas membre du jeu de données ROLES, et r_asc est un membre du jeu de données ROLES.

Fonctions système pour les hiérarchies de rôles générales

CreateSession(user,session) Cette fonction créé une nouvelle session avec un utilisateur donné comme propriétaire, et un jeu donné de rôles actifs. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS, et le jeu de rôle actif est un sous-jeu autorisé pour cet utilisateur. Noter que si un rôle est actif pour une session, ses descendants ne sont pas nécessairement actifs pour cette session. Dans une implémentation RBAC, les rôles actifs d'une session peuvent être les groupes qui représentent ces rôles.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS, le rôle est membre du jeu de données ROLES, l'identifiant de session est membre du jeu de données SESSIONS, l'utilisateur est autorisé pour ce rôle, et la session est possédée par cet utilisateur.

Fonctions d'examen pour les hiérarchies de rôles générales

   Toutes les fonctions de la section "Fonctions d'examen pour Core RBAC" sont valides. Cette section définis les fonctions suivantes:

AuthorizedUsers Cette fonction retourne le jeu d'utilisateurs autorisés pour un rôle donné, par ex., les utilisateurs qui sont assignés à un rôle qui hérite du rôle donné. La fonction est valide si et seulement si le rôle donné est un membre du jeu de données ROLES.
AuthorizedRoles Cette fonction retourne le jeu de rôles autorisés pour un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est un membre de jeu de données USERS.

Fonction d'examen avancé pour les hiérarchies de rôles générales

   Cette section redéfinis les fonction RolePermissions et UserPermissions de la section "Fonctions d'examen avancé pour Core RBAC". toutes les autres fonction de cette section sont valides.

RolePermissions Cette fonction retourne le jeu de permission(ob,obj) octroyé à ou hérité par un rôle donné. La fonction est valide si et seulement si le rôle est un membre du jeu de données ROLES.
UserPermissions Cette fonction retourne le jeu de permissions qu'un utilisateur obtient via ses rôles assignés. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS.
RoleOperationsOnObject Cette fonction retourne le jeu d'opérations qu'un rôle donné est autorisé à effectuer sur un objet donné. Le jeu contient toutes les opérations octroyées directement à ce rôle ou hérité par ce rôle depuis un autre rôle. La fonction est valide seulement si le rôle est un membre du jeu de données ROLES, et l'objet est un membre de jeu de données OBJS.
UserOperationsOnObject Cette fonction retourne le jeu d'opérations qu'un utilisateur est autorisé à effectuer sur un objet donné. Le jeu consiste de toutes les opérations obtenues par l'utilisateur directement, ou via ses rôle autorisés. La fonction est valide si et seulement si l'utilisateur est un membre de jeu de données USERS et l'objet est un membre du jeu de données OBJS.

Commandes administratives pour les hiérarchies de rôles limitées

   Cette section redéfinis la fonction AddInheritance de la section "Commandes administratives pour les hiérarchies de rôles générales". Toutes les autres fonctions de cette section restent valides

AddInheritance Cette commande établis une nouvelle relation d'héritage immédiate entre les rôles existants r_asc et r_desc. La commande est valide si et seulement si les rôles sont membre du jeu de données ROLES.

Fonctions système pour les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions système pour les hiérarchies de rôles générales" sont valides

Fonction d'examen pour les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions d'examen pour les hiérarchies de rôles générales" sont valides

Fonction d'examen avancé pour les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions d'examen avancé pour les hiérarchies de rôles générales" sont valides

Relations SSD

   La propriété de séparation des privilèges statique, tel que définis dans ce modèle, utilise une collection SSD de paires d'un jeu de rôle et un cardinalité associée. Cette section définis le nouveau type de données SSD, qui dans un implémentation peut être le jeu de noms utilisé pour identifier les paires dans la collection.

Commandes administratives pour les relations SSD

   Cette section redéfinis la fonction AssignUser de la section "Commandes administratives pour Core RBAC", et définis un nouveau jeu de fonctions spécifiques. Les autres fonction de cette section sont valides.

AssignUser Cette commande assigne un utilisateur à un rôle. La commande est valide si et seulement si l'utilisateur est membre du jeu de données USERS, le rôle est membre du jeu de données ROLES, l'utilisateur n'est pas déjà assigné au rôle, et les contraintes SSD sont satisfaites après assignement.
CreateSsdSet Cette commande créé un jeu SSD de rôle et définis la cardinalité n de ses sous-jeu qui ne peuvent pas avoir d'utilisateurs communs. La commande est valide si et seulement si le nom du jeu SSD n'est pas déjà utilisé, tous les rôle dans le jeu SSD sont membres du jeu de données ROLES, n est un nombre naturel supérieur ou égal à 2 et inférieur ou égal à la cardinalité du jeu de rôle SSD, et la containte SSD pour le nouveau rôle est satisfait.
AddSsdRoleMember Cette commande ajoute un rôle à un jeu SSD de rôles. La cardinalité associée avec le jeu de rôle reste inchangée. La commande est valide si et seulement si le rôle SSD existe, le rôle à ajouté est un membre du jeu de données ROLES mais pas membre du jeu de rôle SSD, et la contrainte SSD est satisfaite après l'ajout du rôle dans le jeu de rôle SSD.
DeleteSsdRoleMember Cette commande supprime un jeu de rôle SSD complètement. La commande est valide si et seulement si le jeu de rôle SSD existe.
SetSsdSetCardinality Cette commande définis la cardinalité associée avec un jeu de rôle SSD. La commande est valide si et seulement si le jeu de rôle SSD existe, et la nouvelle cardinalité est un nombre naturel supérieur ou égal à 2 et inférieur ou égal au nombre d'éléments du jeu de rôle SSD, et la contrainte SSD est satisfaite après avoir définis la nouvelle cardinalité.

Fonctions système pour SSD

   Toutes les fonctions de la section "Fonctions système pour Core RBAC" sont valides

Fonctions d'examen pour SSD

   Toutes les fonctions de la section "Fonctions d'examen pour Core RBAC" sont valide. De plus, les fonctions suivantes sont définis:

SsdRoleSets Cette fonction retourne la liste des jeux de rôle SSD.
SsdRoleSetRoles Cette fonction retourne le jeu de rôles d'un jeu de rôle SSD. La fonction est valide si et seulement si le jeu de rôle existe.
SsdRoleSetCardinality Cette fonction retourne la cardinalité associée avec un jeu de rôle SSD. La foncion est valide si et seulement si le jeu de rôle existe.

Fonctions d'examen avancé pour SSD

   Toutes les fonctions de la section "Fonctions d'examen avancé pour Core RBAC" sont valide.

Commandes administratives pour SSD avec les hiérarchies de rôle générales

   Cette section redéfinis les fonctions AssignUser et AddInheritance de la section "Commandes administratives pour les hiérarchies de rôles générales", et les fonctions CreateSsdSet, AddSsdRoleMember, SetSsdSetCardinality de la section "Commandes administratives pour les relations SSD". Les autres fonctions de ces 2 section sont valides.

AssignUser Cette commande assigne un utilisateur à un rôle. La commande est valide si et seulement si l'utilisateur est un membre du jeu de données USERS, et le rôle est un membre du jeu de données ROLES, et l'utilisateur n'est pas déjà assigné au rôle, et les contraintes SSD sont satisfaites après l'assignement.
AddInheritance Cette commande établis une nouvelle relation d'héritage entre les rôles existants r_asc, et r_desc. La commande est valide si et seulement si les rôles sont membres du jeu de données ROLES, r_asc n'est pas un ascendant direct de r_desc, _desc n'hérite pas de r_asc, et les contraintes SSD sont satisfaites après avoir établis l'héritage.
CreateSsdSet Cette commande créé un jeu SSD de rôle et les jeux de cardinalité associés n de ses sous-jeux qui n'ont pas d'utilisateurs communs. La commande est valide si et seulement si le nom du jeu SSD n'est pas déjà utilisé, tous les rrôles dans le jeu SSD sont membre du jeu de données ROLES, n est un nombre naturel supérieur ou égal à 2 et inférieur ou égal à la cardinalité du jeu de rôle SSD, et la contrainte SSD pour le nouveau jeu de rôle est satisfaite.
AddSsdRoleMember Cette commande ajoute un rôle à un jeu SSD de rôles. La cardinalité associée avec le jeu de rôle reste inchangée. La commande est valide si et seulement si le jeu de rôle SSD existe, et le rôe à ajouter est un membre du jeu de données ROLES mais pas membre du jeu de rôle SSD.
SetSsdSetCardinality Cette commande définis la cardinalité associée avec un jeu de rôle SSD. La commande est valide si et seulement si le jeu de rôle SSD existe, la nouvelle cardinalité est un nombre naturel supérieur ou égal à 2 et inférieur ou égal au nombre d'éléments du jeu de rôles SSD, et la containte SSD est satisfaite après avoir définis la nouvelle cardinalité.

Fonctions système pour SSD avec les hiérarchies de rôle générales

   Toutes les fonctions de la section "Fonctions système pour les hiérarchies de rôles générales" sont valides

Fonctions d'examens pour SSD avec les hiérarchies de rôle générales

   Toutes les fonctions des sections "Fonctions d'examen pour les hiérarchies de rôles générales" et "Fonctions d'examen avancé pour SSD" sont valides

Fonction d'examens avancé pour SSD avec les hiérarchies de rôle générales

   Toutes les fonctions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides

Commandes administratives pour SSD avec les hiérarchies de rôle limitées

   Cette section redéfinis la fonction AddInheritance de la section "Commandes administratives pour SSD avec les hiérarchies de rôle générales". Toutes les autres fonctions de cette section sont valides.

AddInheritance Cette commande établis une nouvelle relation d'héritage immédiat entre les rôle r_asc et r_desc. La commande est valide si et seulement si les rôles sont membre du jeu de données ROLES, r_asc n'a pas de descendants, et r_desc n'hérite pas de r_asc.
[SECTION] name="Fonctions système pour SSD avec les hiérarchies de rôle limitées" table="paragraphes" imbrication="0"
Toutes les fonctions de la section "Fonctions système pour SSD avec les hiérarchies de rôle générales" sont valides.

Fonctions d'examens pour SSD avec les hiérarchies de rôle limitées

   Toutes les fonctions des sections "Fonctions système pour les hiérarchies de rôles générales" et "Fonctions d'examen pour SSD" sont valides

Fonction d'examens avancé pour SSD avec les hiérarchies de rôle limitées

   Toutes les foncions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides.

Commandes administratives pour les relations DSD

   Toutes les fonctions de la section "Commandes administratives pour Core RBAC" sont valide. Cette section définis les fonctions supplémentaires suivantes:

CreateDsdSet Cette commande créé un jeu DSD de rôle et définis une cardinalité n associée. La contrainte DSD stipule que le jeu de rôle DSD ne peut pas contenir n rôle ou plus, actifs simultanément dans la même session. La commande est valide si et seulement si le nom du jeu DSD n'est pas déjà utilisé, tous les rôles dans le jeu DSD sont membre du jeu de données ROLES, n est un nombre naturel supérieur ou égal à 2 et inférieur ou égal à la cardinalité du jeu de rôle DSD, et la contrainte DSD pour le nouveau rôle est satisfaite.
AddDsdRoleMember Cette commande ajeute un rôle à un jeu de rôles DSD. La cardinalité associée avec le jeu de rôle reste inchangé. La commande est valide si et seulement si le jeu de rôle DSD existe, le rôle à ajouter est membre du jeu de données ROLES, mais non membre du jeu de rôle DSD, et la contrainte DSD est satisfaite après l'ajout du rôle dans le jeu de rôle DSD.
DeleteDsdRoleMember Cette commande supprime un rôle depuis un jeu de rôles DSD. La cardinalité associée avec le jeu de rôle reste inchangé. La commande est valide si et seulement si le jeu de rôle DSD existe, le rôle à supprimer est un membre du jeu de rôle DSD, et la cardinalité associée avec le jeu de rôle DSD est inférieur au nombre d'éléments du jeu de rôle DSD.
DeleteDsdSet Cette commande supprime un jeu de rôle DSD complètement. Cette commande est valide si et seulement si le jeu de rôle DSD existe.
SetDsdSetCardinality Cette commande définis la cardinalité associée avec un jeu de rôle DSD donné. La commande est valide si et seulement si le jeu de rôle DSD existe, la nouvelle cardinalité est un nombre naturel supérieur ou égal à 2 et inférieur ou égal au nombre d'éléments du jeu de rôle DSD, et la contrainte DSD est satisfaite après avoir définis la nouvelle cardinalité.
[SECTION] name="Fonctions système pour les relations DSD" table="paragraphes" imbrication="0"
Cette section redéfinis les fonctions CreateSession et AddActiveRole de la section "Fonctions système pour Core RBAC". Toutes les autres fonctions de cette section sont valides

CreateSession Cette fonction créé une nouvelle session dont le propriétaire est l'utilisateur donné et un jeu de rôles actif. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et le jeu de role actif de la session est un sous-jeu des rôle assigné pour le propriétaire de la session, le jeu de rôle actif de la session est un sous-jeu des rôles assignés au propriétaire de la session, et le jeu de rôle actif de la session satisfait les contraintes DSD.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS, le rôle est un membre du jeu de données ROLES, l'identifiant de session est membre du jeu de données SESSIONS, le rôle est assigné à cet utilisateur, et l'ancien jeu de rôle actif complété avec le rôle à activer satisfont les contraintes DSD, et la session est possédée par cet utilisateur.

Fonctions d'examen pour les relations DSD

   Toutes les fonction de la section "Fonctions d'examen pour Core RBAC" sont valide. De plus, cette section définis de nouvelles fonctions:

DsdRoleSets Cette fonction retourne la liste de tous les jeux de rôle DSD
DsdRoleSetRoles Cette fonction retourne le jeu de rôles d'un jeu de rôle DSD. La fonction est valide si et seulement si le jeu de rôle existe.
DsdRoleSetCardinality Cette fonction retourne la cardinalité associée avec un jeu de rôle DSD. La fonction est valide si et seulement si le jeu de rôle existe.

Fonctions d'examen avancé pour les relations DSD

   Toutes les fonctions de la section "Fonctions d'examen avancé pour Core RBAC" sont valides.

Commandes administratives pour les relations DSD avec les hiérarchies de rôle générales

   Toutes les fonctions des sections "Commandes administratives pour les hiérarchies de rôles générales" et "Commandes administratives pour les relations DSD" sont valides

Fonctions système pour les relations DSD avec les hiérarchies de rôle générales

   Cette section redéfinis les fonctions CreateSession et AddActiveRole de la section "Fonctions système pour Core RBAC". Toutes les autres fonctions de cette section sont valides

CreateSession Cette fonction créé une nouvelle session dont le propriétaire est l'utilisateur donné et un jeu de rôles actif. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et le jeu de role actif de la session est un sous-jeu des rôle autorisés pour le propriétaire de la session, et le jeu de rôle actif de la session satisfait les contraintes DSD.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS, le rôle est un membre du jeu de données ROLES, l'identifiant de session est membre du jeu de données SESSIONS, le rôle est autorisé pour cet utilisateur, et l'ancien jeu de rôle actif complété avec le rôle à activer satisfont les contraintes DSD, et la session est possédée par cet utilisateur.

Fonctions d'examen pour les relations DSD avec les hiérarchies de rôle générales

   Toutes les fonctions des sections "Fonctions d'examen pour les relations DSD" et "Fonctions d'examen pour les hiérarchies de rôles générales" sont valides

Fonctions d'examen avancé pour les relations DSD avec les hiérarchies de rôle générales

   Toutes les fonctions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides

Commandes administratives pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions des sections "Commandes administratives pour les hiérarchies de rôles limitées" et "Commandes administratives pour les relations DSD" sont valides

Fonctions système pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions système pour les relations DSD avec les hiérarchies de rôle générales" sont valides

Fonctions d'examen pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions d'examen pour les relations DSD avec les hiérarchies de rôle générales" sont valides

Fonctions d'examen avancé pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides
^
10 juillet 2014

htmlpdflatexmanmd




chsh.ldap

chsh.ldap

Change le login shell dans LDAP

   chsh.ldap peut être utilisé pour changer le login shell de l'utilisateur. Le changement actuel dans LDAP est effectué par nslcd et est sujet à ACL dans le serveur.

OPTIONS

-s, --shell SHELL Nom du shell. Si vide, le système sélectionne le shell par défaut.
-l, --list-shells Liste les shells trouvés dans /etc/shells
^
10 juillet 2014

htmlpdflatexmanmd




getent.ldap

getent.ldap

Demandes d'informations LDAP

   getent.ldap peut être utilisé pour rechercher ou énumérer les informations LDAP. À la différence de getent, cette commande bypass complètement les recherches configurées dans nsswitch.conf. et requête nslcd directement. getent.ldap tente de correspondre au fonctionnement et à la sortie de getent autant que possible, cependant il y a certaines différences. Si plusieurs entrées sont trouvées dans LDAP, plusieurs valeurs sont affichées. Certaines base ont des options supplémentaires.

bases

aliases Liste ou requête les alias mail
ethers Liste ou requête les adresses ethernet
group Liste ou requête les groupes. Il recherche les groupes par group id
group.member Si l'argument est un username, retourne les groupes dont l'utilisateur est membre.
hosts Liste ou requête nom d'hôte et adresses par nom d'hôte, ipv4 ou ipv6.
hostsv4 Idem mais ne retourne que les adresses ipv4
hostsv6 Idem mais ne retourne que les adresses ipv6
netgroup Liste les triplet netgroup
netgroup.norec Idem excepté qu'aucune autre recherche n'est faite pour étendre les netgroups qui sont membre du netgroup fournis.
networks Liste les noms et adresses de réseaux
networksv4 Idem mais retourne uniquement les adresses ipv4
networksv6 Idem mais retourne uniquement les adresses ipv6
passwd Liste ou recherche le compte utilisateur
protocols Énumère la base de protocoles internet
rpc Liste ou recherche les noms qui mappe les numéro RPC
services Liste ou recherche le mappage entre les noms pour les services internet et leur numéro de port correspondant
shadow Liste ou recherche les informations étendus de compte utilisateur.
^
10 juillet 2014

htmlpdflatexmanmd




nslcd

nslcd

Daemon de service de nom LDAP local

   nslcd est un service qui fait des requêtes LDAP pour NSS et PAM. Il est configuré via nslcd.conf

OPTIONS

-c, --check Vérifie si le service est lancé. 0 s'il fonctionne, 1 sinon
-d, --debug Mode débug, nslcd ne se place pas en tâche de fond et envoie ses logs sur stderr.
-n, --nofork Ne se fork pas et reste en foreground

Signaux

SIGTERM/SIGINT Annule toute requête en cours et se termine
SIGUSR1 Retente les connexions echouées, sans respecter reconnect_sleeptime et reconnect_retrytime

Fichiers

/etc/nslcd.conf Fichier de configuration de nslcd.
^
10 juillet 2014

htmlpdflatexmanmd




nslcd.conf

nslcd.conf

Fichier de configuration de nslcd

options runtimes

threads NUM Spécifie le nombre de threads. Défaut: 5
uid UID user id du service
gid GID Groupe du service
log SCHEME [LEVEL] Contrôle les logs. SCHEME peut être none ou syslog. (défaut: syslog info)

options de connexion

uri URI URI du serveur LDAP. La valeur alternative DNS peut être utilisée pour rechercher les DNS SRV avec la syntaxe DNS:DOMAIN.
ldap_version VERSION Spécifie la version du protocole LDAP à utiliser
binddn DN DN à utiliser pour le bind.
bindpw PASSWORD Mot de passe du binddn
rootpwmoddn DN Spécifie le DN à utiliser quand root tente de modifier le mot de passe d'un utilisateur en utilisant le module PAM.
rootpwmodpw PASSWORD Mot de passe de rootpwmoddn

options SASL

sasl_mech MECHANISM Spécifie le mécanisme SASL à utiliser pour l'authentification SASL
sasl_realm REALM Domaine SASL
sasl_authcid AUTHCID Identité d'authentification
sasl_authzid AUTHZID Identité d'authorisation (doit être spécifié au format dn:‹dn› ou u:‹username›)
sasl_secprops PROPERTIES Spécifie les propriétés de sécurité SASL de Cyrus. les valeurs permise sont décrites dans ldap.conf
sasl_canonicalize yes|no Détermine si le nom d'hôte du serveur LDAP devrait être canonisé ou non. À yes, effectue un reverse lookup.

options Kerberos

krb5_ccname NAME Nom pour le cache d'accréditations Kerberos

options de recherche et mappage

base [MAP] DN Base de recherche. Peut être spécifié plusieurs fois. Une base de recherche globale peut être spécifiée ou un map spécifique.
scope [MAP] sub[tree]|one[level]|base|children Spécifie le scope de recherche.
deref never|searching|finding|always Définis la stratégie de dé-référencement des alias.
referrals yes|no Spécifie si les référant doivent être suivis ou non.
filter MAP FILTER Filtre de recherche à utiliser pour un map spécifique.
map MAP ATTRIBUTE NEWATTRIBUTE Permet de définir d'autres attributs que ceux de la rfc2307.

options de timing et reconnexion

bind_timelimit SECONDS limite de temps pour la connexion au serveur. Défaut: 10 secondes
timelimit SECONDS Spécifie la limite de temps pour une réponse du serveur. 0 pour une attente infinie.
idle_timelimit SECONDS Période d'inactivité avant de fermer la connexion au serveur. Défaut: pas de limite
reconnect_sleeptime SECONDS Temps au delà duquel un serveur ldap est considéré indisponible. Une fois ce temps atteins, les tentatives seront faites une fois par cette tranche de temps. défaut: 10 secondes.

options SSL/TLS

ssl on|off|start_tls Spécifie le mode à utiliser
tls_reqcert never|allow|try|demand|hard Spécifie quelles vérifications effectuer sur le certificat du serveur. Les valeurs sont décrites dans ldap.conf.
tls_cacertdir PATH Répertoire contenant les certificats X.509 pour l'authentification du paire. Ignoré avec GnuTLS.
tls_cacertfile PATH Spécifie le chemin du certificat X.509 pour l'authentification du paire.
tls_randfile PATH Chemin de la source d'entropie. Ignoré avec GnuTLS
tls_ciphers CIPHERS Chiffrement à utiliser pour TLS.
tls_cert PATH Chemin du certificat du client
tls_key PATH Chemin du fichier contenant la clé privé du client.

autres options

pagesize NUMBER › 0, définis le nombre de résultat pour une recherche paginés. Défaut: 0.
nss_initgroups_ignoreusers user1,user2,... Empêche la recherche du groupe membership dans ldap pour les utilisateurs spécifiés. Peut être spécifié plusieurs fois.
nss_min_uid UID uid minimum pour les recherches dans ldap
nss_nested_groups yes|no Si l'attribut member pointe vers un autre groupe, les membres imbriqués sont retournés. Défaut: no.
validnames REGEX pattern pour déterminer les noms d'utilisateurs et de groupes valides.
ignorecase yes|no Prend en compte ou non la casse. yes peut exposer le système à des vulnérabilités.
pam_authz_search FILTER Permet de paramétrer la vérification d'authorisation. Le filtre spécifié est exécuté et si une entrée matche, l'accès est donné. Le filtre peut contenir les variables suivantes: $username, $service, $ruser, $rhost, $tty, $hostname, $fqdn, $dn, $uid. Peut être spécifié plusieurs fois.
pam_password_prohibit_message "MESSAGE" Refuse la modification de mot de passe avec pam_ldap et affiche le message spécifié. Peut être utilisé pour rediriger l'utilisateur vers un autre moyen de changer son mot de passe.
reconnect_invalidate DB,DB,... Si définis, vide les caches spécifiés au démarrage et lors des reconnexions au serveur. db est une des maps nsswitch.
cache CACHE TIME [TIME] Durée de rétentions des entrées dans le cache interne.

Expressions de mappage d'attributs

   Pour certains attributs, une expression de mappage peut être utilisé pour construire la valeur résultante. C'est actuellement seulement possible pour les attributs qui n'ont pas besoin d'être utilisés dans les filtres de recherche. Les expressions sont un sous-jeu d'expressions shell. Au lieu de substitution de variable, la recherche d'attribut est faite sur l'entrée courante et la valeur d'attribut est substituée. Les expressions suivantes sont supportés:

${attr}, $attr Substitue la valeur de l'attribut
${attr:-word} Substitue la valeur de l'attribut ou, si l'attribut n'est pas définis ou vide, substitue le mot.
${attr:+word} Substitue le mot si l'attribut si l'attribut est mis, sinon substitue une chaîne vide.
${attr#word} Supprime le match le plus court possible de la gauche de la valeur de l'attribut
${attr##word} Supprime le match le plus long possible de la gauche de la valeur de l'attribut
${attr%word} Supprime le match le plus long possible de la droite de la valeur de l'attribut
${attr%%word} Supprime le match le plus court possible de la droite de la valeur de l'attribut

   Seul la version '#' est supportée par nslcd, les autres sont supportés par pynslcd. Également, le seul wilcard supporté par nslcd est ?. Les caractères ", $ et \ doivent être échappés.

Exemples

Utilise l'attribut shadowFlag, avec la valeur 0 par défaut:
"${shadowFlag:-0}"
Utilise uid pour construire homeDirectory si cette attribut est manquant:
"${homeDirectory:-/home/$uid}"
Si isDisabled est mis, retourne 100:
"${isDisabled:+100}"
Enlève le préfixe {crypt} de userPassword:
"${userPassword#{crypt\}}"
^
10 juillet 2014

htmlpdflatexmanmd




pynslcd

pynslcd

Daemon de service de nom LDAP

   pynslcd est un service qui fait des requêtes LDAP pour NSS et PAM. Il est configuré via nslcd.conf

OPTIONS

-c, --check Vérifie si le service est lancé. 0 s'il fonctionne, 1 sinon
-d, --debug Mode débug, pynslcd ne se place pas en tâche de fond et envoie ses logs sur stderr.
-n, --nofork Ne se fork pas et reste en foreground