none
Relation d'approbation, redirection DNS, et plus rien ne va RRS feed

  • Discussion générale

  • Bonjour à tous,

    Je suis face à une difficulté que je n'arrive pas à résoudre. Je travaille dans une grosse collectivité qui fourni la solution de téléphonie à une antenne, autonome dans son SI pour le reste.

    Le caller nécessite une relation d'approbation entre nos domaines pour que leurs postes accèdent à nos partages.

    C'est là que ça coince, leur domaine interne xxxxx.fr a le même nom que la zone publique xxxxx.fr qui héberge leur site internet. Et là quand nous essayons d'aller sur leur site internet, la résolution DNS nous fait pointer sur leur DC...

    Voilà je tourne en rond avec ça et je suis dans l'incapacité de trouver une solution. S'ils suppriment les entrées A "identique au dossier parent" des DC pour laisser celle vers le site externe (en mode split DNS), elelles reviennent automatiquement, si je supprime le redirecteur conditionnel, la relation ne fonctionne plus, si je désactive le routage des suffixes de noms ça semble ne rien changer... Je ne sais plus quoi faire.

    Je sais qu'ils ne devraient pas avoir un nom de domaine AD identique à l'externe mais on ne peut plus le changer à ce stade.

    Merci par avance si vous avez des suggestions, des idées, je suis plus que preneur !

    Bonne journée

    mardi 9 juillet 2019 10:57

Toutes les réponses

  • Au lieu de faire de la redirection conditionnelle, met en place une zone de stub dans tes dns Ad vers leur DNS AD.

    Dans une zone de stub, tu ne récupère que la liste des serveurs DNS du distant. Eux doivent avoir géreé la zone DNS intranet correctement.

    Par contre, il faut que le serveur DNS distant auprès duquel tu va récupérer les informations t'autorise dans la partie transfert de zone.

    mardi 9 juillet 2019 12:08
  • C'est là que ça coince, leur domaine interne xxxxx.fr a le même nom que la zone publique xxxxx.fr qui héberge leur site internet. Et là quand nous essayons d'aller sur leur site internet, la résolution DNS nous fait pointer sur leur DC...

    Quelle enregistrement tu utilises en externe www ? Si tu crée les enregistrements dans la zone interne nécessaire au services externes ?Les postes auraient peut-être les deux ? Les serveurs Web public sont chez un fournisseur ou en local ?

    Le concept même de la résolution de nom DNS veut qu'il n'existe qu'une zone faisant autorité pour un nom de domaine, sinon il y a conflit. 

    De la manière dont tu poses ta question "je ne peux respecter les prérequis indispensable à mon approbation mais il me faut tout de même l'approbation". Une prérequis est requis par définition. Ton approbation entre domaine ne fonctionnera que s'il est respecté.

    Sinon une zone de stub c'est un redirecteur conditionnel "dynamique", vu qu'il récupère la lsite des serveurs de noms de la zone. Cela facilite la migration si les serveurs change, mais en terme de résolution c'est identique au redirecteur conditionnel.

    Voilà je tourne en rond avec ça et je suis dans l'incapacité de trouver une solution. S'ils suppriment les entrées A "identique au dossier parent" des DC

    On ne supprime pas les entrées DNS des contrôleurs de domaine sur les zones utilises à l'AD. AD ne fonctionne pas sans DNS, de plus certain services recrée automatiquement les enregistrement nécessaires.

    mardi 9 juillet 2019 13:16
    Modérateur
  • Il suffit de créer l'enregistrement d'adresse sur leur DNS intranet avec l'adresse IP publique du serveur web.

    Ceci étant, avec redirecteur ou zone de stub, s'ils n'ont pas indiqués les enregistrements d'adresse publiques sur leur zone intranet, ça signifie qu'eux même ne peuvent pas joindre leur site web public ?

    Ca parait étonnant de la part d'un administrateur système d'avoir laisser les utilisateurs sans accès.

    mardi 9 juillet 2019 13:35
  • bonjour,

    pour moi la solution c'est d'ajouter les enregistrements externe manuellement sur votre serveur DNS, ensuite si vous avez un site intranet qui possède le même nom que le site externe vous devez mentionner le distinguer avec www. j'ai le m^me cas de figure et j'ai pu le corriger avec cette méthode.

    Bonne journée

    mardi 9 juillet 2019 13:42
  • Bonjour et merci pour ces suggestions.

    Chez eux, ils utilisent un proxy, et je pense que c'est le proxy qui résout chez les DNS du FAI, ou alors les adresses des DNS qu'ils distribuent par DHCP sur les postes ne sont pas leurs DC, je ne veux même pas savoir !

    Par ailleurs le site n'est pas accessible en WWW.* mais directement par son nom racine sans préfixe (virtualhost sans doute). Le plus drôle là dedans c'est qu'en rajoutant l'ip public en interne, on a un round-robin entre leurs 2 DC et le site, c'est pire que tout...

    Je me tourne maintenant vers un concept que je maîtrise moins, les SPN. Je pense que de ce coté je peux résoudre ma problématique en redirigeant les services HTTP (incl https) vers une ip externe. Qu'en pensez-vous ?

    Merci par avance

    EDIT : j'avais pensé éventuellement à rediriger ces ports (80 + 443) dans le pare-feu Windows (PAT) mais on arrive déjà dans un bricolage qui me déplaît fortement, et ensuite ils ont eu la bonne idée d'installer un autre serveur web interne sur un des DC... (sinon c'est trop simple)
    • Modifié Supaxor vendredi 12 juillet 2019 10:10
    vendredi 12 juillet 2019 10:05
  • ils utilisent un proxy, et je pense que c'est le proxy qui résout chez les DNS du FAI, ou alors les adresses des DNS qu'ils distribuent par DHCP sur les postes ne sont pas leurs DC, je ne veux même pas savoir !

    Le proxy est un service qui va envoyer les requètes WEB (en général) des postes clients à leur place. Le proxy a donc besoin des résoudre les nom sur internet. Pour les postes clients, serveur du domaine et DC, ils est indispensable de résoudre les nom internes, mais n'ont pas forcément besoin de résoudre les noms sur internet s'ils passent par le proxy.

    Le proxy peut avoir plusieurs rôles, la mise en cache des résultats et l'amélioration de la consommation de la bande passante. Il peut également avoir un rôle de contrôle, par rapport au site de destination, aux utilisateurs qui envoient une demande de page internet voir les deux. 

    Le proxy est un service au niveau application, il faut donc configurer le client (navigateur en général) pour relayer ces demandes vers le proxy. Les postes clients ont donc seulement besoin de résoudre les noms internes et éventuellement un nom interne qui désigne le proxy.

    Le proxy doit utiliser des serveurs DNS externes afin d'assurer la résolution de nom internet, il est possible si nécessaire de lui rajouter manuellement quelques nom utiles (mais il n'en a pas forcément besoin).

    Avec l'aide du proxy il devrait être possible de faire cohabiter, cette configuration DNS qui n'est pas très optimale.

    Le plus drôle là dedans c'est qu'en rajoutant l'ip public en interne, on a un round-robin entre leurs 2 DC et le site, c'est pire que tout...

    Un peu étrange comme idée ... qui n'est vraiment pas judicieuse. Dans le domaine les DCs, postes membres doivent avoir une résolution correct, c'est indispensable, pas d'AD sans résolution DNS propre. 

    Je me tourne maintenant vers un concept que je maîtrise moins, les SPN.

    Ils ne faut pas confondre SPN, port TCP  ...

    Quuelques notions sur les SPN et leur utilité dans l'authentification :

    http://www.pbarth.fr/node/336

    vendredi 12 juillet 2019 11:37
    Modérateur
  • Ce que j'explique depuis le début c'est que leur domaine n'est pas bien géré. S'il y a dysfonctionnement chez eux c'est leur souci mais cela nous impacte et c'est bien là qu'est tout le problème.

    Concernant le SPN j'ai simplement vu une association service/host mais je reconnais en ignorer totalement le rôle. Après lecture de l'article, je suis effectivement à coté de la plaque...

    Donc si je comprends bien on revient à la case départ et il n'y a aucune solution ?

    J'ai bien pensé à pousser des lignes dans les fichiers hosts de tous nos postes, mais éthiquement parlant je m'y refuse.


    • Modifié Supaxor vendredi 12 juillet 2019 13:21
    vendredi 12 juillet 2019 13:13
  • Je refais :

    Le proxy doit utiliser des serveurs DNS externes afin d'assurer la résolution de nom internet, les clients qui utilisent le proxy n'ont pas besoin de résoudre les noms sur internet. Le ping sur www.google.fr ne marchera pas depuis un post client et pour autant la navigation devrait fonctionné grâce au proxy.

    L'ensemble des postes et serveurs dans le domaine utilise les DNS interne pour le bon fonctionnement de l'AD.

    Ce n'est pas joli, mais  je l'ai déjà fait faute de mieux et ça a marché.

    vendredi 12 juillet 2019 13:58
    Modérateur
  • Il y a un proxy dans leur domaine, d'où le fait qu'ils n'aient jamais perçu le moindre problème.

    En l’occurrence chez nous il n'y en a pas, nous avons une brique Checkpoint qui assure le filtrage de contenu web. La résolution DNS pour la navigation est donc traitée par nos DNS (DC), et est redirigée vers les DNS du FAI en redirecteurs principaux, ou vers le DNS interne de cette autre entité pour ce nom de domaine précis à cause de la relation d'approbation.

    (Au passage, pas mal ton site !)


    • Modifié Supaxor vendredi 12 juillet 2019 14:28
    vendredi 12 juillet 2019 14:27