Objet de stratégie

L’objet Policy est utilisé pour contrôler l’accès à la base de donnéesde l’autorité de sécurité locale(LSA) et contient des informations qui s’appliquent à l’ensemble du système ou é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 l’application LSA lors du démarrage du système, et les applications ne peuvent pas créer ou détruire l’objet.

Les informations stockées dans un objet Policy incluent :

• Quota de mémoire par défaut du système. Sauf indication contraire, chaque utilisateur qui se connecte au système reçoit ce quota de mémoire. Des quotas de mémoire spéciaux peuvent être attribués à des individus ou à des membres de groupes ou de groupes locaux via 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 à utiliser pour les demandes d’authentification, le nom et les traductions SID, et 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’en tant qu’indicateur. 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 contrôleur de domaine principal connu.
• Informations sur la conservation de la copie principale des informations de stratégie ou d’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 est identique au nom de l’ordinateur. Le champ PrimaryDomain contient le nom du groupe de travail dont cette machine est membre. objets TrustedDomain sont ignorés avec une exception : 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 l’ordinateur.
• Sur un système disposant d’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 pour le système. En outre, il doit y avoir un objet TrustedDomain portant 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. Les autres objets TrustedDomain sont ignorés.
• Sur les contrôleurs de domaine, le champ AccountDomain identifie le domaine de compte local du système ; toutefois, le nom du compte est attribué par l’utilisateur plutôt que d’être un nom connu. Étant donné que le domaine principal est identique au domaine de compte, le champ primaryDomain doit contenir la même valeur que le champ AccountDomain. De plus, 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 pas d’autres domaines, il ne doit y avoir aucun objets TrustedDomain.