Windows Serveur 2008 erreur NETLOGON et KERBEROS - Réseaux - Systèmes & Réseaux Pro
Marsh Posté le 26-10-2008 à 14:26:46
Bonjour,
je ne sais pas ce qu'est le SID, je débute dans l'installation de serveurs et je galère un peu... Comme tu vois
Marsh Posté le 26-10-2008 à 14:33:17
Merci mais peux-tu plus détailler ta réponse ? Je dois changer le SID sur quel pc ?
edit : apparemment on ne peut pas le changer sur un controleur de domaine, je suppose donc qu'il s'agit du poste client... Je suis en train de la changer avec l'outil NewSID (est-ce la bonne méthode?) c'est en cours je teste dans quelques minutes.
Marsh Posté le 26-10-2008 à 16:26:07
Bonjour,
après 2 heures de recherche je n'ai pas trouvé d'outil capable de changer le SID sur Vista x64. Ça se termine systématiquement par un plantage, même en le lançant en tant qu'admin.
Help me !
Marsh Posté le 27-10-2008 à 12:26:04
Bonjour,
existe t-il un moyen de désactiver cette sécurité ? Je restaure très souvent et je n'ai pas vraiment le temps de perdre des heures à chaque fois alors que je me fiche totalement de cette option; ce n'est pas le serveur qui s'occupe de la sécurité dans l'entreprise.
J'ai vu également que la commande netdom ou nltest permettait de désactiver ou réinitialiser le canal de sécurité mais je n'ai pas réussi à trouver la bonne syntaxe. Pour l'instant j'ai testé ça :
nltest /SC_RESET:domaine.fr \ORDI --> ne marche pas, mauvaise syntaxe
netdom join ORDI /Domain:domaine.fr --> accès refusé
Netdom join ORDI /Domain:domaine.fr /UserD:Administrateur /PasswordD:Password /UserO:User /PasswordO:Password --> Cet ordinateur est déjà lié à un domaine.
Netdom remove ORDI /Domain:domaine.fr /UserD:Administrateur /PasswordD:Password /UserO:User /PasswordO:Password --> Le mappage entre les noms de compte et les ID de sécurité n'a pas été effectué.
Netdom reset ORDI /Domain:domaine.fr /Server:serveur@domaine.fr /UserO:User /PasswordO:Password
--> La relation d'approbation entre cette station de travail et le domaine principal a echoué.
Je ne sais plus quoi tester... Merci à ceux qui connaissent le problème de m'aider, je désespère un peu là. J'aimerais avancer dans mon travail et je ne peux continuer à cause d'un détail pour certains qui m'occupe depuis de (très) longues heures.
Marsh Posté le 27-10-2008 à 12:44:49
Bonjour,
j'ai déjà fais quelques heures de recherches hier sur sysrep et n'ai rien trouvé d'intéressant concernant mon problème. Je veux garder ma façon de faire des ghosts et non utiliser l'outil de déploiement de Microsoft. J'aurais préféré un coup de main avec nltest et netdom...
Marsh Posté le 27-10-2008 à 12:52:08
Ca n'a surtout rien à voir.
Toi tu fais des ghosts d'une machine particulière et tu t'étonnes que toutes tes machines clonnées soient identique. Le SID machine y compris (et tout un tas d'autres param).
Avant de ghoster il faut rendre ta machine générique et faire ton clone. Après tes machines clonées vont se spécialiser.
C'est LA méthode parce que c'est comme ça que ça doit être fait et c'est ce que tout le monde utilise.
Netdom va te rajouter ta machine au domaine mais en utilisant son SID, c'est exactement pareil que si tu passes par l'interface.
Sysrep n'est pas un outil de déploiement en plus, ta pas du aller chercher très loin.
donc soit tu fais tes ghosts bien, soit tu restes avec tes pb.
Marsh Posté le 27-10-2008 à 12:54:03
Bonjour,
je ne comprends pas. Toutes les machines sont différentes, pourquoi le SID serait-il cloné, alors qu'il est forcément différent à la base ?
edit: je voudrais quand même essayer ce soft mais je n'arrive à trouver la version x64... Tu aurais un lien ?
Marsh Posté le 27-10-2008 à 12:56:32
Ben parce qu'elles le sont ! Ce sont tous des pc différents, avec du matos différent, des programmes différents, des OS différents ! Chaque ghost correspond à un seul et unique pc.
Marsh Posté le 27-10-2008 à 12:59:38
Ahhhhhhhhhhhhhhhhhhhhhhhhhhhh, fallait l'expliciter.
C'est un peu barbare ton truc
Si tu ghost une machine déjà dans un domaine, c'est normal qu'il faille la disjoindre/rejoindre. Le compte machine a son mdp qui est changé régulièrement et du coup bah elles sont plus sync.
Marsh Posté le 27-10-2008 à 13:01:39
et on retombe sur mon problème de base ! Car la session est nouvelle et il faut tout recommencer ! La boucle est bouclée
En quoi mon système est-il barbare ? Je trouve que les ghosts des systèmes sont parmi les meilleures inventions de softs.
Marsh Posté le 27-10-2008 à 13:34:04
up ! je ne vais tout de même pas créer à chaque restauration une nouvelle session !?!
Marsh Posté le 27-10-2008 à 23:15:20
up je suis sur que je ne suis pas le seul à ghoster des pcs dans un domaine !!!
Marsh Posté le 30-10-2008 à 10:36:38
Allez essaie ça :
nltest /server:LENOMDETAMACHINE /sc_reset:LENOMDETONDOMAINE\LENOMDETONDC
Cependant si le netdom marche pas, lui a peu de chance de marcher non plus
Marsh Posté le 30-10-2008 à 23:24:34
Bonsoir,
j'avais hélas déjà testé cette commande, qui me retourne l'erreur : I_NetLogonControl a échoué : Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN (quel que soit les informations rentrées)
J'ai eu l'occasion de parler à quelques pros de ce problème, et tous m'ont conseillé la même chose : créer des profils itinérants stockés sur le serveur. Ainsi, lorsqu'après une restauration je dois me délogger et me logguer à nouveau sur le domaine, les informations de profil utilisateur ne changent pas et je n'ai pas à recréer de session.
Il semble qu'il n'est pas possible de faire autrement. Merci de ton aide.
Marsh Posté le 26-10-2008 à 14:16:41
Bonjour,
j'ai un problème sur l'un de mes postes client après une restauration système. Celui-ci se connecte correctement au domaine et a toujours accès aux ressources partagées du serveur, mais c'est tout. Le serveur ne peut pas s'y connecter ni aucun autre ordinateur du domaine. L'erreur est la suivante :
"Échec de l'authentification de la configuration de session de l'ordinateur ORDI. Le nom du compte référencé dans la base de données de la sécurité est ORDI$. L'erreur suivante s'est produite :
Accès refusé."
et
"Le client Kerberos a reçu une erreur KRB_AP_ERR_MODIFIED du serveur ordi$. Le nom cible utilisé était cifs/ordi. Cela indique que le serveur cible n'a pas réussi à déchiffrer le ticket fourni par le client. Cela risque de se produire lorsque le nom principal du serveur (SPN) cible est inscrit sur un compte différent de celui utilisé par le service cible. Veuillez vous assurer que le SPN est inscrit sur, et uniquement sur, le compte utilisé par le serveur. Cette erreur peut aussi se produire lorsque le service cible utilise un mot de passe pour le compte du service cible qui diffère par rapport à celui que possède le centre de distribution de clés Kerberos pour le compte du service cible. Veuillez vous assurer que le service sur le serveur et le centre de distribution de clés Kerberos sont tous deux mis à jour pour utiliser le mot de passe actuel. Si le nom de serveur n'est pas pleinement qualifié, et que le domaine cible (ordi.fr) diffère du domaine client (ordi.fr), vérifiez s'il existe des comptes de serveur de même nom dans ces deux domaines, ou utilisez le nom pleinement qualifié pour identifier le serveur."
Après quelques recherches sur le net j'ai vu que cela pouvait être dû à un nom en double sur le réseau, ce n'est pas mon cas. Le fait de déconnecter et reconnecter le poste au domaine résout le problème mais le pc client crée une toute nouvelle session en perdant donc tous les paramètres précédents. Vu le temps pour créer ce type de session (il y a énormément de réglage) c'est impensable pour moi de tout réinstaller à chaque restauration - qui du même coup perdrait fortement de l'intérêt...
Ma question est donc la suivante : comment réinitialiser le compte, ou changer simplement le nom référencé en enlevant le $ ? Ou une toute autre méthode ? Un peu d'aide me serait des plus précieuses car je fais très régulièrement des restaurations systèmes pour différentes raisons et ne peut pas m'en passer.
Merci d'avance à toutes et à tous !
Message édité par ramkiller le 26-10-2008 à 14:16:57
---------------
Mon feedback