Partie 1 – Connaissances de base et théorie

Cet article s’adresse à tous les administrateurs amateurs qui disposent d’un Windows Server 2003 pour leur réseau privé et qui souhaitent également en exploiter toutes les possibilités. En raison de l’abondance des possibilités, l’article sera divisé en plusieurs parties, l’une s’appuyant sur l’autre.

Connaissances de base et un peu de théorie

Il est souhaitable d’avoir des connaissances de base sur le fonctionnement d’un réseau et de connaître la terminologie spécialisée. Si certains termes techniques ne vous sont pas familiers, vous pouvez les rechercher dans le glossaire d’AT-Mix.

Conformément à ce principe, je ne traiterai pas (ou ne pourrai pas traiter) tous les détails techniques en détail dans cet article et j’omettrai une grande partie de la théorie – les administrateurs expérimentés manqueront donc l’une ou l’autre chose. Néanmoins, le chemin complet vers un domaine personnel avec les fonctionnalités utiles pour un réseau local privé sera décrit de manière aussi détaillée que possible.

A propos de la personne

Je m’appelle Jörg Alexander Ott, je suis né en 1976 et je m’occupe d’ordinateurs depuis près de 20 ans. Depuis quelques années, je travaille comme administrateur de systèmes et de réseaux et je suis responsable de la planification, de l’installation, de la maintenance et du dépannage des systèmes dans un environnement hétérogène – je m’occupe donc non seulement des serveurs Windows, mais aussi des serveurs Linux et de tous les systèmes clients (W9x à XP). Je suis actuellement en train de suivre une formation continue MCSE2003, qui devrait être terminée à l’automne 2004.

Partie 1 – Connaissances de base et un peu de théorie

Avant l’installation, Dieu a placé la théorie – cet article ne peut (malheureusement) pas faire l’impasse sur ce principe, même si je vais essayer de limiter la théorie au minimum. Mais je ne peux pas la laisser de côté…

Qu’est-ce qu’un „domaine“ ?

Le terme „domaine“ est surtout connu en relation avec les domaines Internet. Il en va de même pour les domaines locaux, un domaine se composant ici aussi d’au moins deux „parties“. Dans la pratique, cela se présente généralement comme suit : domaene.local ou site.domaene.local. Et tout comme pour les domaines Internet, les directives pour une résolution DNS correcte doivent être respectées (bien que le serveur 2003 offre encore la résolution NetBios, c’est la résolution DNS qui est importante).

L’objectif d’un domaine local – connu depuis Windows 2000 sous le nom d’Active Directory – est en fait d’encadrer les ordinateurs d’un réseau dans un environnement gérable de manière centralisée et de pouvoir ainsi gérer tous les ordinateurs à partir d’un point central. En même temps, un domaine permet d’exclure tous les membres qui ne font pas partie du domaine de l’utilisation des ressources, ce qui est par exemple presque impossible dans un réseau peer-to-peer sans domaine.

Le terme „domaine“ date encore de l’époque de NT4, entre-temps on parle d'“Active Directory“ (ci-après AD), et ce n’est pas sans raison :

L’AD représente un catalogue de répertoires dans lequel des objets de différents types peuvent être enregistrés. Les objets peuvent être des comptes d’utilisateurs, des comptes d’ordinateurs ou encore des imprimantes. Les fonctionnalités AD permettent d’attribuer à chaque objet certains paramètres de sécurité, de sorte que, par exemple, User1 peut imprimer des documents sur l’imprimante1, mais pas User2, etc. Il en va de même pour les partages de fichiers au sein de l’AD – c’est là que les possibilités des paramètres de sécurité prennent tout leur sens.

Chaque objet dans l’AD reçoit son propre SID et est donc unique, ce qui le rend relativement facile à retrouver (le point concernant la „récupération“ est plutôt valable pour les grands réseaux ; dans un réseau privé, la récupération d’objets ne devrait pas poser de problème).

Il est important de noter que chaque membre de l’AD peut être autorisé ou non à accéder à n’importe quel objet dans l’AD – nous y reviendrons plus tard.

L’ordinateur le plus important dans l’AD est le contrôleur de domaine (ci-après DC) – il contient toutes les informations de l’AD, ce que l’on appelle le „catalogue global“. En même temps, il sert de serveur de connexion qui procède à l’authentification et autorise ou refuse ainsi l’accès. Dans un environnement „mono-serveur“, le DC est également utilisé comme serveur d’applications et de fichiers.

A quoi faut-il faire attention avant de promouvoir un serveur Windows 2003 au rang de contrôleur de domaine ?

Pour réussir à reproduire cet article, il est avant tout important que le serveur ait été installé récemment et qu’aucun paramètre n’ait été modifié – une installation standard tout à fait normale avec les valeurs par défaut proposées lors du setup. Il est certainement possible de transformer un serveur déjà en production et configuré en conséquence en un DC – mais cela doit être bien planifié au préalable et nécessite avant tout la réinitialisation de certains paramètres aux valeurs par défaut, ce que je ne peux évidemment pas aborder ici.

Le seul paramètre qui doit être modifié avant la mise à niveau est l’attribution d’une adresse IP statique, nous y reviendrons plus tard.

Conditions requises pour l’utilisation d’un contrôleur de domaine

Pour exploiter un AD dans un LAN, il faut un peu de planification préalable. Il faut d’abord savoir quel segment IP on choisit – une fois que l’on a attribué une adresse IP statique au DC et qu’on l’a surclassé, il est difficile de la modifier par la suite. Le choix du segment IP est particulièrement important si l’on souhaite accéder ultérieurement à des réseaux externes à partir du LAN : si le réseau de l’entreprise utilise par exemple le même segment IP, les connexions VPN poseront problème plus tard, etc. Plus de détails à ce sujet plus tard. Choisissez donc le segment IP de votre DC (et donc de votre LAN) de préférence en dehors de tous les réseaux déjà existants (dans cet article, le segment IP sera 192.168.10.0/24), c’est-à-dire un réseau privé de classe C.

En outre, le système d’exploitation des clients dans le réseau est important : Windows 2000 Professional ou Windows XP Professional sont les systèmes d’exploitation qui ont leur place dans un AD, les systèmes plus anciens comme 9x, ME ou NT ne permettent pas de faire grand chose dans l’AD. Dans cet article, je me base sur Windows XP Professional comme système d’exploitation client, bien que la plupart des paramètres puissent être repris 1:1 pour Windows 2000 Professional.

Enfin, le réseau lui-même doit fonctionner correctement, il devrait donc y avoir au moins un commutateur ou un routeur avec commutateur intégré et les câbles appropriés pour connecter les clients. Je déconseille ici les connexions directes via un câble croisé, qui conduisent inévitablement à des problèmes si les deux ordinateurs ne fonctionnent pas en permanence – chaque DC doit être connecté en permanence à une connexion réseau active, sinon les messages d’erreur pleuvent. Dans le cas d’une connexion croisée, la connexion réseau est désactivée lorsque le client est éteint, les problèmes sont donc inévitables. En outre, on peut se demander s’il faut absolument un DC pour un ordinateur…

Voilà pour la théorie – la deuxième partie, qui sera accompagnée de captures d’écran comme toutes les autres parties suivantes, traite de l’élévation d’un serveur Windows 2003 au rang de contrôleur de domaine et décrit la procédure et les conséquences.

Partie 2 : Configuration de l’Active Directory
Partie 3 : configuration du service DNS/WINS et du serveur DHCP, etc.
Partie 4 : création des partages nécessaires, création d’utilisateurs, etc.
Partie 5 : Création et liaison d’un script de connexion, définition des autorisations locales, etc.
Partie 6 : installation et configuration des Software Update Services (SUS)