Modèle de sécurité des services de noms LDAP

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).

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

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.

Sécurité de la couche de transport

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.

Affectation de niveaux d'identification client

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.

• anonymous

• proxy

• proxy anonymous

• self (appelé par utilisateur dans ce document)

Niveau d'identification anonymous LDAP

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é.

---

Niveau d'identification proxy LDAP

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.

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.

Niveau d'identification proxy anonymous LDAP

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é.

Authentification per-user LDAP

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.

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.

Commutateur enableShadowUpdate

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.

Stockage des informations d'identification des clients LDAP

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.

Choix des méthodes d'authentification du service de noms LDAP

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.

• none

  Le client ne s'authentifie sur l'annuaire. Il s'agit de l'équivalent du niveau d'identification anonymous.

• simple

  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.

• sasl/digest-MD5

  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.

• tls:simple

  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

Spécification des méthodes d'authentification pour des services spécifiques dans LDAP

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 :

• passwd-cmd

  Ce service est utilisé par passwd(1) pour modifier le mot de passe de connexion et ses attributs.

• keyserv

  Les utilitaires chkey(1) et newkey(1M) créent et modifient une paire de clés Diffie-Hellman par le biais de ce service.

• pam_ldap

  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.

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

Méthodes d'authentification enfichables

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.

Modules de service pam_unix_*

Si vous n'avez pas modifié le fichier /etc/pam.conf, l'authentification UNIX est activée par défaut.

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.

1. Le client récupère le mot de passe chiffré de l'utilisateur auprès du service de noms.

2. L'utilisateur est invité à saisir le mot de passe utilisateur.

3. Le mot de passe utilisateur est chiffré.

4. 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.

Module de service Kerberos

Reportez-vous à la page de manuel pam_krb5(5) et au manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.

Module de service LDAP

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.

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

PAM et modification des mots de passe

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.

Gestion des comptes LDAP

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.

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.

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

Gestion des comptes LDAP avec les modules pam_unix_*

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.