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 .
la source
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)?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.Réponses:
Si les clients résolvent correctement le nom d'hôte, vous avez un autre problème. DNS est hors de portée une fois le nom d'hôte résolu par le client.
Quelques réflexions:
Les clients utilisent-ils une sorte de proxy HTTP pour accéder à Internet? Le proxy dispose-t-il des informations DNS correctes?
À quoi ressemble le cache DNS sur le client après une tentative d'accès infructueuse? Voyez-vous la bonne adresse IP mise en cache pour le nom d'hôte?
Que se passe-t-il réellement sur le client? Voyez-vous une connexion bloquée dans l'état SYN_SENT à la bonne adresse IP du serveur, le port TCP 80?
Existe-t-il des règles de pare-feu susceptibles de bloquer l'accès à l'adresse du site Web?
Cela sent comme un problème de pare-feu / proxy / cache / filtre, pas un problème DNS.
Malheureusement, je ne peux rien dire de vraiment convaincant de se débarrasser du domaine Active Directory mal nommé. Il est regrettable qu'ils aient choisi de suivre cette voie, mais techniquement, cela peut fonctionner. (Je déteste ce genre de mauvaise pratique de dénomination aussi ... "vil", je crois, c'est comme je l'ai mentionné dans le passé ... J'aimerais avoir de bons conseils pour vous transmettre un argument de changement de nom de domaine ...)
la source
If the clients are resolving the hostname properly then you've got another problem.Bon sang. Si tel est le cas, il s'agit probablement de notre proxy Web astucieux. J'étais beaucoup plus heureux quand je pensais que cela ne pouvait pas être résolu techniquement, et ils devraient enfin réparer leur gâchis $ # @ ^% ing déjà. :(wwwrecord A ne fonctionne pas, l'administrateur système est énervé et aggrave sa cirrhose.