Objet de stratégie

L’objet Policy est utilisé pour contrôler l’accès à la base de données LSA ( Local Security Authority ) et contient des informations qui s’appliquent à l’ensemble du système ou qui établissent des valeurs par défaut pour le système. Chaque système n’a qu’un seul objet Policy . Cet objet Policy est créé par le LSA au démarrage du système et les applications ne peuvent pas le créer ou le détruire.

Les informations stockées dans un objet Policy incluent :

• Quota de mémoire par défaut du système. Sauf indication contraire, ce quota de mémoire est attribué à chaque utilisateur qui se connecte au système. Des quotas de mémoire spéciaux peuvent être attribués à des individus ou des membres de groupes ou de groupes locaux par le biais d’un objet Account .
• Exigences d’audit de sécurité à l’échelle du système.
• Nom et SID du domaine de compte de ce système.
• Informations sur le domaine principal de ce système. Ces informations incluent le nom et le SID du domaine principal, le nom du compte dans le domaine principal qui doit être utilisé pour les demandes d’authentification, les traductions de nom et de SID, ainsi que l’obtention des noms des contrôleurs de domaine au sein du domaine. Ces noms peuvent être obsolètes et ne doivent être pris qu’à titre d’indication. L’ordre de cette liste est supposé être significatif et sera maintenu. Cela permet, par exemple, au prénom de la liste de représenter le dernier contrôleur de domaine principal connu.
• Informations indiquant si la LSA détient le master copie des informations de stratégie ou un réplica. Seule une partie des informations de stratégie est répliquée ; le reste est établi par système.

Les champs AccountDomain et PrimaryDomain de l’objet Policy sont utilisés à des fins différentes en fonction du type de relations système et d’approbation :

• Sur un système qui n’a pas de domaine principal, le champ AccountDomain contient le nom et le SID du domaine de compte local du système, qui sont identiques au nom de l’ordinateur. Le champ PrimaryDomain contient le nom du groupe de travail dont cette machine est membre. Les objets TrustedDomain sont ignorés à une exception près : il ne peut pas y avoir d’objet TrustedDomain portant le même nom que le groupe de travail, car il apparaît comme s’il s’agit du domaine principal de la machine.
• Sur un système qui a un domaine principal, le champ AccountDomain identifie le nom et le SID du domaine de compte local, comme précédemment. Toutefois, le champ PrimaryDomain contient le nom et le SID du domaine principal du système. En outre, il doit y avoir un objet TrustedDomain avec le nom et le SID identifiés dans le champ PrimaryDomain . Cet objet TrustedDomain contient les informations de compte et de serveur nécessaires pour établir un canal sécurisé vers un contrôleur de domaine dans le domaine principal. Tous les autres objets TrustedDomain sont ignorés.
• Sur les contrôleurs de domaine, le champ AccountDomain identifie le domaine de compte local pour le système ; toutefois, le nom du compte est attribué par l’utilisateur au lieu d’être un nom connu. Étant donné que le domaine principal est identique au domaine du compte, le champ PrimaryDomain doit contenir la même valeur que le champ AccountDomain . En outre, tous les objets TrustedDomain sont censés être valides et représenter des relations d’approbation avec d’autres domaines. Si le système n’approuve aucun autre domaine, il ne doit pas y avoir d’objets TrustedDomain .