Re : "Comment pouvons-nous permettre à notre partenaire de se connecter à notre AD, mais l'empêcher d'accéder à tout autre serveur, à l'exception de ceux du site ?"
Je vous encourage vivement à créer un AD forêt expressément pour les ressources de la PJ. Créez des trusts forestiers intransitifs à sens unique avec les infrastructures AD existantes des membres de l'entreprise commune. À l'aide d'une redirection DNS sélective, maintenez le DNS de l'entreprise commune dans une zone DNS intégrée AD sécurisée hébergée par les serveurs de l'entreprise commune. Cela permet de maintenir le partenaire à distance de vos propres serveurs. Les deux partenaires doivent explicitement placer les données / applications / serveurs partagés dans la zone partagée. L'utilisation de votre AD existant pour la "zone partagée" peut vous faire économiser un peu d'argent sur la licence, mais cela ne vaut pas le risque et la complexité supplémentaires.
re : "Comment pouvons-nous configurer ce système pour que les services informatiques respectifs de chaque partenaire puissent gérer les postes de travail locaux sans disposer de privilèges d'administration sur notre AD ?" et "Actuellement, nous travaillons à partir du schéma de réseau ci-dessous. En utilisant des VLAN, nous pouvons empêcher chaque partenaire de la coentreprise de traverser le lien VPN des autres et permettre l'accès aux ressources partagées, mais cette configuration ne permet pas à chaque partenaire de la coentreprise de gérer ses propres postes de travail et utilisateurs."
Je ne suis pas sûr de comprendre. Je vois ce que vous dites à propos de l'isolation du trafic réseau des membres de l'entreprise commune, mais je ne comprends pas le reste. Les membres de l'entreprise commune vont-ils avoir des comptes d'utilisateurs et d'ordinateurs dans leurs propres forêts AD, ou dans la forêt de l'entreprise commune ? Ce n'est pas clair pour moi. Je demanderais aux membres du PJ de maintenir leurs comptes d'utilisateur et d'ordinateur dans leurs propres forêts AD, et d'accorder l'accès aux ressources partagées du PJ par l'adhésion à des groupes dans la forêt AD du PJ.
Ohh ! Je crois que j'ai compris. Sur ce "site", il y aura quelques ordinateurs clients qui seront partagés par les utilisateurs des deux membres de la JV travaillant ensemble ! Est-ce que j'ai raison ?
Vous pouvez gérer ces ordinateurs "partagés" de plusieurs manières différentes.
Je joindrais probablement les ordinateurs au domaine AD de JV, mais vous ne le feriez peut-être pas. La propriété des ordinateurs clients dicterait probablement la façon dont je traiterais cette question. Si les ordinateurs clients restent avec chaque membre de l'entreprise commune, je pense que je les joindrais au domaine AD du membre de l'entreprise commune propriétaire.
Lorsque les ordinateurs clients sont joints au domaine AD de l'entreprise commune, les comptes d'utilisateur de l'un ou l'autre des domaines membres de l'entreprise commune (ainsi que le domaine AD de l'entreprise commune lui-même) peuvent être utilisés pour se connecter aux ordinateurs clients (puisque des relations de confiance sont établies entre la forêt AD de l'entreprise commune et les forêts AD des membres).
Sachez qu'il serait utile d'avoir des contrôleurs de domaine en lecture seule de la forêt AD de chaque membre en place sur le "site partagé". Si les ordinateurs clients sont joints à la forêt AD JV, la stratégie de groupe d'ordinateurs proviendra de la forêt AD JV. La politique de groupe d'utilisateurs proviendra des forêts AD des membres, cependant, donc avoir un DC local serait utile. Si les ordinateurs clients sont joints aux forêts AD des membres, alors, évidemment, avoir un DC local de chaque forêt des membres serait bien.
La délégation de contrôle dans la forêt AD de l'entreprise commune peut être utilisée pour donner au personnel informatique des membres de l'entreprise commune toutes les capacités dont il a besoin dans la forêt AD de l'entreprise commune elle-même. La politique de groupe "Groupes restreints" peut être utilisée pour accorder au personnel informatique des membres de l'entreprise commune des droits administratifs sur "leurs" ordinateurs clients qui sont joints au domaine AD de l'entreprise commune. (Les ordinateurs clients qui restent dans les forêts AD des membres sont un point discutable).
re : "Mettre en place une confiance à double sens entre les partenaires de la JV et permettre à chaque partenaire de gérer ses propres utilisateurs et machines". Quels sont les avantages et les inconvénients de cette solution ? Jusqu'où cette confiance s'étend-elle ?" et "Créer un nouveau domaine et mettre en place des trusts à sens unique à partir de chacun des domaines d'origine. Quels sont les avantages et les inconvénients de ce système ?
Une "relation de confiance" Windows ne donne accès à rien, en soi. Regardez cette déclaration : "Le domaine A fait confiance au domaine B."
Maintenant, remplacez le mot "trusts" par la phrase "is permitted to name in permissions users, groups, and computers from" : "Le domaine A est autorisé à nommer dans les autorisations les utilisateurs, les groupes et les ordinateurs du domaine B."
Une "confiance" n'accorde pas l'accès, elle vous donne la possibilité d'accorder l'accès . Si vous avez une forêt AD JV dédiée, vous voudrez qu'elle ait des trusts intransitifs externes à sens unique avec les forêts AD des membres JV afin que les utilisateurs et les groupes de la forêt des membres JV puissent être nommés dans les autorisations ou joints aux groupes de la forêt AD JV. Cela permettrait aux comptes d'utilisateurs et d'ordinateurs de chaque membre de l'entreprise commune d'être gérés dans la forêt AD de ce membre. En utilisant des groupes situés dans la forêt AD de l'entreprise commune pour contrôler les autorisations d'accès aux ressources de l'entreprise commune, cette dernière pourrait gérer efficacement les autorisations d'accès à ses ressources.
D'après ce que je comprends de votre situation, vous ne voudriez en aucun cas d'une confiance réciproque. Ai-je raison de penser qu'il n'est pas mutuellement souhaitable que l'un des membres de JV nomme les utilisateurs, les groupes ou les ordinateurs de l'autre membre dans les autorisations ? Il semble qu'il n'y aura pas de ressources partagées hébergées sur des serveurs appartenant aux deux membres de la JV, la confiance mutuelle n'est donc pas nécessaire. Cela dit, une fois encore, une confiance réciproque ne permet que la capacité d'accorder l'accès et n'accorde en fait aucun accès.
J'ai une certaine expérience d'un projet similaire mené il y a quelques années entre une association hosptique locale et plusieurs groupes de médecins. Dans leur cas, ils ont créé une forêt AD dédiée pour la JV, mais n'ont pas créé de relations de confiance avec les infrastructures existantes des membres de la JV. Nous nous sommes retrouvés avec des informations d'identification en double dans l'AD local des membres de l'entreprise commune et dans l'AD de l'entreprise commune. C'était la plus grande "verrue" que j'ai vue dans leur réseau, et c'est quelque chose que j'éviterais à l'avenir.
Je vois que vous êtes dans la construction. J'ai un client qui fait de l'ingénierie de contact et de la gestion de projet pour des projets de construction à grande échelle et dont les employés se trouvent souvent dans des bureaux de terrain (ou "remorques") sur les sites du client pendant des années. Je n'ai pas encore eu de situation où le client ou un autre entrepreneur du projet a atteint le niveau de détail que vous recherchez, mais la situation que j'ai décrite ci-dessus est celle que je suivrais si cela se produisait. Le coût de quelques licences Windows Server et d'ordinateurs pour héberger les contrôleurs de domaine pour l'AD JV (et les DC en lecture seule des membres sur site) n'est pas très élevé amorti sur 4 ans, et crée une base très solide sur laquelle mener des opérations partagées.
