> Tech > Sécurité au niveau domaine

Sécurité au niveau domaine

Tech - Par iTPro - Publié le 24 juin 2010
email

Bien que les systèmes NT puissent fonctionner indépendamment et en toute sécurité sans bénéficier d'un domaine, il est risqué de compter seulement sur la sécurité au niveau de l'hôte quand de nombreux utilisateurs du réseau ont besoin d'accéder aux ressources de plusieurs serveurs. Quand un ordinateur n'est pas membre d'un

Sécurité au niveau domaine

domaine, les utilisateurs doivent utiliser un compte local de machine dans le SAM de l’ordinateur pour se connecter à  cet ordinateur. Sans un domaine, chaque utilisateur a besoin de comptes utilisateurs multiples – un pour chaque serveur auquel il doit accéder. La multiplication des comptes par utilisateur multiplie également les problèmes. Les utilisateurs sont contraints de synchroniser les mots de passe pour chaque compte. Et, quand des employés quittent la société, il faut trouver et supprimer chacun de leurs comptes. On peut facilement en oublier un et se retrouver avec un problème d’accès résiduel (c’est-à -dire, des utilisateurs encore capables d’accéder au réseau, longtemps après avoir quitté la société). Pour régler tous ces problèmes, il faut créer un domaine et donner à  chaque utilisateur un compte de domaine valide pour tous les serveurs auxquels il a besoin d’accéder.

Quand une station de travail ou un serveur de membre rejoint un domaine, il ne perd aucun de ses paramètres de sécurité propres à  l’ordinateur ; bien au contraire, il gagne des fonctionnalités de domaine supplémentaires. Après qu’un serveur ou une station de travail ait rejoint un domaine, la machine fait confiance au DC du domaine pour authentifier les utilisateurs de celui-ci. Par conséquent, les utilisateurs peuvent se connecter (log on) en utilisant un compte local de machine ou un compte de domaine. Une fois qu’un ordinateur a rejoint un domaine, on peut également ajouter des utilisateurs de domaines et des groupes de domaines aux ACL des fichiers et autres objets sur l’ordinateur. NT ajoute automatiquement le groupe Domain Admins du domaine au groupe Administrators local de l’ordinateur. (Cette action explique pourquoi les membres de Domain Admins ont un accès administrateur à  chaque ordinateur du domaine. Pour plus d’informations sur la mise en oeuvre du contrôle administratif personnalisé, voir « NT Security: Establishing Custom Administrative Control », http://www.win2000mag.com, InstantDoc ID 4871.)

Alors que les SAM des serveurs de membres ou des stations de travail sont spécifiques et limités à  un ordinateur, un SAM de DC ne l’est pas. Un SAM de PDC est le SAM pour tout le domaine, et User Manager for Domains ouvre automatiquement le SAM du PDC. Quand on crée un utilisateur ou un groupe ou qu’on modifie une politique dans User Manager for Domains, l’utilitaire enregistre les changements dans le SAM du PDC. Quelques minutes après, le PDC réplique ce changement dans le SAM de chaque BDC. Par conséquent – en tenant compte du temps de latence entre les cycles de réplication – tous les DC dans un domaine donné partagent un SAM en double et ont les mêmes comptes, groupes et politiques utilisateurs. Ainsi, quand on active l’audit dans User Manager for Domains, on active également l’audit pour le PDC. Lors de la réplication, NT active l’audit sur chaque BDC.

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro - Publié le 24 juin 2010