Bonjour Camille Richard,
Votre problème a-t-il déjà été résolu ? Si c'est le cas, merci d'accepter la réponse car cela aide aussi d'autres personnes partageant le même problème. Merci :)
Domic V.
Journalisation d’événements non sollicitée : identification des configurations d’audit natives dans un nouveau déploiement AWS sous Windows Server 2019
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(19.2, 88%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECR%3C/text%3E%3C/svg%3E)
Camille Richard
40
Points de réputation
Bonjour,
Nous avons récemment provisionné des instances AWS EC2 exécutant Windows Server 2019 Datacenter afin de servir de socle à notre nouveau réseau d’entreprise. Lors d’un premier contrôle de conformité sur ces nouveaux contrôleurs de domaine et serveurs membres, j’ai constaté que l’Observateur d’événements Windows commençait déjà à alimenter activement les journaux de sécurité.
Cela est assez surprenant, car notre équipe d’ingénierie n’a encore déployé aucun objet de stratégie de groupe (GPO) administratif et nous n’avons pas non plus configuré manuellement de règles dans la stratégie de sécurité locale pour imposer un suivi d’audit. Pourriez-vous préciser quelles activités système spécifiques le système d’exploitation capture nativement « out of the box » ? Merci beaucoup.
Windows pour les entreprises | Windows Server | Expérience utilisateur | Autre
2 réponses
Trier par : Le plus utile
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 33%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDV%3C/text%3E%3C/svg%3E)
Domic Vo 34,160 Points de réputation Conseiller indépendant2026-05-08T10:53:44.8133333+00:00 -
Domic Vo 34,160 Points de réputation Conseiller indépendant
2026-05-06T14:38:39.5333333+00:00 Hi Camille Richard,
The activity you are seeing is the intended behavior for modern Windows Server environments. Starting with Windows Server 2016 and continuing through 2019 and 2022, Microsoft implemented a "secure by default" posture that enables several Advanced Audit Policy subcategories immediately upon installation. Even before you link a single GPO, the operating system kernel is hardcoded to capture "Success" events for critical activities. This includes process creation, which generates Event ID 4688, and account logons, which generate Event ID 4624. These events allow for immediate forensic visibility without requiring manual administrative setup.
When you promoted these EC2 instances to Domain Controllers, the "Default Domain Controllers Policy" was automatically applied. This policy is unique because it specifically targets the OU containing your DCs and enforces more rigorous auditing for directory service access and account management. If you observe logs involving the Security Accounts Manager or Kerberos authentication, these are triggered by this built-in GPO. To see exactly which rules are currently in effect and bypassing the "Not Configured" labels often seen in the local security policy UI, you should run auditpol /get /category:* from an administrative command prompt. This utility queries the system's effective policy directly from the local security authority, providing the most accurate view of your active audit state.
If this answer helped, please click "Accept Answer " so that other community members with similar issues can easily find the solution. Your contribution is much appreciated.
Domic V.