Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Utilisation des services de noms et d'annuaire dans Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
Partie I A propos des services d'annuaire et de noms
1. Services d'annuaire et de noms (présentation)
2. Commutateur du service de noms (présentation)
4. Configuration des clients Active Directory Oracle Solaris (tâches)
Partie II Configuration et administration NIS
5. Service d'information réseau (présentation)
6. Définition et configuration du service NIS (tâches)
7. Administration de NIS (tâches)
Partie III Service de noms LDAP
9. Introduction aux services de noms LDAP (présentation)
10. Exigences de planification pour les services de noms LDAP (tâches)
Présentation de la planification LDAP
Planification du modèle de réseau LDAP
Planification de l'arborescence des informations d'annuaire
Serveurs d'annuaires multiples
Planification du modèle de sécurité LDAP
Planification des profils client et des valeurs d'attribut par défaut pour LDAP
Planification du renseignement de données LDAP
Remplissage d'un serveur avec des entrées host à l'aide de la commande ldapaddent
11. Configuration de Oracle Directory Server Enterprise Edition avec les clients LDAP (tâches)
12. Configuration des clients LDAP (tâches)
13. Dépannage LDAP (référence)
14. Service de noms LDAP (référence)
Les services de noms LDAP ont une arborescence d'informations d'annuaire (DIT) par défaut et un schéma par défaut associé. Par exemple, le conteneur ou=people inclut le compte utilisateur, le mot de passe et les informations shadow. Le conteneur ou=hosts inclut des informations sur les systèmes du réseau. Chaque entrée du conteneur ou=people est issue de objectclass posixAccount et shadowAccount.
L'arborescence DIT par défaut est une structure d'annuaire bien conçue et basée sur des normes ouvertes. Pour plus d'informations, reportez-vous aux documents RFC 2307bis et RFC 4876. L'arborescence DIT par défaut est censée répondre à la plupart des besoins de service de noms et est conseillée pour une utilisation sans modifications. Si vous choisissez d'utiliser l'arborescence DIT par défaut, il vous suffit de décider dans quel noeud (base DN) de l'arborescence des annuaires vous souhaitez rechercher les informations de services de noms pour un domaine donné. Ce noeud est spécifié avec l'attribut defaultSearchBase. De plus, vous souhaiterez parfois définir l'attribut defaultSearchScope afin d'indiquer aux clients l'étendue de la recherche du service de noms à cibler. Faut-il simplement rechercher dans un niveau sous le nom distinctif (one) ou dans toute la sous-arborescence située sous le nom distinctif (sub) ?
Cependant, une plus grande flexibilité est parfois nécessaire pour permettre au service de noms LDAP d'utiliser une arborescence DIT existante ou de gérer une arborescence DIT plus complexe avec des données de service de noms dispersées. Par exemple, des entrées du compte utilisateur peuvent exister dans différentes parties de l'arborescence. Les attributs serviceSearchDescriptor, attributeMap et objectclassMap du profil client sont conçus pour gérer ces situations.
Un descripteur de recherche de service peut être utilisé pour remplacer les valeurs par défaut pour la base de recherche, l'étendue de la recherche et le filtre de recherche d'un service particulier. Reportez-vous à la section Descripteurs de recherche de service et mappage de schémas.
Les attributs attributeMap et objectclassMap fournissent une méthode pour le mappage de schéma. Grâce à eux, les services de noms LDAP peuvent fonctionner avec une DIT existante. Vous pouvez mapper la classe d'objet posixAccount sur une classe d'objet existante (myAccount, par exemple). Vous pouvez mapper un attribut de la classe d'objet posixAccount sur un attribut de la classe d'objet myAccount.
Plusieurs serveurs LDAP peuvent servir une arborescence DIT. Par exemple, certaines sous-arborescences de l'arborescence DIT résident sur d'autres serveurs LDAP. Dans ce cas, un serveur LDAP peut renvoyer le client LDAP vers un serveur différent pour les données de nommage dont il connaît l'existence mais qui ne sont pas dans sa propre base de données. Si vous prévoyez une telle configuration DIT, vous devez définir l'attribut de profil des clients followReferrals de manière à indiquer au service de noms LDAP de suivre les références serveur pour continuer les recherches de service de noms. Cependant, il est préférable que toutes les données de nommage d'un domaine donné résident sur un seul serveur d'annuaire, dans la mesure du possible.
Les références peuvent être utiles si vous souhaitez que les clients aient accès aux répliques en lecture seule la plupart du temps et qu'ils suivent les références à un serveur maître en lecture/écriture uniquement lorsque cela est nécessaire. De cette façon, le serveur maître n'est pas surchargé de demandes qui pourraient être gérées par les répliques.
Pour faire le meilleur usage de LDAP, vous devez avoir une seule entrée LDAP pour chaque entrée logique. Par exemple, pour un utilisateur, vous pouvez avoir non seulement des informations extraites du livre blanc d'une société, mais aussi des informations de compte et éventuellement des données spécifiques aux applications. Etant donné que posixAccount et shadowAccount sont des classes d'objet auxiliaires, elles peuvent être ajoutées à n'importe quelle entrée de l'annuaire. Cette opération nécessite une planification, une configuration et une administration minutieuse.
Pour plus d'informations sur la procédure à suivre pour choisir un suffixe d'annuaire approprié, reportez-vous à la documentation relative à Oracle Directory Server Enterprise Edition.