Pourquoi Mac OSX Lion perd-il ses identifiants de connexion / réseau?


13

Symptômes

Au travail, nous avons installé OSX 10.7.3 et de temps en temps je verrai les comportements suivants:

  1. Si l'écran est verrouillé, plusieurs tentatives du même utilisateur / passe ne sont pas acceptées.

  2. Si l'écran est déverrouillé, l'ouverture d'un nouveau terme bash peut générer des invites telles que:

    `I have no name$`
    

    ou

    lkyrala$ ssh lkyrala@ah-lkyrala2u 
    You don't exist, go away!
    

Même lorsque nos Mac fonctionnent normalement, tout le monde ici doit se connecter deux fois. La première fois après le démarrage échoue toujours , mais la deuxième fois (avec le même mot de passe, sans rien changer, en appuyant à nouveau sur Entrée) réussit. Bizarre?

Solutions de contournement

Il existe des solutions de contournement qui résolvent le problème immédiat, mais ne l'empêchent pas de se reproduire:

  1. attendez (peut-être une heure ou deux) et les problèmes disparaissent parfois d'eux-mêmes.

  2. tuez 'opendirectoryd' et laissez-le redémarrer. (dans les communautés d'assistance Apple: l'ID utilisateur (et non les données) a été supprimé soudainement? )

  3. maintenez le bouton d'alimentation pour réinitialiser l'ordinateur

MISE À JOUR 10/04/2012

Nos administrateurs réseau soupçonnent que lockd est impliqué. lockd utilise apparemment UDP et lorsque le réseau est encombré, les paquets sont perdus, ce qui entraîne le blocage. Ils envisagent des mesures pour réduire la congestion. Si l'accès au fichier en question se trouve être le handle d'authentification Active Directory, alors toutes ces différentes pièces commencent à s'emboîter.

Discussion

Maintenant, les preuves ci-dessus m'indiquent quelque chose de délirant avec le répertoire ouvert et les informations de connexion. D'autres personnes signalent avoir ces problèmes de connexion, mais il est difficile de déterminer où se situe le problème réel (Mac ou environnement réseau?).

Je dois ajouter que la plupart du réseau sont des machines Windows, mais nous avons également quelques machines Mac et Linux, mais je ne suis pas sûr des détails de la façon dont l'authentification réseau est mappée de divers domaines à d'autres ... tous Je sais que nos informations d'identification réseau fonctionnent dans les domaines Windows ainsi que dans les connexions Mac et Linux - donc quelque chose connecte des systèmes distincts ou utilise le même système d'authentification global.

Détails supplémentaires

Malheureusement, je n'ai pas configuré ce Mac, notre département informatique l'a fait, donc je ne suis pas entièrement sûr du fonctionnement de l'authentification. Je sais que c'est une connexion réseau (ce qui est inhabituel dans mon expérience avec les Mac, ils ont généralement des comptes locaux qui se connectent à des ressources externes) mais ici, notre dossier personnel est sur le réseau, pas local. Sous mes installations Linux, la connexion au réseau implique yp / NIS, (ce qui nous permet de monter automatiquement des parties de notre système de fichiers réseau depuis n'importe quelle machine), et le opendirectoryd.log semble confirmer que cela est impliqué ...

/var/log/opendirectoryd.log* spectacles:

2012-04-04 01:29:12.370 EDT - ddddd.dddddd.dddddd.dddddd - Client: automount, UID: 0, EUID: 0, GID: 0, EGID: 0
2012-04-04 01:29:12.370 EDT - ddddd.dddddd.dddddd.dddddd, Node: /NIS/Domain, Module: nis - could not determine map for rectype 'mounts' attribute 'byname'
2012-04-04 01:32:04.504 EDT - failed to get YP map list

Il semble que le domaine «Domain» soit en quelque sorte perdu. Pourquoi l'UID == 0 est-il ici? Cela semble mauvais, non?

Je sais que sous Linux il y a quelque temps, j'ai découvert que la diffusion NIS avait été désactivée ou bloquée, j'ai donc rassemblé les adresses IP de quelqu'un et défini manuellement les adresses IP ypserver /etc/yp.confet corrigé les baisses dans Linux. Peut-être que quelque chose de similaire se passe ici?

J'ai essayé de rechercher des informations dans les pages de manuel yp de Mac:

Et puis trouvé ce post détaillant où les serveurs existants sont définis:

Cependant, la vérification des paramètres ypserver a montré que les deux IP de serveur étaient correctement définies pour NIS.

Vérification /var/log/system.logmontre:

Aug 28 00:30:08 mymac ypbind[22991]: direct: sendto: No route to host
Aug 28 00:30:08 mymac ypbind[22991]: direct: sendto: No route to host
Aug 28 00:30:08 mymac ypbind[22991]: Can't contact any servers listed in /var/yp/binding/Domain.ypservers.  Aborting
Aug 28 00:30:08 mymac com.apple.launchd[1] (com.apple.nis.ypbind[22991]): Exited with code: 1
Aug 28 00:30:08 mymac com.apple.launchd[1] (com.apple.nis.ypbind): Throttling respawn: Will start in 10 seconds
Aug 28 00:30:08 mymac xpchelper[22990]: getpwuid_r() failed for UID: uuuu, ret: 0, errno: 0

Cela me fait donc soupçonner les paramètres nfs.conf, etc. Certains pensent que cela est dû à quelque chose dans lockd.

Recherche

Rapports de problèmes similaires


Veuillez nous en dire plus sur votre environnement (vous semblez utiliser OpenDirectory (?) Joint à un domaine Windows (?) - comment l'avez-vous configuré? L'ordinateur disparaît-il du domaine? Perd-il la connectivité réseau? Etc. ), vérifiez également les journaux de votre système - ils ont souvent des informations sur des problèmes comme celui-ci ...
voretaq7

J'ai ajouté la section "Détails supplémentaires" ci-dessus qui en dit plus sur opendirectoryd.log et l'environnement environnant tel que je le connais. Le problème est que je n'en ai pas installé beaucoup, et je n'ai pas de crédits d'administrateur réseau. J'essaie de faire des recherches pour aider nos gars, car nous nous attaquons à ce problème depuis des mois, mais nous ne l'avons jamais vraiment trouvé.
Larry Kyrala

Avez-vous une mise à jour à ce sujet, j'essaie de faire fonctionner NIS / NFS sur OS X 10.7 tandis que sur Ubuntu fonctionne très bien. Je reçois le même message que toi.
Sorin

Toujours pas de mise à jour, désolé. N'importe qui?
Larry Kyrala

1
Cela ressemble à un problème que nous avons eu ici à l'école. Les macs perdraient aléatoirement la connectivité réseau au contrôleur de domaine, ce qui empêcherait les utilisateurs de se connecter. Autant que je sache, cela a été causé après une mise à jour logicielle sur le serveur Mac. Il semblait que les MAC étaient trop anciens pour gérer les nouvelles mises à jour du serveur. Jusqu'à ce que les nouveaux MAC soient achetés, ils devraient être rejoints au DC même si le MAC dans les paramètres était toujours lié.
Jake Andrew

Réponses:


1

Avez-vous lié le mac à un serveur OSX ou à Active Directory? Si ce dernier vérifie si le domaine se termine par .local. Si c'est le cas, il existe des problèmes connus d'interférence de multidiffusion sur OSX. Le processus ici peut fonctionner pour vous: http://www.macwindows.com/TIP-Lion-dot-local-AD-disable-multicast.html

Certains Mac ne sont tout simplement pas satisfaits d'un réseau AD. J'ai eu plusieurs iMac avec des spécifications essentiellement identiques et la plupart étaient bien, mais 2 ont continué à perdre la connectivité avec le contrôleur de domaine et avaient des problèmes constants liés aux tickets Kerberos. Dans ce cas, la rupture du mac du domaine puis sa reconnexion à l'aide de Centrify Express ont résolu le problème. Vous pouvez trouver l'agent sur leur site Web ici: http://www.centrify.com/express/free-active-directory-tools-for-linux-mac.asp#agents


Je crois qu'il est lié à AD, et le domaine ne se termine pas par .local. En regardant les détails maintenant ... (merci pour l'info!)
Larry Kyrala

Puisque notre AD ne se termine pas par .local, je pense que le premier lien ne s'applique pas. Le deuxième lien est quelque chose que les administrateurs réseau doivent faire. De plus, j'ai mis à jour le message avec quelque chose que les administrateurs réseau ont découvert il y a quelques semaines: les paquets UDP verrouillés sont perdus lorsque le réseau devient soudainement congestionné. Je ne suis pas sûr, mais des sons comme celui-ci affecteraient une gamme de choses sur Mac, surtout si la connexion AD était l'une des poignées affectées.
Larry Kyrala
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.