Utilisation des services de noms et d'annuaire Oracle® Solaris 11.2 : DNS et NIS

Quitter la vue de l'impression

Mis à jour : Juillet 2014
 
 

Présentation du module de service de noms nss_ad

Le client Oracle Solaris doit être joint à un domaine AD pour que les fonctionnalités d'interopérabilité AD (y compris nss_ad) puissent être utilisées. L'utilitaire kclient permet de relier le client à AD. Durant l'opération de liaison, kclient configure Kerberos v5 sur le client. Par conséquent, nss_ad peut être utilisé pour résoudre les demandes de service de noms en spécifiant ad en tant que source dans le fichier nsswitch.conf pour les bases de données prises en charge. Le module nss_ad utilise les identifiants hôte pour rechercher les informations relatives au service de noms dans AD.

Le module nss_ad utilise les enregistrements du serveur DNS pour détecter automatiquement les serveurs d'annuaire AD tels que les contrôleurs et les serveurs de catalogue global. Par conséquent, DNS doit être correctement configuré sur le client Oracle Solaris. Le module nss_ad utilise également le protocole LDAP v3 pour accéder aux informations de nommage à partir des serveurs AD. Le schéma du serveur AD ne requiert aucune modification car nss_ad fonctionne avec le schéma AD natif.

Actuellement, le module nss_ad ne prend pas en charge les connexions des utilisateurs Windows sur le système Oracle Solaris. Tant que ces connexions sont prises en charge, ces utilisateurs doivent continuer à se connecter en utilisant les backends traditionnels tels que nis et ldap.

Les services idmap et svc:/system/name-service/cache doivent être activés pour que nss_ad puisse être utilisé. Le module nss_ad tire parti du service idmap pour le mappage des identifiants de sécurité Windows (SID), des identifiants utilisateur UNIX et des identifiants de groupe (GID).

Assurez-vous que tous les noms de groupe et d'utilisateur AD sont désignés à l'aide de noms de domaine tels que user@domain ou group@domain. Par exemple, getpwnam(dana) échoue, mais getpwnam(dana@domain) réussit, à condition que dana soit un utilisateur Windows valide dans le domaine nommé domain.

Les règles supplémentaires suivantes s'appliquent également au module nss_ad :

  • A l'instar d'AD, nss_ad effectue un rapprochement sensible à la casse des noms de groupe et d'utilisateur.

  • Employez le module nss_ad uniquement dans les environnements linguistiques UTF-8 ou les domaines où les utilisateurs et les groupes sont uniquement constitués de caractères ASCII.

  • Les SID connus sont un ensemble de SID qui identifie des utilisateurs ou des groupes génériques dans l'environnement Windows. Ils ne sont pas spécifiques au domaine et leurs valeurs restent constantes dans tous les systèmes d'exploitation Windows. Les noms de SID bien connus sont qualifiés par la chaîne BUILTIN (Remote Desktop Users@BUILTIN, par exemple).

  • Le module nss_ad ne prend pas en charge l'énumération. Par conséquent, les interfaces et les commandes getpwent() et getgrent() qui les utilisent (getent passwd et getent group, par exemple) ne peuvent pas récupérer les informations d'AD.

  • Actuellement, le module nss_ad prend uniquement en charge les fichiers passwd et group. nss_ad ne prend pas en charge les autres bases de données de service de noms qui suivent l'entrée passwd, telles que audit_user et user_attr. Si le backend ad est traité (en fonction de la configuration), il renvoie NOT FOUND pour ces bases de données.