4 votes

Échec de la vérification de la confiance dans le canal sécurisé

Je travaille sur un problème de mise en place d'une confiance entre deux domaines avec plusieurs pare-feu entre eux, et un routage en trou d'épingle entre deux serveurs dans ces domaines.

newdc.newdomain.com est un serveur 2012 dans un tout nouveau domaine. admt.olddomain.local est un serveur 2008R2 dans un domaine existant, avec deux contrôleurs de domaine existants dc1.olddomain.local et dc2.olddomain.local Ce serveur sera utilisé pour, comme vous l'avez peut-être deviné, Active Directory Migration Tool (ADMT)

Des règles de pare-feu sont en place pour permettre à newdc.newdomain.com de parler Active Directory uniquement à admt.olddomain.local dans les deux sens. Tous les tests DNS sont bons, ainsi que les DCDIAG des deux côtés.

Lors de la création de la confiance sur admt.olddomain.local j'ai obtenu l'erreur suivante

La confiance entrante a été vérifiée. Il est en place et actif. La vérification de la confiance sortante a échoué avec la ou les erreurs suivantes : Le test de vérification du mot de passe du trust n'a pas été concluant. Une réinitialisation du canal sécurisé va être tentée. La réinitialisation du canal sécurisé a échoué avec l'erreur 1311 : Il n'y a actuellement aucun serveur de connexion disponible pour répondre à la demande de connexion.

Les trusts ont cependant été créés, entrants et sortants, dans les deux domaines. La validation de la confiance (dans les deux sens) sur newdc.newdomain.com revient comme vérifiée avec succès. Cependant, lorsque je tente de valider le trust à partir du serveur admt.olddomain.local, j'obtiens l'erreur suivante :

La réinitialisation du canal sécurisé (SC) sur le contrôleur de domaine Active Directory \dc1.olddomain.local du domaine olddomain.local au domaine newdomain.com a échoué avec une erreur : Il n'y a actuellement aucun serveur de connexion disponible pour répondre à la demande de connexion.

La confiance entrante a été validée avec succès.

Je peux voir le problème ici, même si j'effectue la validation depuis admt.olddomain.local, il tente en fait de vérifier le canal sécurisé depuis dc1.olddomain.local qui ne peut pas communiquer avec le serveur newdc.newdomain.com, mais est-ce vraiment un problème ? Existe-t-il un moyen de forcer la validation à avoir lieu depuis admt.olddomain.local ? Pourrons-nous utiliser ADMT avec cette configuration ? (Nous allons bientôt essayer une copie de test en l'utilisant, juste pour voir ce qui se passe dans la configuration actuelle).

Finalement, nous allons reconstruire ce serveur admt.olddomain.local en contrôleur de domaine en lecture seule pour newdomain.com en utilisant la même adresse réseau et la même configuration de pare-feu/routage réseau, et il sera la seule machine capable de communiquer avec dc01.olddomain.local et dc02.olddomain.local, mais aurons-nous le même problème puisque newdc.newdomain.com ne peut pas router directement vers l'un ou l'autre de dc01/dc02 pour vérifier la confiance ?

Merci pour toute contribution à ce sujet !

0voto

harper Points 5962

OK, voici donc ce que nous avons fini par faire, reconstruire la structure AD afin que le nouveau domaine.com ait un serveur ADMT/DC sur le même réseau que les serveurs AD de l'ancien domaine.com, puis transférer les rôles FSMO vers le nouveau serveur de domaine afin que les deux domaines puissent communiquer directement entre les maîtres FSMO sans que tous les pare-feu intermédiaires ne viennent perturber les choses. Si vous avez tout réglé pour le DNS, les pare-feu, etc., et que vous obtenez toujours des erreurs, commencez à regarder si les maîtres de rôle FSMO peuvent se parler directement !

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X