Cliquez pour évaluer et commenter
TechNet
Bibliothèque TechNet
Windows
Windows Server
Windows Server 2003
Windows Server 2003 ...
R2: Product Help (R2 only)
 Résolution des problèmes relatifs a...

  Passer à l'affichage pour faible bande passante
Résolution des problèmes relatifs au service Serveur pour NIS

Résolution des problèmes

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 migrer (uniquement journaliser) » était activé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. Pour remplacer la valeur par défaut lorsque vous exécutez l'utilitaire de ligne de commande (Nis2ad.exe), spécifiez l'option -m sur la ligne de commande.

Des conflits de migration se produisent même si le test de migration avec l'option « Ne pas migrer » a réussi.

Cause :  si les données présentes dans les mappages NIS (Network Information Service) en cours de migration créent des conflits, ces derniers risquent de ne pas être signalés avant l'achèvement des mappages, car seuls les conflits entre mappages NIS et Active Directory sont consignés.

Solution :  résolvez les conflits dans les mappages NIS d'origine, puis effectuez la migration des données NIS qui n'ont pas migré à l'aide de l'option 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 mappages 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 effectuez à nouveau la migration de l'entrée.

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

Cause :  un mappage contient des clés avec des majuscules et des minuscules. HP-UX convertit toutes les clés en minuscules avant d'envoyer la demande NIS. Il s'agit d'un problème lié à 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 du service 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 à partir d'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 Modifier la fréquence des mises à jour de mappage sur des serveurs NIS subordonnés (esclaves) UNIX 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 (esclaves)), 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é à partir d'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 client Solaris

  • Vérifiez que le serveur 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 le serveur 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'indique 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 client Linux

  • Vérifiez que le serveur Windows qui exécute le 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 qui figure dans /etc/sysconfig/authconfig possède la valeur USENIS=yes.
  • Vérifiez que le fichier nsswitch.conf est correctement configuré.
Contenu de la communauté   Qu'est-ce que le Contenu de la communauté ?
Ajouter du contenu RSS  Annotations
Processing
© 2009 Microsoft Corporation. Tous droits réservés. Conditions d'utilisation  |  Marques  |  Confidentialité
Page view tracker