Dépannage

Quels sont les problèmes rencontrés ?

L’Assistant Migration des données NIS ou l’utilitaire de ligne de commande fonctionne correctement, mais aucun mappage n’est ajouté au Serveur pour NIS.

Cause :  L’option Ne pas effectuer la migration (consigner uniquement) était sélectionnée.

Solution :  puisque la migration est irréversible, l’option Ne pas migrer (uniquement journaliser) est l’option par défaut. Vous pouvez remplacer l’option par défaut lors de l’exécution de l’Assistant en sélectionnant Remplacer ou Conserver sur la page Gérer les conflits de migration de l’Assistant Migration des données NIS. Pour remplacer la valeur par défaut lorsque vous exécutez l’utilitaire en ligne de commande pour effectuer la migration à la place (Nis2ad.exe), spécifiez l’option -m sur la ligne de commande.

Des conflits de migration se produisent malgré la réussite d’un test de migration avec l’option Ne pas effectuer la migration (consigner uniquement) sélectionnée.

Cause :  si des données génèrent un conflit dans des bases de données NIS (Network Information Service) dont vous effectuez la migration, ce conflit risque de ne pas être consigné tant que la migration en cours n’est pas terminée, car Serveur pour NIS signale uniquement les conflits entre des mappages NIS et Active Directory.

Solution :  résolvez les conflits dans les bases de données NIS d’origine, puis effectuez la migration des données NIS qui n’ont pas migré à l’aide de l’option de ligne de commande nis2ad –r yes.

Un conflit se produit lors de la tentative de migration de plusieurs utilisateurs avec le même identificateur d’utilisateur (UID).

Cause :  l’Assistant Migration des données NIS ne peut pas procéder à la migration d’utilisateurs possédant le même UID. Seule la migration du premier utilisateur réussit.

Solution :  vérifiez que tous les utilisateurs possèdent des UID uniques avant la migration des bases de données NIS.

L’Assistant Migration des données NIS ou l’utilitaire de ligne de commande signale des conflits de noms NIS (Network Information Service) avec le compte système.

Cause :  un nom d’utilisateur dans NIS est identique à un nom de compte Windows réservé. Les noms de comptes réservés incluent des noms tels que Réseau, Système, Utilisateurs et Ordinateurs.

Solution :  résolvez le conflit en renommant le compte UNIX, puis en effectuant à nouveau la migration de l’entrée à l’aide de l’option de ligne de commande nis2ad –r yes.

L’utilitaire ypmatch échoue sur un ordinateur HP-UX.

Cause :  un mappage contient des clés avec des majuscules et des minuscules. Le système d’exploitation HP-UX convertit toutes les clés en minuscules avant l’envoi de la requête NIS. Il s’agit d’un problème lié au système d’exploitation HP-UX qui dépasse le cadre de Serveur pour NIS.

Solution :  convertissez les clés en minuscules avant de les faire migrer.

La première demande effectuée vers le Serveur pour NIS échoue.

Cause :  si le nombre d’objets migrés vers le Serveur pour NIS était très important, la création du cache de mappage par le Serveur pour NIS peut prendre longtemps.

Solution :  effectuez à nouveau la demande après un délai d’au moins 30 minutes. Les demandes suivantes peuvent fonctionner.

Les objets migrés vers des conteneurs non standard n’apparaissent pas dans Utilisateurs et ordinateurs Active Directory.

Cause :  le composant Utilisateurs et ordinateurs Active Directory n’affiche pas de conteneur non standard par défaut.

Solution :  dans le menu Affichage, cliquez sur Fonctionnalités avancées.

L’utilitaire ypcat affiche parfois des informations de mot de passe incorrectes, en revanche ypmatch fournit les informations correctes.

Cause :  les données de Serveur pour NIS n’ont pas encore mis à jour le cache de mappage après la modification des données dans Active Directory. L’utilitaire ypcat recueille ses informations à partir de ce cache ; l’utilitaire ypmatch obtient ses informations directement depuis Active Directory.

Solution :  diminuez l’intervalle d’actualisation entre les mises à jour du cache de mappage, ou vérifiez que les mises à jour ont été immédiatement mises en cache suite à des modifications dans Active Directory. Pour plus d’informations, voir Modification de la fréquence des mises à jour de mappage et Propager des mappages modifiés maintenant.

Les utilisateurs dotés de nouveaux comptes Windows créés par la migration NIS ne peuvent se connecter ni à Windows ni à des ordinateurs clients NIS.

Cause :  pour éviter d’exposer de nouveaux comptes à une utilisation erronée, l’Assistant de migration désactive les nouveaux comptes.

Solution :  après l’exécution de la migration, activez les nouveaux comptes uniquement lorsque les utilisateurs sont prêts à les utiliser. Pour des raisons de sécurité, nous vous recommandons de modifier le mot de passe sur tous les comptes d’utilisateur Windows nouvellement créés avec des valeurs temporaires. Avertissez les utilisateurs au sujet des mots de passe temporaires et demandez-leur de modifier leurs mots de passe Windows dès que possible. Informez-les sur la fréquence de propagation des modifications de mappage (voir Envoi de mises à jour de mappage périodiques vers des serveurs NIS subordonnés), afin qu’ils sachent à quel moment leurs mots de passe UNIX seront mis à jour.

Un compte d’utilisateur désactivé dans Active Directory n’est pas également désactivé sur les hôtes UNIX.

Cause :  les comptes Windows et UNIX doivent être désactivés séparément car le mécanisme de désactivation est fondamentalement différent, et la méthode de désactivation de comptes UNIX diffère en fonction de la version du système et des préférences de l’administrateur.

Solution :  après la désactivation d’un compte à l’aide du composant Utilisateurs et ordinateurs Active Directory, vous devez aussi désactiver ou verrouiller le compte UNIX correspondant selon les moyens habituels (comme la modification du mot de passe avec une valeur inconnue de l’utilisateur, en ajoutant un caractère spécial au mot de passe de l’utilisateur dans le fichier passwd, en modifiant l’environnement de démarrage du compte, ou l’ensemble des trois).

Un utilisateur nouvellement migré n’est pas authentifié par un client UNIX.

Cause :  erreurs de configuration éventuelles sur l’ordinateur client.

Solution :  suivez les étapes de résolution de problèmes ci-dessous pour le système d’exploitation client indiqué.

Sur un ordinateur client exécutant le système d’exploitation Solaris :

  • Vérifiez que l’ordinateur Windows qui exécute Serveur pour NIS est ajouté au fichier /etc/hosts sur le client Solaris. Exécutez ensuite la commande ypwhich sur le client et vérifiez que l’ordinateur Windows correct apparaît.

  • Assurez-vous que le fichier /etc/nsswitch.conf contient une entrée similaire à celle ci-dessous :

    passwd:   files [NOTFOUND=continue] nis

  • Vérifiez que l’utilisateur n’est pas répertorié dans le fichier passwd local.

  • Ajoutez l’élément suivant à la fin du fichier /etc/passwd sur l’ordinateur client :

    +::::::

  • Assurez-vous que les fichiers shadow sont également migrés vers le Serveur pour NIS, le cas échéant.

  • Vérifiez que la commande ypcat password n’affiche pas X dans le champ de mot de passe de l’utilisateur.

  • Assurez-vous que le fichier /var/yp/securenets est configuré de manière à autoriser l’authentification à partir de l’ordinateur client.

Sur un ordinateur client exécutant le système d’exploitation Linux :

  • Vérifiez que le serveur Windows qui exécute Serveur pour NIS a été ajouté au fichier /etc/hosts sur l’ordinateur client et que la commande ypwhich sur l’ordinateur client affiche correctement le nom de l’ordinateur basé sur Windows.

  • Assurez-vous que l’entrée USENIS dans /etc/sysconfig/authconfig est défini à USENIS=yes.

  • Vérifiez que le fichier nsswitch.conf est correctement configuré.

Table des matières