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)
Documents de référence conseillés
Services de noms LDAP comparés à d'autres services de noms
Avantages des services de noms LDAP
Restrictions en matière de services de noms LDAP
Configuration des services de noms LDAP (liste des tâches)
Format d'échange de données LDAP
Utilisation des noms de domaine complets avec LDAP
Arborescence des informations d'annuaire par défaut
Descripteurs de recherche de service et mappage de schémas
Attributs de profil client LDAP
Modèle de sécurité des services de noms LDAP
Sécurité de la couche de transport
Affectation de niveaux d'identification client
Niveau d'identification anonymous LDAP
Niveau d'identification proxy LDAP
Niveau d'identification proxy anonymous LDAP
Authentification per-user LDAP
Commutateur enableShadowUpdate
Stockage des informations d'identification des clients LDAP
Choix des méthodes d'authentification du service de noms LDAP
Spécification des méthodes d'authentification pour des services spécifiques dans LDAP
Méthodes d'authentification enfichables
10. Exigences de planification pour les services de noms LDAP (tâches)
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 peuvent utiliser le référentiel LDAP de deux façons différentes : soit en tant que source d'un service de noms et d'un service d'authentification, soit strictement en tant que source de données de nommage. Cette section présente les concepts d'identité client, les méthodes d'authentification, les modules pam_ldap et pam_unix_* et la gestion des comptes lorsque le référentiel LDAP est utilisé comme service de noms et d'authentification. Cette section aborde également l'utilisation des services de noms LDAP avec l'environnement Kerberos (Partie VI, Service Kerberos du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité) et les modules pam_krb5(5).
Remarque - Auparavant, si vous activiez la gestion des comptes pam_ldap, tous les utilisateurs devaient fournir un mot de passe de connexion pour s'authentifier à chaque fois qu'ils se connectaient au système. Par conséquent, les connexions qui ne reposent pas sur des mots de passe à l'aide des outils tels que ssh échoueraient.
Effectuez la gestion des comptes et récupérez le statut du compte des utilisateurs sans authentification au serveur d'annuaire au moment de la connexion. Le nouveau contrôle sur le serveur d'annuaire est 1.3.6.1.4.1.42.2.27.9.5.8 ; il est activé par défaut.
Pour définir ce contrôle sur une autre valeur que celle par défaut, ajoutez des instructions de contrôle d'accès (ACI) sur le serveur d'annuaire :
dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid:1.3.6.1.4.1.42.2.27.9.5.8 cn:Password Policy Account Usable Request Control aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; allow (read, search, compare, proxy) (groupdn = "ldap:///cn=Administrators,cn=config");) creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=server,cn=plugins,cn=config
Remarque - Si vous utilisez Kerberos comme système d'authentification et l'intégrer avec le système de nommage LDAP, vous serez en mesure de prendre en charge un environnement à authentification unique (SSO) dans votre entreprise par le biais Kerberos. Vous pourrez également utiliser ce même système d'identité lors de l'interrogation des données de nommage LDAP par utilisateur ou par hôte.
Pour accéder aux informations contenues dans le référentiel LDAP, les clients peuvent d'abord établir leur identité avec le serveur d'annuaire. Cette identité peut être anonyme ou celle d'un hôte ou d'un utilisateur reconnu par le serveur LDAP. En fonction de l'identité du client et des informations de contrôle d'accès (ACI) du serveur, le serveur LDAP permet au client de lire des informations d'annuaire. Pour plus d'informations sur les ACI, consultez le Administration Guide pour la version de Oracle Directory Server Enterprise Edition dont vous disposez.
Si l'identité est basée sur l'hôte d'où provient la demande, vous utilisez l'authentification de proxy. Une fois que l'hôte a été authentifié, tous les utilisateurs sur cet hôte obtiennent un accès. Si l'identité est basée sur l'utilisateur, vous appliquez l'authentification par utilisateur. Chaque utilisateur d'un hôte doit être authentifié pour obtenir un accès.
Si le client se connecte à un autre titre que celui d'anonyme pour n'importe quelle demande donnée, le client doit prouver son identité au serveur à l'aide d'une méthode d'authentification prise en charge à la fois par le client et le serveur. Une fois que le client a établi son identité, il peut alors effectuer les différentes demandes LDAP.
Lorsque vous vous connectez à un système, le service PAM peut utiliser les informations de la machine locale, du service LDAP, d'un serveur Kerberos ou une combinaison des trois pour décider si la tentative de connexion aboutit. Lorsque le module pam_kerb est utilisé, la décision d'autoriser ou non l'accès provient du serveur Kerberos. Lorsque le module pam_ldap est utilisé, la moitié des décisions provient du serveur LDAP et l'autre moitié de l'hôte local. Pour les informations issues de l'hôte local à l'aide des modules pam_unix_*, la décision est prise localement.
Lorsque vous utilisez pam_ldap pour vous connecter à l'aide du service LDAP, il existe une distinction entre la manière dont le service de noms et le service d'authentification (pam_ldap) accèdent à l'annuaire. Le service de noms lit diverses entrées et leurs attributs à partir de l'annuaire en fonction de l'identité prédéfinie. Le service d'authentification établit si l'utilisateur a entré le mot de passe correct lors de la saisie de son nom d'utilisateur et mot de passe pour s'authentifier auprès du serveur LDAP. Pour plus d'informations sur le service d'authentification, reportez-vous à la page de manuel pam_ldap(5).
Si Kerberos est utilisé pour réaliser des opérations d'authentification, et lorsque l'authentification est également activée dans les services de noms LDAP (tel qu'exigé pour le mode par utilisateur), Kerberos peut offrir deux fonctions. Kerberos s'authentifie auprès du serveur et l'identité Kerberos pour l'utilisateur ou l'hôte principal est utilisée pour s'authentifier auprès de l'annuaire. De cette façon, la même identité d'utilisateur utilisée pour l'authentification auprès du système est également utilisée pour s'authentifier auprès de l'annuaire pour les recherches et les mises à jour. Les administrateurs peuvent utiliser les informations de contrôle d'accès (ACI) dans l'annuaire pour limiter les résultats du service de noms.
La sécurité de la couche de transport (TLS, Transport layer security) peut être utilisée pour communiquer entre un client LDAP et le serveur d'annuaire, garantissant ainsi la confidentialité et l'intégrité des données. Le protocole TLS est un surensemble du protocole SSL (Secure Sockets Layer). Les services de noms LDAP prennent en charge les connexions TLS. N'oubliez pas que l'utilisation de SSL constitue une charge supplémentaire sur le serveur d'annuaire et le client.
Vous devez configurer le serveur d'annuaire pour le protocole SSL. Pour plus d'informations sur la configuration de Oracle Directory Server Enterprise Edition pour SSL, reportez-vous au Guide d'administration pour la version du Oracle Directory Server Enterprise Edition que vous utilisez. Vous devez également configurer le client LDAP pour le protocole SSL.
Si vous utilisez TLS, vous devez installer les bases de données de sécurité requises. Sont nécessaires, en particulier, les fichiers des bases de données des clés et des certificats. Par exemple, si vous adoptez un ancien format de base de données Netscape Communicator, les deux fichiers, cert7.db et key3.db sont nécessaires. De même, si vous utilisez un nouveau format de base de données de Mozilla, les trois fichiers cert8.db, key3.db et secmod.db sont nécessaires. Les fichiers cert7.db ou cert8.db contiennent des certificats de confiance. Le fichier key3.db contient les clés du client. Même si le client de service de noms LDAP n'utilise pas de clés client, ce fichier doit être présent. Le fichier secmod.db contient les modules de sécurité comme PKCS#11. Ce fichier n'est pas requis si l'ancien format est utilisé.
Reportez-vous à la section Configuration de la sécurité TLS pour plus d'informations.
Les clients des services de noms LDAP s'authentifient auprès du serveur LDAP conformément à leur niveau d'identification. Les clients LDAP peuvent recevoir plusieurs informations d'identification leur permettant de s'authentifier auprès d'un serveur d'annuaire.
Si vous utilisez l'accès anonymous, vous pouvez accéder uniquement aux données qui sont disponibles pour tout le monde. En mode anonyme, l'opération LDAP BIND n'a pas lieu. En outre, vous devez prendre en compte les implications en matière de sécurité. L'autorisation de l'accès anonymous à certaines parties de l'annuaire implique que toute personne ayant accès à l'annuaire dispose d'un accès en lecture. Si vous utilisez un niveau d'identification anonymous, vous devez autoriser l'accès en lecture à tous les attributs et entrées de nommage LDAP.
![]() | Attention - Vous ne devez jamais autoriser l'écriture anonymous pour un annuaire, car quiconque pourrait modifier les informations contenues dans l'arborescence d'informations d'annuaire à laquelle il dispose d'un accès en écriture, y compris le mot de passe d'un autre utilisateur ou leur propre identité. |
Remarque - Oracle Directory Server Enterprise Edition vous permet de restreindre l'accès par rapport à des adresses IP, un nom DNS, une méthode d'authentification et l'heure de la journée. Vous pouvez souhaiter limiter l'accès avec d'autres restrictions. Pour plus d'informations, reportez-vous à "Managing Access Control" dans le Administration Guide pour la version de Oracle Directory Server Enterprise Edition que vous utilisez.
Le client authentifie ou établit une liaison vers un ensemble partagé unique d'informations d'authentification de liaison LDAP, également connu sous le nom de compte proxy. Ce compte proxy peut être n'importe quelle entrée autorisée à effectuer une liaison à l'annuaire. Il nécessite un accès suffisant pour exécuter les fonctions du service de noms sur le serveur LDAP. Le compte proxy est une ressource partagée par système. C'est-à-dire que chaque utilisateur connecté à un système à l'aide de l'accès proxy, y compris l'utilisateur root, voit les mêmes résultats que tous les autres utilisateurs sur le système. Vous devez configurer les paramètres proxyDN et proxyPassword sur chaque client utilisant le niveau d'identification proxy. Le paramètre proxyPassword chiffré est stocké localement sur le client. Vous pouvez configurer différents proxies pour différents groupes de clients. Par exemple, vous pouvez configurer un proxy pour que tous les clients commerciaux accèdent aux annuaires des ventes et à ceux ouverts à l'ensemble de la société, tout en empêchant ces clients d'accéder aux annuaires des ressources humaines contenant des informations sur les feuilles de paie. Ou, dans les cas extrêmes, vous pouvez affecter des proxies différents pour chaque client ou un seul serveur proxy pour tous les clients. Un déploiement LDAP standard se trouve probablement entre ces deux extrêmes. Prenez en compte les différents choix attentivement. Un nombre trop limité d'agents proxy est susceptible de limiter votre capacité à contrôler l'accès des utilisateurs aux ressources. Cependant, trop de proxies compliquent la configuration et la maintenance du système. Vous devez accorder les droits appropriés à l'utilisateur proxy, en fonction de votre environnement. Pour plus d'informations sur la façon de déterminer la méthode d'authentification la plus appropriée pour votre configuration, reportez-vous à la section Stockage des informations d'identification des clients LDAP.
Si un mot de passe est modifié pour un utilisateur proxy, vous devez le mettre à jour sur chaque client qui utilise cet utilisateur proxy. Si vous utilisez la fonction de durée de vie des mots de passe sur les comptes LDAP, assurez-vous de la désactiver pour les utilisateurs proxy.
Remarque - N'oubliez pas que le niveau d'identification proxy s'applique à tous les utilisateurs et processus sur tout système donné. Si deux utilisateurs doivent utiliser différentes stratégies de nommage, ils doivent utiliser des machines différentes, ou le modèle d'authentification par utilisateur.
En outre, si les clients utilisent des informations d'identification proxy pour s'authentifier, le proxyDN doit avoir le même mot de passe proxyPassword sur tous les serveurs.
proxy anonymous est une entrée à valeurs multiples, au sens où plusieurs niveaux d'identification sont définis. Un client avec le niveau proxy anonymous va d'abord tenter de s'authentifier avec son identité proxy. Si le client n'est pas en mesure de s'authentifier en tant qu'utilisateur proxy pour quelque raison que ce soit (verrouillage d'utilisateur, le mot de passe est arrivé à expiration, par exemple), le client va utiliser l'accès anonyme. Cette option risque d'entraîner un autre niveau de service, en fonction de la façon dont l'annuaire est configuré.
L'authentification par utilisateur (self ou per-user) utilise l'identité Kerberos (principale) pour effectuer une recherche pour chaque utilisateur ou chaque système lors de l'authentification auprès du serveur d'annuaire. Avec une authentification par utilisateur, l'administrateur système peut tirer parti des instructions de contrôle d'accès (ACI), des listes de contrôle d'accès (ACL), des rôles, des groupes ou d'autres mécanismes de contrôle de l'accès à l'annuaire pour accorder ou refuser l'accès à des données de services de noms spécifiques à des utilisateurs ou des systèmes spécifiques.
Remarque - Lorsque vous configurez le mode par utilisateur, la valeur de configuration pour activer ce mode est "self".
Pour utiliser le modèle d'authentification par utilisateur, le service de connexion unique de Kerberos doit être déployé. En outre, le ou les serveurs d'annuaire utilisés dans le déploiement doivent prendre en charge SASL et le mécanisme d'authentification SASL/GSSAPI. Comme Kerberos s'attend à utiliser des fichiers et le DNS pour les recherches de noms d'hôte, au lieu de LDAP, le DNS doit être déployé dans cet environnement. En outre, pour utiliser une authentification par utilisateur, nscd doit être activé. Le démon nscd n'est pas un composant facultatif dans cette configuration.
Si le commutateur enableShadowUpdate est défini sur true sur le client, les informations d'identification admin sont utilisées pour mettre à jour les données shadow. Ces données sont stockées dans la classe d'objet shadowAccount sur le serveur d'annuaire. Les informations d'identification administrateur sont définies par les valeurs des attributs adminDN et adminPassword, comme décrit à la section Attributs client LDAP locaux. Ces informations ne sont pas utilisées à d'autres fins.
Les informations d'identification administrateur ont des propriétés similaires aux informations d'identification proxy. L'exception étant que pour les informations d'identification administrateur, l'utilisateur doit avoir tous les privilèges de la zone ou un UID de root pour lire ou mettre à jour les données en double. Les informations d'identification administrateur peuvent être attribuées à n'importe quelle entrée autorisée à effectuer une liaison vers l'annuaire. Cependant, n'utilisez pas la même identité de gestionnaire d'annuaire (cn=Directory Manager) que celle du serveur LDAP.
Cette entrée, avec les informations d'identification administrateur, doit avoir un accès suffisant pour lire et écrire les données en double de l'annuaire. Etant donné que l'entrée est une ressource partagée par système, les attributs adminDN et adminPassword doivent être configurés sur chaque client. Le paramètre adminPassword chiffré est stocké localement sur le client. Le mot de passe utilise les mêmes méthodes d'authentification que celles configurées pour le client. Les informations d'identification administrateur sont utilisées par tous les utilisateurs et processus d'un système donné pour lire et mettre à jour les données en double.
Si vous configurez un client pour qu'il utilise une identité proxy, le client enregistre les informations de proxy dans le service svc:/network/ldap/client . L'implémentation LDAP actuelle ne stocke par les informations d'identification de proxy dans un profil de client. Toutes les informations d'identification de proxy définies à l'aide de ldapclient durant l'installation sont stockées dans le référentiel SMF. Cela se traduit par une amélioration de la sécurité relative aux informations de DN et de mot de passe du proxy. Pour plus d'informations sur la configuration des profils client, reportez-vous au Chapitre 12, Configuration des clients LDAP (tâches).
De même, si vous configurez un client pour qu'il autorise les mises à jour de données shadow et si le niveau d'identification n'est pas self, le client enregistre ses informations dans le service svc:/network/ldap/client.
Si vous configurez un client pour utiliser l'authentification par utilisateur, les informations de ticket et d'identité Kerberos pour chaque utilisateur ou hôte principal sont utilisées au cours de l'authentification. Dans cet environnement, le serveur d'annuaire mappe l'utilisateur ou l'hôte principal Kerberos sur un nom distinctif (DN) et les informations d'identification Kerberos sont utilisées pour l'authentification par rapport à ce DN. Le serveur d'annuaire peut alors appliquer ses mécanismes d'instructions de contrôle d'accès (ACI) pour autoriser ou refuser l'accès aux données des services de noms, selon les besoins. Dans cette situation, les informations du ticket Kerberos sont utilisées pour l'authentification auprès du serveur d'annuaire et les DN ou les mots de passe ne sont pas stockés sur le système. Par conséquent, dans ce type de configuration, inutile de spécifier les attributs adminDN et adminPassword lorsque le client est initialisé avec la commande ldapclient.
Lorsque vous affectez le niveau d'identification proxy ou proxy-anonymous à un client, vous devez également sélectionner la méthode utilisée par le proxy pour s'authentifier auprès du serveur d'annuaire. Par défaut, la méthode d'authentification est none, ce qui implique un accès anonyme. La méthode d'authentification peut également avoir une option de sécurité du transport qui lui est associée.
La méthode d'authentification, comme le niveau d'identification, peut être à valeurs multiples. Par exemple, dans le profil client, vous pouvez spécifier que le client tente d'abord d'établir la liaison à l'aide de la méthode simple sécurisée par TLS. Si la méthode n'aboutit pas, le client tente alors d'établir la liaison avec la méthode sasl/digest-MD5. La méthode authenticationMethod serait tls:simple;sasl/digest-MD5.
Les services de noms LDAP prennent en charge les mécanismes du protocole SASL (Simple Authentication and Security Layer). Ces mécanismes permettent l'échange d'un mot de passe sécurisé sans exiger le protocole TLS. Cependant, ces mécanismes ne fournissent pas l'intégrité ou la confidentialité des données. Pour plus d'informations sur le protocole SASL, consultez le document RFC 2222.
Les mécanismes d'authentification suivants sont pris en charge.
Le client ne s'authentifie sur l'annuaire. Il s'agit de l'équivalent du niveau d'identification anonymous.
Si le système client utilise la méthode d'authentification simple, il est lié au serveur par l'envoi du mot de passe de l'utilisateur en clair. Le mot de passe peut être volé sauf si la session est protégée par IPsec. Les principaux avantages de la méthode d'authentification simple sont que tous les serveurs d'annuaires la prennent en charge et qu'elle est facilement configurable.
Le mot de passe du client est protégé au cours de l'authentification, mais la session n'est pas chiffrée. Certains serveurs d'annuaire, y compris Oracle Directory Server Enterprise Edition, prennent également en charge la méthode d'authentification sasl/digest-MD5. Le principal avantage de digest-MD5 est que le mot de passe n'est pas envoyé sur le réseau en clair au cours de l'authentification et par conséquent, il est plus sûr que la méthode d'authentification simple. Pour plus d'informations sur digest-MD5 , reportez-vous au document RFC 2831. digest-MD5 est considéré comme une amélioration de cram-MD5 en raison du renforcement de la sécurité.
Lorsque vous utilisez sasl/digest-MD5, l'authentification est sécurisée, mais la session n'est pas protégée.
Remarque - Si vous utilisez Oracle Directory Server Enterprise Edition, le mot de passe doit être stocké en clair dans l'annuaire.
sasl/cram-MD5
Dans ce cas, la session LDAP n'est pas chiffrée, mais le mot de passe du client est protégé au cours de l'authentification, car celle-ci est effectuée par le biais de sasl/cram-MD5. Cette méthode d'authentification est obsolète et ne doit pas être appliquée.
sasl/GSSAPI
Cette méthode d'authentification est utilisée avec le mode d'identification self pour activer les recherches par utilisateur. Un démon nscd par utilisateur destiné à utiliser les informations d'identification du client se connecte au serveur d'annuaire à l'aide de la méthode sasl/GSSAPI et des informations d'identification Kerberos du client. L'accès peut être contrôlé dans le serveur d'annuaire par utilisateur.
Le client se connecte à l'aide de la méthode simple et la session est chiffrée. Le mot de passe est protégé.
tls:sasl/cram-MD5
La session LDAP est chiffrée et le client s'authentifie auprès du serveur d'annuaire à l'aide de sasl/cram-MD5.
tls:sasl/digest-MD5
La session LDAP est chiffrée et le client s'authentifie auprès du serveur d'annuaire à l'aide de sasl/digest-MD5.
![]() | Attention - Oracle Directory Server Enterprise Edition nécessite que les mots de passe soient stockés en clair afin de pouvoir utiliser digest-MD5. Si la méthode d'authentification est définie sur sasl/digest-MD5 ou tls:sasl/digest-MD5, les mots de passe de l'utilisateur proxy doivent être stockés en clair. Soyez particulièrement attentif à ce que l'attribut userPassword ait le bon ACI s'il est stocké en clair, afin qu'il ne soit pas lisible. |
Le tableau ci-dessous résume les différentes méthodes d'authentification et leurs caractéristiques respectives.
Tableau 9-4 Méthodes d'authentification
|
La méthode d'authentification peut être spécifiée pour un service donné dans l'attribut serviceAuthenticationMethod. Les services suivants permettent de sélectionner la méthode d'authentification :
Ce service est utilisé par passwd(1) pour modifier le mot de passe de connexion et ses attributs.
Les utilitaires chkey(1) et newkey(1M) créent et modifient une paire de clés Diffie-Hellman par le biais de ce service.
Ce service est mis en oeuvre lors de l'authentification d'utilisateurs avec pam_ldap(5).
pam_ldap prend en charge la gestion des comptes.
Remarque - Si aucune méthode serviceauthenticationmethod n'est définie, le service reçoit par défaut la valeur de l'attribut authenticationMethod.
Remarque - Dans le mode par utilisateur, Module de service Kerberos (pam Kerberos) fait office de service d'authentification. ServiceAuthenticationMethod n'est pas nécessaire dans ce mode de fonctionnement.
Remarque - Si le commutateur enableShadowUpdate est défini sur true, le démon ldap_cachemgr établit la liaison avec le serveur LDAP à l'aide de la méthode d'authentification définie dans le paramètre serviceAuthenticationMethod de passwd-cmd, le cas échéant. Si la méthode n'est pas définie, authenticationMethod est utilisée. Le démon n'utilise pas la méthode d'authentification none.
L'exemple ci-dessous illustre une section d'un profil client dans laquelle les utilisateurs utiliseront sasl/digest-MD5 pour s'authentifier auprès du serveur d'annuaire, mais utiliseront une session SSL pour modifier leur mot de passe.
serviceAuthenticationMethod=pam_ldap:sasl/digest-MD5 serviceAuthenticationMethod=passwd-cmd:tls:simple
Grâce à la structure PAM, vous pouvez choisir entre plusieurs services d'authentification, y compris pam_unix_*, pam_krb5 et pam_ldap_*.
Si la méthode d'authentification par utilisateur est utilisée (pam_krb5), le service d'authentification le plus complexe des méthodes mentionnées ci-dessus doit être activé. Reportez-vous à la page de manuel pam_krb5(5) et à la section Administration d’Oracle Solaris 11.1 : Services de sécurité.
Le système d'authentification pam_krb5 peut être utilisé même si l'authentification par utilisateur n'est pas activée. Si des niveaux d'identification proxy ou anonymous sont utilisés pour accéder aux données du serveur d'annuaire, la restriction de l'accès par utilisateur aux données d'annuaire n'est pas possible.
En raison de sa flexibilité accrue, de la prise en charge de méthodes d'authentification plus complexes et de la capacité à utiliser la gestion des comptes, pam_ldap est recommandé par rapport aux modules pam_unix_* lorsque des méthodes d'authentification proxy ou anonymous sont utilisées.
Si vous n'avez pas modifié le fichier /etc/pam.conf, l'authentification UNIX est activée par défaut.
Remarque - Le module pam_unix a été supprimé et n'est plus pris en charge avec la version Oracle Solaris. Un ensemble d'autres modules de service offre des fonctions équivalentes ou meilleures. C'est pourquoi, dans ce guide, pam_unix fait référence à la fonction équivalente, et non au module pam_unix proprement dit.
Vous trouverez ci-après une liste des modules qui fournissent un équivalent du module pam_unix d'origine.
Les modules pam_unix_* suivent le modèle traditionnel d'authentification UNIX, comme décrit dans la liste suivante.
Le client récupère le mot de passe chiffré de l'utilisateur auprès du service de noms.
L'utilisateur est invité à saisir le mot de passe utilisateur.
Le mot de passe utilisateur est chiffré.
Le client compare les deux mots de passe chiffrés afin de déterminer si l'utilisateur doit s'authentifier.
En outre, deux restrictions existent lors de l'utilisation des modules pam_unix_* .
Le mot de passe doit être stocké au format crypt UNIX et avec aucune autre méthode de chiffrement, y compris la méthode en clair (sans codage).
L'attribut userPassword doit être lisible par le service de noms.
Par exemple, si vous définissez le niveau d'identification anonymous, toute personne doit être capable de lire l'attribut userPassword. De même, si vous définissez le niveau d'identification proxy, l'utilisateur proxy doit être capable de lire l'attribut userPassword.
Remarque - L'authentification UNIX n'est pas compatible avec la méthode d'authentification sasl digest-md5, car Oracle Directory Server Enterprise Edition impose que les mots de passe soient stockés en clair afin d'utiliser digest-md5. L'authentification UNIX requiert le stockage du mot de passe au format crypt.
Remarque - Le module pam_unix_account prend en charge la gestion des comptes lorsque le commutateur enableShadowUpdate est défini sur true. Les contrôles d'un compte utilisateur LDAP distant sont appliqués comme ceux d'un compte utilisateur local défini dans les fichiers passwd et shadow. En mode enableShadowUpdate, pour le compte LDAP, le système met à jour et utilise les données en double sur le serveur LDAP pour la durée de vie des mots de passe et le verrouillage de comptes. Bien entendu, les données en double sur le compte local s'appliquent uniquement au système client local, tandis que les données en double d'un compte utilisateur LDAP s'appliquent à l'utilisateur sur tous les systèmes client.
La vérification de l'historique du mot de passe n'est prise en charge que pour le client local, et non pour un compte utilisateur LDAP.
Reportez-vous à la page de manuel pam_krb5(5) et au manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
Lorsque vous implémentez l'authentification LDAP, l'utilisateur pam_ldap établit la liaison au serveur LDAP à l'aide de la méthode d'authentification définie dans le paramètre serviceAuthenticationMethod, s'il en existe une. Si la méthode n'est pas définie, authenticationMethod est utilisée.
Si pam_ldap est en mesure d'établir la liaison avec le serveur avec l'identité de l'utilisateur et le mot de passe fourni, il authentifie l'utilisateur.
Remarque - Auparavant, si vous activiez la gestion des comptes pam_ldap, tous les utilisateurs devaient fournir un mot de passe de connexion pour s'authentifier à chaque fois qu'ils se connectaient au système. Par conséquent, les connexions qui ne reposent pas sur des mots de passe à l'aide des outils tels que ssh échoueraient.
Effectuez la gestion des comptes et récupérez le statut du compte des utilisateurs sans authentification au serveur d'annuaire au moment de la connexion. Le nouveau contrôle sur le serveur d'annuaire est 1.3.6.1.4.1.42.2.27.9.5.8 ; il est activé par défaut.
Pour définir ce contrôle sur une autre valeur que celle par défaut, ajoutez des instructions de contrôle d'accès (ACI) sur le serveur d'annuaire :
dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid:1.3.6.1.4.1.42.2.27.9.5.8 cn:Password Policy Account Usable Request Control aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; allow (read, search, compare, proxy) (groupdn = "ldap:///cn=Administrators,cn=config");) creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=server,cn=plugins,cn=config
pam_ldap ne lit pas l'attribut userPassword. Par conséquent, il n'est pas nécessaire d'accorder d'accès pour lire l'attribut userPassword à moins que d'autres clients n'utilisent l'authentification UNIX. En outre, pam_ldap ne prend pas en charge la méthode d'authentification none. Par conséquent, vous devez définir les attributs serviceAuthenticationMethod ou authenticationMethod afin que les clients puissent utiliser pam_ldap. Pour plus d'informations, reportez-vous à la page de manuel pam_ldap(5).
![]() | Attention - Si la méthode d'authentification simple est utilisée, l'attribut userPassword peut être lu sur le réseau par des tiers. |
Le tableau suivant récapitule les principales différentes entre les mécanismes d'authentification.
Tableau 9-5 Comportement d'authentification dans LDAP
|
Exécutez la commande passwd pour modifier un mot de passe. Si le commutateur enableShadowUpdate n'est pas défini sur true, l'attribut userPassword doit être accessible en écriture par l'utilisateur. Si le commutateur enableShadowUpdate est défini sur true, les informations d'identification administrateur doivent être en mesure de mettre à jour l'attribut userPassword. Souvenez-vous que serviceAuthenticationMethod pour passwd-cmd prime sur authenticationMethod pour cette opération. Selon la méthode d'authentification utilisée, le mot de passe actuel peut être déchiffré sur le réseau.
En cas d'authentification UNIX, le nouvel attribut userPassword est chiffré à l'aide du format crypt UNIX et marqué avant d'être écrit sur LDAP. Par conséquent, le nouveau mot de passe est chiffré sur le réseau, quelle que soit la méthode d'authentification utilisée pour la liaison avec le serveur. Pour plus d'informations, reportez-vous à la page de manuel pam_authtok_store(5).
Si le commutateur enableShadowUpdate est défini sur true, les modules pam_unix_* mettent également à jour les informations shadow lorsque le mot de passe utilisateur est modifié. Les modules pam_unix_* mettent à jour les mêmes champs shadow dans les fichiers shadow locaux que les modules lors de la modification du mot de passe utilisateur.
pam_ldap ne prend plus en charge la mise à jour du mot de passe. pam_authtok_store avec l'option server_policy remplace désormais la fonction de mise à jour du mot de passe pam_ldap. Lorsque vous exécutez pam_authtok_store, le nouveau mot de passe est envoyé au serveur LDAP en clair. Par conséquent, pour garantir la confidentialité, utilisez TLS. Sinon, le nouveau mot de passe userPassword est susceptible d'être usurpé. Si vous définissez un mot de passe non balisé avec Oracle Directory Server Enterprise Edition, le logiciel chiffre le mot de passe à l'aide de l'attribut passwordStorageScheme. Pour plus d'informations sur le schéma passwordStorageScheme, reportez-vous à la section sur la gestion des comptes utilisateur dans le Administration Guide pour la version de Oracle Directory Server Enterprise Edition que vous utilisez.
Remarque - Vous devez prendre en compte les problèmes de configuration suivants lors de la définition de l'attribut passwordStorageScheme. Si un NIS ou un autre client mettant en oeuvre l'authentification UNIX utilise LDAP en tant que référentiel, passwordStorageScheme doit être crypt. Par ailleurs, si vous utilisez l'authentification LDAP avec sasl/digest-MD5 dans Oracle Directory Server Enterprise Edition, passwordStorageScheme doit être défini sur clear.
Si vous sélectionnez pam_krb5 en tant que système de gestion de vos compte et mot de passe, l'environnement Kerberos gérera toutes vos informations de compte, mot de passe, verrouillage de compte et autres. Reportez-vous à la page de manuel pam_krb5(5) et au manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
Si vous n'utilisez pas pam_krb5, les services de noms LDAP peuvent être configurés de façon à tirer parti de la prise en charge de la stratégie de mot de passe et de verrouillage de compte dans Oracle Directory Server Enterprise Edition. Vous pouvez configurer pam_ldap(5) pour prendre en charge la gestion des comptes utilisateur. passwd(1) applique les règles de syntaxe de mot de passe définies par la stratégie de mot de passe Oracle Directory Server Enterprise Edition, lorsqu'il est utilisé avec la bonne configuration PAM.
Les fonctions de gestion des comptes suivantes sont prises en charge par le biais de pam_ldap(5). Ces fonctions dépendent de la configuration de la stratégie de mot de passe et de verrouillage de compte de Oracle Directory Server Enterprise Edition. Vous pouvez activer autant de fonctions que vous le souhaitez.
Durée de vie des mots de passe et notification d'expiration
Les utilisateurs doivent modifier leurs mots de passe en fonction d'un calendrier. Un mot de passe expire s'il n'est pas modifié dans le temps configuré. Un mot de passe expiré entraîne l'échec de l'authentification utilisateur.
Les utilisateurs voient un message d'avertissement chaque fois qu'ils se connectent pendant la période d'avertissement d'expiration. Le message indique le nombre d'heures ou de jours restants jusqu'à ce que le mot de passe expire.
Vérification de la syntaxe du mot de passe
Les nouveaux mots de passe doivent respecter la longueur minimale requise pour le mot de passe. En outre, un mot de passe ne peut pas correspondre à la valeur des attributs uid, cn, sn ou mail dans l'entrée d'annuaire de l'utilisateur.
Vérification de l'historique de mot de passe
Les utilisateurs ne peuvent pas réutiliser les mots de passe. Si un utilisateur essaie de remplacer le mot de passe par un mot de passe précédemment utilisé, passwd(1) échoue. Les administrateurs LDAP peuvent configurer le nombre de mots de passe stockés dans la liste Historique du serveur.
Verrouillage de compte utilisateur
Un compte utilisateur peut être bloqué après un nombre donné de d'échecs d'authentification répétés. Un utilisateur peut également être bloqué si son compte est désactivé par un administrateur. L'authentification continuera d'échouer jusqu'à ce que la durée du verrouillage de compte soit écoulée ou jusqu'à ce que l'administrateur réactive le compte.
Remarque - Les fonctions de gestion des comptes précédentes ne fonctionnent qu'avec Oracle Directory Server Enterprise Edition. Pour plus d'informations sur la configuration de la stratégie de mot de passe et de verrouillage de compte sur le serveur, reportez-vous au chapitre "User Account Management" du guide d'administration pour la version de Oracle Directory Server Enterprise Edition que vous utilisez. Reportez-vous également à la section Exemple de fichier pam_conf utilisant le module pam_ldap pour la gestion des comptes. N'activez pas la gestion des comptes proxy.
Avant de configurer la stratégie de mot de passe et de verrouillage de compte sur Oracle Directory Server Enterprise Edition, assurez-vous que tous les hôtes utilisent le client LDAP “le plus récent” avec la gestion des comptes pam_ldap.
En outre, assurez-vous que les clients ont un fichier pam.conf(4) correctement configuré. Dans le cas contraire, les services de noms LDAP cessent de fonctionner lorsque les mots de passe proxy ou utilisateur expirent.
Remarque - Auparavant, si vous activiez la gestion des comptes pam_ldap, tous les utilisateurs devaient fournir un mot de passe de connexion pour s'authentifier à chaque fois qu'ils se connectaient au système. Par conséquent, les connexions qui ne reposent pas sur des mots de passe à l'aide des outils tels que ssh échoueraient.
Effectuez la gestion des comptes et récupérez le statut du compte des utilisateurs sans authentification au serveur d'annuaire au moment de la connexion. Le nouveau contrôle sur le serveur d'annuaire est 1.3.6.1.4.1.42.2.27.9.5.8 ; il est activé par défaut.
Pour définir ce contrôle sur une autre valeur que celle par défaut, ajoutez des instructions de contrôle d'accès (ACI) sur le serveur d'annuaire :
dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid:1.3.6.1.4.1.42.2.27.9.5.8 cn:Password Policy Account Usable Request Control aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; allow (read, search, compare, proxy) (groupdn = "ldap:///cn=Administrators,cn=config");) creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=server,cn=plugins,cn=config
Si le commutateur enableShadowUpdate est défini sur true sur le client, la fonction de gestion des comptes disponible pour les comptes locaux est également disponible sur les comptes LDAP. La fonction inclut la durée de vie des mots de passe, l'expiration des comptes et sa notification, le verrouillage des comptes dont la connexion a échoué, etc. En outre, les options -dluNfnwx pour la commande passwd sont maintenant prises en charge dans LDAP. Par conséquent, l'intégralité des fonctions de la commande passwd et des modules pam_unix_* dans le service de noms de fichiers est prise en charge dans le service de noms LDAP. Le commutateur enableShadowUpdate offre un moyen d'implémenter une gestion cohérente des comptes des utilisateurs définis dans les fichiers et sur l'étendue LDAP.
Pour empêcher les utilisateurs de modifier leurs propres données de gestion des comptes et de ce fait contourner la stratégie de mot de passe, le serveur LDAP est configuré de manière à interdire à l'utilisateur l'accès en écriture à ses données en double placées sur le serveur. Un administrateur doté d'informations d'identification administrateur effectue les mises à jour des données en double pour un système client. Une telle configuration, cependant, entre en conflit avec le module pam_ldap, qui exige que les mots de passe soient modifiables par des utilisateurs. Par conséquent, les opérations de gestion des comptes par les modules pam_ldap et pam_unix_* sont incompatibles.
![]() | Attention - N'utilisez pas les modules pam_ldap et pam_unix_* dans le même domaine de noms LDAP. Soit tous les clients utilisent le module pam_ldap, soit ils utilisent tous les modules pam_unix_*. Cette limitation peut indiquer que vous avez besoin d'un serveur LDAP dédié. Par exemple, une application Web ou de messagerie peut attendre des utilisateurs qu'ils modifient leur propre mot de passe sur le serveur LDAP. |
L'implémentation de enableShadowUpdate exige également que les informations d'identification administrateur (adminDN et adminPassword ) soient stockées localement sur chaque client. Ces informations sont stockées dans le service svc:/network/ldap/client.
Dans le cadre de la gestion des comptes, contrairement à pam_ldap, les modules pam_unix_* n'imposent pas d'apporter des modifications au fichier /etc/pam.conf. Le fichier /etc/pam.conf par défaut suffit.