Discussion :

[StringBuilder]

Bonjour,

Pour commencer, autant j'ai déjà administré un réseau NT à titre professionnel, à l'époque de NT 4.0... autant ma dernière expérience avec un contrôleur de domaine date de... Windows 2000, et c'était à titre perso.
Du coup j'ai des notions, un peu rouillées, et pas forcément à jour, ni approfondies... Désolé par avance.

Je tiens à préciser, je n'administre pas les serveurs dont je parle ci-après, je demande juste conseil à titre indicatif et culture personnelle.

Nous hébergeons pour plusieurs clients des applications nécessitant une intégration à leurs domaines.

Les services en question ne peuvent pas être installés sur un contrôleur de domaine (aussi bien pour des raisons de sécurité que pour des raisons d'incompatibilité).
Donc on a un DC par client qui se synchronise avec le DC de chacun de nos client.

Pour gérer 10 pékins connectés en même temps et par client, je trouve ça vraiment du gâchis en termes de ressources et de licences.
De plus ça a des répercutions négatives sur le coût de location de l'hébergement, c'est dommage.

A l'époque de Windows 2000 est apparu la notion de "forêt" en plus de la simple notion de domaine (même s'il me semble qu'il y avait déjà des notions de sous-domaine depuis NT 3.51...)

L'idée que j'ai, donc, serait d'avoir chez nous un seul DC, qui gère un domaine principal "fictif" (avec genre juste les comptes des admins de l'hébergeur), et avec un sous-domaine par client.
Ensuite, les serveurs des clients seraient membres du sous-domaine qui correspond au client.

Je suis content de mon idée, mais je me demande bien pourquoi je serais le seul de ma boîte, alors que c'est pas mon métier, à l'avoir eu.
Du coup, quelques questions avant de passer pour un 3 lettres

1/ Un même DC peut-il gérer lui-même un domaine et plusieurs sous-domaines ? Ou si chaque sous domaine doit être géré par son propre DC, tous membres du domaine principal ? (il me semble que sous NT 4.0 ça marchait comme ça). Je sais qu'un DC ne peut pas gérer plusieurs domaines... mais cela englobe-t-il aussi les sous-domaines ?

2/ Un sous-domaine peut-il est synchronisé avec un autre DC qui n'est pas membre du domaine principal ? On ne va évidement pas demander à nos client de devenir membres de notre domaine d'hébergement...

Si tout ça n'est pas possible, avez-vous une idée alternative pour permettre de gérer le plus proprement possible la réplication des comptes de nos clients sans devoir installer un DC par client ?

Quand je vois Office 365, j'imagine que Microsoft s'amuse pas à mettre en place un DC pour chaque client... si ?

[chrtophe]

Les grosses évolutions de l'Active Directory par rapport aux anciennes versions est en caricaturant le calage par rapport au fonctionnement des DNS.

Admettons que developpez.com gère un Active Directory. Tu pourras avoir un domaine paris.developpez.com, un autre domaine marseille.developpez.com. La forêt sera developpez.com, paris et marseille seront des domaines. Il pourra également y avoir des sous-domaines comme dev.paris.developpez.com. Chaque domaine est autonome, faisant toujours partie d'une forêt, même avec un domaine unique.

Pour ton cas, tu auras la forêt de ton entreprises :
- un domaine interne
- un domaine pour chacun de tes clients.

C'est pour la présentation, le domaine interne ne devra pas être dans la même forêt que les domaines des clients sauf nécessité absolue.

Le domaine interne à ta forêt et dédié à ton client X aura des relations d'approbation avec le domaine de ton client (si j'ai bien compris c'est en gros ce que tu dois avoir actuellement mais sans gestion centralisée). Une relation d'approbation défini les droits d'accès inter-domaine.

Mais la première question sera, pourquoi avez-vous besoin de vous connecter sur les domaines de vos clients ?

Il est également possible de faire des relations d'approbations entre forêts.

Le shéma d'annuaire Active Directory est le même pour tous les domaines de la forêt. La forêt facilite la communication entre les domaines mais ceux-ci restent autonomes.

[StringBuilder]

En fait, on a besoin de gérer la relation avec le domaine de nos clients pour plusieurs licences :
- On héberge un ERP dont les comptes sont liés à l'AD. Ainsi, il est plus simple pour le client de gérer ses licences directement depuis son contrôleur de domaine chez lui.
- L'ERP en question, évidement, contient des informations vitales pour l'entreprise. D'un point de vue gestion du risque, il est plus simple que la moindre modification d'habilitation (notamment désactivation d'un compte) soit répercutée immédiatement dans l'ERP sans autre actions.
- Les utilisateurs se connectent en TSE sur le serveur. Mais un ERP ayant besoin d'interagir avec des fichiers et mails, on souhaite pouvoir mapper des serveurs de fichiers du client directement accessible depuis le TSE chez nous, et on souhaite pouvoir utilise une suite office au nom des utilisateurs sur le TSE.

Sans synchro AD, ça va être la croix et la bannière, et ça va se terminer avec des mots de passes différents, des droits incohérents, etc.

D'où cette nécessité d'inscrire les serveurs dans le domaine du client.
Après, notre besoin d'avoir un DC en local c'est surtout au niveau performances : si on peut éviter de passer par le VPN pour valider chaque action des utilisateurs, ça sera toujours autant de bande passante gagnée pour le TSE (sans oublier le lag lié au ping énorme d'un VPN).