Domaine AD et contrôleur de domaine accessible en local et internet
Résolu/Fermé
Fuxill
Messages postés
88
Date d'inscription
vendredi 20 juillet 2018
Statut
Membre
Dernière intervention
30 août 2022
-
6 nov. 2021 à 17:26
Fuxill Messages postés 88 Date d'inscription vendredi 20 juillet 2018 Statut Membre Dernière intervention 30 août 2022 - 8 nov. 2021 à 00:22
Fuxill Messages postés 88 Date d'inscription vendredi 20 juillet 2018 Statut Membre Dernière intervention 30 août 2022 - 8 nov. 2021 à 00:22
A voir également:
- Domaine AD et contrôleur de domaine accessible en local et internet
- Appdata local - Guide
- Gps sans internet - Guide
- Ip local - Guide
- Ad doubleclick net ✓ - Forum Téléphones & tablettes Android
- Youtube ad blocker - Guide
6 réponses
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
7 nov. 2021 à 18:06
7 nov. 2021 à 18:06
Bonjour,
Je suis navré mais je ne comprends pas du tout ce que tu souhaites faire.
Quel est le but recherché ou l'utilité ?
Plusieurs points qui me font tiquer :
- laisser un DC ouvert a tous mais cette installation qui sert de "test" et serait très pratique , rien de confidentiel ne sera stocké dans cette infrastructure
En fait il y a -pour moi- aucun intérêt à laisser AD ouvert sur le net. A quoi ça sert ?
Même s'il n'y a rien de confidentiel, c'est exposé, attaquable, et donc on peut rebondir grâce à cette foret sur le reste de l'infra en interne. On peut aussi y mettre des petites bricoles pour une utilisation "autre".
- Je sais qu'il faut rendre le serveur DNS AD public et l'associer au domaine publique
D'où sort cette affirmation ?
En fait il est vivement conseillé de nommer une foret AD avec un nom de domaine non routable (un nom de domaine non connu d'internet en gros). Ou à minima un sous domaine réservé/non déclaré publiquement d'un domaine routable -> corp.mondomaine.com par ex.
- sauf que mon registraire de NDD ne veut pas accepter l'ip publique de ma passerelle (0.0.0.0)
Pourquoi indiquer l'IP publique de la passerelle ? je ne comprends pas bien - surtout quel est le projet de mettre 0.0.0.0 - normal que ça ne passe pas.
- exemple.com:35 : à quoi correspond le port 35 ?
- DNS AD (requête avec le port ldap 35) ?
Je comprends pas trop le port LDAP 35 , et le mélanger à une requête DNS.
-
J'ai beaucoup de mal à comprendre le but recherché dans tout ça, le montage voulu, et l'utilité derrière.
Je suis navré mais je ne comprends pas du tout ce que tu souhaites faire.
Quel est le but recherché ou l'utilité ?
Plusieurs points qui me font tiquer :
- laisser un DC ouvert a tous mais cette installation qui sert de "test" et serait très pratique , rien de confidentiel ne sera stocké dans cette infrastructure
En fait il y a -pour moi- aucun intérêt à laisser AD ouvert sur le net. A quoi ça sert ?
Même s'il n'y a rien de confidentiel, c'est exposé, attaquable, et donc on peut rebondir grâce à cette foret sur le reste de l'infra en interne. On peut aussi y mettre des petites bricoles pour une utilisation "autre".
- Je sais qu'il faut rendre le serveur DNS AD public et l'associer au domaine publique
D'où sort cette affirmation ?
En fait il est vivement conseillé de nommer une foret AD avec un nom de domaine non routable (un nom de domaine non connu d'internet en gros). Ou à minima un sous domaine réservé/non déclaré publiquement d'un domaine routable -> corp.mondomaine.com par ex.
- sauf que mon registraire de NDD ne veut pas accepter l'ip publique de ma passerelle (0.0.0.0)
Pourquoi indiquer l'IP publique de la passerelle ? je ne comprends pas bien - surtout quel est le projet de mettre 0.0.0.0 - normal que ça ne passe pas.
- exemple.com:35 : à quoi correspond le port 35 ?
- DNS AD (requête avec le port ldap 35) ?
Je comprends pas trop le port LDAP 35 , et le mélanger à une requête DNS.
-
J'ai beaucoup de mal à comprendre le but recherché dans tout ça, le montage voulu, et l'utilité derrière.
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
7 nov. 2021 à 20:17
7 nov. 2021 à 20:17
Ce montage n'est tout simplement pas supporté, AD n'est pas fait pour fonctionner à travers Internet en fait, qui plus est derrière un NAT avec une IP publique.
Si c'est pour ouvrir une session avec profil itinérant sur Internet ... AD n'est pas fait pour couvrir cet usage.
Pour la partie network, il faudrait rediriger tous les ports AD de la box vers le DC.
C'est pas une mince affaire car il y en a énormément - colonne "server" dans le lien ci dessous.
https://docs.microsoft.com/fr-fr/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts
Cela va poser problème si ces ports sont utilisés en sortie par une autre connexion cliente (d'une autre machine que le DC) pour aller sur le net - ce qu'on appelle les ephemeral ports...
Lorsque la connexion sera sur le retour (en inbound pour la box) le flux sera redirigé vers le DC, et non vers le client initial.
Autre souci, le DC a une IP privée, et s'enregistre dans son propre DNS.
Même si on fait le montage DNS blablabla IP publique coté Registrar Internet ; le DNS du DC fournira toujours l'IP privée et non publique.
Donc pour un client sur Internet qui demanderait les infos de la foret avec DNS, il s'attend à avoir l'IP publique pour joindre le DC ; or il aurait une IP privée en réponse - non routable sur Internet.
A moins d'avoir plusieurs IP publiques et en dédier une pour le DC avec du NAT...le DC doit avoir cette IP publique dans sa conf réseau ; mais pas plusieurs IPs, ce n'est pas supporté. (cela s'appelle le multihoming).
Cela posera problème pour les clients AD sur le réseau privé d'ailleurs.
Je pourrai en citer probablement d'autres, mais les points ci dessus sont déja des NO GO.
-
Il est possible d'ouvrir une session Windows "AD", lorsque l'on est pas sur le réseau d'entreprise sans VPN. La machine est munie (par défaut) d'un cache de session ; cela sous entend d'avoir au préalable ouvert une session sur le réseau d'entreprise.
Avec tous les problème qui vont faire surface, la perte de la sécurité (et donc du besoin d'avoir un AD), la non "supportabilité" et la non pérennité, la complexité de configuration ; c'est plus simple de se pencher sur une solution autour d'un VPN; ça coutera moins cher à tous les points de vue, et surtout c'est supporté et ça fonctionne ;-)
Navré, mais il faut abandonner l'idée initiale.
Si c'est pour ouvrir une session avec profil itinérant sur Internet ... AD n'est pas fait pour couvrir cet usage.
Pour la partie network, il faudrait rediriger tous les ports AD de la box vers le DC.
C'est pas une mince affaire car il y en a énormément - colonne "server" dans le lien ci dessous.
https://docs.microsoft.com/fr-fr/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts
Cela va poser problème si ces ports sont utilisés en sortie par une autre connexion cliente (d'une autre machine que le DC) pour aller sur le net - ce qu'on appelle les ephemeral ports...
Lorsque la connexion sera sur le retour (en inbound pour la box) le flux sera redirigé vers le DC, et non vers le client initial.
Autre souci, le DC a une IP privée, et s'enregistre dans son propre DNS.
Même si on fait le montage DNS blablabla IP publique coté Registrar Internet ; le DNS du DC fournira toujours l'IP privée et non publique.
Donc pour un client sur Internet qui demanderait les infos de la foret avec DNS, il s'attend à avoir l'IP publique pour joindre le DC ; or il aurait une IP privée en réponse - non routable sur Internet.
A moins d'avoir plusieurs IP publiques et en dédier une pour le DC avec du NAT...le DC doit avoir cette IP publique dans sa conf réseau ; mais pas plusieurs IPs, ce n'est pas supporté. (cela s'appelle le multihoming).
Cela posera problème pour les clients AD sur le réseau privé d'ailleurs.
Je pourrai en citer probablement d'autres, mais les points ci dessus sont déja des NO GO.
-
Il est possible d'ouvrir une session Windows "AD", lorsque l'on est pas sur le réseau d'entreprise sans VPN. La machine est munie (par défaut) d'un cache de session ; cela sous entend d'avoir au préalable ouvert une session sur le réseau d'entreprise.
Avec tous les problème qui vont faire surface, la perte de la sécurité (et donc du besoin d'avoir un AD), la non "supportabilité" et la non pérennité, la complexité de configuration ; c'est plus simple de se pencher sur une solution autour d'un VPN; ça coutera moins cher à tous les points de vue, et surtout c'est supporté et ça fonctionne ;-)
Navré, mais il faut abandonner l'idée initiale.
Fuxill
Messages postés
88
Date d'inscription
vendredi 20 juillet 2018
Statut
Membre
Dernière intervention
30 août 2022
2
7 nov. 2021 à 19:32
7 nov. 2021 à 19:32
Bonsoir, en effet je vois que mon post n'est pas très bien expliqué et je m'en excuse ..
Je vous remercie pour avoir pris le temps de me répondre .
"En fait il y a -pour moi- aucun intérêt à laisser AD ouvert sur le net. A quoi ça sert ?"
Mon objectif serait de pouvoir joindre le domaine depuis l'extérieur du réseau local pour par exemple ouvrir une session avec un profil itinérant sans passer par un vpn ou autre donc une des option serait de rendre accessible le contrôleur de domaine depuis internet, et pour ce qui est du problème de sécurité je prend le risque sur les machine du réseaux local .
"D'où sort cette affirmation ?"
D'un forum anglais qui parler vaguement du sujet pour pesé le pour et le contre.
Pour ce qui est du domaine AD mon but étant qu'il soit accessible depuis internet donc pas possible de mettre un nom de domaine ex .lan. Par contre je suis assez d'accord avec vous pour ce qui est du domaine AD en sous domaine du domaine "public" ad.exemple.com" donc j'aimerais bien qu'il soit accessible sur ce genre adresse mais je suis un peu perdu j'avais des piste mais je me suis mélangé les pinceaux ....
"Pourquoi indiquer l'IP publique de la passerelle ? je ne comprends pas bien - surtout quel est le
projet de mettre 0.0.0.0 - normal que ça ne passe pas."
L'IP 0.0.0.0 est un exemple le but étant de mettre l'ip de la box ou est connecté le serveur qui gere DNS , DC pour définir comme serveur DNS du domaine "publique" le serveur DNS que j'ai sur la machine du domaine AD pour que le dns du domaine AD ai a la fois l'autorité sur le domaine publique et sur le domaine AD pour que celui-ci soit accessible depuis l'extérieur.
"Je comprends pas trop le port LDAP 35 , et le mélanger à une requête DNS."
Pour ça je me suis totalement mélangé les pinceaux car se que j'ai écris n'a aucun sens ;)
J'ai mélangé le port du serveur dns 53 (pas 35) et le port ldap du DC.
Je vous remercie encore d'avoir pris le temps de me répondre, et je vous souhaite une bonne soirée !!
Je vous remercie pour avoir pris le temps de me répondre .
"En fait il y a -pour moi- aucun intérêt à laisser AD ouvert sur le net. A quoi ça sert ?"
Mon objectif serait de pouvoir joindre le domaine depuis l'extérieur du réseau local pour par exemple ouvrir une session avec un profil itinérant sans passer par un vpn ou autre donc une des option serait de rendre accessible le contrôleur de domaine depuis internet, et pour ce qui est du problème de sécurité je prend le risque sur les machine du réseaux local .
"D'où sort cette affirmation ?"
D'un forum anglais qui parler vaguement du sujet pour pesé le pour et le contre.
Pour ce qui est du domaine AD mon but étant qu'il soit accessible depuis internet donc pas possible de mettre un nom de domaine ex .lan. Par contre je suis assez d'accord avec vous pour ce qui est du domaine AD en sous domaine du domaine "public" ad.exemple.com" donc j'aimerais bien qu'il soit accessible sur ce genre adresse mais je suis un peu perdu j'avais des piste mais je me suis mélangé les pinceaux ....
"Pourquoi indiquer l'IP publique de la passerelle ? je ne comprends pas bien - surtout quel est le
projet de mettre 0.0.0.0 - normal que ça ne passe pas."
L'IP 0.0.0.0 est un exemple le but étant de mettre l'ip de la box ou est connecté le serveur qui gere DNS , DC pour définir comme serveur DNS du domaine "publique" le serveur DNS que j'ai sur la machine du domaine AD pour que le dns du domaine AD ai a la fois l'autorité sur le domaine publique et sur le domaine AD pour que celui-ci soit accessible depuis l'extérieur.
"Je comprends pas trop le port LDAP 35 , et le mélanger à une requête DNS."
Pour ça je me suis totalement mélangé les pinceaux car se que j'ai écris n'a aucun sens ;)
J'ai mélangé le port du serveur dns 53 (pas 35) et le port ldap du DC.
Je vous remercie encore d'avoir pris le temps de me répondre, et je vous souhaite une bonne soirée !!
Fuxill
Messages postés
88
Date d'inscription
vendredi 20 juillet 2018
Statut
Membre
Dernière intervention
30 août 2022
2
7 nov. 2021 à 20:40
7 nov. 2021 à 20:40
Impressionnant vous avancer des explication très détaillés et intéressantes vous avez surement raison mais j'avais un espoir ayant vu un post a ce sujet qui menais a une solution mais qui n'était pas claire. Mais vous avez raison .. Même si je fait passé mon propre DNS comme DNS pour le domaine "publique" et que j'ajoute par exemple un enregistrement A "AD" avec ensuite l'adresse privé ex 192.168.0.15 du DC le DNS répondra au client 192.168.0.15 pour ad.exemple.com ce qui n'est en effet pas routable sur l'internet publique c'est bien ça ?
Pour les port pas très grave il n'y a jusque a routé toute la plage dynamique a la machine ?
Apres dans les fait j'ai déjà 2 ip publique une pour la ligne fixe ADSL et une autre pour l'agrégation 4G de la box mais celle-ci est dynamique malheureusement ..
"Cela posera problème pour les clients AD sur le réseau privé d'ailleurs."
qu'entendez vous par là ?
Pour les port pas très grave il n'y a jusque a routé toute la plage dynamique a la machine ?
Apres dans les fait j'ai déjà 2 ip publique une pour la ligne fixe ADSL et une autre pour l'agrégation 4G de la box mais celle-ci est dynamique malheureusement ..
"Cela posera problème pour les clients AD sur le réseau privé d'ailleurs."
qu'entendez vous par là ?
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
7 nov. 2021 à 20:56
7 nov. 2021 à 20:56
Pour les port pas très grave il n'y a jusque a routé toute la plage dynamique a la machine ?
Il n'y a pas que cette plage. Mais cette plage est aussi utilisée en sortie pour aller sur le net ; donc au retour, ça sera redirigée sur le DC, au lieu d'un client sur le réseau local qui allait sur le net en gros.
"Cela posera problème pour les clients AD sur le réseau privé d'ailleurs."
qu'entendez vous par là ?
C'est ce qu'on appelle du hairpinning (ou NAT loopback)
Il n'y a pas que cette plage. Mais cette plage est aussi utilisée en sortie pour aller sur le net ; donc au retour, ça sera redirigée sur le DC, au lieu d'un client sur le réseau local qui allait sur le net en gros.
"Cela posera problème pour les clients AD sur le réseau privé d'ailleurs."
qu'entendez vous par là ?
C'est ce qu'on appelle du hairpinning (ou NAT loopback)
Fuxill
Messages postés
88
Date d'inscription
vendredi 20 juillet 2018
Statut
Membre
Dernière intervention
30 août 2022
2
Modifié le 8 nov. 2021 à 00:33
Modifié le 8 nov. 2021 à 00:33
Rebonsoir, J'ai enfin réussi a relier mon domaine publique au dns que j'ai sur mon serveur mais je ne comprend pas ... Tout semble dénué de sens j'ai crée un enregistrement A vers une ip privé d'un serveur sur le réseaux local donc ex : iis.exemple.com 192.168.0.15 et ... le serveur arrive a être résoudre a l'extérieur alors que en réalité il se passe ça
Client qui demande iis.exemple.com > exemple.com > NS NS1.exemple.com > IP publique box > serveur dns ouvert en 53 > réponse du DNS A : IIS = 192.168.0.15 > réponse au client = 192.168.0.15
je prend mon téléphone en 4g (en dehors du réseaux local des machines) j'essaye de résoudre iis.exemple.com et j'arrive bien sur l'interface du serveur iis je comprend pas comment avec une adresse ip privé mon téléphone a réussi a résoudre le serveur ...
EDIT : Faux !!! Le wifi avait décidé de se rallumé de lui même voila qui me semble plus logique
Client qui demande iis.exemple.com > exemple.com > NS NS1.exemple.com > IP publique box > serveur dns ouvert en 53 > réponse du DNS A : IIS = 192.168.0.15 > réponse au client = 192.168.0.15
je prend mon téléphone en 4g (en dehors du réseaux local des machines) j'essaye de résoudre iis.exemple.com et j'arrive bien sur l'interface du serveur iis je comprend pas comment avec une adresse ip privé mon téléphone a réussi a résoudre le serveur ...
EDIT : Faux !!! Le wifi avait décidé de se rallumé de lui même voila qui me semble plus logique
Fuxill
Messages postés
88
Date d'inscription
vendredi 20 juillet 2018
Statut
Membre
Dernière intervention
30 août 2022
2
7 nov. 2021 à 22:01
7 nov. 2021 à 22:01
D'accord je comprend mieux donc compliqué ... Merci pour vos explications
Bon je vais devoir me rabattre sur l'option vpn vu les problèmes avec le Hairpinning mais comme lot de consolation de ne pas pouvoir mettre en place ça, j'aimerais bien utilisé le serveur dns que propose Microsoft comme serveur dns pour mon nom de domaine publique pour avoir un contrôle total de mes enregistrement est-ce pas trop dur a réalisé ? Vu que quand j'essaye de mettre l'ip de ma box dans comme serveur de nom chez mon registra il me redonne une erreur ..
Bon je vais devoir me rabattre sur l'option vpn vu les problèmes avec le Hairpinning mais comme lot de consolation de ne pas pouvoir mettre en place ça, j'aimerais bien utilisé le serveur dns que propose Microsoft comme serveur dns pour mon nom de domaine publique pour avoir un contrôle total de mes enregistrement est-ce pas trop dur a réalisé ? Vu que quand j'essaye de mettre l'ip de ma box dans comme serveur de nom chez mon registra il me redonne une erreur ..
