En relation avec ma précédente question, pourquoi est-ce une mauvaise idée d'utiliser le nom de domaine racine comme nom de votre forêt Active Directory ...
J'ai un employeur, que j'appellerai ITcluelessinc, pour des raisons de simplicité (et d'honnêteté). Cet employeur possède un site Web hébergé en externe, www.ITcluelessinc.com , et quelques domaines Active Directory. N'ayant aucune idée de l'informatique, il y a de nombreuses années, ils se sont installés sur une forêt Active Directory nommée ITcluelessinc.prvet ont commis des atrocités indescriptibles contre elle. Ces atrocités indicibles ont fini par les rattraper, et avec tout ce qui s'est effondré autour d'eux, ils ont décidé de payer à quelqu'un une énorme somme d'argent pour «le réparer», ce qui comprenait la migration hors de la ITcluelessinc.prvforêt horriblement brisée .
Et bien sûr, n'ayant aucune idée de l'informatique, ils ne connaissaient pas les bons conseils quand ils l'ont entendu, ont accepté la recommandation de nommer leur nouvelle forêt AD ITcluelessinc.com, au lieu des conseils sensés qu'ils ont également reçus, et ont commencé à mettre des choses dessus. Il y a quelques heures, nous avons une entreprise avec la plupart de ses éléments joints à et utilisant l'ancienne ITcluelessinc.prvforêt Active Directory, avec une bonne quantité de nouveaux éléments joints et / ou utilisant la ITcluelessinc.comforêt. Pour que cela fonctionne ensemble de manière relativement transparente, j'ai utilisé des redirecteurs conditionnels dans DNS pour envoyer le ITcluelessinc.comtrafic vers ITcluelessinc.prvet vice versa.
(Les domaines corp.ITcluelessinc.comet eval.ITcluelessinc.comsont des domaines correctement nommés que je suis arrivé et que j'ai configurés plus tard et qui ne sont pas encore pertinents.)
Il y a quelques heures, une employée non technique d'ITcluelessinc a remarqué qu'elle ne pouvait pas accéder à www.ITcluelessinc.com depuis son poste de travail (à l'intérieur du réseau d'entreprise d'ITcluelessinc) et a décidé que c'était un problème, alors elle contacte Employé VIP d'ITcluelessinc, qui décide que cela doit être résolu le plus Ricky-tick. En règle générale, ce n'est pas énorme, ajoutez un enregistrement A wwwsous la zone DNS pour ITcluelessinc.com, et vous pouvez parcourir le site, tant que vous n'essayez pas le lien nu.
Il semble donc que tout est correctement configuré. Les redirecteurs, l' wwwentrée d'hôte dans DNS et, pourtant, les clients utilisant le ITcluelessinc.prvcontrôleur de domaine comme serveurs DNS obtiennent un délai de connexion lorsqu'ils essaient de naviguer sur www.ITcluelessinc.com , au lieu de la page Web que j'obtiens de mon réseau domestique.
Quelqu'un a-t-il une idée de la façon dont je peux autoriser les clients internes du ITcluelessinc.prvdomaine à parcourir www.ITcluelessinc.com , compte tenu de la présence de la ITcluelessinc.comforêt Active Directory et des redirecteurs conditionnels dont elle a besoin? Ou, à l'inverse, quelqu'un [d'autre] est-il convaincu que la seule façon de le faire fonctionner est de se débarrasser de la ITcluelessinc.comforêt Active Directory?
Il semble que la configuration que j'ai maintenant devrait fonctionner, mais ce n'est clairement pas le cas, et je ne sais pas où je pourrais me procurer un environnement de test avec lequel je me suis retrouvé à expérimenter. Et pour ce que ça vaut, j'ai quelque peu poliment suggéré que la seule façon de résoudre ce problème est de migrer vers les forêts correctement nommées que j'ai configurées, et quand ce n'est pas une bonne réponse, prévoyez d'héberger un miroir du site Web sur tous nos ITcluelessinc.comcontrôleurs de domaine jusqu'à ce que tout casse .
NSenregistrements. À condition que le pare-feu permette la communication des contrôleurs de domaine au serveur DNS externe, cela atténue quelque peu le cauchemar et les enregistrements publics peuvent être gérés sur le serveur public.
wwwnom, ou obtiennent-ils une adresse incorrecte? Ou bien, obtiennent-ils la bonne adresse mais ne peuvent-ils pas se connecter à cette adresse (le site Web est-il hébergé sur des serveurs à l'intérieur du réseau, provoquant un problème NAT en épingle à cheveux)?