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

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

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

Peut-on utiliser des serveurs remplissant d'autres rôles comme contrôleurs de domaine?

Quels éléments devraient être pris en compte pour déterminer s'il faut "double usage" d'un serveur?

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

Existe-t-il une différence entre les versions de Windows Server?

Vous pouvez et cela fonctionne. J'ai environ 40 succursales et - pour des raisons politiques - une décision de gestion a été prise pour donner à chacun une infrastructure de serveur complète. Pour des raisons financières, il s'agissait d'un environnement à serveur unique dans chacun, donc tout est DC / File / Exchange (c'était dans les jours Windows 2000).

Cependant, sa gestion est un cauchemar, et ma règle préférée est "un DC est un DC et rien d'autre ne s'y passe". Ce sont vos serveurs les plus importants, et si votre annonce devient drôle, vous aurez du mal à le récupérer correctement. Si vous le pouvez, donnez-vous les meilleures chances d'éviter cela en ayant des rôles DC dédiés. Si vous ne pouvez pas, mendier, crier, gémir, soudoyer, menacer, prophétiser ou tout ce qu'il faut pour vous mettre dans une position où vous le pouvez.

Les contrôleurs de domaine multi-rôles sont assez courants. Bien que la plupart des rôles qu'ils remplissent soient des rôles d'infrastructure réseau. De bons exemples sont les serveurs de fichiers, DHCP et DNS. Ce sont de mauvais choix pour des choses comme les serveurs Terminal Server (les utilisateurs n'ont pas le droit de se connecter à un contrôleur de domaine et leur octroyer lesdites autorisations nécessite des administrateurs de 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 que tous les serveurs DNS internes s'exécutent sur des contrôleurs de domaine ainsi que mes services DHCP. Cela semble être une bonne combinaison de rôles sur les contrôleurs de domaine pour réduire les coûts et tirer le meilleur parti du matériel possible.

• Peut-on utiliser des serveurs remplissant d'autres rôles comme contrôleurs de domaine?

"Vous pouvez même couper une boîte de conserve avec, mais vous ne voudriez pas!" - M. Popeil , paroles Weird Al Yankovic

Je suppose que la question est: voulez-vous? Bien sûr, vous pouvez transformer votre contrôleur de domaine en un serveur de fichiers et d'impression, ou une boîte SQL Server, ou n'importe quel nombre d'autres fonctions. Mais il y a un inconvénient à cela, un prix à payer sous la forme de fonctionnalités dégradées sur cette boîte. Si vous avez très peu d'utilisateurs (par exemple moins de 25-50), ou si vous êtes pressé par des contraintes budgétaires et que vous devez en faire une boîte "tout en un", vous pouvez vous en sortir. Mais il y a des problèmes de performances, des problèmes de sécurité et même des incompatibilités potentielles entre les services. Faire des boîtes «tout en un» est fonction des budgets malfaisants établis par les gardiens du marché qui ne comprennent pas le prix qu'ils paieront.

Si vous pouvez vous le permettre, placez le contrôleur de domaine dans une boîte séparée. Heck, si possible, obtenez une boîte bon marché mais de qualité serveur, probablement une boîte au niveau du département, et mettez vos services DC là-dessus; puis obtenez un jumeau de cette boîte et mettez également les services DC sur cela. C'est le modèle que Windows aimerait avoir, et vous devriez vraiment, vraiment , avoir au moins deux contrôleurs de domaine pour chaque domaine.

Achetez les boites boeuf pour les services qui sont les plus utilisés - bases de données, e-mail, fichier et impression, etc. Ce sont les boîtes «quotidiennes» que les utilisateurs voient régulièrement; il est préférable que les contrôleurs de domaine conservent les informations d'identification des utilisateurs sur le domaine.

• Quels éléments devraient être pris en compte pour déterminer s'il faut "double usage" d'un serveur?

Pouvez-vous vous en sortir avec des niveaux de performances dégradés? Y aura-t-il une incompatibilité entre le service que vous installez et tout autre service pouvant s'exécuter? Cela interférera-t-il avec l'authentification AD?

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

Non. Mais cela augmentera sa charge de travail. Et si vous intégrez d'autres fonctions non Windows (par exemple, en utilisant une pile PAM pour authentifier une boîte Linux via Kerberos dans le cadre d'un service IMAP), attendez-vous à ce que la charge de travail augmente.

• Existe-t-il une différence entre les versions de Windows Server?

Chaque version augmente le nombre de fonctionnalités, bien qu'il soit sûr de dire que vous voulez au moins Windows 2000, sinon mieux. La plupart des gens utilisent Windows 2003 (et leurs cousins), ce qui inclut des améliorations des services de fichiers, des clichés instantanés de volumes, etc. 2008 fournit encore plus d'améliorations.

Microsoft Small Business Server est AD + Exchange + serveur de fichiers + routeur / serveur VPN + Sharepoint + SQL Server .. et plus encore tous regroupés en un seul serveur. Je ne dirais donc pas que sa «meilleure pratique» consiste à avoir toutes les fonctions sur un serveur différent. Pour les petites opérations, il n'est pas logique de tout exécuter sur un matériel différent.

Il semble que cela se résume à la sécurité et aux performances. Je ne pense pas que les performances soient un problème majeur sur les petits réseaux, AD utilise une quantité infime du serveur le moins cher que vous pourriez mettre en place en ce moment.

À ce stade, vous pouvez simplement comparer la sécurité et le coût - c'est à cela que se résument toutes les questions de sécurité dans un petit réseau ...

Je pense que toutes les réponses peuvent être résumées par Small Business Server.

Bien sûr, MS a pu jeter presque TOUT (AD, Exchange, SQL, etc.) sur une seule boîte. Mais il fonctionne comme de la merde et n'est utile que dans des situations très limitées.

En bref, pouvez-vous le faire? Oui. Devriez-vous le faire? Je ne le recommande pas, mais cela peut fonctionner si vous êtes dans une impasse.

Du point de vue des performances, cela dépend de la charge des deux services. Sur un réseau plus petit, un contrôleur de domaine peut également servir de serveur DNS ou DHCP sans problème. Sur un réseau plus grand, cela demande des ennuis.

Je recommanderais fortement que vous ne mettiez pas plus d'un serveur "principal" sur la même boîte physique. IE, s'il s'agit de votre DC maître, l'utiliser comme serveur DNS secondaire ou serveur DHCP de sauvegarde serait acceptable. La raison en est que vous ne voulez pas qu'un échec sur une boîte soit souscrit pour souscrire deux services.

Je découragerais fortement quiconque d'exécuter des services plus exigeants, tels qu'un serveur Web (IIS ou Apache, etc.) ou des bases de données de toute sorte.

Si vous décidez d'exécuter plus d'un type de service sur la même boîte physique, je recommanderais fortement de devenir aussi "costaud" que possible et de l'utiliser comme hôte pour les serveurs virtualisés. De cette façon, tous vos services sont encore quelque peu indépendants les uns des autres au niveau du système d'exploitation.

Il n'y a rien qui empêche intrinsèquement un contrôleur de domaine de fonctionner dans d'autres capacités.

Si vous avez une infrastructure AD existante et que vous n'avez qu'un seul contrôleur de domaine, je dirais que les inconvénients de la promotion d'un autre serveur seraient compensés par les avantages d'obtenir un autre contrôleur de domaine.

N'oubliez pas qu'après avoir exécuté dcpromo, vous devrez redémarrer, donc tous les services fournis par la machine nouvellement promue seront interrompus. De plus, si vous disposez de stratégies de sécurité de contrôleur de domaine, elles s'appliqueront à ce serveur.

Vous POUVEZ mais pourquoi voudriez-vous? Théoriquement, vous pouvez avoir l'ensemble des services sur la même boîte (Small Business Server). Cependant, ce n'est pas parce que vous POUVEZ faire quelque chose que vous devez le faire. Le contrôleur de domaine détient la base de données AD, donc si vous voulez risquer de l'enliser avec l'impression (et Dieu ne plaise) le partage de fichiers, c'est un risque que vous devrez vous évaluer. Si vous voulez jouer en toute sécurité, montez gratuitement un serveur Linux et utilisez-le comme partage de fichiers réseau ou serveur d'impression et essayez de garder vos boîtes de serveur de domaine comme ça.

Oui, ils le peuvent, mais du point de vue de la sécurité, la réponse habituelle est non. La raison en est simple: plus il s'exécute sur un contrôleur de domaine, plus la surface exploitable pour prendre la boîte est grande. Prenez la boîte et vous avez le domaine. En règle générale, il n'est pas rare de voir DNS s'exécuter avec des zones intégrées à Active Directory. Cependant, quoi que ce soit d'autre, je dirais non, sauf si vous êtes un petit magasin et que vous ne pouvez tout simplement pas vous permettre de vous séparer des services.

(ne me prends pas trop au sérieux, mais tu sais que j'ai un point)

Bien sûr, installez simplement VMware, et sur cela Debian et vous avez un excellent serveur polyvalent. Autrement dit, si la charge sur l'hôte est suffisamment petite.

Si j'avais le choix d'avoir un seul contrôleur de domaine ou d'exécuter un autre contrôleur de domaine sur une boîte SQL, je prendrais cette option.

En fait, je préférerais probablement exécuter un serveur virtuel plutôt que de transformer n'importe quel autre serveur en un contrôleur de domaine, même s'il ne fonctionnait que sur un poste de travail.

Mon opinion personnelle est que pour la stabilité, vous avez besoin d'au moins trois contrôleurs de domaine qui vous permettent de diviser les rôles de maître d'opération, et vous devriez toujours avoir au moins deux catalogues globaux - mais en tenant compte du fait que le maître d'infrastructure ne doit pas être un GC .

Je voudrais généralement exécuter DNS et DHCP sur un ou plusieurs contrôleurs de domaine et avoir au moins deux contrôleurs de domaine. Personnellement, j'ai un DC virtuel fonctionnant sur deux de mes hôtes virtuels (exécutant VMware ESXi, trois hôtes virtuels au total) et un physique également. Tous les contrôleurs de domaine sont des serveurs DNS, et deux d'entre eux sont des serveurs DHCP (desservant chacun la moitié de la plage). La virtualisation facilite (et en fonction de la façon dont vous payez pour les licences Windows, abordable) d'avoir des machines virtuelles spécifiques aux tâches, et je préfère de loin diviser les choses car le redémarrage d'un serveur n'affectera pas les autres.

Cependant, j'exécute SBS 2003 dans un autre bureau (plus petit) et il fonctionne bien sur un serveur costaud, bien que le problème de planification du redémarrage soit parfois ennuyeux. SBS est physique, mais j'ai un deuxième serveur exécutant VMware ESXi qui a une machine virtuelle Windows qui est également un contrôleur de domaine, j'ai donc un serveur secondaire (le deuxième contrôleur de domaine est autorisé avec SBS tant que SBS détient des rôles FSMO). Je déteste avoir un DC, cela rendrait la récupération plus difficile et tout temps d'arrêt plus long!

J'essaierais d'ajouter seulement quelque chose comme l'impression et / ou le service de fichiers à un DC si possible, en plus du DNS et du DHCP. D'autres devraient être soigneusement pesés ... et si possible, collez même un serveur de bureau / bas de gamme comme boîte secondaire DC / DNS uniquement si vous devez mélanger sur le matériel principal. Même le matériel non redondant est susceptible d'être opérationnel si votre serveur principal est en panne et vice versa (que ce soit pour un redémarrage ou un crash).