locked
RODC : ports à ouvrir en In et en Out? RRS feed

  • Question

  • Bonjour,

    Pour des besoins d'authentification, nous avons besoin de mettre un RODC en DMZ (environnement Windows 2008 R2).
    D'après le lien Configuration de ports requise pour AD, l'ouverture des ports 135, 389 et 53248 sont nécessaires. Mais sur quel DC et dans quel sens?

    La réplication est unidirectionnelle donc est ce qu'une ouverture en OUT sur le DC principale et IN sur le RODC est suffisante? Ou est-ce que le RODC doit interroger le DC principale d'une quelconque manière?

    Quand je lis ce post, j'ai l'impression qu'il faut ouvrir sur tous les DC, les ports de la même manière.

    Je voudrais donc savoir si ça fonctionne en ouvrant seulement les ports en IN sur le DC principale et OUT sur le RODC.
    Je ne veux pas autoriser les ports en IN sur le DC principale depuis la DMZ en fait.


    Merci d'avance.

    jeudi 21 mars 2013 09:15

Réponses

  • Dans ce cas le RODC ne correspond pas à vos besoins.

    Il existe deux autres approches :

    • une instance AD LDS qui servira de magasin d'auth LDAP (http://technet.microsoft.com/fr-fr/library/cc754361(v=ws.10).aspx). Attention, il ne s'agit pas d'auth de serveurs membres d'un domaine, mais d'un fournisseur d'auth pour des applications type serveur Web.
    • un proxy LDAP, mais il ne correspondra pas forcement à vos besoins non plus.

    Pour la communication Serveur -> RODC -> DC/GC, il faut savoir que le RODC ne peut pas réaliser toutes les opérations d'un DC/GC, certaines opérations doivent être remontées en amont. Cela fait partie de la stratégie de sécurité des RODC et c'est pourquoi ils doivent communiquer avec un DC/GC.

    Si ce n'était pas le cas, cela signifierait qu'un RODC serait beaucoup trop proche d'un DC d'un point de vue sécurité (génération de TGT, gestion des mdp, ...).

    Voici un article qui décrit différents scénarii de communication avec un RODC : http://technet.microsoft.com/en-us/library/cc754218(v=ws.10).aspx


    Bruce Jourdain de Coutance - Consultant Exchange http://brucejdc.blog.free.fr



    • Modifié Bruce JDC mardi 26 mars 2013 09:07
    • Marqué comme réponse Kyo67 mardi 26 mars 2013 11:00
    mardi 26 mars 2013 09:01
  • Avec AD LDS, les ports doivent également être ouvert IN sur le DC principal, non?

    Cela depend, vous pouvez exporter les données de l'AD et l'importer sur le LDS via ldifde par exemple.

    http://technet.microsoft.com/fr-fr/library/cc753671(v=ws.10).aspx


    Bruce Jourdain de Coutance - Consultant Exchange http://brucejdc.blog.free.fr

    • Marqué comme réponse Kyo67 mardi 26 mars 2013 11:00
    mardi 26 mars 2013 10:54

Toutes les réponses

  • Bonjour, 

    Tous les détails sur les ports qu'il faut les ouvrir et dans quel sens se trouve dans ce lien: Designing RODCs in the Perimeter Network


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    jeudi 21 mars 2013 12:36
    Auteur de réponse
  • La réplication est unidirectionnelle donc est ce qu'une ouverture en OUT sur le DC principale et IN sur le RODC est suffisante? Ou est-ce que le RODC doit interroger le DC principale d'une quelconque manière?

    Le RODC va passer toutes les requetes qu'il n'a pas le droit de traiter vers les DC, donc il faut forcement permettre une communication RODC -> DC / GC. Par exemple lorsqu'un utilisateur change son mdp il va adresser la requete à un GC, donc hors RODC.

    Pour l'auth, ne pas oublier de mettre en cache les comptes qui s'authentifient sur le RODC.


    Bruce Jourdain de Coutance - Consultant Exchange http://brucejdc.blog.free.fr - Un script pour facilement monter son lab chez soi : http://social.technet.microsoft.com/Forums/fr-FR/windows8fr/thread/f26dd7dd-96b2-4b6a-a085-bc83d3d64599 Votez pour si ce script va vous servir!

    jeudi 21 mars 2013 13:15
  • Le RODC va passer toutes les requetes qu'il n'a pas le droit de traiter vers les DC, donc il faut forcement permettre une communication RODC -> DC / GC. Par exemple lorsqu'un utilisateur change son mdp il va adresser la requete à un GC, donc hors RODC.

    Et si l'on veut uniquement autoriser l'authentification?

    Merci de vos réponses en tout cas.

    jeudi 21 mars 2013 15:18
  • Le RODC doit pouvoir communiquer avec DC / GC

    Certains produits peuvent demander à communiquer directement avec un DC ou GC pour fonctionner (ex : Exchange).

    Communication from the RODC to a writeable domain controller

    To enable the RODC role on a server that is designated to be an RODC, there must be communication between that server and a writeable domain controller.

    For the required the ports for each functionality, see the “Required communication ports” section later in this topic.

    Based on the requirements of your RODC design, you may have to allow traffic from the perimeter network client computers and servers to a writeable domain controller that resides in the corporate network. For example, you may have to allow DNS traffic for dynamic updates, LDAP referrals, or other protocols, depending on your deployment scenario.


    Bruce Jourdain de Coutance - Consultant Exchange http://brucejdc.blog.free.fr - Un script pour facilement monter son lab chez soi : http://social.technet.microsoft.com/Forums/fr-FR/windows8fr/thread/f26dd7dd-96b2-4b6a-a085-bc83d3d64599 Votez pour si ce script va vous servir!

    jeudi 21 mars 2013 15:32
  • Et si l'on veut uniquement autoriser l'authentification?

    Bruce vous a déjà répondu à cette question, il suffit de mettre les utilisateur en cache pour qu'il s'authentifie.

    Pour avoir plus des détails veuillez consulter ce lien :Password Replication Policy Administration


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    jeudi 21 mars 2013 15:33
    Auteur de réponse
  • Oui mais Bruce a dit aussi que le RODC doit communiquer avec DC / GC et dans la doc Microsoft : "... there must be communication between that server and a writeable domain controller". Pour certaines applications, je conçois bien cette nécessité... Mais je veux juste pouvoir autoriser les users à se connecter (sans changement de mot de passe, ni rien).

    Si l'on met les utilisateurs en cache pour qu'il s'authentifie et que l'on bloque en IN les ports du DC (donc pas de communication du RODC vers le DC mais uniquement du DC vers le RODC), cela va t'il fonctionner?

    Si ce n'est pas le cas, pourquoi faut-il obligatoirement ouvrir la communication dans les deux sens?

    Il y a peut-être une autre solution envisageable qui m'échappe?


    • Modifié Kyo67 samedi 23 mars 2013 10:58
    samedi 23 mars 2013 10:56
  • Bonjour,

    Si l'on met les utilisateurs en cache pour qu'il s'authentifie et que l'on bloque en IN les ports du DC (donc pas de communication du RODC vers le DC mais uniquement du DC vers le RODC), cela va t'il fonctionner?

    Oui , l'utilisateur peuvent s'authentifier mais lors du changement du mot de passe de l'un des utilisateurs^ou bien créatio ou suppréssion par exemple d'un utilisateurs ou ordinateur , la bases de donnée utilisé par RODC ne sera pas mis à jour.

    Si ce n'est pas le cas, pourquoi faut-il obligatoirement ouvrir la communication dans les deux sens?

    Il faut juste respecter les ports qu'il faudra les ouvrir dans le lien que je vous ai fourni dans ma première réponse.

    Il y a peut-être une autre solution envisageable qui m'échappe?

    La ^présence d'un active directory est indispensable pour qu'un utilisateur de domaine puisse s'authentifier, le RODC vous permet de réduire la bande passante (réplication vers un seul  sens (DC---> RODC), et avec la fonctionnalité les utilisateur puissent s'authentifier sans avoir besoin de contacter un autre contrôleur 


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    lundi 25 mars 2013 10:16
    Auteur de réponse
  • Si l'on met les utilisateurs en cache pour qu'il s'authentifie et que l'on bloque en IN les ports du DC (donc pas de communication du RODC vers le DC mais uniquement du DC vers le RODC), cela va t'il fonctionner?

    Oui , l'utilisateur peuvent s'authentifier mais lors du changement du mot de passe de l'un des utilisateurs^ou bien créatio ou suppréssion par exemple d'un utilisateurs ou ordinateur , la bases de donnée utilisé par RODC ne sera pas mis à jour.

    Mmmhhh... Et si l'on planifie chaque nuit une réplication complète du DC vers le RODC? En forçant la réplication sans se soucier de ce qu'il y a déjà sur le RODC? C'est un peu barbare mais est-ce que ça fonctionnerait?

    Ou dois-je me faire à l'idée que si je ne veux pas ouvrir de ports en IN sur le DC, Microsoft ne me propose pas de solution d'authentification en DMZ?

    lundi 25 mars 2013 16:36
  • Mmmhhh... Et si l'on planifie chaque nuit une réplication complète du DC vers le RODC? 

    Comment comptes-tu faire cela ?

    Perso je resterai sur une utilisation de l'AD tel qu'il est prévu.

    Le RODC est la pour palier au problème de DC sur un site distant. Je ne vois pas trop ce qu'il fait dans une DMZ ....Après je ne vois pas en quoi cela peut être gênant de laisser des DC dialoguer et répliquer tel que prévue.

    En générale on mets plutôt un serveur frontale dans la DMZ qui lui dialogue avec le DC. Je ne vois pas trop l'objectif final.

    lundi 25 mars 2013 19:56
  • Mmmhhh... Et si l'on planifie chaque nuit une réplication complète du DC vers le RODC? 

    Comment comptes-tu faire cela ?

    Perso je resterai sur une utilisation de l'AD tel qu'il est prévu.

    Peu importe. Via script ou autre. Tant que c'est possible, ça me va. Je veux juste savoir si ça l'est. Peu importe les recommandations de Microsoft.

    Je n'ouvrirais pas les ports en IN sur le DC.

    mardi 26 mars 2013 08:32
  • Dans ce cas le RODC ne correspond pas à vos besoins.

    Il existe deux autres approches :

    • une instance AD LDS qui servira de magasin d'auth LDAP (http://technet.microsoft.com/fr-fr/library/cc754361(v=ws.10).aspx). Attention, il ne s'agit pas d'auth de serveurs membres d'un domaine, mais d'un fournisseur d'auth pour des applications type serveur Web.
    • un proxy LDAP, mais il ne correspondra pas forcement à vos besoins non plus.

    Pour la communication Serveur -> RODC -> DC/GC, il faut savoir que le RODC ne peut pas réaliser toutes les opérations d'un DC/GC, certaines opérations doivent être remontées en amont. Cela fait partie de la stratégie de sécurité des RODC et c'est pourquoi ils doivent communiquer avec un DC/GC.

    Si ce n'était pas le cas, cela signifierait qu'un RODC serait beaucoup trop proche d'un DC d'un point de vue sécurité (génération de TGT, gestion des mdp, ...).

    Voici un article qui décrit différents scénarii de communication avec un RODC : http://technet.microsoft.com/en-us/library/cc754218(v=ws.10).aspx


    Bruce Jourdain de Coutance - Consultant Exchange http://brucejdc.blog.free.fr



    • Modifié Bruce JDC mardi 26 mars 2013 09:07
    • Marqué comme réponse Kyo67 mardi 26 mars 2013 11:00
    mardi 26 mars 2013 09:01
  • Tout est possible même casser son AD ... Maintenant l'objectif d'une recommandation c'est de l'éviter ....

    DC classique ou RODC les DC doivent répliqués tel que cela a été prévues par Microsoft ...

    Voir 

    http://technet.microsoft.com/en-us/library/dd728028(v=ws.10).aspx#ad_rep

    Je reprends la phrase de Bruce, car la réponse à votre question est posté depuis un moment :

    Le RODC doit pouvoir communiquer avec DC / GC

    mardi 26 mars 2013 09:16
  • Dans ce cas le RODC ne correspond pas à vos besoins.

    Il existe deux autres approches :

    • une instance AD LDS qui servira de magasin d'auth LDAP (http://technet.microsoft.com/fr-fr/library/cc754361(v=ws.10).aspx). Attention, il ne s'agit pas d'auth de serveurs membres d'un domaine, mais d'un fournisseur d'auth pour des applications type serveur Web.
    • un proxy LDAP, mais il ne correspondra pas forcement à vos besoins non plus.

    Ok, le RODC n'est pas la bonne solution. Je suis parti sur une mauvaise voie.

    Je veux pouvoir authentifier les utilisateurs sur des services web comme un calendrier par exemple (non Microsoft) qui utilise LDAP. Et ceci sans ouvrir de ports de l'extérieur vers l'intérieur. Qu'il y ait un laps de temps entre le changement de mot de passe sur le réseau interne et l'accès externe m'est égal.

    S'il est possible de faire un push des comptes de l'AD vers la solution choisie, cela me convient parfaitement.

    Avec AD LDS, les ports doivent également être ouvert IN sur le DC principal, non?

    mardi 26 mars 2013 10:26
  • Avec AD LDS, les ports doivent également être ouvert IN sur le DC principal, non?

    Cela depend, vous pouvez exporter les données de l'AD et l'importer sur le LDS via ldifde par exemple.

    http://technet.microsoft.com/fr-fr/library/cc753671(v=ws.10).aspx


    Bruce Jourdain de Coutance - Consultant Exchange http://brucejdc.blog.free.fr

    • Marqué comme réponse Kyo67 mardi 26 mars 2013 11:00
    mardi 26 mars 2013 10:54
  • Avec AD LDS, les ports doivent également être ouvert IN sur le DC principal, non?

    Cela depend, vous pouvez exporter les données de l'AD et l'importer sur le LDS via ldifde par exemple.

    http://technet.microsoft.com/fr-fr/library/cc753671(v=ws.10).aspx


    Bruce Jourdain de Coutance - Consultant Exchange http://brucejdc.blog.free.fr

    Ah yessss! Good! Je vais tester ça.

    Merci à tous pour vos réponses.

    mardi 26 mars 2013 11:00