\documentclass{report}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{geometry}
\geometry{top=15mm, bottom=15mm, left=1cm, right=1cm}
\usepackage[french]{babel}
\usepackage{pslatex}
\usepackage[colorlinks=true,urlcolor=black]{hyperref}
\usepackage{graphicx}
\usepackage{fancyhdr}
\pagestyle{fancy}
\renewcommand{\footrulewidth}{0.4pt}
\fancyfoot[L]{Uubu.fr}
\fancyfoot[R]{ven. juil. 24 10:57:18 CEST 2015}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={draft-bannister-dbis-passwd-05},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={dbis: passwd et group},
CreationDate={D:20150724105718},
ModDate={D:20150724105718},
Keywords={LDAP;Lightweight Directory Access Protocol}
}}
\begin{document}
 
\begin{center}
{\Huge draft-bannister-dbis-passwd-05 }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large dbis: passwd et group}
 
\vspace{10mm}
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Maps de configuration }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm} 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:
 
{\ttfamily
Database\_\_\_\_\_\_dbisMapFilter\\ passwd\_\_\_\_\_\_\_\_objectClass=posixUserAccount\\ group\_\_\_\_\_\_\_\_\_objectClass=posixGroupAccount\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Exemple d'entrées de map de configuration }
 
\
 
\hspace{1mm} L'exemple suivant donne un exemple d'entrée de map de configuration pour une base passwd:
 
{\ttfamily
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\\
}
\vspace{8mm}
 
\hspace{1mm} L'exemple suivant donne un exemple d'entrée de map de configuration pour une base group:
 
{\ttfamily
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\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge base passwd }
 
\
 
\hspace{1mm}  Une base de données passwd contient les champs suivants:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Nom d'utilisateur}
\item[\hspace{1mm} -]{Mot de passe de l'utilisateur}
\item[\hspace{1mm} -]{Identifiant numérique de l'utilisateur}
\item[\hspace{1mm} -]{Identifiant numérique du groupe primaire de l'utilisateur}
\item[\hspace{1mm} -]{description de l'utilisateur}
\item[\hspace{1mm} -]{Chemin du répertoire personnel de l'utilisateur}
\item[\hspace{1mm} -]{Chemin du shell de connexion de l'utilisateur.}
\end{description}
 
\vspace{1cm}{\huge ObjectClass }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge dbisPasswdConfig }
 
\
 
\hspace{1mm} La classe dbispasswdConfig est définie comme suit:
 
{\ttfamily
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 )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge posixUserAccount }
 
\
 
\hspace{1mm} La classe posixUserAccount est définie comme suit:
 
{\ttfamily
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 ) )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Attributs }
 
\
 
 
 
\vspace{1cm}{\huge dbisMapGecos }
 
\
 
\hspace{1mm} 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:
 
{\ttfamily
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 )\\
}
\vspace{8mm}
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge dbisOverlayDN }
 
\
 
\hspace{1mm} 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:
 
{\ttfamily
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 )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge en }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge uidNumber }
 
\
 
\hspace{1mm} L'UID est stocké dans l'attribut uidNumber qui doit être assigné à l'entrée posixUserAccount:
 
{\ttfamily
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 )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge gidNumber }
 
\
 
\hspace{1mm} Le GID primaire est stocké dans l'attribut gidNumber qui doit être assigné à une entrée posixGroupAccount:
 
{\ttfamily
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 )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge homeDirectory }
 
\
 
\hspace{1mm} Le chemin du répertoire personnel de l'utilisateur est stocké dans l'attribut homeDirectory qui doit être assigné à une entrée posixUserAccount:
 
{\ttfamily
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 )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge authPassword }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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é.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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é.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le transfert des valeurs authPassword est fortement découragé quand le service de transport sous-jacent ne peut pas garantir la confidentialité.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge userPassword }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm} La représentation chaîne de l'attribut userPassword devrait matcher la grammaire suivante, spécifiée en notation ABNF:
 
{\ttfamily
scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme\\ altscheme = "x-" keystring\\ userPassword = LCURLY scheme RCURLY cryptpass\\
}
\vspace{8mm}
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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é.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge loginShell }
 
\
 
\hspace{1mm} Le chemin du répertoire personnel de l'utilisateur est stocké dans l'attribut loginShell qui peut être assigné à une entrée posixUserAccount:
 
{\ttfamily
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 )\\
}
\vspace{8mm}
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge disableObject }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Exemple d'entrée passwd }
 
\
 
\hspace{1mm} L'exemple suivant est un exemple d'entrée posixUserAccount au format LDIF:
 
{\ttfamily
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\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge groupes }
 
\
 
\hspace{1mm}  Une base group contient les détails suivants:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Le nom du groupe}
\item[\hspace{1mm} -]{Le mot de passe du groupe}
\item[\hspace{1mm} -]{Un identifiant numérique pour le groupe}
\item[\hspace{1mm} -]{La liste des membres}
\end{description}
 
\vspace{1cm}{\huge ObjectClass }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge dbisGroupConfig }
 
\
 
\hspace{1mm} La classe dbisGroupConfig est définie comme suit:
 
{\ttfamily
objectclass ( 1.3.6.1.4.1.23780.219.1.11 NAME 'dbisGroupConfig' DESC 'DBIS group configuration map' SUP dbisMapConfig STRUCTURAL MAY dbisOverlayDN )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge posixGroupAccount }
 
\
 
\hspace{1mm} La classe posixGroupAccount est définie comme suit:
 
{\ttfamily
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 ) )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge en }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge gidNumber }
 
\
 
\hspace{1mm}  Le GID est socké dans l'attribut gidNumber qui doit être assigné à une entrée posixGroupAccount
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge authPassword }
 
\
 
\hspace{1mm}  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
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge userPassword }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge exactUser }
 
\
 
\hspace{1mm} 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:
 
{\ttfamily
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\} )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge uniqueMember }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge description }
 
\
 
\hspace{1mm}  L'attribut description peut être associé avec une entrée posixGroupAccount pour fournir une description arbitraire de l'entrée.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge manager }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge disableObject }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Exemple d'entrée groupe }
 
\
 
\hspace{1mm} L'exemple suivant est une entrée posixGroupAccount au format LDIF:
 
{\ttfamily
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\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Overlays }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge ObjectClass }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge dbisPasswdOverlay }
 
\
 
\hspace{1mm} La classe dbisPasswdOverlay est définie comme suit:
 
{\ttfamily
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 ) )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge dbisGroupOverlay }
 
\
 
\hspace{1mm} La classe dbisGroupOverlay est définie comme suit:
 
{\ttfamily
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 ) )\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Attributs }
 
\
 
 
 
\vspace{1cm}{\huge en }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge uidNumber }
 
\
 
\hspace{1mm}  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
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge gidNumber }
 
\
 
\hspace{1mm}  Un GID alternatif à utiliser pour un groupe correspondant peut être stocké dans l'attribut gidNumber qui peut être associé avec une entrée dbisGroupOverlay
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge HomeDirectory }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge loginShell }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge description }
 
\
 
\hspace{1mm}  L'attribut description peut être associé avec une entrée dbisPasswdOverlay ou dbisGroupOverlay pour fournir une description arbitraire de l'entrée.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge disableObject }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Exemple d'entrées overlay }
 
\
 
\hspace{1mm} 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:
 
{\ttfamily
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\\ \hspace{2mm}\\ 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\\ \hspace{2mm}\\ dn: en=julie,ou=passwd,ou=overlays,ou=sales-merger,o=infra\\ objectClass: top\\ objectClass: dbisPasswdOverlay\\ en: julie\\ uidNumber: 5001\\ loginShell: /bin/sh\\
}
\vspace{8mm}
 
\hspace{1mm} 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:
 
{\ttfamily
dn: en=finance,ou=group,ou=overlays,ou=sales-merger,o=infra\\ objectClass: top\\ objectClass: dbisGroupOverlay\\ en: finance\\ gidNumber: 7308\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Syntaxe d'attributs }
 
\
 
\hspace{1mm} Les syntaxes suivantes sont utilisée par les attributs définis dans ce document:
 
{\ttfamily
Syntax OID - - - - - - - - - - Value - - - - - - Reference\\ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \\ 1.3.6.1.4.1.1466.115.121.1.12 DN - - - - - - - - \texttt{[}RFC4517\texttt{]}\\ 1.3.6.1.4.1.1466.115.121.1.15 Directory String -\texttt{[}RFC4517\texttt{]}\\ 1.3.6.1.4.1.1466.115.121.1.26 IA5 String - - - -\texttt{[}RFC4517\texttt{]}\\ 1.3.6.1.4.1.1466.115.121.1.27 Integer - - - - - \texttt{[}RFC4517\texttt{]}\\ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Notes d'implémentation }
 
\
 
 
 
\vspace{1cm}{\huge Mappage des champs compatibles NIS }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge passwd }
 
\
 
\hspace{1mm} Les champs de la base passwd sont mappés comme suit:
 
{\ttfamily
user = en\\ password = \%x78 ; lowercase "x", see below\\ uid = uidNumber\\ gid = gidNumber\\ gecos = dbisMapGecos ; derived, see below\\ homedir = homeDirectory\\ loginshell = loginShell\\ \hspace{2mm}\\ passwd-entry = user COLON password COLON uid COLON gid COLON gecos COLON homedir COLON loginshell\\
}
\vspace{8mm}
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{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.}
\item[\hspace{1mm} -]{gecos est déterminé en recherchant l'attribut définis par l'attribut dbisMapGecos donné dans l'entrée de map de configuration.}
\end{description}
 
\vspace{1cm}{\huge group }
 
\
 
\hspace{1mm} Les champs de la base group sont mappés comme suit:
 
{\ttfamily
group = en\\ password = \%x2a ; asterisk "*", see below\\ gid = gidNumber\\ users = exactUser ; derived, see below\\ \hspace{2mm}\\ group-entry = group COLON password COLON gid COLON users\\
}
\vspace{8mm}
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Pour des raisons de sécurité il est recommandé que le mot de passe soit mis à "*" et pas de authPassword.}
\item[\hspace{1mm} -]{La liste des utilisateur est une liste séparé par des virgules d'attributs exactUser.}
\end{description}
 
\vspace{1cm}{\huge Filtres de recherche communs }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm} Pour localiser la map de configuration pour un domain DBIS donné, rechercher les entrées sous l'entrée dbisDomainObject: \\
\hspace{1mm} \textbf{(\&(objectClass=dbisPasswdConfig)(!(disableObject=TRUE)))} \\
\hspace{1mm} \textbf{(\&(objectClass=dbisGroupConfig)(!(disableObject=TRUE)))} \\
\hspace{1mm} Les entrées passwd et group sont énumérées en appliquant le filtre dbisMapFilter suivant: \\
\hspace{1mm} \textbf{(\&(dbisMapFilter)(!(disableObject=TRUE)))} \\
\hspace{1mm} Si une entrée passwd et group est connue pas "name", sa définition est localisée en utilisant le filtre de recherche suivant: \\
\hspace{1mm} \textbf{(\&(dbisMapFilter)(!(disableObject=TRUE))(en=name))} \\
\hspace{1mm} Si une entrée passwd a l'uid "uid", sa définition est localisée en utilisant le filtre suivant: \\
\hspace{1mm} \textbf{(\&(dbisMapFilter)(!(disableObject=TRUE))(uidNumber=uid))} \\
\hspace{1mm} Si une entrée group a le gid "gid", sa définition est localisée en utilisant le filtre suivant: \\
\hspace{1mm} \textbf{(\&(dbisMapFilter)(!(disableObject=TRUE))(gidNumber=gid))} \\
\end{flushleft}
\end{document}
