Windows : les contrôleurs de domaine peuvent-ils aussi remplir d'autres fonctions ?

[visiteur]

Cette question portait sur la nécessité d’Active Directory pour exécuter les services Terminal. Mais une chaîne de réponses et de commentaires (principalement de moi) a soulevé une question connexe sur les contrôleurs de domaine.

Il est clairement une mauvaise pratique de n’avoir qu’un seul contrôleur de domaine dans un environnement AD. Il est également clairement recommandé d’avoir chaque contrôleur de domaine sur un serveur dédié (physique ou virtuel) à fonction unique. Cependant, tout le monde ne peut pas toujours suivre les bonnes pratiques.

Est-il acceptable d’utiliser des serveurs remplissant d’autres rôles comme contrôleurs de domaine ?

Quels éléments faut-il prendre en compte pour décider de « doubler l’usage » d’un serveur ?

Le rôle de contrôleur de domaine change-t-il la façon dont Windows gère le système de fichiers ou le matériel ?

Y a-t-il des différences entre les versions de Windows Server ?

[admin]

Les contrôleurs de domaine multi-rôles sont assez courants. Cependant, la plupart des rôles qu’ils remplissent sont des rôles d’infrastructure réseau. De bons exemples sont les serveurs de fichiers, DHCP et DNS. Ils sont de mauvais choix pour des choses comme les serveurs Terminal (les utilisateurs n’ont pas le droit de se connecter à un contrôleur de domaine et leur donner ces droits nécessite les droits d’administrateur du domaine), les serveurs d’applications web, les serveurs d’applications métier, les serveurs pare-feu/proxy/ISA, etc.

Dans mes environnements, je préfère avoir tous les serveurs DNS internes fonctionnant sur les contrôleurs de domaine ainsi que mes services DHCP. Cela semble être une bonne combinaison de rôles sur les DC pour réduire les coûts et tirer le meilleur parti du matériel disponible.