Aller au contenu

Mutualisation active directory


okba6z

Messages recommandés

Bonsoir à tous,

Je suis actuellement admin système au sein d'une communauté de commune, nous venons d'être mutualisé.

Au paravent j'étais dans la collectivité A.

J’ai comme projet la mutualisation de plusieurs domaines qui se trouve sur plusieurs forêts différentes.

Dans la collectivité A, il y'a 2 DC mono forêt mono domaine (+- 700 comptes AD/exch)

Dans la communauté de commune, il y'a 2 DC mono forêt mono domaine, elle gère actuellement 2 autres petites collectivités (dans des OU distinctes)  (+- 150 comtpes AD/exch)

3 autres communes vont venir s'ajoutés à cette mutualisation.

Dans la B il y a 2 dc mono forêt mono domaine (+- 300 comptes AD/exch)

Dans la C il y a 2 dc mono forêt mono domaine (+- 450 comptes AD/exch)

Dans D il y a 2 dc mono forêt mono domaine (+- 500 comptes AD/exch)

L'ensemble des collectivités utilisent leurs messageries sur EXCHANGE 2013.

L'ensemble des collectivités ont un lien fibre et ou hertzien entre elles.

 

Les difficultés que nous rencontrons actuellement c'est que des agents des collectivités A ou B ou C peuvent être amenés a travaillés dans les locaux de la communauté de commune et ou dans les autres collectivités et donc nécessite l'accès à des ressources (fichiers, progiciels, calendrier, wifi etc....)

Actuellement ces agents ont un compte AD dans leur collectivité respectif et un compte dans la communauté de commune.

 

Nous souhaiterions mutualisé l'ensemble des actives directory/exchange pour une meilleur facilité de gestion et ainsi permettre à n'importe quel agent ou qu'il soit de pouvoir se connecté aisément et avoir accès aux ressources qu'il a besoin.

 

Je ne sais pas vers quoi me lancé vers une forêt multi-domaine?

Ou forêt mono domaine avec domaine enfant?

 

 

A terme nous souhaiterions mutualisé le serveur de fichier, est-ce une bonne idée?

 

merci d'avance de m'éclairer avec vos lumière

 

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

 

Le plus simple pour accéder au ressource de n'importe quel utilisateur sur n'importe quel PC sur n'importe quel site est de mettre en place des relations d'approbations AD.

 

Cet article est très clair je trouve : https://rdr-it.com/active-directory-relation-approbation-entre-deux-forets-domaines/

 

Dans ce cas précis c'est de multiples relations d'approbations entre différentes forêts AD.

 

Cela permet aussi des accès croisés aux ressources.

 

Lien vers le commentaire
Partager sur d’autres sites

Merci à vous pour vos réponses, j'avais déjà étudier les relations d'approbations entre domaine.

Le point bloquant concernant les relations d'approbation est le suivant:

- Un agent de l'entité B ou C ne peut pas interagir avec le calendrier du compte exchange (ajout/suppression de rdv) de l'agent de l'entité A ou D

Je vous donne un exemple pour que cela soit plus parlant:

Nous avons des secrétaires de l'entité B ou C qui peuvent gérer les calendriers (ajout/suppression de rdv) des agents de l'entité A/B/C/D

La relation d'approbation ne permet pas ces droits

 

Merci de m'aiguiller

Lien vers le commentaire
Partager sur d’autres sites

Attention aux relations d'approbations !
Il faut bien faire attention au sens d'autorisations, et ne surtout jamais tout autoriser. Si un des domaines est trop permissif, tu vas dégrader toute la foret.

Pour des collectivités, il faut prendre en compte que tu seras amener à gérer des données sensibles ou bien que des données sensibles soient hébergées sur le domaine.
I faut par conséquent vérifier la note Cyber de la foret.
Un outil gratuit, et développé par un français, permet de voir cela très facilement, cela s'appelle Ping Castle. Je le conseille à toute personne en charge d'un domaine AD.

 

A dispo.

Lien vers le commentaire
Partager sur d’autres sites

  • 2 weeks later...
Le 28/02/2022 à 09:33, okba6z a dit :

Merci à vous pour vos réponses, j'avais déjà étudier les relations d'approbations entre domaine.

Le point bloquant concernant les relations d'approbation est le suivant:

- Un agent de l'entité B ou C ne peut pas interagir avec le calendrier du compte exchange (ajout/suppression de rdv) de l'agent de l'entité A ou D

Je vous donne un exemple pour que cela soit plus parlant:

Nous avons des secrétaires de l'entité B ou C qui peuvent gérer les calendriers (ajout/suppression de rdv) des agents de l'entité A/B/C/D

La relation d'approbation ne permet pas ces droits

 

Merci de m'aiguiller

 

Exchange 2013 est en fin de support étendu dans un an, c'est le bon moment pour lancer les études de renouvellement/fusion/externalisation de ces serveurs.

Vu le volume d'utilisateurs et de serveurs s'y prendre un an à l'avance, surtout dans le public me semble important :)

 

C'est pas précisé, mais les serveurs sont probablement en 2012R2 (voir pire ^^), le topo de l'EOL est le même.

 

Sinon pour la cible, je verrais bien un DC par site pour ne pas dépendre du lien internet pour l'authentification, coté domaines/forêts dur à dire sans beaucoup plus de précisions.

 

Exchange vu le volume total de boites c'est une grosse infra si sur site, au moins 2 serveurs CAS en frontaux, et 3 à 6 serveurs BAL.

Le tout avec du load balancer, de la backup sérieuse, antispam, anti-dos et pare feu NGEN pour protéger tout cela.

 

Même si ça serait un super "Kiff" de monter un truc pareil, j'aurais pas une envie folle de le maintenir au quotidien !

Lien vers le commentaire
Partager sur d’autres sites

  • 3 weeks later...

Hello, j'ajoute ma pierre à l'édifice.

Oui, la relation d’approbation te permettra de répondre à la demande rapidement mais c'est une solution très douteuse à long terme surtout dans ta situation.

Comme indiqué plus haut, la meilleure méthode c'est de lancer un grand projet de réunification,

DC sur chaque site, forêt unique et des OU bien organisées.

 

J'ai bossé sur la réunification de 3 hôpitaux, j'ai pu voir de haut comment ils avaient géré ça et la meilleure méthode a été de faire ce que je viens de dire.

Lien vers le commentaire
Partager sur d’autres sites

×
×
  • Créer...