convert_library_version: 'v2 ; Compat Mode: [0] {[v2.1] (DEFAULT) Don''t use any Compatibility
  Mode}'
urn: urn:intuitem:risk:library:anssi-points-de-controle-active-directory
locale: fr
ref_id: anssi-points-de-controle-active-directory
name: "Points de contr\xF4le Active Directory (AD)"
description: "L'annuaire Active Directory, centre n\xE9vralgique de la s\xE9curit\xE9\
  \ des syst\xE8mes d'information Microsoft, est un \xE9l\xE9ment critique permettant\
  \ la gestion centralis\xE9e de comptes, de ressources et de permissions. L'obtention\
  \ de privil\xE8ges \xE9lev\xE9s sur cet annuaire entra\xEEne une prise de contr\xF4\
  le instantan\xE9e et compl\xE8te de toutes les ressources ainsi administr\xE9es.\n\
  L'analyse des modes op\xE9ratoires des attaques r\xE9centes met en \xE9vidence une\
  \ recrudescence du ciblage des annuaires Active Directory, compte tenu de leur r\xF4\
  le de pierre angulaire de la plupart des syst\xE8mes d'information. En effet, l'attaquant\
  \ ayant obtenu des droits \xE9lev\xE9s sur l'annuaire peut alors d\xE9ployer une\
  \ charge malveillante sur l'ensemble du syst\xE8me d'information, notamment par\
  \ GPO ou en utilisant des connexions directes (`psexec`, `wmiexec`). Par cons\xE9\
  quent, le faible niveau de s\xE9curit\xE9 des annuaires met en danger les syst\xE8\
  mes d'information dans leur globalit\xE9 et fait porter un risque syst\xE9mique\
  \ aux organisations.\nLes observations de l'ANSSI font appara\xEEtre un manque de\
  \ maturit\xE9 critique et r\xE9current sur la s\xE9curit\xE9 des annuaires Active\
  \ Directory. Le niveau de s\xE9curit\xE9 d\xE9cro\xEEt ainsi de mani\xE8re importante\
  \ en fonction du temps et au rythme de la manipulation de ses objets ou des actions\
  \ d'administration.\nEn r\xE9ponse \xE0 ce risque croissant, l'ANSSI a d\xE9velopp\xE9\
  \ et met \xE0 disposition un recueil de points de contr\xF4le, afin d'accompagner\
  \ les chaines DSI et SSI dans le suivi du niveau de s\xE9curit\xE9 des annuaires\
  \ Active Directory. Ce recueil a vocation \xE0 \xEAtre enrichi r\xE9guli\xE8rement\
  \ en fonction des travaux de recherche, des pratiques constat\xE9es en audit, et\
  \ de l'analyse des modes op\xE9ratoires adverses."
copyright: ANSSI
version: 1
publication_date: 2025-11-21
provider: ANSSI
packager: intuitem
translations:
  en:
    name: ANSSI Active Directory (AD) Security Assessment Checklist
    description: 'Active Directory is a critical component of Microsoft-based information
      systems; it provides unified management features for user accounts, resources
      and access rights or permissions. Gaining high privileges in this context instantly
      grants full control over all resources that are managed through the Active Directory
      infrastructure.

      Recently observed adversary tactics shed light on regained interest for targeting
      Active Directory infrastructure, given their essential role in most information
      systems. Attackers who have gained high privileges may be able to deploy malware
      at scale throughout the whole network, leveraging GPOs or direct connections
      (`psexec`, `wmiexec`). Weak security controls in such environments pose a real
      systemic threat to the whole IT system in organizations.

      ANSSI regularly meets a critical lack of cyber security maturity when applied
      to Active Directory environments. The observed security level weakens significantly
      with time, loose day-to-day operations and management.

      To address this growing risk, ANSSI has implemented and publishes an assessment
      checklist and corrective measures. This is intended for CTOs and CISOs, helping
      them track the actual security level of their Active Directory infrastructure.
      This collection will be improved upon on a regular basis, benefiting from ongoing
      research, observed practical constraints and solutions during audits, as well
      as threat intelligence.'
    copyright: ANSSI
objects:
  framework:
    urn: urn:intuitem:risk:framework:anssi-points-de-controle-active-directory
    ref_id: anssi-points-de-controle-active-directory
    name: "Points de contr\xF4le Active Directory (AD)"
    description: "L'annuaire Active Directory, centre n\xE9vralgique de la s\xE9curit\xE9\
      \ des syst\xE8mes d'information Microsoft, est un \xE9l\xE9ment critique permettant\
      \ la gestion centralis\xE9e de comptes, de ressources et de permissions. L'obtention\
      \ de privil\xE8ges \xE9lev\xE9s sur cet annuaire entra\xEEne une prise de contr\xF4\
      le instantan\xE9e et compl\xE8te de toutes les ressources ainsi administr\xE9\
      es.\nL'analyse des modes op\xE9ratoires des attaques r\xE9centes met en \xE9\
      vidence une recrudescence du ciblage des annuaires Active Directory, compte\
      \ tenu de leur r\xF4le de pierre angulaire de la plupart des syst\xE8mes d'information.\
      \ En effet, l'attaquant ayant obtenu des droits \xE9lev\xE9s sur l'annuaire\
      \ peut alors d\xE9ployer une charge malveillante sur l'ensemble du syst\xE8\
      me d'information, notamment par GPO ou en utilisant des connexions directes\
      \ (`psexec`, `wmiexec`). Par cons\xE9quent, le faible niveau de s\xE9curit\xE9\
      \ des annuaires met en danger les syst\xE8mes d'information dans leur globalit\xE9\
      \ et fait porter un risque syst\xE9mique aux organisations.\nLes observations\
      \ de l'ANSSI font appara\xEEtre un manque de maturit\xE9 critique et r\xE9current\
      \ sur la s\xE9curit\xE9 des annuaires Active Directory. Le niveau de s\xE9curit\xE9\
      \ d\xE9cro\xEEt ainsi de mani\xE8re importante en fonction du temps et au rythme\
      \ de la manipulation de ses objets ou des actions d'administration.\nEn r\xE9\
      ponse \xE0 ce risque croissant, l'ANSSI a d\xE9velopp\xE9 et met \xE0 disposition\
      \ un recueil de points de contr\xF4le, afin d'accompagner les chaines DSI et\
      \ SSI dans le suivi du niveau de s\xE9curit\xE9 des annuaires Active Directory.\
      \ Ce recueil a vocation \xE0 \xEAtre enrichi r\xE9guli\xE8rement en fonction\
      \ des travaux de recherche, des pratiques constat\xE9es en audit, et de l'analyse\
      \ des modes op\xE9ratoires adverses."
    translations:
      en:
        name: ANSSI Active Directory (AD) Security Assessment Checklist
        description: 'Active Directory is a critical component of Microsoft-based
          information systems; it provides unified management features for user accounts,
          resources and access rights or permissions. Gaining high privileges in this
          context instantly grants full control over all resources that are managed
          through the Active Directory infrastructure.

          Recently observed adversary tactics shed light on regained interest for
          targeting Active Directory infrastructure, given their essential role in
          most information systems. Attackers who have gained high privileges may
          be able to deploy malware at scale throughout the whole network, leveraging
          GPOs or direct connections (`psexec`, `wmiexec`). Weak security controls
          in such environments pose a real systemic threat to the whole IT system
          in organizations.

          ANSSI regularly meets a critical lack of cyber security maturity when applied
          to Active Directory environments. The observed security level weakens significantly
          with time, loose day-to-day operations and management.

          To address this growing risk, ANSSI has implemented and publishes an assessment
          checklist and corrective measures. This is intended for CTOs and CISOs,
          helping them track the actual security level of their Active Directory infrastructure.
          This collection will be improved upon on a regular basis, benefiting from
          ongoing research, observed practical constraints and solutions during audits,
          as well as threat intelligence.'
    implementation_groups_definition:
    - ref_id: level_1
      name: Niveau 1
      description: "L'annuaire Active Directory pr\xE9sente des probl\xE8mes critiques\
        \ de configuration qui mettent en danger imm\xE9diat l'ensemble des ressources\
        \ h\xE9berg\xE9es. Des actions correctrices sont \xE0 prendre dans les plus\
        \ brefs d\xE9lais ;"
      translations:
        en:
          name: Level 1
          description: Critical weaknesses and misconfigurations pose an immediate
            threat to all hosted resources. Corrective actions should be taken as
            soon as possible;
    - ref_id: level_2
      name: Niveau 2
      description: "L'annuaire Active Directory pr\xE9sente des lacunes de configuration\
        \ et de gestion suffisantes pour mettre en danger l'ensemble des ressources\
        \ h\xE9berg\xE9es. Des actions correctrices sont \xE0 prendre \xE0 court terme\
        \ ;"
      translations:
        en:
          name: Level 2
          description: Configuration and management weaknesses put all hosted resources
            at risk of a short-term compromise. Corrective actions should be carefully
            planned and implemented shortly;
    - ref_id: level_3
      name: Niveau 3
      description: "L'annuaire Active Directory poss\xE8de un niveau de s\xE9curit\xE9\
        \ basique non affaibli depuis son installation ;"
      translations:
        en:
          name: Level 3
          description: The Active Directory infrastructure does not appear to have
            been weakened from what default installation settings provide;
    - ref_id: level_4
      name: Niveau 4
      description: "L'annuaire Active Directory dispose d'un bon niveau de s\xE9curit\xE9\
        \ ;"
      translations:
        en:
          name: Level 4
          description: The Active Directory infrastructure exhibits an enhanced level
            of security and management;
    requirement_nodes:
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:intro
      assessable: false
      depth: 1
      name: Introduction
      translations:
        en:
          name: Introduction
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:intro_text
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:intro
      description: "L'annuaire Active Directory, centre n\xE9vralgique de la s\xE9\
        curit\xE9 des syst\xE8mes d'information Microsoft, est un \xE9l\xE9ment critique\
        \ permettant la gestion centralis\xE9e de comptes, de ressources et de permissions.\
        \ L'obtention de privil\xE8ges \xE9lev\xE9s sur cet annuaire entra\xEEne une\
        \ prise de contr\xF4le instantan\xE9e et compl\xE8te de toutes les ressources\
        \ ainsi administr\xE9es.\n\nL'analyse des modes op\xE9ratoires des attaques\
        \ r\xE9centes met en \xE9vidence une recrudescence du ciblage des annuaires\
        \ Active Directory, compte tenu de leur r\xF4le de pierre angulaire de la\
        \ plupart des syst\xE8mes d'information. En effet, l'attaquant ayant obtenu\
        \ des droits \xE9lev\xE9s sur l'annuaire peut alors d\xE9ployer une charge\
        \ malveillante sur l'ensemble du syst\xE8me d'information, notamment par GPO\
        \ ou en utilisant des connexions directes (`psexec`, `wmiexec`). Par cons\xE9\
        quent, le faible niveau de s\xE9curit\xE9 des annuaires met en danger les\
        \ syst\xE8mes d'information dans leur globalit\xE9 et fait porter un risque\
        \ syst\xE9mique aux organisations.\n\nLes observations de l'ANSSI font appara\xEE\
        tre un manque de maturit\xE9 critique et r\xE9current sur la s\xE9curit\xE9\
        \ des annuaires Active Directory. Le niveau de s\xE9curit\xE9 d\xE9cro\xEE\
        t ainsi de mani\xE8re importante en fonction du temps et au rythme de la manipulation\
        \ de ses objets ou des actions d'administration.\n\nEn r\xE9ponse \xE0 ce\
        \ risque croissant, l'ANSSI a d\xE9velopp\xE9 et met \xE0 disposition un recueil\
        \ de points de contr\xF4le, afin d'accompagner les chaines DSI et SSI dans\
        \ le suivi du niveau de s\xE9curit\xE9 des annuaires Active Directory. Ce\
        \ recueil a vocation \xE0 \xEAtre enrichi r\xE9guli\xE8rement en fonction\
        \ des travaux de recherche, des pratiques constat\xE9es en audit, et de l'analyse\
        \ des modes op\xE9ratoires adverses.\n\nChaque point de contr\xF4le vise \xE0\
        \ v\xE9rifier l'absence d'une pratique susceptible d'affaiblir le niveau de\
        \ s\xE9curit\xE9 et qui pourrait le cas \xE9ch\xE9ant \xEAtre utilis\xE9e\
        \ dans le cadre d'une attaque. En fonction des faiblesses trouv\xE9es, l'annuaire\
        \ Active Directory se voit affect\xE9 un niveau :\n\n* <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> L'annuaire Active Directory\
        \ pr\xE9sente des probl\xE8mes critiques de configuration qui mettent en danger\
        \ imm\xE9diat l'ensemble des ressources h\xE9berg\xE9es. Des actions correctrices\
        \ sont \xE0 prendre dans les plus brefs d\xE9lais ;\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> L'annuaire Active Directory pr\xE9\
        sente des lacunes de configuration et de gestion suffisantes pour mettre en\
        \ danger l'ensemble des ressources h\xE9berg\xE9es. Des actions correctrices\
        \ sont \xE0 prendre \xE0 court terme ;\n* <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> L'annuaire Active Directory poss\xE8\
        de un niveau de s\xE9curit\xE9 basique non affaibli depuis son installation\
        \ ;\n* <span style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255,\
        \ 255)\">4</span> L'annuaire Active Directory dispose d'un bon niveau de s\xE9\
        curit\xE9 ;\n* <span style=\"background-color:rgb(40, 167, 69);color:rgb(255,\
        \ 255, 255)\">5</span> L'annuaire Active Directory dispose d'un niveau de\
        \ s\xE9curit\xE9 \xE0 l'\xE9tat de l'art.\n\nPour obtenir un niveau, un annuaire\
        \ Active Directory doit passer avec succ\xE8s tous les points de contr\xF4\
        les des niveaux inf\xE9rieurs. Un annuaire de niveau <span style=\"background-color:rgb(40,\
        \ 167, 69);color:rgb(255, 255, 255)\">5</span> a pass\xE9 avec succ\xE8s tous\
        \ les points de contr\xF4le.\n\nChaque point de contr\xF4le d\xE9taill\xE9\
        \ pr\xE9sente les caract\xE9ristiques suivantes:\n\n* Titre du point de contr\xF4\
        le et niveau associ\xE9 ;\n* Identifiant du point de contr\xF4le ;\n* Description\
        \ de la vuln\xE9rabilit\xE9 ou de l'affaiblissement de s\xE9curit\xE9 induit\
        \ que l'on cherche \xE0 caract\xE9riser par le point de contr\xF4le ;\n* Recommandation\
        \ \xE0 appliquer pour valider le point de contr\xF4le et durcir la configuration\
        \ de l'annuaire.\n\nLorsqu'elles sont applicables, les documentations officielles\
        \ sont propos\xE9es pour approfondissement.\n\nD\xE9velopp\xE9 par l'ANSSI,\
        \ le service [ADS (Active Directory Security)](https://www.ssi.gouv.fr/actualite/le-service-active-directory-security-ads-accompagner-la-securisation-des-annuaires-active-directory-des-acteurs-critiques/)\
        \ met \xE0 disposition des op\xE9rateurs r\xE8glement\xE9s et de la sph\xE8\
        re publique une capacit\xE9 d'audit des annuaires Active Directory visant\
        \ \xE0 leur donner de la visibilit\xE9 sur le niveau de s\xE9curit\xE9 de\
        \ leur annuaire et \xE0 les accompagner dans son durcissement par l'application\
        \ progressive de mesures ad\xE9quates, avec un suivi dans le temps. Le service\
        \ ADS impl\xE9mente l'ensemble des points de contr\xF4le pr\xE9sent\xE9s dans\
        \ ce recueil."
      translations:
        en:
          description: 'Active Directory is a critical component of Microsoft-based
            information systems; it provides unified management features for user
            accounts, resources and access rights or permissions. Gaining high privileges
            in this context instantly grants full control over all resources that
            are managed through the Active Directory infrastructure.


            Recently observed adversary tactics shed light on regained interest for
            targeting Active Directory infrastructure, given their essential role
            in most information systems. Attackers who have gained high privileges
            may be able to deploy malware at scale throughout the whole network, leveraging
            GPOs or direct connections (`psexec`, `wmiexec`). Weak security controls
            in such environments pose a real systemic threat to the whole IT system
            in organizations.


            ANSSI regularly meets a critical lack of cyber security maturity when
            applied to Active Directory environments. The observed security level
            weakens significantly with time, loose day-to-day operations and management.


            To address this growing risk, ANSSI has implemented and publishes an assessment
            checklist and corrective measures. This is intended for CTOs and CISOs,
            helping them track the actual security level of their Active Directory
            infrastructure. This collection will be improved upon on a regular basis,
            benefiting from ongoing research, observed practical constraints and solutions
            during audits, as well as threat intelligence.


            Each assessment item aims at ensuring no dangerous practices either pose
            a threat to the infrastructure or may have already been exploited by an
            attacker. Based on found weaknesses, each Active Directory forest is given
            a score, or level:


            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Critical weaknesses and misconfigurations pose an immediate threat to
            all hosted resources. Corrective actions should be taken as soon as possible;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            Configuration and management weaknesses put all hosted resources at risk
            of a short-term compromise. Corrective actions should be carefully planned
            and implemented shortly;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            The Active Directory infrastructure does not appear to have been weakened
            from what default installation settings provide;

            * <span style="background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)">4</span>
            The Active Directory infrastructure exhibits an enhanced level of security
            and management;

            * <span style="background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)">5</span>
            The Active Directory infrastructure correctly implements the latest state-of-the-art
            administrative model and security features.


            To gain any given level, an Active Directory forest must pass all of the
            lower assessment items. A level 5 forest successfully passed the full
            assessment checklist.


            Each assessment item provides the following guidance information:


            * Assigned security level and item title;

            * Item identifier;

            * A detailed description of the vulnerability or weakness assessed during
            the audit;

            * Resolution guidance and references to pass the current item and properly
            harden the Active Directory infrastructure.


            Official documentation resources are provided when applicable .


            Built upon years of internal research and experience, the [ADS (Active
            Directory Security)](https://www.ssi.gouv.fr/actualite/le-service-active-directory-security-ads-accompagner-la-securisation-des-annuaires-active-directory-des-acteurs-critiques/)
            assessment service provides regulated infrastructure operators and the
            public sector with a fully fledged Active Directory audit capability.
            It aims at restoring visibility and maturity with respect to actual cyber
            security exposure of their environments. Progressive, practical measures
            and agency support are intended to help improve security and track changes
            in the long run. The agency''s ADS assessment service implements every
            item listed herein.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:about_assessment_item_list
      assessable: false
      depth: 1
      name: "A propos de la Liste des points de contr\xF4le"
      translations:
        en:
          name: About Assessment Item List
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:about_assessment_item_list_text
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:about_assessment_item_list
      description: "Un point de contr\xF4le peut appara\xEEtre pour plusieurs niveaux\
        \ de s\xE9curit\xE9 d'un Active directory. Plus le niveau vis\xE9 est \xE9\
        lev\xE9, plus ses crit\xE8res deviennent stricts. \xC0 ce jour, seuls les\
        \ points permettant la validation des niveaux de s\xE9curit\xE9 1 \xE0 3 sont\
        \ publi\xE9s. Les points de contr\xF4le de niveaux sup\xE9rieurs seront publi\xE9\
        s lors de mises \xE0 jour futures de ce document.\n\nLa liste suivante permet\
        \ de naviguer dans les points de contr\xF4le et de consulter les recommandations\
        \ associ\xE9es.\n\nL'historique des modifications est [disponible ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/changelog)."
      translations:
        en:
          description: 'An assessment item may appear at multiple Active Directory
            security levels. The higher the level, the stricter its rules. Only items
            from security levels 1 through 3 are published so far. Future updates
            of this document will bring items from higher levels.


            This list below helps navigate the Active Directory security assessment
            checklist and obtain relevant mitigation guidance.


            Modification history is [available here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/changelog).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      assessable: false
      depth: 1
      name: "Liste des points de contr\xF4le"
      translations:
        en:
          name: Assessment Item List
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_adcs_control-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_adcs_control-l1
      name: "Permissions dangereuses sur les conteneurs de certificats (chemins de\
        \ contr\xF4le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les conteneurs de certificats. Ces permissions permettent d'ajouter\
        \ une autorit\xE9 de certification malveillante et donc notamment d'usurper\
        \ des utilisateurs ou des services.\n\nL\xE9gende: Contr\xF4le fort et imm\xE9\
        diat, Contr\xF4le indirect, Contr\xF4le indirect faible\n\n# Permissions dangereuses\
        \ et chemins de contr\xF4le\n\nDes permissions dangereuses permettent la prise\
        \ de contr\xF4le d'un objet cible, sur lequel ces permissions sont positionn\xE9\
        es, par l'\xE9criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation\
        \ de droits privil\xE9gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9\
        cifiques.\n\nUne fois l'objet ma\xEEtris\xE9 par un attaquant, ce dernier\
        \ peut alors poursuivre un chemin de prise de contr\xF4le d'autres objets\
        \ qui, par transitivit\xE9, peut mener \xE0 des \xE9l\xE9vations de privil\xE8\
        ges et \xE0 la compromission de l'annuaire Active Directory tout entier. L'encha\xEE\
        nement de permissions dangereuses ainsi exploit\xE9es s'appelle un ***chemin\
        \ de contr\xF4le** , ou un chemin d'attaque* (Un chemin de contr\xF4le est\
        \ compos\xE9 d'un ensemble de relations de contr\xF4le direct, o\xF9 chaque\
        \ relation traduit la ma\xEEtrise d'un objet sur un autre au travers d'une\
        \ propri\xE9t\xE9 particuli\xE8re.).\n\nAinsi, les chemins de contr\xF4le\
        \ repr\xE9sentent des moyens pour un attaquant d'atteindre des cibles, et\
        \ permettent d'identifier des d\xE9viances dans la gestion du domaine, de\
        \ valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des\
        \ cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler des moyens\
        \ de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Visualisation\n\nIl est possible de visualiser les chemins de contr\xF4\
        le qui permettent la compromission totale de la for\xEAt via l'onglet d\xE9\
        di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nLors de l'installation d'un serveur de PKI\
        \ Microsoft, l'utilisateur r\xE9alisant l'installation se voit automatiquement\
        \ d\xE9l\xE9guer des droits sur ces conteneurs.\n\nIl est recommand\xE9 d'enlever\
        \ les permissions dangereuses sur ces conteneurs de certificats afin de revenir\
        \ \xE0 un \xE9tat par d\xE9faut. La correction est g\xE9n\xE9ralement effectu\xE9\
        e \xE0 l'aide des consoles `adsiedit.msc` ou de l'utilitaire `ldp`.\n\n##\
        \ Contexte : chemins de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9\
        \ d'un ensemble de relations de contr\xF4le direct, o\xF9 chaque relation\
        \ traduit la ma\xEEtrise d'un objet sur un autre au travers d'une propri\xE9\
        t\xE9 particuli\xE8re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des\
        \ moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier\
        \ des d\xE9viances dans la gestion du domaine, de valider l'application d'un\
        \ p\xE9rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais\
        \ \xE9galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un\
        \ attaquant apr\xE8s une compromission.\n\n## Limites\n\nCertains chemins\
        \ de contr\xF4le peuvent disposer de correctifs qui les rendent non exploitables.\
        \ Ces cas imposent g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs\
        \ de domaine au m\xEAme niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9\
        s dangereuses peuvent parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre\
        \ de registre ou dsHeuristics. Il est donc toujours recommand\xE9 de nettoyer\
        \ les permissions concern\xE9es de l'Active Directory pour pr\xE9venir une\
        \ r\xE9apparition du probl\xE8me.\n\nListe des correctifs sp\xE9cifiques connus\
        \ :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose certificate containers (attack path) (Level
            1)
          description: '# Vulnerability description


            Dangerous ACLs expose certificate containers. These permissions allow
            adding a malicious certificate authority, which allows an attacker to
            authenticate as arbitrary users or services.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            A user installing a Microsoft PKI server will have these permissions automatically
            delegated to these containers.


            Dangerous permissions on these containers should be removed to revert
            them to a default state. Fixing usually requires using `adsiedit.msc`
            or the `ldp` utility.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_adcs_template_control-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_adcs_template_control-l1
      name: "Permissions dangereuses sur les objets de mod\xE8les de certificats (chemins\
        \ de contr\xF4le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les objets de mod\xE8les de certificats (certificate templates).\n\
        \nLe contr\xF4le d'un mod\xE8le de certificat permet de faire g\xE9n\xE9rer\
        \ par l'autorit\xE9 de certification un certificat arbitraire. Il est par\
        \ exemple possible d'obtenir un certificat d'authentification par carte \xE0\
        \ puce pour n'importe quel utilisateur, et ainsi d'usurper son identit\xE9\
        .\n\nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4\
        le indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seuls les mod\xE8les publi\xE9\
        s par au moins un serveur Active Directory Certificate Services (AD CS) apparaissent\
        \ ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des mod\xE8les sont concern\xE9s.\n\n# Permissions\
        \ dangereuses et chemins de contr\xF4le\n\nDes permissions dangereuses permettent\
        \ la prise de contr\xF4le d'un objet cible, sur lequel ces permissions sont\
        \ positionn\xE9es, par l'\xE9criture de propri\xE9t\xE9s sensibles, par d\xE9\
        l\xE9gation de droits privil\xE9gi\xE9s ou par l'usage de fonctionnalit\xE9\
        s sp\xE9cifiques.\n\nUne fois l'objet ma\xEEtris\xE9 par un attaquant, ce\
        \ dernier peut alors poursuivre un chemin de prise de contr\xF4le d'autres\
        \ objets qui, par transitivit\xE9, peut mener \xE0 des \xE9l\xE9vations de\
        \ privil\xE8ges et \xE0 la compromission de l'annuaire Active Directory tout\
        \ entier. L'encha\xEEnement de permissions dangereuses ainsi exploit\xE9es\
        \ s'appelle un ***chemin de contr\xF4le** , ou un chemin d'attaque* (Un chemin\
        \ de contr\xF4le est compos\xE9 d'un ensemble de relations de contr\xF4le\
        \ direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet sur un autre\
        \ au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\nAinsi, les chemins\
        \ de contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre\
        \ des cibles, et permettent d'identifier des d\xE9viances dans la gestion\
        \ du domaine, de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9\
        \ autour des cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler\
        \ des moyens de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Visualisation\n\nIl est possible de visualiser les chemins de contr\xF4\
        le qui permettent la compromission totale de la for\xEAt via l'onglet d\xE9\
        di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl est recommand\xE9 d'enlever les permissions\
        \ dangereuses sur ces mod\xE8les de certificats afin de restaurer l'\xE9tat\
        \ par d\xE9faut. La correction est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide\
        \ de la console `adsiedit.msc`, `pkiview.msc` ou de l'utilitaire `ldp`.\n\n\
        ## Contexte : chemins de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9\
        \ d'un ensemble de relations de contr\xF4le direct, o\xF9 chaque relation\
        \ traduit la ma\xEEtrise d'un objet sur un autre au travers d'une propri\xE9\
        t\xE9 particuli\xE8re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des\
        \ moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier\
        \ des d\xE9viances dans la gestion du domaine, de valider l'application d'un\
        \ p\xE9rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais\
        \ \xE9galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un\
        \ attaquant apr\xE8s une compromission.\n\n## Limites\n\nCertains chemins\
        \ de contr\xF4le peuvent disposer de correctifs qui les rendent non exploitables.\
        \ Ces cas imposent g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs\
        \ de domaine au m\xEAme niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9\
        s dangereuses peuvent parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre\
        \ de registre ou dsHeuristics. Il est donc toujours recommand\xE9 de nettoyer\
        \ les permissions concern\xE9es de l'Active Directory pour pr\xE9venir une\
        \ r\xE9apparition du probl\xE8me.\n\nListe des correctifs sp\xE9cifiques connus\
        \ :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose certificate template objects (attack path) (Level
            1)
          description: '# Vulnerability description


            Dangerous ACLs expose certificate template objects.


            Controlling certificate templates allows one to have the certificate authority
            issue an arbitrary certificate. It becomes possible to obtain a smart
            card authentication certificate for any user, thus stealing his identity.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only the templates published by at least one ADCS
            server are processed ;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all templates are processed.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            Dangerous permissions on these containers should be removed to revert
            them to a default state. Fixing usually requires using `adsiedit.msc`,
            `pkiview.msc` or the `ldp` utility.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_adcs_template_control-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_adcs_template_control-l2
      name: "Permissions dangereuses sur les objets de mod\xE8les de certificats (chemins\
        \ de contr\xF4le) (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les objets de mod\xE8les de certificats (certificate templates).\n\
        \nLe contr\xF4le d'un mod\xE8le de certificat permet de faire g\xE9n\xE9rer\
        \ par l'autorit\xE9 de certification un certificat arbitraire. Il est par\
        \ exemple possible d'obtenir un certificat d'authentification par carte \xE0\
        \ puce pour n'importe quel utilisateur, et ainsi d'usurper son identit\xE9\
        .\n\nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4\
        le indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seuls les mod\xE8les publi\xE9\
        s par au moins un serveur Active Directory Certificate Services (AD CS) apparaissent\
        \ ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des mod\xE8les sont concern\xE9s.\n\n# Permissions\
        \ dangereuses et chemins de contr\xF4le\n\nDes permissions dangereuses permettent\
        \ la prise de contr\xF4le d'un objet cible, sur lequel ces permissions sont\
        \ positionn\xE9es, par l'\xE9criture de propri\xE9t\xE9s sensibles, par d\xE9\
        l\xE9gation de droits privil\xE9gi\xE9s ou par l'usage de fonctionnalit\xE9\
        s sp\xE9cifiques.\n\nUne fois l'objet ma\xEEtris\xE9 par un attaquant, ce\
        \ dernier peut alors poursuivre un chemin de prise de contr\xF4le d'autres\
        \ objets qui, par transitivit\xE9, peut mener \xE0 des \xE9l\xE9vations de\
        \ privil\xE8ges et \xE0 la compromission de l'annuaire Active Directory tout\
        \ entier. L'encha\xEEnement de permissions dangereuses ainsi exploit\xE9es\
        \ s'appelle un ***chemin de contr\xF4le** , ou un chemin d'attaque* (Un chemin\
        \ de contr\xF4le est compos\xE9 d'un ensemble de relations de contr\xF4le\
        \ direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet sur un autre\
        \ au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\nAinsi, les chemins\
        \ de contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre\
        \ des cibles, et permettent d'identifier des d\xE9viances dans la gestion\
        \ du domaine, de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9\
        \ autour des cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler\
        \ des moyens de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Visualisation\n\nIl est possible de visualiser les chemins de contr\xF4\
        le qui permettent la compromission totale de la for\xEAt via l'onglet d\xE9\
        di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl est recommand\xE9 d'enlever les permissions\
        \ dangereuses sur ces mod\xE8les de certificats afin de restaurer l'\xE9tat\
        \ par d\xE9faut. La correction est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide\
        \ de la console `adsiedit.msc`, `pkiview.msc` ou de l'utilitaire `ldp`.\n\n\
        ## Contexte : chemins de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9\
        \ d'un ensemble de relations de contr\xF4le direct, o\xF9 chaque relation\
        \ traduit la ma\xEEtrise d'un objet sur un autre au travers d'une propri\xE9\
        t\xE9 particuli\xE8re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des\
        \ moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier\
        \ des d\xE9viances dans la gestion du domaine, de valider l'application d'un\
        \ p\xE9rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais\
        \ \xE9galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un\
        \ attaquant apr\xE8s une compromission.\n\n## Limites\n\nCertains chemins\
        \ de contr\xF4le peuvent disposer de correctifs qui les rendent non exploitables.\
        \ Ces cas imposent g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs\
        \ de domaine au m\xEAme niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9\
        s dangereuses peuvent parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre\
        \ de registre ou dsHeuristics. Il est donc toujours recommand\xE9 de nettoyer\
        \ les permissions concern\xE9es de l'Active Directory pour pr\xE9venir une\
        \ r\xE9apparition du probl\xE8me.\n\nListe des correctifs sp\xE9cifiques connus\
        \ :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous ACLs expose certificate template objects (attack path) (Level
            2)
          description: '# Vulnerability description


            Dangerous ACLs expose certificate template objects.


            Controlling certificate templates allows one to have the certificate authority
            issue an arbitrary certificate. It becomes possible to obtain a smart
            card authentication certificate for any user, thus stealing his identity.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only the templates published by at least one ADCS
            server are processed ;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all templates are processed.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            Dangerous permissions on these containers should be removed to revert
            them to a default state. Fixing usually requires using `adsiedit.msc`,
            `pkiview.msc` or the `ldp` utility.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_adcs_template_auth_enroll_with_name-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_adcs_template_auth_enroll_with_name-l1
      name: "Permissions d'enr\xF4lement dangereuses sur des mod\xE8les de certificats\
        \ permettant l'authentification (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions d'enr\xF4\
        lement dangereuses existent vers des mod\xE8les de certificats utilisables\
        \ pour l'authentification Windows et dont les informations de nom peuvent\
        \ \xEAtre arbitrairement fournies par le demandeur.\n\nCes permissions permettent\
        \ de faire g\xE9n\xE9rer par l'autorit\xE9 de certification un certificat\
        \ avec un sujet arbitraire. Il est par exemple possible d'obtenir un certificat\
        \ d'authentification par carte \xE0 puce pour n'importe quel utilisateur,\
        \ et ainsi d'usurper son identit\xE9.\n\nSont list\xE9s ci-dessous les d\xE9\
        l\xE9gations accord\xE9es \xE0 des \xAB principals \xBB non privil\xE9gi\xE9\
        s permettant de demander ces certificats approuv\xE9s pour de l\u2019authentification\
        \ Windows et dont le mod\xE8le de certificat permet au demandeur de sp\xE9\
        cifier un sujet arbitraire.\n\nIl est \xE0 noter que si la d\xE9l\xE9gation\
        \ est accord\xE9e \xE0 un principal de type *Utilisateurs authentifi\xE9s*\
        \ (Authenticated Users), *Utilisateurs du domaine* (Domain Users) ou *Ordinateurs\
        \ du domaine* (Domain Computers) la for\xEAt peut \xEAtre instantan\xE9ment\
        \ compromise."
      annotation: "# Recommandation\n\nPlusieurs actions peuvent \xEAtre entreprises\
        \ pour corriger ce d\xE9faut de configuration. Celles-ci sont list\xE9es ci-dessous\
        \ par ordre d\u2019importance.\n\n## Cas 1 : la CA associ\xE9e n'est pas utilis\xE9\
        e pour de l'authentification Windows par carte \xE0 puce ou Radius\n\nLes\
        \ CA approuv\xE9es pour \xE9mettre des certifications r\xE9alisant de l\u2019\
        authentification Windows par certificats ou `PEAP/EAP-TLS` avec le service\
        \ Microsoft Radius IAS (Internet Authentication Service) doivent \xEAtre inscrites\
        \ dans le conteneur `NTAuthCertificates` ([https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store))\n\
        \nSi ce n\u2019est pas le cas, il est recommand\xE9 de supprimer la CA du\
        \ conteneur `NTAuthCertificates` \xE0 l'aide de `pkiview.msc` ou `certutil.exe`.\n\
        \nNotes :\n\n* Il ne faut pas confondre le conteneur `NTAuthCertificates`\
        \ avec le conteneur `Certification Authorities` qui indique les CA de confiance\n\
        * Supprimer un CA du conteneur `NTAuthCertificates` n\u2019affecte pas les\
        \ m\xE9canismes d\u2019authentification TLS (mutuelle ou non) utilis\xE9s\
        \ par exemple avec le protocole HTTPS\n\n## Cas 2 : le demandeur ne doit pas\
        \ fournir le sujet du certificat\n\nS\u2019il est accord\xE9 au demandeur\
        \ de pouvoir fournir un sujet arbitraire, l\u2019autorit\xE9 de certification\
        \ n\u2019effectuera aucune validation sur l\u2019identit\xE9 du sujet sp\xE9\
        cifi\xE9. G\xE9n\xE9ralement, le sujet d\u2019un certificat est construit\
        \ par rapport aux attributs issus de l\u2019Active Directory associ\xE9 au\
        \ compte du demandeur et \xE0 son authentification.\n\nIl est recommand\xE9\
        \ de ne pas permettre au demandeur de fournir un sujet arbitraire. Cette option\
        \ peut \xEAtre modifi\xE9e dans les propri\xE9t\xE9s des mod\xE8les de certificat\
        \ qui peuvent \xEAtre \xE9dit\xE9s \xE0 l'aide de la console `certtmpl.msc`.\n\
        \n## Cas 3: la d\xE9l\xE9gation des droits est trop large\n\nSi le mod\xE8\
        le de certificat doit autoriser le demandeur \xE0 sp\xE9cifier un sujet arbitraire\
        \ et que la CA doit \xEAtre approuv\xE9e pour de l\u2019authentification Windows,\
        \ une \xE9ventuelle d\xE9l\xE9gation ne doit \xEAtre effectu\xE9e que pour\
        \ un principal privil\xE9gi\xE9.\n\nSupprimer les droits d'enr\xF4lement dangereux\
        \ sur les mod\xE8les de certificat \xE0 l'aide de la console `pkiview.msc`,\
        \ `adsiedit.msc` ou de l'utilitaire `ldp.exe`.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous enrollment permission on authentication certificate templates
            (Level 1)
          description: "# Vulnerability description\n\nDangerous permissions exist\
            \ on certificate template usable for Windows authentication and for which\
            \ the user can supply the name information.\n\nThose permissions allows\
            \ one to have the certificate authority issue an arbitrary certificate.\
            \ It becomes possible to obtain a smart card authentication certificate\
            \ for any user, thus stealing his identity.\n\nAre display the delegations,\
            \ granted to unprivileged principals, to request certificates approved\
            \ for Windows authentication whose certificate template allows the requester\
            \ to provide an arbitrary subject.\n\nNote that if the delegation is granted\
            \ to *Authenticated Users* (Utilisateurs authentifi\xE9s), *Domain Users*\
            \ (Utilisateurs du domaine) or *Domain Computers* (Ordinateurs du domaine)\
            \ the forest can be instantly compromised."
          annotation: '# Recommended measure


            Several actions can be taken to fix that misconfiguration, they are listed
            below by priority.


            ## Option 1: the associated CA is not used for Windows smart card authentication
            or Radius


            CA approved for Windows certificate authentication or `PEAP/EAP-TLS` with
            Microsoft Radius IAS (Internet Authentication Service) must be published
            in the `NTAuthCertificates` container ([https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store))


            If not, it is recommended to remove the CA from the `NTAuthCertificates`
            container with `pkiview.msc` or `certutil.exe`.


            Notes :


            * Take care not to confuse the `NTAuthCertificates` container with the
            `Certification Authorities` one which is used for CA trust.

            * Removing a CA from the `NTAuthCertificates` container does not affect
            TLS authentication (mutual or not), for instance with the HTTPS protocol.


            ## Option 2: the requester should provide the certificate subject


            If the requester can provide an arbitrary subject, the CA will not perform
            any validation on the provided identity. Most of the time the certificate
            subject is built from the requester Active Directory attributes.


            It is recommended to prevent requester to provider arbitrary subjects.
            That option can be changed in the certificate template properties with
            `certtmpl.msc`.


            ## Option 3: the delegation is too large


            If the template must allow the requester to provide an arbitrary subject
            and the CA is approved for Windows authentication, delegations should
            only be granted to privileged principals.


            Remove the enroll rights on certificate templates with `pkiview.msc`,
            `adsiedit.msc` or `ldp.exe`.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_certificates_vuln-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_certificates_vuln-l1
      name: "Certificats faibles ou vuln\xE9rables (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nCertains certificats\
        \ poss\xE8dent des probl\xE8mes et ne doivent plus \xEAtre utilis\xE9s. Cette\
        \ vuln\xE9rabilit\xE9 peut appara\xEEtre aux niveaux <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span>, <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> et <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> selon le probl\xE8me rencontr\xE9\
        \ :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">1</span> Utilisation de DSA: le Digital Signature Algorithm (DSA),\
        \ est un algorithme de signature num\xE9rique standardis\xE9 par le NIST,\
        \ et fait partie de la sp\xE9cification Digital Signature Standard adopt\xE9\
        e en 1993 (FIPS 186). Le projet FIPS 186-5 (en cours de r\xE9daction) propose\
        \ la suppression de cet algorithme. Cette suppression interdira l'utilisation\
        \ de DSA pour g\xE9n\xE9rer des signatures num\xE9riques ;\n* <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> Taille\
        \ de cl\xE9 RSA tr\xE8s faible (< 1024): l'utilisation de modules inf\xE9\
        rieurs \xE0 1024 bits est consid\xE9r\xE9e comme insuffisante pour garantir\
        \ une s\xE9curit\xE9 pratique ;\n* <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> Cl\xE9 vuln\xE9rable \xE0 la\
        \ vuln\xE9rabilit\xE9 ROCA: cette vuln\xE9rabilit\xE9 permet de r\xE9cup\xE9\
        rer une cl\xE9 priv\xE9e \xE0 partir d'une cl\xE9 publique ;\n* <span style=\"\
        background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">2</span> Certificat\
        \ impossible \xE0 d\xE9coder: cela peut signifier que le certificat est dans\
        \ un format invalide, et n'est peut-\xEAtre pas utilis\xE9 ;\n* <span style=\"\
        background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)\">3</span> Taille de\
        \ cl\xE9 RSA faible (< 2048): le R\xE9f\xE9rentiel G\xE9n\xE9ral de S\xE9\
        curit\xE9 (RGS) recommande une taille minimale de 2048 bits pour une utilisation\
        \ ne devant pas d\xE9passer l'ann\xE9e 2030 et une taille minimale de 3072\
        \ bits pour une utilisation au-del\xE0 de 2030 ;\n* <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> Signature utilisant un algorithme\
        \ faible (diff\xE9rent de SHA2 ou de SHA3) : les algorithmes comme MD5 ou\
        \ SHA1 sont vuln\xE9rables aux collisions ;\n* <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> Exposant public RSA faible (< 65537)\
        \ : les calculs de chiffrement et de d\xE9chiffrement RSA font intervenir\
        \ deux autres donn\xE9es que le module, appel\xE9es exposant public et exposant\
        \ secret. Le R\xE9f\xE9rentiel G\xE9n\xE9ral de S\xE9curit\xE9 (RGS) recommande\
        \ d'employer des exposants publics sup\xE9rieurs \xE0 65536.\n\nUn individu\
        \ malveillant pourrait tenter d'exploiter l'une de ces vuln\xE9rabilit\xE9\
        s pour g\xE9n\xE9rer un certificat malveillant avec une signature valide,\
        \ lui permettant d'usurper l'identit\xE9 de n'importe quel utilisateur."
      annotation: "# Recommandation\n\nLes conteneurs de certificats d'une for\xEA\
        t peuvent \xEAtre \xE9dit\xE9s via l'outil `pkiview.msc`.\n\n## Cas des autorit\xE9\
        s de certifications valides\n\nIl est recommand\xE9 de r\xE9voquer les certificats\
        \ probl\xE9matiques et de les g\xE9n\xE9rer \xE0 nouveau. Les certificats\
        \ enfants doivent aussi \xEAtre g\xE9n\xE9r\xE9s \xE0 nouveau. Enfin, les\
        \ certificats expir\xE9s doivent \xEAtre purg\xE9s des conteneurs de confiance.\n\
        \nLors de la g\xE9n\xE9ration d'un nouveau certificat, il convient de s'assurer\
        \ que :\n\n* l'algorithme DSA n'est pas utilis\xE9 pour la signature du certificat\
        \ (privil\xE9gier RSA ou ECDSA) ;\n* la taille de la cl\xE9 RSA est d'au moins\
        \ 2048 bits et les exposants publics sup\xE9rieurs \xE0 65536 ;\n* la cl\xE9\
        \ RSA est g\xE9n\xE9r\xE9e \xE0 l'aide d'une biblioth\xE8que \xE0 jour (pour\
        \ \xE9viter les vuln\xE9rabilit\xE9s type ROCA).\n\n## Cas des autorit\xE9\
        s de certifications expir\xE9es\n\nSi le certificat est expir\xE9, il est\
        \ recommand\xE9 de le supprimer de la liste des autorit\xE9s reconnues de\
        \ l'Active Directory. Dans le cas d'une utilisation de signature de code,\
        \ l'autorit\xE9 de certification peut \xEAtre red\xE9ploy\xE9e par GPO."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Weak or vulnerable certificates (Level 1)
          description: '# Vulnerability description


            Some certificates are problematic and must not be used anymore. This vulnerability
            might appear on levels <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span>, <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> and <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> depending on the following issues:


            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Use of DSA algorithm: Digital Signature Algorithm (DSA), is a NIST standard
            signature algorithm, part of the 1993 Digital Signature Standard (FIPS
            186). The proposed FIPS 186-5 draft deprecates the use of DSA and will
            forbid its usage for digital signature purposes;

            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Very weak RSA key length (< 1024): using a modulus shorter than 1024 bits
            is considered insufficient to provide any meaningful security;

            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Key vulnerable to the ROCA vulnerability: this allows recovering the private
            key associated with a public key;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            Certificate impossible to parse: this suggests the stored certificate
            is either stored in an invalid format and probably unused;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            Weak RSA key length (< 2048): the French General Security Regulation (RGS)
            mandates a minimum key size of 2048 bits for cryptographic usage before
            2030, and 3072 bits for usage after 2030;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            Weak signature algorithm (not SHA2 or SHA3): algorithms such as MD5 or
            SHA1 are vulnerable to collision attacks;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            Weak RSA exponent (< 65537): RSA encryption and decryption operations
            involve two other parameters than a modulus: a public exponent and a secret
            exponent. The French General Security Regulation (RGS) mandates usage
            of public exponents greater than 65536.'
          annotation: '# Recommended measure


            Certificate containers may be edited with `pkiview.msc`.


            ## Case 1: valid, non-expired certification authorities


            Problematic certificates must be revoked and reissued. Children certificates
            must also be reissued. Expired certificates should also be purged from
            trusted certificate stores.


            When issuing a new certificate, the following requirements should be met:


            * DSA algorithm is not used for certificate signature (RSA or ECDSA should
            be preferred);

            * RSA key length is greater or equal to 2048 bits and public exponents
            are greater than 65536;

            * an up-to-date library is used to generate the RSA key (to prevent currently
            known weaknesses, such as ROCA).


            ## Case 2: expired certification authorities


            If the certificate is expired, it should be purged from the trusted authorities
            list of the Active Directory. For binary code signature usage, the certificate
            authority can be redeployed locally through GPO management.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_certificates_vuln-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_certificates_vuln-l2
      name: "Certificats faibles ou vuln\xE9rables (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nCertains certificats\
        \ poss\xE8dent des probl\xE8mes et ne doivent plus \xEAtre utilis\xE9s. Cette\
        \ vuln\xE9rabilit\xE9 peut appara\xEEtre aux niveaux <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span>, <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> et <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> selon le probl\xE8me rencontr\xE9\
        \ :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">1</span> Utilisation de DSA: le Digital Signature Algorithm (DSA),\
        \ est un algorithme de signature num\xE9rique standardis\xE9 par le NIST,\
        \ et fait partie de la sp\xE9cification Digital Signature Standard adopt\xE9\
        e en 1993 (FIPS 186). Le projet FIPS 186-5 (en cours de r\xE9daction) propose\
        \ la suppression de cet algorithme. Cette suppression interdira l'utilisation\
        \ de DSA pour g\xE9n\xE9rer des signatures num\xE9riques ;\n* <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> Taille\
        \ de cl\xE9 RSA tr\xE8s faible (< 1024): l'utilisation de modules inf\xE9\
        rieurs \xE0 1024 bits est consid\xE9r\xE9e comme insuffisante pour garantir\
        \ une s\xE9curit\xE9 pratique ;\n* <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> Cl\xE9 vuln\xE9rable \xE0 la\
        \ vuln\xE9rabilit\xE9 ROCA: cette vuln\xE9rabilit\xE9 permet de r\xE9cup\xE9\
        rer une cl\xE9 priv\xE9e \xE0 partir d'une cl\xE9 publique ;\n* <span style=\"\
        background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">2</span> Certificat\
        \ impossible \xE0 d\xE9coder: cela peut signifier que le certificat est dans\
        \ un format invalide, et n'est peut-\xEAtre pas utilis\xE9 ;\n* <span style=\"\
        background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)\">3</span> Taille de\
        \ cl\xE9 RSA faible (< 2048): le R\xE9f\xE9rentiel G\xE9n\xE9ral de S\xE9\
        curit\xE9 (RGS) recommande une taille minimale de 2048 bits pour une utilisation\
        \ ne devant pas d\xE9passer l'ann\xE9e 2030 et une taille minimale de 3072\
        \ bits pour une utilisation au-del\xE0 de 2030 ;\n* <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> Signature utilisant un algorithme\
        \ faible (diff\xE9rent de SHA2 ou de SHA3) : les algorithmes comme MD5 ou\
        \ SHA1 sont vuln\xE9rables aux collisions ;\n* <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> Exposant public RSA faible (< 65537)\
        \ : les calculs de chiffrement et de d\xE9chiffrement RSA font intervenir\
        \ deux autres donn\xE9es que le module, appel\xE9es exposant public et exposant\
        \ secret. Le R\xE9f\xE9rentiel G\xE9n\xE9ral de S\xE9curit\xE9 (RGS) recommande\
        \ d'employer des exposants publics sup\xE9rieurs \xE0 65536.\n\nUn individu\
        \ malveillant pourrait tenter d'exploiter l'une de ces vuln\xE9rabilit\xE9\
        s pour g\xE9n\xE9rer un certificat malveillant avec une signature valide,\
        \ lui permettant d'usurper l'identit\xE9 de n'importe quel utilisateur."
      annotation: "# Recommandation\n\nLes conteneurs de certificats d'une for\xEA\
        t peuvent \xEAtre \xE9dit\xE9s via l'outil `pkiview.msc`.\n\n## Cas des autorit\xE9\
        s de certifications valides\n\nIl est recommand\xE9 de r\xE9voquer les certificats\
        \ probl\xE9matiques et de les g\xE9n\xE9rer \xE0 nouveau. Les certificats\
        \ enfants doivent aussi \xEAtre g\xE9n\xE9r\xE9s \xE0 nouveau. Enfin, les\
        \ certificats expir\xE9s doivent \xEAtre purg\xE9s des conteneurs de confiance.\n\
        \nLors de la g\xE9n\xE9ration d'un nouveau certificat, il convient de s'assurer\
        \ que :\n\n* l'algorithme DSA n'est pas utilis\xE9 pour la signature du certificat\
        \ (privil\xE9gier RSA ou ECDSA) ;\n* la taille de la cl\xE9 RSA est d'au moins\
        \ 2048 bits et les exposants publics sup\xE9rieurs \xE0 65536 ;\n* la cl\xE9\
        \ RSA est g\xE9n\xE9r\xE9e \xE0 l'aide d'une biblioth\xE8que \xE0 jour (pour\
        \ \xE9viter les vuln\xE9rabilit\xE9s type ROCA).\n\n## Cas des autorit\xE9\
        s de certifications expir\xE9es\n\nSi le certificat est expir\xE9, il est\
        \ recommand\xE9 de le supprimer de la liste des autorit\xE9s reconnues de\
        \ l'Active Directory. Dans le cas d'une utilisation de signature de code,\
        \ l'autorit\xE9 de certification peut \xEAtre red\xE9ploy\xE9e par GPO."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Weak or vulnerable certificates (Level 2)
          description: '# Vulnerability description


            Some certificates are problematic and must not be used anymore. This vulnerability
            might appear on levels <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span>, <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> and <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> depending on the following issues:


            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Use of DSA algorithm: Digital Signature Algorithm (DSA), is a NIST standard
            signature algorithm, part of the 1993 Digital Signature Standard (FIPS
            186). The proposed FIPS 186-5 draft deprecates the use of DSA and will
            forbid its usage for digital signature purposes;

            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Very weak RSA key length (< 1024): using a modulus shorter than 1024 bits
            is considered insufficient to provide any meaningful security;

            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Key vulnerable to the ROCA vulnerability: this allows recovering the private
            key associated with a public key;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            Certificate impossible to parse: this suggests the stored certificate
            is either stored in an invalid format and probably unused;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            Weak RSA key length (< 2048): the French General Security Regulation (RGS)
            mandates a minimum key size of 2048 bits for cryptographic usage before
            2030, and 3072 bits for usage after 2030;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            Weak signature algorithm (not SHA2 or SHA3): algorithms such as MD5 or
            SHA1 are vulnerable to collision attacks;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            Weak RSA exponent (< 65537): RSA encryption and decryption operations
            involve two other parameters than a modulus: a public exponent and a secret
            exponent. The French General Security Regulation (RGS) mandates usage
            of public exponents greater than 65536.'
          annotation: '# Recommended measure


            Certificate containers may be edited with `pkiview.msc`.


            ## Case 1: valid, non-expired certification authorities


            Problematic certificates must be revoked and reissued. Children certificates
            must also be reissued. Expired certificates should also be purged from
            trusted certificate stores.


            When issuing a new certificate, the following requirements should be met:


            * DSA algorithm is not used for certificate signature (RSA or ECDSA should
            be preferred);

            * RSA key length is greater or equal to 2048 bits and public exponents
            are greater than 65536;

            * an up-to-date library is used to generate the RSA key (to prevent currently
            known weaknesses, such as ROCA).


            ## Case 2: expired certification authorities


            If the certificate is expired, it should be purged from the trusted authorities
            list of the Active Directory. For binary code signature usage, the certificate
            authority can be redeployed locally through GPO management.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_certificates_vuln-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_certificates_vuln-l3
      name: "Certificats faibles ou vuln\xE9rables (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nCertains certificats\
        \ poss\xE8dent des probl\xE8mes et ne doivent plus \xEAtre utilis\xE9s. Cette\
        \ vuln\xE9rabilit\xE9 peut appara\xEEtre aux niveaux <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span>, <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> et <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> selon le probl\xE8me rencontr\xE9\
        \ :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">1</span> Utilisation de DSA: le Digital Signature Algorithm (DSA),\
        \ est un algorithme de signature num\xE9rique standardis\xE9 par le NIST,\
        \ et fait partie de la sp\xE9cification Digital Signature Standard adopt\xE9\
        e en 1993 (FIPS 186). Le projet FIPS 186-5 (en cours de r\xE9daction) propose\
        \ la suppression de cet algorithme. Cette suppression interdira l'utilisation\
        \ de DSA pour g\xE9n\xE9rer des signatures num\xE9riques ;\n* <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> Taille\
        \ de cl\xE9 RSA tr\xE8s faible (< 1024): l'utilisation de modules inf\xE9\
        rieurs \xE0 1024 bits est consid\xE9r\xE9e comme insuffisante pour garantir\
        \ une s\xE9curit\xE9 pratique ;\n* <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> Cl\xE9 vuln\xE9rable \xE0 la\
        \ vuln\xE9rabilit\xE9 ROCA: cette vuln\xE9rabilit\xE9 permet de r\xE9cup\xE9\
        rer une cl\xE9 priv\xE9e \xE0 partir d'une cl\xE9 publique ;\n* <span style=\"\
        background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">2</span> Certificat\
        \ impossible \xE0 d\xE9coder: cela peut signifier que le certificat est dans\
        \ un format invalide, et n'est peut-\xEAtre pas utilis\xE9 ;\n* <span style=\"\
        background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)\">3</span> Taille de\
        \ cl\xE9 RSA faible (< 2048): le R\xE9f\xE9rentiel G\xE9n\xE9ral de S\xE9\
        curit\xE9 (RGS) recommande une taille minimale de 2048 bits pour une utilisation\
        \ ne devant pas d\xE9passer l'ann\xE9e 2030 et une taille minimale de 3072\
        \ bits pour une utilisation au-del\xE0 de 2030 ;\n* <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> Signature utilisant un algorithme\
        \ faible (diff\xE9rent de SHA2 ou de SHA3) : les algorithmes comme MD5 ou\
        \ SHA1 sont vuln\xE9rables aux collisions ;\n* <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> Exposant public RSA faible (< 65537)\
        \ : les calculs de chiffrement et de d\xE9chiffrement RSA font intervenir\
        \ deux autres donn\xE9es que le module, appel\xE9es exposant public et exposant\
        \ secret. Le R\xE9f\xE9rentiel G\xE9n\xE9ral de S\xE9curit\xE9 (RGS) recommande\
        \ d'employer des exposants publics sup\xE9rieurs \xE0 65536.\n\nUn individu\
        \ malveillant pourrait tenter d'exploiter l'une de ces vuln\xE9rabilit\xE9\
        s pour g\xE9n\xE9rer un certificat malveillant avec une signature valide,\
        \ lui permettant d'usurper l'identit\xE9 de n'importe quel utilisateur."
      annotation: "# Recommandation\n\nLes conteneurs de certificats d'une for\xEA\
        t peuvent \xEAtre \xE9dit\xE9s via l'outil `pkiview.msc`.\n\n## Cas des autorit\xE9\
        s de certifications valides\n\nIl est recommand\xE9 de r\xE9voquer les certificats\
        \ probl\xE9matiques et de les g\xE9n\xE9rer \xE0 nouveau. Les certificats\
        \ enfants doivent aussi \xEAtre g\xE9n\xE9r\xE9s \xE0 nouveau. Enfin, les\
        \ certificats expir\xE9s doivent \xEAtre purg\xE9s des conteneurs de confiance.\n\
        \nLors de la g\xE9n\xE9ration d'un nouveau certificat, il convient de s'assurer\
        \ que :\n\n* l'algorithme DSA n'est pas utilis\xE9 pour la signature du certificat\
        \ (privil\xE9gier RSA ou ECDSA) ;\n* la taille de la cl\xE9 RSA est d'au moins\
        \ 2048 bits et les exposants publics sup\xE9rieurs \xE0 65536 ;\n* la cl\xE9\
        \ RSA est g\xE9n\xE9r\xE9e \xE0 l'aide d'une biblioth\xE8que \xE0 jour (pour\
        \ \xE9viter les vuln\xE9rabilit\xE9s type ROCA).\n\n## Cas des autorit\xE9\
        s de certifications expir\xE9es\n\nSi le certificat est expir\xE9, il est\
        \ recommand\xE9 de le supprimer de la liste des autorit\xE9s reconnues de\
        \ l'Active Directory. Dans le cas d'une utilisation de signature de code,\
        \ l'autorit\xE9 de certification peut \xEAtre red\xE9ploy\xE9e par GPO."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Weak or vulnerable certificates (Level 3)
          description: '# Vulnerability description


            Some certificates are problematic and must not be used anymore. This vulnerability
            might appear on levels <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span>, <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> and <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> depending on the following issues:


            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Use of DSA algorithm: Digital Signature Algorithm (DSA), is a NIST standard
            signature algorithm, part of the 1993 Digital Signature Standard (FIPS
            186). The proposed FIPS 186-5 draft deprecates the use of DSA and will
            forbid its usage for digital signature purposes;

            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Very weak RSA key length (< 1024): using a modulus shorter than 1024 bits
            is considered insufficient to provide any meaningful security;

            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            Key vulnerable to the ROCA vulnerability: this allows recovering the private
            key associated with a public key;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            Certificate impossible to parse: this suggests the stored certificate
            is either stored in an invalid format and probably unused;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            Weak RSA key length (< 2048): the French General Security Regulation (RGS)
            mandates a minimum key size of 2048 bits for cryptographic usage before
            2030, and 3072 bits for usage after 2030;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            Weak signature algorithm (not SHA2 or SHA3): algorithms such as MD5 or
            SHA1 are vulnerable to collision attacks;

            * <span style="background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)">3</span>
            Weak RSA exponent (< 65537): RSA encryption and decryption operations
            involve two other parameters than a modulus: a public exponent and a secret
            exponent. The French General Security Regulation (RGS) mandates usage
            of public exponents greater than 65536.'
          annotation: '# Recommended measure


            Certificate containers may be edited with `pkiview.msc`.


            ## Case 1: valid, non-expired certification authorities


            Problematic certificates must be revoked and reissued. Children certificates
            must also be reissued. Expired certificates should also be purged from
            trusted certificate stores.


            When issuing a new certificate, the following requirements should be met:


            * DSA algorithm is not used for certificate signature (RSA or ECDSA should
            be preferred);

            * RSA key length is greater or equal to 2048 bits and public exponents
            are greater than 65536;

            * an up-to-date library is used to generate the RSA key (to prevent currently
            known weaknesses, such as ROCA).


            ## Case 2: expired certification authorities


            If the certificate is expired, it should be purged from the trusted authorities
            list of the Active Directory. For binary code signature usage, the certificate
            authority can be redeployed locally through GPO management.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_critical_objects-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_critical_objects-l1
      name: Objets critiques non disponibles (Niveau 1)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nCertaines informations\
        \ n\xE9cessaires \xE0 la g\xE9n\xE9ration de ce rapport ne sont pas disponibles.\n\
        \nPour pouvoir traiter correctement les annuaires Active Directory, le service\
        \ ADS a besoin d'informations sur certains objets, en particulier :\n\n* l'\
        \ `adminSDHolder`;\n* les comptes *KRBTGT* (KRBTGT) (krbtgt)  ;\n* les comptes\
        \ *Administrateur* (Administrator) (administrateur)  ;\n* les groupes *Administrateurs\
        \ du domaine* (Domain Admins) (admins du domaine)  ;\n* les groupes *Administrateurs\
        \ du sch\xE9ma* (Schema Admins) (administrateurs du sch\xE9ma) et *Administrateurs\
        \ de l'entreprise* (Enterprise Admins) (adminsitrateurs d'entreprise).\n\n\
        Des modifications de droits ont \xE9t\xE9 effectu\xE9es sur l'annuaire, ce\
        \ qui a emp\xEAch\xE9 l'utilisateur ayant effectu\xE9 le relev\xE9 de voir\
        \ les objets susmentionn\xE9s. Si le relev\xE9 a \xE9t\xE9 effectu\xE9 directement\
        \ sur un contr\xF4leur de domaine, il faudra peut-\xEAtre lancer ORADAD depuis\
        \ un shell \xE9lev\xE9 pour \xE9viter le filtrage du jeton par l'UAC.\n\n\
        Note : ce point de contr\xF4le ne r\xE9v\xE8le pas de probl\xE8me de configuration\
        \ ou de vuln\xE9rabilit\xE9, mais peut fausser l'analyse."
      annotation: "# Recommandation\n\nIl est recommand\xE9 d'effectuer un nouveau\
        \ relev\xE9 en utilisant un compte avec un plus haut niveau de privil\xE8\
        ges et depuis un poste d'administration s'il s'agit d'un compte d'administration."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Critical objects unavailable (Level 1)
          description: "# Vulnerability description\n\nIn order to accurately process\
            \ Active Directory forests, this tool needs information about some objects,\
            \ including:\n\n* `adminSDHolder`\n* *KRBTGT* (KRBTGT) accounts (krbtgt)\n\
            * *Administrator* (Administrateur) accounts (administrator)\n* *Domain\
            \ Admins* (Administrateurs du domaine) groups (domain admins)\n* *Schema\
            \ Admins* (Administrateurs du sch\xE9ma) (schema admins) and *Enterprise\
            \ Admins* (Administrateurs de l'entreprise) (enterprise administrators)\
            \ groups\n\nWith some of these objects unreadable, analysis cannot be\
            \ completed. The following accounts are not available:\n\nPermissions\
            \ have been changed on objects of this directory, which make the aforementioned\
            \ data unreadable for the user account with which ORADAD was executed.\
            \ When ORADAD is run on a domain controller, using an elevated shell might\
            \ be necessary to prevent token filtering by the UAC mechanism.\n\nNB:\
            \ This item does not indicate a misconfiguration or vulnerability, but\
            \ rather denotes modifications made to access control lists."
          annotation: '# Recommended measure


            Access rights modifications in Active Directory have prevented the user
            who retrieved information from the forest to see the aforementioned objects.


            It is advised to restart the collection tool from the beginning using
            a more privileged account. It may be necessary to perform the dump using
            Domain Admin privilege.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dc_inconsistent_uac-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dc_inconsistent_uac-l1
      name: "Contr\xF4leurs de domaine incoh\xE9rents (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nCertains contr\xF4\
        leurs de domaine de la for\xEAt poss\xE8dent des attributs dans un \xE9tat\
        \ incoh\xE9rent. Ces incoh\xE9rences peuvent \xEAtre symptomatiques d'une\
        \ erreur de configuration (manuelle ou par un logiciel) ou de traces de malveillance."
      annotation: "# Recommandation\n\nChaque contr\xF4leur de domaine doit poss\xE9\
        der les caract\xE9ristiques suivantes :\n\n* l'attribut `userAccountControl`\
        \ de l'objet machine d'un contr\xF4leur de domaine doit contenir <code style=\"\
        background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)\">SERVER_TRUST_ACCOUNT</code>\
        \ et <code style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)\"\
        >TRUSTED_FOR_DELEGATION</code>;\n* l'attribut `userAccountControl` de l'objet\
        \ machine d'un RODC doit contenir <code style=\"background-color:rgb(0, 123,\
        \ 255);color:rgb(255, 255, 255)\">PARTIAL_SECRETS_ACCOUNT</code>, <code style=\"\
        background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)\">TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION</code>\
        \ et <code style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)\"\
        >WORKSTATION_TRUST_ACCOUNT</code>;\n* un objet de type `server` doit exister\
        \ dans la partition de configuration et avoir un attribut `serverReference`\
        \ portant le DN du compte d'ordinateur:\n* l'objet `server` doit avoir un\
        \ objet fils `NTDS Settings` de type `nTDSDSA` (ou `nTDSDSARO` si c'est un\
        \ contr\xF4leur de domaine en lecture seule).\n\nLa correction est g\xE9n\xE9\
        ralement effectu\xE9e \xE0 l'aide de l'utilitaire `ldp`.\n\nNote : certains\
        \ \xE9diteurs cr\xE9ent pour leurs produits des configurations de ce type.\
        \ C'est notamment le cas pour l'\xE9diteur Riverbed."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Domain controllers in inconsistent state (Level 1)
          description: '# Vulnerability description


            Some domain controllers in the forest have inconsistent attributes. Inconsistencies
            can either occur upon manual or software-induced misconfiguration. They
            could also reveal malicious activity.'
          annotation: '# Recommended measure


            "Writable" domain controllers must have the following setup:


            * The `userAccountControl` attribute of their computer object must have
            the <code style="background-color:rgb(0, 123, 255);color:rgb(255, 255,
            255)">SERVER_TRUST_ACCOUNT</code> and <code style="background-color:rgb(0,
            123, 255);color:rgb(255, 255, 255)">TRUSTED_FOR_DELEGATION</code> flags
            set;

            * An object of type `server` must exist in the configuration partition
            and have a `serverReference` attribute containing the computer account
            DN;

            * Their `server` object must have a child `NTDS Settings` object of type
            `nTDSDSA`.


            Read-Only Domain Controllers (RODC) must have the following setup:


            * The `userAccountControl` attribute of their computer object must have
            the <code style="background-color:rgb(0, 123, 255);color:rgb(255, 255,
            255)">PARTIAL_SECRETS_ACCOUNT</code>, <code style="background-color:rgb(0,
            123, 255);color:rgb(255, 255, 255)">TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION</code>
            and <code style="background-color:rgb(0, 123, 255);color:rgb(255, 255,
            255)">WORKSTATION_TRUST_ACCOUNT</code> flags set;

            * An object of type `server` must exist in the configuration partition
            and have a `serverReference` attribute containing the computer account
            DN;

            * Their `server` object must have a child `NTDS Settings` object of type
            `nTDSDSARO`.


            This fix is usually applied through the `ldp` utility.


            Note: some publishers may introduce such deviations when installing their
            products. Riverbed is such a known case.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_delegation_a2d2-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_delegation_a2d2-l1
      name: "D\xE9l\xE9gation d'authentification contrainte vers un service d'un contr\xF4\
        leur de domaine (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes poss\xE8\
        dent des d\xE9l\xE9gations d'authentification contraintes vers un service\
        \ d'un contr\xF4leur de domaine. Elles permettent au compte d'\xE9lever ses\
        \ privil\xE8ges aupr\xE8s du contr\xF4leur de domaine."
      annotation: "# Recommandation\n\nLa d\xE9l\xE9gation d'authentification contrainte\
        \ permet \xE0 un compte de s'authentifier aupr\xE8s d'un service Kerberos\
        \ avec l'identit\xE9 d'un autre utilisateur (s'\xE9tant pr\xE9alablement authentifi\xE9\
        \ aupr\xE8s de ce compte). Si cette d\xE9l\xE9gation est autoris\xE9e vers\
        \ une ressource privil\xE9gi\xE9e (notamment un service pr\xE9sent sur un\
        \ contr\xF4leur de domaine), elle permet au compte d'\xE9lever ses privil\xE8\
        ges et de compromettre la for\xEAt.\n\nLa d\xE9l\xE9gation d'authentification\
        \ contrainte vers un service d'un contr\xF4leur de domaine ne doit pas \xEA\
        tre utilis\xE9e.\n\nPour les comptes concern\xE9s, il faut supprimer dans\
        \ l'attribut `msDS-AllowedToDelegateTo` tous les Service Principal Name (SPN)\
        \ r\xE9f\xE9ren\xE7ant les contr\xF4leurs de domaine. Cette op\xE9ration peut\
        \ \xEAtre effectu\xE9e directement \xE0 partir de l'onglet \xAB D\xE9l\xE9\
        gation \xBB de la console de gestion des utilisateurs et ordinateurs."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Constrained authentication delegation to a domain controller service
            (Level 1)
          description: '# Vulnerability description


            Some accounts have constrained authentication delegations to the services
            of domain controllers. These grant the subject account the ability to
            elevate its privileges on the domain controller.'
          annotation: '# Recommended measure


            Constrained authentication delegation allows an account to authenticate
            to a Kerberos service with the identity of a third-party user who has
            authenticated to that account. If such a delegation is authorized to a
            privileged resource (including domain controllers), it allows that account
            to elevate privileges and compromise the forest.


            Constrained authentication delegation to any domain controller service
            must not be allowed.


            For each of the aforementioned accounts, all Service Principal Names (SPNs)
            referencing domain controllers must be removed from their `msDS-AllowedToDelegateTo`
            attribute. This can be performed through the "Delegation" tab of the Active
            directory Users and Computers management console.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_delegation_sourcedeleg-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_delegation_sourcedeleg-l1
      name: "D\xE9l\xE9gation contrainte bas\xE9e sur les ressources, sur des contr\xF4\
        leurs de domaine (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nSur les contr\xF4leurs\
        \ de domaine, la d\xE9l\xE9gation contrainte bas\xE9e sur les ressources (resource-based\
        \ constrained delegation) est configur\xE9e. Cette configuration accorde \xE0\
        \ des comptes une d\xE9l\xE9gation compl\xE8te vers les contr\xF4leurs de\
        \ domaine."
      annotation: "# Recommandation\n\nLa d\xE9l\xE9gation vers des ressources privil\xE9\
        gi\xE9es (par exemple un service d'un contr\xF4leur de domaine) ne doit pas\
        \ \xEAtre utilis\xE9e.\n\nContrairement aux autres types de d\xE9l\xE9gations\
        \ reposant sur un Service Principal Name (SPN), la d\xE9l\xE9gation contrainte\
        \ bas\xE9e sur les ressources est impl\xE9ment\xE9e avec un descripteur de\
        \ s\xE9curit\xE9 sur la ressource cible. Ce descripteur de s\xE9curit\xE9\
        \ est stock\xE9 dans l'attribut `msDS-AllowedToActOnBehalfOfOtherIdentity`\
        \ sur l'ordinateur cible. Pour retirer cette d\xE9l\xE9gation, il est n\xE9\
        cessaire de supprimer l'attribut.\n\nCette modification peut \xEAtre r\xE9\
        alis\xE9e en PowerShell. Par exemple, la commande `Set-ADComputer MACHINE\
        \ -PrincipalsAllowedToDelegateToAccount $Null` permet de retirer cette d\xE9\
        l\xE9gation autoris\xE9e sur une machine appel\xE9e `MACHINE`."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Resource-based constrained delegation on domain controllers (Level
            1)
          description: '# Vulnerability description


            Resource-based constrained delegation is configured on domain controllers.
            This configuration grants some accounts with a complete delegation to
            domain controllers:'
          annotation: '# Recommended measure


            Delegation mechanisms towards privileged resources (such as domain controllers)
            should not be used.


            Unlike other delegation types based on a Service Principal Name (SPN),
            resource-based constrained delegation is configured through a security
            descriptor on the target resource. This security descriptor is stored
            in the `msDS-AllowedToActOnBehalfOfOtherIdentity` attribute of the target
            computer object. To remove this delegation, the attribute must be deleted.


            This can be fixed with PowerShell. The following command can be used to
            remove such a delegation on a target computer named `COMPUTER`: `Set-ADComputer
            COMPUTER -PrincipalsAllowedToDelegateToAccount $Null`.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_delegation_t2a4d-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_delegation_t2a4d-l1
      name: "D\xE9l\xE9gation d'authentification contrainte avec transition de protocole\
        \ vers un service privil\xE9gi\xE9 (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes poss\xE8\
        dent des d\xE9l\xE9gations d'authentification contraintes avec transition\
        \ de protocole vers un service privil\xE9gi\xE9. Elles permettent au compte\
        \ d'\xE9lever ses privil\xE8ges. Les services privil\xE9gi\xE9s consid\xE9\
        r\xE9s sont :\n\n* les services des contr\xF4leurs de domaine ;\n* le service\
        \ `krbtgt`."
      annotation: "# Recommandation\n\nLa d\xE9l\xE9gation d'authentification contrainte\
        \ avec transition de protocole permet \xE0 un compte de s'authentifier aupr\xE8\
        s d'un service Kerberos avec l'identit\xE9 d'un autre utilisateur. Si cette\
        \ d\xE9l\xE9gation est autoris\xE9e vers une ressource privil\xE9gi\xE9e (notamment\
        \ un service pr\xE9sent sur un contr\xF4leur de domaine), elle permet au compte\
        \ d'\xE9lever ses privil\xE8ges et de compromettre la for\xEAt.\n\nLa d\xE9\
        l\xE9gation d'authentification contrainte vers un service d'un contr\xF4leur\
        \ de domaine ne doit pas \xEAtre utilis\xE9e.\n\nPour les comptes concern\xE9\
        s, il faut supprimer dans l'attribut `msDS-AllowedToDelegateTo` tous les Service\
        \ Principal Name (SPN) r\xE9f\xE9ren\xE7ant les contr\xF4leurs de domaine.\
        \ Cette op\xE9ration peut \xEAtre effectu\xE9e directement \xE0 partir de\
        \ l'onglet \xAB D\xE9l\xE9gation \xBB de la console de gestion des utilisateurs\
        \ et ordinateurs."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Constrained delegation with protocol transition to a privileged service
            (Level 1)
          description: '# Vulnerability description


            Some accounts have constrained authentication delegations with protocol
            transition to a privileged service. These grant the subject account the
            ability to elevate its privileges. The following services are handled:


            * domain controller services;

            * `krbtgt` service.'
          annotation: '# Recommended measure


            Constrained delegation with protocol transition allows an account to temporarily
            act on behalf of any user or computer. If that delegation is authorized
            to a privileged resource (including domain controllers), it allows the
            account to assume the privileges of that resource and compromise the forest.


            Constrained delegation with protocol transition to a domain controller
            service must not be allowed.


            For each of the aforementioned account, all Service Principal Names (SPNs)
            referencing domain controllers must be removed from their `msDS-AllowedToDelegateTo`
            attribute. This can be performed through the "Delegation" tab of the Active
            directory Users and Computers management console.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_delegation_t4d-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_delegation_t4d-l1
      name: "D\xE9l\xE9gation d'authentification non contrainte (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes de la for\xEA\
        t poss\xE8dent des d\xE9l\xE9gations d'authentification non contraintes. Cette\
        \ d\xE9l\xE9gation permet d'usurper l'identit\xE9 de tout utilisateur s'authentifiant\
        \ aupr\xE8s de ces comptes."
      annotation: "# Recommandation\n\nLa d\xE9l\xE9gation d'authentification non\
        \ contrainte permet \xE0 un compte de s'authentifier aupr\xE8s de n'importe\
        \ quel service Kerberos avec l'identit\xE9 d'un utilisateur (s'\xE9tant pr\xE9\
        alablement authentifi\xE9 aupr\xE8s de ce compte). Elle n'est donn\xE9e par\
        \ d\xE9faut qu'aux contr\xF4leurs de domaine et ne doit pas \xEAtre accord\xE9\
        e \xE0 d'autres comptes.\n\nPour les comptes concern\xE9s, il convient de\
        \ supprimer la propri\xE9t\xE9 <code style=\"background-color:rgb(220, 53,\
        \ 69);color:rgb(255, 255, 255)\">TRUSTED_FOR_DELEGATION</code> pr\xE9sente\
        \ dans l'attribut `userAccountControl`. Cette op\xE9ration peut \xEAtre effectu\xE9\
        e directement \xE0 partir de l'onglet \xAB D\xE9l\xE9gation \xBB de la console\
        \ de gestion des utilisateurs et ordinateurs. Si une d\xE9l\xE9gation Kerberos\
        \ doit \xEAtre mise en \u0153uvre, il faut utiliser la d\xE9l\xE9gation contrainte."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Unconstrained authentication delegation (Level 1)
          description: '# Vulnerability description


            Some accounts in the forest have been granted unconstrained authentication
            delegations. This grants them the ability to act as any user that will
            authenticate against them.'
          annotation: '# Recommended measure


            Unconstrained authentication delegation allows an account to authenticate
            to any Kerberos service acting on behalf of any user who has tried to
            authenticate to that account. It allows that account to elevate privileges
            and compromise the forest. By default, unconstrained authentication delegation
            is only granted to domain controllers, and must not be granted to any
            other account.


            For all of the accounts listed above, remove the <code style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">TRUSTED_FOR_DELEGATION</code> flag in
            their `userAccountControl` attribute. This can be performed through the
            "Delegation" tab of the Active directory Users and Computers management
            console. If a Kerberos delegation really is required, use a constrained
            one.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_display_specifier-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_display_specifier-l1
      name: "Pr\xE9sence de Display Specifiers dangereux (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLes objets `Display\
        \ Specifiers` permettent de modifier les menus de la console d'administration\
        \ `dsa.msc` et d'ex\xE9cuter des objets COM ou des scripts. La for\xEAt contient\
        \ des objets `Display Specifiers` pointant sur des scripts situ\xE9s sur des\
        \ serveurs de fichiers (hors du sysvol) :"
      annotation: "# Recommandation\n\nLes scripts pr\xE9sents dans les objets `Display\
        \ Specifiers` doivent \xEAtre supprim\xE9s ou d\xE9plac\xE9s sur le partage\
        \ sysvol d'un contr\xF4leur de domaine."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous Display Specifiers (Level 1)
          description: '# Vulnerability description


            `Display Specifiers` are an extension mechanism for the `dsa.msc` menus
            that allow executing COM objets or scripts. The forest has `Display Specifiers`
            referencing scripts on file servers (non sysvol) :'
          annotation: '# Recommended measure


            Scripts references in `Display Specifiers` objects should be deleted or
            moved to a sysvol share of a domain controller.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dnsadmins-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dnsadmins-l1
      name: Permissions dangereuses sur le groupe DnsAdmins (Niveau 1)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nPlusieurs comptes non\
        \ privil\xE9gi\xE9s sont membres du groupe `DnsAdmins` ou poss\xE8dent des\
        \ droits dangereux sur celui-ci.\n\nLes membres du groupe `DnsAdmins` disposent\
        \ de nombreux droits pour g\xE9rer le service DNS Microsoft, qui est g\xE9\
        n\xE9ralement h\xE9berg\xE9 par un contr\xF4leur de domaine.\n\nParmi ces\
        \ droits, il est possible de g\xE9rer l'int\xE9gralit\xE9 des enregistrements\
        \ des zones DNS ayant une port\xE9e domaine, d'employer des fonctionnalit\xE9\
        s de debug du serveur, voire non document\xE9es, comme par exemple la possibilit\xE9\
        \ de faire red\xE9marrer instantan\xE9ment ou d'arr\xEAter le service DNS.\n\
        \nEnfin, selon le niveau de mise \xE0 jour du syst\xE8me d'exploitation de\
        \ l'int\xE9gralit\xE9 des serveurs DNS en production, ou de la configuration\
        \ locale du service DNS, il peut toujours \xEAtre possible de faire ex\xE9\
        cuter du code arbitraire via la fonctionnalit\xE9 `serverlevelplugindll`.\n\
        \nMalgr\xE9 la [disponibilit\xE9 d'un correctif aupr\xE8s de Microsoft](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40469),\
        \ ces fonctionnalit\xE9s dangereuses peuvent toujours \xEAtre r\xE9activ\xE9\
        es. Il est donc impossible d'\xE9valuer l'innocuit\xE9 du param\xE9trage uniquement\
        \ par l'\xE9tude de la configuration dans l'Active Directory, tout comme il\
        \ est impossible de v\xE9rifier avec certitude que l'ensemble des serveurs\
        \ DNS Microsoft soient \xE0 jour.\n\nL'ensemble de ces possibilit\xE9s donne\
        \ des capacit\xE9s de nuisance significatives, voire facilite des attaques\
        \ r\xE9seau, et justifient donc de consid\xE9rer ce groupe comme \xE9tant\
        \ privil\xE9gi\xE9.\n\n# Permissions dangereuses et chemins de contr\xF4le\n\
        \nDes permissions dangereuses permettent la prise de contr\xF4le d'un objet\
        \ cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9criture\
        \ de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl est recommand\xE9 de ne pas utiliser le\
        \ groupe `DNSAdmin`. Une d\xE9l\xE9gation doit \xEAtre cr\xE9\xE9e pour la\
        \ gestion du DNS (cr\xE9ation/suppression de zones, gestion des enregistrements,\
        \ etc.), g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide de l'utilitaire `ldp`.\
        \ Cette d\xE9l\xE9gation peut \xEAtre effectu\xE9e en deux \xE9tapes.\n\n\
        ## \xC9tape 1: autoriser l'acc\xE8s aux RPC n\xE9cessaires \xE0 l'utilisation\
        \ des composants enfichables de gestion DNS\n\nDans la partition du domaine,\
        \ dans le conteneur `CN=System`, d\xE9l\xE9guer les droits suivants sur le\
        \ conteneur `CN=MicrosoftDNS`:\n\n|  |  |  |  |\n| --- | --- | --- | --- |\n\
        | <input type=\"checkbox\" disabled checked /> Propri\xE9t\xE9 de lecture\
        \ | <input type=\"checkbox\" disabled /> Propri\xE9t\xE9 d'\xE9criture | <input\
        \ type=\"checkbox\" disabled /> Cr\xE9er un enfant | <input type=\"checkbox\"\
        \ disabled /> Contr\xF4ler l'acc\xE8s |\n| <input type=\"checkbox\" disabled\
        \ checked /> Liste | <input type=\"checkbox\" disabled /> DACL d'\xE9criture\
        \ | <input type=\"checkbox\" disabled /> Supprimer un enfant | <input type=\"\
        checkbox\" disabled /> \xC9criture \xE9tendue |\n| <input type=\"checkbox\"\
        \ disabled checked /> Afficher la liste pour l'objet | <input type=\"checkbox\"\
        \ disabled /> Acc\xE8s en \xE9criture au propri\xE9taire | <input type=\"\
        checkbox\" disabled /> Supprimer |\n| <input type=\"checkbox\" disabled checked\
        \ /> Autorisations de lecture | <input type=\"checkbox\" disabled /> \xC9\
        crire la liste SACL | <input type=\"checkbox\" disabled /> Supprimer l'arborescence\
        \ |\n\n## \xC9tape 2: autoriser la modification de la zone DNS\n\nDans la\
        \ partition `DC=DomainDnsZones`, sur chaque zone ayant besoin d'\xEAtre administr\xE9\
        e, d\xE9l\xE9guer les droits suivants avec h\xE9ritage sur le conteneur `CN=MicrosoftDNS`:\n\
        \n|  |  |  |  |\n| --- | --- | --- | --- |\n| <input type=\"checkbox\" disabled\
        \ checked /> Propri\xE9t\xE9 de lecture | <input type=\"checkbox\" disabled\
        \ /> Propri\xE9t\xE9 d'\xE9criture | <input type=\"checkbox\" disabled checked\
        \ /> Cr\xE9er un enfant | <input type=\"checkbox\" disabled /> Contr\xF4ler\
        \ l'acc\xE8s |\n| <input type=\"checkbox\" disabled checked /> Liste | <input\
        \ type=\"checkbox\" disabled /> DACL d'\xE9criture | <input type=\"checkbox\"\
        \ disabled checked /> Supprimer un enfant | <input type=\"checkbox\" disabled\
        \ /> \xC9criture \xE9tendue |\n| <input type=\"checkbox\" disabled checked\
        \ /> Afficher la liste pour l'objet | <input type=\"checkbox\" disabled />\
        \ Acc\xE8s en \xE9criture au propri\xE9taire | <input type=\"checkbox\" disabled\
        \ checked /> Supprimer |\n| <input type=\"checkbox\" disabled checked /> Autorisations\
        \ de lecture | <input type=\"checkbox\" disabled /> \xC9crire la liste SACL\
        \ | <input type=\"checkbox\" disabled checked /> Supprimer l'arborescence\
        \ |\n\nAttention \xE0 ne pas oublier \xE9galement de d\xE9l\xE9guer les zones\
        \ inverses (reverse DNS).\n\nNote : pour changer de naming context (partition)\
        \ dans `ldp`, il faut utiliser le menu `affichage`, `arborescence` et utiliser\
        \ le menu d\xE9roulant pour s\xE9lectionner `DomainDnsZones`.\n\nDe plus,\
        \ les op\xE9rations suivantes sont \xE0 r\xE9aliser sur le groupe `DnsAdmins`:\n\
        \n* vider le groupe ;\n* s'assurer que le propri\xE9taire du groupe est *Administrateurs\
        \ du domaine* (Domain Admins);\n* optionnellement, positionner une ACE interdisant\
        \ \xE0 tout le monde de changer le propri\xE9taire, de changer les droits\
        \ d'acc\xE8s et d'\xE9crire les membres du groupe.\n\n## Contexte : chemins\
        \ de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9 d'un ensemble\
        \ de relations de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEE\
        trise d'un objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8\
        re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Limites\n\nCertains chemins de contr\xF4le peuvent\
        \ disposer de correctifs qui les rendent non exploitables. Ces cas imposent\
        \ g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs de domaine au m\xEA\
        me niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9s dangereuses peuvent\
        \ parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics.\
        \ Il est donc toujours recommand\xE9 de nettoyer les permissions concern\xE9\
        es de l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8\
        me.\n\nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Cas particulier de\
        \ Microsoft Exchange Server\n\nCertains chemins de contr\xF4le qui apparaissent\
        \ peuvent \xEAtre li\xE9s \xE0 des groupes Exchange b\xE9n\xE9ficiant de permissions\
        \ dangereuses. Deux cas particuliers peuvent se pr\xE9senter :\n\n1. s'il\
        \ s'agit de groupes datant d'une ancienne installation de Exchange Server\
        \ 2007 ou ant\xE9rieure (\"Exchange Enterprise Servers\", \"Exchange Domain\
        \ Servers\" ou \"Exchange Services\") et que cette infrastructure a \xE9t\xE9\
        \ migr\xE9e vers une version 2010 ou ult\xE9rieure, il est recommand\xE9 de\
        \ supprimer ces groupes et les permissions associ\xE9es. [Microsoft fournit\
        \ une proc\xE9dure \xE0 cette fin](https://learn.microsoft.com/fr-fr/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
        2. sinon pour les autres groupes, il convient de v\xE9rifier les contr\xF4\
        les dangereux concern\xE9s pour d\xE9terminer la correction ad\xE9quate (voir\
        \ plus bas).\n\nLes contr\xF4les suivants, uniquement s'ils sont mentionn\xE9\
        s pour un groupe li\xE9 \xE0 Exchange, ont fait l'objet d'un correctif de\
        \ Microsoft :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nAttention\
        \ : certaines des propri\xE9t\xE9s LDAP concern\xE9es par ces \xE9critures\
        \ (`servicePrincipalName` et `altSecurityIdentities`) font partie du property-set\
        \ `Public-Information`. Ainsi, les permissions d'\xE9critures peuvent \xEA\
        tre attribu\xE9es pour chaque attribut unitairement ou le property-set entier,\
        \ auquel cas seul ce dernier sera visible dans la DACL de l'objet concern\xE9\
        .\n\nPour appliquer ce correctif, il est n\xE9cessaire d'effectuer les actions\
        \ suivantes :\n\n* pour Exchange Server 2019 : installer le SU de mai 2022\
        \ sur le CU12 ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2016 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2013 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014260](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
        \ ;\n* pour toutes les versions, apr\xE8s installation des correctifs pr\xE9\
        c\xE9dents : ex\xE9cuter la phase de pr\xE9paration des domaines \"/PrepareAllDomains\"\
        \n  * pour Exchange Server 2019 et 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
        \ /PrepareAllDomains` ou `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
        \ /PrepareAllDomains` depuis le r\xE9pertoire d'installation de Exchange ;\n\
        \  * pour Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
        \ /PrepareAllDomains`;\n  * il est rappel\xE9 que Exchange Server 2010 n'est\
        \ plus support\xE9 par l'\xE9diteur.\n\nPour tout autre chemin de contr\xF4\
        le, une qualification manuelle doit \xEAtre effectu\xE9e pour caract\xE9riser\
        \ le probl\xE8me.\n\n\xC0 titre d'information, la liste des derniers correctifs\
        \ publi\xE9s pour Exchange Server est [disponible ici](https://learn.microsoft.com/fr-fr/exchange/new-features/build-numbers-and-release-dates).\n\
        \n## Acceptation du risque\n\nSi des permissions sp\xE9cifiques sont n\xE9\
        cessaires, il convient de consid\xE9rer que les comptes ou les groupes d\xE9\
        l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9gi\xE9s. Ainsi, ils doivent \xEA\
        tre correctement prot\xE9g\xE9s et leurs permissions appliqu\xE9es doivent\
        \ \xEAtre au moins aussi restrictives que celles appliqu\xE9es \xE0 l' `adminSDHolder`.\
        \ Il est donc n\xE9cessaire de leur appliquer des permissions \"s\xE9curis\xE9\
        es\". Pour cela, il est recommand\xE9 d'utiliser la commande ``Set-ADSyncRestrictedPermissions``\
        \ du module `AdSyncConfig.psm1` fourni avec Azure AD Connect. Cette commande\
        \ supprime l'h\xE9ritage et applique des permissions (ACE) restreintes. Pour\
        \ un groupe d\xE9l\xE9gu\xE9, l'application de cette seule commande n'est\
        \ pas suffisante : il faut \xE9galement retirer les membres du groupe, ou\
        \ les consid\xE9rer eux-m\xEAmes comme \xE9tant privil\xE9gi\xE9e en leur\
        \ appliquant la m\xEAme commande.\n\nExemple d'utilisation de ``Set-ADSyncRestrictedPermissions``\
        \ pour appliquer des permissions \"s\xE9curis\xE9es\" sur un compte privil\xE9\
        gi\xE9 :\n\n```powershell\nImport-Module .\\AdSyncConfig.psm1\n$credential\
        \ = Get-Credential\nSet-ADSyncRestrictedPermissions -ADConnectorAccountDN\
        \ \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\" -Credential $credential\n\
        ```\n\nNote : le module `AdSyncConfig.psm1` peut \xEAtre directement extrait\
        \ du fichier d'installation d'Azure AD Connect \xE0 l'aide de l'utilitaire\
        \ int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\\
        temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9l\xE9charg\xE9 \xE0\
        \ l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous permissions on the DnsAdmins group (Level 1)
          description: '# Vulnerability description


            The `DnsAdmins` group includes some non-privileged member accounts or
            have dangerous permissions set.


            Members of the `DnsAdmins` group are granted access rights to manage a
            Microsoft DNS service, which is often hosted on domain controllers.


            Those access rights grant at least the following abilities: managing the
            entirety of domain-level DNS zones, using debug features or undocumented
            features such as the ability to instantly restart or stop the DNS server.


            One of these rights allows the user to make the DNS service run arbitrary
            code via the `serverlevelplugindll` feature, depending on the patch level
            or on specific configuration of all Windows Servers running DNS services
            across the forest.


            Despite [an official fix being available](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40469),
            these dagerous features may still be re-enabled. Evaluating the security
            of the running configuration cannot be done solely based on Active Directory-stored
            parameters, just as it is impossible to ensure that all running Microsoft
            DNS servers are up to date.


            This provides an attacker with significant nuisance capabilities or even
            could facilitate network attacks. This group should therefore be considered
            as privileged.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: "# Recommended measure\n\nThe `DnsAdmins` must not be used:\
            \ manual DNS zone delegations must be used instead to manage the service\
            \ (zone creation/deletion, record management, ...). These delegations\
            \ are usually granted through the `ldp` utility. This is a two-step process:\n\
            \n## Step 1: allow access to RPC used by DNS management MMC snap in\n\n\
            In the domain naming context, under the `CN=System` container, set the\
            \ following access rights on the `CN=MicrosoftDNS` container:\n\n|  |\
            \  |  |  |\n| --- | --- | --- | --- |\n| <input type=\"checkbox\" disabled\
            \ checked /> Propri\xE9t\xE9 de lecture | <input type=\"checkbox\" disabled\
            \ /> Propri\xE9t\xE9 d'\xE9criture | <input type=\"checkbox\" disabled\
            \ /> Cr\xE9er un enfant | <input type=\"checkbox\" disabled /> Contr\xF4\
            ler l'acc\xE8s |\n| <input type=\"checkbox\" disabled checked /> Liste\
            \ | <input type=\"checkbox\" disabled /> DACL d'\xE9criture | <input type=\"\
            checkbox\" disabled /> Supprimer un enfant | <input type=\"checkbox\"\
            \ disabled /> \xC9criture \xE9tendue |\n| <input type=\"checkbox\" disabled\
            \ checked /> Afficher la liste pour l'objet | <input type=\"checkbox\"\
            \ disabled /> Acc\xE8s en \xE9criture au propri\xE9taire | <input type=\"\
            checkbox\" disabled /> Supprimer |\n| <input type=\"checkbox\" disabled\
            \ checked /> Autorisations de lecture | <input type=\"checkbox\" disabled\
            \ /> \xC9crire la liste SACL | <input type=\"checkbox\" disabled /> Supprimer\
            \ l'arborescence |\n\n## Step 2: allow DNS zone modifications\n\nIn the\
            \ `DC=DomainDnsZones` naming context, on every zone you wish to delegate\
            \ management, enable inheritance and set the following access rights on\
            \ the `CN=MicrosoftDNS` container:\n\n|  |  |  |  |\n| --- | --- | ---\
            \ | --- |\n| <input type=\"checkbox\" disabled checked /> Propri\xE9t\xE9\
            \ de lecture | <input type=\"checkbox\" disabled /> Propri\xE9t\xE9 d'\xE9\
            criture | <input type=\"checkbox\" disabled checked /> Cr\xE9er un enfant\
            \ | <input type=\"checkbox\" disabled /> Contr\xF4ler l'acc\xE8s |\n|\
            \ <input type=\"checkbox\" disabled checked /> Liste | <input type=\"\
            checkbox\" disabled /> DACL d'\xE9criture | <input type=\"checkbox\" disabled\
            \ checked /> Supprimer un enfant | <input type=\"checkbox\" disabled />\
            \ \xC9criture \xE9tendue |\n| <input type=\"checkbox\" disabled checked\
            \ /> Afficher la liste pour l'objet | <input type=\"checkbox\" disabled\
            \ /> Acc\xE8s en \xE9criture au propri\xE9taire | <input type=\"checkbox\"\
            \ disabled checked /> Supprimer |\n| <input type=\"checkbox\" disabled\
            \ checked /> Autorisations de lecture | <input type=\"checkbox\" disabled\
            \ /> \xC9crire la liste SACL | <input type=\"checkbox\" disabled checked\
            \ /> Supprimer l'arborescence |\n\nNote: to change the current naming\
            \ context in `ldp`, go to `View`, `Tree` and use the drop-down list to\
            \ select `DomainDnsZones`.\n\nAdditionally, the following operations must\
            \ be carried out on the `DnsAdmins` group:\n\n* empty it of all its members;\n\
            * make sure the group is owned by *Domain Admins* (Administrateurs du\
            \ domaine);\n* add an Access Control Entry forbidding Everyone to change\
            \ its owner, change its access rights, and write its list of members.\n\
            \n## Context: control path exposure\n\nA control path materializes through\
            \ a set of granted access permissions: each granted permission can be\
            \ expressed as one object controlling another through a specific property,\
            \ attribute or setting. Control paths reveal how an attacker could leverage\
            \ a chain of defective or dangerous permissions to gain control of some\
            \ targets. They can also be leveraged to quickly identify domain mismanagement,\
            \ to validate the actual security boundary of a particular scope (making\
            \ sure some object of interest cannot be taken over by unauthorized users\
            \ through misconfiguration). Indicators of compromise may also be found\
            \ through control path review.\n\n## Limitations\n\nSome control paths\
            \ may have fixes that renders them non-exploitable. Such a case usually\
            \ requires having all domain controllers equally up to date. Furthermore,\
            \ dangerous features may sometimes be re-enabled through a registry or\
            \ dsHeuristics setting. It is therefore still recommended to clean the\
            \ affected permissions from your Active Directory to prevent an accidental\
            \ re-occurrence.\n\nList of known specific fixes:\n\n* [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
            \ fixes the <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">OWNER</span> and <span style=\"background-color:rgb(255, 165,\
            \ 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> control path on computer\
            \ accounts only, but the dangerous behavior can still be re-enabled.\n\
            * Various Exchange-related control paths have been fixed through specific\
            \ cumulative updates; refer to the dedicated section below if applicable.\n\
            \n## Microsoft Exchange Server Specifics\n\nSome control paths under this\
            \ item may appear because of Exchange Server management groups with excessive\
            \ permissions. The cause can be:\n\n1. either the offending groups come\
            \ from a legacy Exchange Server 2007 or earlier instance (\"Exchange Enterprise\
            \ Servers\", \"Exchange Domain Servers\" ou \"Exchange Services\") which\
            \ has been migrated to version 2010 or later, it is then best to remove\
            \ those groups and associated permissions. [Microsoft provides relevant\
            \ guidance to fix these issues](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
            2. or these are current Exchange Server management groups, a specific\
            \ analysis will help select the applicable solution (see below).\n\nThe\
            \ following controls have been fixed by Microsoft, only if pertaining\
            \ to Exchange Server groups:\n\n* <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>\n* <span style=\"\
            background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n\
            * <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
            \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nWarning:\
            \ some LDAP attributes (`servicePrincipalName` and `altSecurityIdentities`)\
            \ behind these controls belong to the `Public-Information` property set.\
            \ Therefore, these write permissions may be granted on an attribute basis\
            \ or to the whole property set, in which case only this property set will\
            \ be visible in the object's DACL.\n\nApplying the official fix involves\
            \ the following steps:\n\n* Exchange Server 2019 : install may 2022 SU\
            \ on CU12 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2016 : install may 2022 SU on CU23 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2013 : install may 2022 SU on CU23 ([KB5014260](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
            \ ;\n* for all version, after applying the above security updates: run\
            \ the \"/PrepareAllDomains\" setup phase\n  * on Exchange Server 2019\
            \ and 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
            \ /PrepareAllDomains` or `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * on Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * Please note Exchange Server 2010 is not supported anymore by Microsoft.\n\
            \nAny other control path shall be manually investigated to properly address\
            \ the issue.\n\nA list of published Exchange Server security updates is\
            \ [available here](https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates).\n\
            \n## Risk Acceptance\n\nIf special permissions are required, delegated\
            \ groups or accounts should be considered as privileged. Therefore, they\
            \ must comply with appropriate protection measures, and their own access\
            \ control list should be at least as strict as that of the `adminSDHolder`\
            \ object. \"Secure\" ACLs should therefore be implemented on these delegated\
            \ groups, which will not open a new control path exposure. To remove inheritance\
            \ and restrict ACEs, the following command may be used: ``Set-ADSyncRestrictedPermissions``\
            \ found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated\
            \ groups, strengthening permissions using this command is not enough:\
            \ the permissions of this group's members must also be strengthened by\
            \ applying this command to them, or they can be removed from the delegated\
            \ group.\n\nExample: applying \"secure\" permission on a privileged account\
            \ through ``Set-ADSyncRestrictedPermissions``:\n\n```powershell\nImport-Module\
            \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
            \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
            \ -Credential $credential\n```\n\nNote: the `AdSyncConfig.psm1` module\
            \ may be extracted from the Azure AD Connect installer with `msiexec`:\
            \ `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\temp\\`\n\nThe\
            \ installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dnszone_bad_prop-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dnszone_bad_prop-l1
      name: "Zones DNS mal configur\xE9es (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes zones DNS pr\xE9\
        sentent des probl\xE8mes de configuration.\n\nPar exemple, la valeur <code\
        \ style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">ZONE_UPDATE_UNSECURE</code>\
        \ (propri\xE9t\xE9 `DSPROPERTY_ZONE_ALLOW_UPDATE`) permet la mise \xE0 jour\
        \ d'un enregistrement DNS sans authentification. Un individu malveillant peut\
        \ utiliser cette vuln\xE9rabilit\xE9 pour :\n\n* ajouter arbitrairement un\
        \ nom DNS ;\n* remplacer un nom afin d'usurper une interface d'administration\
        \ et attendre une authentification pour subtiliser des identifiants.\n\n##\
        \ Seuils de tol\xE9rance\n\nCe point de contr\xF4le pr\xE9sente des seuils\
        \ de tol\xE9rance diff\xE9rents en fonction du niveau de s\xE9curit\xE9 vis\xE9\
        \ :\n\n* au niveau <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">1</span> seules les zones des domaines et les zones `_msdcs`\
        \ associ\xE9es sont remont\xE9es ;\n* au niveau <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> toutes les zones sont remont\xE9\
        es."
      annotation: "# Recommandation\n\nSi la propri\xE9t\xE9 `DSPROPERTY_ZONE_ALLOW_UPDATE`\
        \ vaut <code style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">ZONE_UPDATE_UNSECURE</code>, il est recommand\xE9 de reconfigurer\
        \ les zones DNS pour n'autoriser que les mises \xE0 jour s\xE9curis\xE9es\
        \ avec la commande suivante: `dnscmd <servername> /Config <zone> /AllowUpdate\
        \ 2`"
      implementation_groups:
      - level_1
      translations:
        en:
          name: Misconfigured DNS zones (Level 1)
          description: '# Vulnerability description


            Some DNS zones are misconfigured:


            For instance, a value of <code style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">ZONE_UPDATE_UNSECURE</code> (for the `DSPROPERTY_ZONE_ALLOW_UPDATE`
            attribute) allows updating a DNS record anonymously. An attacker could
            leverage this vulnerability to:


            * arbitrarily add a new DNS record;

            * replace an existing record to spoof a management interface, then wait
            for incoming connections in order to steal credentials.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only local domain zones and `_msdcs` zones are checked;

            * at level <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> all zones are checked.'
          annotation: '# Recommended measure


            If the `DSPROPERTY_ZONE_ALLOW_UPDATE` property is set to <code style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">ZONE_UPDATE_UNSECURE</code>, reconfigure
            DNS zones to only allow secure updates, using the following command:


            dnscmd <servername> /Config <zone> /AllowUpdate 2'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dnszone_bad_prop-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dnszone_bad_prop-l3
      name: "Zones DNS mal configur\xE9es (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes zones DNS pr\xE9\
        sentent des probl\xE8mes de configuration.\n\nPar exemple, la valeur <code\
        \ style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">ZONE_UPDATE_UNSECURE</code>\
        \ (propri\xE9t\xE9 `DSPROPERTY_ZONE_ALLOW_UPDATE`) permet la mise \xE0 jour\
        \ d'un enregistrement DNS sans authentification. Un individu malveillant peut\
        \ utiliser cette vuln\xE9rabilit\xE9 pour :\n\n* ajouter arbitrairement un\
        \ nom DNS ;\n* remplacer un nom afin d'usurper une interface d'administration\
        \ et attendre une authentification pour subtiliser des identifiants.\n\n##\
        \ Seuils de tol\xE9rance\n\nCe point de contr\xF4le pr\xE9sente des seuils\
        \ de tol\xE9rance diff\xE9rents en fonction du niveau de s\xE9curit\xE9 vis\xE9\
        \ :\n\n* au niveau <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">1</span> seules les zones des domaines et les zones `_msdcs`\
        \ associ\xE9es sont remont\xE9es ;\n* au niveau <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span> toutes les zones sont remont\xE9\
        es."
      annotation: "# Recommandation\n\nSi la propri\xE9t\xE9 `DSPROPERTY_ZONE_ALLOW_UPDATE`\
        \ vaut <code style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">ZONE_UPDATE_UNSECURE</code>, il est recommand\xE9 de reconfigurer\
        \ les zones DNS pour n'autoriser que les mises \xE0 jour s\xE9curis\xE9es\
        \ avec la commande suivante: `dnscmd <servername> /Config <zone> /AllowUpdate\
        \ 2`"
      implementation_groups:
      - level_3
      translations:
        en:
          name: Misconfigured DNS zones (Level 3)
          description: '# Vulnerability description


            Some DNS zones are misconfigured:


            For instance, a value of <code style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">ZONE_UPDATE_UNSECURE</code> (for the `DSPROPERTY_ZONE_ALLOW_UPDATE`
            attribute) allows updating a DNS record anonymously. An attacker could
            leverage this vulnerability to:


            * arbitrarily add a new DNS record;

            * replace an existing record to spoof a management interface, then wait
            for incoming connections in order to steal credentials.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only local domain zones and `_msdcs` zones are checked;

            * at level <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> all zones are checked.'
          annotation: '# Recommended measure


            If the `DSPROPERTY_ZONE_ALLOW_UPDATE` property is set to <code style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">ZONE_UPDATE_UNSECURE</code>, reconfigure
            DNS zones to only allow secure updates, using the following command:


            dnscmd <servername> /Config <zone> /AllowUpdate 2'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dont_expire_priv-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dont_expire_priv-l1
      name: "Comptes privil\xE9gi\xE9s dont le mot de passe n'expire jamais (Niveau\
        \ 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nCertains comptes privil\xE9\
        gi\xE9s poss\xE8dent des mots de passe n'expirant pas.\n\nSi aucun m\xE9canisme\
        \ de s\xE9curit\xE9 ne force le changement de ces mots de passe, la r\xE9\
        cup\xE9ration d'un compte privil\xE9gi\xE9 permet \xE0 un individu malveillant\
        \ de conserver ces droits d'acc\xE8s au domaine sur le long terme."
      annotation: "# Recommandation\n\n## Cas g\xE9n\xE9ral\n\nIl est recommand\xE9\
        \ de changer r\xE9guli\xE8rement les mots de passe des membres des groupes\
        \ privil\xE9gi\xE9s (au maximum tous les 3 ans). Afin que la politique de\
        \ mot de passe du domaine soit impos\xE9e sur ces comptes, la propri\xE9t\xE9\
        \ <code style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\"\
        >DONT_EXPIRE</code> ne doit pas \xEAtre positionn\xE9e. Il convient donc de\
        \ supprimer cette propri\xE9t\xE9 pour ces comptes et de renouveler r\xE9\
        guli\xE8rement leur mot de passe d\xE8s la suppression de la propri\xE9t\xE9\
        . Cette action peut \xEAtre effectu\xE9e en d\xE9cochant la case \xAB Le mot\
        \ de passe n'expire jamais \xBB dans les propri\xE9t\xE9s du compte de l'utilisateur\
        \ (onglet compte).\n\nNote importante : il est d\xE9conseill\xE9 de forcer\
        \ ce renouvellement trop fr\xE9quemment (quelques mois). Une demande de renouvellement\
        \ trop fr\xE9quente induit statistiquement un nouveau choix de mot de passe\
        \ plus faible, ce qui en fait une mesure de s\xE9curit\xE9 contre-productive.\
        \ La fr\xE9quence de changement doit \xEAtre adapt\xE9e en fonction du contexte\
        \ d'emploi du compte. La politique de mot de passe impos\xE9e par le domaine\
        \ peut \xEAtre soit globale, soit affin\xE9e via le m\xE9canisme des Password\
        \ Settings Object (PSO).\n\nLorsque la propri\xE9t\xE9 <code style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">DONT_EXPIRE</code> n'est pas positionn\xE9\
        e sur un compte donn\xE9, l'annuaire Active Directory construit, pour ce compte,\
        \ un attribut `msDS-UserPasswordExpiryTimeComputed`. Cet attribut contient\
        \ la date d'expiration du mot de passe, qui peut servir pour anticiper l'expiration\
        \ des mots de passe, en particulier pour les comptes de service.\n\n## Cas\
        \ particuliers\n\nSi la propri\xE9t\xE9 <code style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">DONT_EXPIRE</code> a \xE9t\xE9 positionn\xE9\
        e car le changement de mot de passe de ces comptes n'est pas possible facilement,\
        \ cela peut signifier que ces comptes ne sont pas utilis\xE9s pour des op\xE9\
        rations d'administration (par exemple, des comptes de service). Ces comptes\
        \ ne doivent en aucun cas \xEAtre membres d'un groupe privil\xE9gi\xE9. Il\
        \ convient de :\n\n* les retirer de ces groupes ;\n* leur conf\xE9rer les\
        \ d\xE9l\xE9gations n\xE9cessaires \xE0 leur fonctionnement ;\n* documenter\
        \ une proc\xE9dure de changement de mot de passe sp\xE9cifique ;\n* d'enlever\
        \ la propri\xE9t\xE9 <code style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">DONT_EXPIRE</code>.\n\n## Cas des comptes non utilis\xE9s\n\n\
        Il est n\xE9cessaire de neutraliser les comptes qui ne sont plus utilis\xE9\
        s. La m\xE9thode suivante de neutralisation apporte les m\xEAmes avantages\
        \ que la suppression tout en conservant la tra\xE7abilit\xE9 offerte par la\
        \ simple d\xE9sactivation. Pour neutraliser un compte, il faut :\n\n* d\xE9\
        sactiver le compte ;\n* le retirer de tous ses groupes d'appartenance ;\n\
        * changer son mot de passe de fa\xE7on al\xE9atoire. Pour garantir un mot\
        \ de passe al\xE9atoire, il est recommand\xE9 de s\xE9lectionner l\u2019option\
        \ \xAB Une carte \xE0 puce est n\xE9cessaire pour ouvrir une session interactive\
        \ \xBB dans les propri\xE9t\xE9s du compte. Cela revient \xE0 positionner\
        \ l'attribut <code style=\"background-color:rgb(40, 167, 69);color:rgb(255,\
        \ 255, 255)\">ADS_UF_SMARTCARD_REQUIRED</code> dans la propri\xE9t\xE9 `userAccountControl`;\n\
        * \xE9ventuellement, d\xE9placer le compte dans une OU d\xE9di\xE9e ;\n* \xE9\
        ventuellement, mettre \xE0 jour le champ description du compte afin d'indiquer\
        \ le contexte de d\xE9sactivation (date, raison, etc.).\n\n## Contexte : groupes\
        \ privil\xE9gi\xE9s\n\nLes groupes privil\xE9gi\xE9s sont les groupes d'administration\
        \ et les groupes op\xE9ratifs ayant tous les droits et privil\xE8ges sur la\
        \ for\xEAt ou pouvant se les attribuer :\n\n* \xAB *Administrateurs* (Administrators)\
        \ \xBB ;\n* \xAB *Contr\xF4leurs de domaine* (Domain Controllers) \xBB;\n\
        * \xAB *Administrateurs du sch\xE9ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs\
        \ de l'entreprise* (Enterprise Admins) \xBB ;\n* \xAB *Administrateurs du\
        \ domaine* (Domain Admins) \xBB : ces administrateurs ont les privil\xE8ges\
        \ de lire la base des secrets de tous les comptes et donc d'extraire les secrets\
        \ de l'ensemble des comptes privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de\
        \ cl\xE9s* (Key Admins) \xBB et \xAB *Administrateurs de cl\xE9s de l'entreprise*\
        \ (Enterprise Key Admins) \xBB: ces administrateurs peuvent fixer des valeurs\
        \ arbitraires aux attributs relatifs \xE0 Windows Hello for Business, pour\
        \ tous les utilisateurs sauf ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`.\
        \ Si l'authentification bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9\
        e, ils peuvent g\xE9n\xE9rer un certificat sous leur contr\xF4le, l'assigner\
        \ \xE0 un compte privil\xE9gi\xE9 (par exemple, un contr\xF4leur de domaine),\
        \ et s'authentifier en tant que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer tous les comptes\
        \ d'utilisateurs, machines et groupes; \xE0 l'exception des comptes prot\xE9\
        g\xE9s par l' `adminSDHolder`;\n* \xAB *Op\xE9rateurs de serveur* (Server\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer les contr\xF4leurs\
        \ de domaine, et donc r\xE9cup\xE9rer les secrets de tous les comptes privil\xE9\
        gi\xE9s ;\n* \xAB *Op\xE9rateurs de sauvegarde* (Backup Operators) \xBB :\
        \ ces op\xE9rateurs peuvent sauvegarder un contr\xF4leur de domaine et donc\
        \ extraire les secrets de tous les comptes privil\xE9gi\xE9s depuis cette\
        \ sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression* (Print Operators) \xBB\
        \ : ces op\xE9rateurs peuvent charger des pilotes d'impression sur les contr\xF4\
        leurs de domaine et donc charger un pilote malveillant pour par exemple extraire\
        \ les secrets de tous les comptes privil\xE9gi\xE9s.\n\nLes groupes \xAB op\xE9\
        rateurs \xBB sont vides par d\xE9faut et ne devraient contenir aucun membre."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Privileged accounts with never-expiring passwords (Level 1)
          description: '# Vulnerability description


            Some privileged accounts have passwords that never expire.


            If no security mechanism enforces a periodic password rotation, taking
            over an account allows any malicious user to keep their access rights
            in the domain for extended periods of time.'
          annotation: "# Recommended measure\n\n## General Case\n\nPasswords should\
            \ be periodically changed for all privileged group members (at most every\
            \ 3 years). To enforce the domain password policy on these accounts, their\
            \ <code style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
            \ 255)\">DONT_EXPIRE</code> flag should not be set. This account flag\
            \ should then be unset, usually by unchecking the \"password never expires\"\
            \ option in the \"Account\" tab of the user properties. Their passwords\
            \ should then be rolled immediately.\n\nImportant note: passwords should\
            \ not be renewed too often. Enforcing short password lifespans compels\
            \ users to choose statistically weaker passwords, which negates the intended\
            \ benefits. Password lifespan should be determined by taking into account\
            \ multiple factors such as usage context. The password policy may be globally\
            \ enforced on all domain accounts or scoped to select accounts, through\
            \ the Password Settings Object (PSO) mechanism.\n\nWhen the <code style=\"\
            background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">DONT_EXPIRE</code>\
            \ flag is not set, Active Directory will compute the `msDS-UserPasswordExpiryTimeComputed`\
            \ for the relevant accounts. This attribute contains the password expiry\
            \ date, which can be used to anticipate password changes, especially for\
            \ service accounts.\n\n## Specific Cases\n\nIf the <code style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">DONT_EXPIRE</code> flag has been\
            \ set on accounts with difficult-to-change passwords, it may mean these\
            \ accounts are not used for administration purposes (i.e., service accounts).\
            \ These accounts shall not belong to any privileged group. The following\
            \ must be done:\n\n* remove those accounts from privileged groups;\n*\
            \ grant these accounts the required rights delegations for proper operation;\n\
            * document a specific password change procedure;\n* remove the <code style=\"\
            background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">DONT_EXPIRE</code>\
            \ flag.\n\n## Unused accounts\n\nUnused accounts should be disabled. The\
            \ following procedure provides similar benefits than deletion, while retaining\
            \ information relevant to audit traces. To properly disable an account:\n\
            \n* disable the account;\n* remove all of its group memberships;\n* randomly\
            \ change its password. To enforce a random password, one can check the\
            \ smart card is required for interactive logon flag in the account properties.\
            \ This is equivalent to manually setting the <code style=\"background-color:rgb(40,\
            \ 167, 69);color:rgb(255, 255, 255)\">ADS_UF_SMARTCARD_REQUIRED</code>\
            \ flag of its `userAccountControl` attribute;\n* optionally, move the\
            \ account to a dedicated OU;\n* optionally, update the account description\
            \ field to mention the context for disabling (date, reason, etc.).\n\n\
            The \xAB operators \xBB groups are empty by default and must not have\
            \ any member.\n\n## Context: privileged groups\n\nPrivileged groups include\
            \ administrator groups and operator groups which have full control over\
            \ the Active Directory forest either by design, or by granting themselves\
            \ such privileges:\n\n* \xAB *Administrators* (Administrateurs) \xBB;\n\
            * \xAB *Domain Controllers* (Contr\xF4leurs de domaine) \xBB;\n* \xAB\
            \ *Schema Admins* (Administrateurs du sch\xE9ma) \xBB;\n* \xAB *Enterprise\
            \ Admins* (Administrateurs de l'entreprise) \xBB;\n* \xAB *Domain Admins*\
            \ (Administrateurs du domaine) \xBB: these administrators are able to\
            \ read the authentication database and extract password hashes and other\
            \ secrets of all privileged accounts;\n* \xAB *Key Admins* (Administrateurs\
            \ de cl\xE9s) \xBB and \xAB *Enterprise Key Admins* (Administrateurs de\
            \ cl\xE9s de l'entreprise) \xBB: these administrators can set arbitrary\
            \ values to attributes relating to Windows Hello for Business, for all\
            \ users except those protected by the `adminSDHolder` mechanism. If certificate-based\
            \ authentication has been enabled, they can generate a certificate that\
            \ they control, assign it to privileged accounts (for instance, a domain\
            \ controller), and log on as them;\n* \xAB *Account Operators* (Op\xE9\
            rateurs de compte) \xBB: these operators can manage user accounts, machine\
            \ accounts and groups except accounts protected by the `adminSDHolder`\
            \ mechanism;\n* \xAB *Server Operators* (Op\xE9rateurs de serveur) \xBB\
            : these operators can manage domain controllers, which grants them the\
            \ ability to recover privileged user secrets directly from the authentication\
            \ database;\n* \xAB *Backup Operators* (Op\xE9rateurs de sauvegarde) \xBB\
            : these operators can back up a domain controller, which grants them the\
            \ ability to recover privileged user secrets from that backup;\n* \xAB\
            \ *Print Operators* (Op\xE9rateurs d'impression) \xBB: these operators\
            \ can load arbitrary printer drivers on domain controllers, which grants\
            \ them the ability to recover privileged user secrets directly from the\
            \ authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dsheuristics_bad-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dsheuristics_bad-l1
      name: "Param\xE8tres dSHeuristics dangereux (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes param\xE8tres dangereux\
        \ sont configur\xE9s dans l'attribut `dSHeuristics`. Cette vuln\xE9rabilit\xE9\
        \ peut appara\xEEtre aux niveaux <span style=\"background-color:rgb(220, 53,\
        \ 69);color:rgb(255, 255, 255)\">1</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> selon le probl\xE8me rencontr\xE9\
        \ :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">1</span> si `fAllowAnonNSPI` est diff\xE9rent de 0 ;\n* <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> si `dwAdminSDExMask`\
        \ est diff\xE9rent de 0 ;\n* <span style=\"background-color:rgb(255, 165,\
        \ 0);color:rgb(0, 0, 0)\">2</span> si `fLDAPBlockAnonOps` est \xE9gal \xE0\
        \ 2 ;\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
        >2</span> si `DoNotVerifyUPNAndOrSPNUniqueness` est diff\xE9rent de 0 (KB5008382)\
        \ ;\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
        >2</span> si `AttributeAuthorizationOnLDAPAdd` est \xE9gal \xE0 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1))\
        \ ;\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
        >2</span> si `BlockOwnerImplicitRights` est \xE9gal \xE0 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1))\
        \ ;\n* <span style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255,\
        \ 255)\">4</span> si `AttributeAuthorizationOnLDAPAdd` est diff\xE9rent de\
        \ 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1))\
        \ ;\n* <span style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255,\
        \ 255)\">4</span> si `BlockOwnerImplicitRights` est diff\xE9rent de 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)).\n\
        \nLe tableau ci-dessous liste les valeurs explicitement d\xE9finies dans l'attribut\
        \ `dSHeuristics`. Les valeurs vides signifient qu'aucune valeur n'a \xE9t\xE9\
        \ d\xE9finie, et que la valeur par d\xE9faut s'applique. La valeur `00000000010000000002000000011`\
        \ permet par exemple d'atteindre le niveau <span style=\"background-color:rgb(40,\
        \ 167, 69);color:rgb(255, 255, 255)\">5</span>: elle met tous les champs \xE0\
        \ leur valeur par d\xE9faut, sauf `BlockOwnerImplicitRights` et `AttributeAuthorizationOnLDAPAdd`\
        \ qui sont mis \xE0 `1`."
      annotation: "# Recommandation\n\nL'attribut `dSHeuristics` permet de d\xE9finir\
        \ des heuristiques qui sont utilis\xE9es pour d\xE9terminer le fonctionnement\
        \ de certains m\xE9canismes de l'Active Directory. Par exemple :\n\n* `fLDAPBlockAnonOps`\
        \ permet d'autoriser des op\xE9rations LDAP sans authentification ;\n* `fAllowAnonNSPI`\
        \ permet d'autoriser l'acc\xE8s anonyme au Name Service Provider Interface\
        \ (NSPI) ;\n* `dwAdminSDExMask` permet de d\xE9finir les groupes prot\xE9\
        g\xE9s par le m\xE9canisme SDProp ;\n* `DoNotVerifyUPNAndOrSPNUniqueness`\
        \ permet de relaxer les v\xE9rifications sur l'unicit\xE9 des UPN et SPN ;\n\
        * `LDAPAddAuthZVerifications` permet de d\xE9sactiver l'audit et la protection\
        \ apport\xE9e par la [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1);\n\
        * `BlockOwnerImplicitRights` permet de d\xE9sactiver l'audit et la protection\
        \ apport\xE9e par la [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1).\n\
        \nLes param\xE8tres dangereux configur\xE9s dans la propri\xE9t\xE9 `dSHeuristics`\
        \ doivent \xEAtre modifi\xE9s et r\xE9initialis\xE9s \xE0 leur valeur par\
        \ d\xE9faut :\n\n* `fLDAPBlockAnonOps` ne doit pas \xEAtre configur\xE9 ou\
        \ avoir une valeur diff\xE9rente de 2 ;\n* `fAllowAnonNSPI` doit valoir 0\
        \ ;\n* `dwAdminSDExMask` doit valoir 0 ;\n* `DoNotVerifyUPNAndOrSPNUniqueness`\
        \ doit valoir 0 ;\n* `LDAPAddAuthZVerifications` ne doit pas \xEAtre configur\xE9\
        \ ou avoir une valeur diff\xE9rente de 2 pour atteindre le niveau 3 ; cette\
        \ valeur doit \xEAtre explicitement positionn\xE9e \xE0 1 pour atteindre le\
        \ niveau 5 ;\n* `BlockOwnerImplicitRights` ne doit pas \xEAtre configur\xE9\
        \ ou avoir une valeur diff\xE9rente de 2 pour atteindre le niveau 3 ; cette\
        \ valeur doit \xEAtre explicitement positionn\xE9e \xE0 1 pour atteindre le\
        \ niveau 5.\n\nLa correction est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide\
        \ des consoles `adsiedit.msc` ou de l'utilitaire `ldp`. L'attribut `dSHeuristics`\
        \ a un format particulier, dont la description est donn\xE9e dans la [documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous dsHeuristics settings (Level 1)
          description: '# Vulnerability description


            Dangerous values are set for the `dSHeuristics` attribute. Depending on
            severity, this issue can be raised at levels <span style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">1</span> or <span style="background-color:rgb(255,
            165, 0);color:rgb(0, 0, 0)">2</span>:


            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            if `fAllowAnonNSPI` differs from 0;

            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            if `dwAdminSDExMask` differs from 0;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `fLDAPBlockAnonOps` equals 2;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `DoNotVerifyUPNAndOrSPNUniqueness` differs from 0 (KB5008382);

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `AttributeAuthorizationOnLDAPAdd` equals 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1));

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `BlockOwnerImplicitRights` equals 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1));

            * <span style="background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)">4</span>
            if `AttributeAuthorizationOnLDAPAdd` differs from 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1));

            * <span style="background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)">4</span>
            if `BlockOwnerImplicitRights` differs from 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)).


            The following values are set in the `dSHeuristics` attribute. Empty values
            mean that no value has been explicitely defined. In this case, the default
            value is used. For example, setting `dSHeuristics` to `00000000010000000002000000011`
            allows reaching level <span style="background-color:rgb(40, 167, 69);color:rgb(255,
            255, 255)">5</span>, as this value sets every field to their default value,
            except `BlockOwnerImplicitRights` and `AttributeAuthorizationOnLDAPAdd`
            which are set to `1`.'
          annotation: '# Recommended measure


            The `dSHeuristics` attribute ([documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5))defines
            some heuristics later used to alter some Active Directory mechanisms.
            For instance:


            * `fLDAPBlockAnonOps` enables unauthenticated LDAP operations;

            * `fAllowAnonNSPI` controls anonymous access to the Name Service Provider
            Interface (NSPI);

            * `dwAdminSDExMask` defines which groups are covered by the SDProp mechanism;

            * `DoNotVerifyUPNAndOrSPNUniqueness` disables checks on UPN / SPN uniqueness;

            * `AttributeAuthorizationOnLDAPAdd` disables the auditing and enforcement
            of [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1);

            * `BlockOwnerImplicitRights` disables the auditing and enforcement of
            [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1).


            These dangerous `dSHeuristics` settings must be reset to their default
            value.


            * `fLDAPBlockAnonOps` should not be set or should have any value other
            than 2;

            * `fAllowAnonNSPI` should be set to 0;

            * `dwAdminSDExMask` should be set to 0;

            * `DoNotVerifyUPNAndOrSPNUniqueness` should be set to 0;

            * `AttributeAuthorizationOnLDAPAdd` should not be set or should have any
            value other than 2 to reach level 3; it must be explicitely set to 1 to
            reach level 5;

            * `BlockOwnerImplicitRights` should not be set or should have any value
            other than 2 to reach level 3; it must be explicitely set to 1 to reach
            level 5.


            The fix is usually applied through the `adsiedit.msc` or `ldp` utilities.
            The `dSHeuristics` attribute uses a specific format that is described
            in the [documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dsheuristics_bad-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dsheuristics_bad-l2
      name: "Param\xE8tres dSHeuristics dangereux (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes param\xE8tres dangereux\
        \ sont configur\xE9s dans l'attribut `dSHeuristics`. Cette vuln\xE9rabilit\xE9\
        \ peut appara\xEEtre aux niveaux <span style=\"background-color:rgb(220, 53,\
        \ 69);color:rgb(255, 255, 255)\">1</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> selon le probl\xE8me rencontr\xE9\
        \ :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">1</span> si `fAllowAnonNSPI` est diff\xE9rent de 0 ;\n* <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> si `dwAdminSDExMask`\
        \ est diff\xE9rent de 0 ;\n* <span style=\"background-color:rgb(255, 165,\
        \ 0);color:rgb(0, 0, 0)\">2</span> si `fLDAPBlockAnonOps` est \xE9gal \xE0\
        \ 2 ;\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
        >2</span> si `DoNotVerifyUPNAndOrSPNUniqueness` est diff\xE9rent de 0 (KB5008382)\
        \ ;\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
        >2</span> si `AttributeAuthorizationOnLDAPAdd` est \xE9gal \xE0 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1))\
        \ ;\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
        >2</span> si `BlockOwnerImplicitRights` est \xE9gal \xE0 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1))\
        \ ;\n* <span style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255,\
        \ 255)\">4</span> si `AttributeAuthorizationOnLDAPAdd` est diff\xE9rent de\
        \ 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1))\
        \ ;\n* <span style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255,\
        \ 255)\">4</span> si `BlockOwnerImplicitRights` est diff\xE9rent de 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)).\n\
        \nLe tableau ci-dessous liste les valeurs explicitement d\xE9finies dans l'attribut\
        \ `dSHeuristics`. Les valeurs vides signifient qu'aucune valeur n'a \xE9t\xE9\
        \ d\xE9finie, et que la valeur par d\xE9faut s'applique. La valeur `00000000010000000002000000011`\
        \ permet par exemple d'atteindre le niveau <span style=\"background-color:rgb(40,\
        \ 167, 69);color:rgb(255, 255, 255)\">5</span>: elle met tous les champs \xE0\
        \ leur valeur par d\xE9faut, sauf `BlockOwnerImplicitRights` et `AttributeAuthorizationOnLDAPAdd`\
        \ qui sont mis \xE0 `1`."
      annotation: "# Recommandation\n\nL'attribut `dSHeuristics` permet de d\xE9finir\
        \ des heuristiques qui sont utilis\xE9es pour d\xE9terminer le fonctionnement\
        \ de certains m\xE9canismes de l'Active Directory. Par exemple :\n\n* `fLDAPBlockAnonOps`\
        \ permet d'autoriser des op\xE9rations LDAP sans authentification ;\n* `fAllowAnonNSPI`\
        \ permet d'autoriser l'acc\xE8s anonyme au Name Service Provider Interface\
        \ (NSPI) ;\n* `dwAdminSDExMask` permet de d\xE9finir les groupes prot\xE9\
        g\xE9s par le m\xE9canisme SDProp ;\n* `DoNotVerifyUPNAndOrSPNUniqueness`\
        \ permet de relaxer les v\xE9rifications sur l'unicit\xE9 des UPN et SPN ;\n\
        * `LDAPAddAuthZVerifications` permet de d\xE9sactiver l'audit et la protection\
        \ apport\xE9e par la [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1);\n\
        * `BlockOwnerImplicitRights` permet de d\xE9sactiver l'audit et la protection\
        \ apport\xE9e par la [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1).\n\
        \nLes param\xE8tres dangereux configur\xE9s dans la propri\xE9t\xE9 `dSHeuristics`\
        \ doivent \xEAtre modifi\xE9s et r\xE9initialis\xE9s \xE0 leur valeur par\
        \ d\xE9faut :\n\n* `fLDAPBlockAnonOps` ne doit pas \xEAtre configur\xE9 ou\
        \ avoir une valeur diff\xE9rente de 2 ;\n* `fAllowAnonNSPI` doit valoir 0\
        \ ;\n* `dwAdminSDExMask` doit valoir 0 ;\n* `DoNotVerifyUPNAndOrSPNUniqueness`\
        \ doit valoir 0 ;\n* `LDAPAddAuthZVerifications` ne doit pas \xEAtre configur\xE9\
        \ ou avoir une valeur diff\xE9rente de 2 pour atteindre le niveau 3 ; cette\
        \ valeur doit \xEAtre explicitement positionn\xE9e \xE0 1 pour atteindre le\
        \ niveau 5 ;\n* `BlockOwnerImplicitRights` ne doit pas \xEAtre configur\xE9\
        \ ou avoir une valeur diff\xE9rente de 2 pour atteindre le niveau 3 ; cette\
        \ valeur doit \xEAtre explicitement positionn\xE9e \xE0 1 pour atteindre le\
        \ niveau 5.\n\nLa correction est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide\
        \ des consoles `adsiedit.msc` ou de l'utilitaire `ldp`. L'attribut `dSHeuristics`\
        \ a un format particulier, dont la description est donn\xE9e dans la [documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous dsHeuristics settings (Level 2)
          description: '# Vulnerability description


            Dangerous values are set for the `dSHeuristics` attribute. Depending on
            severity, this issue can be raised at levels <span style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">1</span> or <span style="background-color:rgb(255,
            165, 0);color:rgb(0, 0, 0)">2</span>:


            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            if `fAllowAnonNSPI` differs from 0;

            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            if `dwAdminSDExMask` differs from 0;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `fLDAPBlockAnonOps` equals 2;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `DoNotVerifyUPNAndOrSPNUniqueness` differs from 0 (KB5008382);

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `AttributeAuthorizationOnLDAPAdd` equals 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1));

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `BlockOwnerImplicitRights` equals 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1));

            * <span style="background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)">4</span>
            if `AttributeAuthorizationOnLDAPAdd` differs from 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1));

            * <span style="background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)">4</span>
            if `BlockOwnerImplicitRights` differs from 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)).


            The following values are set in the `dSHeuristics` attribute. Empty values
            mean that no value has been explicitely defined. In this case, the default
            value is used. For example, setting `dSHeuristics` to `00000000010000000002000000011`
            allows reaching level <span style="background-color:rgb(40, 167, 69);color:rgb(255,
            255, 255)">5</span>, as this value sets every field to their default value,
            except `BlockOwnerImplicitRights` and `AttributeAuthorizationOnLDAPAdd`
            which are set to `1`.'
          annotation: '# Recommended measure


            The `dSHeuristics` attribute ([documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5))defines
            some heuristics later used to alter some Active Directory mechanisms.
            For instance:


            * `fLDAPBlockAnonOps` enables unauthenticated LDAP operations;

            * `fAllowAnonNSPI` controls anonymous access to the Name Service Provider
            Interface (NSPI);

            * `dwAdminSDExMask` defines which groups are covered by the SDProp mechanism;

            * `DoNotVerifyUPNAndOrSPNUniqueness` disables checks on UPN / SPN uniqueness;

            * `AttributeAuthorizationOnLDAPAdd` disables the auditing and enforcement
            of [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1);

            * `BlockOwnerImplicitRights` disables the auditing and enforcement of
            [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1).


            These dangerous `dSHeuristics` settings must be reset to their default
            value.


            * `fLDAPBlockAnonOps` should not be set or should have any value other
            than 2;

            * `fAllowAnonNSPI` should be set to 0;

            * `dwAdminSDExMask` should be set to 0;

            * `DoNotVerifyUPNAndOrSPNUniqueness` should be set to 0;

            * `AttributeAuthorizationOnLDAPAdd` should not be set or should have any
            value other than 2 to reach level 3; it must be explicitely set to 1 to
            reach level 5;

            * `BlockOwnerImplicitRights` should not be set or should have any value
            other than 2 to reach level 3; it must be explicitely set to 1 to reach
            level 5.


            The fix is usually applied through the `adsiedit.msc` or `ldp` utilities.
            The `dSHeuristics` attribute uses a specific format that is described
            in the [documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dsheuristics_bad-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dsheuristics_bad-l3
      name: "Param\xE8tres dSHeuristics dangereux (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes param\xE8tres dangereux\
        \ sont configur\xE9s dans l'attribut `dSHeuristics`. Cette vuln\xE9rabilit\xE9\
        \ peut appara\xEEtre aux niveaux <span style=\"background-color:rgb(220, 53,\
        \ 69);color:rgb(255, 255, 255)\">1</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> selon le probl\xE8me rencontr\xE9\
        \ :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">1</span> si `fAllowAnonNSPI` est diff\xE9rent de 0 ;\n* <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> si `dwAdminSDExMask`\
        \ est diff\xE9rent de 0 ;\n* <span style=\"background-color:rgb(255, 165,\
        \ 0);color:rgb(0, 0, 0)\">2</span> si `fLDAPBlockAnonOps` est \xE9gal \xE0\
        \ 2 ;\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
        >2</span> si `DoNotVerifyUPNAndOrSPNUniqueness` est diff\xE9rent de 0 (KB5008382)\
        \ ;\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
        >2</span> si `AttributeAuthorizationOnLDAPAdd` est \xE9gal \xE0 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1))\
        \ ;\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
        >2</span> si `BlockOwnerImplicitRights` est \xE9gal \xE0 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1))\
        \ ;\n* <span style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255,\
        \ 255)\">4</span> si `AttributeAuthorizationOnLDAPAdd` est diff\xE9rent de\
        \ 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1))\
        \ ;\n* <span style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255,\
        \ 255)\">4</span> si `BlockOwnerImplicitRights` est diff\xE9rent de 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)).\n\
        \nLe tableau ci-dessous liste les valeurs explicitement d\xE9finies dans l'attribut\
        \ `dSHeuristics`. Les valeurs vides signifient qu'aucune valeur n'a \xE9t\xE9\
        \ d\xE9finie, et que la valeur par d\xE9faut s'applique. La valeur `00000000010000000002000000011`\
        \ permet par exemple d'atteindre le niveau <span style=\"background-color:rgb(40,\
        \ 167, 69);color:rgb(255, 255, 255)\">5</span>: elle met tous les champs \xE0\
        \ leur valeur par d\xE9faut, sauf `BlockOwnerImplicitRights` et `AttributeAuthorizationOnLDAPAdd`\
        \ qui sont mis \xE0 `1`."
      annotation: "# Recommandation\n\nL'attribut `dSHeuristics` permet de d\xE9finir\
        \ des heuristiques qui sont utilis\xE9es pour d\xE9terminer le fonctionnement\
        \ de certains m\xE9canismes de l'Active Directory. Par exemple :\n\n* `fLDAPBlockAnonOps`\
        \ permet d'autoriser des op\xE9rations LDAP sans authentification ;\n* `fAllowAnonNSPI`\
        \ permet d'autoriser l'acc\xE8s anonyme au Name Service Provider Interface\
        \ (NSPI) ;\n* `dwAdminSDExMask` permet de d\xE9finir les groupes prot\xE9\
        g\xE9s par le m\xE9canisme SDProp ;\n* `DoNotVerifyUPNAndOrSPNUniqueness`\
        \ permet de relaxer les v\xE9rifications sur l'unicit\xE9 des UPN et SPN ;\n\
        * `LDAPAddAuthZVerifications` permet de d\xE9sactiver l'audit et la protection\
        \ apport\xE9e par la [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1);\n\
        * `BlockOwnerImplicitRights` permet de d\xE9sactiver l'audit et la protection\
        \ apport\xE9e par la [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1).\n\
        \nLes param\xE8tres dangereux configur\xE9s dans la propri\xE9t\xE9 `dSHeuristics`\
        \ doivent \xEAtre modifi\xE9s et r\xE9initialis\xE9s \xE0 leur valeur par\
        \ d\xE9faut :\n\n* `fLDAPBlockAnonOps` ne doit pas \xEAtre configur\xE9 ou\
        \ avoir une valeur diff\xE9rente de 2 ;\n* `fAllowAnonNSPI` doit valoir 0\
        \ ;\n* `dwAdminSDExMask` doit valoir 0 ;\n* `DoNotVerifyUPNAndOrSPNUniqueness`\
        \ doit valoir 0 ;\n* `LDAPAddAuthZVerifications` ne doit pas \xEAtre configur\xE9\
        \ ou avoir une valeur diff\xE9rente de 2 pour atteindre le niveau 3 ; cette\
        \ valeur doit \xEAtre explicitement positionn\xE9e \xE0 1 pour atteindre le\
        \ niveau 5 ;\n* `BlockOwnerImplicitRights` ne doit pas \xEAtre configur\xE9\
        \ ou avoir une valeur diff\xE9rente de 2 pour atteindre le niveau 3 ; cette\
        \ valeur doit \xEAtre explicitement positionn\xE9e \xE0 1 pour atteindre le\
        \ niveau 5.\n\nLa correction est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide\
        \ des consoles `adsiedit.msc` ou de l'utilitaire `ldp`. L'attribut `dSHeuristics`\
        \ a un format particulier, dont la description est donn\xE9e dans la [documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5)."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Dangerous dsHeuristics settings (Level 3)
          description: '# Vulnerability description


            Dangerous values are set for the `dSHeuristics` attribute. Depending on
            severity, this issue can be raised at levels <span style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">1</span> or <span style="background-color:rgb(255,
            165, 0);color:rgb(0, 0, 0)">2</span>:


            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            if `fAllowAnonNSPI` differs from 0;

            * <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">1</span>
            if `dwAdminSDExMask` differs from 0;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `fLDAPBlockAnonOps` equals 2;

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `DoNotVerifyUPNAndOrSPNUniqueness` differs from 0 (KB5008382);

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `AttributeAuthorizationOnLDAPAdd` equals 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1));

            * <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)">2</span>
            if `BlockOwnerImplicitRights` equals 2 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1));

            * <span style="background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)">4</span>
            if `AttributeAuthorizationOnLDAPAdd` differs from 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1));

            * <span style="background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)">4</span>
            if `BlockOwnerImplicitRights` differs from 1 ([KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)).


            The following values are set in the `dSHeuristics` attribute. Empty values
            mean that no value has been explicitely defined. In this case, the default
            value is used. For example, setting `dSHeuristics` to `00000000010000000002000000011`
            allows reaching level <span style="background-color:rgb(40, 167, 69);color:rgb(255,
            255, 255)">5</span>, as this value sets every field to their default value,
            except `BlockOwnerImplicitRights` and `AttributeAuthorizationOnLDAPAdd`
            which are set to `1`.'
          annotation: '# Recommended measure


            The `dSHeuristics` attribute ([documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5))defines
            some heuristics later used to alter some Active Directory mechanisms.
            For instance:


            * `fLDAPBlockAnonOps` enables unauthenticated LDAP operations;

            * `fAllowAnonNSPI` controls anonymous access to the Name Service Provider
            Interface (NSPI);

            * `dwAdminSDExMask` defines which groups are covered by the SDProp mechanism;

            * `DoNotVerifyUPNAndOrSPNUniqueness` disables checks on UPN / SPN uniqueness;

            * `AttributeAuthorizationOnLDAPAdd` disables the auditing and enforcement
            of [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1);

            * `BlockOwnerImplicitRights` disables the auditing and enforcement of
            [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1).


            These dangerous `dSHeuristics` settings must be reset to their default
            value.


            * `fLDAPBlockAnonOps` should not be set or should have any value other
            than 2;

            * `fAllowAnonNSPI` should be set to 0;

            * `dwAdminSDExMask` should be set to 0;

            * `DoNotVerifyUPNAndOrSPNUniqueness` should be set to 0;

            * `AttributeAuthorizationOnLDAPAdd` should not be set or should have any
            value other than 2 to reach level 3; it must be explicitely set to 1 to
            reach level 5;

            * `BlockOwnerImplicitRights` should not be set or should have any value
            other than 2 to reach level 3; it must be explicitely set to 1 to reach
            level 5.


            The fix is usually applied through the `adsiedit.msc` or `ldp` utilities.
            The `dSHeuristics` attribute uses a specific format that is described
            in the [documentation](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_functional_level-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_functional_level-l1
      name: "Niveaux fonctionnels de la for\xEAt et des domaines insuffisants (Niveau\
        \ 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLe niveau fonctionnel\
        \ de la for\xEAt ou des domaines est insuffisant. L'utilisation d'un niveau\
        \ fonctionnel Active Directory faible prive la for\xEAt de fonctionnalit\xE9\
        s de s\xE9curit\xE9 importantes.\n\n## Seuils de tol\xE9rance\n\nCe point\
        \ de contr\xF4le appara\xEEt selon des seuils de tol\xE9rance diff\xE9rents\
        \ en fonction du niveau de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> si le\
        \ niveau fonctionnel de la for\xEAt est inf\xE9rieur \xE0 <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">Windows 2008R2</span>;\n* au niveau <span\
        \ style=\"background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)\">3</span>\
        \ si le niveau fonctionnel de la for\xEAt est inf\xE9rieur \xE0 <span style=\"\
        background-color:rgb(18, 41, 77);color:rgb(255, 255, 255)\">Windows 2012R2</span>;\n\
        * au niveau <span style=\"background-color:rgb(0, 123, 255);color:rgb(255,\
        \ 255, 255)\">4</span> si le niveau fonctionnel de la for\xEAt est inf\xE9\
        rieur \xE0 <span style=\"background-color:rgb(40, 167, 69);color:rgb(255,\
        \ 255, 255)\">Windows 2016 / 2019 / 2022</span>."
      annotation: "# Recommandation\n\nDans les environnements Active Directory, certains\
        \ m\xE9canismes sont li\xE9s aux niveaux fonctionnels qui peuvent \xEAtre\
        \ au niveau for\xEAt ou domaine. Les niveaux fonctionnels sont caract\xE9\
        ris\xE9s par un chiffre allant de **0** (<span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">Windows 2000</span>) \xE0 **7** (<span\
        \ style=\"background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)\">Windows\
        \ 2016 / 2019 / 2022</span>). Afin de b\xE9n\xE9ficier des derni\xE8res fonctionnalit\xE9\
        s de s\xE9curit\xE9, il est important d'augmenter les niveaux fonctionnels\
        \ des domaines ainsi que de la for\xEAt. Chaque niveau fonctionnel apporte\
        \ des fonctionnalit\xE9s de s\xE9curit\xE9 :\n\n* niveau de fonctionnalit\xE9\
        \ 2 (<span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\"\
        >Windows 2003</span>) : ajoute les relations d'approbation de for\xEAts et\
        \ le support des contr\xF4leurs de domaine en lecture seule (RODC) ;\n* niveau\
        \ de fonctionnalit\xE9 3 (<span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">Windows 2008</span>) : permet la prise en charge des algorithmes\
        \ de chiffrement robustes comme AES et *DFS* (Distributed File System) pour\
        \ la r\xE9plication des partages `SYSVOL`;\n* niveau de fonctionnalit\xE9\
        \ 4 (<span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\"\
        >Windows 2008R2</span>) : permet l'utilisation de la fonctionnalit\xE9 de\
        \ corbeille AD (protection contre les suppressions accidentelles d'objets)\
        \ ;\n* niveau de fonctionnalit\xE9 5 (<span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">Windows 2012</span>) : permet l'utilisation\
        \ des fonctionnalit\xE9s avanc\xE9es de Kerberos comme l'authentification\
        \ compos\xE9e et les claims;\n* niveau de fonctionnalit\xE9 6 (<span style=\"\
        background-color:rgb(18, 41, 77);color:rgb(255, 255, 255)\">Windows 2012R2</span>)\
        \ : introduit de nombreuses fonctionnalit\xE9s de s\xE9curit\xE9 comme les\
        \ politiques et silos d'authentification et le groupe *Protected users* (Protected\
        \ users);\n* niveau de fonctionnalit\xE9 7 (<span style=\"background-color:rgb(40,\
        \ 167, 69);color:rgb(255, 255, 255)\">Windows 2016 / 2019 / 2022</span>) :\
        \ am\xE9liore la s\xE9curit\xE9 des comptes lorsque l'authentification par\
        \ carte \xE0 puce est utilis\xE9e et ajoute les relations d'approbation de\
        \ for\xEAt de type Privileged Identity Management (PIM).\n\nPour augmenter\
        \ le niveau fonctionnel d'un domaine, il est n\xE9cessaire de mettre \xE0\
        \ niveau l'ensemble des contr\xF4leurs de domaine vers un syst\xE8me d'exploitation\
        \ supportant le niveau d\xE9sir\xE9 et de r\xE9aliser une migration au niveau\
        \ fonctionnel sup\xE9rieur.\n\nDe m\xEAme, pour augmenter le niveau fonctionnel\
        \ d'une for\xEAt, il est n\xE9cessaire que l'ensemble des domaines soient\
        \ dans un niveau fonctionnel \xE9quivalent ou sup\xE9rieur.\n\nNote : il est\
        \ n\xE9cessaire de v\xE9rifier la compatibilit\xE9 du niveau fonctionnel avec\
        \ les logiciels tiers install\xE9s. Par exemple, pour Microsoft Exchange :\
        \ [matrice de compatibilit\xE9](https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Insufficient forest and domains functional levels (Level 1)
          description: '# Vulnerability description


            The current forest or domain functional level is insufficient. Using a
            weak functional level deprives the forest from important security features.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> if the forest functional level is lower than <span
            style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">Windows
            2008R2</span>;

            * at level <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> if the forest functional level is lower than <span style="background-color:rgb(18,
            41, 77);color:rgb(255, 255, 255)">Windows 2012R2</span>;

            * at level <span style="background-color:rgb(0, 123, 255);color:rgb(255,
            255, 255)">4</span> if the forest functional level is lower than <span
            style="background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)">Windows
            2016 / 2019 / 2022</span>.'
          annotation: '# Recommended measure


            In Active Directory environments, some mechanisms are linked to functional
            levels which are set at either the forest or domain level. Functional
            levels are identified by a digit from **0** (<span style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">Windows 2000</span>) to **7** (<span
            style="background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)">Windows
            2016 / 2019 / 2022</span>). In order to leverage the latest security features,
            one must raise domain and forest functional levels. Each functional level
            brings new security features:


            * functional level 2 (<span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">Windows 2003</span>): brings forest trusts and read-only domain
            controller (RODC) support;

            * functional level 3 (<span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">Windows 2008</span>): brings support for modern cryptographic
            algorithms such as AES and *DFS* (Distributed File System) for `SYSVOL`
            share replication;

            * functional level 4 (<span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">Windows 2008R2</span>): brings support for Active Directory
            Recycle Bin (protects objects against accidental deletion);

            * functional level 5 (<span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">Windows 2012</span>): brings advanced Kerberos features, such as
            compound authentication and claims support;

            * functional level 6 (<span style="background-color:rgb(18, 41, 77);color:rgb(255,
            255, 255)">Windows 2012R2</span>): brings numerous new security features
            such as authentication policies, authentication policy silos and the *Protected
            users* (Protected users) group;

            * functional level 7 (<span style="background-color:rgb(40, 167, 69);color:rgb(255,
            255, 255)">Windows 2016 / 2019 / 2022</span>): brings an upgraded smart
            card logon security and Privileged Identity Management (PIM) trust relationships
            between forests.


            To raise a domain functional level, all of its domain controllers must
            be upgraded to an operating system which supports the desired functional
            level.


            The same applies to raise a forest functional level: raising all of its
            domains to a greater or equal functional level is required.


            Note: compatibility with the target functional level must be checked for
            all third-party software. Refer to the Microsoft Exchange Server supportability
            matrix for such an instance where incompatibility could arise: [https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019](https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_functional_level-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_functional_level-l3
      name: "Niveaux fonctionnels de la for\xEAt et des domaines insuffisants (Niveau\
        \ 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLe niveau fonctionnel\
        \ de la for\xEAt ou des domaines est insuffisant. L'utilisation d'un niveau\
        \ fonctionnel Active Directory faible prive la for\xEAt de fonctionnalit\xE9\
        s de s\xE9curit\xE9 importantes.\n\n## Seuils de tol\xE9rance\n\nCe point\
        \ de contr\xF4le appara\xEEt selon des seuils de tol\xE9rance diff\xE9rents\
        \ en fonction du niveau de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> si le\
        \ niveau fonctionnel de la for\xEAt est inf\xE9rieur \xE0 <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">Windows 2008R2</span>;\n* au niveau <span\
        \ style=\"background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)\">3</span>\
        \ si le niveau fonctionnel de la for\xEAt est inf\xE9rieur \xE0 <span style=\"\
        background-color:rgb(18, 41, 77);color:rgb(255, 255, 255)\">Windows 2012R2</span>;\n\
        * au niveau <span style=\"background-color:rgb(0, 123, 255);color:rgb(255,\
        \ 255, 255)\">4</span> si le niveau fonctionnel de la for\xEAt est inf\xE9\
        rieur \xE0 <span style=\"background-color:rgb(40, 167, 69);color:rgb(255,\
        \ 255, 255)\">Windows 2016 / 2019 / 2022</span>."
      annotation: "# Recommandation\n\nDans les environnements Active Directory, certains\
        \ m\xE9canismes sont li\xE9s aux niveaux fonctionnels qui peuvent \xEAtre\
        \ au niveau for\xEAt ou domaine. Les niveaux fonctionnels sont caract\xE9\
        ris\xE9s par un chiffre allant de **0** (<span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">Windows 2000</span>) \xE0 **7** (<span\
        \ style=\"background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)\">Windows\
        \ 2016 / 2019 / 2022</span>). Afin de b\xE9n\xE9ficier des derni\xE8res fonctionnalit\xE9\
        s de s\xE9curit\xE9, il est important d'augmenter les niveaux fonctionnels\
        \ des domaines ainsi que de la for\xEAt. Chaque niveau fonctionnel apporte\
        \ des fonctionnalit\xE9s de s\xE9curit\xE9 :\n\n* niveau de fonctionnalit\xE9\
        \ 2 (<span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\"\
        >Windows 2003</span>) : ajoute les relations d'approbation de for\xEAts et\
        \ le support des contr\xF4leurs de domaine en lecture seule (RODC) ;\n* niveau\
        \ de fonctionnalit\xE9 3 (<span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">Windows 2008</span>) : permet la prise en charge des algorithmes\
        \ de chiffrement robustes comme AES et *DFS* (Distributed File System) pour\
        \ la r\xE9plication des partages `SYSVOL`;\n* niveau de fonctionnalit\xE9\
        \ 4 (<span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\"\
        >Windows 2008R2</span>) : permet l'utilisation de la fonctionnalit\xE9 de\
        \ corbeille AD (protection contre les suppressions accidentelles d'objets)\
        \ ;\n* niveau de fonctionnalit\xE9 5 (<span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">Windows 2012</span>) : permet l'utilisation\
        \ des fonctionnalit\xE9s avanc\xE9es de Kerberos comme l'authentification\
        \ compos\xE9e et les claims;\n* niveau de fonctionnalit\xE9 6 (<span style=\"\
        background-color:rgb(18, 41, 77);color:rgb(255, 255, 255)\">Windows 2012R2</span>)\
        \ : introduit de nombreuses fonctionnalit\xE9s de s\xE9curit\xE9 comme les\
        \ politiques et silos d'authentification et le groupe *Protected users* (Protected\
        \ users);\n* niveau de fonctionnalit\xE9 7 (<span style=\"background-color:rgb(40,\
        \ 167, 69);color:rgb(255, 255, 255)\">Windows 2016 / 2019 / 2022</span>) :\
        \ am\xE9liore la s\xE9curit\xE9 des comptes lorsque l'authentification par\
        \ carte \xE0 puce est utilis\xE9e et ajoute les relations d'approbation de\
        \ for\xEAt de type Privileged Identity Management (PIM).\n\nPour augmenter\
        \ le niveau fonctionnel d'un domaine, il est n\xE9cessaire de mettre \xE0\
        \ niveau l'ensemble des contr\xF4leurs de domaine vers un syst\xE8me d'exploitation\
        \ supportant le niveau d\xE9sir\xE9 et de r\xE9aliser une migration au niveau\
        \ fonctionnel sup\xE9rieur.\n\nDe m\xEAme, pour augmenter le niveau fonctionnel\
        \ d'une for\xEAt, il est n\xE9cessaire que l'ensemble des domaines soient\
        \ dans un niveau fonctionnel \xE9quivalent ou sup\xE9rieur.\n\nNote : il est\
        \ n\xE9cessaire de v\xE9rifier la compatibilit\xE9 du niveau fonctionnel avec\
        \ les logiciels tiers install\xE9s. Par exemple, pour Microsoft Exchange :\
        \ [matrice de compatibilit\xE9](https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019)."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Insufficient forest and domains functional levels (Level 3)
          description: '# Vulnerability description


            The current forest or domain functional level is insufficient. Using a
            weak functional level deprives the forest from important security features.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> if the forest functional level is lower than <span
            style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">Windows
            2008R2</span>;

            * at level <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> if the forest functional level is lower than <span style="background-color:rgb(18,
            41, 77);color:rgb(255, 255, 255)">Windows 2012R2</span>;

            * at level <span style="background-color:rgb(0, 123, 255);color:rgb(255,
            255, 255)">4</span> if the forest functional level is lower than <span
            style="background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)">Windows
            2016 / 2019 / 2022</span>.'
          annotation: '# Recommended measure


            In Active Directory environments, some mechanisms are linked to functional
            levels which are set at either the forest or domain level. Functional
            levels are identified by a digit from **0** (<span style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">Windows 2000</span>) to **7** (<span
            style="background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)">Windows
            2016 / 2019 / 2022</span>). In order to leverage the latest security features,
            one must raise domain and forest functional levels. Each functional level
            brings new security features:


            * functional level 2 (<span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">Windows 2003</span>): brings forest trusts and read-only domain
            controller (RODC) support;

            * functional level 3 (<span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">Windows 2008</span>): brings support for modern cryptographic
            algorithms such as AES and *DFS* (Distributed File System) for `SYSVOL`
            share replication;

            * functional level 4 (<span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">Windows 2008R2</span>): brings support for Active Directory
            Recycle Bin (protects objects against accidental deletion);

            * functional level 5 (<span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">Windows 2012</span>): brings advanced Kerberos features, such as
            compound authentication and claims support;

            * functional level 6 (<span style="background-color:rgb(18, 41, 77);color:rgb(255,
            255, 255)">Windows 2012R2</span>): brings numerous new security features
            such as authentication policies, authentication policy silos and the *Protected
            users* (Protected users) group;

            * functional level 7 (<span style="background-color:rgb(40, 167, 69);color:rgb(255,
            255, 255)">Windows 2016 / 2019 / 2022</span>): brings an upgraded smart
            card logon security and Privileged Identity Management (PIM) trust relationships
            between forests.


            To raise a domain functional level, all of its domain controllers must
            be upgraded to an operating system which supports the desired functional
            level.


            The same applies to raise a forest functional level: raising all of its
            domains to a greater or equal functional level is required.


            Note: compatibility with the target functional level must be checked for
            all third-party software. Refer to the Microsoft Exchange Server supportability
            matrix for such an instance where incompatibility could arise: [https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019](https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_functional_level-l4
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_functional_level-l4
      name: "Niveaux fonctionnels de la for\xEAt et des domaines insuffisants (Niveau\
        \ 4)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLe niveau fonctionnel\
        \ de la for\xEAt ou des domaines est insuffisant. L'utilisation d'un niveau\
        \ fonctionnel Active Directory faible prive la for\xEAt de fonctionnalit\xE9\
        s de s\xE9curit\xE9 importantes.\n\n## Seuils de tol\xE9rance\n\nCe point\
        \ de contr\xF4le appara\xEEt selon des seuils de tol\xE9rance diff\xE9rents\
        \ en fonction du niveau de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> si le\
        \ niveau fonctionnel de la for\xEAt est inf\xE9rieur \xE0 <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">Windows 2008R2</span>;\n* au niveau <span\
        \ style=\"background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)\">3</span>\
        \ si le niveau fonctionnel de la for\xEAt est inf\xE9rieur \xE0 <span style=\"\
        background-color:rgb(18, 41, 77);color:rgb(255, 255, 255)\">Windows 2012R2</span>;\n\
        * au niveau <span style=\"background-color:rgb(0, 123, 255);color:rgb(255,\
        \ 255, 255)\">4</span> si le niveau fonctionnel de la for\xEAt est inf\xE9\
        rieur \xE0 <span style=\"background-color:rgb(40, 167, 69);color:rgb(255,\
        \ 255, 255)\">Windows 2016 / 2019 / 2022</span>."
      annotation: "# Recommandation\n\nDans les environnements Active Directory, certains\
        \ m\xE9canismes sont li\xE9s aux niveaux fonctionnels qui peuvent \xEAtre\
        \ au niveau for\xEAt ou domaine. Les niveaux fonctionnels sont caract\xE9\
        ris\xE9s par un chiffre allant de **0** (<span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">Windows 2000</span>) \xE0 **7** (<span\
        \ style=\"background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)\">Windows\
        \ 2016 / 2019 / 2022</span>). Afin de b\xE9n\xE9ficier des derni\xE8res fonctionnalit\xE9\
        s de s\xE9curit\xE9, il est important d'augmenter les niveaux fonctionnels\
        \ des domaines ainsi que de la for\xEAt. Chaque niveau fonctionnel apporte\
        \ des fonctionnalit\xE9s de s\xE9curit\xE9 :\n\n* niveau de fonctionnalit\xE9\
        \ 2 (<span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\"\
        >Windows 2003</span>) : ajoute les relations d'approbation de for\xEAts et\
        \ le support des contr\xF4leurs de domaine en lecture seule (RODC) ;\n* niveau\
        \ de fonctionnalit\xE9 3 (<span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">Windows 2008</span>) : permet la prise en charge des algorithmes\
        \ de chiffrement robustes comme AES et *DFS* (Distributed File System) pour\
        \ la r\xE9plication des partages `SYSVOL`;\n* niveau de fonctionnalit\xE9\
        \ 4 (<span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\"\
        >Windows 2008R2</span>) : permet l'utilisation de la fonctionnalit\xE9 de\
        \ corbeille AD (protection contre les suppressions accidentelles d'objets)\
        \ ;\n* niveau de fonctionnalit\xE9 5 (<span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">Windows 2012</span>) : permet l'utilisation\
        \ des fonctionnalit\xE9s avanc\xE9es de Kerberos comme l'authentification\
        \ compos\xE9e et les claims;\n* niveau de fonctionnalit\xE9 6 (<span style=\"\
        background-color:rgb(18, 41, 77);color:rgb(255, 255, 255)\">Windows 2012R2</span>)\
        \ : introduit de nombreuses fonctionnalit\xE9s de s\xE9curit\xE9 comme les\
        \ politiques et silos d'authentification et le groupe *Protected users* (Protected\
        \ users);\n* niveau de fonctionnalit\xE9 7 (<span style=\"background-color:rgb(40,\
        \ 167, 69);color:rgb(255, 255, 255)\">Windows 2016 / 2019 / 2022</span>) :\
        \ am\xE9liore la s\xE9curit\xE9 des comptes lorsque l'authentification par\
        \ carte \xE0 puce est utilis\xE9e et ajoute les relations d'approbation de\
        \ for\xEAt de type Privileged Identity Management (PIM).\n\nPour augmenter\
        \ le niveau fonctionnel d'un domaine, il est n\xE9cessaire de mettre \xE0\
        \ niveau l'ensemble des contr\xF4leurs de domaine vers un syst\xE8me d'exploitation\
        \ supportant le niveau d\xE9sir\xE9 et de r\xE9aliser une migration au niveau\
        \ fonctionnel sup\xE9rieur.\n\nDe m\xEAme, pour augmenter le niveau fonctionnel\
        \ d'une for\xEAt, il est n\xE9cessaire que l'ensemble des domaines soient\
        \ dans un niveau fonctionnel \xE9quivalent ou sup\xE9rieur.\n\nNote : il est\
        \ n\xE9cessaire de v\xE9rifier la compatibilit\xE9 du niveau fonctionnel avec\
        \ les logiciels tiers install\xE9s. Par exemple, pour Microsoft Exchange :\
        \ [matrice de compatibilit\xE9](https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019)."
      implementation_groups:
      - level_4
      translations:
        en:
          name: Insufficient forest and domains functional levels (Level 4)
          description: '# Vulnerability description


            The current forest or domain functional level is insufficient. Using a
            weak functional level deprives the forest from important security features.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> if the forest functional level is lower than <span
            style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">Windows
            2008R2</span>;

            * at level <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> if the forest functional level is lower than <span style="background-color:rgb(18,
            41, 77);color:rgb(255, 255, 255)">Windows 2012R2</span>;

            * at level <span style="background-color:rgb(0, 123, 255);color:rgb(255,
            255, 255)">4</span> if the forest functional level is lower than <span
            style="background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)">Windows
            2016 / 2019 / 2022</span>.'
          annotation: '# Recommended measure


            In Active Directory environments, some mechanisms are linked to functional
            levels which are set at either the forest or domain level. Functional
            levels are identified by a digit from **0** (<span style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">Windows 2000</span>) to **7** (<span
            style="background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)">Windows
            2016 / 2019 / 2022</span>). In order to leverage the latest security features,
            one must raise domain and forest functional levels. Each functional level
            brings new security features:


            * functional level 2 (<span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">Windows 2003</span>): brings forest trusts and read-only domain
            controller (RODC) support;

            * functional level 3 (<span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">Windows 2008</span>): brings support for modern cryptographic
            algorithms such as AES and *DFS* (Distributed File System) for `SYSVOL`
            share replication;

            * functional level 4 (<span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">Windows 2008R2</span>): brings support for Active Directory
            Recycle Bin (protects objects against accidental deletion);

            * functional level 5 (<span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">Windows 2012</span>): brings advanced Kerberos features, such as
            compound authentication and claims support;

            * functional level 6 (<span style="background-color:rgb(18, 41, 77);color:rgb(255,
            255, 255)">Windows 2012R2</span>): brings numerous new security features
            such as authentication policies, authentication policy silos and the *Protected
            users* (Protected users) group;

            * functional level 7 (<span style="background-color:rgb(40, 167, 69);color:rgb(255,
            255, 255)">Windows 2016 / 2019 / 2022</span>): brings an upgraded smart
            card logon security and Privileged Identity Management (PIM) trust relationships
            between forests.


            To raise a domain functional level, all of its domain controllers must
            be upgraded to an operating system which supports the desired functional
            level.


            The same applies to raise a forest functional level: raising all of its
            domains to a greater or equal functional level is required.


            Note: compatibility with the target functional level must be checked for
            all third-party software. Refer to the Microsoft Exchange Server supportability
            matrix for such an instance where incompatibility could arise: [https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019](https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_kerberos_properties_preauth_priv-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_kerberos_properties_preauth_priv-l1
      name: "Comptes privil\xE9gi\xE9s sans pr\xE9authentification Kerberos (Niveau\
        \ 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes privil\xE9\
        gi\xE9s n'imposent pas la pr\xE9authentification Kerberos."
      annotation: "# Recommandation\n\nLa pr\xE9authentification permet de s'assurer\
        \ que l'utilisateur conna\xEEt un de ses secrets d'authentification lors d'une\
        \ demande de TGT (ticket Kerberos obtenu aupr\xE8s d'un contr\xF4leur de domaine).\
        \ Sans pr\xE9authentification il est possible d'obtenir un ticket chiffr\xE9\
        \ avec un des secrets associ\xE9s au compte correspondant. Il est ensuite\
        \ possible de lancer une attaque afin de retrouver le mot de passe de l'utilisateur,\
        \ ce qui peut \xEAtre facilit\xE9 s'il n'est pas assez robuste.\n\nLa propri\xE9\
        t\xE9 <code style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">DONT_REQUIRE_PREAUTH</code> doit \xEAtre supprim\xE9e pour ces comptes\
        \ et le mot de passe doit \xEAtre chang\xE9.\n\nPar d\xE9faut, tous les comptes\
        \ utilisateur imposent la pr\xE9authentification car la propri\xE9t\xE9 <code\
        \ style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">DONT_REQUIRE_PREAUTH</code>\
        \ n'est pas positionn\xE9e. Cette propri\xE9t\xE9 ne doit jamais \xEAtre positionn\xE9\
        e pour les comptes privil\xE9gi\xE9s du domaine. En cas d'incompatibilit\xE9\
        \ avec une application, celle-ci doit faire l'objet d'une \xE9volution applicative.\n\
        \n## Contexte : groupes privil\xE9gi\xE9s\n\nLes groupes privil\xE9gi\xE9\
        s sont les groupes d'administration et les groupes op\xE9ratifs ayant tous\
        \ les droits et privil\xE8ges sur la for\xEAt ou pouvant se les attribuer\
        \ :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n* \xAB *Contr\xF4\
        leurs de domaine* (Domain Controllers) \xBB;\n* \xAB *Administrateurs du sch\xE9\
        ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs de l'entreprise* (Enterprise\
        \ Admins) \xBB ;\n* \xAB *Administrateurs du domaine* (Domain Admins) \xBB\
        \ : ces administrateurs ont les privil\xE8ges de lire la base des secrets\
        \ de tous les comptes et donc d'extraire les secrets de l'ensemble des comptes\
        \ privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de cl\xE9s* (Key Admins) \xBB\
        \ et \xAB *Administrateurs de cl\xE9s de l'entreprise* (Enterprise Key Admins)\
        \ \xBB: ces administrateurs peuvent fixer des valeurs arbitraires aux attributs\
        \ relatifs \xE0 Windows Hello for Business, pour tous les utilisateurs sauf\
        \ ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`. Si l'authentification\
        \ bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9e, ils peuvent g\xE9n\xE9\
        rer un certificat sous leur contr\xF4le, l'assigner \xE0 un compte privil\xE9\
        gi\xE9 (par exemple, un contr\xF4leur de domaine), et s'authentifier en tant\
        \ que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account Operators) \xBB : ces\
        \ op\xE9rateurs peuvent administrer tous les comptes d'utilisateurs, machines\
        \ et groupes; \xE0 l'exception des comptes prot\xE9g\xE9s par l' `adminSDHolder`;\n\
        * \xAB *Op\xE9rateurs de serveur* (Server Operators) \xBB : ces op\xE9rateurs\
        \ peuvent administrer les contr\xF4leurs de domaine, et donc r\xE9cup\xE9\
        rer les secrets de tous les comptes privil\xE9gi\xE9s ;\n* \xAB *Op\xE9rateurs\
        \ de sauvegarde* (Backup Operators) \xBB : ces op\xE9rateurs peuvent sauvegarder\
        \ un contr\xF4leur de domaine et donc extraire les secrets de tous les comptes\
        \ privil\xE9gi\xE9s depuis cette sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression*\
        \ (Print Operators) \xBB : ces op\xE9rateurs peuvent charger des pilotes d'impression\
        \ sur les contr\xF4leurs de domaine et donc charger un pilote malveillant\
        \ pour par exemple extraire les secrets de tous les comptes privil\xE9gi\xE9\
        s.\n\nLes groupes \xAB op\xE9rateurs \xBB sont vides par d\xE9faut et ne devraient\
        \ contenir aucun membre."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Kerberos preauthentication disabled for privileged accounts (Level
            1)
          description: '# Vulnerability description


            The <code style="background-color:rgb(220, 53, 69);color:rgb(255, 255,
            255)">DONT_REQUIRE_PREAUTH</code> flag is set for some privileged users.'
          annotation: '# Recommended measure


            Kerberos preauthentication ensures that users requesting a Ticket Granting
            Ticket (TGT) know a given authentication secret. Without preauthentication,
            it is possible to acquire a ticket encrypted with one of the Kerberos
            keys associated with the requested account. It is then possible to carry
            out a brute force or dictionary guessing attack to crack an account password
            if it is not strong enough.


            All affected accounts must have their <code style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">DONT_REQUIRE_PREAUTH</code> flag unset
            then their password changed immediately.


            By default, all user accounts require preauthentication because their
            <code style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">DONT_REQUIRE_PREAUTH</code>
            flag is not set. That property was designed for backward compatibility
            with older Kerberos implementations. It must never be set for privileged
            domain accounts. Any incompatible software must be upgraded.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_password_change_dc_no_change-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_password_change_dc_no_change-l1
      name: "Contr\xF4leurs de domaine dont le mot de passe de compte d'ordinateur\
        \ est inchang\xE9 depuis plus de 45 jours (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes contr\xF4leurs\
        \ de domaine n'ont pas chang\xE9 le mot de passe de leur compte d'ordinateur\
        \ depuis plus de 45 jours, ce qui indique que leurs secrets ne sont pas renouvel\xE9\
        s."
      annotation: "# Recommandation\n\nDans leur fonctionnement par d\xE9faut, les\
        \ contr\xF4leurs de domaine changent automatiquement le mot de passe de leur\
        \ compte d'ordinateur p\xE9riodiquement (30 jours par d\xE9faut). Il convient\
        \ d'investiguer la raison qui emp\xEAche le contr\xF4leur de domaine de changer\
        \ son mot de passe.\n\nUne premi\xE8re v\xE9rification consiste \xE0 v\xE9\
        rifier la valeur des entr\xE9es de Registre suivantes :\n\n* `HKLM\\System\\\
        CurrentControlSet\\Services\\Netlogon\\Parameters\\DisablePasswordChange`:\
        \ doit valoir 0 ou ne pas exister ;\n* `HKLM\\System\\CurrentControlSet\\\
        Services\\Netlogon\\Parameters\\MaximumPasswordAge`: doit valoir 30.\n\nSi\
        \ ces valeurs sont incorrectes, il convient de les remettre aux valeurs par\
        \ d\xE9faut et de s'assurer qu'elles ne sont pas positionn\xE9es par une GPO.\n\
        \nSi ces valeurs sont correctes, v\xE9rifier si le service `NETLOGON` est\
        \ d\xE9marr\xE9 avec `sc.exe query netlogon`.\n\nEnfin, il faut v\xE9rifier\
        \ que le mot de passe de la machine soit synchronis\xE9 avec celui du compte\
        \ machine dans l'annuaire. Ceci peut \xEAtre v\xE9rifi\xE9 avec la commande\
        \ `nltest /SC_VERIFY:<DomainName>`, o\xF9 `DomainName` correspond au nom NetBIOS\
        \ du domaine. Dans les deux v\xE9rifications effectu\xE9es, la commande doit\
        \ indiquer le code de retour `0 0x0 NERR_Success`."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Domain controllers with passwords unchanged for more than 45 days
            (Level 1)
          description: '# Vulnerability description


            Some domain controllers have not changed their password for more than
            45 days, indicating their secrets are not renewed.'
          annotation: '# Recommended measure


            Default domain controller settings have them change their passwords automatically
            every 30 days. The reason for this change not to occur properly must be
            investigated as it may be indicative of a compromise.


            First, check the following registry values:


            * `HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange`:
            must be set to 0 or inexistent;

            * `HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge`:
            must be set to 30.


            Incorrect values should be reset to their default setting, and GPOs must
            be checked to ensure they do not override those.


            If these values are correct, check if the `NETLOGON` service is started
            with `sc.exe query netlogon`.


            Finally, proper synchronization between the machine password and that
            of the machine account in the Active Directory database must be validated.
            Running `nltest /SC_VERIFY:<DomainName>` (with `DomainName` being the
            domain NetBIOS name) can check the synchronization status, and should
            display `0 0x0 NERR_Success` for both verifications.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_password_change_inactive_dc-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_password_change_inactive_dc-l1
      name: "Contr\xF4leurs de domaines inactifs (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes contr\xF4leurs\
        \ de domaine ne se sont pas authentifi\xE9s depuis plus de 45 jours."
      annotation: "# Recommandation\n\nDans leur fonctionnement par d\xE9faut, les\
        \ contr\xF4leurs de domaine doivent s'authentifier et changer automatiquement\
        \ leur mot de passe sur le domaine tous les 30 jours.\n\nL'absence d'authentification\
        \ au domaine est symptomatique d'une machine d\xE9synchronis\xE9e. Les contr\xF4\
        leurs de domaine d\xE9synchronis\xE9s du domaine doivent \xEAtre r\xE9install\xE9\
        s ou supprim\xE9s. Dans le cas d'une r\xE9installation, afin d'\xE9viter le\
        \ chemin de contr\xF4le de type <span style=\"background-color:rgb(220, 53,\
        \ 69);color:rgb(255, 255, 255)\">OWNER</span> du compte d'ordinateur, il est\
        \ recommand\xE9 d'effectuer une jonction de domaine hors connexion \xE0 l'aide\
        \ de l'utilitaire [Djoin](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/ff793312(v%3Dws.11))."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Inactive domain controllers (Level 1)
          description: '# Vulnerability description


            Some domain controllers have not authenticated themselves for more than
            45 days.'
          annotation: '# Recommended measure


            Domain controllers must authenticate and change their passwords at least
            every 30 days.


            Lack of domain authentication reveals out-of-sync machines. Out-of-sync
            domain controllers must be either reinstalled or removed. When reinstalling
            an out-of-sync domain controller, care must be taken not to introduce
            a new <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255,
            255)">OWNER</span> control path exposing its computer account. To avoid
            doing so, use of the [Djoin](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/ff793312(v%3Dws.11))
            utility is advised.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_password_change_priv-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_password_change_priv-l1
      name: "Comptes privil\xE9gi\xE9s dont le mot de passe est inchang\xE9 depuis\
        \ plus de 3 ans (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa date de dernier\
        \ changement du mot de passe de comptes privil\xE9gi\xE9s est sup\xE9rieure\
        \ \xE0 3 ans."
      annotation: "# Recommandation\n\n## Cas g\xE9n\xE9ral\n\nAfin de limiter l'impact\
        \ en cas de vol d'un mot de passe, il est n\xE9cessaire de mettre en \u0153\
        uvre une politique de renouvellement des mots de passe pour les comptes privil\xE9\
        gi\xE9s. La dur\xE9e de ce renouvellement doit \xEAtre inf\xE9rieure \xE0\
        \ 3 ans.\n\nLe compte \xAB Administrateur int\xE9gr\xE9 \xBB (RID 500, utilis\xE9\
        \ en tant que compte bris de glace ne devant jamais \xEAtre utilis\xE9 sauf\
        \ en de rares exceptions) doit \xE9galement faire l'objet d'un changement\
        \ de mot de passe tous les 3 ans. En effet il est important de s'assurer r\xE9\
        guli\xE8rement que celui-ci est toujours accessible et que les proc\xE9dures\
        \ associ\xE9es \xE0 son utilisation sont toujours correctes.\n\nNote importante\
        \ : il est d\xE9conseill\xE9 de forcer ce renouvellement trop fr\xE9quemment\
        \ (quelques mois). Une demande de renouvellement trop fr\xE9quente induit\
        \ statistiquement un nouveau choix de mot de passe plus faible, ce qui en\
        \ fait une mesure de s\xE9curit\xE9 contre-productive.\n\n## Cas des comptes\
        \ de service\n\nS'il s'agit d'un compte de service o\xF9 le changement de\
        \ mot de passe n'est pas possible, il convient de :\n\n* le retirer de ces\
        \ groupes ;\n* lui conf\xE9rer les d\xE9l\xE9gations n\xE9cessaires \xE0 son\
        \ fonctionnement\n* \xE9tudier la possibilit\xE9 de recourir aux Managed Service\
        \ Accounts (sMSA, gMSA).\n\n## Cas des comptes non utilis\xE9s\n\nIl est n\xE9\
        cessaire de neutraliser les comptes qui ne sont plus utilis\xE9s. Cette m\xE9\
        thode de neutralisation apporte les m\xEAmes avantages que la suppression\
        \ tout en conservant la tra\xE7abilit\xE9 offerte par la simple d\xE9sactivation.\
        \ Pour neutraliser un compte, il faut :\n\n* d\xE9sactiver le compte ;\n*\
        \ le retirer de tous ses groupes ;\n* changer son mot de passe de fa\xE7on\
        \ al\xE9atoire. Pour garantir un mot de passe al\xE9atoire, il est recommand\xE9\
        \ de s\xE9lectionner l\u2019option \xAB Une carte \xE0 puce est n\xE9cessaire\
        \ pour ouvrir une session interactive \xBB dans les propri\xE9t\xE9s du compte.\
        \ Cela revient \xE0 positionner l'attribut <code style=\"background-color:rgb(40,\
        \ 167, 69);color:rgb(255, 255, 255)\">ADS_UF_SMARTCARD_REQUIRED</code> dans\
        \ la propri\xE9t\xE9 `userAccountControl`;\n* \xE9ventuellement, d\xE9placer\
        \ le compte dans une OU d\xE9di\xE9e ;\n* \xE9ventuellement, mettre \xE0 jour\
        \ le champ description du compte afin d'indiquer le contexte de d\xE9sactivation\
        \ (date, raison, etc.).\n\n## Contexte : groupes privil\xE9gi\xE9s\n\nLes\
        \ groupes privil\xE9gi\xE9s sont les groupes d'administration et les groupes\
        \ op\xE9ratifs ayant tous les droits et privil\xE8ges sur la for\xEAt ou pouvant\
        \ se les attribuer :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n\
        * \xAB *Contr\xF4leurs de domaine* (Domain Controllers) \xBB;\n* \xAB *Administrateurs\
        \ du sch\xE9ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs de l'entreprise*\
        \ (Enterprise Admins) \xBB ;\n* \xAB *Administrateurs du domaine* (Domain\
        \ Admins) \xBB : ces administrateurs ont les privil\xE8ges de lire la base\
        \ des secrets de tous les comptes et donc d'extraire les secrets de l'ensemble\
        \ des comptes privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de cl\xE9s* (Key\
        \ Admins) \xBB et \xAB *Administrateurs de cl\xE9s de l'entreprise* (Enterprise\
        \ Key Admins) \xBB: ces administrateurs peuvent fixer des valeurs arbitraires\
        \ aux attributs relatifs \xE0 Windows Hello for Business, pour tous les utilisateurs\
        \ sauf ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`. Si l'authentification\
        \ bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9e, ils peuvent g\xE9n\xE9\
        rer un certificat sous leur contr\xF4le, l'assigner \xE0 un compte privil\xE9\
        gi\xE9 (par exemple, un contr\xF4leur de domaine), et s'authentifier en tant\
        \ que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account Operators) \xBB : ces\
        \ op\xE9rateurs peuvent administrer tous les comptes d'utilisateurs, machines\
        \ et groupes; \xE0 l'exception des comptes prot\xE9g\xE9s par l' `adminSDHolder`;\n\
        * \xAB *Op\xE9rateurs de serveur* (Server Operators) \xBB : ces op\xE9rateurs\
        \ peuvent administrer les contr\xF4leurs de domaine, et donc r\xE9cup\xE9\
        rer les secrets de tous les comptes privil\xE9gi\xE9s ;\n* \xAB *Op\xE9rateurs\
        \ de sauvegarde* (Backup Operators) \xBB : ces op\xE9rateurs peuvent sauvegarder\
        \ un contr\xF4leur de domaine et donc extraire les secrets de tous les comptes\
        \ privil\xE9gi\xE9s depuis cette sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression*\
        \ (Print Operators) \xBB : ces op\xE9rateurs peuvent charger des pilotes d'impression\
        \ sur les contr\xF4leurs de domaine et donc charger un pilote malveillant\
        \ pour par exemple extraire les secrets de tous les comptes privil\xE9gi\xE9\
        s.\n\nLes groupes \xAB op\xE9rateurs \xBB sont vides par d\xE9faut et ne devraient\
        \ contenir aucun membre."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Privileged account passwords age too old (Level 1)
          description: '# Vulnerability description


            Some privileged accounts in the forest have not changed their password
            for more than three years.'
          annotation: "# Recommended measure\n\n## General Case\n\nPasswords should\
            \ be periodically changed for all privileged group members (at most every\
            \ 3 years). To enforce the domain password policy on these accounts, their\
            \ <code style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
            \ 255)\">DONT_EXPIRE</code> flag should not be set. This account flag\
            \ should then be unset, usually by unchecking the \"password never expires\"\
            \ option in the \"Account\" tab of the user properties. Their passwords\
            \ should then be rolled immediately.\n\nThe built-in Administrator account\
            \ (RID 500, used as a last resort only) must also have its password changed\
            \ at most every 3 years. It is crucial to periodically ensure this account\
            \ is in working condition and that its usage guidelines and procedures\
            \ are up to date.\n\nImportant note: passwords should not be renewed too\
            \ often. Enforcing short password lifespans compels users to choose statistically\
            \ weaker passwords, which negates the intended benefits. Password lifespan\
            \ should be determined by taking into account multiple factors such as\
            \ usage context. The password policy may be globally enforced on all domain\
            \ accounts or scoped to select accounts, through the Password Settings\
            \ Object (PSO) mechanism.\n\n## Specific Cases\n\nIf the <code style=\"\
            background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">DONT_EXPIRE</code>\
            \ flag has been set on accounts with difficult-to-change passwords, it\
            \ may mean these accounts are not used for administration purposes (i.e.,\
            \ service accounts). These accounts shall not belong to any privileged\
            \ group. The following must be done:\n\n* remove those accounts from privileged\
            \ groups;\n* grant these accounts the required rights delegations for\
            \ proper operation;\n* document a specific password change procedure;\n\
            * remove the <code style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
            \ 255, 255)\">DONT_EXPIRE</code> flag.\n\n## Unused accounts\n\nUnused\
            \ accounts should be disabled. The following procedure provides similar\
            \ benefits than deletion, while retaining information relevant to audit\
            \ traces. To properly disable an account:\n\n* disable the account;\n\
            * remove all of its group memberships;\n* randomly change its password.\
            \ To enforce a random password, one can check the smart card is required\
            \ for interactive logon flag in the account properties. This is equivalent\
            \ to manually setting the <code style=\"background-color:rgb(40, 167,\
            \ 69);color:rgb(255, 255, 255)\">ADS_UF_SMARTCARD_REQUIRED</code> flag\
            \ of its `userAccountControl` attribute;\n* optionally, move the account\
            \ to a dedicated OU;\n* optionally, update the account description field\
            \ to mention the context for disabling (date, reason, etc.).\n\nThe \xAB\
            \ operators \xBB groups are empty by default and must not have any member.\n\
            \n## Context: privileged groups\n\nPrivileged groups include administrator\
            \ groups and operator groups which have full control over the Active Directory\
            \ forest either by design, or by granting themselves such privileges:\n\
            \n* \xAB *Administrators* (Administrateurs) \xBB;\n* \xAB *Domain Controllers*\
            \ (Contr\xF4leurs de domaine) \xBB;\n* \xAB *Schema Admins* (Administrateurs\
            \ du sch\xE9ma) \xBB;\n* \xAB *Enterprise Admins* (Administrateurs de\
            \ l'entreprise) \xBB;\n* \xAB *Domain Admins* (Administrateurs du domaine)\
            \ \xBB: these administrators are able to read the authentication database\
            \ and extract password hashes and other secrets of all privileged accounts;\n\
            * \xAB *Key Admins* (Administrateurs de cl\xE9s) \xBB and \xAB *Enterprise\
            \ Key Admins* (Administrateurs de cl\xE9s de l'entreprise) \xBB: these\
            \ administrators can set arbitrary values to attributes relating to Windows\
            \ Hello for Business, for all users except those protected by the `adminSDHolder`\
            \ mechanism. If certificate-based authentication has been enabled, they\
            \ can generate a certificate that they control, assign it to privileged\
            \ accounts (for instance, a domain controller), and log on as them;\n\
            * \xAB *Account Operators* (Op\xE9rateurs de compte) \xBB: these operators\
            \ can manage user accounts, machine accounts and groups except accounts\
            \ protected by the `adminSDHolder` mechanism;\n* \xAB *Server Operators*\
            \ (Op\xE9rateurs de serveur) \xBB: these operators can manage domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database;\n* \xAB *Backup Operators* (Op\xE9\
            rateurs de sauvegarde) \xBB: these operators can back up a domain controller,\
            \ which grants them the ability to recover privileged user secrets from\
            \ that backup;\n* \xAB *Print Operators* (Op\xE9rateurs d'impression)\
            \ \xBB: these operators can load arbitrary printer drivers on domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_adminsdholder-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_adminsdholder-l1
      name: Permissions dangereuses sur l'objet adminSDHolder (Niveau 1)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur l'objet `adminSDHolder`. Ces permissions permettent aux comptes\
        \ concern\xE9s de prendre le contr\xF4le complet de l'Active Directory. Dans\
        \ un mod\xE8le d'administration en niveaux (tiered administrative model),\
        \ ces permissions cassent l'\xE9tanch\xE9it\xE9 du Tier 0.\n\nL\xE9gende:\
        \ Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4le indirect\
        \ faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le pr\xE9sente\
        \ des seuils de tol\xE9rance diff\xE9rents en fonction du niveau de s\xE9\
        curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\n## Cas g\xE9n\xE9ral\n\nLes permissions de\
        \ l'objet `adminSDHolder` sont r\xE9guli\xE8rement appliqu\xE9es sur l'ensemble\
        \ des objets prot\xE9g\xE9s (membres des groupes administratifs et op\xE9\
        ratifs) de l'Active Directory. Par d\xE9faut, seuls les objets privil\xE9\
        gi\xE9s poss\xE8dent des droits sur l'objet `adminSDHolder`. Ainsi, ce m\xE9\
        canisme permet de prot\xE9ger les utilisateurs et les groupes les plus privil\xE9\
        gi\xE9s de l'Active Directory.\n\nIl est fortement d\xE9conseill\xE9 de changer\
        \ les permissions par d\xE9faut de cet objet. Ainsi il est recommand\xE9 d'enlever\
        \ les permissions dangereuses sur l'objet `adminSDHolder` afin de revenir\
        \ \xE0 un \xE9tat par d\xE9faut. La correction est g\xE9n\xE9ralement effectu\xE9\
        e \xE0 l'aide du composant logiciel enfichable `ADSI Edit` ou de l'utilitaire\
        \ `ldp`.\n\n## Cas particuliers\n\nDans le cadre de la mise en \u0153uvre\
        \ de for\xEAts d'administration, il est tol\xE9r\xE9 d'ajouter des droits\
        \ \xE0 un groupe sur l' `adminSDHolder` aux conditions suivantes :\n\n* les\
        \ permissions sur ce groupe sont plus restrictives que celles appliqu\xE9\
        es initialement par l'objet `adminSDHolder`;\n* l'h\xE9ritage des permissions\
        \ sur ce groupe est d\xE9sactiv\xE9.\n\nSi une permission est li\xE9e \xE0\
        \ Exchange (par exemple <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>), il est n\xE9cessaire d'appliquer les mises\
        \ \xE0 jour Exchange ad hoc. La documentation relative aux permissions Exchange\
        \ positionn\xE9es sur l'objet `adminSDHolder` est accessible \xE0 cette URL\
        \ :\n\n* [https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server](https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server)\
        \ Information : le contr\xF4le depuis `Exchange Trusted Subsystem` avec <span\
        \ style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\
        \ est un d\xE9faut de configuration qui a \xE9t\xE9 corrig\xE9 par Microsoft.\n\
        \nSi les permissions concernent un compte Azure ADConnect (MSOL), il est n\xE9\
        cessaire de reconfigurer les droits dans l'AD relatifs au compte MSOL sp\xE9\
        cifi\xE9. La documentation relative aux comptes Azure ADConnect (MSOL) est\
        \ accessible \xE0 cette URL :\n\n* [https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account)\
        \ Utiliser la cmdlet `Set-ADSyncRestrictedPermissions` avec `-SkipAdminSdHolders`\
        \ dans les commandes de configuration.\n\n## Contexte : chemins de contr\xF4\
        le\n\nUn chemin de contr\xF4le est compos\xE9 d'un ensemble de relations de\
        \ contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet\
        \ sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les\
        \ chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre\
        \ des cibles, et permettent d'identifier des d\xE9viances dans la gestion\
        \ du domaine, de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9\
        \ autour des cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler\
        \ des moyens de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Cas particulier de\
        \ Microsoft Exchange Server\n\nCertains chemins de contr\xF4le qui apparaissent\
        \ peuvent \xEAtre li\xE9s \xE0 des groupes Exchange b\xE9n\xE9ficiant de permissions\
        \ dangereuses. Deux cas particuliers peuvent se pr\xE9senter :\n\n1. s'il\
        \ s'agit de groupes datant d'une ancienne installation de Exchange Server\
        \ 2007 ou ant\xE9rieure (\"Exchange Enterprise Servers\", \"Exchange Domain\
        \ Servers\" ou \"Exchange Services\") et que cette infrastructure a \xE9t\xE9\
        \ migr\xE9e vers une version 2010 ou ult\xE9rieure, il est recommand\xE9 de\
        \ supprimer ces groupes et les permissions associ\xE9es. [Microsoft fournit\
        \ une proc\xE9dure \xE0 cette fin](https://learn.microsoft.com/fr-fr/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
        2. sinon pour les autres groupes, il convient de v\xE9rifier les contr\xF4\
        les dangereux concern\xE9s pour d\xE9terminer la correction ad\xE9quate (voir\
        \ plus bas).\n\nLes contr\xF4les suivants, uniquement s'ils sont mentionn\xE9\
        s pour un groupe li\xE9 \xE0 Exchange, ont fait l'objet d'un correctif de\
        \ Microsoft :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nAttention\
        \ : certaines des propri\xE9t\xE9s LDAP concern\xE9es par ces \xE9critures\
        \ (`servicePrincipalName` et `altSecurityIdentities`) font partie du property-set\
        \ `Public-Information`. Ainsi, les permissions d'\xE9critures peuvent \xEA\
        tre attribu\xE9es pour chaque attribut unitairement ou le property-set entier,\
        \ auquel cas seul ce dernier sera visible dans la DACL de l'objet concern\xE9\
        .\n\nPour appliquer ce correctif, il est n\xE9cessaire d'effectuer les actions\
        \ suivantes :\n\n* pour Exchange Server 2019 : installer le SU de mai 2022\
        \ sur le CU12 ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2016 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2013 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014260](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
        \ ;\n* pour toutes les versions, apr\xE8s installation des correctifs pr\xE9\
        c\xE9dents : ex\xE9cuter la phase de pr\xE9paration des domaines \"/PrepareAllDomains\"\
        \n  * pour Exchange Server 2019 et 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
        \ /PrepareAllDomains` ou `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
        \ /PrepareAllDomains` depuis le r\xE9pertoire d'installation de Exchange ;\n\
        \  * pour Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
        \ /PrepareAllDomains`;\n  * il est rappel\xE9 que Exchange Server 2010 n'est\
        \ plus support\xE9 par l'\xE9diteur.\n\nPour tout autre chemin de contr\xF4\
        le, une qualification manuelle doit \xEAtre effectu\xE9e pour caract\xE9riser\
        \ le probl\xE8me.\n\n\xC0 titre d'information, la liste des derniers correctifs\
        \ publi\xE9s pour Exchange Server est [disponible ici](https://learn.microsoft.com/fr-fr/exchange/new-features/build-numbers-and-release-dates)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous permissions on the adminSDHolder object (Level 1)
          description: '# Vulnerability description


            Dangerous permissions are set on the `adminSDHolder` object. Permissions
            set on this object may grant trusted objects full control over the Active
            Directory. In a tiered administrative model, these permissions allow compromise
            of Tier 0 objects from lower trust tiers.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: "# Recommended measure\n\n## General Case\n\nPermissions set\
            \ on the `adminSDHolder` object are periodically copied to all protected\
            \ AD objects (privileged built-in group members). By default, only privileged\
            \ objects are granted access rights on the `adminSDHolder` object. This\
            \ mechanism protects the most privileged Active directory users and groups\
            \ from accidental misconfigurations.\n\nModifying default permissions\
            \ set on this object is strongly discouraged. Removing dangerous permissions\
            \ is strongly advised to return the object to its default state. Fixing\
            \ usually requires using `adsiedit.msc` or the `ldp` utility.\n\n## Specific\
            \ Cases\n\nWhen deploying an administration forest, granting access rights\
            \ on the `adminSDHolder` object to a group is tolerated given the following\
            \ cumulative criteria are met:\n\n* access rights on the trusted group\
            \ are stricter than those initially granted on the `adminSDHolder` object;\n\
            * permission inheritance is disabled for the trusted group.\n\nIf a flagged\
            \ access right relates to Exchange, (such as <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>), the latest relevant\
            \ cumulative updates must be applied. Documentation on access rights granted\
            \ to Exchange Server is available at the following URL:\n\n* [https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server](https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server)\
            \ Note: if flagged, the <span style=\"background-color:rgb(0, 123, 255);color:rgb(255,\
            \ 255, 255)\">WRITE_ALT_IDENTITY</span> access right granted to `Exchange\
            \ Trusted Subsystem` is a configuration defect that has been fixed by\
            \ Microsoft in a previous update.\n\nIf a flagged access right relates\
            \ to an Azure adconnect account (MSOL), its relevant access rights must\
            \ be reconfigured. Documentation is available at the following URL:\n\n\
            * [https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account)\
            \ PowerShell cmdlets `Set-ADSyncRestrictedPermissions` with `-SkipAdminSdHolders`\
            \ may be used during the configuration phase.\n\n## Context: control path\
            \ exposure\n\nA control path materializes through a set of granted access\
            \ permissions: each granted permission can be expressed as one object\
            \ controlling another through a specific property, attribute or setting.\
            \ Control paths reveal how an attacker could leverage a chain of defective\
            \ or dangerous permissions to gain control of some targets. They can also\
            \ be leveraged to quickly identify domain mismanagement, to validate the\
            \ actual security boundary of a particular scope (making sure some object\
            \ of interest cannot be taken over by unauthorized users through misconfiguration).\
            \ Indicators of compromise may also be found through control path review.\n\
            \n## Limitations\n\nSome control paths may have fixes that renders them\
            \ non-exploitable. Such a case usually requires having all domain controllers\
            \ equally up to date. Furthermore, dangerous features may sometimes be\
            \ re-enabled through a registry or dsHeuristics setting. It is therefore\
            \ still recommended to clean the affected permissions from your Active\
            \ Directory to prevent an accidental re-occurrence.\n\nList of known specific\
            \ fixes:\n\n* [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
            \ fixes the <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">OWNER</span> and <span style=\"background-color:rgb(255, 165,\
            \ 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> control path on computer\
            \ accounts only, but the dangerous behavior can still be re-enabled.\n\
            * Various Exchange-related control paths have been fixed through specific\
            \ cumulative updates; refer to the dedicated section below if applicable.\n\
            \n## Microsoft Exchange Server Specifics\n\nSome control paths under this\
            \ item may appear because of Exchange Server management groups with excessive\
            \ permissions. The cause can be:\n\n1. either the offending groups come\
            \ from a legacy Exchange Server 2007 or earlier instance (\"Exchange Enterprise\
            \ Servers\", \"Exchange Domain Servers\" ou \"Exchange Services\") which\
            \ has been migrated to version 2010 or later, it is then best to remove\
            \ those groups and associated permissions. [Microsoft provides relevant\
            \ guidance to fix these issues](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
            2. or these are current Exchange Server management groups, a specific\
            \ analysis will help select the applicable solution (see below).\n\nThe\
            \ following controls have been fixed by Microsoft, only if pertaining\
            \ to Exchange Server groups:\n\n* <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>\n* <span style=\"\
            background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n\
            * <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
            \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nWarning:\
            \ some LDAP attributes (`servicePrincipalName` and `altSecurityIdentities`)\
            \ behind these controls belong to the `Public-Information` property set.\
            \ Therefore, these write permissions may be granted on an attribute basis\
            \ or to the whole property set, in which case only this property set will\
            \ be visible in the object's DACL.\n\nApplying the official fix involves\
            \ the following steps:\n\n* Exchange Server 2019 : install may 2022 SU\
            \ on CU12 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2016 : install may 2022 SU on CU23 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2013 : install may 2022 SU on CU23 ([KB5014260](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
            \ ;\n* for all version, after applying the above security updates: run\
            \ the \"/PrepareAllDomains\" setup phase\n  * on Exchange Server 2019\
            \ and 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
            \ /PrepareAllDomains` or `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * on Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * Please note Exchange Server 2010 is not supported anymore by Microsoft.\n\
            \nAny other control path shall be manually investigated to properly address\
            \ the issue.\n\nA list of published Exchange Server security updates is\
            \ [available here](https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_adminsdholder-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_adminsdholder-l2
      name: Permissions dangereuses sur l'objet adminSDHolder (Niveau 2)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur l'objet `adminSDHolder`. Ces permissions permettent aux comptes\
        \ concern\xE9s de prendre le contr\xF4le complet de l'Active Directory. Dans\
        \ un mod\xE8le d'administration en niveaux (tiered administrative model),\
        \ ces permissions cassent l'\xE9tanch\xE9it\xE9 du Tier 0.\n\nL\xE9gende:\
        \ Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4le indirect\
        \ faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le pr\xE9sente\
        \ des seuils de tol\xE9rance diff\xE9rents en fonction du niveau de s\xE9\
        curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\n## Cas g\xE9n\xE9ral\n\nLes permissions de\
        \ l'objet `adminSDHolder` sont r\xE9guli\xE8rement appliqu\xE9es sur l'ensemble\
        \ des objets prot\xE9g\xE9s (membres des groupes administratifs et op\xE9\
        ratifs) de l'Active Directory. Par d\xE9faut, seuls les objets privil\xE9\
        gi\xE9s poss\xE8dent des droits sur l'objet `adminSDHolder`. Ainsi, ce m\xE9\
        canisme permet de prot\xE9ger les utilisateurs et les groupes les plus privil\xE9\
        gi\xE9s de l'Active Directory.\n\nIl est fortement d\xE9conseill\xE9 de changer\
        \ les permissions par d\xE9faut de cet objet. Ainsi il est recommand\xE9 d'enlever\
        \ les permissions dangereuses sur l'objet `adminSDHolder` afin de revenir\
        \ \xE0 un \xE9tat par d\xE9faut. La correction est g\xE9n\xE9ralement effectu\xE9\
        e \xE0 l'aide du composant logiciel enfichable `ADSI Edit` ou de l'utilitaire\
        \ `ldp`.\n\n## Cas particuliers\n\nDans le cadre de la mise en \u0153uvre\
        \ de for\xEAts d'administration, il est tol\xE9r\xE9 d'ajouter des droits\
        \ \xE0 un groupe sur l' `adminSDHolder` aux conditions suivantes :\n\n* les\
        \ permissions sur ce groupe sont plus restrictives que celles appliqu\xE9\
        es initialement par l'objet `adminSDHolder`;\n* l'h\xE9ritage des permissions\
        \ sur ce groupe est d\xE9sactiv\xE9.\n\nSi une permission est li\xE9e \xE0\
        \ Exchange (par exemple <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>), il est n\xE9cessaire d'appliquer les mises\
        \ \xE0 jour Exchange ad hoc. La documentation relative aux permissions Exchange\
        \ positionn\xE9es sur l'objet `adminSDHolder` est accessible \xE0 cette URL\
        \ :\n\n* [https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server](https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server)\
        \ Information : le contr\xF4le depuis `Exchange Trusted Subsystem` avec <span\
        \ style=\"background-color:rgb(0, 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\
        \ est un d\xE9faut de configuration qui a \xE9t\xE9 corrig\xE9 par Microsoft.\n\
        \nSi les permissions concernent un compte Azure ADConnect (MSOL), il est n\xE9\
        cessaire de reconfigurer les droits dans l'AD relatifs au compte MSOL sp\xE9\
        cifi\xE9. La documentation relative aux comptes Azure ADConnect (MSOL) est\
        \ accessible \xE0 cette URL :\n\n* [https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account)\
        \ Utiliser la cmdlet `Set-ADSyncRestrictedPermissions` avec `-SkipAdminSdHolders`\
        \ dans les commandes de configuration.\n\n## Contexte : chemins de contr\xF4\
        le\n\nUn chemin de contr\xF4le est compos\xE9 d'un ensemble de relations de\
        \ contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet\
        \ sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les\
        \ chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre\
        \ des cibles, et permettent d'identifier des d\xE9viances dans la gestion\
        \ du domaine, de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9\
        \ autour des cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler\
        \ des moyens de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Cas particulier de\
        \ Microsoft Exchange Server\n\nCertains chemins de contr\xF4le qui apparaissent\
        \ peuvent \xEAtre li\xE9s \xE0 des groupes Exchange b\xE9n\xE9ficiant de permissions\
        \ dangereuses. Deux cas particuliers peuvent se pr\xE9senter :\n\n1. s'il\
        \ s'agit de groupes datant d'une ancienne installation de Exchange Server\
        \ 2007 ou ant\xE9rieure (\"Exchange Enterprise Servers\", \"Exchange Domain\
        \ Servers\" ou \"Exchange Services\") et que cette infrastructure a \xE9t\xE9\
        \ migr\xE9e vers une version 2010 ou ult\xE9rieure, il est recommand\xE9 de\
        \ supprimer ces groupes et les permissions associ\xE9es. [Microsoft fournit\
        \ une proc\xE9dure \xE0 cette fin](https://learn.microsoft.com/fr-fr/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
        2. sinon pour les autres groupes, il convient de v\xE9rifier les contr\xF4\
        les dangereux concern\xE9s pour d\xE9terminer la correction ad\xE9quate (voir\
        \ plus bas).\n\nLes contr\xF4les suivants, uniquement s'ils sont mentionn\xE9\
        s pour un groupe li\xE9 \xE0 Exchange, ont fait l'objet d'un correctif de\
        \ Microsoft :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nAttention\
        \ : certaines des propri\xE9t\xE9s LDAP concern\xE9es par ces \xE9critures\
        \ (`servicePrincipalName` et `altSecurityIdentities`) font partie du property-set\
        \ `Public-Information`. Ainsi, les permissions d'\xE9critures peuvent \xEA\
        tre attribu\xE9es pour chaque attribut unitairement ou le property-set entier,\
        \ auquel cas seul ce dernier sera visible dans la DACL de l'objet concern\xE9\
        .\n\nPour appliquer ce correctif, il est n\xE9cessaire d'effectuer les actions\
        \ suivantes :\n\n* pour Exchange Server 2019 : installer le SU de mai 2022\
        \ sur le CU12 ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2016 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2013 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014260](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
        \ ;\n* pour toutes les versions, apr\xE8s installation des correctifs pr\xE9\
        c\xE9dents : ex\xE9cuter la phase de pr\xE9paration des domaines \"/PrepareAllDomains\"\
        \n  * pour Exchange Server 2019 et 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
        \ /PrepareAllDomains` ou `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
        \ /PrepareAllDomains` depuis le r\xE9pertoire d'installation de Exchange ;\n\
        \  * pour Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
        \ /PrepareAllDomains`;\n  * il est rappel\xE9 que Exchange Server 2010 n'est\
        \ plus support\xE9 par l'\xE9diteur.\n\nPour tout autre chemin de contr\xF4\
        le, une qualification manuelle doit \xEAtre effectu\xE9e pour caract\xE9riser\
        \ le probl\xE8me.\n\n\xC0 titre d'information, la liste des derniers correctifs\
        \ publi\xE9s pour Exchange Server est [disponible ici](https://learn.microsoft.com/fr-fr/exchange/new-features/build-numbers-and-release-dates)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous permissions on the adminSDHolder object (Level 2)
          description: '# Vulnerability description


            Dangerous permissions are set on the `adminSDHolder` object. Permissions
            set on this object may grant trusted objects full control over the Active
            Directory. In a tiered administrative model, these permissions allow compromise
            of Tier 0 objects from lower trust tiers.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: "# Recommended measure\n\n## General Case\n\nPermissions set\
            \ on the `adminSDHolder` object are periodically copied to all protected\
            \ AD objects (privileged built-in group members). By default, only privileged\
            \ objects are granted access rights on the `adminSDHolder` object. This\
            \ mechanism protects the most privileged Active directory users and groups\
            \ from accidental misconfigurations.\n\nModifying default permissions\
            \ set on this object is strongly discouraged. Removing dangerous permissions\
            \ is strongly advised to return the object to its default state. Fixing\
            \ usually requires using `adsiedit.msc` or the `ldp` utility.\n\n## Specific\
            \ Cases\n\nWhen deploying an administration forest, granting access rights\
            \ on the `adminSDHolder` object to a group is tolerated given the following\
            \ cumulative criteria are met:\n\n* access rights on the trusted group\
            \ are stricter than those initially granted on the `adminSDHolder` object;\n\
            * permission inheritance is disabled for the trusted group.\n\nIf a flagged\
            \ access right relates to Exchange, (such as <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>), the latest relevant\
            \ cumulative updates must be applied. Documentation on access rights granted\
            \ to Exchange Server is available at the following URL:\n\n* [https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server](https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server)\
            \ Note: if flagged, the <span style=\"background-color:rgb(0, 123, 255);color:rgb(255,\
            \ 255, 255)\">WRITE_ALT_IDENTITY</span> access right granted to `Exchange\
            \ Trusted Subsystem` is a configuration defect that has been fixed by\
            \ Microsoft in a previous update.\n\nIf a flagged access right relates\
            \ to an Azure adconnect account (MSOL), its relevant access rights must\
            \ be reconfigured. Documentation is available at the following URL:\n\n\
            * [https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account)\
            \ PowerShell cmdlets `Set-ADSyncRestrictedPermissions` with `-SkipAdminSdHolders`\
            \ may be used during the configuration phase.\n\n## Context: control path\
            \ exposure\n\nA control path materializes through a set of granted access\
            \ permissions: each granted permission can be expressed as one object\
            \ controlling another through a specific property, attribute or setting.\
            \ Control paths reveal how an attacker could leverage a chain of defective\
            \ or dangerous permissions to gain control of some targets. They can also\
            \ be leveraged to quickly identify domain mismanagement, to validate the\
            \ actual security boundary of a particular scope (making sure some object\
            \ of interest cannot be taken over by unauthorized users through misconfiguration).\
            \ Indicators of compromise may also be found through control path review.\n\
            \n## Limitations\n\nSome control paths may have fixes that renders them\
            \ non-exploitable. Such a case usually requires having all domain controllers\
            \ equally up to date. Furthermore, dangerous features may sometimes be\
            \ re-enabled through a registry or dsHeuristics setting. It is therefore\
            \ still recommended to clean the affected permissions from your Active\
            \ Directory to prevent an accidental re-occurrence.\n\nList of known specific\
            \ fixes:\n\n* [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
            \ fixes the <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">OWNER</span> and <span style=\"background-color:rgb(255, 165,\
            \ 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> control path on computer\
            \ accounts only, but the dangerous behavior can still be re-enabled.\n\
            * Various Exchange-related control paths have been fixed through specific\
            \ cumulative updates; refer to the dedicated section below if applicable.\n\
            \n## Microsoft Exchange Server Specifics\n\nSome control paths under this\
            \ item may appear because of Exchange Server management groups with excessive\
            \ permissions. The cause can be:\n\n1. either the offending groups come\
            \ from a legacy Exchange Server 2007 or earlier instance (\"Exchange Enterprise\
            \ Servers\", \"Exchange Domain Servers\" ou \"Exchange Services\") which\
            \ has been migrated to version 2010 or later, it is then best to remove\
            \ those groups and associated permissions. [Microsoft provides relevant\
            \ guidance to fix these issues](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
            2. or these are current Exchange Server management groups, a specific\
            \ analysis will help select the applicable solution (see below).\n\nThe\
            \ following controls have been fixed by Microsoft, only if pertaining\
            \ to Exchange Server groups:\n\n* <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>\n* <span style=\"\
            background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n\
            * <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
            \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nWarning:\
            \ some LDAP attributes (`servicePrincipalName` and `altSecurityIdentities`)\
            \ behind these controls belong to the `Public-Information` property set.\
            \ Therefore, these write permissions may be granted on an attribute basis\
            \ or to the whole property set, in which case only this property set will\
            \ be visible in the object's DACL.\n\nApplying the official fix involves\
            \ the following steps:\n\n* Exchange Server 2019 : install may 2022 SU\
            \ on CU12 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2016 : install may 2022 SU on CU23 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2013 : install may 2022 SU on CU23 ([KB5014260](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
            \ ;\n* for all version, after applying the above security updates: run\
            \ the \"/PrepareAllDomains\" setup phase\n  * on Exchange Server 2019\
            \ and 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
            \ /PrepareAllDomains` or `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * on Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * Please note Exchange Server 2010 is not supported anymore by Microsoft.\n\
            \nAny other control path shall be manually investigated to properly address\
            \ the issue.\n\nA list of published Exchange Server security updates is\
            \ [available here](https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_dc-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_dc-l1
      name: "Permissions dangereuses sur les objets contr\xF4leurs de domaine (chemins\
        \ de contr\xF4le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\n## Cas g\xE9n\xE9ral\n\
        \nDes permissions dangereuses existent sur les objets des contr\xF4leurs de\
        \ domaine. Cela permet aux comptes concern\xE9s de prendre le contr\xF4le\
        \ complet de l'Active Directory. Un attaquant peut, par exemple, r\xE9pliquer\
        \ l'ensemble des secrets (dont ceux des *Administrateurs du domaine* (Domain\
        \ Admins)), les r\xE9utiliser et ainsi prendre le contr\xF4le complet du domaine.\n\
        \n## Cas des contr\xF4leurs de domaine en lecture seule\n\nDans le cas particulier\
        \ des contr\xF4leurs de domaine en lecture seule (RODC), un attaquant peut\
        \ r\xE9pliquer l'ensemble des secrets autoris\xE9s sur ce RODC et en devenir\
        \ administrateur local. Le contr\xF4le <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">MANAGED_BY</span> permet d'\xEAtre administrateur\
        \ local du RODC.\n\nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4\
        le indirect, Contr\xF4le indirect faible\n\n## Seuils de tol\xE9rance\n\n\
        Ce point de contr\xF4le pr\xE9sente des seuils de tol\xE9rance diff\xE9rents\
        \ en fonction du niveau de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> seules\
        \ les permissions pouvant \xEAtre exploit\xE9es par un attaquant, sans pr\xE9\
        requis majeur, sont prises en compte ;\n* au niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> l'ensemble des permissions potentiellement\
        \ dangereuses sont prises en compte.\n\n# Permissions dangereuses et chemins\
        \ de contr\xF4le\n\nDes permissions dangereuses permettent la prise de contr\xF4\
        le d'un objet cible, sur lequel ces permissions sont positionn\xE9es, par\
        \ l'\xE9criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits\
        \ privil\xE9gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\
        \nUne fois l'objet ma\xEEtris\xE9 par un attaquant, ce dernier peut alors\
        \ poursuivre un chemin de prise de contr\xF4le d'autres objets qui, par transitivit\xE9\
        , peut mener \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission\
        \ de l'annuaire Active Directory tout entier. L'encha\xEEnement de permissions\
        \ dangereuses ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le**\
        \ , ou un chemin d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un\
        \ ensemble de relations de contr\xF4le direct, o\xF9 chaque relation traduit\
        \ la ma\xEEtrise d'un objet sur un autre au travers d'une propri\xE9t\xE9\
        \ particuli\xE8re.).\n\nAinsi, les chemins de contr\xF4le repr\xE9sentent\
        \ des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier\
        \ des d\xE9viances dans la gestion du domaine, de valider l'application d'un\
        \ p\xE9rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais\
        \ \xE9galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un\
        \ attaquant apr\xE8s une compromission.\n\n## Visualisation\n\nIl est possible\
        \ de visualiser les chemins de contr\xF4le qui permettent la compromission\
        \ totale de la for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant\
        \ ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl convient de consid\xE9rer les comptes ayant\
        \ des permissions sur les contr\xF4leurs de domaine comme \xE9tant privil\xE9\
        gi\xE9s. Il est alors n\xE9cessaire de les prot\xE9ger avec le m\xE9canisme\
        \ de l' `adminSDHolder`. Pour cela, ces comptes doivent appartenir au groupe\
        \ *Administrateurs de l'entreprise* (Enterprise Admins) ou *Administrateurs\
        \ du domaine* (Domain Admins).\n\nDans le cadre de la mise en place de for\xEA\
        ts d'administration, il est tol\xE9r\xE9 d'ajouter des droits sur les contr\xF4\
        leurs de domaine aux conditions suivantes :\n\n* le groupe est de type `DOMAIN\
        \ LOCAL`;\n* les permissions sur ce groupe sont plus restrictives que celles\
        \ de l' `adminSDHolder`.\n\n## Contexte : chemins de contr\xF4le\n\nUn chemin\
        \ de contr\xF4le est compos\xE9 d'un ensemble de relations de contr\xF4le\
        \ direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet sur un autre\
        \ au travers d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les chemins de\
        \ contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre des\
        \ cibles, et permettent d'identifier des d\xE9viances dans la gestion du domaine,\
        \ de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des\
        \ cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler des moyens\
        \ de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Cas particulier de\
        \ Microsoft Exchange Server\n\nCertains chemins de contr\xF4le qui apparaissent\
        \ peuvent \xEAtre li\xE9s \xE0 des groupes Exchange b\xE9n\xE9ficiant de permissions\
        \ dangereuses. Deux cas particuliers peuvent se pr\xE9senter :\n\n1. s'il\
        \ s'agit de groupes datant d'une ancienne installation de Exchange Server\
        \ 2007 ou ant\xE9rieure (\"Exchange Enterprise Servers\", \"Exchange Domain\
        \ Servers\" ou \"Exchange Services\") et que cette infrastructure a \xE9t\xE9\
        \ migr\xE9e vers une version 2010 ou ult\xE9rieure, il est recommand\xE9 de\
        \ supprimer ces groupes et les permissions associ\xE9es. [Microsoft fournit\
        \ une proc\xE9dure \xE0 cette fin](https://learn.microsoft.com/fr-fr/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
        2. sinon pour les autres groupes, il convient de v\xE9rifier les contr\xF4\
        les dangereux concern\xE9s pour d\xE9terminer la correction ad\xE9quate (voir\
        \ plus bas).\n\nLes contr\xF4les suivants, uniquement s'ils sont mentionn\xE9\
        s pour un groupe li\xE9 \xE0 Exchange, ont fait l'objet d'un correctif de\
        \ Microsoft :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nAttention\
        \ : certaines des propri\xE9t\xE9s LDAP concern\xE9es par ces \xE9critures\
        \ (`servicePrincipalName` et `altSecurityIdentities`) font partie du property-set\
        \ `Public-Information`. Ainsi, les permissions d'\xE9critures peuvent \xEA\
        tre attribu\xE9es pour chaque attribut unitairement ou le property-set entier,\
        \ auquel cas seul ce dernier sera visible dans la DACL de l'objet concern\xE9\
        .\n\nPour appliquer ce correctif, il est n\xE9cessaire d'effectuer les actions\
        \ suivantes :\n\n* pour Exchange Server 2019 : installer le SU de mai 2022\
        \ sur le CU12 ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2016 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2013 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014260](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
        \ ;\n* pour toutes les versions, apr\xE8s installation des correctifs pr\xE9\
        c\xE9dents : ex\xE9cuter la phase de pr\xE9paration des domaines \"/PrepareAllDomains\"\
        \n  * pour Exchange Server 2019 et 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
        \ /PrepareAllDomains` ou `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
        \ /PrepareAllDomains` depuis le r\xE9pertoire d'installation de Exchange ;\n\
        \  * pour Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
        \ /PrepareAllDomains`;\n  * il est rappel\xE9 que Exchange Server 2010 n'est\
        \ plus support\xE9 par l'\xE9diteur.\n\nPour tout autre chemin de contr\xF4\
        le, une qualification manuelle doit \xEAtre effectu\xE9e pour caract\xE9riser\
        \ le probl\xE8me.\n\n\xC0 titre d'information, la liste des derniers correctifs\
        \ publi\xE9s pour Exchange Server est [disponible ici](https://learn.microsoft.com/fr-fr/exchange/new-features/build-numbers-and-release-dates).\n\
        \n## Acceptation du risque\n\nSi des permissions sp\xE9cifiques sont n\xE9\
        cessaires, il convient de consid\xE9rer que les comptes ou les groupes d\xE9\
        l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9gi\xE9s. Ainsi, ils doivent \xEA\
        tre correctement prot\xE9g\xE9s et leurs permissions appliqu\xE9es doivent\
        \ \xEAtre au moins aussi restrictives que celles appliqu\xE9es \xE0 l' `adminSDHolder`.\
        \ Il est donc n\xE9cessaire de leur appliquer des permissions \"s\xE9curis\xE9\
        es\". Pour cela, il est recommand\xE9 d'utiliser la commande ``Set-ADSyncRestrictedPermissions``\
        \ du module `AdSyncConfig.psm1` fourni avec Azure AD Connect. Cette commande\
        \ supprime l'h\xE9ritage et applique des permissions (ACE) restreintes. Pour\
        \ un groupe d\xE9l\xE9gu\xE9, l'application de cette seule commande n'est\
        \ pas suffisante : il faut \xE9galement retirer les membres du groupe, ou\
        \ les consid\xE9rer eux-m\xEAmes comme \xE9tant privil\xE9gi\xE9e en leur\
        \ appliquant la m\xEAme commande.\n\nExemple d'utilisation de ``Set-ADSyncRestrictedPermissions``\
        \ pour appliquer des permissions \"s\xE9curis\xE9es\" sur un compte privil\xE9\
        gi\xE9 :\n\n```powershell\nImport-Module .\\AdSyncConfig.psm1\n$credential\
        \ = Get-Credential\nSet-ADSyncRestrictedPermissions -ADConnectorAccountDN\
        \ \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\" -Credential $credential\n\
        ```\n\nNote : le module `AdSyncConfig.psm1` peut \xEAtre directement extrait\
        \ du fichier d'installation d'Azure AD Connect \xE0 l'aide de l'utilitaire\
        \ int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\\
        temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9l\xE9charg\xE9 \xE0\
        \ l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose domain controller objects (attack path) (Level
            1)
          description: '# Vulnerability description


            ## General Case


            Dangerous ACLs expose domain controller objects. Accounts granted these
            permissions can take full control over the Active Directory. An attacker
            could replicate all secrets from the user database (including *Domain
            Admins* (Administrateurs du domaine)), reuse them and gain full control
            over the domain.


            ## Read-Only Domain Controllers (RODC)


            When the flagged domain controller is a RODC, an attacker can replicate
            all of the secrets it is allowed to store locally and can become local
            administrator. The <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">MANAGED_BY</span> attribute grants local administration privileges
            on a RODC.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: "# Recommended measure\n\nAccounts which are granted permissions\
            \ on domain controllers must be considered privileged. Therefore, they\
            \ must be protected through the `adminSDHolder` mechanism. These accounts\
            \ must belong to either the *Enterprise Admins* (Administrateurs de l'entreprise)\
            \ or the *Domain Admins* (Administrateurs du domaine) group.\n\nWhen deploying\
            \ an administration forest, granting access rights on domain controllers\
            \ is tolerated given the following cumulative criteria are met:\n\n* delegated\
            \ groups must be of `DOMAIN LOCAL` type\n* permissions on that group must\
            \ be stricter than those applied to `adminSDHolder`\n\n## Context: control\
            \ path exposure\n\nA control path materializes through a set of granted\
            \ access permissions: each granted permission can be expressed as one\
            \ object controlling another through a specific property, attribute or\
            \ setting. Control paths reveal how an attacker could leverage a chain\
            \ of defective or dangerous permissions to gain control of some targets.\
            \ They can also be leveraged to quickly identify domain mismanagement,\
            \ to validate the actual security boundary of a particular scope (making\
            \ sure some object of interest cannot be taken over by unauthorized users\
            \ through misconfiguration). Indicators of compromise may also be found\
            \ through control path review.\n\n## Limitations\n\nSome control paths\
            \ may have fixes that renders them non-exploitable. Such a case usually\
            \ requires having all domain controllers equally up to date. Furthermore,\
            \ dangerous features may sometimes be re-enabled through a registry or\
            \ dsHeuristics setting. It is therefore still recommended to clean the\
            \ affected permissions from your Active Directory to prevent an accidental\
            \ re-occurrence.\n\nList of known specific fixes:\n\n* [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
            \ fixes the <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">OWNER</span> and <span style=\"background-color:rgb(255, 165,\
            \ 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> control path on computer\
            \ accounts only, but the dangerous behavior can still be re-enabled.\n\
            * Various Exchange-related control paths have been fixed through specific\
            \ cumulative updates; refer to the dedicated section below if applicable.\n\
            \n## Microsoft Exchange Server Specifics\n\nSome control paths under this\
            \ item may appear because of Exchange Server management groups with excessive\
            \ permissions. The cause can be:\n\n1. either the offending groups come\
            \ from a legacy Exchange Server 2007 or earlier instance (\"Exchange Enterprise\
            \ Servers\", \"Exchange Domain Servers\" ou \"Exchange Services\") which\
            \ has been migrated to version 2010 or later, it is then best to remove\
            \ those groups and associated permissions. [Microsoft provides relevant\
            \ guidance to fix these issues](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
            2. or these are current Exchange Server management groups, a specific\
            \ analysis will help select the applicable solution (see below).\n\nThe\
            \ following controls have been fixed by Microsoft, only if pertaining\
            \ to Exchange Server groups:\n\n* <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>\n* <span style=\"\
            background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n\
            * <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
            \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nWarning:\
            \ some LDAP attributes (`servicePrincipalName` and `altSecurityIdentities`)\
            \ behind these controls belong to the `Public-Information` property set.\
            \ Therefore, these write permissions may be granted on an attribute basis\
            \ or to the whole property set, in which case only this property set will\
            \ be visible in the object's DACL.\n\nApplying the official fix involves\
            \ the following steps:\n\n* Exchange Server 2019 : install may 2022 SU\
            \ on CU12 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2016 : install may 2022 SU on CU23 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2013 : install may 2022 SU on CU23 ([KB5014260](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
            \ ;\n* for all version, after applying the above security updates: run\
            \ the \"/PrepareAllDomains\" setup phase\n  * on Exchange Server 2019\
            \ and 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
            \ /PrepareAllDomains` or `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * on Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * Please note Exchange Server 2010 is not supported anymore by Microsoft.\n\
            \nAny other control path shall be manually investigated to properly address\
            \ the issue.\n\nA list of published Exchange Server security updates is\
            \ [available here](https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates).\n\
            \n## Risk Acceptance\n\nIf special permissions are required, delegated\
            \ groups or accounts should be considered as privileged. Therefore, they\
            \ must comply with appropriate protection measures, and their own access\
            \ control list should be at least as strict as that of the `adminSDHolder`\
            \ object. \"Secure\" ACLs should therefore be implemented on these delegated\
            \ groups, which will not open a new control path exposure. To remove inheritance\
            \ and restrict ACEs, the following command may be used: ``Set-ADSyncRestrictedPermissions``\
            \ found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated\
            \ groups, strengthening permissions using this command is not enough:\
            \ the permissions of this group's members must also be strengthened by\
            \ applying this command to them, or they can be removed from the delegated\
            \ group.\n\nExample: applying \"secure\" permission on a privileged account\
            \ through ``Set-ADSyncRestrictedPermissions``:\n\n```powershell\nImport-Module\
            \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
            \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
            \ -Credential $credential\n```\n\nNote: the `AdSyncConfig.psm1` module\
            \ may be extracted from the Azure AD Connect installer with `msiexec`:\
            \ `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\temp\\`\n\nThe\
            \ installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_dc-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_dc-l2
      name: "Permissions dangereuses sur les objets contr\xF4leurs de domaine (chemins\
        \ de contr\xF4le) (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\n## Cas g\xE9n\xE9ral\n\
        \nDes permissions dangereuses existent sur les objets des contr\xF4leurs de\
        \ domaine. Cela permet aux comptes concern\xE9s de prendre le contr\xF4le\
        \ complet de l'Active Directory. Un attaquant peut, par exemple, r\xE9pliquer\
        \ l'ensemble des secrets (dont ceux des *Administrateurs du domaine* (Domain\
        \ Admins)), les r\xE9utiliser et ainsi prendre le contr\xF4le complet du domaine.\n\
        \n## Cas des contr\xF4leurs de domaine en lecture seule\n\nDans le cas particulier\
        \ des contr\xF4leurs de domaine en lecture seule (RODC), un attaquant peut\
        \ r\xE9pliquer l'ensemble des secrets autoris\xE9s sur ce RODC et en devenir\
        \ administrateur local. Le contr\xF4le <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">MANAGED_BY</span> permet d'\xEAtre administrateur\
        \ local du RODC.\n\nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4\
        le indirect, Contr\xF4le indirect faible\n\n## Seuils de tol\xE9rance\n\n\
        Ce point de contr\xF4le pr\xE9sente des seuils de tol\xE9rance diff\xE9rents\
        \ en fonction du niveau de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span> seules\
        \ les permissions pouvant \xEAtre exploit\xE9es par un attaquant, sans pr\xE9\
        requis majeur, sont prises en compte ;\n* au niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> l'ensemble des permissions potentiellement\
        \ dangereuses sont prises en compte.\n\n# Permissions dangereuses et chemins\
        \ de contr\xF4le\n\nDes permissions dangereuses permettent la prise de contr\xF4\
        le d'un objet cible, sur lequel ces permissions sont positionn\xE9es, par\
        \ l'\xE9criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits\
        \ privil\xE9gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\
        \nUne fois l'objet ma\xEEtris\xE9 par un attaquant, ce dernier peut alors\
        \ poursuivre un chemin de prise de contr\xF4le d'autres objets qui, par transitivit\xE9\
        , peut mener \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission\
        \ de l'annuaire Active Directory tout entier. L'encha\xEEnement de permissions\
        \ dangereuses ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le**\
        \ , ou un chemin d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un\
        \ ensemble de relations de contr\xF4le direct, o\xF9 chaque relation traduit\
        \ la ma\xEEtrise d'un objet sur un autre au travers d'une propri\xE9t\xE9\
        \ particuli\xE8re.).\n\nAinsi, les chemins de contr\xF4le repr\xE9sentent\
        \ des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier\
        \ des d\xE9viances dans la gestion du domaine, de valider l'application d'un\
        \ p\xE9rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais\
        \ \xE9galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un\
        \ attaquant apr\xE8s une compromission.\n\n## Visualisation\n\nIl est possible\
        \ de visualiser les chemins de contr\xF4le qui permettent la compromission\
        \ totale de la for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant\
        \ ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl convient de consid\xE9rer les comptes ayant\
        \ des permissions sur les contr\xF4leurs de domaine comme \xE9tant privil\xE9\
        gi\xE9s. Il est alors n\xE9cessaire de les prot\xE9ger avec le m\xE9canisme\
        \ de l' `adminSDHolder`. Pour cela, ces comptes doivent appartenir au groupe\
        \ *Administrateurs de l'entreprise* (Enterprise Admins) ou *Administrateurs\
        \ du domaine* (Domain Admins).\n\nDans le cadre de la mise en place de for\xEA\
        ts d'administration, il est tol\xE9r\xE9 d'ajouter des droits sur les contr\xF4\
        leurs de domaine aux conditions suivantes :\n\n* le groupe est de type `DOMAIN\
        \ LOCAL`;\n* les permissions sur ce groupe sont plus restrictives que celles\
        \ de l' `adminSDHolder`.\n\n## Contexte : chemins de contr\xF4le\n\nUn chemin\
        \ de contr\xF4le est compos\xE9 d'un ensemble de relations de contr\xF4le\
        \ direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet sur un autre\
        \ au travers d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les chemins de\
        \ contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre des\
        \ cibles, et permettent d'identifier des d\xE9viances dans la gestion du domaine,\
        \ de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des\
        \ cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler des moyens\
        \ de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Cas particulier de\
        \ Microsoft Exchange Server\n\nCertains chemins de contr\xF4le qui apparaissent\
        \ peuvent \xEAtre li\xE9s \xE0 des groupes Exchange b\xE9n\xE9ficiant de permissions\
        \ dangereuses. Deux cas particuliers peuvent se pr\xE9senter :\n\n1. s'il\
        \ s'agit de groupes datant d'une ancienne installation de Exchange Server\
        \ 2007 ou ant\xE9rieure (\"Exchange Enterprise Servers\", \"Exchange Domain\
        \ Servers\" ou \"Exchange Services\") et que cette infrastructure a \xE9t\xE9\
        \ migr\xE9e vers une version 2010 ou ult\xE9rieure, il est recommand\xE9 de\
        \ supprimer ces groupes et les permissions associ\xE9es. [Microsoft fournit\
        \ une proc\xE9dure \xE0 cette fin](https://learn.microsoft.com/fr-fr/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
        2. sinon pour les autres groupes, il convient de v\xE9rifier les contr\xF4\
        les dangereux concern\xE9s pour d\xE9terminer la correction ad\xE9quate (voir\
        \ plus bas).\n\nLes contr\xF4les suivants, uniquement s'ils sont mentionn\xE9\
        s pour un groupe li\xE9 \xE0 Exchange, ont fait l'objet d'un correctif de\
        \ Microsoft :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nAttention\
        \ : certaines des propri\xE9t\xE9s LDAP concern\xE9es par ces \xE9critures\
        \ (`servicePrincipalName` et `altSecurityIdentities`) font partie du property-set\
        \ `Public-Information`. Ainsi, les permissions d'\xE9critures peuvent \xEA\
        tre attribu\xE9es pour chaque attribut unitairement ou le property-set entier,\
        \ auquel cas seul ce dernier sera visible dans la DACL de l'objet concern\xE9\
        .\n\nPour appliquer ce correctif, il est n\xE9cessaire d'effectuer les actions\
        \ suivantes :\n\n* pour Exchange Server 2019 : installer le SU de mai 2022\
        \ sur le CU12 ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2016 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2013 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014260](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
        \ ;\n* pour toutes les versions, apr\xE8s installation des correctifs pr\xE9\
        c\xE9dents : ex\xE9cuter la phase de pr\xE9paration des domaines \"/PrepareAllDomains\"\
        \n  * pour Exchange Server 2019 et 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
        \ /PrepareAllDomains` ou `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
        \ /PrepareAllDomains` depuis le r\xE9pertoire d'installation de Exchange ;\n\
        \  * pour Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
        \ /PrepareAllDomains`;\n  * il est rappel\xE9 que Exchange Server 2010 n'est\
        \ plus support\xE9 par l'\xE9diteur.\n\nPour tout autre chemin de contr\xF4\
        le, une qualification manuelle doit \xEAtre effectu\xE9e pour caract\xE9riser\
        \ le probl\xE8me.\n\n\xC0 titre d'information, la liste des derniers correctifs\
        \ publi\xE9s pour Exchange Server est [disponible ici](https://learn.microsoft.com/fr-fr/exchange/new-features/build-numbers-and-release-dates).\n\
        \n## Acceptation du risque\n\nSi des permissions sp\xE9cifiques sont n\xE9\
        cessaires, il convient de consid\xE9rer que les comptes ou les groupes d\xE9\
        l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9gi\xE9s. Ainsi, ils doivent \xEA\
        tre correctement prot\xE9g\xE9s et leurs permissions appliqu\xE9es doivent\
        \ \xEAtre au moins aussi restrictives que celles appliqu\xE9es \xE0 l' `adminSDHolder`.\
        \ Il est donc n\xE9cessaire de leur appliquer des permissions \"s\xE9curis\xE9\
        es\". Pour cela, il est recommand\xE9 d'utiliser la commande ``Set-ADSyncRestrictedPermissions``\
        \ du module `AdSyncConfig.psm1` fourni avec Azure AD Connect. Cette commande\
        \ supprime l'h\xE9ritage et applique des permissions (ACE) restreintes. Pour\
        \ un groupe d\xE9l\xE9gu\xE9, l'application de cette seule commande n'est\
        \ pas suffisante : il faut \xE9galement retirer les membres du groupe, ou\
        \ les consid\xE9rer eux-m\xEAmes comme \xE9tant privil\xE9gi\xE9e en leur\
        \ appliquant la m\xEAme commande.\n\nExemple d'utilisation de ``Set-ADSyncRestrictedPermissions``\
        \ pour appliquer des permissions \"s\xE9curis\xE9es\" sur un compte privil\xE9\
        gi\xE9 :\n\n```powershell\nImport-Module .\\AdSyncConfig.psm1\n$credential\
        \ = Get-Credential\nSet-ADSyncRestrictedPermissions -ADConnectorAccountDN\
        \ \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\" -Credential $credential\n\
        ```\n\nNote : le module `AdSyncConfig.psm1` peut \xEAtre directement extrait\
        \ du fichier d'installation d'Azure AD Connect \xE0 l'aide de l'utilitaire\
        \ int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\\
        temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9l\xE9charg\xE9 \xE0\
        \ l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous ACLs expose domain controller objects (attack path) (Level
            2)
          description: '# Vulnerability description


            ## General Case


            Dangerous ACLs expose domain controller objects. Accounts granted these
            permissions can take full control over the Active Directory. An attacker
            could replicate all secrets from the user database (including *Domain
            Admins* (Administrateurs du domaine)), reuse them and gain full control
            over the domain.


            ## Read-Only Domain Controllers (RODC)


            When the flagged domain controller is a RODC, an attacker can replicate
            all of the secrets it is allowed to store locally and can become local
            administrator. The <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">MANAGED_BY</span> attribute grants local administration privileges
            on a RODC.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: "# Recommended measure\n\nAccounts which are granted permissions\
            \ on domain controllers must be considered privileged. Therefore, they\
            \ must be protected through the `adminSDHolder` mechanism. These accounts\
            \ must belong to either the *Enterprise Admins* (Administrateurs de l'entreprise)\
            \ or the *Domain Admins* (Administrateurs du domaine) group.\n\nWhen deploying\
            \ an administration forest, granting access rights on domain controllers\
            \ is tolerated given the following cumulative criteria are met:\n\n* delegated\
            \ groups must be of `DOMAIN LOCAL` type\n* permissions on that group must\
            \ be stricter than those applied to `adminSDHolder`\n\n## Context: control\
            \ path exposure\n\nA control path materializes through a set of granted\
            \ access permissions: each granted permission can be expressed as one\
            \ object controlling another through a specific property, attribute or\
            \ setting. Control paths reveal how an attacker could leverage a chain\
            \ of defective or dangerous permissions to gain control of some targets.\
            \ They can also be leveraged to quickly identify domain mismanagement,\
            \ to validate the actual security boundary of a particular scope (making\
            \ sure some object of interest cannot be taken over by unauthorized users\
            \ through misconfiguration). Indicators of compromise may also be found\
            \ through control path review.\n\n## Limitations\n\nSome control paths\
            \ may have fixes that renders them non-exploitable. Such a case usually\
            \ requires having all domain controllers equally up to date. Furthermore,\
            \ dangerous features may sometimes be re-enabled through a registry or\
            \ dsHeuristics setting. It is therefore still recommended to clean the\
            \ affected permissions from your Active Directory to prevent an accidental\
            \ re-occurrence.\n\nList of known specific fixes:\n\n* [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
            \ fixes the <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">OWNER</span> and <span style=\"background-color:rgb(255, 165,\
            \ 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> control path on computer\
            \ accounts only, but the dangerous behavior can still be re-enabled.\n\
            * Various Exchange-related control paths have been fixed through specific\
            \ cumulative updates; refer to the dedicated section below if applicable.\n\
            \n## Microsoft Exchange Server Specifics\n\nSome control paths under this\
            \ item may appear because of Exchange Server management groups with excessive\
            \ permissions. The cause can be:\n\n1. either the offending groups come\
            \ from a legacy Exchange Server 2007 or earlier instance (\"Exchange Enterprise\
            \ Servers\", \"Exchange Domain Servers\" ou \"Exchange Services\") which\
            \ has been migrated to version 2010 or later, it is then best to remove\
            \ those groups and associated permissions. [Microsoft provides relevant\
            \ guidance to fix these issues](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
            2. or these are current Exchange Server management groups, a specific\
            \ analysis will help select the applicable solution (see below).\n\nThe\
            \ following controls have been fixed by Microsoft, only if pertaining\
            \ to Exchange Server groups:\n\n* <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>\n* <span style=\"\
            background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n\
            * <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
            \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nWarning:\
            \ some LDAP attributes (`servicePrincipalName` and `altSecurityIdentities`)\
            \ behind these controls belong to the `Public-Information` property set.\
            \ Therefore, these write permissions may be granted on an attribute basis\
            \ or to the whole property set, in which case only this property set will\
            \ be visible in the object's DACL.\n\nApplying the official fix involves\
            \ the following steps:\n\n* Exchange Server 2019 : install may 2022 SU\
            \ on CU12 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2016 : install may 2022 SU on CU23 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2013 : install may 2022 SU on CU23 ([KB5014260](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
            \ ;\n* for all version, after applying the above security updates: run\
            \ the \"/PrepareAllDomains\" setup phase\n  * on Exchange Server 2019\
            \ and 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
            \ /PrepareAllDomains` or `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * on Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * Please note Exchange Server 2010 is not supported anymore by Microsoft.\n\
            \nAny other control path shall be manually investigated to properly address\
            \ the issue.\n\nA list of published Exchange Server security updates is\
            \ [available here](https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates).\n\
            \n## Risk Acceptance\n\nIf special permissions are required, delegated\
            \ groups or accounts should be considered as privileged. Therefore, they\
            \ must comply with appropriate protection measures, and their own access\
            \ control list should be at least as strict as that of the `adminSDHolder`\
            \ object. \"Secure\" ACLs should therefore be implemented on these delegated\
            \ groups, which will not open a new control path exposure. To remove inheritance\
            \ and restrict ACEs, the following command may be used: ``Set-ADSyncRestrictedPermissions``\
            \ found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated\
            \ groups, strengthening permissions using this command is not enough:\
            \ the permissions of this group's members must also be strengthened by\
            \ applying this command to them, or they can be removed from the delegated\
            \ group.\n\nExample: applying \"secure\" permission on a privileged account\
            \ through ``Set-ADSyncRestrictedPermissions``:\n\n```powershell\nImport-Module\
            \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
            \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
            \ -Credential $credential\n```\n\nNote: the `AdSyncConfig.psm1` module\
            \ may be extracted from the Azure AD Connect installer with `msiexec`:\
            \ `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\temp\\`\n\nThe\
            \ installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_dfsr_sysvol-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_dfsr_sysvol-l1
      name: "Permissions dangereuses sur les objets des param\xE8tres DFSR du SYSVOL\
        \ (chemins de contr\xF4le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les objets des param\xE8tres du moteur de r\xE9plication de\
        \ fichiers de Microsoft (DFSR) du volume syst\xE8me (SYSVOL). Un attaquant\
        \ peut enregistrer un nouveau r\xE9plica DFS du SYSVOL, modifier son contenu\
        \ et enfin forcer une synchronisation de celui-ci. Les mod\xE8les de strat\xE9\
        gie de groupe et / ou les scripts ainsi modifi\xE9s seront appliqu\xE9s (par\
        \ exemple, sur les contr\xF4leurs de domaine) par les GPO ad hoc, ce qui permet\
        \ de prendre le contr\xF4le total du domaine.\n\nL\xE9gende: Contr\xF4le fort\
        \ et imm\xE9diat, Contr\xF4le indirect, Contr\xF4le indirect faible\n\n##\
        \ Seuils de tol\xE9rance\n\nCe point de contr\xF4le pr\xE9sente des seuils\
        \ de tol\xE9rance diff\xE9rents en fonction du niveau de s\xE9curit\xE9 vis\xE9\
        \ :\n\n* au niveau <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">1</span> seules les permissions pouvant \xEAtre exploit\xE9\
        es par un attaquant, sans pr\xE9requis majeur, sont prises en compte ;\n*\
        \ au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0,\
        \ 0)\">2</span> l'ensemble des permissions potentiellement dangereuses sont\
        \ prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4le\n\
        \nDes permissions dangereuses permettent la prise de contr\xF4le d'un objet\
        \ cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9criture\
        \ de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl est fortement d\xE9conseill\xE9 de changer\
        \ les permissions par d\xE9faut de cet objet. Ainsi il est recommand\xE9 d'enlever\
        \ les permissions dangereuses sur les param\xE8tres DFSR du SYSVOL afin de\
        \ revenir \xE0 un \xE9tat par d\xE9faut. La correction est g\xE9n\xE9ralement\
        \ effectu\xE9e \xE0 l'aide du composant logiciel enfichable `ADSI Edit` ou\
        \ de l'utilitaire `ldp`.\n\n## Contexte : chemins de contr\xF4le\n\nUn chemin\
        \ de contr\xF4le est compos\xE9 d'un ensemble de relations de contr\xF4le\
        \ direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet sur un autre\
        \ au travers d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les chemins de\
        \ contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre des\
        \ cibles, et permettent d'identifier des d\xE9viances dans la gestion du domaine,\
        \ de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des\
        \ cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler des moyens\
        \ de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose DFSR settings objects of the SYSVOL share (attack
            path) (Level 1)
          description: '# Vulnerability description


            Dangerous ACLs expose DFSR settings objects of the SYSVOL share. An attacker
            could register a new DFS replication group member, gaining the ability
            to modify SYSVOL contents and force its synchronization across the group.
            Group policies and/or scripts modified this way could then be applied
            through linked GPOs, making it possible to fully compromise the domain.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            Editing access control lists of these objects is not recommended. Thus,
            access rights on DFSR SYSVOL settings must be carefully reviewed or reverted
            to their default state. If these modifications are required, trusted Principals
            they delegate access rights to should be protected by the `adminSDHolder`
            mechanism. The fix is usually applied through the `adsiedit.msc` or `ldp`
            utilities.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_dfsr_sysvol-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_dfsr_sysvol-l2
      name: "Permissions dangereuses sur les objets des param\xE8tres DFSR du SYSVOL\
        \ (chemins de contr\xF4le) (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les objets des param\xE8tres du moteur de r\xE9plication de\
        \ fichiers de Microsoft (DFSR) du volume syst\xE8me (SYSVOL). Un attaquant\
        \ peut enregistrer un nouveau r\xE9plica DFS du SYSVOL, modifier son contenu\
        \ et enfin forcer une synchronisation de celui-ci. Les mod\xE8les de strat\xE9\
        gie de groupe et / ou les scripts ainsi modifi\xE9s seront appliqu\xE9s (par\
        \ exemple, sur les contr\xF4leurs de domaine) par les GPO ad hoc, ce qui permet\
        \ de prendre le contr\xF4le total du domaine.\n\nL\xE9gende: Contr\xF4le fort\
        \ et imm\xE9diat, Contr\xF4le indirect, Contr\xF4le indirect faible\n\n##\
        \ Seuils de tol\xE9rance\n\nCe point de contr\xF4le pr\xE9sente des seuils\
        \ de tol\xE9rance diff\xE9rents en fonction du niveau de s\xE9curit\xE9 vis\xE9\
        \ :\n\n* au niveau <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">1</span> seules les permissions pouvant \xEAtre exploit\xE9\
        es par un attaquant, sans pr\xE9requis majeur, sont prises en compte ;\n*\
        \ au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0,\
        \ 0)\">2</span> l'ensemble des permissions potentiellement dangereuses sont\
        \ prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4le\n\
        \nDes permissions dangereuses permettent la prise de contr\xF4le d'un objet\
        \ cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9criture\
        \ de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl est fortement d\xE9conseill\xE9 de changer\
        \ les permissions par d\xE9faut de cet objet. Ainsi il est recommand\xE9 d'enlever\
        \ les permissions dangereuses sur les param\xE8tres DFSR du SYSVOL afin de\
        \ revenir \xE0 un \xE9tat par d\xE9faut. La correction est g\xE9n\xE9ralement\
        \ effectu\xE9e \xE0 l'aide du composant logiciel enfichable `ADSI Edit` ou\
        \ de l'utilitaire `ldp`.\n\n## Contexte : chemins de contr\xF4le\n\nUn chemin\
        \ de contr\xF4le est compos\xE9 d'un ensemble de relations de contr\xF4le\
        \ direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet sur un autre\
        \ au travers d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les chemins de\
        \ contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre des\
        \ cibles, et permettent d'identifier des d\xE9viances dans la gestion du domaine,\
        \ de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des\
        \ cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler des moyens\
        \ de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous ACLs expose DFSR settings objects of the SYSVOL share (attack
            path) (Level 2)
          description: '# Vulnerability description


            Dangerous ACLs expose DFSR settings objects of the SYSVOL share. An attacker
            could register a new DFS replication group member, gaining the ability
            to modify SYSVOL contents and force its synchronization across the group.
            Group policies and/or scripts modified this way could then be applied
            through linked GPOs, making it possible to fully compromise the domain.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            Editing access control lists of these objects is not recommended. Thus,
            access rights on DFSR SYSVOL settings must be carefully reviewed or reverted
            to their default state. If these modifications are required, trusted Principals
            they delegate access rights to should be protected by the `adminSDHolder`
            mechanism. The fix is usually applied through the `adsiedit.msc` or `ldp`
            utilities.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_dpapi-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_dpapi-l1
      name: "Permissions dangereuses sur les objets de cl\xE9s DPAPI (chemins de contr\xF4\
        le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent vers les objets de cl\xE9s `DPAPI`. Si un attaquant obtient la\
        \ cl\xE9 `DPAPI` du domaine, il est en mesure de d\xE9chiffrer l'ensemble\
        \ des secrets prot\xE9g\xE9s par `DPAPI`, moyennant un acc\xE8s pr\xE9alable\
        \ \xE0 cette donn\xE9e chiffr\xE9e.\n\nL\xE9gende: Contr\xF4le fort et imm\xE9\
        diat, Contr\xF4le indirect, Contr\xF4le indirect faible\n\n## Seuils de tol\xE9\
        rance\n\nCe point de contr\xF4le pr\xE9sente des seuils de tol\xE9rance diff\xE9\
        rents en fonction du niveau de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span\
        \ style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span>\
        \ seules les permissions pouvant \xEAtre exploit\xE9es par un attaquant, sans\
        \ pr\xE9requis majeur, sont prises en compte ;\n* au niveau <span style=\"\
        background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">2</span> l'ensemble\
        \ des permissions potentiellement dangereuses sont prises en compte.\n\n#\
        \ Permissions dangereuses et chemins de contr\xF4le\n\nDes permissions dangereuses\
        \ permettent la prise de contr\xF4le d'un objet cible, sur lequel ces permissions\
        \ sont positionn\xE9es, par l'\xE9criture de propri\xE9t\xE9s sensibles, par\
        \ d\xE9l\xE9gation de droits privil\xE9gi\xE9s ou par l'usage de fonctionnalit\xE9\
        s sp\xE9cifiques.\n\nUne fois l'objet ma\xEEtris\xE9 par un attaquant, ce\
        \ dernier peut alors poursuivre un chemin de prise de contr\xF4le d'autres\
        \ objets qui, par transitivit\xE9, peut mener \xE0 des \xE9l\xE9vations de\
        \ privil\xE8ges et \xE0 la compromission de l'annuaire Active Directory tout\
        \ entier. L'encha\xEEnement de permissions dangereuses ainsi exploit\xE9es\
        \ s'appelle un ***chemin de contr\xF4le** , ou un chemin d'attaque* (Un chemin\
        \ de contr\xF4le est compos\xE9 d'un ensemble de relations de contr\xF4le\
        \ direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet sur un autre\
        \ au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\nAinsi, les chemins\
        \ de contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre\
        \ des cibles, et permettent d'identifier des d\xE9viances dans la gestion\
        \ du domaine, de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9\
        \ autour des cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler\
        \ des moyens de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Visualisation\n\nIl est possible de visualiser les chemins de contr\xF4\
        le qui permettent la compromission totale de la for\xEAt via l'onglet d\xE9\
        di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nMicrosoft Windows fournit un m\xE9canisme de\
        \ protection des donn\xE9es (`DPAPI`) dont l'objectif est de prot\xE9ger des\
        \ donn\xE9es (souvent des fichiers ou des mots de passe) d'un utilisateur\
        \ ou d'un processus syst\xE8me. `DPAPI` est, par exemple, utilis\xE9e par\
        \ le gestionnaire de mots de passe de Windows, plusieurs navigateurs web,\
        \ plusieurs messageries de discussion instantan\xE9es, le stockage des cl\xE9\
        s Wi-Fi et les certificats. Les donn\xE9es prot\xE9g\xE9es sont chiffr\xE9\
        es par une cl\xE9 appel\xE9e master key, qui elle-m\xEAme est prot\xE9g\xE9\
        e par le mot de passe de l'utilisateur ou une cl\xE9 du domaine (backup key).\
        \ Note : le m\xE9canisme DPAPI est r\xE9put\xE9 robuste et n'est pas remis\
        \ en question par ce point.\n\nIl est fortement d\xE9conseill\xE9 de modifier\
        \ les permissions par d\xE9faut des cl\xE9s `DPAPI`. Ainsi il recommand\xE9\
        \ d'enlever les permissions dangereuses sur ces cl\xE9s afin de revenir \xE0\
        \ un \xE9tat par d\xE9faut. La correction est g\xE9n\xE9ralement effectu\xE9\
        e \xE0 l'aide du composant logiciel enfichable `ADSI Edit` ou de l'utilitaire\
        \ `ldp`.\n\n## Contexte : chemins de contr\xF4le\n\nUn chemin de contr\xF4\
        le est compos\xE9 d'un ensemble de relations de contr\xF4le direct, o\xF9\
        \ chaque relation traduit la ma\xEEtrise d'un objet sur un autre au travers\
        \ d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les chemins de contr\xF4le\
        \ repr\xE9sentent des moyens pour un attaquant d'atteindre des cibles, et\
        \ permettent d'identifier des d\xE9viances dans la gestion du domaine, de\
        \ valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des\
        \ cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler des moyens\
        \ de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose DPAPI key objects (attack path) (Level 1)
          description: '# Vulnerability description


            Dangerous ACLs expose `DPAPI` key objects. An attacker could recover all
            domain data encrypted via DPAPI if he gains access to such data.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            Microsoft Windows provides a data protection feature (`DPAPI`) which usually
            aims at encrypting user files or passwords, or that of a privileged system
            process. `DPAPI` is used by the Windows password manager, web browsers,
            mail or instant messaging clients, Wi-Fi passphrase or certificate storage
            among others. Data is encrypted with a master key, itself protected by
            its user''s password or a domain backup key. Note: `DPAPI` is considered
            strong and not questioned by the issue raised in this item.


            Editing access control lists of these objects is not recommended. Thus,
            access rights on `DPAPI` keys need to be carefully reviewed or reverted
            to their default state. The fix is usually applied through the `adsiedit.msc`
            or `ldp` utilities.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_dpapi-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_dpapi-l2
      name: "Permissions dangereuses sur les objets de cl\xE9s DPAPI (chemins de contr\xF4\
        le) (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent vers les objets de cl\xE9s `DPAPI`. Si un attaquant obtient la\
        \ cl\xE9 `DPAPI` du domaine, il est en mesure de d\xE9chiffrer l'ensemble\
        \ des secrets prot\xE9g\xE9s par `DPAPI`, moyennant un acc\xE8s pr\xE9alable\
        \ \xE0 cette donn\xE9e chiffr\xE9e.\n\nL\xE9gende: Contr\xF4le fort et imm\xE9\
        diat, Contr\xF4le indirect, Contr\xF4le indirect faible\n\n## Seuils de tol\xE9\
        rance\n\nCe point de contr\xF4le pr\xE9sente des seuils de tol\xE9rance diff\xE9\
        rents en fonction du niveau de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span\
        \ style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">1</span>\
        \ seules les permissions pouvant \xEAtre exploit\xE9es par un attaquant, sans\
        \ pr\xE9requis majeur, sont prises en compte ;\n* au niveau <span style=\"\
        background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">2</span> l'ensemble\
        \ des permissions potentiellement dangereuses sont prises en compte.\n\n#\
        \ Permissions dangereuses et chemins de contr\xF4le\n\nDes permissions dangereuses\
        \ permettent la prise de contr\xF4le d'un objet cible, sur lequel ces permissions\
        \ sont positionn\xE9es, par l'\xE9criture de propri\xE9t\xE9s sensibles, par\
        \ d\xE9l\xE9gation de droits privil\xE9gi\xE9s ou par l'usage de fonctionnalit\xE9\
        s sp\xE9cifiques.\n\nUne fois l'objet ma\xEEtris\xE9 par un attaquant, ce\
        \ dernier peut alors poursuivre un chemin de prise de contr\xF4le d'autres\
        \ objets qui, par transitivit\xE9, peut mener \xE0 des \xE9l\xE9vations de\
        \ privil\xE8ges et \xE0 la compromission de l'annuaire Active Directory tout\
        \ entier. L'encha\xEEnement de permissions dangereuses ainsi exploit\xE9es\
        \ s'appelle un ***chemin de contr\xF4le** , ou un chemin d'attaque* (Un chemin\
        \ de contr\xF4le est compos\xE9 d'un ensemble de relations de contr\xF4le\
        \ direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet sur un autre\
        \ au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\nAinsi, les chemins\
        \ de contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre\
        \ des cibles, et permettent d'identifier des d\xE9viances dans la gestion\
        \ du domaine, de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9\
        \ autour des cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler\
        \ des moyens de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Visualisation\n\nIl est possible de visualiser les chemins de contr\xF4\
        le qui permettent la compromission totale de la for\xEAt via l'onglet d\xE9\
        di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nMicrosoft Windows fournit un m\xE9canisme de\
        \ protection des donn\xE9es (`DPAPI`) dont l'objectif est de prot\xE9ger des\
        \ donn\xE9es (souvent des fichiers ou des mots de passe) d'un utilisateur\
        \ ou d'un processus syst\xE8me. `DPAPI` est, par exemple, utilis\xE9e par\
        \ le gestionnaire de mots de passe de Windows, plusieurs navigateurs web,\
        \ plusieurs messageries de discussion instantan\xE9es, le stockage des cl\xE9\
        s Wi-Fi et les certificats. Les donn\xE9es prot\xE9g\xE9es sont chiffr\xE9\
        es par une cl\xE9 appel\xE9e master key, qui elle-m\xEAme est prot\xE9g\xE9\
        e par le mot de passe de l'utilisateur ou une cl\xE9 du domaine (backup key).\
        \ Note : le m\xE9canisme DPAPI est r\xE9put\xE9 robuste et n'est pas remis\
        \ en question par ce point.\n\nIl est fortement d\xE9conseill\xE9 de modifier\
        \ les permissions par d\xE9faut des cl\xE9s `DPAPI`. Ainsi il recommand\xE9\
        \ d'enlever les permissions dangereuses sur ces cl\xE9s afin de revenir \xE0\
        \ un \xE9tat par d\xE9faut. La correction est g\xE9n\xE9ralement effectu\xE9\
        e \xE0 l'aide du composant logiciel enfichable `ADSI Edit` ou de l'utilitaire\
        \ `ldp`.\n\n## Contexte : chemins de contr\xF4le\n\nUn chemin de contr\xF4\
        le est compos\xE9 d'un ensemble de relations de contr\xF4le direct, o\xF9\
        \ chaque relation traduit la ma\xEEtrise d'un objet sur un autre au travers\
        \ d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les chemins de contr\xF4le\
        \ repr\xE9sentent des moyens pour un attaquant d'atteindre des cibles, et\
        \ permettent d'identifier des d\xE9viances dans la gestion du domaine, de\
        \ valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des\
        \ cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler des moyens\
        \ de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous ACLs expose DPAPI key objects (attack path) (Level 2)
          description: '# Vulnerability description


            Dangerous ACLs expose `DPAPI` key objects. An attacker could recover all
            domain data encrypted via DPAPI if he gains access to such data.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            Microsoft Windows provides a data protection feature (`DPAPI`) which usually
            aims at encrypting user files or passwords, or that of a privileged system
            process. `DPAPI` is used by the Windows password manager, web browsers,
            mail or instant messaging clients, Wi-Fi passphrase or certificate storage
            among others. Data is encrypted with a master key, itself protected by
            its user''s password or a domain backup key. Note: `DPAPI` is considered
            strong and not questioned by the issue raised in this item.


            Editing access control lists of these objects is not recommended. Thus,
            access rights on `DPAPI` keys need to be carefully reviewed or reverted
            to their default state. The fix is usually applied through the `adsiedit.msc`
            or `ldp` utilities.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_gmsa_keys-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_gmsa_keys-l1
      name: "Permissions dangereuses vers les objets de cl\xE9s gMSA (chemins de contr\xF4\
        le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent vers les objets de cl\xE9s des group managed service accounts (`gMSA`).\
        \ Un attaquant ayant un contr\xF4le sur ces cl\xE9s est en mesure de r\xE9\
        cup\xE9rer le mot de passe des `gMSA` associ\xE9s \xE0 ces cl\xE9s.\n\nL\xE9\
        gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4le\
        \ indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nLes comptes membres des `gMSA` h\xE9ritent\
        \ de certaines propri\xE9t\xE9s des classes utilisateurs et ordinateurs et\
        \ permettent donc plus de souplesse au niveau de la gestion des comptes de\
        \ services. Les `gMSA` utilisent le service de distribution de cl\xE9s (KDS)\
        \ pour cr\xE9er et g\xE9rer les mots de passe des comptes. Les mots de passe\
        \ de ces comptes sont d\xE9riv\xE9s d'une cl\xE9 g\xE9r\xE9e par le KDS.\n\
        \nIl est fortement d\xE9conseill\xE9 de modifier les permissions par d\xE9\
        faut de ces objets. Ainsi il recommand\xE9 d'enlever les permissions dangereuses\
        \ sur ceux-ci afin de retourner \xE0 un \xE9tat par d\xE9faut. La correction\
        \ peut \xEAtre effectu\xE9e \xE0 l'aide de la commande `Dsacls <DN> /S /T`.\
        \ Cette commande restaure les permissions par d\xE9faut \xE0 partir du sch\xE9\
        ma.\n\n## Contexte : chemins de contr\xF4le\n\nUn chemin de contr\xF4le est\
        \ compos\xE9 d'un ensemble de relations de contr\xF4le direct, o\xF9 chaque\
        \ relation traduit la ma\xEEtrise d'un objet sur un autre au travers d'une\
        \ propri\xE9t\xE9 particuli\xE8re. Ainsi, les chemins de contr\xF4le repr\xE9\
        sentent des moyens pour un attaquant d'atteindre des cibles, et permettent\
        \ d'identifier des d\xE9viances dans la gestion du domaine, de valider l'application\
        \ d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9\
        es, mais \xE9galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9\
        s par un attaquant apr\xE8s une compromission.\n\n## Limites\n\nCertains chemins\
        \ de contr\xF4le peuvent disposer de correctifs qui les rendent non exploitables.\
        \ Ces cas imposent g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs\
        \ de domaine au m\xEAme niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9\
        s dangereuses peuvent parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre\
        \ de registre ou dsHeuristics. Il est donc toujours recommand\xE9 de nettoyer\
        \ les permissions concern\xE9es de l'Active Directory pour pr\xE9venir une\
        \ r\xE9apparition du probl\xE8me.\n\nListe des correctifs sp\xE9cifiques connus\
        \ :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose gMSA key objects (attack path) (Level 1)
          description: '# Vulnerability description


            Dangerous ACLs expose group managed service accounts (`gMSA`) key objects.
            An attacker gaining access to those keys will be able to recover their
            associated `gMSA` passwords.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            `gMSA` member accounts inherit some user and computer class attributes
            which eases service account management. `gMSA` leverage the key distribution
            service (KDS) to create and manage account passwords. These passwords
            are derived from a KDS-managed key.


            Editing access control lists of these objects is strongly discouraged.
            Thus, access rights on `gMSA` keys need to be carefully reviewed or reset
            to their default values. If these modifications are required, trusted
            Principals they delegate access rights to should be protected by the `adminSDHolder`
            mechanism.


            To restore default permission the following command may be used: `Dsacls
            <DN> /S /T`. This command restores the permissions from the schema.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_gmsa_keys-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_gmsa_keys-l2
      name: "Permissions dangereuses vers les objets de cl\xE9s gMSA (chemins de contr\xF4\
        le) (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent vers les objets de cl\xE9s des group managed service accounts (`gMSA`).\
        \ Un attaquant ayant un contr\xF4le sur ces cl\xE9s est en mesure de r\xE9\
        cup\xE9rer le mot de passe des `gMSA` associ\xE9s \xE0 ces cl\xE9s.\n\nL\xE9\
        gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4le\
        \ indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nLes comptes membres des `gMSA` h\xE9ritent\
        \ de certaines propri\xE9t\xE9s des classes utilisateurs et ordinateurs et\
        \ permettent donc plus de souplesse au niveau de la gestion des comptes de\
        \ services. Les `gMSA` utilisent le service de distribution de cl\xE9s (KDS)\
        \ pour cr\xE9er et g\xE9rer les mots de passe des comptes. Les mots de passe\
        \ de ces comptes sont d\xE9riv\xE9s d'une cl\xE9 g\xE9r\xE9e par le KDS.\n\
        \nIl est fortement d\xE9conseill\xE9 de modifier les permissions par d\xE9\
        faut de ces objets. Ainsi il recommand\xE9 d'enlever les permissions dangereuses\
        \ sur ceux-ci afin de retourner \xE0 un \xE9tat par d\xE9faut. La correction\
        \ peut \xEAtre effectu\xE9e \xE0 l'aide de la commande `Dsacls <DN> /S /T`.\
        \ Cette commande restaure les permissions par d\xE9faut \xE0 partir du sch\xE9\
        ma.\n\n## Contexte : chemins de contr\xF4le\n\nUn chemin de contr\xF4le est\
        \ compos\xE9 d'un ensemble de relations de contr\xF4le direct, o\xF9 chaque\
        \ relation traduit la ma\xEEtrise d'un objet sur un autre au travers d'une\
        \ propri\xE9t\xE9 particuli\xE8re. Ainsi, les chemins de contr\xF4le repr\xE9\
        sentent des moyens pour un attaquant d'atteindre des cibles, et permettent\
        \ d'identifier des d\xE9viances dans la gestion du domaine, de valider l'application\
        \ d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9\
        es, mais \xE9galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9\
        s par un attaquant apr\xE8s une compromission.\n\n## Limites\n\nCertains chemins\
        \ de contr\xF4le peuvent disposer de correctifs qui les rendent non exploitables.\
        \ Ces cas imposent g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs\
        \ de domaine au m\xEAme niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9\
        s dangereuses peuvent parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre\
        \ de registre ou dsHeuristics. Il est donc toujours recommand\xE9 de nettoyer\
        \ les permissions concern\xE9es de l'Active Directory pour pr\xE9venir une\
        \ r\xE9apparition du probl\xE8me.\n\nListe des correctifs sp\xE9cifiques connus\
        \ :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous ACLs expose gMSA key objects (attack path) (Level 2)
          description: '# Vulnerability description


            Dangerous ACLs expose group managed service accounts (`gMSA`) key objects.
            An attacker gaining access to those keys will be able to recover their
            associated `gMSA` passwords.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            `gMSA` member accounts inherit some user and computer class attributes
            which eases service account management. `gMSA` leverage the key distribution
            service (KDS) to create and manage account passwords. These passwords
            are derived from a KDS-managed key.


            Editing access control lists of these objects is strongly discouraged.
            Thus, access rights on `gMSA` keys need to be carefully reviewed or reset
            to their default values. If these modifications are required, trusted
            Principals they delegate access rights to should be protected by the `adminSDHolder`
            mechanism.


            To restore default permission the following command may be used: `Dsacls
            <DN> /S /T`. This command restores the permissions from the schema.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_naming_context-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_naming_context-l1
      name: "Permissions dangereuses sur la racine des naming contexts (chemins de\
        \ contr\xF4le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les racines LDAP de l'Active Directory, appel\xE9es naming\
        \ contexts.\n\nSelon le contr\xF4le appliqu\xE9 sur le naming context, un\
        \ attaquant peut prendre le contr\xF4le complet de l'Active Directory.\n\n\
        L\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4\
        le indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nUn annuaire Active Directory contient plusieurs\
        \ partitions appel\xE9es naming contexts:\n\n* `Domain`, contient les informations\
        \ des objets d'un domaine, comme les ordinateurs, les utilisateurs, les groupes,\
        \ ... ;\n* `Configuration`, contient les \xE9l\xE9ments de configuration de\
        \ la for\xEAt ;\n* `Schema`, contient la d\xE9finition de tous les objets\
        \ ;\n* `DomainDns`, contient les zones DNS de niveau domaine ;\n* `ForestDns`,\
        \ contient les zones DNS de niveau for\xEAt.\n\nIl est fortement d\xE9conseill\xE9\
        \ de changer les permissions par d\xE9faut de la racine des naming contexts.\
        \ Ainsi il est recommand\xE9 d'enlever ces permissions dangereuses. La correction\
        \ est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide du composant logiciel enfichable\
        \ `ADSI Edit` ou de l'utilitaire `ldp`.\n\nCertaines de ces permissions, notamment\
        \ relatives au service Microsoft Exchange, peuvent faire l'objet de correctifs\
        \ de s\xE9curit\xE9 qu'il est n\xE9cessaire d'appliquer. C'est notamment le\
        \ cas lorsque les objets suivants sont concern\xE9s :\n\n* Exchange Windows\
        \ Permissions ;\n* Exchange Trusted Subsystem.\n\nDocumentation relative aux\
        \ permissions Exchange positionn\xE9es sur la racine des domaines :\n\n* [https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server](https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server)\n\
        \nDocumentation relative aux comptes Azure ADConnect (MSOL) :\n\n* [https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account)\
        \ Utiliser la cmdlet `Set-ADSyncRestrictedPermissions`.\n\n## Contexte : chemins\
        \ de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9 d'un ensemble\
        \ de relations de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEE\
        trise d'un objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8\
        re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Limites\n\nCertains chemins de contr\xF4le peuvent\
        \ disposer de correctifs qui les rendent non exploitables. Ces cas imposent\
        \ g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs de domaine au m\xEA\
        me niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9s dangereuses peuvent\
        \ parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics.\
        \ Il est donc toujours recommand\xE9 de nettoyer les permissions concern\xE9\
        es de l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8\
        me.\n\nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Cas particulier de\
        \ Microsoft Exchange Server\n\nCertains chemins de contr\xF4le qui apparaissent\
        \ peuvent \xEAtre li\xE9s \xE0 des groupes Exchange b\xE9n\xE9ficiant de permissions\
        \ dangereuses. Deux cas particuliers peuvent se pr\xE9senter :\n\n1. s'il\
        \ s'agit de groupes datant d'une ancienne installation de Exchange Server\
        \ 2007 ou ant\xE9rieure (\"Exchange Enterprise Servers\", \"Exchange Domain\
        \ Servers\" ou \"Exchange Services\") et que cette infrastructure a \xE9t\xE9\
        \ migr\xE9e vers une version 2010 ou ult\xE9rieure, il est recommand\xE9 de\
        \ supprimer ces groupes et les permissions associ\xE9es. [Microsoft fournit\
        \ une proc\xE9dure \xE0 cette fin](https://learn.microsoft.com/fr-fr/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
        2. sinon pour les autres groupes, il convient de v\xE9rifier les contr\xF4\
        les dangereux concern\xE9s pour d\xE9terminer la correction ad\xE9quate (voir\
        \ plus bas).\n\nLes contr\xF4les suivants, uniquement s'ils sont mentionn\xE9\
        s pour un groupe li\xE9 \xE0 Exchange, ont fait l'objet d'un correctif de\
        \ Microsoft :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nAttention\
        \ : certaines des propri\xE9t\xE9s LDAP concern\xE9es par ces \xE9critures\
        \ (`servicePrincipalName` et `altSecurityIdentities`) font partie du property-set\
        \ `Public-Information`. Ainsi, les permissions d'\xE9critures peuvent \xEA\
        tre attribu\xE9es pour chaque attribut unitairement ou le property-set entier,\
        \ auquel cas seul ce dernier sera visible dans la DACL de l'objet concern\xE9\
        .\n\nPour appliquer ce correctif, il est n\xE9cessaire d'effectuer les actions\
        \ suivantes :\n\n* pour Exchange Server 2019 : installer le SU de mai 2022\
        \ sur le CU12 ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2016 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2013 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014260](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
        \ ;\n* pour toutes les versions, apr\xE8s installation des correctifs pr\xE9\
        c\xE9dents : ex\xE9cuter la phase de pr\xE9paration des domaines \"/PrepareAllDomains\"\
        \n  * pour Exchange Server 2019 et 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
        \ /PrepareAllDomains` ou `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
        \ /PrepareAllDomains` depuis le r\xE9pertoire d'installation de Exchange ;\n\
        \  * pour Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
        \ /PrepareAllDomains`;\n  * il est rappel\xE9 que Exchange Server 2010 n'est\
        \ plus support\xE9 par l'\xE9diteur.\n\nPour tout autre chemin de contr\xF4\
        le, une qualification manuelle doit \xEAtre effectu\xE9e pour caract\xE9riser\
        \ le probl\xE8me.\n\n\xC0 titre d'information, la liste des derniers correctifs\
        \ publi\xE9s pour Exchange Server est [disponible ici](https://learn.microsoft.com/fr-fr/exchange/new-features/build-numbers-and-release-dates).\n\
        \n## Acceptation du risque\n\nSi des permissions sp\xE9cifiques sont n\xE9\
        cessaires, il convient de consid\xE9rer que les comptes ou les groupes d\xE9\
        l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9gi\xE9s. Ainsi, ils doivent \xEA\
        tre correctement prot\xE9g\xE9s et leurs permissions appliqu\xE9es doivent\
        \ \xEAtre au moins aussi restrictives que celles appliqu\xE9es \xE0 l' `adminSDHolder`.\
        \ Il est donc n\xE9cessaire de leur appliquer des permissions \"s\xE9curis\xE9\
        es\". Pour cela, il est recommand\xE9 d'utiliser la commande ``Set-ADSyncRestrictedPermissions``\
        \ du module `AdSyncConfig.psm1` fourni avec Azure AD Connect. Cette commande\
        \ supprime l'h\xE9ritage et applique des permissions (ACE) restreintes. Pour\
        \ un groupe d\xE9l\xE9gu\xE9, l'application de cette seule commande n'est\
        \ pas suffisante : il faut \xE9galement retirer les membres du groupe, ou\
        \ les consid\xE9rer eux-m\xEAmes comme \xE9tant privil\xE9gi\xE9e en leur\
        \ appliquant la m\xEAme commande.\n\nExemple d'utilisation de ``Set-ADSyncRestrictedPermissions``\
        \ pour appliquer des permissions \"s\xE9curis\xE9es\" sur un compte privil\xE9\
        gi\xE9 :\n\n```powershell\nImport-Module .\\AdSyncConfig.psm1\n$credential\
        \ = Get-Credential\nSet-ADSyncRestrictedPermissions -ADConnectorAccountDN\
        \ \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\" -Credential $credential\n\
        ```\n\nNote : le module `AdSyncConfig.psm1` peut \xEAtre directement extrait\
        \ du fichier d'installation d'Azure AD Connect \xE0 l'aide de l'utilitaire\
        \ int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\\
        temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9l\xE9charg\xE9 \xE0\
        \ l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose a naming context root (attack path) (Level 1)
          description: '# Vulnerability description


            Dangerous ACLs expose the root of Active Directory naming contexts.


            These permissions grant the trusted Principal complete control over the
            Active Directory.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: "# Recommended measure\n\nAn Active Directory has several naming\
            \ contexts:\n\n* `Domain`, contains domain object information, such as\
            \ users, groups, computers, ...;\n* `Configuration`, contains forest configuration\
            \ settings;\n* `Schema`, contains object attribute definitions;\n* `DomainDns`,\
            \ contains domain-level DNS zones;\n* `ForestDns`, contains forest-level\
            \ DNZ zones.\n\nChanging default permissions to these various naming context\
            \ roots is strongly discouraged. They should be reverted to default permissions.\
            \ The fix is usually applied through the `adsiedit.msc` or `ldp` utilities.\n\
            \nSome of these access rights, especially regarding the Microsoft Exchange\
            \ service, can be fixed by relevant security updates which must be applied.\
            \ It is notably the case for the following principals:\n\n* Exchange Windows\
            \ Permissions\n* Exchange Trusted Subsystem\n\n* For Exchange Server-related\
            \ issues: [https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server](https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server)\n\
            * For Azure ADConnect Accounts (MSOL): [https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account)\
            \ Use the cmdlet `Set-ADSyncRestrictedPermissions`.\n\n## Context: control\
            \ path exposure\n\nA control path materializes through a set of granted\
            \ access permissions: each granted permission can be expressed as one\
            \ object controlling another through a specific property, attribute or\
            \ setting. Control paths reveal how an attacker could leverage a chain\
            \ of defective or dangerous permissions to gain control of some targets.\
            \ They can also be leveraged to quickly identify domain mismanagement,\
            \ to validate the actual security boundary of a particular scope (making\
            \ sure some object of interest cannot be taken over by unauthorized users\
            \ through misconfiguration). Indicators of compromise may also be found\
            \ through control path review.\n\n## Limitations\n\nSome control paths\
            \ may have fixes that renders them non-exploitable. Such a case usually\
            \ requires having all domain controllers equally up to date. Furthermore,\
            \ dangerous features may sometimes be re-enabled through a registry or\
            \ dsHeuristics setting. It is therefore still recommended to clean the\
            \ affected permissions from your Active Directory to prevent an accidental\
            \ re-occurrence.\n\nList of known specific fixes:\n\n* [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
            \ fixes the <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">OWNER</span> and <span style=\"background-color:rgb(255, 165,\
            \ 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> control path on computer\
            \ accounts only, but the dangerous behavior can still be re-enabled.\n\
            * Various Exchange-related control paths have been fixed through specific\
            \ cumulative updates; refer to the dedicated section below if applicable.\n\
            \n## Microsoft Exchange Server Specifics\n\nSome control paths under this\
            \ item may appear because of Exchange Server management groups with excessive\
            \ permissions. The cause can be:\n\n1. either the offending groups come\
            \ from a legacy Exchange Server 2007 or earlier instance (\"Exchange Enterprise\
            \ Servers\", \"Exchange Domain Servers\" ou \"Exchange Services\") which\
            \ has been migrated to version 2010 or later, it is then best to remove\
            \ those groups and associated permissions. [Microsoft provides relevant\
            \ guidance to fix these issues](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
            2. or these are current Exchange Server management groups, a specific\
            \ analysis will help select the applicable solution (see below).\n\nThe\
            \ following controls have been fixed by Microsoft, only if pertaining\
            \ to Exchange Server groups:\n\n* <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>\n* <span style=\"\
            background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n\
            * <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
            \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nWarning:\
            \ some LDAP attributes (`servicePrincipalName` and `altSecurityIdentities`)\
            \ behind these controls belong to the `Public-Information` property set.\
            \ Therefore, these write permissions may be granted on an attribute basis\
            \ or to the whole property set, in which case only this property set will\
            \ be visible in the object's DACL.\n\nApplying the official fix involves\
            \ the following steps:\n\n* Exchange Server 2019 : install may 2022 SU\
            \ on CU12 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2016 : install may 2022 SU on CU23 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2013 : install may 2022 SU on CU23 ([KB5014260](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
            \ ;\n* for all version, after applying the above security updates: run\
            \ the \"/PrepareAllDomains\" setup phase\n  * on Exchange Server 2019\
            \ and 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
            \ /PrepareAllDomains` or `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * on Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * Please note Exchange Server 2010 is not supported anymore by Microsoft.\n\
            \nAny other control path shall be manually investigated to properly address\
            \ the issue.\n\nA list of published Exchange Server security updates is\
            \ [available here](https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates).\n\
            \n## Risk Acceptance\n\nIf special permissions are required, delegated\
            \ groups or accounts should be considered as privileged. Therefore, they\
            \ must comply with appropriate protection measures, and their own access\
            \ control list should be at least as strict as that of the `adminSDHolder`\
            \ object. \"Secure\" ACLs should therefore be implemented on these delegated\
            \ groups, which will not open a new control path exposure. To remove inheritance\
            \ and restrict ACEs, the following command may be used: ``Set-ADSyncRestrictedPermissions``\
            \ found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated\
            \ groups, strengthening permissions using this command is not enough:\
            \ the permissions of this group's members must also be strengthened by\
            \ applying this command to them, or they can be removed from the delegated\
            \ group.\n\nExample: applying \"secure\" permission on a privileged account\
            \ through ``Set-ADSyncRestrictedPermissions``:\n\n```powershell\nImport-Module\
            \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
            \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
            \ -Credential $credential\n```\n\nNote: the `AdSyncConfig.psm1` module\
            \ may be extracted from the Azure AD Connect installer with `msiexec`:\
            \ `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\temp\\`\n\nThe\
            \ installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_naming_context-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_naming_context-l2
      name: "Permissions dangereuses sur la racine des naming contexts (chemins de\
        \ contr\xF4le) (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les racines LDAP de l'Active Directory, appel\xE9es naming\
        \ contexts.\n\nSelon le contr\xF4le appliqu\xE9 sur le naming context, un\
        \ attaquant peut prendre le contr\xF4le complet de l'Active Directory.\n\n\
        L\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4\
        le indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nUn annuaire Active Directory contient plusieurs\
        \ partitions appel\xE9es naming contexts:\n\n* `Domain`, contient les informations\
        \ des objets d'un domaine, comme les ordinateurs, les utilisateurs, les groupes,\
        \ ... ;\n* `Configuration`, contient les \xE9l\xE9ments de configuration de\
        \ la for\xEAt ;\n* `Schema`, contient la d\xE9finition de tous les objets\
        \ ;\n* `DomainDns`, contient les zones DNS de niveau domaine ;\n* `ForestDns`,\
        \ contient les zones DNS de niveau for\xEAt.\n\nIl est fortement d\xE9conseill\xE9\
        \ de changer les permissions par d\xE9faut de la racine des naming contexts.\
        \ Ainsi il est recommand\xE9 d'enlever ces permissions dangereuses. La correction\
        \ est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide du composant logiciel enfichable\
        \ `ADSI Edit` ou de l'utilitaire `ldp`.\n\nCertaines de ces permissions, notamment\
        \ relatives au service Microsoft Exchange, peuvent faire l'objet de correctifs\
        \ de s\xE9curit\xE9 qu'il est n\xE9cessaire d'appliquer. C'est notamment le\
        \ cas lorsque les objets suivants sont concern\xE9s :\n\n* Exchange Windows\
        \ Permissions ;\n* Exchange Trusted Subsystem.\n\nDocumentation relative aux\
        \ permissions Exchange positionn\xE9es sur la racine des domaines :\n\n* [https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server](https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server)\n\
        \nDocumentation relative aux comptes Azure ADConnect (MSOL) :\n\n* [https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account)\
        \ Utiliser la cmdlet `Set-ADSyncRestrictedPermissions`.\n\n## Contexte : chemins\
        \ de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9 d'un ensemble\
        \ de relations de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEE\
        trise d'un objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8\
        re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Limites\n\nCertains chemins de contr\xF4le peuvent\
        \ disposer de correctifs qui les rendent non exploitables. Ces cas imposent\
        \ g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs de domaine au m\xEA\
        me niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9s dangereuses peuvent\
        \ parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics.\
        \ Il est donc toujours recommand\xE9 de nettoyer les permissions concern\xE9\
        es de l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8\
        me.\n\nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Cas particulier de\
        \ Microsoft Exchange Server\n\nCertains chemins de contr\xF4le qui apparaissent\
        \ peuvent \xEAtre li\xE9s \xE0 des groupes Exchange b\xE9n\xE9ficiant de permissions\
        \ dangereuses. Deux cas particuliers peuvent se pr\xE9senter :\n\n1. s'il\
        \ s'agit de groupes datant d'une ancienne installation de Exchange Server\
        \ 2007 ou ant\xE9rieure (\"Exchange Enterprise Servers\", \"Exchange Domain\
        \ Servers\" ou \"Exchange Services\") et que cette infrastructure a \xE9t\xE9\
        \ migr\xE9e vers une version 2010 ou ult\xE9rieure, il est recommand\xE9 de\
        \ supprimer ces groupes et les permissions associ\xE9es. [Microsoft fournit\
        \ une proc\xE9dure \xE0 cette fin](https://learn.microsoft.com/fr-fr/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
        2. sinon pour les autres groupes, il convient de v\xE9rifier les contr\xF4\
        les dangereux concern\xE9s pour d\xE9terminer la correction ad\xE9quate (voir\
        \ plus bas).\n\nLes contr\xF4les suivants, uniquement s'ils sont mentionn\xE9\
        s pour un groupe li\xE9 \xE0 Exchange, ont fait l'objet d'un correctif de\
        \ Microsoft :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nAttention\
        \ : certaines des propri\xE9t\xE9s LDAP concern\xE9es par ces \xE9critures\
        \ (`servicePrincipalName` et `altSecurityIdentities`) font partie du property-set\
        \ `Public-Information`. Ainsi, les permissions d'\xE9critures peuvent \xEA\
        tre attribu\xE9es pour chaque attribut unitairement ou le property-set entier,\
        \ auquel cas seul ce dernier sera visible dans la DACL de l'objet concern\xE9\
        .\n\nPour appliquer ce correctif, il est n\xE9cessaire d'effectuer les actions\
        \ suivantes :\n\n* pour Exchange Server 2019 : installer le SU de mai 2022\
        \ sur le CU12 ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2016 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2013 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014260](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
        \ ;\n* pour toutes les versions, apr\xE8s installation des correctifs pr\xE9\
        c\xE9dents : ex\xE9cuter la phase de pr\xE9paration des domaines \"/PrepareAllDomains\"\
        \n  * pour Exchange Server 2019 et 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
        \ /PrepareAllDomains` ou `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
        \ /PrepareAllDomains` depuis le r\xE9pertoire d'installation de Exchange ;\n\
        \  * pour Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
        \ /PrepareAllDomains`;\n  * il est rappel\xE9 que Exchange Server 2010 n'est\
        \ plus support\xE9 par l'\xE9diteur.\n\nPour tout autre chemin de contr\xF4\
        le, une qualification manuelle doit \xEAtre effectu\xE9e pour caract\xE9riser\
        \ le probl\xE8me.\n\n\xC0 titre d'information, la liste des derniers correctifs\
        \ publi\xE9s pour Exchange Server est [disponible ici](https://learn.microsoft.com/fr-fr/exchange/new-features/build-numbers-and-release-dates).\n\
        \n## Acceptation du risque\n\nSi des permissions sp\xE9cifiques sont n\xE9\
        cessaires, il convient de consid\xE9rer que les comptes ou les groupes d\xE9\
        l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9gi\xE9s. Ainsi, ils doivent \xEA\
        tre correctement prot\xE9g\xE9s et leurs permissions appliqu\xE9es doivent\
        \ \xEAtre au moins aussi restrictives que celles appliqu\xE9es \xE0 l' `adminSDHolder`.\
        \ Il est donc n\xE9cessaire de leur appliquer des permissions \"s\xE9curis\xE9\
        es\". Pour cela, il est recommand\xE9 d'utiliser la commande ``Set-ADSyncRestrictedPermissions``\
        \ du module `AdSyncConfig.psm1` fourni avec Azure AD Connect. Cette commande\
        \ supprime l'h\xE9ritage et applique des permissions (ACE) restreintes. Pour\
        \ un groupe d\xE9l\xE9gu\xE9, l'application de cette seule commande n'est\
        \ pas suffisante : il faut \xE9galement retirer les membres du groupe, ou\
        \ les consid\xE9rer eux-m\xEAmes comme \xE9tant privil\xE9gi\xE9e en leur\
        \ appliquant la m\xEAme commande.\n\nExemple d'utilisation de ``Set-ADSyncRestrictedPermissions``\
        \ pour appliquer des permissions \"s\xE9curis\xE9es\" sur un compte privil\xE9\
        gi\xE9 :\n\n```powershell\nImport-Module .\\AdSyncConfig.psm1\n$credential\
        \ = Get-Credential\nSet-ADSyncRestrictedPermissions -ADConnectorAccountDN\
        \ \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\" -Credential $credential\n\
        ```\n\nNote : le module `AdSyncConfig.psm1` peut \xEAtre directement extrait\
        \ du fichier d'installation d'Azure AD Connect \xE0 l'aide de l'utilitaire\
        \ int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\\
        temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9l\xE9charg\xE9 \xE0\
        \ l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous ACLs expose a naming context root (attack path) (Level 2)
          description: '# Vulnerability description


            Dangerous ACLs expose the root of Active Directory naming contexts.


            These permissions grant the trusted Principal complete control over the
            Active Directory.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: "# Recommended measure\n\nAn Active Directory has several naming\
            \ contexts:\n\n* `Domain`, contains domain object information, such as\
            \ users, groups, computers, ...;\n* `Configuration`, contains forest configuration\
            \ settings;\n* `Schema`, contains object attribute definitions;\n* `DomainDns`,\
            \ contains domain-level DNS zones;\n* `ForestDns`, contains forest-level\
            \ DNZ zones.\n\nChanging default permissions to these various naming context\
            \ roots is strongly discouraged. They should be reverted to default permissions.\
            \ The fix is usually applied through the `adsiedit.msc` or `ldp` utilities.\n\
            \nSome of these access rights, especially regarding the Microsoft Exchange\
            \ service, can be fixed by relevant security updates which must be applied.\
            \ It is notably the case for the following principals:\n\n* Exchange Windows\
            \ Permissions\n* Exchange Trusted Subsystem\n\n* For Exchange Server-related\
            \ issues: [https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server](https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server)\n\
            * For Azure ADConnect Accounts (MSOL): [https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account)\
            \ Use the cmdlet `Set-ADSyncRestrictedPermissions`.\n\n## Context: control\
            \ path exposure\n\nA control path materializes through a set of granted\
            \ access permissions: each granted permission can be expressed as one\
            \ object controlling another through a specific property, attribute or\
            \ setting. Control paths reveal how an attacker could leverage a chain\
            \ of defective or dangerous permissions to gain control of some targets.\
            \ They can also be leveraged to quickly identify domain mismanagement,\
            \ to validate the actual security boundary of a particular scope (making\
            \ sure some object of interest cannot be taken over by unauthorized users\
            \ through misconfiguration). Indicators of compromise may also be found\
            \ through control path review.\n\n## Limitations\n\nSome control paths\
            \ may have fixes that renders them non-exploitable. Such a case usually\
            \ requires having all domain controllers equally up to date. Furthermore,\
            \ dangerous features may sometimes be re-enabled through a registry or\
            \ dsHeuristics setting. It is therefore still recommended to clean the\
            \ affected permissions from your Active Directory to prevent an accidental\
            \ re-occurrence.\n\nList of known specific fixes:\n\n* [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
            \ fixes the <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">OWNER</span> and <span style=\"background-color:rgb(255, 165,\
            \ 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> control path on computer\
            \ accounts only, but the dangerous behavior can still be re-enabled.\n\
            * Various Exchange-related control paths have been fixed through specific\
            \ cumulative updates; refer to the dedicated section below if applicable.\n\
            \n## Microsoft Exchange Server Specifics\n\nSome control paths under this\
            \ item may appear because of Exchange Server management groups with excessive\
            \ permissions. The cause can be:\n\n1. either the offending groups come\
            \ from a legacy Exchange Server 2007 or earlier instance (\"Exchange Enterprise\
            \ Servers\", \"Exchange Domain Servers\" ou \"Exchange Services\") which\
            \ has been migrated to version 2010 or later, it is then best to remove\
            \ those groups and associated permissions. [Microsoft provides relevant\
            \ guidance to fix these issues](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
            2. or these are current Exchange Server management groups, a specific\
            \ analysis will help select the applicable solution (see below).\n\nThe\
            \ following controls have been fixed by Microsoft, only if pertaining\
            \ to Exchange Server groups:\n\n* <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>\n* <span style=\"\
            background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n\
            * <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
            \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nWarning:\
            \ some LDAP attributes (`servicePrincipalName` and `altSecurityIdentities`)\
            \ behind these controls belong to the `Public-Information` property set.\
            \ Therefore, these write permissions may be granted on an attribute basis\
            \ or to the whole property set, in which case only this property set will\
            \ be visible in the object's DACL.\n\nApplying the official fix involves\
            \ the following steps:\n\n* Exchange Server 2019 : install may 2022 SU\
            \ on CU12 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2016 : install may 2022 SU on CU23 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2013 : install may 2022 SU on CU23 ([KB5014260](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
            \ ;\n* for all version, after applying the above security updates: run\
            \ the \"/PrepareAllDomains\" setup phase\n  * on Exchange Server 2019\
            \ and 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
            \ /PrepareAllDomains` or `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * on Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * Please note Exchange Server 2010 is not supported anymore by Microsoft.\n\
            \nAny other control path shall be manually investigated to properly address\
            \ the issue.\n\nA list of published Exchange Server security updates is\
            \ [available here](https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates).\n\
            \n## Risk Acceptance\n\nIf special permissions are required, delegated\
            \ groups or accounts should be considered as privileged. Therefore, they\
            \ must comply with appropriate protection measures, and their own access\
            \ control list should be at least as strict as that of the `adminSDHolder`\
            \ object. \"Secure\" ACLs should therefore be implemented on these delegated\
            \ groups, which will not open a new control path exposure. To remove inheritance\
            \ and restrict ACEs, the following command may be used: ``Set-ADSyncRestrictedPermissions``\
            \ found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated\
            \ groups, strengthening permissions using this command is not enough:\
            \ the permissions of this group's members must also be strengthened by\
            \ applying this command to them, or they can be removed from the delegated\
            \ group.\n\nExample: applying \"secure\" permission on a privileged account\
            \ through ``Set-ADSyncRestrictedPermissions``:\n\n```powershell\nImport-Module\
            \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
            \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
            \ -Credential $credential\n```\n\nNote: the `AdSyncConfig.psm1` module\
            \ may be extracted from the Azure AD Connect installer with `msiexec`:\
            \ `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\temp\\`\n\nThe\
            \ installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_schema-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_schema-l1
      name: "Permissions dangereuses sur les objets du sch\xE9ma (chemins de contr\xF4\
        le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les objets du sch\xE9ma. Un attaquant ayant un contr\xF4le\
        \ sur le sch\xE9ma peut prendre le contr\xF4le complet de l'Active Directory.\n\
        \nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4\
        le indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nLe sch\xE9ma est l'une des trois partitions\
        \ (appel\xE9es aussi naming context) de l'Active Directory. Il contient la\
        \ d\xE9finition de tous les objets de la for\xEAt Active Directory.\n\nIl\
        \ est fortement d\xE9conseill\xE9 de changer les permissions par d\xE9faut\
        \ de ces objets sauf dans le cadre d'une pr\xE9paration de for\xEAt lors de\
        \ la mise \xE0 jour du niveau fonctionnel de la for\xEAt ou lors de l'installation\
        \ d'un composant. Ainsi il est recommand\xE9 d'enlever les permissions dangereuses\
        \ sur les objets du sch\xE9ma afin de revenir \xE0 un \xE9tat par d\xE9faut.\
        \ La correction peut \xEAtre effectu\xE9e \xE0 l'aide de la commande `Dsacls\
        \ <DN> /S /T`. Cette commande restaure les permissions par d\xE9faut \xE0\
        \ partir du sch\xE9ma.\n\nDescripteurs de s\xE9curit\xE9 par d\xE9faut :\n\
        \n* `User`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-user\n\
        * `Group`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-group\n\
        * `Computer`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-computer\n\
        * `Group-Policy-Container`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-grouppolicycontainer\n\
        \n## Contexte : chemins de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9\
        \ d'un ensemble de relations de contr\xF4le direct, o\xF9 chaque relation\
        \ traduit la ma\xEEtrise d'un objet sur un autre au travers d'une propri\xE9\
        t\xE9 particuli\xE8re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des\
        \ moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier\
        \ des d\xE9viances dans la gestion du domaine, de valider l'application d'un\
        \ p\xE9rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais\
        \ \xE9galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un\
        \ attaquant apr\xE8s une compromission.\n\n## Limites\n\nCertains chemins\
        \ de contr\xF4le peuvent disposer de correctifs qui les rendent non exploitables.\
        \ Ces cas imposent g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs\
        \ de domaine au m\xEAme niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9\
        s dangereuses peuvent parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre\
        \ de registre ou dsHeuristics. Il est donc toujours recommand\xE9 de nettoyer\
        \ les permissions concern\xE9es de l'Active Directory pour pr\xE9venir une\
        \ r\xE9apparition du probl\xE8me.\n\nListe des correctifs sp\xE9cifiques connus\
        \ :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose schema objects (attack path) (Level 1)
          description: '# Vulnerability description


            Dangerous ACLs expose schema objects. These permissions grant the trusted
            Principal complete control over the Active Directory.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            Schema is one of three main Active Directory naming context. It contains
            every object attribute definitions of the forest.


            Changing default permissions to these various naming context roots is
            strongly discouraged, except when upgrading a forest functional level
            or when installing specific components. They should be reverted to default
            permissions. To restore default permission the following command may be
            used: `Dsacls <DN> /S /T`. This command restores the permissions from
            the schema.


            Default security descriptors:


            * `User`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-user

            * `Group`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-group

            * `Computer`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-computer

            * `Group-Policy-Container`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-grouppolicycontainer


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_schema-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_schema-l2
      name: "Permissions dangereuses sur les objets du sch\xE9ma (chemins de contr\xF4\
        le) (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les objets du sch\xE9ma. Un attaquant ayant un contr\xF4le\
        \ sur le sch\xE9ma peut prendre le contr\xF4le complet de l'Active Directory.\n\
        \nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4\
        le indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nLe sch\xE9ma est l'une des trois partitions\
        \ (appel\xE9es aussi naming context) de l'Active Directory. Il contient la\
        \ d\xE9finition de tous les objets de la for\xEAt Active Directory.\n\nIl\
        \ est fortement d\xE9conseill\xE9 de changer les permissions par d\xE9faut\
        \ de ces objets sauf dans le cadre d'une pr\xE9paration de for\xEAt lors de\
        \ la mise \xE0 jour du niveau fonctionnel de la for\xEAt ou lors de l'installation\
        \ d'un composant. Ainsi il est recommand\xE9 d'enlever les permissions dangereuses\
        \ sur les objets du sch\xE9ma afin de revenir \xE0 un \xE9tat par d\xE9faut.\
        \ La correction peut \xEAtre effectu\xE9e \xE0 l'aide de la commande `Dsacls\
        \ <DN> /S /T`. Cette commande restaure les permissions par d\xE9faut \xE0\
        \ partir du sch\xE9ma.\n\nDescripteurs de s\xE9curit\xE9 par d\xE9faut :\n\
        \n* `User`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-user\n\
        * `Group`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-group\n\
        * `Computer`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-computer\n\
        * `Group-Policy-Container`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-grouppolicycontainer\n\
        \n## Contexte : chemins de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9\
        \ d'un ensemble de relations de contr\xF4le direct, o\xF9 chaque relation\
        \ traduit la ma\xEEtrise d'un objet sur un autre au travers d'une propri\xE9\
        t\xE9 particuli\xE8re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des\
        \ moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier\
        \ des d\xE9viances dans la gestion du domaine, de valider l'application d'un\
        \ p\xE9rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais\
        \ \xE9galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un\
        \ attaquant apr\xE8s une compromission.\n\n## Limites\n\nCertains chemins\
        \ de contr\xF4le peuvent disposer de correctifs qui les rendent non exploitables.\
        \ Ces cas imposent g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs\
        \ de domaine au m\xEAme niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9\
        s dangereuses peuvent parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre\
        \ de registre ou dsHeuristics. Il est donc toujours recommand\xE9 de nettoyer\
        \ les permissions concern\xE9es de l'Active Directory pour pr\xE9venir une\
        \ r\xE9apparition du probl\xE8me.\n\nListe des correctifs sp\xE9cifiques connus\
        \ :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous ACLs expose schema objects (attack path) (Level 2)
          description: '# Vulnerability description


            Dangerous ACLs expose schema objects. These permissions grant the trusted
            Principal complete control over the Active Directory.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            Schema is one of three main Active Directory naming context. It contains
            every object attribute definitions of the forest.


            Changing default permissions to these various naming context roots is
            strongly discouraged, except when upgrading a forest functional level
            or when installing specific components. They should be reverted to default
            permissions. To restore default permission the following command may be
            used: `Dsacls <DN> /S /T`. This command restores the permissions from
            the schema.


            Default security descriptors:


            * `User`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-user

            * `Group`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-group

            * `Computer`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-computer

            * `Group-Policy-Container`: https://learn.microsoft.com/en-us/windows/win32/adschema/c-grouppolicycontainer


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_msdns-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_msdns-l1
      name: "Permissions dangereuses sur les objets serveurs MicrosoftDNS (chemins\
        \ de contr\xF4le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les objets de serveurs DNS Microsoft.\n\nLes comptes ayant\
        \ le droit d'\xE9crire les propri\xE9t\xE9s du conteneur `CN=MicrosoftDNS,CN=System`\
        \ ont la possibilit\xE9 de faire ex\xE9cuter du code arbitraire par le service\
        \ DNS, qui est g\xE9n\xE9ralement h\xE9berg\xE9 par un contr\xF4leur de domaine.\
        \ Par d\xE9faut, les membres du groupe `DnsAdmins` ont ce droit.\n\nL\xE9\
        gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4le\
        \ indirect faible\n\n# Permissions dangereuses et chemins de contr\xF4le\n\
        \nDes permissions dangereuses permettent la prise de contr\xF4le d'un objet\
        \ cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9criture\
        \ de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl est recommand\xE9 de retirer la permission\
        \ d'\xE9criture sur les propri\xE9t\xE9s du conteneur `CN=MicrosoftDNS,CN=System`\
        \ pour ces comptes.\n\nSi la mise en place d'une telle permission a \xE9t\xE9\
        \ faite pour la gestion du DNS, il est possible de cr\xE9er une d\xE9l\xE9\
        gation manuellement. Cette d\xE9l\xE9gation est g\xE9n\xE9ralement effectu\xE9\
        e \xE0 l'aide de l'utilitaire `ldp` et elle peut \xEAtre effectu\xE9e en deux\
        \ \xE9tapes.\n\n## \xC9tape 1: autoriser l'acc\xE8s aux RPC n\xE9cessaires\
        \ \xE0 l'utilisation des composants enfichables de gestion DNS\n\nDans la\
        \ partition du domaine, dans le conteneur `CN=System`, d\xE9l\xE9guer les\
        \ droits suivants sur le conteneur `CN=MicrosoftDNS`:\n\n|  |  |  |  |\n|\
        \ --- | --- | --- | --- |\n| <input type=\"checkbox\" disabled checked />\
        \ Propri\xE9t\xE9 de lecture | <input type=\"checkbox\" disabled /> Propri\xE9\
        t\xE9 d'\xE9criture | <input type=\"checkbox\" disabled /> Cr\xE9er un enfant\
        \ | <input type=\"checkbox\" disabled /> Contr\xF4ler l'acc\xE8s |\n| <input\
        \ type=\"checkbox\" disabled checked /> Liste | <input type=\"checkbox\" disabled\
        \ /> DACL d'\xE9criture | <input type=\"checkbox\" disabled /> Supprimer un\
        \ enfant | <input type=\"checkbox\" disabled /> \xC9criture \xE9tendue |\n\
        | <input type=\"checkbox\" disabled checked /> Afficher la liste pour l'objet\
        \ | <input type=\"checkbox\" disabled /> Acc\xE8s en \xE9criture au propri\xE9\
        taire | <input type=\"checkbox\" disabled /> Supprimer |\n| <input type=\"\
        checkbox\" disabled checked /> Autorisations de lecture | <input type=\"checkbox\"\
        \ disabled /> \xC9crire la liste SACL | <input type=\"checkbox\" disabled\
        \ /> Supprimer l'arborescence |\n\n## \xC9tape 2: autoriser la modification\
        \ de la zone DNS\n\nDans la partition `DC=DomainDnsZones`, sur chaque zone\
        \ ayant besoin d'\xEAtre administr\xE9e, d\xE9l\xE9guer les droits suivants\
        \ avec h\xE9ritage sur le conteneur `CN=MicrosoftDNS`:\n\n|  |  |  |  |\n\
        | --- | --- | --- | --- |\n| <input type=\"checkbox\" disabled checked />\
        \ Propri\xE9t\xE9 de lecture | <input type=\"checkbox\" disabled /> Propri\xE9\
        t\xE9 d'\xE9criture | <input type=\"checkbox\" disabled checked /> Cr\xE9\
        er un enfant | <input type=\"checkbox\" disabled /> Contr\xF4ler l'acc\xE8\
        s |\n| <input type=\"checkbox\" disabled checked /> Liste | <input type=\"\
        checkbox\" disabled /> DACL d'\xE9criture | <input type=\"checkbox\" disabled\
        \ checked /> Supprimer un enfant | <input type=\"checkbox\" disabled /> \xC9\
        criture \xE9tendue |\n| <input type=\"checkbox\" disabled checked /> Afficher\
        \ la liste pour l'objet | <input type=\"checkbox\" disabled /> Acc\xE8s en\
        \ \xE9criture au propri\xE9taire | <input type=\"checkbox\" disabled checked\
        \ /> Supprimer |\n| <input type=\"checkbox\" disabled checked /> Autorisations\
        \ de lecture | <input type=\"checkbox\" disabled /> \xC9crire la liste SACL\
        \ | <input type=\"checkbox\" disabled checked /> Supprimer l'arborescence\
        \ |\n\nAttention \xE0 ne pas oublier \xE9galement de d\xE9l\xE9guer les zones\
        \ inverses (reverse DNS).\n\nNote : pour changer de naming context (partition)\
        \ dans `ldp`, il faut utiliser le menu `affichage`, `arborescence` et utiliser\
        \ le menu d\xE9roulant pour s\xE9lectionner `DomainDnsZones`.\n\n## Contexte\
        \ : chemins de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9 d'un\
        \ ensemble de relations de contr\xF4le direct, o\xF9 chaque relation traduit\
        \ la ma\xEEtrise d'un objet sur un autre au travers d'une propri\xE9t\xE9\
        \ particuli\xE8re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des moyens\
        \ pour un attaquant d'atteindre des cibles, et permettent d'identifier des\
        \ d\xE9viances dans la gestion du domaine, de valider l'application d'un p\xE9\
        rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9\
        galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant\
        \ apr\xE8s une compromission.\n\n## Limites\n\nCertains chemins de contr\xF4\
        le peuvent disposer de correctifs qui les rendent non exploitables. Ces cas\
        \ imposent g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs de domaine\
        \ au m\xEAme niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9s dangereuses\
        \ peuvent parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre de registre\
        \ ou dsHeuristics. Il est donc toujours recommand\xE9 de nettoyer les permissions\
        \ concern\xE9es de l'Active Directory pour pr\xE9venir une r\xE9apparition\
        \ du probl\xE8me.\n\nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose MicrosoftDNS server objects (attack path) (Level
            1)
          description: '# Vulnerability description


            Dangerous ACLs expose Microsoft DNS server objects.


            Accounts granted permission to write the `CN=MicrosoftDNS,CN=System` container
            attributes have the ability to run arbitrary code on the DNS service,
            which is typically run on domain controllers. `DnsAdmins` group members
            have this permission by default.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            The `DnsAdmins` must not be used: manual DNS zone delegations must be
            used instead to manage the service (zone creation/deletion, record management,
            ...). These delegations are usually granted through the `ldp` utility.
            This is a two-step process:


            ## Step 1: allow access to RPC used by DNS management MMC snap in


            In the domain naming context, under the `CN=System` container, set the
            following access rights on the `CN=MicrosoftDNS` container:


            |  |  |  |  |

            | --- | --- | --- | --- |

            | <input type="checkbox" disabled checked /> Read property | <input type="checkbox"
            disabled /> Write Property | <input type="checkbox" disabled /> Create
            Child | <input type="checkbox" disabled /> Control access |

            | <input type="checkbox" disabled checked /> List | <input type="checkbox"
            disabled /> Write DACL | <input type="checkbox" disabled /> Delete child
            | <input type="checkbox" disabled /> Extended write |

            | <input type="checkbox" disabled checked /> List object | <input type="checkbox"
            disabled /> Write owner | <input type="checkbox" disabled /> Delete |

            | <input type="checkbox" disabled checked /> Read permissions | <input
            type="checkbox" disabled /> Write SACL | <input type="checkbox" disabled
            /> Delete tree |


            ## Step 2: allow DNS zone modifications


            In the `DC=DomainDnsZones` naming context, on every zone you wish to delegate
            management, enable inheritance and set the following access rights on
            the `CN=MicrosoftDNS` container:


            |  |  |  |  |

            | --- | --- | --- | --- |

            | <input type="checkbox" disabled checked /> Read property | <input type="checkbox"
            disabled /> Write Property | <input type="checkbox" disabled checked />
            Create Child | <input type="checkbox" disabled /> Control access |

            | <input type="checkbox" disabled checked /> List | <input type="checkbox"
            disabled /> Write DACL | <input type="checkbox" disabled checked /> Delete
            child | <input type="checkbox" disabled /> Extended write |

            | <input type="checkbox" disabled checked /> List object | <input type="checkbox"
            disabled /> Write owner | <input type="checkbox" disabled checked /> Delete
            |

            | <input type="checkbox" disabled checked /> Read permissions | <input
            type="checkbox" disabled /> Write SACL | <input type="checkbox" disabled
            checked /> Delete tree |


            Note: to change the current naming context in `ldp`, go to `View`, `Tree`
            and use the drop-down list to select `DomainDnsZones`.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_gpo_priv-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_gpo_priv-l1
      name: "Permissions dangereuses sur les objets de GPO s'appliquant aux membres\
        \ des groupes privil\xE9gi\xE9s (chemins de contr\xF4le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur les objets des GPO s'appliquant aux membres des groupes privil\xE9\
        gi\xE9s. Un attaquant ayant le contr\xF4le sur ces GPO peut ex\xE9cuter du\
        \ code sur les machines utilis\xE9es par ces membres et \xE9lever ses privil\xE8\
        ges.\n\nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect,\
        \ Contr\xF4le indirect faible\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl est recommand\xE9 de revoir les permissions\
        \ positionn\xE9es sur les GPO.\n\nLa correction doit \xEAtre effectu\xE9e\
        \ \xE0 l'aide du composant logiciel enfichable de gestion des GPO `gpmc.msc`\
        \ afin de maintenir la synchronisation des permissions entre l'annuaire LDAP\
        \ et le r\xE9pertoire SYSVOL.\n\nLa correction s'effectue dans l'onglet \"\
        D\xE9l\xE9gation\", il est toutefois recommand\xE9 d'utiliser la vue \"avanc\xE9\
        e\" de cet \xE9diteur.\n\nAvant d'accepter le risque (voir ci-dessous), il\
        \ est fortement recommand\xE9 de s'assurer qu'il est bien intentionnel de\
        \ consid\xE9rer comme des administrateurs T0 l'ensemble des principals pour\
        \ lesquels il existe un chemin de contr\xF4le vers ces GPOs. En cas d'acceptation\
        \ du risque, l'ensemble des principals (y compris leurs membres pour les groupes,\
        \ r\xE9cursivement) pour lesquels il existe un chemin de contr\xF4le vers\
        \ ces GPOs doivent \xEAtre consid\xE9r\xE9s comme privil\xE9gi\xE9s, et doivent\
        \ \xEAtre prot\xE9g\xE9s.\n\n## Contexte : chemins de contr\xF4le\n\nUn chemin\
        \ de contr\xF4le est compos\xE9 d'un ensemble de relations de contr\xF4le\
        \ direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet sur un autre\
        \ au travers d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les chemins de\
        \ contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre des\
        \ cibles, et permettent d'identifier des d\xE9viances dans la gestion du domaine,\
        \ de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9 autour des\
        \ cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler des moyens\
        \ de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose GPOs applied to privileged group members (attack
            path) (Level 1)
          description: '# Vulnerability description


            Dangerous ACLs expose GPOs that are applied to privileged group members.
            An attacker gaining access to these GPOs may execute code on those privilege
            account workstations to escalate their privileges.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            GPO LDAP object permissions should be reviewed.


            The fix should be applied is usually applied using the `gpmc.msc` utility
            which ensures permissions as synchronized with the SYSVOL folder.


            Before accepting the risk (see below), review the list of principals and
            ensure that they should really be considered as T0 administrators. In
            case of risk acceptance, all principals (including their members for groups,
            recursively) for whom a control path exists to a GPO that is applied to
            privileged group members must also be considered as privileged and protected
            as such.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_primary_group_id_1000-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_primary_group_id_1000-l1
      name: "Comptes avec un PrimaryGroupID inf\xE9rieur \xE0 1000 (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nCertains utilisateurs\
        \ ou ordinateurs ont un attribut `primaryGroupId` en dehors des valeurs par\
        \ d\xE9faut recommand\xE9es. Les `primaryGroupId` inf\xE9rieurs \xE0 1000\
        \ sont souvent privil\xE9gi\xE9s."
      annotation: "# Recommandation\n\nDans le fonctionnement d'un Active Directory,\
        \ l'attribut `primaryGroupId` d'un compte utilisateur ou machine permet d'affecter\
        \ implicitement ce compte \xE0 un groupe, m\xEAme si ce groupe n'est pas r\xE9\
        pertori\xE9 par l'attribut `memberOf` de l'utilisateur. L'appartenance \xE0\
        \ un groupe via cet attribut n'appara\xEEt pas dans la liste des membres du\
        \ groupe dans certaines interfaces. Cet attribut peut permettre de dissimuler\
        \ l'appartenance d'un compte \xE0 un groupe.\n\nIl est recommand\xE9 de repositionner\
        \ les attributs `primaryGroupId` des utilisateurs ou ordinateurs concern\xE9\
        s \xE0 leur valeur par d\xE9faut :\n\n* utilisateurs: 513 (*Utilisateurs du\
        \ domaine* (Domain Users)) ou 514 (*Invit\xE9s du domaine* (Domain Guests));\
        \ ;\n* ordinateurs: 515 (*Ordinateurs du domaine* (Domain Computers)) ;\n\
        * contr\xF4leurs de domaine: 516 (*Contr\xF4leurs de domaine* (Domain Controllers))\
        \ ;\n* contr\xF4leurs de domaine en lecture seule (RODC) : 521 (*Contr\xF4\
        leurs de domaine en lecture seule* (Read-only Domain Controllers))."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Accounts with PrimaryGroupID lower than 1000 (Level 1)
          description: '# Vulnerability description


            Some users or computers have a `primaryGroupId` attribute lower than 1000.
            `primaryGroupId` values lower than 1000 are usually privileged.'
          annotation: "# Recommended measure\n\nThe `primaryGroupId` attribute of\
            \ a user or computer account grants implicit membership to a group. Membership\
            \ through this attribute does not appear in the list of group members\
            \ in some interfaces. This attribute may be used as an attempt to hide\
            \ group membership.\n\nReset the `primaryGroupId` attributes of users\
            \ and computers to their default values:\n\n* user accounts: 513 (*Domain\
            \ Users* (Utilisateurs du domaine)) or 514 (*Domain Guests* (Invit\xE9\
            s du domaine));\n* computer accounts: 515 (*Domain Computers* (Ordinateurs\
            \ du domaine));\n* domain controller accounts: 516 (*Domain Controllers*\
            \ (Contr\xF4leurs de domaine));\n* read-only domain controller (RODC)\
            \ accounts : 521 (*Read-only Domain Controllers* (Contr\xF4leurs de domaine\
            \ en lecture seule))."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_privileged_members-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_privileged_members-l1
      name: "Nombre important de membres des groupes privil\xE9gi\xE9s (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa for\xEAt contient\
        \ trop de comptes privil\xE9gi\xE9s (**?** comptes). Le seuil est fix\xE9\
        \ \xE0 50 comptes ou \xE0 3 fois le nombre de domaines de la for\xEAt.\n\n\
        La pr\xE9sence d'un nombre important de comptes privil\xE9gi\xE9s ne permet\
        \ pas d'en assurer le contr\xF4le : cela induit une mauvaise visibilit\xE9\
        \ des comptes privil\xE9gi\xE9s r\xE9ellement n\xE9cessaires, une augmentation\
        \ du risque d'oubli de d\xE9sactivation ou de suppression d'un compte non\
        \ utilis\xE9, etc.\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* Au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> les comptes sont d\xE9dupliqu\xE9\
        s par l'attribut `sAMAccountName`;\n* Au niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> les comptes uniques sont consid\xE9\
        r\xE9s.\n\nNote : les comptes int\xE9gr\xE9s `RID-500` ainsi que les contr\xF4\
        leurs de domaine sont ignor\xE9s pour le d\xE9compte ci-dessus. Chaque compte\
        \ privil\xE9gi\xE9 ne sera compt\xE9 qu'une fois, m\xEAme s'il est membre\
        \ de plusieurs groupes privil\xE9gi\xE9s."
      annotation: "# Recommandation\n\nLes groupes privil\xE9gi\xE9s de l'Active Directory\
        \ permettent aux comptes qui en sont membres de poss\xE9der le plus haut niveau\
        \ de droits et privil\xE8ges la for\xEAt. L'utilisation de ces groupes, \xE0\
        \ l'exception des groupes \xAB *Administrateurs* (Administrators) \xBB et\
        \ \xAB *Administrateurs du domaine* (Domain Admins) \xBB, procure donc un\
        \ faux sentiment de s\xE9curit\xE9.\n\nIl est n\xE9cessaire de mettre en place\
        \ un mod\xE8le d'administration permettant de r\xE9duire le nombre de comptes\
        \ privil\xE9gi\xE9s. Pour cela, il convient de r\xE9f\xE9rencer les besoins\
        \ d'administration de chaque compte et de faire les d\xE9l\xE9gations ad hoc.\
        \ Par exemple, pour un administrateur ayant besoin de cr\xE9er et de supprimer\
        \ des utilisateurs, les d\xE9l\xE9gations n\xE9cessaires seront :\n\n* cr\xE9\
        er un enfant ;\n* supprimer un enfant ;\n* propri\xE9t\xE9 d'\xE9criture ;\n\
        * reset password.\n\nCette d\xE9l\xE9gation est g\xE9n\xE9ralement effectu\xE9\
        e \xE0 l'aide de l'utilitaire `ldp`.\n\nNote : l'\xAB Assistant D\xE9l\xE9\
        gation de contr\xF4le \xBB de l'Active Directory permet \xE9galement de d\xE9\
        l\xE9guer certaines actions d'administration. Bien que plus facile d'utilisation,\
        \ cet assistant positionne trop de privil\xE8ges pour certaines d\xE9l\xE9\
        gations. Il est donc conseill\xE9 de privil\xE9gier l'utilitaire `ldp`.\n\n\
        Enfin, les r\xE8gles d'appartenance suivantes doivent \xEAtre mises en \u0153\
        uvre :\n\n* groupes op\xE9ratifs : tous vides ;\n* groupes r\xE9plicateurs\
        \ : tous vides ;\n* groupes d'administration de niveau for\xEAt (entreprise\
        \ et sch\xE9ma) : vides et peupl\xE9s temporairement uniquement lors d'op\xE9\
        rations n\xE9cessitant ces droits ;\n* groupes d'administration de niveau\
        \ domaine : aucun compte de service.\n\n## Contexte : groupes privil\xE9gi\xE9\
        s\n\nLes groupes privil\xE9gi\xE9s sont les groupes d'administration et les\
        \ groupes op\xE9ratifs ayant tous les droits et privil\xE8ges sur la for\xEA\
        t ou pouvant se les attribuer :\n\n* \xAB *Administrateurs* (Administrators)\
        \ \xBB ;\n* \xAB *Contr\xF4leurs de domaine* (Domain Controllers) \xBB;\n\
        * \xAB *Administrateurs du sch\xE9ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs\
        \ de l'entreprise* (Enterprise Admins) \xBB ;\n* \xAB *Administrateurs du\
        \ domaine* (Domain Admins) \xBB : ces administrateurs ont les privil\xE8ges\
        \ de lire la base des secrets de tous les comptes et donc d'extraire les secrets\
        \ de l'ensemble des comptes privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de\
        \ cl\xE9s* (Key Admins) \xBB et \xAB *Administrateurs de cl\xE9s de l'entreprise*\
        \ (Enterprise Key Admins) \xBB: ces administrateurs peuvent fixer des valeurs\
        \ arbitraires aux attributs relatifs \xE0 Windows Hello for Business, pour\
        \ tous les utilisateurs sauf ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`.\
        \ Si l'authentification bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9\
        e, ils peuvent g\xE9n\xE9rer un certificat sous leur contr\xF4le, l'assigner\
        \ \xE0 un compte privil\xE9gi\xE9 (par exemple, un contr\xF4leur de domaine),\
        \ et s'authentifier en tant que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer tous les comptes\
        \ d'utilisateurs, machines et groupes; \xE0 l'exception des comptes prot\xE9\
        g\xE9s par l' `adminSDHolder`;\n* \xAB *Op\xE9rateurs de serveur* (Server\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer les contr\xF4leurs\
        \ de domaine, et donc r\xE9cup\xE9rer les secrets de tous les comptes privil\xE9\
        gi\xE9s ;\n* \xAB *Op\xE9rateurs de sauvegarde* (Backup Operators) \xBB :\
        \ ces op\xE9rateurs peuvent sauvegarder un contr\xF4leur de domaine et donc\
        \ extraire les secrets de tous les comptes privil\xE9gi\xE9s depuis cette\
        \ sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression* (Print Operators) \xBB\
        \ : ces op\xE9rateurs peuvent charger des pilotes d'impression sur les contr\xF4\
        leurs de domaine et donc charger un pilote malveillant pour par exemple extraire\
        \ les secrets de tous les comptes privil\xE9gi\xE9s.\n\nLes groupes \xAB op\xE9\
        rateurs \xBB sont vides par d\xE9faut et ne devraient contenir aucun membre."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Large privileged group member count (Level 1)
          description: '# Vulnerability description


            The forest contains too many privileged accounts (**?** accounts). The
            threshold is 50 accounts or 3 times the number of domains in the forest.


            A large number of accounts in privileged groups prevents keeping track
            of them: this can lead to poor accountability of privileged users that
            are absolutely necessary, problems with deactivating or deleting an unused
            account, etc.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> accounts are deduplicated by the `sAMAccountName`
            attribute;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> distinct user accounts are considered.


            NB: The analysis excludes the integrated `RID-500` and domain controllers
            accounts from the aforementioned number. Each privileged account is counted
            once, even when it is a member of several privileged groups.'
          annotation: "# Recommended measure\n\nActive Directory Privileged Groups\
            \ grant their member accounts all rights and privileges on the forest.\
            \ Except for the \xAB *Administrators* (Administrateurs) \xBB and \xAB\
            \ *Domain Admins* (Administrateurs du domaine) \xBB groups, use of the\
            \ privileged groups gives a false sense of security.\n\nImplementing an\
            \ administrative model which allows minimizing the number of privileged\
            \ accounts is crucial, especially by establishing well-separated administrative\
            \ roles. In doing so, administrative actions should be inventoried and\
            \ affected to specific accounts through relevant rights delegations. For\
            \ instance, a user management account that needs to be able to create\
            \ and delete user accounts will benefit from the following delegations:\n\
            \n* child object creation;\n* child object deletion;\n* write to object\
            \ attribute;\n* reset password.\n\nThis is usually applied through the\
            \ `ldp` utility.\n\nNote : the Active Directory \"Delegation of Control\"\
            \ Wizard also helps delegating access rights. While of easier use, this\
            \ wizard grants excessive access rights for some delegation categories.\
            \ `ldp` should therfore be preferred.\n\nThe overall model must follow\
            \ the following rules regarding group membership:\n\n* operator groups\
            \ must be empty;\n* replication groups must be empty;\n* forest-level\
            \ administrative groups (enterprise and schema) must be empty and only\
            \ temporarily populated during operations which require those privileges;\n\
            * domain-level administrative groups must not contain any service account.\n\
            \nThe \xAB operators \xBB groups are empty by default and must not have\
            \ any member.\n\n## Context: privileged groups\n\nPrivileged groups include\
            \ administrator groups and operator groups which have full control over\
            \ the Active Directory forest either by design, or by granting themselves\
            \ such privileges:\n\n* \xAB *Administrators* (Administrateurs) \xBB;\n\
            * \xAB *Domain Controllers* (Contr\xF4leurs de domaine) \xBB;\n* \xAB\
            \ *Schema Admins* (Administrateurs du sch\xE9ma) \xBB;\n* \xAB *Enterprise\
            \ Admins* (Administrateurs de l'entreprise) \xBB;\n* \xAB *Domain Admins*\
            \ (Administrateurs du domaine) \xBB: these administrators are able to\
            \ read the authentication database and extract password hashes and other\
            \ secrets of all privileged accounts;\n* \xAB *Key Admins* (Administrateurs\
            \ de cl\xE9s) \xBB and \xAB *Enterprise Key Admins* (Administrateurs de\
            \ cl\xE9s de l'entreprise) \xBB: these administrators can set arbitrary\
            \ values to attributes relating to Windows Hello for Business, for all\
            \ users except those protected by the `adminSDHolder` mechanism. If certificate-based\
            \ authentication has been enabled, they can generate a certificate that\
            \ they control, assign it to privileged accounts (for instance, a domain\
            \ controller), and log on as them;\n* \xAB *Account Operators* (Op\xE9\
            rateurs de compte) \xBB: these operators can manage user accounts, machine\
            \ accounts and groups except accounts protected by the `adminSDHolder`\
            \ mechanism;\n* \xAB *Server Operators* (Op\xE9rateurs de serveur) \xBB\
            : these operators can manage domain controllers, which grants them the\
            \ ability to recover privileged user secrets directly from the authentication\
            \ database;\n* \xAB *Backup Operators* (Op\xE9rateurs de sauvegarde) \xBB\
            : these operators can back up a domain controller, which grants them the\
            \ ability to recover privileged user secrets from that backup;\n* \xAB\
            \ *Print Operators* (Op\xE9rateurs d'impression) \xBB: these operators\
            \ can load arbitrary printer drivers on domain controllers, which grants\
            \ them the ability to recover privileged user secrets directly from the\
            \ authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_privileged_members-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_privileged_members-l2
      name: "Nombre important de membres des groupes privil\xE9gi\xE9s (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa for\xEAt contient\
        \ trop de comptes privil\xE9gi\xE9s (**?** comptes). Le seuil est fix\xE9\
        \ \xE0 50 comptes ou \xE0 3 fois le nombre de domaines de la for\xEAt.\n\n\
        La pr\xE9sence d'un nombre important de comptes privil\xE9gi\xE9s ne permet\
        \ pas d'en assurer le contr\xF4le : cela induit une mauvaise visibilit\xE9\
        \ des comptes privil\xE9gi\xE9s r\xE9ellement n\xE9cessaires, une augmentation\
        \ du risque d'oubli de d\xE9sactivation ou de suppression d'un compte non\
        \ utilis\xE9, etc.\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* Au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> les comptes sont d\xE9dupliqu\xE9\
        s par l'attribut `sAMAccountName`;\n* Au niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> les comptes uniques sont consid\xE9\
        r\xE9s.\n\nNote : les comptes int\xE9gr\xE9s `RID-500` ainsi que les contr\xF4\
        leurs de domaine sont ignor\xE9s pour le d\xE9compte ci-dessus. Chaque compte\
        \ privil\xE9gi\xE9 ne sera compt\xE9 qu'une fois, m\xEAme s'il est membre\
        \ de plusieurs groupes privil\xE9gi\xE9s."
      annotation: "# Recommandation\n\nLes groupes privil\xE9gi\xE9s de l'Active Directory\
        \ permettent aux comptes qui en sont membres de poss\xE9der le plus haut niveau\
        \ de droits et privil\xE8ges la for\xEAt. L'utilisation de ces groupes, \xE0\
        \ l'exception des groupes \xAB *Administrateurs* (Administrators) \xBB et\
        \ \xAB *Administrateurs du domaine* (Domain Admins) \xBB, procure donc un\
        \ faux sentiment de s\xE9curit\xE9.\n\nIl est n\xE9cessaire de mettre en place\
        \ un mod\xE8le d'administration permettant de r\xE9duire le nombre de comptes\
        \ privil\xE9gi\xE9s. Pour cela, il convient de r\xE9f\xE9rencer les besoins\
        \ d'administration de chaque compte et de faire les d\xE9l\xE9gations ad hoc.\
        \ Par exemple, pour un administrateur ayant besoin de cr\xE9er et de supprimer\
        \ des utilisateurs, les d\xE9l\xE9gations n\xE9cessaires seront :\n\n* cr\xE9\
        er un enfant ;\n* supprimer un enfant ;\n* propri\xE9t\xE9 d'\xE9criture ;\n\
        * reset password.\n\nCette d\xE9l\xE9gation est g\xE9n\xE9ralement effectu\xE9\
        e \xE0 l'aide de l'utilitaire `ldp`.\n\nNote : l'\xAB Assistant D\xE9l\xE9\
        gation de contr\xF4le \xBB de l'Active Directory permet \xE9galement de d\xE9\
        l\xE9guer certaines actions d'administration. Bien que plus facile d'utilisation,\
        \ cet assistant positionne trop de privil\xE8ges pour certaines d\xE9l\xE9\
        gations. Il est donc conseill\xE9 de privil\xE9gier l'utilitaire `ldp`.\n\n\
        Enfin, les r\xE8gles d'appartenance suivantes doivent \xEAtre mises en \u0153\
        uvre :\n\n* groupes op\xE9ratifs : tous vides ;\n* groupes r\xE9plicateurs\
        \ : tous vides ;\n* groupes d'administration de niveau for\xEAt (entreprise\
        \ et sch\xE9ma) : vides et peupl\xE9s temporairement uniquement lors d'op\xE9\
        rations n\xE9cessitant ces droits ;\n* groupes d'administration de niveau\
        \ domaine : aucun compte de service.\n\n## Contexte : groupes privil\xE9gi\xE9\
        s\n\nLes groupes privil\xE9gi\xE9s sont les groupes d'administration et les\
        \ groupes op\xE9ratifs ayant tous les droits et privil\xE8ges sur la for\xEA\
        t ou pouvant se les attribuer :\n\n* \xAB *Administrateurs* (Administrators)\
        \ \xBB ;\n* \xAB *Contr\xF4leurs de domaine* (Domain Controllers) \xBB;\n\
        * \xAB *Administrateurs du sch\xE9ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs\
        \ de l'entreprise* (Enterprise Admins) \xBB ;\n* \xAB *Administrateurs du\
        \ domaine* (Domain Admins) \xBB : ces administrateurs ont les privil\xE8ges\
        \ de lire la base des secrets de tous les comptes et donc d'extraire les secrets\
        \ de l'ensemble des comptes privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de\
        \ cl\xE9s* (Key Admins) \xBB et \xAB *Administrateurs de cl\xE9s de l'entreprise*\
        \ (Enterprise Key Admins) \xBB: ces administrateurs peuvent fixer des valeurs\
        \ arbitraires aux attributs relatifs \xE0 Windows Hello for Business, pour\
        \ tous les utilisateurs sauf ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`.\
        \ Si l'authentification bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9\
        e, ils peuvent g\xE9n\xE9rer un certificat sous leur contr\xF4le, l'assigner\
        \ \xE0 un compte privil\xE9gi\xE9 (par exemple, un contr\xF4leur de domaine),\
        \ et s'authentifier en tant que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer tous les comptes\
        \ d'utilisateurs, machines et groupes; \xE0 l'exception des comptes prot\xE9\
        g\xE9s par l' `adminSDHolder`;\n* \xAB *Op\xE9rateurs de serveur* (Server\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer les contr\xF4leurs\
        \ de domaine, et donc r\xE9cup\xE9rer les secrets de tous les comptes privil\xE9\
        gi\xE9s ;\n* \xAB *Op\xE9rateurs de sauvegarde* (Backup Operators) \xBB :\
        \ ces op\xE9rateurs peuvent sauvegarder un contr\xF4leur de domaine et donc\
        \ extraire les secrets de tous les comptes privil\xE9gi\xE9s depuis cette\
        \ sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression* (Print Operators) \xBB\
        \ : ces op\xE9rateurs peuvent charger des pilotes d'impression sur les contr\xF4\
        leurs de domaine et donc charger un pilote malveillant pour par exemple extraire\
        \ les secrets de tous les comptes privil\xE9gi\xE9s.\n\nLes groupes \xAB op\xE9\
        rateurs \xBB sont vides par d\xE9faut et ne devraient contenir aucun membre."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Large privileged group member count (Level 2)
          description: '# Vulnerability description


            The forest contains too many privileged accounts (**?** accounts). The
            threshold is 50 accounts or 3 times the number of domains in the forest.


            A large number of accounts in privileged groups prevents keeping track
            of them: this can lead to poor accountability of privileged users that
            are absolutely necessary, problems with deactivating or deleting an unused
            account, etc.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> accounts are deduplicated by the `sAMAccountName`
            attribute;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> distinct user accounts are considered.


            NB: The analysis excludes the integrated `RID-500` and domain controllers
            accounts from the aforementioned number. Each privileged account is counted
            once, even when it is a member of several privileged groups.'
          annotation: "# Recommended measure\n\nActive Directory Privileged Groups\
            \ grant their member accounts all rights and privileges on the forest.\
            \ Except for the \xAB *Administrators* (Administrateurs) \xBB and \xAB\
            \ *Domain Admins* (Administrateurs du domaine) \xBB groups, use of the\
            \ privileged groups gives a false sense of security.\n\nImplementing an\
            \ administrative model which allows minimizing the number of privileged\
            \ accounts is crucial, especially by establishing well-separated administrative\
            \ roles. In doing so, administrative actions should be inventoried and\
            \ affected to specific accounts through relevant rights delegations. For\
            \ instance, a user management account that needs to be able to create\
            \ and delete user accounts will benefit from the following delegations:\n\
            \n* child object creation;\n* child object deletion;\n* write to object\
            \ attribute;\n* reset password.\n\nThis is usually applied through the\
            \ `ldp` utility.\n\nNote : the Active Directory \"Delegation of Control\"\
            \ Wizard also helps delegating access rights. While of easier use, this\
            \ wizard grants excessive access rights for some delegation categories.\
            \ `ldp` should therfore be preferred.\n\nThe overall model must follow\
            \ the following rules regarding group membership:\n\n* operator groups\
            \ must be empty;\n* replication groups must be empty;\n* forest-level\
            \ administrative groups (enterprise and schema) must be empty and only\
            \ temporarily populated during operations which require those privileges;\n\
            * domain-level administrative groups must not contain any service account.\n\
            \nThe \xAB operators \xBB groups are empty by default and must not have\
            \ any member.\n\n## Context: privileged groups\n\nPrivileged groups include\
            \ administrator groups and operator groups which have full control over\
            \ the Active Directory forest either by design, or by granting themselves\
            \ such privileges:\n\n* \xAB *Administrators* (Administrateurs) \xBB;\n\
            * \xAB *Domain Controllers* (Contr\xF4leurs de domaine) \xBB;\n* \xAB\
            \ *Schema Admins* (Administrateurs du sch\xE9ma) \xBB;\n* \xAB *Enterprise\
            \ Admins* (Administrateurs de l'entreprise) \xBB;\n* \xAB *Domain Admins*\
            \ (Administrateurs du domaine) \xBB: these administrators are able to\
            \ read the authentication database and extract password hashes and other\
            \ secrets of all privileged accounts;\n* \xAB *Key Admins* (Administrateurs\
            \ de cl\xE9s) \xBB and \xAB *Enterprise Key Admins* (Administrateurs de\
            \ cl\xE9s de l'entreprise) \xBB: these administrators can set arbitrary\
            \ values to attributes relating to Windows Hello for Business, for all\
            \ users except those protected by the `adminSDHolder` mechanism. If certificate-based\
            \ authentication has been enabled, they can generate a certificate that\
            \ they control, assign it to privileged accounts (for instance, a domain\
            \ controller), and log on as them;\n* \xAB *Account Operators* (Op\xE9\
            rateurs de compte) \xBB: these operators can manage user accounts, machine\
            \ accounts and groups except accounts protected by the `adminSDHolder`\
            \ mechanism;\n* \xAB *Server Operators* (Op\xE9rateurs de serveur) \xBB\
            : these operators can manage domain controllers, which grants them the\
            \ ability to recover privileged user secrets directly from the authentication\
            \ database;\n* \xAB *Backup Operators* (Op\xE9rateurs de sauvegarde) \xBB\
            : these operators can back up a domain controller, which grants them the\
            \ ability to recover privileged user secrets from that backup;\n* \xAB\
            \ *Print Operators* (Op\xE9rateurs d'impression) \xBB: these operators\
            \ can load arbitrary printer drivers on domain controllers, which grants\
            \ them the ability to recover privileged user secrets directly from the\
            \ authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_privileged_members_perm-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_privileged_members_perm-l1
      name: "Permissions dangereuses sur des membres de groupes privil\xE9gi\xE9s\
        \ (chemins de contr\xF4le) (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur des membres de groupes privil\xE9gi\xE9s. Ces chemins de contr\xF4\
        le correspondent \xE0 des droits ou privil\xE8ges permettant \xE0 des utilisateurs\
        \ non privil\xE9gi\xE9s de prendre le contr\xF4le de comptes privil\xE9gi\xE9\
        s.\n\nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4\
        le indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nLa plupart des permissions dangereuses cit\xE9\
        es dans cette vuln\xE9rabilit\xE9 sont \xE9galement li\xE9es aux vuln\xE9\
        rabilit\xE9s \xAB Permissions dangereuses sur l'objet adminSDHolder \xBB et\
        \ \xAB Permissions dangereuses sur les objets des contr\xF4leurs de domaine\
        \ \xBB. L'application des recommandations associ\xE9es \xE0 ces vuln\xE9rabilit\xE9\
        s corrigera une majorit\xE9 de ces chemins.\n\nPour les permissions restantes,\
        \ il est recommand\xE9 d'enlever les entr\xE9es dangereuses. La correction\
        \ est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide du composant logiciel enfichable\
        \ `ADSI Edit` ou de l'utilitaire `ldp`.\n\n## Contexte : chemins de contr\xF4\
        le\n\nUn chemin de contr\xF4le est compos\xE9 d'un ensemble de relations de\
        \ contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet\
        \ sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les\
        \ chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre\
        \ des cibles, et permettent d'identifier des d\xE9viances dans la gestion\
        \ du domaine, de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9\
        \ autour des cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler\
        \ des moyens de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Cas particulier de\
        \ Microsoft Exchange Server\n\nCertains chemins de contr\xF4le qui apparaissent\
        \ peuvent \xEAtre li\xE9s \xE0 des groupes Exchange b\xE9n\xE9ficiant de permissions\
        \ dangereuses. Deux cas particuliers peuvent se pr\xE9senter :\n\n1. s'il\
        \ s'agit de groupes datant d'une ancienne installation de Exchange Server\
        \ 2007 ou ant\xE9rieure (\"Exchange Enterprise Servers\", \"Exchange Domain\
        \ Servers\" ou \"Exchange Services\") et que cette infrastructure a \xE9t\xE9\
        \ migr\xE9e vers une version 2010 ou ult\xE9rieure, il est recommand\xE9 de\
        \ supprimer ces groupes et les permissions associ\xE9es. [Microsoft fournit\
        \ une proc\xE9dure \xE0 cette fin](https://learn.microsoft.com/fr-fr/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
        2. sinon pour les autres groupes, il convient de v\xE9rifier les contr\xF4\
        les dangereux concern\xE9s pour d\xE9terminer la correction ad\xE9quate (voir\
        \ plus bas).\n\nLes contr\xF4les suivants, uniquement s'ils sont mentionn\xE9\
        s pour un groupe li\xE9 \xE0 Exchange, ont fait l'objet d'un correctif de\
        \ Microsoft :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nAttention\
        \ : certaines des propri\xE9t\xE9s LDAP concern\xE9es par ces \xE9critures\
        \ (`servicePrincipalName` et `altSecurityIdentities`) font partie du property-set\
        \ `Public-Information`. Ainsi, les permissions d'\xE9critures peuvent \xEA\
        tre attribu\xE9es pour chaque attribut unitairement ou le property-set entier,\
        \ auquel cas seul ce dernier sera visible dans la DACL de l'objet concern\xE9\
        .\n\nPour appliquer ce correctif, il est n\xE9cessaire d'effectuer les actions\
        \ suivantes :\n\n* pour Exchange Server 2019 : installer le SU de mai 2022\
        \ sur le CU12 ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2016 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2013 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014260](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
        \ ;\n* pour toutes les versions, apr\xE8s installation des correctifs pr\xE9\
        c\xE9dents : ex\xE9cuter la phase de pr\xE9paration des domaines \"/PrepareAllDomains\"\
        \n  * pour Exchange Server 2019 et 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
        \ /PrepareAllDomains` ou `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
        \ /PrepareAllDomains` depuis le r\xE9pertoire d'installation de Exchange ;\n\
        \  * pour Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
        \ /PrepareAllDomains`;\n  * il est rappel\xE9 que Exchange Server 2010 n'est\
        \ plus support\xE9 par l'\xE9diteur.\n\nPour tout autre chemin de contr\xF4\
        le, une qualification manuelle doit \xEAtre effectu\xE9e pour caract\xE9riser\
        \ le probl\xE8me.\n\n\xC0 titre d'information, la liste des derniers correctifs\
        \ publi\xE9s pour Exchange Server est [disponible ici](https://learn.microsoft.com/fr-fr/exchange/new-features/build-numbers-and-release-dates).\n\
        \n## Contexte : groupes privil\xE9gi\xE9s\n\nLes groupes privil\xE9gi\xE9\
        s sont les groupes d'administration et les groupes op\xE9ratifs ayant tous\
        \ les droits et privil\xE8ges sur la for\xEAt ou pouvant se les attribuer\
        \ :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n* \xAB *Contr\xF4\
        leurs de domaine* (Domain Controllers) \xBB;\n* \xAB *Administrateurs du sch\xE9\
        ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs de l'entreprise* (Enterprise\
        \ Admins) \xBB ;\n* \xAB *Administrateurs du domaine* (Domain Admins) \xBB\
        \ : ces administrateurs ont les privil\xE8ges de lire la base des secrets\
        \ de tous les comptes et donc d'extraire les secrets de l'ensemble des comptes\
        \ privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de cl\xE9s* (Key Admins) \xBB\
        \ et \xAB *Administrateurs de cl\xE9s de l'entreprise* (Enterprise Key Admins)\
        \ \xBB: ces administrateurs peuvent fixer des valeurs arbitraires aux attributs\
        \ relatifs \xE0 Windows Hello for Business, pour tous les utilisateurs sauf\
        \ ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`. Si l'authentification\
        \ bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9e, ils peuvent g\xE9n\xE9\
        rer un certificat sous leur contr\xF4le, l'assigner \xE0 un compte privil\xE9\
        gi\xE9 (par exemple, un contr\xF4leur de domaine), et s'authentifier en tant\
        \ que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account Operators) \xBB : ces\
        \ op\xE9rateurs peuvent administrer tous les comptes d'utilisateurs, machines\
        \ et groupes; \xE0 l'exception des comptes prot\xE9g\xE9s par l' `adminSDHolder`;\n\
        * \xAB *Op\xE9rateurs de serveur* (Server Operators) \xBB : ces op\xE9rateurs\
        \ peuvent administrer les contr\xF4leurs de domaine, et donc r\xE9cup\xE9\
        rer les secrets de tous les comptes privil\xE9gi\xE9s ;\n* \xAB *Op\xE9rateurs\
        \ de sauvegarde* (Backup Operators) \xBB : ces op\xE9rateurs peuvent sauvegarder\
        \ un contr\xF4leur de domaine et donc extraire les secrets de tous les comptes\
        \ privil\xE9gi\xE9s depuis cette sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression*\
        \ (Print Operators) \xBB : ces op\xE9rateurs peuvent charger des pilotes d'impression\
        \ sur les contr\xF4leurs de domaine et donc charger un pilote malveillant\
        \ pour par exemple extraire les secrets de tous les comptes privil\xE9gi\xE9\
        s.\n\nLes groupes \xAB op\xE9rateurs \xBB sont vides par d\xE9faut et ne devraient\
        \ contenir aucun membre.\n\n## Acceptation du risque\n\nSi des permissions\
        \ sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9rer que les\
        \ comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9gi\xE9\
        s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dangerous ACLs expose members of privileged groups (attack path) (Level
            1)
          description: '# Vulnerability description


            Dangerous ACLs expose members of privileged groups. These access rights
            grant non-privileged users the ability to take control of privileged accounts.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: "# Recommended measure\n\nMost of the items shown here are due\
            \ to the \" `Dangerous permissions on the adminSDHolder object` \" and\
            \ \" `Dangerous ACLs expose domain controller objects` \" checks. Fixing\
            \ it will take care of most of these items.\n\nFor all remaining permissions,\
            \ relevant dangerous entries should be removed. The fix is usually applied\
            \ through the `adsiedit.msc` or `ldp` utilities.\n\nThe \xAB operators\
            \ \xBB groups are empty by default and must not have any member.\n\n##\
            \ Context: control path exposure\n\nA control path materializes through\
            \ a set of granted access permissions: each granted permission can be\
            \ expressed as one object controlling another through a specific property,\
            \ attribute or setting. Control paths reveal how an attacker could leverage\
            \ a chain of defective or dangerous permissions to gain control of some\
            \ targets. They can also be leveraged to quickly identify domain mismanagement,\
            \ to validate the actual security boundary of a particular scope (making\
            \ sure some object of interest cannot be taken over by unauthorized users\
            \ through misconfiguration). Indicators of compromise may also be found\
            \ through control path review.\n\n## Limitations\n\nSome control paths\
            \ may have fixes that renders them non-exploitable. Such a case usually\
            \ requires having all domain controllers equally up to date. Furthermore,\
            \ dangerous features may sometimes be re-enabled through a registry or\
            \ dsHeuristics setting. It is therefore still recommended to clean the\
            \ affected permissions from your Active Directory to prevent an accidental\
            \ re-occurrence.\n\nList of known specific fixes:\n\n* [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
            \ fixes the <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">OWNER</span> and <span style=\"background-color:rgb(255, 165,\
            \ 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> control path on computer\
            \ accounts only, but the dangerous behavior can still be re-enabled.\n\
            * Various Exchange-related control paths have been fixed through specific\
            \ cumulative updates; refer to the dedicated section below if applicable.\n\
            \n## Microsoft Exchange Server Specifics\n\nSome control paths under this\
            \ item may appear because of Exchange Server management groups with excessive\
            \ permissions. The cause can be:\n\n1. either the offending groups come\
            \ from a legacy Exchange Server 2007 or earlier instance (\"Exchange Enterprise\
            \ Servers\", \"Exchange Domain Servers\" ou \"Exchange Services\") which\
            \ has been migrated to version 2010 or later, it is then best to remove\
            \ those groups and associated permissions. [Microsoft provides relevant\
            \ guidance to fix these issues](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
            2. or these are current Exchange Server management groups, a specific\
            \ analysis will help select the applicable solution (see below).\n\nThe\
            \ following controls have been fixed by Microsoft, only if pertaining\
            \ to Exchange Server groups:\n\n* <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>\n* <span style=\"\
            background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n\
            * <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
            \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nWarning:\
            \ some LDAP attributes (`servicePrincipalName` and `altSecurityIdentities`)\
            \ behind these controls belong to the `Public-Information` property set.\
            \ Therefore, these write permissions may be granted on an attribute basis\
            \ or to the whole property set, in which case only this property set will\
            \ be visible in the object's DACL.\n\nApplying the official fix involves\
            \ the following steps:\n\n* Exchange Server 2019 : install may 2022 SU\
            \ on CU12 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2016 : install may 2022 SU on CU23 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2013 : install may 2022 SU on CU23 ([KB5014260](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
            \ ;\n* for all version, after applying the above security updates: run\
            \ the \"/PrepareAllDomains\" setup phase\n  * on Exchange Server 2019\
            \ and 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
            \ /PrepareAllDomains` or `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * on Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * Please note Exchange Server 2010 is not supported anymore by Microsoft.\n\
            \nAny other control path shall be manually investigated to properly address\
            \ the issue.\n\nA list of published Exchange Server security updates is\
            \ [available here](https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates).\n\
            \n## Context: privileged groups\n\nPrivileged groups include administrator\
            \ groups and operator groups which have full control over the Active Directory\
            \ forest either by design, or by granting themselves such privileges:\n\
            \n* \xAB *Administrators* (Administrateurs) \xBB;\n* \xAB *Domain Controllers*\
            \ (Contr\xF4leurs de domaine) \xBB;\n* \xAB *Schema Admins* (Administrateurs\
            \ du sch\xE9ma) \xBB;\n* \xAB *Enterprise Admins* (Administrateurs de\
            \ l'entreprise) \xBB;\n* \xAB *Domain Admins* (Administrateurs du domaine)\
            \ \xBB: these administrators are able to read the authentication database\
            \ and extract password hashes and other secrets of all privileged accounts;\n\
            * \xAB *Key Admins* (Administrateurs de cl\xE9s) \xBB and \xAB *Enterprise\
            \ Key Admins* (Administrateurs de cl\xE9s de l'entreprise) \xBB: these\
            \ administrators can set arbitrary values to attributes relating to Windows\
            \ Hello for Business, for all users except those protected by the `adminSDHolder`\
            \ mechanism. If certificate-based authentication has been enabled, they\
            \ can generate a certificate that they control, assign it to privileged\
            \ accounts (for instance, a domain controller), and log on as them;\n\
            * \xAB *Account Operators* (Op\xE9rateurs de compte) \xBB: these operators\
            \ can manage user accounts, machine accounts and groups except accounts\
            \ protected by the `adminSDHolder` mechanism;\n* \xAB *Server Operators*\
            \ (Op\xE9rateurs de serveur) \xBB: these operators can manage domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database;\n* \xAB *Backup Operators* (Op\xE9\
            rateurs de sauvegarde) \xBB: these operators can back up a domain controller,\
            \ which grants them the ability to recover privileged user secrets from\
            \ that backup;\n* \xAB *Print Operators* (Op\xE9rateurs d'impression)\
            \ \xBB: these operators can load arbitrary printer drivers on domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database (by loading a malicious driver).\n\n\
            ## Risk Acceptance\n\nIf special permissions are required, delegated groups\
            \ or accounts should be considered as privileged. Therefore, they must\
            \ comply with appropriate protection measures, and their own access control\
            \ list should be at least as strict as that of the `adminSDHolder` object.\
            \ \"Secure\" ACLs should therefore be implemented on these delegated groups,\
            \ which will not open a new control path exposure. To remove inheritance\
            \ and restrict ACEs, the following command may be used: ``Set-ADSyncRestrictedPermissions``\
            \ found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated\
            \ groups, strengthening permissions using this command is not enough:\
            \ the permissions of this group's members must also be strengthened by\
            \ applying this command to them, or they can be removed from the delegated\
            \ group.\n\nExample: applying \"secure\" permission on a privileged account\
            \ through ``Set-ADSyncRestrictedPermissions``:\n\n```powershell\nImport-Module\
            \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
            \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
            \ -Credential $credential\n```\n\nNote: the `AdSyncConfig.psm1` module\
            \ may be extracted from the Azure AD Connect installer with `msiexec`:\
            \ `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\temp\\`\n\nThe\
            \ installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_privileged_members_perm-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_privileged_members_perm-l2
      name: "Permissions dangereuses sur des membres de groupes privil\xE9gi\xE9s\
        \ (chemins de contr\xF4le) (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur des membres de groupes privil\xE9gi\xE9s. Ces chemins de contr\xF4\
        le correspondent \xE0 des droits ou privil\xE8ges permettant \xE0 des utilisateurs\
        \ non privil\xE9gi\xE9s de prendre le contr\xF4le de comptes privil\xE9gi\xE9\
        s.\n\nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect, Contr\xF4\
        le indirect faible\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le\
        \ pr\xE9sente des seuils de tol\xE9rance diff\xE9rents en fonction du niveau\
        \ de s\xE9curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">1</span> seules les permissions pouvant\
        \ \xEAtre exploit\xE9es par un attaquant, sans pr\xE9requis majeur, sont prises\
        \ en compte ;\n* au niveau <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
        \ 0, 0)\">2</span> l'ensemble des permissions potentiellement dangereuses\
        \ sont prises en compte.\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nLa plupart des permissions dangereuses cit\xE9\
        es dans cette vuln\xE9rabilit\xE9 sont \xE9galement li\xE9es aux vuln\xE9\
        rabilit\xE9s \xAB Permissions dangereuses sur l'objet adminSDHolder \xBB et\
        \ \xAB Permissions dangereuses sur les objets des contr\xF4leurs de domaine\
        \ \xBB. L'application des recommandations associ\xE9es \xE0 ces vuln\xE9rabilit\xE9\
        s corrigera une majorit\xE9 de ces chemins.\n\nPour les permissions restantes,\
        \ il est recommand\xE9 d'enlever les entr\xE9es dangereuses. La correction\
        \ est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide du composant logiciel enfichable\
        \ `ADSI Edit` ou de l'utilitaire `ldp`.\n\n## Contexte : chemins de contr\xF4\
        le\n\nUn chemin de contr\xF4le est compos\xE9 d'un ensemble de relations de\
        \ contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un objet\
        \ sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re. Ainsi, les\
        \ chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant d'atteindre\
        \ des cibles, et permettent d'identifier des d\xE9viances dans la gestion\
        \ du domaine, de valider l'application d'un p\xE9rim\xE8tre de s\xE9curit\xE9\
        \ autour des cibles consid\xE9r\xE9es, mais \xE9galement de r\xE9v\xE9ler\
        \ des moyens de persistance laiss\xE9s par un attaquant apr\xE8s une compromission.\n\
        \n## Limites\n\nCertains chemins de contr\xF4le peuvent disposer de correctifs\
        \ qui les rendent non exploitables. Ces cas imposent g\xE9n\xE9ralement d'avoir\
        \ l'ensemble des contr\xF4leurs de domaine au m\xEAme niveau de mise \xE0\
        \ jour. De plus, les fonctionnalit\xE9s dangereuses peuvent parfois \xEAtre\
        \ r\xE9activ\xE9es par un param\xE8tre de registre ou dsHeuristics. Il est\
        \ donc toujours recommand\xE9 de nettoyer les permissions concern\xE9es de\
        \ l'Active Directory pour pr\xE9venir une r\xE9apparition du probl\xE8me.\n\
        \nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Cas particulier de\
        \ Microsoft Exchange Server\n\nCertains chemins de contr\xF4le qui apparaissent\
        \ peuvent \xEAtre li\xE9s \xE0 des groupes Exchange b\xE9n\xE9ficiant de permissions\
        \ dangereuses. Deux cas particuliers peuvent se pr\xE9senter :\n\n1. s'il\
        \ s'agit de groupes datant d'une ancienne installation de Exchange Server\
        \ 2007 ou ant\xE9rieure (\"Exchange Enterprise Servers\", \"Exchange Domain\
        \ Servers\" ou \"Exchange Services\") et que cette infrastructure a \xE9t\xE9\
        \ migr\xE9e vers une version 2010 ou ult\xE9rieure, il est recommand\xE9 de\
        \ supprimer ces groupes et les permissions associ\xE9es. [Microsoft fournit\
        \ une proc\xE9dure \xE0 cette fin](https://learn.microsoft.com/fr-fr/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
        2. sinon pour les autres groupes, il convient de v\xE9rifier les contr\xF4\
        les dangereux concern\xE9s pour d\xE9terminer la correction ad\xE9quate (voir\
        \ plus bas).\n\nLes contr\xF4les suivants, uniquement s'ils sont mentionn\xE9\
        s pour un groupe li\xE9 \xE0 Exchange, ont fait l'objet d'un correctif de\
        \ Microsoft :\n\n* <span style=\"background-color:rgb(220, 53, 69);color:rgb(255,\
        \ 255, 255)\">WRITE_SPN</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nAttention\
        \ : certaines des propri\xE9t\xE9s LDAP concern\xE9es par ces \xE9critures\
        \ (`servicePrincipalName` et `altSecurityIdentities`) font partie du property-set\
        \ `Public-Information`. Ainsi, les permissions d'\xE9critures peuvent \xEA\
        tre attribu\xE9es pour chaque attribut unitairement ou le property-set entier,\
        \ auquel cas seul ce dernier sera visible dans la DACL de l'objet concern\xE9\
        .\n\nPour appliquer ce correctif, il est n\xE9cessaire d'effectuer les actions\
        \ suivantes :\n\n* pour Exchange Server 2019 : installer le SU de mai 2022\
        \ sur le CU12 ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2016 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014261](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
        \ ;\n* pour Exchange Server 2013 : installer le SU de mai 2022 sur le CU23\
        \ ([KB5014260](https://support.microsoft.com/fr-fr/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
        \ ;\n* pour toutes les versions, apr\xE8s installation des correctifs pr\xE9\
        c\xE9dents : ex\xE9cuter la phase de pr\xE9paration des domaines \"/PrepareAllDomains\"\
        \n  * pour Exchange Server 2019 et 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
        \ /PrepareAllDomains` ou `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
        \ /PrepareAllDomains` depuis le r\xE9pertoire d'installation de Exchange ;\n\
        \  * pour Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
        \ /PrepareAllDomains`;\n  * il est rappel\xE9 que Exchange Server 2010 n'est\
        \ plus support\xE9 par l'\xE9diteur.\n\nPour tout autre chemin de contr\xF4\
        le, une qualification manuelle doit \xEAtre effectu\xE9e pour caract\xE9riser\
        \ le probl\xE8me.\n\n\xC0 titre d'information, la liste des derniers correctifs\
        \ publi\xE9s pour Exchange Server est [disponible ici](https://learn.microsoft.com/fr-fr/exchange/new-features/build-numbers-and-release-dates).\n\
        \n## Contexte : groupes privil\xE9gi\xE9s\n\nLes groupes privil\xE9gi\xE9\
        s sont les groupes d'administration et les groupes op\xE9ratifs ayant tous\
        \ les droits et privil\xE8ges sur la for\xEAt ou pouvant se les attribuer\
        \ :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n* \xAB *Contr\xF4\
        leurs de domaine* (Domain Controllers) \xBB;\n* \xAB *Administrateurs du sch\xE9\
        ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs de l'entreprise* (Enterprise\
        \ Admins) \xBB ;\n* \xAB *Administrateurs du domaine* (Domain Admins) \xBB\
        \ : ces administrateurs ont les privil\xE8ges de lire la base des secrets\
        \ de tous les comptes et donc d'extraire les secrets de l'ensemble des comptes\
        \ privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de cl\xE9s* (Key Admins) \xBB\
        \ et \xAB *Administrateurs de cl\xE9s de l'entreprise* (Enterprise Key Admins)\
        \ \xBB: ces administrateurs peuvent fixer des valeurs arbitraires aux attributs\
        \ relatifs \xE0 Windows Hello for Business, pour tous les utilisateurs sauf\
        \ ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`. Si l'authentification\
        \ bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9e, ils peuvent g\xE9n\xE9\
        rer un certificat sous leur contr\xF4le, l'assigner \xE0 un compte privil\xE9\
        gi\xE9 (par exemple, un contr\xF4leur de domaine), et s'authentifier en tant\
        \ que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account Operators) \xBB : ces\
        \ op\xE9rateurs peuvent administrer tous les comptes d'utilisateurs, machines\
        \ et groupes; \xE0 l'exception des comptes prot\xE9g\xE9s par l' `adminSDHolder`;\n\
        * \xAB *Op\xE9rateurs de serveur* (Server Operators) \xBB : ces op\xE9rateurs\
        \ peuvent administrer les contr\xF4leurs de domaine, et donc r\xE9cup\xE9\
        rer les secrets de tous les comptes privil\xE9gi\xE9s ;\n* \xAB *Op\xE9rateurs\
        \ de sauvegarde* (Backup Operators) \xBB : ces op\xE9rateurs peuvent sauvegarder\
        \ un contr\xF4leur de domaine et donc extraire les secrets de tous les comptes\
        \ privil\xE9gi\xE9s depuis cette sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression*\
        \ (Print Operators) \xBB : ces op\xE9rateurs peuvent charger des pilotes d'impression\
        \ sur les contr\xF4leurs de domaine et donc charger un pilote malveillant\
        \ pour par exemple extraire les secrets de tous les comptes privil\xE9gi\xE9\
        s.\n\nLes groupes \xAB op\xE9rateurs \xBB sont vides par d\xE9faut et ne devraient\
        \ contenir aucun membre.\n\n## Acceptation du risque\n\nSi des permissions\
        \ sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9rer que les\
        \ comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9gi\xE9\
        s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous ACLs expose members of privileged groups (attack path) (Level
            2)
          description: '# Vulnerability description


            Dangerous ACLs expose members of privileged groups. These access rights
            grant non-privileged users the ability to take control of privileged accounts.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * at level <span style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">1</span> only dangerous access control entries that can be
            exploited without any major prerequisite are taken into account;

            * at level <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">2</span> all potentially dangerous access control entries are taken
            into account.


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: "# Recommended measure\n\nMost of the items shown here are due\
            \ to the \" `Dangerous permissions on the adminSDHolder object` \" and\
            \ \" `Dangerous ACLs expose domain controller objects` \" checks. Fixing\
            \ it will take care of most of these items.\n\nFor all remaining permissions,\
            \ relevant dangerous entries should be removed. The fix is usually applied\
            \ through the `adsiedit.msc` or `ldp` utilities.\n\nThe \xAB operators\
            \ \xBB groups are empty by default and must not have any member.\n\n##\
            \ Context: control path exposure\n\nA control path materializes through\
            \ a set of granted access permissions: each granted permission can be\
            \ expressed as one object controlling another through a specific property,\
            \ attribute or setting. Control paths reveal how an attacker could leverage\
            \ a chain of defective or dangerous permissions to gain control of some\
            \ targets. They can also be leveraged to quickly identify domain mismanagement,\
            \ to validate the actual security boundary of a particular scope (making\
            \ sure some object of interest cannot be taken over by unauthorized users\
            \ through misconfiguration). Indicators of compromise may also be found\
            \ through control path review.\n\n## Limitations\n\nSome control paths\
            \ may have fixes that renders them non-exploitable. Such a case usually\
            \ requires having all domain controllers equally up to date. Furthermore,\
            \ dangerous features may sometimes be re-enabled through a registry or\
            \ dsHeuristics setting. It is therefore still recommended to clean the\
            \ affected permissions from your Active Directory to prevent an accidental\
            \ re-occurrence.\n\nList of known specific fixes:\n\n* [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
            \ fixes the <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">OWNER</span> and <span style=\"background-color:rgb(255, 165,\
            \ 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> control path on computer\
            \ accounts only, but the dangerous behavior can still be re-enabled.\n\
            * Various Exchange-related control paths have been fixed through specific\
            \ cumulative updates; refer to the dedicated section below if applicable.\n\
            \n## Microsoft Exchange Server Specifics\n\nSome control paths under this\
            \ item may appear because of Exchange Server management groups with excessive\
            \ permissions. The cause can be:\n\n1. either the offending groups come\
            \ from a legacy Exchange Server 2007 or earlier instance (\"Exchange Enterprise\
            \ Servers\", \"Exchange Domain Servers\" ou \"Exchange Services\") which\
            \ has been migrated to version 2010 or later, it is then best to remove\
            \ those groups and associated permissions. [Microsoft provides relevant\
            \ guidance to fix these issues](https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb288905(v=exchg.80)?redirectedfrom=MSDN);\n\
            2. or these are current Exchange Server management groups, a specific\
            \ analysis will help select the applicable solution (see below).\n\nThe\
            \ following controls have been fixed by Microsoft, only if pertaining\
            \ to Exchange Server groups:\n\n* <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">WRITE_SPN</span>\n* <span style=\"\
            background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">WRITE_DAC</span>\n\
            * <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >WRITE_OWNER</span>\n* <span style=\"background-color:rgb(255, 165, 0);color:rgb(0,\
            \ 0, 0)\">WRITE_MANAGED_BY</span>\n* <span style=\"background-color:rgb(0,\
            \ 123, 255);color:rgb(255, 255, 255)\">WRITE_ALT_IDENTITY</span>\n\nWarning:\
            \ some LDAP attributes (`servicePrincipalName` and `altSecurityIdentities`)\
            \ behind these controls belong to the `Public-Information` property set.\
            \ Therefore, these write permissions may be granted on an attribute basis\
            \ or to the whole property set, in which case only this property set will\
            \ be visible in the object's DACL.\n\nApplying the official fix involves\
            \ the following steps:\n\n* Exchange Server 2019 : install may 2022 SU\
            \ on CU12 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2016 : install may 2022 SU on CU23 ([KB5014261](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2016-and-2019-may-10-2022-kb5014261-cd5ecb59-a0eb-47ef-ae35-f62b13c8b817))\
            \ ;\n* Exchange Server 2013 : install may 2022 SU on CU23 ([KB5014260](https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-may-10-2022-kb5014260-701fda2b-7417-4ffa-979b-0b2bc8e93b1c))\
            \ ;\n* for all version, after applying the above security updates: run\
            \ the \"/PrepareAllDomains\" setup phase\n  * on Exchange Server 2019\
            \ and 2016 : `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON\
            \ /PrepareAllDomains` or `Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * on Exchange Server 2013 : `Setup.exe /IAcceptExchangeServerLicenseTerms\
            \ /PrepareAllDomains` from your Exchange Server installation path;\n \
            \ * Please note Exchange Server 2010 is not supported anymore by Microsoft.\n\
            \nAny other control path shall be manually investigated to properly address\
            \ the issue.\n\nA list of published Exchange Server security updates is\
            \ [available here](https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates).\n\
            \n## Context: privileged groups\n\nPrivileged groups include administrator\
            \ groups and operator groups which have full control over the Active Directory\
            \ forest either by design, or by granting themselves such privileges:\n\
            \n* \xAB *Administrators* (Administrateurs) \xBB;\n* \xAB *Domain Controllers*\
            \ (Contr\xF4leurs de domaine) \xBB;\n* \xAB *Schema Admins* (Administrateurs\
            \ du sch\xE9ma) \xBB;\n* \xAB *Enterprise Admins* (Administrateurs de\
            \ l'entreprise) \xBB;\n* \xAB *Domain Admins* (Administrateurs du domaine)\
            \ \xBB: these administrators are able to read the authentication database\
            \ and extract password hashes and other secrets of all privileged accounts;\n\
            * \xAB *Key Admins* (Administrateurs de cl\xE9s) \xBB and \xAB *Enterprise\
            \ Key Admins* (Administrateurs de cl\xE9s de l'entreprise) \xBB: these\
            \ administrators can set arbitrary values to attributes relating to Windows\
            \ Hello for Business, for all users except those protected by the `adminSDHolder`\
            \ mechanism. If certificate-based authentication has been enabled, they\
            \ can generate a certificate that they control, assign it to privileged\
            \ accounts (for instance, a domain controller), and log on as them;\n\
            * \xAB *Account Operators* (Op\xE9rateurs de compte) \xBB: these operators\
            \ can manage user accounts, machine accounts and groups except accounts\
            \ protected by the `adminSDHolder` mechanism;\n* \xAB *Server Operators*\
            \ (Op\xE9rateurs de serveur) \xBB: these operators can manage domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database;\n* \xAB *Backup Operators* (Op\xE9\
            rateurs de sauvegarde) \xBB: these operators can back up a domain controller,\
            \ which grants them the ability to recover privileged user secrets from\
            \ that backup;\n* \xAB *Print Operators* (Op\xE9rateurs d'impression)\
            \ \xBB: these operators can load arbitrary printer drivers on domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database (by loading a malicious driver).\n\n\
            ## Risk Acceptance\n\nIf special permissions are required, delegated groups\
            \ or accounts should be considered as privileged. Therefore, they must\
            \ comply with appropriate protection measures, and their own access control\
            \ list should be at least as strict as that of the `adminSDHolder` object.\
            \ \"Secure\" ACLs should therefore be implemented on these delegated groups,\
            \ which will not open a new control path exposure. To remove inheritance\
            \ and restrict ACEs, the following command may be used: ``Set-ADSyncRestrictedPermissions``\
            \ found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated\
            \ groups, strengthening permissions using this command is not enough:\
            \ the permissions of this group's members must also be strengthened by\
            \ applying this command to them, or they can be removed from the delegated\
            \ group.\n\nExample: applying \"secure\" permission on a privileged account\
            \ through ``Set-ADSyncRestrictedPermissions``:\n\n```powershell\nImport-Module\
            \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
            \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
            \ -Credential $credential\n```\n\nNote: the `AdSyncConfig.psm1` module\
            \ may be extracted from the Azure AD Connect installer with `msiexec`:\
            \ `msiexec /a \"AzureADConnect.msi\" /qb TARGETDIR=c:\\temp\\`\n\nThe\
            \ installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_spn_priv-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_spn_priv-l1
      name: "Comptes privil\xE9gi\xE9s avec SPN (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nL'attribut `servicePrincipalName`\
        \ (SPN) est positionn\xE9 pour plusieurs comptes privil\xE9gi\xE9s.\n\nIl\
        \ est possible de lancer une attaque afin de retrouver le mot de passe de\
        \ l'utilisateur, ce qui peut \xEAtre facilit\xE9 si celui-ci n'est pas assez\
        \ robuste."
      annotation: "# Recommandation\n\nLe SPN permet d'associer des noms de service\
        \ Kerberos \xE0 des comptes. Lorsqu'un compte poss\xE8de un nom de service\
        \ Kerberos, n'importe quel utilisateur authentifi\xE9 peut demander un ticket\
        \ pour ce service. Dans ce cas, le ticket \xE9mis est chiffr\xE9 avec une\
        \ des cl\xE9s Kerberos associ\xE9es au compte correspondant, ce qui permet\
        \ de faire une attaque par brute force. Par d\xE9faut seuls les comptes machine\
        \ poss\xE8dent des SPN, cet attribut doit toujours \xEAtre vide pour les comptes\
        \ privil\xE9gi\xE9s du domaine.\n\n## Cas g\xE9n\xE9ral: supprimer le SPN\n\
        \nSi les comptes ayant un SPN ont r\xE9ellement besoin d'\xEAtre privil\xE9\
        gi\xE9s, il convient de supprimer leur attribut `servicePrincipalName` et\
        \ de changer leur mot de passe.\n\nNote : il est tol\xE9r\xE9 qu'un compte\
        \ privil\xE9gi\xE9 poss\xE8de un SPN aux conditions suivantes :\n\n* le compte\
        \ est un Managed Service Account (`sMSA` / `gMSA`) ;\n* **OU** une politique\
        \ de mot de passe affin\xE9e (Password Settings Object ou PSO) s'applique\
        \ sur le compte avec une longueur de mot de passe sup\xE9rieure \xE0 **32**;\
        \ une politique de mot de passe affin\xE9e (Password Settings Object ou PSO)\
        \ s'applique sur le compte avec une dur\xE9e d'expiration maximale de **3\
        \ ans**; le mot de passe du compte a chang\xE9 depuis la derni\xE8re modification\
        \ du PSO ;\n  * une politique de mot de passe affin\xE9e (Password Settings\
        \ Object ou PSO) s'applique sur le compte avec une longueur de mot de passe\
        \ sup\xE9rieure \xE0 **32**;\n  * une politique de mot de passe affin\xE9\
        e (Password Settings Object ou PSO) s'applique sur le compte avec une dur\xE9\
        e d'expiration maximale de **3 ans**;\n  * le mot de passe du compte a chang\xE9\
        \ depuis la derni\xE8re modification du PSO ;\n* le compte ne peut utiliser\
        \ que les algorithmes AES.\n\n## Cas particulier: retirer le compte des groupes\
        \ privil\xE9gi\xE9s\n\nSi les comptes ayant un SPN n'ont pas r\xE9ellement\
        \ besoin d'\xEAtre membres d'un groupe privil\xE9gi\xE9 de l'Active Directory,\
        \ il est pr\xE9f\xE9rable de les retirer de ces groupes et de faire les d\xE9\
        l\xE9gations n\xE9cessaires.\n\n## Contexte : groupes privil\xE9gi\xE9s\n\n\
        Les groupes privil\xE9gi\xE9s sont les groupes d'administration et les groupes\
        \ op\xE9ratifs ayant tous les droits et privil\xE8ges sur la for\xEAt ou pouvant\
        \ se les attribuer :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n\
        * \xAB *Contr\xF4leurs de domaine* (Domain Controllers) \xBB;\n* \xAB *Administrateurs\
        \ du sch\xE9ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs de l'entreprise*\
        \ (Enterprise Admins) \xBB ;\n* \xAB *Administrateurs du domaine* (Domain\
        \ Admins) \xBB : ces administrateurs ont les privil\xE8ges de lire la base\
        \ des secrets de tous les comptes et donc d'extraire les secrets de l'ensemble\
        \ des comptes privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de cl\xE9s* (Key\
        \ Admins) \xBB et \xAB *Administrateurs de cl\xE9s de l'entreprise* (Enterprise\
        \ Key Admins) \xBB: ces administrateurs peuvent fixer des valeurs arbitraires\
        \ aux attributs relatifs \xE0 Windows Hello for Business, pour tous les utilisateurs\
        \ sauf ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`. Si l'authentification\
        \ bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9e, ils peuvent g\xE9n\xE9\
        rer un certificat sous leur contr\xF4le, l'assigner \xE0 un compte privil\xE9\
        gi\xE9 (par exemple, un contr\xF4leur de domaine), et s'authentifier en tant\
        \ que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account Operators) \xBB : ces\
        \ op\xE9rateurs peuvent administrer tous les comptes d'utilisateurs, machines\
        \ et groupes; \xE0 l'exception des comptes prot\xE9g\xE9s par l' `adminSDHolder`;\n\
        * \xAB *Op\xE9rateurs de serveur* (Server Operators) \xBB : ces op\xE9rateurs\
        \ peuvent administrer les contr\xF4leurs de domaine, et donc r\xE9cup\xE9\
        rer les secrets de tous les comptes privil\xE9gi\xE9s ;\n* \xAB *Op\xE9rateurs\
        \ de sauvegarde* (Backup Operators) \xBB : ces op\xE9rateurs peuvent sauvegarder\
        \ un contr\xF4leur de domaine et donc extraire les secrets de tous les comptes\
        \ privil\xE9gi\xE9s depuis cette sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression*\
        \ (Print Operators) \xBB : ces op\xE9rateurs peuvent charger des pilotes d'impression\
        \ sur les contr\xF4leurs de domaine et donc charger un pilote malveillant\
        \ pour par exemple extraire les secrets de tous les comptes privil\xE9gi\xE9\
        s.\n\nLes groupes \xAB op\xE9rateurs \xBB sont vides par d\xE9faut et ne devraient\
        \ contenir aucun membre."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Privileged accounts with SPN (Level 1)
          description: '# Vulnerability description


            The `servicePrincipalName` (SPN) attribute is set on some privileged user
            accounts.


            An attacker could use this to attempt a brute force password cracking
            attempt, which may succeed for accounts with weak passwords.'
          annotation: "# Recommended measure\n\nThe `servicePrincipalName` (SPN) attribute\
            \ allows linking Kerberos service names to accounts. Whenever an account\
            \ owns a Kerberos service name, it becomes possible for any user to request\
            \ a ticket for that service. In that case, the received ticket is encrypted\
            \ with one of the corresponding account Kerberos encryption keys. Thus,\
            \ it is possible to start an offline brute force attack on the ticket\
            \ to recover the account password if it is not strong enough. By default,\
            \ only computer accounts have SPNs and the attribute must remain empty\
            \ for all privileged accounts.\n\n## General case: clear SPNs\n\nIn the\
            \ event that accounts currently with an SPN set must be privileged, their\
            \ `servicePrincipalName` attribute must be cleared and their password\
            \ must be changed.\n\nNote: a privileged account may hold an SPN granted\
            \ the following criteria are met:\n\n* the account is a Managed Service\
            \ Account (`sMSA` / `gMSA`);\n* **OR** a Password Settings Object (PSO)\
            \ applies to that account with a **32** or more character length requirement;\
            \ a Password Settings Object (PSO) applies to that account with an expiration\
            \ period of less than **3 years**; the account password was changed since\
            \ the last PSO modification;\n  * a Password Settings Object (PSO) applies\
            \ to that account with a **32** or more character length requirement;\n\
            \  * a Password Settings Object (PSO) applies to that account with an\
            \ expiration period of less than **3 years**;\n  * the account password\
            \ was changed since the last PSO modification;\n* the account can only\
            \ use AES encryption algorithms.\n\n## Specific cases: remove the account\
            \ from privileged groups\n\nIn the event that accounts currently with\
            \ an SPN set do not require their current privileged group membership,\
            \ they should be removed from those groups and be granted the relevant\
            \ access rights delegations.\n\nThe \xAB operators \xBB groups are empty\
            \ by default and must not have any member.\n\n## Context: privileged groups\n\
            \nPrivileged groups include administrator groups and operator groups which\
            \ have full control over the Active Directory forest either by design,\
            \ or by granting themselves such privileges:\n\n* \xAB *Administrators*\
            \ (Administrateurs) \xBB;\n* \xAB *Domain Controllers* (Contr\xF4leurs\
            \ de domaine) \xBB;\n* \xAB *Schema Admins* (Administrateurs du sch\xE9\
            ma) \xBB;\n* \xAB *Enterprise Admins* (Administrateurs de l'entreprise)\
            \ \xBB;\n* \xAB *Domain Admins* (Administrateurs du domaine) \xBB: these\
            \ administrators are able to read the authentication database and extract\
            \ password hashes and other secrets of all privileged accounts;\n* \xAB\
            \ *Key Admins* (Administrateurs de cl\xE9s) \xBB and \xAB *Enterprise\
            \ Key Admins* (Administrateurs de cl\xE9s de l'entreprise) \xBB: these\
            \ administrators can set arbitrary values to attributes relating to Windows\
            \ Hello for Business, for all users except those protected by the `adminSDHolder`\
            \ mechanism. If certificate-based authentication has been enabled, they\
            \ can generate a certificate that they control, assign it to privileged\
            \ accounts (for instance, a domain controller), and log on as them;\n\
            * \xAB *Account Operators* (Op\xE9rateurs de compte) \xBB: these operators\
            \ can manage user accounts, machine accounts and groups except accounts\
            \ protected by the `adminSDHolder` mechanism;\n* \xAB *Server Operators*\
            \ (Op\xE9rateurs de serveur) \xBB: these operators can manage domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database;\n* \xAB *Backup Operators* (Op\xE9\
            rateurs de sauvegarde) \xBB: these operators can back up a domain controller,\
            \ which grants them the ability to recover privileged user secrets from\
            \ that backup;\n* \xAB *Print Operators* (Op\xE9rateurs d'impression)\
            \ \xBB: these operators can load arbitrary printer drivers on domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_trusts_domain_notfiltered-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_trusts_domain_notfiltered-l1
      name: "Relations d'approbation sortante de type domaine non filtr\xE9 (Niveau\
        \ 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nUn ou plusieurs domaines\
        \ de la for\xEAt approuvent un domaine externe sans filtrage.\n\nUn attaquant\
        \ ayant compromis le domaine externe peut usurper l'identit\xE9 de n'importe\
        \ quel utilisateur ou machine du domaine (sauf comptes ayant un RID inf\xE9\
        rieur \xE0 1000, ce qui exclut les utilisateurs ou les groupes pr\xE9sents\
        \ par d\xE9faut). Il est alors possible pour cet individu malveillant d'acc\xE9\
        der \xE0 l'ensemble des donn\xE9es du domaine. Si un chemin de contr\xF4le\
        \ existe pour le compte usurp\xE9, il peut \xE9galement \xE9lever ses privil\xE8\
        ges vers \xAB *Administrateurs du domaine* (Domain Admins) \xBB et ainsi compromettre\
        \ l'ensemble de la for\xEAt."
      annotation: "# Recommandation\n\nDepuis <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">Windows 2003</span>, il est possible\
        \ de filtrer un domaine externe approuv\xE9. Ce m\xE9canisme est appel\xE9\
        \ \xAB quarantaine \xBB. Ce filtrage emp\xEAche tout utilisateur du domaine\
        \ approuv\xE9 d'usurper l'identit\xE9 d'un utilisateur d'un autre domaine.\
        \ Les relations d'approbation concern\xE9es doivent avoir ce m\xE9canisme\
        \ de quarantaine activ\xE9. Cette action peut \xEAtre effectu\xE9e via la\
        \ commande : `netdom trust <domaine> /domain:<domaine_externe_approuv\xE9\
        > /Quarantine:oui`.\n\nDe plus, il est recommand\xE9 de ne pas \xE9tablir\
        \ de relation d'approbation sortante depuis une for\xEAt de confiance vers\
        \ un domaine de moindre confiance / sensibilit\xE9.\n\nNote : le type de relation\
        \ d'approbation est v\xE9rifi\xE9 par la pr\xE9sence ou l'absence de certains\
        \ attributs ldap. La relation externe relev\xE9e dans cette vuln\xE9rabilit\xE9\
        \ est d\xE9duite de l'absence de l'attribut <code style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WITHIN_FOREST</code>. Dans certains\
        \ cas, lorsque les for\xEAts sont anciennes, les relations d'approbation internes\
        \ ne sont pas correctement marqu\xE9es <code style=\"background-color:rgb(0,\
        \ 123, 255);color:rgb(255, 255, 255)\">WITHIN_FOREST</code>. Dans ce cas,\
        \ il est n\xE9cessaire d'effectuer une op\xE9ration manuelle pour positionner\
        \ les attributs corrects sur les relations."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Unfiltered outbound domain trust relationship (Level 1)
          description: '# Vulnerability description


            Some domains in the forest are currently trusting a third-party domain
            without quarantine.


            An attacker having compromised the remote domain can spoof any user or
            machine on the local domain (except for accounts with a RID lower than
            1000, excluding built-in accounts and groups). This attacker can therefore
            access every resource on the local domain. If a dangerous control path
            is exposed to any "spoofable" account (virtually any account other than
            the built-in ones), the attacker could also escalate his privileges up
            to " *Domain Admins* (Administrateurs du domaine) " and compromise the
            entire forest.'
          annotation: '# Recommended measure


            <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">Windows
            2003</span> introduces the ability to quarantine a trusted external domain
            (also called "filtering"). This prevents any user from the trusted domain
            from spoofing a user of another. Each relevant trust relationship must
            have this feature enabled individually. This can be done by issuing the
            following command: `netdom trust <local domain> /domain:<external trusted
            domain> /Quarantine:yes`.


            Setting up outbound trust relationships to lower trust-level domains is
            strongly discouraged.


            Note: each trust relationship type is defined by flags set within some
            of their LDAP attributes. This issue focuses on relationships lacking
            the <code style="background-color:rgb(0, 123, 255);color:rgb(255, 255,
            255)">WITHIN_FOREST</code> flag. In some cases, particularly with legacy
            / old forests, internal trust relationships may not bear the <code style="background-color:rgb(0,
            123, 255);color:rgb(255, 255, 255)">WITHIN_FOREST</code> flag. Should
            this occur the various flags must be manually set on all relevant relationships.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_trusts_forest_sidhistory-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_trusts_forest_sidhistory-l1
      name: "Relations d'approbation sortantes de type for\xEAt avec sID History activ\xE9\
        \ (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa for\xEAt approuve\
        \ une for\xEAt externe, avec un filtrage affaibli. Un attaquant ayant compromis\
        \ la for\xEAt externe peut usurper l'identit\xE9 de n'importe quel utilisateur\
        \ ou machine de la for\xEAt (sauf comptes ayant un RID inf\xE9rieur \xE0 1000,\
        \ ce qui exclut les utilisateurs ou les groupes pr\xE9sents par d\xE9faut).\
        \ Il est alors possible pour cet individu malveillant d'acc\xE9der \xE0 l'ensemble\
        \ des donn\xE9es de la for\xEAt. Si un chemin de contr\xF4le existe pour le\
        \ compte usurp\xE9, il peut \xE9galement \xE9lever ses privil\xE8ges vers\
        \ \xAB *Administrateurs du domaine* (Domain Admins) \xBB et ainsi compromettre\
        \ l'ensemble de la for\xEAt."
      annotation: "# Recommandation\n\nPar construction, les relations d'approbation\
        \ de type for\xEAt sont filtr\xE9es. Toutefois, ce filtrage a \xE9t\xE9 affaibli\
        \ pour permettre le fonctionnement d'un m\xE9canisme appel\xE9 `sIDHistory`,\
        \ utilis\xE9 notamment lors d'une migration de for\xEAt.\n\nIl convient pr\xE9\
        alablement de justifier l'affaiblissement du filtrage entre ces for\xEAts.\
        \ Ceci peut \xEAtre d\xFB \xE0 une migration en cours n\xE9cessitant le m\xE9\
        canisme du `sIDHistory`. Si c'est le cas, il est alors n\xE9cessaire de terminer\
        \ cette migration avant de r\xE9activer le filtrage par d\xE9faut. Le retour\
        \ \xE0 un \xE9tat de filtrage par d\xE9faut peut \xEAtre effectu\xE9 avec\
        \ la commande : `netdom trust <for\xEAt> /domain:<for\xEAt_tierce_approuv\xE9\
        e> /EnableSIDHistory:no`."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Outbound forest trust relationships with sID History enabled (Level
            1)
          description: '# Vulnerability description


            The forest currently trusts an external forest with diminished filtering.


            An attacker having compromised the remote domain can spoof any user or
            machine on the local domain (except for accounts with a RID lower than
            1000, excluding built-in accounts and groups). This attacker can therefore
            access every resource on the local domain. If a dangerous control path
            is exposed to any "spoofable" account (virtually any account other than
            the built-in ones), the attacker could also escalate his privileges up
            to " *Domain Admins* (Administrateurs du domaine) " and compromise the
            entire forest.'
          annotation: '# Recommended measure


            Any outbound trust extends the trusting forest security boundary to include
            a third-party forest. By default, forest trusts are filtered. However,
            it is possible to relax these restrictions, and enable the `sIDHistory`
            mechanism. In that case, the trusting forest is endangered by the trusted
            forest.


            The rationale behind the current configuration (<code style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">TREAT_AS_EXTERNAL</code>) should first
            be clarified. It might be set for an ongoing migration which requires
            the `sIDHistory` mechanism. Otherwise, filtering should be restored to
            its defaults through the command: `netdom trust <forest> /domain:<other
            trusted forest> /EnableSIDHistory:no`.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_user_accounts_dormant-l1
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_user_accounts_dormant-l1
      name: "Nombre important de comptes actifs inutilis\xE9s (Niveau 1)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa for\xEAt contient\
        \ plus de 25% de comptes dormants. Les comptes dormants correspondent \xE0\
        \ des comptes utilisateur ou machine, non d\xE9sactiv\xE9s qui ne se sont\
        \ pas authentifi\xE9s aupr\xE8s de l'Active Directory depuis plus d'un an,\
        \ ou qui ont \xE9t\xE9 cr\xE9\xE9s il y a plus d'un an et ne se sont jamais\
        \ connect\xE9s. Ces comptes dormants sont soit des comptes l\xE9gitimes devant\
        \ \xEAtre rarement utilis\xE9s, soit des comptes obsol\xE8tes.\n\nLes comptes\
        \ obsol\xE8tes peuvent donner acc\xE8s \xE0 des personnes n'en ayant plus\
        \ besoin (suite \xE0 un d\xE9part par exemple) ou \xEAtre utilis\xE9s de mani\xE8\
        re furtive par un attaquant, ce qui est d'autant plus pr\xE9judiciable si\
        \ ces comptes sont privil\xE9gi\xE9s. La pr\xE9sence de ces comptes augmente\
        \ par ailleurs le travail de gestion des comptes (revue de droits, etc.).\n\
        \n## Comptes dormants / Comptes non d\xE9sactiv\xE9s"
      annotation: "# Recommandation\n\nL'absence de politique de gestion des comptes\
        \ (ou sa mauvaise application) peut entra\xEEner la persistance de comptes\
        \ obsol\xE8tes sur le domaine. Cela peut s'expliquer, par exemple, par le\
        \ d\xE9part ou le changement d'affectation d'un utilisateur, la suppression\
        \ d'une application ou la mise au rebut d'une machine.\n\nSont consid\xE9\
        r\xE9s comme dormants des comptes n'ayant pas eu d'activit\xE9 aupr\xE8s du\
        \ domaine depuis plus d'un an. Sont consid\xE9r\xE9s comme obsol\xE8tes des\
        \ comptes dormants dont l'existence dans le domaine n'est plus justifi\xE9\
        e.\n\nDeux crit\xE8res peuvent \xEAtre utilis\xE9s pour \xE9num\xE9rer les\
        \ comptes dormants dans un domaine :\n\n* les comptes dont le mot de passe\
        \ doit expirer et pour lesquels la date de dernier changement est sup\xE9\
        rieure \xE0 un an (propri\xE9t\xE9 `pwdLastSet`) ;\n* les comptes n'ayant\
        \ pas r\xE9alis\xE9 une authentification aupr\xE8s du domaine depuis plus\
        \ d'un an (propri\xE9t\xE9 `LastLogonTimestamp`), ou n'ayant jamais r\xE9\
        alis\xE9 d'authentification aupr\xE8s du domaine et ayant \xE9t\xE9 cr\xE9\
        \xE9s il y a plus d'un an. Attention, cette propri\xE9t\xE9 n'est mise \xE0\
        \ jour que si le niveau de fonctionnalit\xE9 du domaine est au moins positionn\xE9\
        \ \xE0 <span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255,\
        \ 255)\">Windows 2003</span>.\n\nIl convient de d\xE9terminer, parmi ces comptes\
        \ dormants, les comptes obsol\xE8tes. En effet, une partie des comptes pr\xE9\
        sent\xE9s en annexe peut concerner des comptes dormants l\xE9gitimes (par\
        \ exemple un compte de secours) ou encore des comptes utilis\xE9s pour cr\xE9\
        er des bo\xEEtes de messagerie Exchange consult\xE9es uniquement par d\xE9\
        l\xE9gation. Ces comptes fonctionnels Exchange doivent \xEAtre d\xE9sactiv\xE9\
        s et positionn\xE9s dans une OU ad\xE9quate.\n\nIl est n\xE9cessaire de neutraliser\
        \ les comptes obsol\xE8tes. Cette m\xE9thode de neutralisation apporte les\
        \ m\xEAmes avantages que la suppression tout en conservant la tra\xE7abilit\xE9\
        \ offerte par la simple d\xE9sactivation. Pour neutraliser un compte, il faut\
        \ :\n\n* d\xE9sactiver le compte ;\n* le retirer de tous ses groupes d'appartenance\
        \ ;\n* changer son mot de passe de fa\xE7on al\xE9atoire. Pour garantir un\
        \ mot de passe al\xE9atoire, il est recommand\xE9 de s\xE9lectionner l\u2019\
        option \xAB Une carte \xE0 puce est n\xE9cessaire pour ouvrir une session\
        \ interactive \xBB dans les propri\xE9t\xE9s du compte. Cela revient \xE0\
        \ positionner l'attribut <code style=\"background-color:rgb(40, 167, 69);color:rgb(255,\
        \ 255, 255)\">ADS_UF_SMARTCARD_REQUIRED</code> dans la propri\xE9t\xE9 `userAccountControl`;\n\
        * \xE9ventuellement, d\xE9placer le compte dans une OU d\xE9di\xE9e ;\n* \xE9\
        ventuellement, mettre \xE0 jour le champ description du compte afin d'indiquer\
        \ le contexte de d\xE9sactivation (date, raison, etc.)."
      implementation_groups:
      - level_1
      translations:
        en:
          name: Dormant accounts (Level 1)
          description: '# Vulnerability description


            More than 25% of forest accounts are dormant. This type of user or computer
            accounts are not disabled, and did not authenticate against the Active
            Directory for more than a year, or were created more than a year ago and
            have never authenticated. Dormant accounts are either legitimate accounts
            which are rarely used, or obsolete accounts.


            Obsolete accounts grant users illegitimate accesses (e.g., after they
            left the company) or be stealthily used by attackers, which is even more
            problematic if the accounts are privileged. Their mere existence also
            makes user and access rights accountability much harder.


            ## Dormant accounts / Enabled accounts'
          annotation: '# Recommended measure


            Without an account management policy, obsolete accounts can remain for
            extended periods of time in the domain. This can be due to a person leaving
            the company or changing roles, or an application or computer being retired.


            Dormant accounts have had no activity in the domain in the past year.
            Obsolete accounts are dormant accounts which do not have a purpose anymore.


            Obsolete accounts (computer, user, administrator, or service alike) must
            be disabled, or even deleted.


            Two criteria can help enumerate dormant accounts in a domain:


            * accounts whose password expires and whose last password change date
            is older than a year (the `pwdLastSet` attribute);

            * accounts which have not authenticated to the domain for more than a
            year (the `LastLogonTimestamp` attribute), or accounts which have never
            authenticated to the domain and were created more than a year ago. Beware
            this attribute is only updated if the domain functional level is <span
            style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">Windows
            2003</span> or more.


            Obsolete accounts must be distinguished from other dormant accounts. As
            a matter of fact, part of the accounts in the list can be legitimate dormant
            accounts (for instance, accounts used in case of emergency) or used to
            create Exchange mailboxes read through access delegations. Such functional
            Exchange accounts should be disabled and put in a dedicated OU.


            Unused accounts should be disabled. The following procedure provides similar
            benefits than deletion, while retaining information relevant to audit
            traces. To properly disable an account:


            * disable the account;

            * remove all of its group memberships;

            * randomly change its password. To enforce a random password, one can
            check the smart card is required for interactive logon flag in the account
            properties. This is equivalent to manually setting the <code style="background-color:rgb(40,
            167, 69);color:rgb(255, 255, 255)">ADS_UF_SMARTCARD_REQUIRED</code> flag
            of its `userAccountControl` attribute;

            * optionally, move the account to a dedicated OU;

            * optionally, update the account description field to mention the context
            for disabling (date, reason, etc.).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_adupdate_bad-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_adupdate_bad-l2
      name: Mauvaises versions de l'Active Directory (Niveau 2)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa pr\xE9paration du\
        \ domaine (Domain-wide update) est en version <span style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">15</span>. Cette version cr\xE9e un chemin\
        \ de contr\xF4le permettant le contr\xF4le total de l'Active Directory par\
        \ certains groupes."
      annotation: "# Recommandation\n\nLa pr\xE9paration du domaine en version <span\
        \ style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">15</span>\
        \ positionne des ACE trop permissives aux groupes *Administrateurs de cl\xE9\
        s* (Key Admins) et *Administrateurs de cl\xE9s de l'entreprise* (Enterprise\
        \ Key Admins). Il est donc recommand\xE9 d'appliquer la pr\xE9paration de\
        \ domaine au moins en version <span style=\"background-color:rgb(40, 167,\
        \ 69);color:rgb(255, 255, 255)\">16</span>.\n\nLa pr\xE9paration d'un domaine\
        \ est effectu\xE9e \xE0 l'aide de l'outil `adprep.exe`, pr\xE9sent dans le\
        \ m\xE9dia d'installation Windows Server. La r\xE9vision <span style=\"background-color:rgb(40,\
        \ 167, 69);color:rgb(255, 255, 255)\">16</span> est disponible depuis un m\xE9\
        dia Windows Server, version 1709 ou ult\xE9rieur (par exemple Windows Server\
        \ 2019).\n\nLes commandes permettant de r\xE9aliser cette action sont `adprep\
        \ /ForestPrep` puis `adprep /DomainPrep`. [https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/adprep/changes-made-by-adprep](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/adprep/changes-made-by-adprep)\n\
        \n**Note**: l'op\xE9ration de pr\xE9paration d'un domaine est d\xE9corr\xE9\
        l\xE9e de la version des syst\xE8mes d'exploitation des contr\xF4leurs de\
        \ domaine ou des niveaux fonctionnels (domaine et for\xEAt). Il n'est donc\
        \ pas n\xE9cessaire de mettre \xE0 jour les syst\xE8mes d'exploitation des\
        \ contr\xF4leurs de domaine ou d'augmenter les niveaux fonctionnels."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Bad Active Directory versions (Level 2)
          description: '# Vulnerability description


            The domain preparation (Domain-Wide update) has a revision on <span style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">15</span>. This specific version mistakenly
            introduces a control path exposing the Active Directory to a full takeover
            by some builtin user groups.'
          annotation: "# Recommended measure\n\nThe revision <span style=\"background-color:rgb(220,\
            \ 53, 69);color:rgb(255, 255, 255)\">15</span> domain preparation is problematic.\
            \ It sets overly permissive Access Control Entries (ACEs) on groups *Key\
            \ Admins* (Administrateurs de cl\xE9s) and *Enterprise Key Admins* (Administrateurs\
            \ de cl\xE9s de l'entreprise). Is is recommanded to apply the domain preparation\
            \ of at least revision <span style=\"background-color:rgb(40, 167, 69);color:rgb(255,\
            \ 255, 255)\">16</span>.\n\nThe domain preparation is performed using\
            \ the `adprep.exe` utility, found in the Windows Server installation media.\
            \ The revision <span style=\"background-color:rgb(40, 167, 69);color:rgb(255,\
            \ 255, 255)\">16</span> is available on Windows Server media of version\
            \ 1709 and later (for instance Windows Server 2019).\n\nThe following\
            \ commands are used to perform this operation `adprep /ForestPrep` then\
            \ `adprep /DomainPrep`. [https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/adprep/changes-made-by-adprep](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/adprep/changes-made-by-adprep)\n\
            \n**Note**: the domain preparation operation is not linked to domain controller\
            \ operating systems or functional levels (domain and forest). It is not\
            \ required to update domain controllers operating systems or raise functional\
            \ levels."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_compatible_2000_anonymous-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_compatible_2000_anonymous-l2
      name: Le groupe "Pre-Windows 2000 Compatible Access" contient "Anonymous" (Niveau
        2)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLe m\xE9canisme de\
        \ compatibilit\xE9 pr\xE9-Windows 2000 est activ\xE9. Cela se caract\xE9rise\
        \ par la pr\xE9sence de l'identifiant de s\xE9curit\xE9 *Anonyme* (Anonymous)\
        \ (`S-1-5-7`) dans les membres du groupe *Builtin\\Acc\xE8s compatible pr\xE9\
        -Windows 2000* (Builtin\\Pre-Windows 2000 Compatible Access). Ce m\xE9canisme\
        \ permet une \xE9num\xE9ration anonyme de certains \xE9l\xE9ments aupr\xE8\
        s des contr\xF4leurs de domaine."
      annotation: "# Recommandation\n\nLe m\xE9canisme de compatibilit\xE9 pr\xE9\
        -Windows 2000 permet d'assurer le support des syst\xE8mes ant\xE9rieur \xE0\
        \ Windows 2000 (Windows NT 4.0). Historiquement utilis\xE9 pour des raisons\
        \ de r\xE9trocompatibilit\xE9, le groupe *Builtin\\Acc\xE8s compatible pr\xE9\
        -Windows 2000* (Builtin\\Pre-Windows 2000 Compatible Access) ne doit contenir\
        \ que *Utilisateurs authentifi\xE9s* (Authenticated Users) (`S-1-5-11`)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: The "Pre-Windows 2000 Compatible Access" group includes "Anonymous"
            (Level 2)
          description: "# Vulnerability description\n\nThe pre-Windows 2000 compatibility\
            \ mechanism ensures Windows NT domains are still supported. It is enabled\
            \ by adding the *Anonymous* (Anonyme) SID (`S-1-5-7`) to the *Builtin\\\
            Pre-Windows 2000 Compatible Access* (Builtin\\Acc\xE8s compatible pr\xE9\
            -Windows 2000) group, which allows anonymous access to some of Active\
            \ Directory contents on domain controllers."
          annotation: "# Recommended measure\n\nThe *Builtin\\Pre-Windows 2000 Compatible\
            \ Access* (Builtin\\Acc\xE8s compatible pr\xE9-Windows 2000) group used\
            \ to serve backward compatibility purposes for systems prior to Windows\
            \ 2000 (Windows NT 4.0). This group must only include *Authenticated Users*\
            \ (Utilisateurs authentifi\xE9s) (`S-1-5-11`)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dc_crypto-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dc_crypto-l2
      name: "Algorithmes de chiffrement support\xE9s par les DC/RODC (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLes DC/RODC mettent\
        \ en \u0153uvre diff\xE9rents algorithmes de chiffrement pour les tickets\
        \ Kerberos (DES, RC4, AES). Initialement, seul l'algorithme RC4 (RC4-HMAC)\
        \ \xE9tait support\xE9 pour les syst\xE8mes Windows et les algorithmes bas\xE9\
        s sur DES pouvaient \xEAtre activ\xE9 pour am\xE9liorer la compatibilit\xE9\
        \ avec les syst\xE8mes non Windows.\n\nWindows Server 2008 a apport\xE9 le\
        \ support d'algorithmes reposant sur AES (AES128-CTS-HMAC-SHA1-96 et AES256-CTS-HMAC-SHA1-96)\
        \ , ceux-ci ayant \xE9t\xE9 normalis\xE9s et support\xE9s par des syst\xE8\
        mes non Windows.\n\nActuellement, les algorithmes bas\xE9s sur DES (DES-CBC-CRC\
        \ et DES-CBC-MD5) sont consid\xE9r\xE9s comme obsol\xE8tes et doivent \xEA\
        tes d\xE9sactiv\xE9s. De m\xEAme, dans un objectif de durcissement, l'algorithme\
        \ RC4 peut \xEAtre d\xE9sactiv\xE9 ceci entrainant cependant la perte de compatibilit\xE9\
        \ avec les syst\xE8mes ant\xE9rieurs \xE0 Windows Vista et Windows Server\
        \ 2008.\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le pr\xE9sente\
        \ des seuils de tol\xE9rance diff\xE9rents en fonction du niveau de s\xE9\
        curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> apparaissent les DC/RODC avec les\
        \ algorithmes DES-CBC-CRC ou DES-CBC-MD5 activ\xE9 ;\n* au niveau <span style=\"\
        background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)\">3</span> apparaissent\
        \ les DC/RODC ne supportant pas AES (AES128-CTS-HMAC-SHA1-96 ou AES256-CTS-HMAC-SHA1-96)\
        \ ;\n* au niveau <span style=\"background-color:rgb(0, 123, 255);color:rgb(255,\
        \ 255, 255)\">4</span> apparaissent les DC/RODC avec l'algorithme RC4-HMAC\
        \ activ\xE9."
      annotation: "# Recommandation\n\nLa configuration des algorithmes support\xE9\
        s par un DC/RODC est d\xE9finie dans les options de s\xE9curit\xE9 de la strat\xE9\
        gie de s\xE9curit\xE9 locale (S\xE9curit\xE9 r\xE9seau : Configurer les types\
        \ de chiffrement autoris\xE9s pour Kerberos). Ce param\xE8tre ne doit pas\
        \ \xEAtre modifi\xE9 dans chaque strat\xE9gie de s\xE9curit\xE9 locale des\
        \ DC (risque de d\xE9synchronisation entre les DC). Il est recommand\xE9 de\
        \ modifier ce param\xE8tre dans la GPO \"Default Domain Controller Policy\"\
        \ ou toute autre GPO appliqu\xE9e aux DC.\n\nAu niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span>, il est recommand\xE9 de d\xE9finir\
        \ cette strat\xE9gie et d'activer : RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96\
        \ et \"Futurs types de chiffrement\".\n\nAu niveau <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span>, il est recommand\xE9 de d\xE9finir\
        \ cette strat\xE9gie et d'activer : AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96\
        \ et \"Futurs types de chiffrement\".\n\nAvant de modifier ce param\xE8tre,\
        \ il est n\xE9cessaire de s'assurer que les contr\xF4leurs de domaine n'\xE9\
        mettent que des TGT ou des tickets de service chiffr\xE9s avec AES128 ou AES256.\
        \ Ceci peut \xEAtre v\xE9rifi\xE9 en regardant, sur chaque DC, les \xE9v\xE8\
        nements 4768 (demande de TGT) et 4769 (demande de ticket de service) dans\
        \ le journal S\xE9curit\xE9. Dans ces deux \xE9v\xE8nements, l'attribut `TicketEncryptionType`\
        \ indique l'algorithme utilis\xE9 par le contr\xF4le de domaine pour chiffrer\
        \ le ticket. Il convient de s'assurer que seuls les types 0x11 (AES128-CTS-HMAC-SHA1-96)\
        \ ou 0x12 (AES256-CTS-HMAC-SHA1-96) sont utilis\xE9s.\n\nLa modification ne\
        \ doit pas \xEAtre faite en \xE9ditant l'attribut LDAP `msDS-SupportedEncryptionTypes`\
        \ directement, mais en passant par une GPO qui doit \xEAtre d\xE9ploy\xE9\
        e sur tous les DC et RODC. Le param\xE8tre se trouve sous :\n\nConsole GPO\n\
        \n* Configuration ordinateur\n  * Param\xE8tres Windows\n    * Param\xE8tres\
        \ de s\xE9curit\xE9\n      * Strat\xE9gies locales\n        * Options de s\xE9\
        curit\xE9\n          * S\xE9curit\xE9 r\xE9seau : Configurer les types de\
        \ chiffrement autoris\xE9s pour Kerberos : RC4-HMAC, AES128-CTS-HMAC-SHA1-96,\
        \ AES256-CTS-HMAC-SHA1-96 et \"Futurs types de chiffrement\""
      implementation_groups:
      - level_2
      translations:
        en:
          name: DC/RODC supported encryption algorithms (Level 2)
          description: '# Vulnerability description


            DC and RODC may use several encryption algorithms for Kerberos tickets
            (DES, RC4, AES). At first, only the RC4 algorithm (RC4-HMAC) was supported
            for Windows systems and DES based algorithms could be enabled to improve
            compatibility with non-Windows systems.


            Windows Server 2008 introduced the support of AES-based algorithms (AES128-CTS-HMAC-SHA1-96
            and AES256-CTS-HMAC-SHA1-96), which had been supported for non-Windows
            systems.


            Today, DES based algorithms (DES-CBC-CRC et DES-CBC-MD5) are considered
            obsolete and must be disabled. Likewise, in a hardening perspective, the
            RC4 algorithm should be disabled, with the side effect the loss of compatibility
            with systems older than Windows Vista and Windows Server 2008.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * level <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0,
            0)">2</span> shows DC/RODC with DES-CBC-CRC or DES-CBC-MD5 algorithms
            enabled;

            * level <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> shows DC/RODC without AES support (AES128-CTS-HMAC-SHA1-96
            or AES256-CTS-HMAC-SHA1-96);

            * level <span style="background-color:rgb(0, 123, 255);color:rgb(255,
            255, 255)">4</span> shows DC/RODC with RC4-HMAC algorithm enabled.'
          annotation: "# Recommended measure\n\nThe configuration of supported encryption\
            \ algorithms for DC/RODC is made in the security options of the local\
            \ security policy (Network Security : Configure encryption types allowed\
            \ for Kerberos). This setting should not be modified manually in each\
            \ DC local security policy (risking desynchronization between DCs). Rather,\
            \ one should edit this setting in the \"Default Domain Controller Policy\"\
            \ GPO, or any other GPO which applies to domain controllers.\n\nAt level\
            \ <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >2</span>, it is recommended to enable that strategy and check: RC4-HMAC,\
            \ AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and \"Future encryption\
            \ types\".\n\nAt level <span style=\"background-color:rgb(240, 230, 140);color:rgb(0,\
            \ 0, 0)\">3</span>, it is recommended to enable that strategy and check:\
            \ AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and \"Future encryption\
            \ types\".\n\nIt is required to check that domain controllers only emit\
            \ tickets with AES128 or AES256 encryption before editing this setting.\
            \ This can be done by looking at the events 4768 (TGT requests) and 4769\
            \ (service tickets requests) in the Security event log of every DC. In\
            \ those two events, the `TicketEncryptionType` attribute indicates the\
            \ encryption algorithm used by the DC. Only types 0x11 (AES128-CTS-HMAC-SHA1-96)\
            \ or 0x12 (AES256-CTS-HMAC-SHA1-96) should be used.\n\nThe change shall\
            \ not be applied through modifying the `msDS-SupportedEncryptionTypes`\
            \ LDAP attribute directly. Use a GPO that would apply to all DCs and RODCs\
            \ instead. The setting can be found under:\n\nConsole GPO\n\n* Computer\
            \ Configuration\n  * Windows Settings\n    * Security Settings\n     \
            \ * Local Policies\n        * Security Options\n          * S\xE9curit\xE9\
            \ r\xE9seau : Configurer les types de chiffrement autoris\xE9s pour Kerberos\
            \ : RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and \"\
            Future encryption types\""
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dc_crypto-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dc_crypto-l3
      name: "Algorithmes de chiffrement support\xE9s par les DC/RODC (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLes DC/RODC mettent\
        \ en \u0153uvre diff\xE9rents algorithmes de chiffrement pour les tickets\
        \ Kerberos (DES, RC4, AES). Initialement, seul l'algorithme RC4 (RC4-HMAC)\
        \ \xE9tait support\xE9 pour les syst\xE8mes Windows et les algorithmes bas\xE9\
        s sur DES pouvaient \xEAtre activ\xE9 pour am\xE9liorer la compatibilit\xE9\
        \ avec les syst\xE8mes non Windows.\n\nWindows Server 2008 a apport\xE9 le\
        \ support d'algorithmes reposant sur AES (AES128-CTS-HMAC-SHA1-96 et AES256-CTS-HMAC-SHA1-96)\
        \ , ceux-ci ayant \xE9t\xE9 normalis\xE9s et support\xE9s par des syst\xE8\
        mes non Windows.\n\nActuellement, les algorithmes bas\xE9s sur DES (DES-CBC-CRC\
        \ et DES-CBC-MD5) sont consid\xE9r\xE9s comme obsol\xE8tes et doivent \xEA\
        tes d\xE9sactiv\xE9s. De m\xEAme, dans un objectif de durcissement, l'algorithme\
        \ RC4 peut \xEAtre d\xE9sactiv\xE9 ceci entrainant cependant la perte de compatibilit\xE9\
        \ avec les syst\xE8mes ant\xE9rieurs \xE0 Windows Vista et Windows Server\
        \ 2008.\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le pr\xE9sente\
        \ des seuils de tol\xE9rance diff\xE9rents en fonction du niveau de s\xE9\
        curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> apparaissent les DC/RODC avec les\
        \ algorithmes DES-CBC-CRC ou DES-CBC-MD5 activ\xE9 ;\n* au niveau <span style=\"\
        background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)\">3</span> apparaissent\
        \ les DC/RODC ne supportant pas AES (AES128-CTS-HMAC-SHA1-96 ou AES256-CTS-HMAC-SHA1-96)\
        \ ;\n* au niveau <span style=\"background-color:rgb(0, 123, 255);color:rgb(255,\
        \ 255, 255)\">4</span> apparaissent les DC/RODC avec l'algorithme RC4-HMAC\
        \ activ\xE9."
      annotation: "# Recommandation\n\nLa configuration des algorithmes support\xE9\
        s par un DC/RODC est d\xE9finie dans les options de s\xE9curit\xE9 de la strat\xE9\
        gie de s\xE9curit\xE9 locale (S\xE9curit\xE9 r\xE9seau : Configurer les types\
        \ de chiffrement autoris\xE9s pour Kerberos). Ce param\xE8tre ne doit pas\
        \ \xEAtre modifi\xE9 dans chaque strat\xE9gie de s\xE9curit\xE9 locale des\
        \ DC (risque de d\xE9synchronisation entre les DC). Il est recommand\xE9 de\
        \ modifier ce param\xE8tre dans la GPO \"Default Domain Controller Policy\"\
        \ ou toute autre GPO appliqu\xE9e aux DC.\n\nAu niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span>, il est recommand\xE9 de d\xE9finir\
        \ cette strat\xE9gie et d'activer : RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96\
        \ et \"Futurs types de chiffrement\".\n\nAu niveau <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span>, il est recommand\xE9 de d\xE9finir\
        \ cette strat\xE9gie et d'activer : AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96\
        \ et \"Futurs types de chiffrement\".\n\nAvant de modifier ce param\xE8tre,\
        \ il est n\xE9cessaire de s'assurer que les contr\xF4leurs de domaine n'\xE9\
        mettent que des TGT ou des tickets de service chiffr\xE9s avec AES128 ou AES256.\
        \ Ceci peut \xEAtre v\xE9rifi\xE9 en regardant, sur chaque DC, les \xE9v\xE8\
        nements 4768 (demande de TGT) et 4769 (demande de ticket de service) dans\
        \ le journal S\xE9curit\xE9. Dans ces deux \xE9v\xE8nements, l'attribut `TicketEncryptionType`\
        \ indique l'algorithme utilis\xE9 par le contr\xF4le de domaine pour chiffrer\
        \ le ticket. Il convient de s'assurer que seuls les types 0x11 (AES128-CTS-HMAC-SHA1-96)\
        \ ou 0x12 (AES256-CTS-HMAC-SHA1-96) sont utilis\xE9s.\n\nLa modification ne\
        \ doit pas \xEAtre faite en \xE9ditant l'attribut LDAP `msDS-SupportedEncryptionTypes`\
        \ directement, mais en passant par une GPO qui doit \xEAtre d\xE9ploy\xE9\
        e sur tous les DC et RODC. Le param\xE8tre se trouve sous :\n\nConsole GPO\n\
        \n* Configuration ordinateur\n  * Param\xE8tres Windows\n    * Param\xE8tres\
        \ de s\xE9curit\xE9\n      * Strat\xE9gies locales\n        * Options de s\xE9\
        curit\xE9\n          * S\xE9curit\xE9 r\xE9seau : Configurer les types de\
        \ chiffrement autoris\xE9s pour Kerberos : RC4-HMAC, AES128-CTS-HMAC-SHA1-96,\
        \ AES256-CTS-HMAC-SHA1-96 et \"Futurs types de chiffrement\""
      implementation_groups:
      - level_3
      translations:
        en:
          name: DC/RODC supported encryption algorithms (Level 3)
          description: '# Vulnerability description


            DC and RODC may use several encryption algorithms for Kerberos tickets
            (DES, RC4, AES). At first, only the RC4 algorithm (RC4-HMAC) was supported
            for Windows systems and DES based algorithms could be enabled to improve
            compatibility with non-Windows systems.


            Windows Server 2008 introduced the support of AES-based algorithms (AES128-CTS-HMAC-SHA1-96
            and AES256-CTS-HMAC-SHA1-96), which had been supported for non-Windows
            systems.


            Today, DES based algorithms (DES-CBC-CRC et DES-CBC-MD5) are considered
            obsolete and must be disabled. Likewise, in a hardening perspective, the
            RC4 algorithm should be disabled, with the side effect the loss of compatibility
            with systems older than Windows Vista and Windows Server 2008.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * level <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0,
            0)">2</span> shows DC/RODC with DES-CBC-CRC or DES-CBC-MD5 algorithms
            enabled;

            * level <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> shows DC/RODC without AES support (AES128-CTS-HMAC-SHA1-96
            or AES256-CTS-HMAC-SHA1-96);

            * level <span style="background-color:rgb(0, 123, 255);color:rgb(255,
            255, 255)">4</span> shows DC/RODC with RC4-HMAC algorithm enabled.'
          annotation: "# Recommended measure\n\nThe configuration of supported encryption\
            \ algorithms for DC/RODC is made in the security options of the local\
            \ security policy (Network Security : Configure encryption types allowed\
            \ for Kerberos). This setting should not be modified manually in each\
            \ DC local security policy (risking desynchronization between DCs). Rather,\
            \ one should edit this setting in the \"Default Domain Controller Policy\"\
            \ GPO, or any other GPO which applies to domain controllers.\n\nAt level\
            \ <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >2</span>, it is recommended to enable that strategy and check: RC4-HMAC,\
            \ AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and \"Future encryption\
            \ types\".\n\nAt level <span style=\"background-color:rgb(240, 230, 140);color:rgb(0,\
            \ 0, 0)\">3</span>, it is recommended to enable that strategy and check:\
            \ AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and \"Future encryption\
            \ types\".\n\nIt is required to check that domain controllers only emit\
            \ tickets with AES128 or AES256 encryption before editing this setting.\
            \ This can be done by looking at the events 4768 (TGT requests) and 4769\
            \ (service tickets requests) in the Security event log of every DC. In\
            \ those two events, the `TicketEncryptionType` attribute indicates the\
            \ encryption algorithm used by the DC. Only types 0x11 (AES128-CTS-HMAC-SHA1-96)\
            \ or 0x12 (AES256-CTS-HMAC-SHA1-96) should be used.\n\nThe change shall\
            \ not be applied through modifying the `msDS-SupportedEncryptionTypes`\
            \ LDAP attribute directly. Use a GPO that would apply to all DCs and RODCs\
            \ instead. The setting can be found under:\n\nConsole GPO\n\n* Computer\
            \ Configuration\n  * Windows Settings\n    * Security Settings\n     \
            \ * Local Policies\n        * Security Options\n          * S\xE9curit\xE9\
            \ r\xE9seau : Configurer les types de chiffrement autoris\xE9s pour Kerberos\
            \ : RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and \"\
            Future encryption types\""
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dc_crypto-l4
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dc_crypto-l4
      name: "Algorithmes de chiffrement support\xE9s par les DC/RODC (Niveau 4)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLes DC/RODC mettent\
        \ en \u0153uvre diff\xE9rents algorithmes de chiffrement pour les tickets\
        \ Kerberos (DES, RC4, AES). Initialement, seul l'algorithme RC4 (RC4-HMAC)\
        \ \xE9tait support\xE9 pour les syst\xE8mes Windows et les algorithmes bas\xE9\
        s sur DES pouvaient \xEAtre activ\xE9 pour am\xE9liorer la compatibilit\xE9\
        \ avec les syst\xE8mes non Windows.\n\nWindows Server 2008 a apport\xE9 le\
        \ support d'algorithmes reposant sur AES (AES128-CTS-HMAC-SHA1-96 et AES256-CTS-HMAC-SHA1-96)\
        \ , ceux-ci ayant \xE9t\xE9 normalis\xE9s et support\xE9s par des syst\xE8\
        mes non Windows.\n\nActuellement, les algorithmes bas\xE9s sur DES (DES-CBC-CRC\
        \ et DES-CBC-MD5) sont consid\xE9r\xE9s comme obsol\xE8tes et doivent \xEA\
        tes d\xE9sactiv\xE9s. De m\xEAme, dans un objectif de durcissement, l'algorithme\
        \ RC4 peut \xEAtre d\xE9sactiv\xE9 ceci entrainant cependant la perte de compatibilit\xE9\
        \ avec les syst\xE8mes ant\xE9rieurs \xE0 Windows Vista et Windows Server\
        \ 2008.\n\n## Seuils de tol\xE9rance\n\nCe point de contr\xF4le pr\xE9sente\
        \ des seuils de tol\xE9rance diff\xE9rents en fonction du niveau de s\xE9\
        curit\xE9 vis\xE9 :\n\n* au niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span> apparaissent les DC/RODC avec les\
        \ algorithmes DES-CBC-CRC ou DES-CBC-MD5 activ\xE9 ;\n* au niveau <span style=\"\
        background-color:rgb(240, 230, 140);color:rgb(0, 0, 0)\">3</span> apparaissent\
        \ les DC/RODC ne supportant pas AES (AES128-CTS-HMAC-SHA1-96 ou AES256-CTS-HMAC-SHA1-96)\
        \ ;\n* au niveau <span style=\"background-color:rgb(0, 123, 255);color:rgb(255,\
        \ 255, 255)\">4</span> apparaissent les DC/RODC avec l'algorithme RC4-HMAC\
        \ activ\xE9."
      annotation: "# Recommandation\n\nLa configuration des algorithmes support\xE9\
        s par un DC/RODC est d\xE9finie dans les options de s\xE9curit\xE9 de la strat\xE9\
        gie de s\xE9curit\xE9 locale (S\xE9curit\xE9 r\xE9seau : Configurer les types\
        \ de chiffrement autoris\xE9s pour Kerberos). Ce param\xE8tre ne doit pas\
        \ \xEAtre modifi\xE9 dans chaque strat\xE9gie de s\xE9curit\xE9 locale des\
        \ DC (risque de d\xE9synchronisation entre les DC). Il est recommand\xE9 de\
        \ modifier ce param\xE8tre dans la GPO \"Default Domain Controller Policy\"\
        \ ou toute autre GPO appliqu\xE9e aux DC.\n\nAu niveau <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">2</span>, il est recommand\xE9 de d\xE9finir\
        \ cette strat\xE9gie et d'activer : RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96\
        \ et \"Futurs types de chiffrement\".\n\nAu niveau <span style=\"background-color:rgb(240,\
        \ 230, 140);color:rgb(0, 0, 0)\">3</span>, il est recommand\xE9 de d\xE9finir\
        \ cette strat\xE9gie et d'activer : AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96\
        \ et \"Futurs types de chiffrement\".\n\nAvant de modifier ce param\xE8tre,\
        \ il est n\xE9cessaire de s'assurer que les contr\xF4leurs de domaine n'\xE9\
        mettent que des TGT ou des tickets de service chiffr\xE9s avec AES128 ou AES256.\
        \ Ceci peut \xEAtre v\xE9rifi\xE9 en regardant, sur chaque DC, les \xE9v\xE8\
        nements 4768 (demande de TGT) et 4769 (demande de ticket de service) dans\
        \ le journal S\xE9curit\xE9. Dans ces deux \xE9v\xE8nements, l'attribut `TicketEncryptionType`\
        \ indique l'algorithme utilis\xE9 par le contr\xF4le de domaine pour chiffrer\
        \ le ticket. Il convient de s'assurer que seuls les types 0x11 (AES128-CTS-HMAC-SHA1-96)\
        \ ou 0x12 (AES256-CTS-HMAC-SHA1-96) sont utilis\xE9s.\n\nLa modification ne\
        \ doit pas \xEAtre faite en \xE9ditant l'attribut LDAP `msDS-SupportedEncryptionTypes`\
        \ directement, mais en passant par une GPO qui doit \xEAtre d\xE9ploy\xE9\
        e sur tous les DC et RODC. Le param\xE8tre se trouve sous :\n\nConsole GPO\n\
        \n* Configuration ordinateur\n  * Param\xE8tres Windows\n    * Param\xE8tres\
        \ de s\xE9curit\xE9\n      * Strat\xE9gies locales\n        * Options de s\xE9\
        curit\xE9\n          * S\xE9curit\xE9 r\xE9seau : Configurer les types de\
        \ chiffrement autoris\xE9s pour Kerberos : RC4-HMAC, AES128-CTS-HMAC-SHA1-96,\
        \ AES256-CTS-HMAC-SHA1-96 et \"Futurs types de chiffrement\""
      implementation_groups:
      - level_4
      translations:
        en:
          name: DC/RODC supported encryption algorithms (Level 4)
          description: '# Vulnerability description


            DC and RODC may use several encryption algorithms for Kerberos tickets
            (DES, RC4, AES). At first, only the RC4 algorithm (RC4-HMAC) was supported
            for Windows systems and DES based algorithms could be enabled to improve
            compatibility with non-Windows systems.


            Windows Server 2008 introduced the support of AES-based algorithms (AES128-CTS-HMAC-SHA1-96
            and AES256-CTS-HMAC-SHA1-96), which had been supported for non-Windows
            systems.


            Today, DES based algorithms (DES-CBC-CRC et DES-CBC-MD5) are considered
            obsolete and must be disabled. Likewise, in a hardening perspective, the
            RC4 algorithm should be disabled, with the side effect the loss of compatibility
            with systems older than Windows Vista and Windows Server 2008.


            ## Alert threshold


            This assessment raises an alert depending on varying thresholds:


            * level <span style="background-color:rgb(255, 165, 0);color:rgb(0, 0,
            0)">2</span> shows DC/RODC with DES-CBC-CRC or DES-CBC-MD5 algorithms
            enabled;

            * level <span style="background-color:rgb(240, 230, 140);color:rgb(0,
            0, 0)">3</span> shows DC/RODC without AES support (AES128-CTS-HMAC-SHA1-96
            or AES256-CTS-HMAC-SHA1-96);

            * level <span style="background-color:rgb(0, 123, 255);color:rgb(255,
            255, 255)">4</span> shows DC/RODC with RC4-HMAC algorithm enabled.'
          annotation: "# Recommended measure\n\nThe configuration of supported encryption\
            \ algorithms for DC/RODC is made in the security options of the local\
            \ security policy (Network Security : Configure encryption types allowed\
            \ for Kerberos). This setting should not be modified manually in each\
            \ DC local security policy (risking desynchronization between DCs). Rather,\
            \ one should edit this setting in the \"Default Domain Controller Policy\"\
            \ GPO, or any other GPO which applies to domain controllers.\n\nAt level\
            \ <span style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\"\
            >2</span>, it is recommended to enable that strategy and check: RC4-HMAC,\
            \ AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and \"Future encryption\
            \ types\".\n\nAt level <span style=\"background-color:rgb(240, 230, 140);color:rgb(0,\
            \ 0, 0)\">3</span>, it is recommended to enable that strategy and check:\
            \ AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and \"Future encryption\
            \ types\".\n\nIt is required to check that domain controllers only emit\
            \ tickets with AES128 or AES256 encryption before editing this setting.\
            \ This can be done by looking at the events 4768 (TGT requests) and 4769\
            \ (service tickets requests) in the Security event log of every DC. In\
            \ those two events, the `TicketEncryptionType` attribute indicates the\
            \ encryption algorithm used by the DC. Only types 0x11 (AES128-CTS-HMAC-SHA1-96)\
            \ or 0x12 (AES256-CTS-HMAC-SHA1-96) should be used.\n\nThe change shall\
            \ not be applied through modifying the `msDS-SupportedEncryptionTypes`\
            \ LDAP attribute directly. Use a GPO that would apply to all DCs and RODCs\
            \ instead. The setting can be found under:\n\nConsole GPO\n\n* Computer\
            \ Configuration\n  * Windows Settings\n    * Security Settings\n     \
            \ * Local Policies\n        * Security Options\n          * S\xE9curit\xE9\
            \ r\xE9seau : Configurer les types de chiffrement autoris\xE9s pour Kerberos\
            \ : RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and \"\
            Future encryption types\""
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_dont_expire-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_dont_expire-l2
      name: Comptes dont le mot de passe n'expire jamais (Niveau 2)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nPlus de 10% des comptes\
        \ poss\xE8dent des mots de passe n'expirant pas. La r\xE9cup\xE9ration d'un\
        \ compte permet \xE0 un individu malveillant de conserver ses droits d'acc\xE8\
        s au domaine sur le long terme."
      annotation: "# Recommandation\n\n## Cas g\xE9n\xE9ral\n\nAfin qu'un renouvellement\
        \ soit impos\xE9 techniquement par l'Active Directory, il est n\xE9cessaire\
        \ que les comptes ne poss\xE8dent pas la propri\xE9t\xE9 <code style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">DONT_EXPIRE</code>. Cette propri\xE9\
        t\xE9 doit \xEAtre supprim\xE9e et le mot de passe \xEAtre chang\xE9.\n\n\
        S'il est contre-productif d'imposer un d\xE9lai d'expiration trop court, il\
        \ convient \xE9galement d'\xE9viter que des mots de passe ne soient jamais\
        \ chang\xE9s. En effet, il est parfois constat\xE9 la pr\xE9sence de comptes\
        \ actifs dont le mot de passe n'a pas chang\xE9 depuis parfois plus de 10\
        \ ans, augmentant la probabilit\xE9 de son exposition, de sa r\xE9utilisation\
        \ ou de sa faiblesse.\n\nAussi, cette exception peut avoir pour effet de mettre\
        \ l'organisme dans la situation de ne jamais pouvoir changer certains mots\
        \ de passe.\n\nEnfin, les comptes utilisateurs d'un Active Directory ne sont\
        \ techniquement pas distinguables de comptes de services non g\xE9r\xE9s (au\
        \ sens gMSA/sMSA). La politique de mot de passe impos\xE9e par le domaine\
        \ peut ainsi \xEAtre soit globale, soit diff\xE9renci\xE9e entre les types\
        \ de comptes utilisateurs non privil\xE9gi\xE9s via le m\xE9canisme des Password\
        \ Settings Object (PSO). Si une dur\xE9e de vie longue des mots de passe est\
        \ tol\xE9r\xE9e par la politique de l'organisme, celle-ci doit \xEAtre explicitement\
        \ d\xE9finie par la politique de mots de passe. La diff\xE9renciation permet\
        \ de maintenir une gestion suivie dans le temps de certaines cat\xE9gories\
        \ de comptes et impose la documentation des exceptions et de leurs proc\xE9\
        dures de changement de mots de passe.\n\nL'usage de la propri\xE9t\xE9 <code\
        \ style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">DONT_EXPIRE</code>\
        \ a g\xE9n\xE9ralement pour cons\xE9quence l'oubli du renouvellement du mot\
        \ de passe de certains comptes d'importance particuli\xE8re, apr\xE8s un incident\
        \ de s\xE9curit\xE9 ou non, voire l\xE9gitime l'installation de produits ou\
        \ l'usage de comptes fonctionnels ayant cette caract\xE9ristique et dont la\
        \ proc\xE9dure de renouvellement risque de ne pas \xEAtre document\xE9e.\n\
        \n## Cas des comptes de service\n\nPour \xEAtre en mesure de changer le mot\
        \ de passe des comptes de service et de pouvoir tracer leur utilisation, il\
        \ est n\xE9cessaire de documenter leur emploi. Un document doit ainsi recenser\
        \ tous les comptes de service et leur utilisation. Il doit contenir pour chaque\
        \ compte de service identifi\xE9 :\n\n* les informations concernant le compte\
        \ (`samAccountName`, description, groupes AD, caract\xE9ristiques, etc.) ;\n\
        * les applications ou les syst\xE8mes qui utilisent ce compte ;\n* la date\
        \ de dernier changement du mot de passe associ\xE9 au compte ;\n* la proc\xE9\
        dure de changement du mot de passe du compte ;\n* une personne ou une \xE9\
        quipe responsable de son cycle de vie."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Accounts with never-expiring passwords (Level 2)
          description: '# Vulnerability description


            More than 10% of accounts have passwords which never expire. Should an
            attacker compromise one of these accounts, he would be able to maintain
            long-term access to the Active Directory domain.'
          annotation: '# Recommended measure


            ## General Case


            In order to make Active Directory enforce periodic password change, accounts
            must not have the <code style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">DONT_EXPIRE</code> flag set. This account flag should then
            be unset, usually by unchecking the "password never expires" option in
            the "Account" tab of the user properties. Their passwords should then
            be rolled immediately.


            While it may be counterproductive to enforce a short password lifespan,
            one should avoid never-changing passwords. Some passwords may have been
            last changed more than 10 years ago, increasing the likelihood of an exposure,
            reuse or weakness.


            Such an exception shall not put the organization at risk of never being
            able to change any specific password.


            Finally, Active Directory user accounts are not technically distinguishable
            from non-managed (non-gMSA/sMSA) service accounts. The domain-enforced
            password policy can either be global or differ on a population category
            basis through the Password Settings Object (PSO) feature. While a long
            password lifespan may be allowed by the organization, this must be explicitly
            reflected by the password policy settings. Diversified password policies
            may help manage passwords of some account categories and ensure proper
            documentation of password change procedures.


            Using the <code style="background-color:rgb(220, 53, 69);color:rgb(255,
            255, 255)">DONT_EXPIRE</code> flag usually results in important accounts
            never having their password change, not rolling those passwords after
            a security breach, or even may legitimize using products or setting up
            shared accounts with such a property, for which no password change procedure
            will be documented.


            ## Service accounts


            In order to be able to change passwords of service accounts and trace
            their usage, it is required to document how they are used. Thus, a list
            of all service accounts and their use must be kept up to date. It must
            include, for each service account:


            * all information about the account (`samAccountName`, description, AD
            group membership, specificities, etc.);

            * applications or systems using that account;

            * the last time its password was changed;

            * a procedure to change its password;

            * a person or a team responsible for its lifecycle.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_guest-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_guest-l2
      name: "Compte Invit\xE9 actif (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLe compte *Invit\xE9\
        * (Guest) est activ\xE9.\n\nLe compte *Invit\xE9* (Guest) permet aux utilisateurs\
        \ r\xE9seau non authentifi\xE9s de se connecter en tant qu' *Invit\xE9* (Guest)\
        \ sans mot de passe. Ces utilisateurs non autoris\xE9s peuvent acc\xE9der\
        \ \xE0 toutes les ressources accessibles au compte *Invit\xE9* (Guest) sur\
        \ le r\xE9seau. Cette fonctionnalit\xE9 signifie que tous les objets ou dossiers\
        \ partag\xE9s avec des autorisations qui autorisent l\u2019acc\xE8s au compte\
        \ *Invit\xE9* (Guest), au groupe *Invit\xE9s du domaine* (Domain Guests),\
        \ au groupe *Invit\xE9s* (Guests), ou au groupe *Tout le monde* (Everyone)\
        \ sont accessibles sur le r\xE9seau, ce qui peut entra\xEEner l\u2019exposition\
        \ ou l\u2019alt\xE9ration des donn\xE9es."
      annotation: "# Recommandation\n\nD\xE9sactiver le compte *Invit\xE9* (Guest)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Guest account enabled (Level 2)
          description: "# Vulnerability description\n\nThe *Guest* (Invit\xE9) account\
            \ is enabled.\n\nThe *Guest* (Invit\xE9) account allows unauthenticated\
            \ network users to log on as a *Guest* (Invit\xE9) with no password. These\
            \ unauthorized users could access any resources that are accessible to\
            \ the *Guest* (Invit\xE9) account over the network. This capability means\
            \ that any objects or shared folders with permissions that allow access\
            \ to the *Guest* (Invit\xE9) account, the *Domain Guests* (Invit\xE9s\
            \ du domaine) group, the *Guests* (Invit\xE9s) group, or the *Everyone*\
            \ (Tout le monde) group are accessible over the network, which could lead\
            \ to the exposure or corruption of data."
          annotation: "# Recommended measure\n\nDisable the *Guest* (Invit\xE9) account."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_kerberos_properties_deskey-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_kerberos_properties_deskey-l2
      name: Comptes utilisateurs avec un chiffrement Kerberos faible (Niveau 2)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa propri\xE9t\xE9\
        \ <code style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\"\
        >USE_DES_KEY_ONLY</code> est positionn\xE9e pour plusieurs utilisateurs. Cette\
        \ propri\xE9t\xE9 autorise les contr\xF4leurs de domaine \xE0 \xE9mettre des\
        \ tickets chiffr\xE9s avec l'algorithme DES, afin d'assurer une compatibilit\xE9\
        \ avec d'anciennes impl\xE9mentations Kerberos. Cet algorithme est consid\xE9\
        r\xE9 comme obsol\xE8te et ne doit plus \xEAtre utilis\xE9. Il diminue grandement\
        \ la robustesse des tickets Kerberos \xE9mis et simplifie les attaques par\
        \ brute force."
      annotation: "# Recommandation\n\nLe support des familles de chiffrement par\
        \ les syst\xE8mes Windows est, dans une configuration par d\xE9faut, le suivant\
        \ :\n\n* Windows XP et Windows Server 2003 : DES et RC4 ;\n* Windows Vista\
        \ et Windows Server 2008 : DES, RC4 et AES ;\n* Windows 7 et Windows Server\
        \ 2008 R2 (et suivants) : RC4 et AES. DES est support\xE9, mais d\xE9sactiv\xE9\
        \ par d\xE9faut.\n\nLa propri\xE9t\xE9 <code style=\"background-color:rgb(220,\
        \ 53, 69);color:rgb(255, 255, 255)\">USE_DES_KEY_ONLY</code> doit \xEAtre\
        \ retir\xE9e de l'attribut `userAccountControl` des comptes. Cette op\xE9\
        ration peut \xEAtre effectu\xE9e directement \xE0 partir de l'onglet \xAB\
        \ Compte \xBB de la console de gestion des utilisateurs et ordinateurs, en\
        \ d\xE9cochant la case \xAB Utiliser uniquement les types de chiffrement DES\
        \ via Kerberos pour ce compte \xBB.\n\nEn cas d'incompatibilit\xE9 avec une\
        \ application, celle-ci doit faire l'objet d'une \xE9volution applicative."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Use of Kerberos with weak encryption (Level 2)
          description: '# Vulnerability description


            The <code style="background-color:rgb(220, 53, 69);color:rgb(255, 255,
            255)">USE_DES_KEY_ONLY</code> flag is set for some users. This flag allows
            domain controllers to issue Kerberos tickets encrypted with the DES algorithm.
            This property was designed for backward compatibility with older Kerberos
            implementations. The DES algorithm is considered weak and must not be
            used anymore. This flag weakens the security of distributed Kerberos tickets
            significantly, and speeds up brute force cracking attempts.'
          annotation: '# Recommended measure


            Default operating system support of cipher groups is as follows:


            * Windows XP and Windows Server 2003: DES and RC4;

            * Windows Vista and Windows Server 2008: DES, RC4 and AES;

            * Windows 7, Windows Server 2008 R2 and later: RC4 and AES. DES is still
            supported but disabled by default.


            The <code style="background-color:rgb(220, 53, 69);color:rgb(255, 255,
            255)">USE_DES_KEY_ONLY</code> flag must be unset from `userAccountControl`
            attribute of each affected account. This can be performed by unchecking
            the "Use Kerberos DES encryption types for this account" options in the
            user account properties.


            Any incompatible software must be upgraded.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_kerberos_properties_preauth-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_kerberos_properties_preauth-l2
      name: "Comptes sans pr\xE9authentification Kerberos (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes n'imposent\
        \ pas la pr\xE9authentification Kerberos. Sans pr\xE9authentification il est\
        \ possible d'obtenir un ticket chiffr\xE9 avec un des secrets associ\xE9s\
        \ au compte correspondant. Il est ensuite possible de lancer une attaque afin\
        \ de retrouver le mot de passe de l'utilisateur, ce qui peut \xEAtre facilit\xE9\
        \ s'il n'est pas assez robuste."
      annotation: "# Recommandation\n\nLa pr\xE9authentification permet de s'assurer\
        \ que l'utilisateur conna\xEEt un de ses secrets d'authentification lors d'une\
        \ demande de TGT (ticket Kerberos obtenu aupr\xE8s d'un contr\xF4leur de domaine).\
        \ Par d\xE9faut, les comptes utilisateur imposent la pr\xE9authentification.\
        \ Cette propri\xE9t\xE9 ne doit jamais \xEAtre positionn\xE9e pour les comptes\
        \ du domaine.\n\n## Cas g\xE9n\xE9ral\n\nLa propri\xE9t\xE9 <code style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">DONT_REQUIRE_PREAUTH</code>\
        \ doit \xEAtre supprim\xE9e pour ces comptes et le mot de passe doit \xEA\
        tre chang\xE9.\n\n## Cas particuliers\n\nEn cas d'incompatibilit\xE9 avec\
        \ une application, celle-ci doit faire l'objet d'une \xE9volution applicative.\
        \ Ce probl\xE8me peut \xEAtre r\xE9duit via les contournements suivants:\n\
        \n* une politique de mot de passe affin\xE9e (Password Settings Object ou\
        \ PSO) s'applique sur le compte avec une longueur de mot de passe sup\xE9\
        rieure \xE0 **32**;\n* une politique de mot de passe affin\xE9e (Password\
        \ Settings Object ou PSO) s'applique sur le compte avec une dur\xE9e d'expiration\
        \ maximale de **3 ans**;\n* le mot de passe du compte a chang\xE9 depuis la\
        \ derni\xE8re modification du PSO ;\n* le compte ne peut utiliser que les\
        \ algorithmes AES."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Kerberos preauthentication disabled (Level 2)
          description: '# Vulnerability description


            Some accounts have Kerberos preauthentication disabled. Without preauthentication,
            it is possible to acquire a ticket encrypted with one of the Kerberos
            keys associated with the requested account. It is then possible to carry
            out a brute force or dictionary guessing attack to crack an account password
            if it is not strong enough.'
          annotation: '# Recommended measure


            Kerberos preauthentication ensures that users requesting a Ticket Granting
            Ticket (TGT) know a given authentication secret. By default, all user
            accounts require preauthentication because their <code style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">DONT_REQUIRE_PREAUTH</code> property
            is not set. That property was designed for backward compatibility with
            older Kerberos implementations.


            ## General Case


            The <code style="background-color:rgb(220, 53, 69);color:rgb(255, 255,
            255)">DONT_REQUIRE_PREAUTH</code> property must be removed from these
            accounts. If an application is not compatible with this change, it must
            be upgraded.


            ## Specific Cases


            Any incompatible software must be upgraded. This issue can be mitigated
            as follows:


            * defining a refined password policy through Password Settings Objects
            (PSO), enforcing a minimum password length of **32** characters;

            * defining a refined password policy through Password Settings Objects
            (PSO), enforcing a maximum expiration duration of **3 years**;

            * changing the affected user passwords after modifying the PSO settings;

            * enforcing AES usage for the affected account.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_krbtgt-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_krbtgt-l2
      name: "Mot de passe du compte krbtgt inchang\xE9 depuis plus d'un an (Niveau\
        \ 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLe mot de passe du\
        \ compte `krbtgt` n'a pas \xE9t\xE9 chang\xE9 depuis plus d'un an.\n\nLe compte\
        \ `krbtgt` est un compte d'infrastructure servant de support de stockage aux\
        \ cl\xE9s des centres de distribution des cl\xE9s Kerberos. La compromission\
        \ du compte `krbtgt` permet \xE0 un attaquant de forger des tickets Kerberos\
        \ (souvent appel\xE9s golden tickets) et ainsi de pouvoir s'authentifier aupr\xE8\
        s de n'importe quelle ressource (serveur, poste de travail, etc.) du domaine\
        \ Active Directory avec des droits d'administration, et ce, de mani\xE8re\
        \ relativement furtive. Le compte `krbtgt` ne changeant pas automatiquement\
        \ de mot de passe, si la base des comptes de l'Active Directory a \xE9t\xE9\
        \ extraite (par exemple par un ancien administrateur, lors d'un audit ou pour\
        \ un test de robustesse des mots de passe), il est possible, tant que ce mot\
        \ de passe n'a pas \xE9t\xE9 chang\xE9, d'utiliser les informations contenues\
        \ dans la base afin d'en extraire les secrets. Une personne malveillante peut\
        \ ainsi s'authentifier sur l'ensemble des services du domaine Active Directory\
        \ plusieurs ann\xE9es apr\xE8s."
      annotation: "# Recommandation\n\nLe compte `krbtgt` est un compte d'infrastructure\
        \ servant de support de stockage aux cl\xE9s des centres de distribution des\
        \ cl\xE9s Kerberos. Afin de renouveler les cl\xE9s Kerberos utilis\xE9es pour\
        \ chiffrer les TGT, il est n\xE9cessaire de proc\xE9der annuellement \xE0\
        \ un changement manuel du mot de passe du compte `krbtgt`. Il est conseill\xE9\
        \ d'effectuer ce changement en utilisant le [script mis \xE0 disposition par\
        \ Microsoft](https://github.com/microsoft/New-KrbtgtKeys.ps1).\n\nLe changement\
        \ de mot de passe doit \xEAtre effectu\xE9 deux fois pour \xEAtre efficace.\n\
        \n<span style=\"background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\"\
        >Attention</span>: toute op\xE9ration de changement du mot de passe du compte\
        \ `krbtgt` doit \xEAtre effectu\xE9e uniquement dans un environnement Active\
        \ Directory o\xF9 la r\xE9plication entre contr\xF4leurs de domaine est nominale.\
        \ Ainsi il est indispensable d'attendre un d\xE9lai avant le deuxi\xE8me changement\
        \ de mot de passe.\n\nIl est \xE9galement possible de r\xE9initialiser manuellement\
        \ le mot de passe du compte `krbtgt`, de la m\xEAme fa\xE7on qu'un compte\
        \ classique. Si le script mis \xE0 disposition n'est pas utilis\xE9, il est\
        \ recommand\xE9 un d\xE9lai d'au minimum 24 heures entre les deux changements\
        \ et de s'assurer de la r\xE9plication effective entre contr\xF4leurs de domaine.\
        \ Une strat\xE9gie peut \xEAtre d'effectuer un unique changement de mot de\
        \ passe tous les 6 mois, afin de garantir un changement effectif annuel."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Krbtgt account password unchanged for more than a year (Level 2)
          description: '# Vulnerability description


            The `krbtgt` account password has not been changed for more than a year.


            The `krbtgt` Kerberos infrastructure account in all Active Directory domains
            is used as a support for key storage in all Kerberos Key Distribution
            Centers (KDC).


            Taking over a `krbtgt` account allows an attacker to forge Kerberos tickets
            of Ticket Granting Ticket (TGT) type (so-called golden tickets), then
            authenticate to any resource (server, workstation, etc.) in the domain
            with full administrative privileges in a more or less stealth manner.


            The `krbtgt` account does not change its password automatically, so if
            the account database was extracted (for instance, by a former administrator,
            during an audit, or for a password strength assessment), it is possible
            to use information from that database to extract the `krbtgt` secrets.
            A malicious user can then compromise all Active Directory services many
            years after the information was extracted.'
          annotation: '# Recommended measure


            The `krbtgt` Kerberos infrastructure account in all Active Directory domains
            is used as a support for key storage in all Kerberos Key Distribution
            Centers (KDC). In order to renew Kerberos keys used to encrypt TGTs, the
            `krbtgt` account must have its password manually changed periodically.
            Using the [Microsoft-provided script is recommended](https://github.com/microsoft/New-KrbtgtKeys.ps1).


            The password change must be carried out twice in a row to effectively
            prevent fraudulent usage of previous passwords (the current and previous
            passwords are both valid at any one time).


            <span style="background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)">Warning</span>:
            any password change operation for the `krbtgt` account must be carried
            out in an Active Directory environment with working, healthy domain controller
            replication. A sufficient delay must be observed between the two consecutive
            password changes for the values to be replicated to all domain controllers.


            The `krbtgt` can be manually rolled, the same way one can force change
            of a user password. If the provided script is not used, a delay of 24
            hours should be observed between the two consecutive password changes
            as well as ensuring replication is properly working between all domain
            controllers. An alternative strategy could be rolling this password only
            once every 6 months, thus ensuring proper revocation of all previous passwords
            every year.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_password_change_server_no_change_90-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_password_change_server_no_change_90-l2
      name: "Serveurs dont le mot de passe de compte d'ordinateur est inchang\xE9\
        \ depuis plus de 90 jours (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes serveurs n'ont\
        \ pas chang\xE9 le mot de passe de leur compte d'ordinateur depuis plus de\
        \ 90 jours, ce qui indique que leurs secrets ne sont pas renouvel\xE9s."
      annotation: "# Recommandation\n\nDans leur fonctionnement par d\xE9faut, les\
        \ serveurs changent automatiquement le mot de passe de leur compte d'ordinateur\
        \ p\xE9riodiquement (30 jours par d\xE9faut). Il convient d'investiguer la\
        \ raison qui emp\xEAche les serveurs de changer leur mot de passe.\n\nUne\
        \ premi\xE8re v\xE9rification consiste \xE0 v\xE9rifier la valeur des entr\xE9\
        es de Registre suivantes :\n\n* `HKLM\\System\\CurrentControlSet\\Services\\\
        Netlogon\\Parameters\\DisablePasswordChange`: doit valoir 0 ou ne pas exister\
        \ ;\n* `HKLM\\System\\CurrentControlSet\\Services\\Netlogon\\Parameters\\\
        MaximumPasswordAge`: doit valoir 30.\n\nSi ces valeurs sont incorrectes, il\
        \ convient de les remettre aux valeurs par d\xE9faut et de s'assurer qu'elles\
        \ ne sont pas positionn\xE9es par une GPO.\n\nSi ces valeurs sont correctes,\
        \ v\xE9rifier si le service `NETLOGON` est d\xE9marr\xE9 avec `sc.exe query\
        \ netlogon`.\n\nEnfin, il faut v\xE9rifier que le mot de passe de la machine\
        \ soit synchronis\xE9 avec celui du compte machine dans l'annuaire. Ceci peut\
        \ \xEAtre v\xE9rifi\xE9 avec la commande `nltest /SC_VERIFY:<DomainName>`,\
        \ o\xF9 `DomainName` correspond au nom NetBIOS du domaine. Dans les deux v\xE9\
        rifications effectu\xE9es, la commande doit indiquer le code de retour `0\
        \ 0x0 NERR_Success`."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Servers with passwords unchanged for more than 90 days (Level 2)
          description: '# Vulnerability description


            Some servers have not changed their passwords for more than 90 days, indicating
            their secrets are not renewed.'
          annotation: '# Recommended measure


            Default server settings have them change their passwords automatically
            every 30 days. The reason for this change not to occur properly must be
            investigated as it may be indicative of a compromise.


            First, check the following registry values:


            * `HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange`:
            must be set to 0 or inexistent;

            * `HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge`:
            must be set to 30.


            Incorrect values should be reset to their default setting, and GPOs must
            be checked to ensure they do not override those.


            If these values are correct, check if the `NETLOGON` service is started
            with `sc.exe query netlogon`.


            Finally, proper synchronization between the machine password and that
            of the machine account in the Active Directory database must be validated.
            Running `nltest /SC_VERIFY:<DomainName>` (with `DomainName` being the
            domain NetBIOS name) can check the synchronization status, and should
            display `0 0x0 NERR_Success` for both verifications.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_password_change_cluster_no_change_3years-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_password_change_cluster_no_change_3years-l2
      name: "Comptes utilis\xE9s dans un cluster de basculement Windows Server dont\
        \ le mot de passe est inchang\xE9 depuis plus de 3 ans (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes utilis\xE9\
        s dans un cluster de basculement Windows Server (appel\xE9s `cluster name\
        \ account`) n'ont pas chang\xE9 leur mot de passe depuis plus de 3 ans."
      annotation: "# Recommandation\n\nIl est recommand\xE9 de proc\xE9der au changement\
        \ du mot de passe des comptes utilis\xE9s dans un cluster de basculement au\
        \ moins tous les 3 ans.\n\nCe changement fait l'objet d'un [processus particulier](https://learn.microsoft.com/fr-fr/windows-server/failover-clustering/configure-ad-accounts#planning-ahead-for-password-resets-and-other-account-maintenance9)\
        \ en fonction de services membres du cluster."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Windows server cluster accounts with passwords unchanged for more
            than 3 years (Level 2)
          description: '# Vulnerability description


            Some computer accounts used in windows server clusters have not changed
            their passwords for more than 3 years, indicating their secrets are not
            renewed.'
          annotation: '# Recommended measure


            It is necessary to renew the password of computers used in windows server
            clusters at least every 3 years.


            The password renewal must follow a Ce changement fait l''objet d''un [specific
            process](https://learn.microsoft.com/fr-fr/windows-server/failover-clustering/configure-ad-accounts#planning-ahead-for-password-resets-and-other-account-maintenance9)
            depending on the cluster members.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_password_change_msa_no_change_90-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_password_change_msa_no_change_90-l2
      name: "Comptes de service manag\xE9s dont le mot de passe de compte est inchang\xE9\
        \ depuis plus de 90 jours (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes de service\
        \ manag\xE9s n'ont pas chang\xE9 le mot de passe de leur compte depuis plus\
        \ de 90 jours, ce qui indique que leurs secrets ne sont pas renouvel\xE9s.\
        \ Les comptes d\xE9sactiv\xE9s ne sont pas consid\xE9r\xE9s."
      annotation: "# Recommandation\n\nDans leur fonctionnement par d\xE9faut, les\
        \ comptes de service manag\xE9s changent automatiquement le mot de passe de\
        \ leur compte p\xE9riodiquement (30 jours par d\xE9faut). Il convient d'investiguer\
        \ la raison qui emp\xEAche les serveurs de changer leur mot de passe.\n\n\
        Une premi\xE8re v\xE9rification consiste \xE0 v\xE9rifier la valeur des entr\xE9\
        es de Registre suivantes :\n\n* `HKLM\\System\\CurrentControlSet\\Services\\\
        Netlogon\\Parameters\\DisablePasswordChange`: doit valoir 0 ou ne pas exister\
        \ ;\n* `HKLM\\System\\CurrentControlSet\\Services\\Netlogon\\Parameters\\\
        MaximumPasswordAge`: doit valoir 30.\n\nSi ces valeurs sont incorrectes, il\
        \ convient de les remettre aux valeurs par d\xE9faut et de s'assurer qu'elles\
        \ ne sont pas positionn\xE9es par une GPO."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Managed service accounts with passwords unchanged for more than 90
            days (Level 2)
          description: '# Vulnerability description


            Some managed service accounts have not changed their passwords for more
            than 90 days, indicating their secrets are not renewed. Disabled service
            accounts are not taken into account.'
          annotation: '# Recommended measure


            Default managed service Accounts settings have them change their passwords
            automatically every 30 days. The reason for this change not to occur properly
            must be investigated as it may be indicative of a compromise.


            First, check the following registry values:


            * `HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange`:
            must be set to 0 or inexistent;

            * `HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge`:
            must be set to 30.


            Incorrect values should be reset to their default setting, and GPOs must
            be checked to ensure they do not override those.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_permissions_gpo_container_priv-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_permissions_gpo_container_priv-l2
      name: "Permissions dangereuses sur des conteneurs d'objets privil\xE9gi\xE9\
        s (chemins de contr\xF4le) (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes permissions dangereuses\
        \ existent sur des conteneurs (sites et OU) contenant des membres des groupes\
        \ privil\xE9gi\xE9s. Un attaquant ayant le contr\xF4le sur ces conteneurs\
        \ pourrait lier une GPO \xE0 cet emplacement et ainsi ex\xE9cuter du code\
        \ sur les machines utilis\xE9es par ces membres et \xE9lever ses privil\xE8\
        ges.\n\nL\xE9gende: Contr\xF4le fort et imm\xE9diat, Contr\xF4le indirect,\
        \ Contr\xF4le indirect faible\n\n# Permissions dangereuses et chemins de contr\xF4\
        le\n\nDes permissions dangereuses permettent la prise de contr\xF4le d'un\
        \ objet cible, sur lequel ces permissions sont positionn\xE9es, par l'\xE9\
        criture de propri\xE9t\xE9s sensibles, par d\xE9l\xE9gation de droits privil\xE9\
        gi\xE9s ou par l'usage de fonctionnalit\xE9s sp\xE9cifiques.\n\nUne fois l'objet\
        \ ma\xEEtris\xE9 par un attaquant, ce dernier peut alors poursuivre un chemin\
        \ de prise de contr\xF4le d'autres objets qui, par transitivit\xE9, peut mener\
        \ \xE0 des \xE9l\xE9vations de privil\xE8ges et \xE0 la compromission de l'annuaire\
        \ Active Directory tout entier. L'encha\xEEnement de permissions dangereuses\
        \ ainsi exploit\xE9es s'appelle un ***chemin de contr\xF4le** , ou un chemin\
        \ d'attaque* (Un chemin de contr\xF4le est compos\xE9 d'un ensemble de relations\
        \ de contr\xF4le direct, o\xF9 chaque relation traduit la ma\xEEtrise d'un\
        \ objet sur un autre au travers d'une propri\xE9t\xE9 particuli\xE8re.).\n\
        \nAinsi, les chemins de contr\xF4le repr\xE9sentent des moyens pour un attaquant\
        \ d'atteindre des cibles, et permettent d'identifier des d\xE9viances dans\
        \ la gestion du domaine, de valider l'application d'un p\xE9rim\xE8tre de\
        \ s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9galement de\
        \ r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant apr\xE8\
        s une compromission.\n\n## Visualisation\n\nIl est possible de visualiser\
        \ les chemins de contr\xF4le qui permettent la compromission totale de la\
        \ for\xEAt via l'onglet d\xE9di\xE9 de ce rapport, en [cliquant ici](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)."
      annotation: "# Recommandation\n\nIl recommand\xE9 d'enlever les permissions\
        \ dangereuses sur ces conteneurs afin de revenir \xE0 un \xE9tat par d\xE9\
        faut. La correction est g\xE9n\xE9ralement effectu\xE9e \xE0 l'aide du composant\
        \ logiciel enfichable `ADSI Edit` ou de l'utilitaire `ldp`.\n\n## Contexte\
        \ : chemins de contr\xF4le\n\nUn chemin de contr\xF4le est compos\xE9 d'un\
        \ ensemble de relations de contr\xF4le direct, o\xF9 chaque relation traduit\
        \ la ma\xEEtrise d'un objet sur un autre au travers d'une propri\xE9t\xE9\
        \ particuli\xE8re. Ainsi, les chemins de contr\xF4le repr\xE9sentent des moyens\
        \ pour un attaquant d'atteindre des cibles, et permettent d'identifier des\
        \ d\xE9viances dans la gestion du domaine, de valider l'application d'un p\xE9\
        rim\xE8tre de s\xE9curit\xE9 autour des cibles consid\xE9r\xE9es, mais \xE9\
        galement de r\xE9v\xE9ler des moyens de persistance laiss\xE9s par un attaquant\
        \ apr\xE8s une compromission.\n\n## Limites\n\nCertains chemins de contr\xF4\
        le peuvent disposer de correctifs qui les rendent non exploitables. Ces cas\
        \ imposent g\xE9n\xE9ralement d'avoir l'ensemble des contr\xF4leurs de domaine\
        \ au m\xEAme niveau de mise \xE0 jour. De plus, les fonctionnalit\xE9s dangereuses\
        \ peuvent parfois \xEAtre r\xE9activ\xE9es par un param\xE8tre de registre\
        \ ou dsHeuristics. Il est donc toujours recommand\xE9 de nettoyer les permissions\
        \ concern\xE9es de l'Active Directory pour pr\xE9venir une r\xE9apparition\
        \ du probl\xE8me.\n\nListe des correctifs sp\xE9cifiques connus :\n\n* [KB5008383](https://support.microsoft.com/fr-fr/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)\
        \ corrige les chemins de contr\xF4le de type <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">OWNER</span> et <span style=\"background-color:rgb(255,\
        \ 165, 0);color:rgb(0, 0, 0)\">WRITE_OWNER</span> sur des comptes machines\
        \ uniquement, mais le comportement dangereux peut \xEAtre r\xE9activ\xE9.\n\
        * Divers chemins de contr\xF4le relatifs \xE0 Exchange Server ont \xE9t\xE9\
        \ corrig\xE9s par des mises \xE0 jour cumulatives sp\xE9cifiques ; se r\xE9\
        f\xE9rer \xE0 l'encart d\xE9di\xE9 si pertinent.\n\n## Acceptation du risque\n\
        \nSi des permissions sp\xE9cifiques sont n\xE9cessaires, il convient de consid\xE9\
        rer que les comptes ou les groupes d\xE9l\xE9gu\xE9s sont eux-m\xEAmes privil\xE9\
        gi\xE9s. Ainsi, ils doivent \xEAtre correctement prot\xE9g\xE9s et leurs permissions\
        \ appliqu\xE9es doivent \xEAtre au moins aussi restrictives que celles appliqu\xE9\
        es \xE0 l' `adminSDHolder`. Il est donc n\xE9cessaire de leur appliquer des\
        \ permissions \"s\xE9curis\xE9es\". Pour cela, il est recommand\xE9 d'utiliser\
        \ la commande ``Set-ADSyncRestrictedPermissions`` du module `AdSyncConfig.psm1`\
        \ fourni avec Azure AD Connect. Cette commande supprime l'h\xE9ritage et applique\
        \ des permissions (ACE) restreintes. Pour un groupe d\xE9l\xE9gu\xE9, l'application\
        \ de cette seule commande n'est pas suffisante : il faut \xE9galement retirer\
        \ les membres du groupe, ou les consid\xE9rer eux-m\xEAmes comme \xE9tant\
        \ privil\xE9gi\xE9e en leur appliquant la m\xEAme commande.\n\nExemple d'utilisation\
        \ de ``Set-ADSyncRestrictedPermissions`` pour appliquer des permissions \"\
        s\xE9curis\xE9es\" sur un compte privil\xE9gi\xE9 :\n\n```powershell\nImport-Module\
        \ .\\AdSyncConfig.psm1\n$credential = Get-Credential\nSet-ADSyncRestrictedPermissions\
        \ -ADConnectorAccountDN \"CN=ExampleUserAccount,CN=Users,DC=example,DC=ads\"\
        \ -Credential $credential\n```\n\nNote : le module `AdSyncConfig.psm1` peut\
        \ \xEAtre directement extrait du fichier d'installation d'Azure AD Connect\
        \ \xE0 l'aide de l'utilitaire int\xE9gr\xE9 `msiexec`: `msiexec /a \"AzureADConnect.msi\"\
        \ /qb TARGETDIR=c:\\temp\\`\n\nLe paquet d'installation peut \xEAtre t\xE9\
        l\xE9charg\xE9 \xE0 l'adresse suivante : [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Dangerous ACLs expose privileged object containers (attack path) (Level
            2)
          description: '# Vulnerability description


            Dangerous ACLs expose containers (sites and OU) that contain privileged
            group members. An attacker gaining access to these containers may link
            a GPO to it and therefore execute code on those privilege account workstations
            to escalate their privileges.


            Legend: Strong and immediate control, Indirect control, Weak indirect
            control


            # Dangerous ACLs and attack paths


            Dangerous permissions allow taking control of a target object, on which
            those permissions are set, by writing sensitive attributes, privileged
            right delegation or through specific features.


            Once granted control of privileged objects, an attacker may then repeat
            the same strategy to gain control of other objects, leading to privilege
            escalation and possibly a full Active Directory compromise. The succession
            of exploited permissions constitutes an ***attack path** or a control
            path* (A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting.).


            Control paths reveal how an attacker could leverage a chain of defective
            or dangerous permissions to gain control of some targets. They can also
            be leveraged to quickly identify domain mismanagement, to validate the
            actual security boundary of a particular scope (making sure some object
            of interest cannot be taken over by unauthorized users through misconfiguration).
            Indicators of compromise may also be found through control path review.


            ## Visualizing


            Effective control paths that lead to a full compromise at the forest level
            can be visualized through the dedicated tab of this report. [Click here](https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#/ad/controlgraph)
            to view control paths for the current forest.'
          annotation: '# Recommended measure


            Access rights on those containers need to be carefully reviewed or reverted
            to their default state. The fix is usually applied through the `adsiedit.msc`
            or `ldp` utilities.


            ## Context: control path exposure


            A control path materializes through a set of granted access permissions:
            each granted permission can be expressed as one object controlling another
            through a specific property, attribute or setting. Control paths reveal
            how an attacker could leverage a chain of defective or dangerous permissions
            to gain control of some targets. They can also be leveraged to quickly
            identify domain mismanagement, to validate the actual security boundary
            of a particular scope (making sure some object of interest cannot be taken
            over by unauthorized users through misconfiguration). Indicators of compromise
            may also be found through control path review.


            ## Limitations


            Some control paths may have fixes that renders them non-exploitable. Such
            a case usually requires having all domain controllers equally up to date.
            Furthermore, dangerous features may sometimes be re-enabled through a
            registry or dsHeuristics setting. It is therefore still recommended to
            clean the affected permissions from your Active Directory to prevent an
            accidental re-occurrence.


            List of known specific fixes:


            * [KB5008383](https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1)
            fixes the <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">OWNER</span> and <span style="background-color:rgb(255, 165, 0);color:rgb(0,
            0, 0)">WRITE_OWNER</span> control path on computer accounts only, but
            the dangerous behavior can still be re-enabled.

            * Various Exchange-related control paths have been fixed through specific
            cumulative updates; refer to the dedicated section below if applicable.


            ## Risk Acceptance


            If special permissions are required, delegated groups or accounts should
            be considered as privileged. Therefore, they must comply with appropriate
            protection measures, and their own access control list should be at least
            as strict as that of the `adminSDHolder` object. "Secure" ACLs should
            therefore be implemented on these delegated groups, which will not open
            a new control path exposure. To remove inheritance and restrict ACEs,
            the following command may be used: ``Set-ADSyncRestrictedPermissions``
            found in the `AdSyncConfig.psm1` module from Azure AD Connect. For delegated
            groups, strengthening permissions using this command is not enough: the
            permissions of this group''s members must also be strengthened by applying
            this command to them, or they can be removed from the delegated group.


            Example: applying "secure" permission on a privileged account through
            ``Set-ADSyncRestrictedPermissions``:


            ```powershell

            Import-Module .\AdSyncConfig.psm1

            $credential = Get-Credential

            Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads"
            -Credential $credential

            ```


            Note: the `AdSyncConfig.psm1` module may be extracted from the Azure AD
            Connect installer with `msiexec`: `msiexec /a "AzureADConnect.msi" /qb
            TARGETDIR=c:\temp\`


            The installation package may be downloaded from [https://go.microsoft.com/fwlink/?LinkId=615771](https://go.microsoft.com/fwlink/?LinkId=615771).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_privileged_members_password-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_privileged_members_password-l2
      name: "Comptes membres de groupes privil\xE9gi\xE9s avec une mauvaise politique\
        \ de mot de passe (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nUne politique de mot\
        \ de passe faible est impos\xE9e \xE0 des comptes privil\xE9gi\xE9s."
      annotation: "# Recommandation\n\nIl est recommand\xE9 d'appliquer une politique\
        \ de mot de passe pour les comptes privil\xE9gi\xE9s avec :\n\n* un renouvellement\
        \ au maximum tous les 3 ans ;\n* une longueur d'au moins 8 caract\xE8res.\n\
        \nNote importante : il est d\xE9conseill\xE9 de forcer un renouvellement trop\
        \ fr\xE9quent (quelques mois). Une demande de renouvellement trop fr\xE9quente\
        \ induit statistiquement un nouveau choix de mot de passe plus faible, ce\
        \ qui en fait une mesure de s\xE9curit\xE9 contre-productive.\n\n## Contexte\
        \ : groupes privil\xE9gi\xE9s\n\nLes groupes privil\xE9gi\xE9s sont les groupes\
        \ d'administration et les groupes op\xE9ratifs ayant tous les droits et privil\xE8\
        ges sur la for\xEAt ou pouvant se les attribuer :\n\n* \xAB *Administrateurs*\
        \ (Administrators) \xBB ;\n* \xAB *Contr\xF4leurs de domaine* (Domain Controllers)\
        \ \xBB;\n* \xAB *Administrateurs du sch\xE9ma* (Schema Admins) \xBB ;\n* \xAB\
        \ *Administrateurs de l'entreprise* (Enterprise Admins) \xBB ;\n* \xAB *Administrateurs\
        \ du domaine* (Domain Admins) \xBB : ces administrateurs ont les privil\xE8\
        ges de lire la base des secrets de tous les comptes et donc d'extraire les\
        \ secrets de l'ensemble des comptes privil\xE9gi\xE9s ;\n* \xAB *Administrateurs\
        \ de cl\xE9s* (Key Admins) \xBB et \xAB *Administrateurs de cl\xE9s de l'entreprise*\
        \ (Enterprise Key Admins) \xBB: ces administrateurs peuvent fixer des valeurs\
        \ arbitraires aux attributs relatifs \xE0 Windows Hello for Business, pour\
        \ tous les utilisateurs sauf ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`.\
        \ Si l'authentification bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9\
        e, ils peuvent g\xE9n\xE9rer un certificat sous leur contr\xF4le, l'assigner\
        \ \xE0 un compte privil\xE9gi\xE9 (par exemple, un contr\xF4leur de domaine),\
        \ et s'authentifier en tant que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer tous les comptes\
        \ d'utilisateurs, machines et groupes; \xE0 l'exception des comptes prot\xE9\
        g\xE9s par l' `adminSDHolder`;\n* \xAB *Op\xE9rateurs de serveur* (Server\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer les contr\xF4leurs\
        \ de domaine, et donc r\xE9cup\xE9rer les secrets de tous les comptes privil\xE9\
        gi\xE9s ;\n* \xAB *Op\xE9rateurs de sauvegarde* (Backup Operators) \xBB :\
        \ ces op\xE9rateurs peuvent sauvegarder un contr\xF4leur de domaine et donc\
        \ extraire les secrets de tous les comptes privil\xE9gi\xE9s depuis cette\
        \ sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression* (Print Operators) \xBB\
        \ : ces op\xE9rateurs peuvent charger des pilotes d'impression sur les contr\xF4\
        leurs de domaine et donc charger un pilote malveillant pour par exemple extraire\
        \ les secrets de tous les comptes privil\xE9gi\xE9s.\n\nLes groupes \xAB op\xE9\
        rateurs \xBB sont vides par d\xE9faut et ne devraient contenir aucun membre."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Privileged group members with weak password policy (Level 2)
          description: '# Vulnerability description


            Some privileged accounts have a weak password policy enforced.'
          annotation: '# Recommended measure


            For privileged accounts, enforcing a password policy with the following
            requirements is recommended:


            * forced change at most every 3 years;

            * length of 8 or more characters.


            Important note: passwords should not be renewed too often. Enforcing short
            password lifespans compels users to choose statistically weaker passwords,
            which negates the intended benefits.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_privileged_members_no_admincount-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_privileged_members_no_admincount-l2
      name: "Comptes membres de groupes privil\xE9gi\xE9s ayant un attribut adminCount\
        \ vide ou valant 0 (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLorsqu'un compte devient\
        \ membre d'un groupe privi\xE9lgi\xE9, son descripteur de s\xE9curit\xE9 est\
        \ repris de celui de l' `adminSDHolder` et son attribut `adminCount` est positionn\xE9\
        \ \xE0 1. Par la suite le contr\xF4leur de domaine ayant le r\xF4le PDCe v\xE9\
        rifie de mani\xE8re r\xE9guli\xE8re le descripteur de s\xE9curit\xE9 des comptes\
        \ privil\xE9gi\xE9s.\n\nLa pr\xE9sence d'un attribut `adminCount` vide ou\
        \ valant 0 pour un compte membre d'un groupe privil\xE9gi\xE9 r\xE9v\xE8le\
        \ donc d'une modification explicite de cet attribut. Ceci peut t\xE9moigner\
        \ d'une volont\xE9 de mettre en d\xE9faut l'analyse d'outils de s\xE9curit\xE9\
        .\n\nDes groupes privil\xE9gi\xE9s de la for\xEAt contiennent des comptes\
        \ ayant un attribut `adminCount` vide ou valant 0 :"
      annotation: "# Recommandation\n\nIl est recommand\xE9 d'identifier la raison\
        \ pour laquelle l'attribut `adminCount` des comptes list\xE9s a \xE9t\xE9\
        \ modifi\xE9.\n\nPar la suite, il est n\xE9cessaire de repositionner cet attribut\
        \ \xE0 la valeur `1`.\n\n## Contexte : groupes privil\xE9gi\xE9s\n\nLes groupes\
        \ privil\xE9gi\xE9s sont les groupes d'administration et les groupes op\xE9\
        ratifs ayant tous les droits et privil\xE8ges sur la for\xEAt ou pouvant se\
        \ les attribuer :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n* \xAB\
        \ *Contr\xF4leurs de domaine* (Domain Controllers) \xBB;\n* \xAB *Administrateurs\
        \ du sch\xE9ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs de l'entreprise*\
        \ (Enterprise Admins) \xBB ;\n* \xAB *Administrateurs du domaine* (Domain\
        \ Admins) \xBB : ces administrateurs ont les privil\xE8ges de lire la base\
        \ des secrets de tous les comptes et donc d'extraire les secrets de l'ensemble\
        \ des comptes privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de cl\xE9s* (Key\
        \ Admins) \xBB et \xAB *Administrateurs de cl\xE9s de l'entreprise* (Enterprise\
        \ Key Admins) \xBB: ces administrateurs peuvent fixer des valeurs arbitraires\
        \ aux attributs relatifs \xE0 Windows Hello for Business, pour tous les utilisateurs\
        \ sauf ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`. Si l'authentification\
        \ bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9e, ils peuvent g\xE9n\xE9\
        rer un certificat sous leur contr\xF4le, l'assigner \xE0 un compte privil\xE9\
        gi\xE9 (par exemple, un contr\xF4leur de domaine), et s'authentifier en tant\
        \ que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account Operators) \xBB : ces\
        \ op\xE9rateurs peuvent administrer tous les comptes d'utilisateurs, machines\
        \ et groupes; \xE0 l'exception des comptes prot\xE9g\xE9s par l' `adminSDHolder`;\n\
        * \xAB *Op\xE9rateurs de serveur* (Server Operators) \xBB : ces op\xE9rateurs\
        \ peuvent administrer les contr\xF4leurs de domaine, et donc r\xE9cup\xE9\
        rer les secrets de tous les comptes privil\xE9gi\xE9s ;\n* \xAB *Op\xE9rateurs\
        \ de sauvegarde* (Backup Operators) \xBB : ces op\xE9rateurs peuvent sauvegarder\
        \ un contr\xF4leur de domaine et donc extraire les secrets de tous les comptes\
        \ privil\xE9gi\xE9s depuis cette sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression*\
        \ (Print Operators) \xBB : ces op\xE9rateurs peuvent charger des pilotes d'impression\
        \ sur les contr\xF4leurs de domaine et donc charger un pilote malveillant\
        \ pour par exemple extraire les secrets de tous les comptes privil\xE9gi\xE9\
        s.\n\nLes groupes \xAB op\xE9rateurs \xBB sont vides par d\xE9faut et ne devraient\
        \ contenir aucun membre."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Privileged groups members having an adminCount attribute which is
            null or 0 (Level 2)
          description: '# Vulnerability description


            When an account becomes member of a privileged group, its security descriptor
            is copied from the `adminSDHolder` and the `adminCount` attribute is set
            to 1. Then, the domain controller having the PDCe role verify the security
            descriptor of protected accounts on a regular basis.


            A member of a privileged group having an `adminCount` attribute that is
            empty or 0 is the result of an intentional modification of this attribute.
            This could aim at hiding the account from security tools.


            Privileged groups in the forest contain accounts having an `adminCount`
            attribute which is null or 0:'
          annotation: "# Recommended measure\n\nIt is recommended to explain why the\
            \ `adminCount` attribute has been changed for the listed accounts.\n\n\
            Then, it is necessary to set the attribute to the value `1`.\n\nThe \xAB\
            \ operators \xBB groups are empty by default and must not have any member.\n\
            \n## Context: privileged groups\n\nPrivileged groups include administrator\
            \ groups and operator groups which have full control over the Active Directory\
            \ forest either by design, or by granting themselves such privileges:\n\
            \n* \xAB *Administrators* (Administrateurs) \xBB;\n* \xAB *Domain Controllers*\
            \ (Contr\xF4leurs de domaine) \xBB;\n* \xAB *Schema Admins* (Administrateurs\
            \ du sch\xE9ma) \xBB;\n* \xAB *Enterprise Admins* (Administrateurs de\
            \ l'entreprise) \xBB;\n* \xAB *Domain Admins* (Administrateurs du domaine)\
            \ \xBB: these administrators are able to read the authentication database\
            \ and extract password hashes and other secrets of all privileged accounts;\n\
            * \xAB *Key Admins* (Administrateurs de cl\xE9s) \xBB and \xAB *Enterprise\
            \ Key Admins* (Administrateurs de cl\xE9s de l'entreprise) \xBB: these\
            \ administrators can set arbitrary values to attributes relating to Windows\
            \ Hello for Business, for all users except those protected by the `adminSDHolder`\
            \ mechanism. If certificate-based authentication has been enabled, they\
            \ can generate a certificate that they control, assign it to privileged\
            \ accounts (for instance, a domain controller), and log on as them;\n\
            * \xAB *Account Operators* (Op\xE9rateurs de compte) \xBB: these operators\
            \ can manage user accounts, machine accounts and groups except accounts\
            \ protected by the `adminSDHolder` mechanism;\n* \xAB *Server Operators*\
            \ (Op\xE9rateurs de serveur) \xBB: these operators can manage domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database;\n* \xAB *Backup Operators* (Op\xE9\
            rateurs de sauvegarde) \xBB: these operators can back up a domain controller,\
            \ which grants them the ability to recover privileged user secrets from\
            \ that backup;\n* \xAB *Print Operators* (Op\xE9rateurs d'impression)\
            \ \xBB: these operators can load arbitrary printer drivers on domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_rodc_priv_revealed-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_rodc_priv_revealed-l2
      name: "Comptes ou groupes privil\xE9gi\xE9s r\xE9v\xE9l\xE9s par des RODC (Niveau\
        \ 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes privil\xE9\
        gi\xE9s ont \xE9t\xE9 r\xE9v\xE9l\xE9s sur des RODC, ce qui signifie que leurs\
        \ secrets d'authentification y sont mis en cache. Une compromission de ces\
        \ machines (g\xE9n\xE9ralement plus expos\xE9es que des contr\xF4leurs de\
        \ domaine classiques) permet de compromettre l'int\xE9gralit\xE9 du domaine."
      annotation: "# Recommandation\n\nLes RODC conservent, entre autres, une copie\
        \ d'une partie des secrets du domaine. Par d\xE9faut, les comptes membres\
        \ de groupes privil\xE9gi\xE9s ne sont pas r\xE9v\xE9l\xE9s (c'est-\xE0-dire\
        \ copi\xE9s) sur les RODC. Cette mesure permet de limiter l'impact d'un acc\xE8\
        s malveillant aux seuls comptes r\xE9v\xE9l\xE9s sur les RODC. Les utilisateurs\
        \ privil\xE9gi\xE9s ne doivent donc pas \xEAtre r\xE9v\xE9l\xE9s sur les RODC.\n\
        \nPour cela, les contr\xF4leurs de domaine en lecture seule (RODC) doivent\
        \ comporter dans l'attribut `msDS-NeverRevealGroup` au minimum les valeurs\
        \ suivantes :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n* \xAB\
        \ *Administrateurs du domaine* (Domain Admins) \xBB ;\n* \xAB *Op\xE9rateurs\
        \ de compte* (Account Operators) \xBB ;\n* \xAB *Op\xE9rateurs de serveur*\
        \ (Server Operators) \xBB ;\n* \xAB *Op\xE9rateurs de sauvegarde* (Backup\
        \ Operators) \xBB ;\n* \xAB *Groupe de r\xE9plication de mot de passe RODC\
        \ refus\xE9e* (Denied RODC Password Replication Group) \xBB.\n\nCette op\xE9\
        ration peut \xEAtre effectu\xE9e directement \xE0 partir de l'onglet \xAB\
        \ Strat\xE9gie de r\xE9plication de mot de passe \xBB de la console de gestion\
        \ des utilisateurs et ordinateurs.\n\n## Contexte : groupes privil\xE9gi\xE9\
        s\n\nLes groupes privil\xE9gi\xE9s sont les groupes d'administration et les\
        \ groupes op\xE9ratifs ayant tous les droits et privil\xE8ges sur la for\xEA\
        t ou pouvant se les attribuer :\n\n* \xAB *Administrateurs* (Administrators)\
        \ \xBB ;\n* \xAB *Contr\xF4leurs de domaine* (Domain Controllers) \xBB;\n\
        * \xAB *Administrateurs du sch\xE9ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs\
        \ de l'entreprise* (Enterprise Admins) \xBB ;\n* \xAB *Administrateurs du\
        \ domaine* (Domain Admins) \xBB : ces administrateurs ont les privil\xE8ges\
        \ de lire la base des secrets de tous les comptes et donc d'extraire les secrets\
        \ de l'ensemble des comptes privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de\
        \ cl\xE9s* (Key Admins) \xBB et \xAB *Administrateurs de cl\xE9s de l'entreprise*\
        \ (Enterprise Key Admins) \xBB: ces administrateurs peuvent fixer des valeurs\
        \ arbitraires aux attributs relatifs \xE0 Windows Hello for Business, pour\
        \ tous les utilisateurs sauf ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`.\
        \ Si l'authentification bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9\
        e, ils peuvent g\xE9n\xE9rer un certificat sous leur contr\xF4le, l'assigner\
        \ \xE0 un compte privil\xE9gi\xE9 (par exemple, un contr\xF4leur de domaine),\
        \ et s'authentifier en tant que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer tous les comptes\
        \ d'utilisateurs, machines et groupes; \xE0 l'exception des comptes prot\xE9\
        g\xE9s par l' `adminSDHolder`;\n* \xAB *Op\xE9rateurs de serveur* (Server\
        \ Operators) \xBB : ces op\xE9rateurs peuvent administrer les contr\xF4leurs\
        \ de domaine, et donc r\xE9cup\xE9rer les secrets de tous les comptes privil\xE9\
        gi\xE9s ;\n* \xAB *Op\xE9rateurs de sauvegarde* (Backup Operators) \xBB :\
        \ ces op\xE9rateurs peuvent sauvegarder un contr\xF4leur de domaine et donc\
        \ extraire les secrets de tous les comptes privil\xE9gi\xE9s depuis cette\
        \ sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression* (Print Operators) \xBB\
        \ : ces op\xE9rateurs peuvent charger des pilotes d'impression sur les contr\xF4\
        leurs de domaine et donc charger un pilote malveillant pour par exemple extraire\
        \ les secrets de tous les comptes privil\xE9gi\xE9s.\n\nLes groupes \xAB op\xE9\
        rateurs \xBB sont vides par d\xE9faut et ne devraient contenir aucun membre."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Privileged users revealed on RODC (Level 2)
          description: '# Vulnerability description


            Some privileged accounts have been revealed on some RODCs, which means
            their authentication secrets are cached there. If those RODCs are compromised
            (they are usually more exposed than regular DCs), the full domain may
            be at risk.'
          annotation: "# Recommended measure\n\nRODCs cache some domain authentication\
            \ secrets. Members of privileged groups are not revealed (i.e. cached)\
            \ on RODCs by default. This helps restrict malicious access only to accounts\
            \ which are revealed. Privileged users should not be revealed on RODCs\
            \ to prevent compromise.\n\nRODCs must therefore include the following\
            \ objects in their `msDS-NeverRevealGroup` attribute:\n\n* \xAB *Administrators*\
            \ (Administrateurs) \xBB ;\n* \xAB *Domain Admins* (Administrateurs du\
            \ domaine) \xBB ;\n* \xAB *Account Operators* (Op\xE9rateurs de compte)\
            \ \xBB ;\n* \xAB *Server Operators* (Op\xE9rateurs de serveur) \xBB ;\n\
            * \xAB *Backup Operators* (Op\xE9rateurs de sauvegarde) \xBB ;\n* \xAB\
            \ *Denied RODC Password Replication Group* (Groupe de r\xE9plication de\
            \ mot de passe RODC refus\xE9e) \xBB.\n\nThis can be done through the\
            \ \"Password Replication Policy\" tab of each RODC computer account properties\
            \ window.\n\nThe \xAB operators \xBB groups are empty by default and must\
            \ not have any member.\n\n## Context: privileged groups\n\nPrivileged\
            \ groups include administrator groups and operator groups which have full\
            \ control over the Active Directory forest either by design, or by granting\
            \ themselves such privileges:\n\n* \xAB *Administrators* (Administrateurs)\
            \ \xBB;\n* \xAB *Domain Controllers* (Contr\xF4leurs de domaine) \xBB\
            ;\n* \xAB *Schema Admins* (Administrateurs du sch\xE9ma) \xBB;\n* \xAB\
            \ *Enterprise Admins* (Administrateurs de l'entreprise) \xBB;\n* \xAB\
            \ *Domain Admins* (Administrateurs du domaine) \xBB: these administrators\
            \ are able to read the authentication database and extract password hashes\
            \ and other secrets of all privileged accounts;\n* \xAB *Key Admins* (Administrateurs\
            \ de cl\xE9s) \xBB and \xAB *Enterprise Key Admins* (Administrateurs de\
            \ cl\xE9s de l'entreprise) \xBB: these administrators can set arbitrary\
            \ values to attributes relating to Windows Hello for Business, for all\
            \ users except those protected by the `adminSDHolder` mechanism. If certificate-based\
            \ authentication has been enabled, they can generate a certificate that\
            \ they control, assign it to privileged accounts (for instance, a domain\
            \ controller), and log on as them;\n* \xAB *Account Operators* (Op\xE9\
            rateurs de compte) \xBB: these operators can manage user accounts, machine\
            \ accounts and groups except accounts protected by the `adminSDHolder`\
            \ mechanism;\n* \xAB *Server Operators* (Op\xE9rateurs de serveur) \xBB\
            : these operators can manage domain controllers, which grants them the\
            \ ability to recover privileged user secrets directly from the authentication\
            \ database;\n* \xAB *Backup Operators* (Op\xE9rateurs de sauvegarde) \xBB\
            : these operators can back up a domain controller, which grants them the\
            \ ability to recover privileged user secrets from that backup;\n* \xAB\
            \ *Print Operators* (Op\xE9rateurs d'impression) \xBB: these operators\
            \ can load arbitrary printer drivers on domain controllers, which grants\
            \ them the ability to recover privileged user secrets directly from the\
            \ authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_sidhistory_dangerous-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_sidhistory_dangerous-l2
      name: Comptes ou groupes ayant un historique de SID d'apparence non conforme
        (Niveau 2)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nPlusieurs comptes ou\
        \ groupes de la for\xEAt poss\xE8dent un attribut `sIDHistory` ayant la valeur\
        \ d'un well-known SID (SID des utilisateurs et groupes g\xE9n\xE9riques) ou\
        \ d'un SID privil\xE9gi\xE9 de domaine. Ce m\xE9canisme peut \xEAtre utilis\xE9\
        \ par des attaquants pour s'accorder ill\xE9gitimement des droits d'acc\xE8\
        s."
      annotation: "# Recommandation\n\nLa propri\xE9t\xE9 `sIDHistory` permet de rajouter\
        \ un identifiant de s\xE9curit\xE9 (SID) arbitraire dans la liste des groupes\
        \ d'un compte utilisateur ou machine. Ce m\xE9canisme est principalement utilis\xE9\
        \ lors de la migration de comptes d'un domaine \xE0 un autre pour perp\xE9\
        tuer l'acc\xE8s \xE0 d'anciennes ressources.\n\nUne investigation doit \xEA\
        tre men\xE9e pour expliquer la pr\xE9sence de ces SID non conformes. L'attribut\
        \ `sIDHistory` doit \xEAtre effac\xE9 pour tous les comptes et groupes concern\xE9\
        s d\xE8s lors que les op\xE9rations de migration ont \xE9t\xE9 effectu\xE9\
        es."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Accounts or groups with unexpected SID history (Level 2)
          description: '# Vulnerability description


            Several accounts or groups in the forest have unexpected `sIDHistory`
            attribute values (either a well-known SID or a domain-level privileged
            SID). This can be exploited by an attacker to grant themselves illegitimate
            access rights.'
          annotation: '# Recommended measure


            The `sIDHistory` attribute allows appending an additional security identifier
            (SID) in their group list. This mechanism is mainly used during migrations
            from one domain to another, to keep access to previous resources.


            An investigation into the reasons for these unexpected SIDs being granted
            to users should be carried out. The `sIDHistory` attribute must then be
            erased for all the aforementioned users and computers.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_sysvol_ntfrs-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_sysvol_ntfrs-l2
      name: "Utilisation de NTFRS pour la r\xE9plication du SYSVOL (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes contr\xF4leurs\
        \ de domaines sont configur\xE9s pour utiliser le protocole de r\xE9plication\
        \ NTFRS (en particulier pour la r\xE9plication du SYSVOL). Ce protocole est\
        \ obsol\xE8te et rajoute inutilement des interfaces d'administration aux contr\xF4\
        leurs de domaine. De plus, ce protocole n'est plus support\xE9 par les derni\xE8\
        res versions de Windows Server, ce qui emp\xEAche la migration vers les derni\xE8\
        res versions."
      annotation: "# Recommandation\n\nIl est recommand\xE9 d'utiliser uniquement\
        \ le m\xE9canisme Distributed File System Replication (DFSR) pour synchroniser\
        \ des r\xE9pertoires sur diff\xE9rents serveurs, en particulier pour la r\xE9\
        plication du SYSVOL.\n\nNote : NTFRS n'est plus support\xE9 dans les derni\xE8\
        res versions de Windows Server. Le processus de migration vers DFSR est document\xE9\
        \ par Microsoft : [https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr](https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr)."
      implementation_groups:
      - level_2
      translations:
        en:
          name: SYSVOL replication through NTFRS (Level 2)
          description: '# Vulnerability description


            Some domain controllers are configured to use the NTFRS protocol to replicate
            the SYSVOL file share. This protocol is obsolete, and exposes unnecessary
            additional administration interfaces to domain controllers. Furthermore,
            latest Windows Server versions have dropped support of NTFRS altogether,
            blocking upgrades for existing infrastructure pending migration to DFSR.'
          annotation: '# Recommended measure


            Distributed File System Replication (DFSR) should be used for share replication,
            including SYSVOL replication.


            Note: support for NTFRS has been dropped in latest Windows Server versions.
            Migration to DSFR is documented at the URL below: [https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr](https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr).'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_trusts_accounts-l2
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_trusts_accounts-l2
      name: "Comptes de trust dont le mot de passe est inchang\xE9 depuis plus d'un\
        \ an (Niveau 2)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLes comptes de trust\
        \ n'ont pas eu leur mot de passe chang\xE9 depuis plus d'un an. Cela peut\
        \ signifier que les relations d'approbation ont \xE9t\xE9 supprim\xE9es, mais\
        \ que les comptes associ\xE9s sont toujours pr\xE9sents."
      annotation: "# Recommandation\n\n## Cas d'une relation d'approbation supprim\xE9\
        e\n\nCertains comptes de trust restent pr\xE9sents alors que les relations\
        \ associ\xE9es ont \xE9t\xE9 supprim\xE9es. Il faut donc supprimer ces comptes.\n\
        \n## Cas d'une relation d'approbation non supprim\xE9e\n\nIl est recommand\xE9\
        \ de changer au moins annuellement les mots de passe des comptes de trust.\
        \ Ce changement doit \xEAtre automatique entre les environnements Microsoft.\
        \ Il convient \xE9galement d'investiguer la cause du non-renouvellement automatique\
        \ de ce mot de passe."
      implementation_groups:
      - level_2
      translations:
        en:
          name: Trust account passwords unchanged for more than a year (Level 2)
          description: '# Vulnerability description


            Trust account passwords have not been changed for more than a year. This
            may be indicative of deleted trust relationships while their corresponding
            trust accounts are still present.'
          annotation: '# Recommended measure


            ## Deleted Trust Relationship


            Some trust accounts may remain while their trust relationships have been
            removed. They should be deleted manually.


            ## Active Trust Relationship


            Trust passwords should be changed at least once a year. That change must
            be automatic for trust relationships between Microsoft environments. The
            cause for the lack of an automatic renewal should be investigated.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_compatible_2000_not_default-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_compatible_2000_not_default-l3
      name: Comptes ou groupes membres de "Pre-Windows 2000 Compatible Access" (Niveau
        3)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLe m\xE9canisme de\
        \ compatibilit\xE9 pr\xE9-Windows 2000 est activ\xE9 pour certains comptes.\
        \ Ce m\xE9canisme permet l'acc\xE8s \xE0 certaines RPC aux membres du groupe\
        \ *Builtin\\Acc\xE8s compatible pr\xE9-Windows 2000* (Builtin\\Pre-Windows\
        \ 2000 Compatible Access). Selon le param\xE9trage syst\xE8me, le groupe int\xE9\
        gr\xE9 *Tout le monde* (Everyone) peut contenir les utilisateurs anonymes,\
        \ ce qui peut augmenter le risque s'il est membre du groupe de r\xE9trocompatibilit\xE9\
        ."
      annotation: "# Recommandation\n\nLe m\xE9canisme de compatibilit\xE9 pr\xE9\
        -Windows 2000 permet d'assurer le support des domaines de type Windows NT.\
        \ Historiquement utilis\xE9 pour des raisons de r\xE9trocompatibilit\xE9,\
        \ le groupe *Builtin\\Acc\xE8s compatible pr\xE9-Windows 2000* (Builtin\\\
        Pre-Windows 2000 Compatible Access) ne doit contenir que *Utilisateurs authentifi\xE9\
        s* (Authenticated Users) (`S-1-5-11`).\n\nNote : les serveurs ADCS sont inscrits\
        \ dans ce groupe lors de leur installation. Dans la plupart des cas, l'appartenance\
        \ \xE0 ce groupe n'est pas n\xE9cessaire et peut \xEAtre supprim\xE9e. Cette\
        \ op\xE9ration est facilement r\xE9versible."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Use of the "Pre-Windows 2000 Compatible Access" group (Level 3)
          description: "# Vulnerability description\n\nThe *Builtin\\Pre-Windows 2000\
            \ Compatible Access* (Builtin\\Acc\xE8s compatible pr\xE9-Windows 2000)\
            \ group contains additional identifiers to the default ones. This grants\
            \ these group members access to some RPC calls. Specific system parameters\
            \ may have the *Everyone* (Tout le monde) group include anonymous users,\
            \ which may increase risk if it belongs to the *Builtin\\Pre-Windows 2000\
            \ Compatible Access* (Builtin\\Acc\xE8s compatible pr\xE9-Windows 2000)\
            \ group."
          annotation: "# Recommended measure\n\nThe *Builtin\\Pre-Windows 2000 Compatible\
            \ Access* (Builtin\\Acc\xE8s compatible pr\xE9-Windows 2000) group used\
            \ to serve backward compatibility purposes for systems prior to Windows\
            \ 2000 (Windows NT 4.0). This group must only include *Authenticated Users*\
            \ (Utilisateurs authentifi\xE9s) (`S-1-5-11`).\n\nNote: ADCS servers are\
            \ automatically added to this group upon installation. They can be removed\
            \ in most instances as it is likely not useful. This operation is easily\
            \ reversible."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_kerberos_properties_encryption-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_kerberos_properties_encryption-l3
      name: "Algorithmes de chiffrement support\xE9s par les comptes de service (Niveau\
        \ 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLes comptes de service\
        \ qui supportent l'authentification Kerberos (i.e. qui disposent d'un attribut\
        \ `servicePrincipalName`) peuvent utiliser diff\xE9rents algorithmes (DES,\
        \ RC4, AES128 et AES256) de chiffrement pour les tickets \xE9mis \xE0 destination\
        \ des services s'ex\xE9cutant sous l'identit\xE9 de ces comptes.\n\nPour un\
        \ compte donn\xE9 dans l'annuaire, l'attribut `msDS-SupportedEncryptionTypes`\
        \ indique aux contr\xF4leurs de domaine les algorithmes support\xE9s pour\
        \ le service s'ex\xE9cutant pour l'identit\xE9 de ce compte. Par d\xE9faut,\
        \ cet attribut est vide et seul l'algorithme RC4 est utilis\xE9.\n\nSi le\
        \ compte de service est un \"compte machine\" s'ex\xE9cutant sous Windows,\
        \ celle-ci va mettre \xE0 jour automatiquement l'attribut en fonction de ses\
        \ capacit\xE9s. Depuis Windows Vista et Windows Server 2008, la machine indique\
        \ g\xE9n\xE9ralement qu'elle supporte RC4, AES128 et AES256."
      annotation: "# Recommandation\n\nPour les comptes de service qui ne sont pas\
        \ de type \"compte machine\", il est n\xE9cessaire de sp\xE9cifier explicitement\
        \ le support d'AES128 ou AES256 dans les options du compte.\n\nCeci peut \xEA\
        tre fait en sp\xE9cifiant la valeur 28 (0x1C) dans l'attribut `msDS-SupportedEncryptionTypes`\
        \ du compte utilisateur ou en activant l'option sp\xE9cifique dans ses propri\xE9\
        t\xE9s :\n\n* dans la console `dsa.msc`, ouvrir les propri\xE9t\xE9s de l'utilisateur\
        \ concern\xE9 ;\n* dans l'onglet \"compte\", cocher les options suivantes\
        \ :\n  * \"Ce compte prend en charge le chiffrement AES 128 bits via Kerberos.\"\
        \n  * \"Ce compte prend en charge le chiffrement AES 256 bits via Kerberos.\"\
        \n\nEn cas d'incompatibilit\xE9 avec une application, celle-ci doit faire\
        \ l'objet d'une \xE9volution applicative."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Service accounts supported encryption algorithms (Level 3)
          description: '# Vulnerability description


            Service accounts supporting Kerberos authentication (i.e., that have a
            `servicePrincipalName` attribute) can use several encryption algorithms
            (DES, RC4, AES128 et AES256) for the tickets issued to the service using
            these accounts.


            For a given directory account, the `msDS-SupportedEncryptionTypes` attribute
            provides the domain controllers with the list of its supported encryption
            algorithms. By default, this attribute is empty and only the RC4 algorithm
            is used.


            If the service account is of the "Windows computer" type, the computer
            automatically updates that attribute. Since Windows Vista and Windows
            Server 2008 the computer usually indicate that it support RC4, AES128
            and AES256.'
          annotation: "# Recommended measure\n\nFor service accounts which are not\
            \ of the \"Windows computer\" account type, it is necessary to specifically\
            \ add the support of AES128 or AES256 in the account options.\n\nThis\
            \ can be done either by setting the attribute `msDS-SupportedEncryptionTypes`\
            \ to 28 (0x1C), or by manually enabling the following user account options:\n\
            \n* in the `dsa.msc` console, navigate to the affected user account and\
            \ open its properties;\n* in the \"account\" tab, enable the following\
            \ options:\n  * \"This account supports Kerberos AES 128-bits encryption.\"\
            \n  * \"This account supports Kerberos AES 256-bits encryption.\"\n\n\
            Any incompatible software must be upgraded."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_owner-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_owner-l3
      name: "Objets ayant un propri\xE9taire inadapt\xE9 (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes objets, cr\xE9\xE9\
        s il y a plus de 7 jours, ont des propri\xE9taires non standard. Note : seuls\
        \ les 20 premiers objets sont affich\xE9s, pour les 10000 premiers propri\xE9\
        taires."
      annotation: "# Recommandation\n\nTous les objets (utilisateurs, groupes, sMSA,\
        \ gMSA, ordinateurs, OU et GPO) doivent avoir pour propri\xE9taire l'un des\
        \ objets suivants :\n\n* \xAB *Administrateurs du domaine* (Domain Admins)\
        \ \xBB ;\n* \xAB *Administrateurs de l'entreprise* (Enterprise Admins) \xBB\
        \ ;\n* \xAB *Administrateurs* (Administrators) \xBB ;\n* \xAB *Syst\xE8me\
        \ local* (Local System) \xBB."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Incorrect object owners (Level 3)
          description: '# Vulnerability description


            Some objects, created for more than 7 days, have non-standard owners.
            Note: Only the first 20 objects are shown for the first 10000 owners.'
          annotation: "# Recommended measure\n\nAll objects (users, groups, sMSA,\
            \ gMSA, computers, OU, GPO) must be owned by one of the following objects:\n\
            \n* \xAB *Domain Admins* (Administrateurs du domaine) \xBB ;\n* \xAB *Enterprise\
            \ Admins* (Administrateurs de l'entreprise) \xBB ;\n* \xAB *Administrators*\
            \ (Administrateurs) \xBB ;\n* \xAB *Local System* (Syst\xE8me local) \xBB\
            ."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_password_change_inactive_servers-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_password_change_inactive_servers-l3
      name: Serveurs inactifs (Niveau 3)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes serveurs ne se\
        \ sont pas authentifi\xE9s depuis plus de 90 jours."
      annotation: "# Recommandation\n\nDans leur fonctionnement par d\xE9faut, les\
        \ serveurs doivent s'authentifier et changer automatiquement leur mot de passe\
        \ sur le domaine tous les 30 jours. Les serveurs non utilis\xE9s doivent \xEA\
        tre d\xE9sactiv\xE9s.\n\nL'absence d'authentification au domaine est symptomatique\
        \ d'une machine d\xE9synchronis\xE9e. Les serveurs d\xE9synchronis\xE9s du\
        \ domaine doivent r\xE9install\xE9s ou supprim\xE9s. Dans le cas d'une r\xE9\
        installation, afin d'\xE9viter le chemin de contr\xF4le de type <span style=\"\
        background-color:rgb(220, 53, 69);color:rgb(255, 255, 255)\">OWNER</span>\
        \ du compte machine, il est recommand\xE9 d'effectuer une jonction de domaine\
        \ hors connexion \xE0 l'aide de l'utilitaire [Djoin](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/ff793312(v%3Dws.11))."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Inactive servers (Level 3)
          description: '# Vulnerability description


            Some servers have not authenticated themselves for more than 90 days.'
          annotation: '# Recommended measure


            Servers must authenticate and change their passwords at least every 30
            days.


            Lack of domain authentication reveals out-of-sync machines. Out-of-sync
            servers must be either reinstalled or removed. When reinstalling an out-of-sync
            server, care must be taken not to introduce a new <span style="background-color:rgb(220,
            53, 69);color:rgb(255, 255, 255)">OWNER</span> control path exposing its
            computer account. To avoid doing so, use of the [Djoin](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/ff793312(v%3Dws.11))
            utility is advised.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_password_change_server_no_change_45-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_password_change_server_no_change_45-l3
      name: "Serveurs dont le mot de passe de compte d'ordinateur est inchang\xE9\
        \ depuis plus de 45 jours (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes serveurs n'ont\
        \ pas chang\xE9 le mot de passe de leur compte d'ordinateur depuis plus de\
        \ 45 jours, ce qui indique que leurs secrets ne sont pas renouvel\xE9s."
      annotation: "# Recommandation\n\nDans leur fonctionnement par d\xE9faut, les\
        \ serveurs changent automatiquement le mot de passe de leur compte d'ordinateur\
        \ p\xE9riodiquement (30 jours par d\xE9faut). Il convient d'investiguer la\
        \ raison qui emp\xEAche les serveurs de changer leur mot de passe.\n\nUne\
        \ premi\xE8re v\xE9rification consiste \xE0 v\xE9rifier la valeur des entr\xE9\
        es de Registre suivantes :\n\n* `HKLM\\System\\CurrentControlSet\\Services\\\
        Netlogon\\Parameters\\DisablePasswordChange`: doit valoir 0 ou ne pas exister\
        \ ;\n* `HKLM\\System\\CurrentControlSet\\Services\\Netlogon\\Parameters\\\
        MaximumPasswordAge`: doit valoir 30.\n\nSi ces valeurs sont incorrectes, il\
        \ convient de les remettre aux valeurs par d\xE9faut et de s'assurer qu'elles\
        \ ne sont pas positionn\xE9es par une GPO.\n\nSi ces valeurs sont correctes,\
        \ v\xE9rifier si le service `NETLOGON` est d\xE9marr\xE9 avec `sc.exe query\
        \ netlogon`.\n\nEnfin, il faut v\xE9rifier que le mot de passe de la machine\
        \ soit synchronis\xE9 avec celui du compte machine dans l'annuaire. Ceci peut\
        \ \xEAtre v\xE9rifi\xE9 avec la commande `nltest /SC_VERIFY:<DomainName>`,\
        \ o\xF9 `DomainName` correspond au nom NetBIOS du domaine. Dans les deux v\xE9\
        rifications effectu\xE9es, la commande doit indiquer le code de retour `0\
        \ 0x0 NERR_Success`."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Servers with passwords unchanged for more than 45 days (Level 3)
          description: '# Vulnerability description


            Some servers have not changed their passwords for more than 45 days, indicating
            their secrets are not renewed.'
          annotation: '# Recommended measure


            Default server settings have them change their passwords automatically
            every 30 days. The reason for this change not to occur properly must be
            investigated as it may be indicative of a compromise.


            First, check the following registry values:


            * `HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange`:
            must be set to 0 or inexistent;

            * `HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge`:
            must be set to 30.


            Incorrect values should be reset to their default setting, and GPOs must
            be checked to ensure they do not override those.


            If these values are correct, check if the `NETLOGON` service is started
            with `sc.exe query netlogon`.


            Finally, proper synchronization between the machine password and that
            of the machine account in the Active Directory database must be validated.
            Running `nltest /SC_VERIFY:<DomainName>` (with `DomainName` being the
            domain NetBIOS name) can check the synchronization status, and should
            display `0 0x0 NERR_Success` for both verifications.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_primary_group_id_nochange-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_primary_group_id_nochange-l3
      name: "Comptes avec un PrimaryGroupID modifi\xE9 (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nCertains utilisateurs\
        \ ou ordinateurs ont un attribut `primaryGroupId` modifi\xE9."
      annotation: "# Recommandation\n\nDans le fonctionnement d'un Active Directory,\
        \ l'attribut `primaryGroupId` d'un compte utilisateur ou machine permet d'affecter\
        \ implicitement ce compte \xE0 un groupe, m\xEAme si ce groupe n'est pas r\xE9\
        pertori\xE9 par l'attribut `memberOf` de l'utilisateur. L'appartenance \xE0\
        \ un groupe via cet attribut n'appara\xEEt pas dans la liste des membres du\
        \ groupe dans certaines interfaces. Cet attribut dissimule l'appartenance\
        \ d'un compte \xE0 un groupe privil\xE9gi\xE9.\n\nIl est recommand\xE9 de\
        \ repositionner les attributs `primaryGroupId` des utilisateurs ou ordinateurs\
        \ concern\xE9s \xE0 leur valeur par d\xE9faut :\n\n* utilisateurs: 513 (*Utilisateurs\
        \ du domaine* (Domain Users)) ou 514 (*Invit\xE9s du domaine* (Domain Guests));\
        \ ;\n* ordinateurs: 515 (*Ordinateurs du domaine* (Domain Computers)) ;\n\
        * contr\xF4leurs de domaine: 516 (*Contr\xF4leurs de domaine* (Domain Controllers))\
        \ ;\n* contr\xF4leurs de domaine en lecture seule (RODC) : 521 (*Contr\xF4\
        leurs de domaine en lecture seule* (Read-only Domain Controllers))."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Accounts with modified PrimaryGroupID (Level 3)
          description: '# Vulnerability description


            Some users or computers have a modified `primaryGroupId` attribute.'
          annotation: "# Recommended measure\n\nThe `primaryGroupId` attribute of\
            \ a user or computer account grants implicit membership to a group. Membership\
            \ through this attribute does not appear in the list of group members\
            \ in some interfaces. This attribute may be used as an attempt to hide\
            \ group membership.\n\nReset the `primaryGroupId` attributes of users\
            \ and computers to their default values:\n\n* user accounts: 513 (*Domain\
            \ Users* (Utilisateurs du domaine)) or 514 (*Domain Guests* (Invit\xE9\
            s du domaine));\n* computer accounts: 515 (*Domain Computers* (Ordinateurs\
            \ du domaine));\n* domain controller accounts: 516 (*Domain Controllers*\
            \ (Contr\xF4leurs de domaine));\n* read-only domain controller (RODC)\
            \ accounts : 521 (*Read-only Domain Controllers* (Contr\xF4leurs de domaine\
            \ en lecture seule))."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_protected_users-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_protected_users-l3
      name: "Comptes privil\xE9gi\xE9s non membres du groupe Protected Users (Niveau\
        \ 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes privil\xE9\
        gi\xE9s ne sont pas prot\xE9g\xE9s par le groupe *Protected users* (Protected\
        \ users)."
      annotation: "# Recommandation\n\nL'ensemble des comptes privil\xE9gi\xE9s doivent\
        \ \xEAtre ajout\xE9s au groupe *Protected users* (Protected users) afin de\
        \ :\n\n* forcer l'authentification en Kerberos ;\n* r\xE9duire la dur\xE9\
        e de vie des tickets Kerberos ;\n* forcer l'utilisation d'algorithmes de chiffrement\
        \ forts (AES) ;\n* interdire la mise en cache du mot de passe sur les postes\
        \ de travail ;\n* interdire toute forme de d\xE9l\xE9gation.\n\n**Attention**:\
        \ l'utilisation du groupe *Protected users* (Protected users) a des impacts\
        \ fonctionnels importants. R\xE9f\xE9rence : [https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group).\n\
        \n## Contexte : groupes privil\xE9gi\xE9s\n\nLes groupes privil\xE9gi\xE9\
        s sont les groupes d'administration et les groupes op\xE9ratifs ayant tous\
        \ les droits et privil\xE8ges sur la for\xEAt ou pouvant se les attribuer\
        \ :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n* \xAB *Contr\xF4\
        leurs de domaine* (Domain Controllers) \xBB;\n* \xAB *Administrateurs du sch\xE9\
        ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs de l'entreprise* (Enterprise\
        \ Admins) \xBB ;\n* \xAB *Administrateurs du domaine* (Domain Admins) \xBB\
        \ : ces administrateurs ont les privil\xE8ges de lire la base des secrets\
        \ de tous les comptes et donc d'extraire les secrets de l'ensemble des comptes\
        \ privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de cl\xE9s* (Key Admins) \xBB\
        \ et \xAB *Administrateurs de cl\xE9s de l'entreprise* (Enterprise Key Admins)\
        \ \xBB: ces administrateurs peuvent fixer des valeurs arbitraires aux attributs\
        \ relatifs \xE0 Windows Hello for Business, pour tous les utilisateurs sauf\
        \ ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`. Si l'authentification\
        \ bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9e, ils peuvent g\xE9n\xE9\
        rer un certificat sous leur contr\xF4le, l'assigner \xE0 un compte privil\xE9\
        gi\xE9 (par exemple, un contr\xF4leur de domaine), et s'authentifier en tant\
        \ que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account Operators) \xBB : ces\
        \ op\xE9rateurs peuvent administrer tous les comptes d'utilisateurs, machines\
        \ et groupes; \xE0 l'exception des comptes prot\xE9g\xE9s par l' `adminSDHolder`;\n\
        * \xAB *Op\xE9rateurs de serveur* (Server Operators) \xBB : ces op\xE9rateurs\
        \ peuvent administrer les contr\xF4leurs de domaine, et donc r\xE9cup\xE9\
        rer les secrets de tous les comptes privil\xE9gi\xE9s ;\n* \xAB *Op\xE9rateurs\
        \ de sauvegarde* (Backup Operators) \xBB : ces op\xE9rateurs peuvent sauvegarder\
        \ un contr\xF4leur de domaine et donc extraire les secrets de tous les comptes\
        \ privil\xE9gi\xE9s depuis cette sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression*\
        \ (Print Operators) \xBB : ces op\xE9rateurs peuvent charger des pilotes d'impression\
        \ sur les contr\xF4leurs de domaine et donc charger un pilote malveillant\
        \ pour par exemple extraire les secrets de tous les comptes privil\xE9gi\xE9\
        s.\n\nLes groupes \xAB op\xE9rateurs \xBB sont vides par d\xE9faut et ne devraient\
        \ contenir aucun membre."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Privileged accounts outside of the Protected Users group (Level 3)
          description: '# Vulnerability description


            Some privileged accounts are not protected by the *Protected users* (Protected
            users) group.'
          annotation: "# Recommended measure\n\nPrivileged users must be members of\
            \ the *Protected users* (Protected users) group so as to:\n\n* enforce\
            \ Kerberos authentication;\n* reduce Kerberos ticket lifetime;\n* enforce\
            \ usage of strong encryption algorithms (AES);\n* prevent caching of passwords\
            \ on workstations;\n* prevent any type of Kerberos delegation.\n\n**Warning**:\
            \ use of the *Protected users* (Protected users) group comes with significant\
            \ functional impacts. Reference : [https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group).\n\
            \nThe \xAB operators \xBB groups are empty by default and must not have\
            \ any member.\n\n## Context: privileged groups\n\nPrivileged groups include\
            \ administrator groups and operator groups which have full control over\
            \ the Active Directory forest either by design, or by granting themselves\
            \ such privileges:\n\n* \xAB *Administrators* (Administrateurs) \xBB;\n\
            * \xAB *Domain Controllers* (Contr\xF4leurs de domaine) \xBB;\n* \xAB\
            \ *Schema Admins* (Administrateurs du sch\xE9ma) \xBB;\n* \xAB *Enterprise\
            \ Admins* (Administrateurs de l'entreprise) \xBB;\n* \xAB *Domain Admins*\
            \ (Administrateurs du domaine) \xBB: these administrators are able to\
            \ read the authentication database and extract password hashes and other\
            \ secrets of all privileged accounts;\n* \xAB *Key Admins* (Administrateurs\
            \ de cl\xE9s) \xBB and \xAB *Enterprise Key Admins* (Administrateurs de\
            \ cl\xE9s de l'entreprise) \xBB: these administrators can set arbitrary\
            \ values to attributes relating to Windows Hello for Business, for all\
            \ users except those protected by the `adminSDHolder` mechanism. If certificate-based\
            \ authentication has been enabled, they can generate a certificate that\
            \ they control, assign it to privileged accounts (for instance, a domain\
            \ controller), and log on as them;\n* \xAB *Account Operators* (Op\xE9\
            rateurs de compte) \xBB: these operators can manage user accounts, machine\
            \ accounts and groups except accounts protected by the `adminSDHolder`\
            \ mechanism;\n* \xAB *Server Operators* (Op\xE9rateurs de serveur) \xBB\
            : these operators can manage domain controllers, which grants them the\
            \ ability to recover privileged user secrets directly from the authentication\
            \ database;\n* \xAB *Backup Operators* (Op\xE9rateurs de sauvegarde) \xBB\
            : these operators can back up a domain controller, which grants them the\
            \ ability to recover privileged user secrets from that backup;\n* \xAB\
            \ *Print Operators* (Op\xE9rateurs d'impression) \xBB: these operators\
            \ can load arbitrary printer drivers on domain controllers, which grants\
            \ them the ability to recover privileged user secrets directly from the\
            \ authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_reversible_password-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_reversible_password-l3
      name: "Comptes ayant leur mot de passe stock\xE9 de mani\xE8re r\xE9versible\
        \ (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes ont leur\
        \ mot de passe stock\xE9 de mani\xE8re r\xE9versible dans l'annuaire.\n\n\
        Il est possible, en poss\xE9dant des droits d'administrateur de r\xE9cup\xE9\
        rer en clair les mots de passe concern\xE9s."
      annotation: "# Recommandation\n\nAfin d'\xE9viter les faiblesses dans la gestion\
        \ des mots de passe, il est n\xE9cessaire de retirer les propri\xE9t\xE9s\
        \ dangereuses relatives aux mots de passe des comptes utilisateur. Cette action\
        \ peut \xEAtre effectu\xE9e \xE0 l'aide de la console \xAB Utilisateurs et\
        \ ordinateurs AD \xBB. Il faut pour cela d\xE9cocher la case \xAB Enregistrer\
        \ le mot de passe en utilisant un chiffrement r\xE9versible \xBB dans l'onglet\
        \ \xAB Compte \xBB des propri\xE9t\xE9s du compte en question. Cela a pour\
        \ effet de retirer la propri\xE9t\xE9 `ENCRYPTED_TEXT_PASSWORD_ALLOWED` de\
        \ l'attribut `userAccountControl`.\n\nSi ces param\xE8tres correspondent \xE0\
        \ un besoin m\xE9tier l\xE9gitime, il convient de le documenter, par exemple\
        \ en l'indiquant dans le commentaire du compte."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Accounts with passwords stored using reversible encryption (Level
            3)
          description: '# Vulnerability description


            Some accounts have their passwords stored in Active Directory using reversible
            encryption.


            With administrator privileges, it becomes possible to retrieve cleartext
            passwords of all affected accounts.'
          annotation: '# Recommended measure


            To avoid common downward spirals in password management, it is important
            to remove dangerous properties regarding user account passwords (Active
            Directory Users and computers console): reversible password storage (`ENCRYPTED_TEXT_PASSWORD_ALLOWED`
            flag in the `userAccountControl` attribute). The checkbox Store password
            using reversible encryption must be left unchecked in the Account tab
            of each account properties.


            If these settings have a legitimate use, it should be documented, for
            instance in the account description attribute.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_rodc_never_reveal-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_rodc_never_reveal-l3
      name: "Configuration dangereuse des contr\xF4leurs de domaine en lecture seule\
        \ (RODC) (neverReveal) (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa for\xEAt poss\xE8\
        de des contr\xF4leurs de domaine en lecture seule (RODC) avec des attributs\
        \ de r\xE9v\xE9lation dangereux. Des groupes par d\xE9faut sont manquants\
        \ dans l'attribut `msDS-NeverRevealGroup` sur des RODC."
      annotation: "# Recommandation\n\nL'attribut `msDS-NeverRevealGroup` permet d'interdire\
        \ la r\xE9v\xE9lation des secrets des objets qui y sont list\xE9s (et ce,\
        \ de mani\xE8re r\xE9cursive).\n\nLes contr\xF4leurs de domaine en lecture\
        \ seule (RODC) doivent comporter dans l'attribut `msDS-NeverRevealGroup` au\
        \ minimum les valeurs suivantes :\n\n* *Administrateurs* (Administrators);\n\
        * *Op\xE9rateurs de serveur* (Server Operators);\n* *Op\xE9rateurs de compte*\
        \ (Account Operators);\n* *Op\xE9rateurs de sauvegarde* (Backup Operators);\n\
        * *Groupe de r\xE9plication de mot de passe RODC refus\xE9e* (Denied RODC\
        \ Password Replication Group)."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Dangerous configuration of read-only domain controllers (RODC) (neverReveal)
            (Level 3)
          description: '# Vulnerability description


            Read-only domain controllers (RODCs) are used in the forest with dangerous
            secret revelation settings. Some default groups are missing from the `msDS-NeverRevealGroup`
            attribute of some RODCs.'
          annotation: "# Recommended measure\n\nThe `msDS-NeverRevealGroup` attribute\
            \ can be used to list objects whose secrets are prevented from being revealed\
            \ on a RODC (these objects are recursively parsed).\n\nRead-only domain\
            \ controllers must have their `msDS-NeverRevealGroup` attribute set to\
            \ include, at least:\n\n* *Administrators* (Administrateurs);\n* *Server\
            \ Operators* (Op\xE9rateurs de serveur);\n* *Account Operators* (Op\xE9\
            rateurs de compte);\n* *Backup Operators* (Op\xE9rateurs de sauvegarde);\n\
            * *Denied RODC Password Replication Group* (Groupe de r\xE9plication de\
            \ mot de passe RODC refus\xE9e)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_rodc_reveal-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_rodc_reveal-l3
      name: "Comptes ou groupes privil\xE9gi\xE9s pr\xE9sents dans les attributs de\
        \ r\xE9v\xE9lation des RODC (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa for\xEAt poss\xE8\
        de des contr\xF4leurs de domaine en lecture seule (RODC) avec des attributs\
        \ de r\xE9v\xE9lation dangereux. En effet, certains utilisateurs ou groupes\
        \ privil\xE9gi\xE9s (RID < 1000) sont pr\xE9sents dans l'attribut `msDS-RevealOnDemandGroup`."
      annotation: "# Recommandation\n\nL'attribut `msDS-RevealOnDemandGroup` permet\
        \ de d\xE9finir les utilisateurs et groupes autoris\xE9s \xE0 \xEAtre r\xE9\
        v\xE9l\xE9s sur un RODC.\n\nLes contr\xF4leurs de domaine en lecture seule\
        \ (RODC) ne doivent pas comporter dans cet attribut des groupes dont le RID\
        \ est inf\xE9rieur \xE0 1000.\n\n## Contexte : groupes privil\xE9gi\xE9s\n\
        \nLes groupes privil\xE9gi\xE9s sont les groupes d'administration et les groupes\
        \ op\xE9ratifs ayant tous les droits et privil\xE8ges sur la for\xEAt ou pouvant\
        \ se les attribuer :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n\
        * \xAB *Contr\xF4leurs de domaine* (Domain Controllers) \xBB;\n* \xAB *Administrateurs\
        \ du sch\xE9ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs de l'entreprise*\
        \ (Enterprise Admins) \xBB ;\n* \xAB *Administrateurs du domaine* (Domain\
        \ Admins) \xBB : ces administrateurs ont les privil\xE8ges de lire la base\
        \ des secrets de tous les comptes et donc d'extraire les secrets de l'ensemble\
        \ des comptes privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de cl\xE9s* (Key\
        \ Admins) \xBB et \xAB *Administrateurs de cl\xE9s de l'entreprise* (Enterprise\
        \ Key Admins) \xBB: ces administrateurs peuvent fixer des valeurs arbitraires\
        \ aux attributs relatifs \xE0 Windows Hello for Business, pour tous les utilisateurs\
        \ sauf ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`. Si l'authentification\
        \ bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9e, ils peuvent g\xE9n\xE9\
        rer un certificat sous leur contr\xF4le, l'assigner \xE0 un compte privil\xE9\
        gi\xE9 (par exemple, un contr\xF4leur de domaine), et s'authentifier en tant\
        \ que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account Operators) \xBB : ces\
        \ op\xE9rateurs peuvent administrer tous les comptes d'utilisateurs, machines\
        \ et groupes; \xE0 l'exception des comptes prot\xE9g\xE9s par l' `adminSDHolder`;\n\
        * \xAB *Op\xE9rateurs de serveur* (Server Operators) \xBB : ces op\xE9rateurs\
        \ peuvent administrer les contr\xF4leurs de domaine, et donc r\xE9cup\xE9\
        rer les secrets de tous les comptes privil\xE9gi\xE9s ;\n* \xAB *Op\xE9rateurs\
        \ de sauvegarde* (Backup Operators) \xBB : ces op\xE9rateurs peuvent sauvegarder\
        \ un contr\xF4leur de domaine et donc extraire les secrets de tous les comptes\
        \ privil\xE9gi\xE9s depuis cette sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression*\
        \ (Print Operators) \xBB : ces op\xE9rateurs peuvent charger des pilotes d'impression\
        \ sur les contr\xF4leurs de domaine et donc charger un pilote malveillant\
        \ pour par exemple extraire les secrets de tous les comptes privil\xE9gi\xE9\
        s.\n\nLes groupes \xAB op\xE9rateurs \xBB sont vides par d\xE9faut et ne devraient\
        \ contenir aucun membre."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Dangerous configuration of read-only domain controllers (RODC) (reveal)
            (Level 3)
          description: '# Vulnerability description


            Read-only domain controllers (RODCs) are used in the forest with dangerous
            secret revelation settings. Some privileged groups or users are included
            in the `msDS-RevealOnDemandGroup` attribute of some RODC.'
          annotation: "# Recommended measure\n\nThe `msDS-RevealOnDemandGroup` attribute\
            \ defines users and groups allowed to be revealed on a RODC.\n\nRead-only\
            \ domain controllers must not have groups in their `msDS-RevealOnDemandGroup`\
            \ attribute whose RID is lower than 1000.\n\nThe \xAB operators \xBB groups\
            \ are empty by default and must not have any member.\n\n## Context: privileged\
            \ groups\n\nPrivileged groups include administrator groups and operator\
            \ groups which have full control over the Active Directory forest either\
            \ by design, or by granting themselves such privileges:\n\n* \xAB *Administrators*\
            \ (Administrateurs) \xBB;\n* \xAB *Domain Controllers* (Contr\xF4leurs\
            \ de domaine) \xBB;\n* \xAB *Schema Admins* (Administrateurs du sch\xE9\
            ma) \xBB;\n* \xAB *Enterprise Admins* (Administrateurs de l'entreprise)\
            \ \xBB;\n* \xAB *Domain Admins* (Administrateurs du domaine) \xBB: these\
            \ administrators are able to read the authentication database and extract\
            \ password hashes and other secrets of all privileged accounts;\n* \xAB\
            \ *Key Admins* (Administrateurs de cl\xE9s) \xBB and \xAB *Enterprise\
            \ Key Admins* (Administrateurs de cl\xE9s de l'entreprise) \xBB: these\
            \ administrators can set arbitrary values to attributes relating to Windows\
            \ Hello for Business, for all users except those protected by the `adminSDHolder`\
            \ mechanism. If certificate-based authentication has been enabled, they\
            \ can generate a certificate that they control, assign it to privileged\
            \ accounts (for instance, a domain controller), and log on as them;\n\
            * \xAB *Account Operators* (Op\xE9rateurs de compte) \xBB: these operators\
            \ can manage user accounts, machine accounts and groups except accounts\
            \ protected by the `adminSDHolder` mechanism;\n* \xAB *Server Operators*\
            \ (Op\xE9rateurs de serveur) \xBB: these operators can manage domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database;\n* \xAB *Backup Operators* (Op\xE9\
            rateurs de sauvegarde) \xBB: these operators can back up a domain controller,\
            \ which grants them the ability to recover privileged user secrets from\
            \ that backup;\n* \xAB *Print Operators* (Op\xE9rateurs d'impression)\
            \ \xBB: these operators can load arbitrary printer drivers on domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_rodc_allowed_group-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_rodc_allowed_group-l3
      name: "Configuration dangereuse des groupes de r\xE9plication pour les contr\xF4\
        leurs de domaine en lecture seule (RODC) (allow) (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLe groupe *Groupe de\
        \ r\xE9plication de mot de passe RODC autoris\xE9e* (Allowed RODC Password\
        \ Replication Group) n'est pas vide."
      annotation: "# Recommandation\n\nLes secrets des membres du groupe *Groupe de\
        \ r\xE9plication de mot de passe RODC autoris\xE9e* (Allowed RODC Password\
        \ Replication Group) peuvent \xEAtre r\xE9v\xE9l\xE9s sur l'ensemble des RODC.\n\
        \nIl est recommand\xE9 de vider ce groupe et d'utiliser des groupes sp\xE9\
        cifiques dans la PRP (Password Replication Policy) de chaque RODC."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Dangerous configuration of replication groups for read-only domain
            controllers (RODCs) (allow) (Level 3)
          description: "# Vulnerability description\n\nThe *Allowed RODC Password\
            \ Replication Group* (Groupe de r\xE9plication de mot de passe RODC autoris\xE9\
            e) is not empty."
          annotation: "# Recommended measure\n\nAccounts belonging to the *Allowed\
            \ RODC Password Replication Group* (Groupe de r\xE9plication de mot de\
            \ passe RODC autoris\xE9e) have their password hashes revealed on all\
            \ RODCs.\n\nThis group should be emptied, and dedicated groups should\
            \ only be added to the Password Replication Policy of each relevant RODC."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_rodc_denied_group-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_rodc_denied_group-l3
      name: "Configuration dangereuse des groupes de r\xE9plication pour les contr\xF4\
        leurs de domaine en lecture seule (RODC) (denied) (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLe groupe *Groupe de\
        \ r\xE9plication de mot de passe RODC refus\xE9e* (Denied RODC Password Replication\
        \ Group) ne poss\xE8de pas l'ensemble de ses membres par d\xE9faut."
      annotation: "# Recommandation\n\nLe groupe *Groupe de r\xE9plication de mot\
        \ de passe RODC refus\xE9e* (Denied RODC Password Replication Group) doit\
        \ avoir au minimum les membres suivants (int\xE9gr\xE9s par d\xE9faut) :\n\
        \n* *Contr\xF4leurs de domaine* (Domain Controllers);\n* *Contr\xF4leurs de\
        \ domaine en lecture seule* (Read-only Domain Controllers);\n* *Propri\xE9\
        taires cr\xE9ateurs de la strat\xE9gie de groupe* (Group Policy Creator Owners);\n\
        * *Administrateurs du domaine* (Domain Admins);\n* *\xC9diteurs de certificats*\
        \ (Cert Publishers);\n* *Administrateurs de l'entreprise* (Enterprise Admins);\n\
        * *Administrateurs du sch\xE9ma* (Schema Admins);\n* *KRBTGT* (KRBTGT)."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Dangerous configuration of replication groups for read-only domain
            controllers (RODCs) (denied) (Level 3)
          description: "# Vulnerability description\n\nSome default groups are missing\
            \ from the *Denied RODC Password Replication Group* (Groupe de r\xE9plication\
            \ de mot de passe RODC refus\xE9e)."
          annotation: "# Recommended measure\n\nThe *Denied RODC Password Replication\
            \ Group* (Groupe de r\xE9plication de mot de passe RODC refus\xE9e) must\
            \ include the following members:\n\n* *Domain Controllers* (Contr\xF4\
            leurs de domaine);\n* *Read-only Domain Controllers* (Contr\xF4leurs de\
            \ domaine en lecture seule);\n* *Group Policy Creator Owners* (Propri\xE9\
            taires cr\xE9ateurs de la strat\xE9gie de groupe);\n* *Domain Admins*\
            \ (Administrateurs du domaine);\n* *Cert Publishers* (\xC9diteurs de certificats);\n\
            * *Enterprise Admins* (Administrateurs de l'entreprise);\n* *Schema Admins*\
            \ (Administrateurs du sch\xE9ma);\n* *KRBTGT* (KRBTGT)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_rodc_orphan_krbtgt-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_rodc_orphan_krbtgt-l3
      name: Comptes krbtgt de RODC orphelins (Niveau 3)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes `krbtgt`\
        \ sont pr\xE9sents mais ne sont plus associ\xE9s \xE0 des RODC."
      annotation: "# Recommandation\n\nLes comptes `krbtgt` inutilis\xE9s peuvent\
        \ \xEAtre supprim\xE9s."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Orphan RODC krbtgt accounts (Level 3)
          description: '# Vulnerability description


            Orphaned `krbtgt` accounts are present and not linked to a RODC server.'
          annotation: '# Recommended measure


            Unused `krbtgt` accounts can be deleted.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_sidhistory_present-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_sidhistory_present-l3
      name: Comptes ou groupes ayant un historique de SID (Niveau 3)
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes comptes ou groupes\
        \ de la for\xEAt poss\xE8dent un attribut `sIDHistory` non vide.\n\nLa pr\xE9\
        sence de `sIDHistory` entraine inutilement la g\xE9n\xE9ration d'\xE9v\xE8\
        nements Windows 4665 et 4666, ce qui peut rendre plus difficile la supervision.\
        \ De plus, leur utilisation l\xE9gitime impose un affaiblissement de la s\xE9\
        curit\xE9 des relations d'approbation.\n\nNote : seuls les 10000 premiers\
        \ objets sont affich\xE9s."
      annotation: "# Recommandation\n\nLa propri\xE9t\xE9 `sIDHistory` permet de rajouter\
        \ un identifiant de s\xE9curit\xE9 (SID) arbitraire dans la liste des groupes\
        \ d'un compte utilisateur ou machine. Ce m\xE9canisme est principalement utilis\xE9\
        \ lors de la migration de comptes d'un domaine \xE0 un autre pour perp\xE9\
        tuer l'acc\xE8s \xE0 d'anciennes ressources. Il peut \xE9galement \xEAtre\
        \ utilis\xE9 par des attaquants pour s'accorder ill\xE9gitimement des droits\
        \ d'acc\xE8s.\n\nL'attribut `sIDHistory` doit \xEAtre effac\xE9 pour tous\
        \ les comptes et groupes concern\xE9s d\xE8s lors que les op\xE9rations de\
        \ migration ont \xE9t\xE9 effectu\xE9es."
      implementation_groups:
      - level_3
      translations:
        en:
          name: Accounts or groups with SID history set (Level 3)
          description: '# Vulnerability description


            Several accounts or groups in the forest have their `sIDHistory` attribute
            set.


            Whenever set, the `sIDHistory` attribute causes Windows event IDs 4665
            et 4666 to be generated uselessly, which can make log monitoring more
            difficult. Moreover, its legitimate use weakens the security of Kerberos
            trusts.


            Note: Only the first 1000 objects are shown.'
          annotation: '# Recommended measure


            The `sIDHistory` attribute allows appending an additional security identifier
            (SID) in their group list. This mechanism is mainly used during migrations
            from one domain to another, to keep access to previous resources. It can
            also be exploited by attackers to grant themselves illegitimate access
            rights.


            The `sIDHistory` attribute must be erased for all accounts and groups
            aforementioned, as soon as domain migrations are completed.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_trusts_tgt_deleg-l3
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_trusts_tgt_deleg-l3
      name: "Relations d'approbation entrante avec d\xE9l\xE9gation (Niveau 3)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes relations d'approbation\
        \ autorisent explicitement la d\xE9l\xE9gation Kerberos. Par construction,\
        \ ces relations permettent aux ressources externes approuv\xE9es de pouvoir\
        \ s'authentifier avec l'identit\xE9 des comptes qui s'y connectent (comptes\
        \ membres de la for\xEAt analys\xE9e). Cela permet \xE0 un attaquant ayant\
        \ compromis le domaine externe approuv\xE9 d'\xE9lever ses privil\xE8ges vers\
        \ le domaine local approbateur."
      annotation: "# Recommandation\n\nUne relation d'approbation entrante permet\
        \ d'\xEAtre approuv\xE9 par un domaine externe ou une for\xEAt tierce. Cela\
        \ permet aux comptes de se connecter \xE0 des ressources externes \xE0 la\
        \ for\xEAt.\n\nUne relation d'approbation entrante doit interdire la d\xE9\
        l\xE9gation Kerberos vers la ressource approbatrice. \xC0 partir de <span\
        \ style=\"background-color:rgb(255, 165, 0);color:rgb(0, 0, 0)\">Windows 2012</span>\
        \ il est possible de d\xE9sactiver la d\xE9l\xE9gation de TGT \xE0 l'aide\
        \ de la commande : `netdom trust <domaine> /domain:<domaine_externe_approuv\xE9\
        > /EnableTGTDelegation:no`"
      implementation_groups:
      - level_3
      translations:
        en:
          name: Inbound trust relationships with delegation (Level 3)
          description: '# Vulnerability description


            Some trust relationships explicitly allow Kerberos delegation. By design,
            inbound trusts allow delegating Kerberos tickets, which allows third-party
            resources to authenticate as the account that authenticated to them. This
            may lead to privilege escalation from the trusted external domain to the
            trusting local domain.'
          annotation: '# Recommended measure


            Inbound trust relationships allow a domain to be trusted by a third-party
            domain or forest. This allows accounts to use third-party resources outside
            their forest.


            Any inbound trust must deny Kerberos delegation to the trusting resource.
            It is possible to disable TGT delegation with <span style="background-color:rgb(255,
            165, 0);color:rgb(0, 0, 0)">Windows 2012</span> and later, through the
            command: `netdom trust <domain> /domain:<trusted domain> /EnableTGTDelegation:no`'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_group_loop-l4
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_group_loop-l4
      name: "Pr\xE9sences de boucles d'imbrication de groupes (Niveau 4)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nLa pr\xE9sence de boucles\
        \ d'imbrication de groupes ne pr\xE9sente pas de danger pour la s\xE9curit\xE9\
        \ de l'Active Directory mais peut affecter le fonctionnement de diff\xE9rents\
        \ outils de s\xE9curit\xE9."
      annotation: "# Recommandation\n\nPar mesure d'hygi\xE8ne il est recommand\xE9\
        \ de nettoyer les boucles d'imbrication de groupes."
      implementation_groups:
      - level_4
      translations:
        en:
          name: Loops in group memberships (Level 4)
          description: '# Vulnerability description


            A loop in group memberships does not present a security issue for Active
            Directory but can affect security tools used to secure the domain.'
          annotation: '# Recommended measure


            For hygiene purpose it is recommended to remove the loops in group memberships.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_silo_priv-l4
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_silo_priv-l4
      name: "Membres des groupes privil\xE9gi\xE9s hors silo d'authentification (Niveau\
        \ 4)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes membres de groupes\
        \ privil\xE9gi\xE9s ne sont pas membres d'un silo d'authentification, ou celui-ci\
        \ n'est pas correctement configur\xE9. Le silo de strat\xE9gies d'authentification\
        \ doit \xEAtre appliqu\xE9 (`msDS-AuthNPolicySiloEnforced` doit \xEAtre positionn\xE9\
        \ \xE0 1)."
      annotation: "# Recommandation\n\nTous les utilisateurs privil\xE9gi\xE9s doivent\
        \ \xEAtre membres d'un silo d'authentification correctement configur\xE9.\n\
        \n## Contexte : groupes privil\xE9gi\xE9s\n\nLes groupes privil\xE9gi\xE9\
        s sont les groupes d'administration et les groupes op\xE9ratifs ayant tous\
        \ les droits et privil\xE8ges sur la for\xEAt ou pouvant se les attribuer\
        \ :\n\n* \xAB *Administrateurs* (Administrators) \xBB ;\n* \xAB *Contr\xF4\
        leurs de domaine* (Domain Controllers) \xBB;\n* \xAB *Administrateurs du sch\xE9\
        ma* (Schema Admins) \xBB ;\n* \xAB *Administrateurs de l'entreprise* (Enterprise\
        \ Admins) \xBB ;\n* \xAB *Administrateurs du domaine* (Domain Admins) \xBB\
        \ : ces administrateurs ont les privil\xE8ges de lire la base des secrets\
        \ de tous les comptes et donc d'extraire les secrets de l'ensemble des comptes\
        \ privil\xE9gi\xE9s ;\n* \xAB *Administrateurs de cl\xE9s* (Key Admins) \xBB\
        \ et \xAB *Administrateurs de cl\xE9s de l'entreprise* (Enterprise Key Admins)\
        \ \xBB: ces administrateurs peuvent fixer des valeurs arbitraires aux attributs\
        \ relatifs \xE0 Windows Hello for Business, pour tous les utilisateurs sauf\
        \ ceux prot\xE9g\xE9s par le m\xE9canisme d' `adminSDHolder`. Si l'authentification\
        \ bas\xE9e sur les certificats a \xE9t\xE9 activ\xE9e, ils peuvent g\xE9n\xE9\
        rer un certificat sous leur contr\xF4le, l'assigner \xE0 un compte privil\xE9\
        gi\xE9 (par exemple, un contr\xF4leur de domaine), et s'authentifier en tant\
        \ que lui ;\n* \xAB *Op\xE9rateurs de compte* (Account Operators) \xBB : ces\
        \ op\xE9rateurs peuvent administrer tous les comptes d'utilisateurs, machines\
        \ et groupes; \xE0 l'exception des comptes prot\xE9g\xE9s par l' `adminSDHolder`;\n\
        * \xAB *Op\xE9rateurs de serveur* (Server Operators) \xBB : ces op\xE9rateurs\
        \ peuvent administrer les contr\xF4leurs de domaine, et donc r\xE9cup\xE9\
        rer les secrets de tous les comptes privil\xE9gi\xE9s ;\n* \xAB *Op\xE9rateurs\
        \ de sauvegarde* (Backup Operators) \xBB : ces op\xE9rateurs peuvent sauvegarder\
        \ un contr\xF4leur de domaine et donc extraire les secrets de tous les comptes\
        \ privil\xE9gi\xE9s depuis cette sauvegarde ;\n* \xAB *Op\xE9rateurs d'impression*\
        \ (Print Operators) \xBB : ces op\xE9rateurs peuvent charger des pilotes d'impression\
        \ sur les contr\xF4leurs de domaine et donc charger un pilote malveillant\
        \ pour par exemple extraire les secrets de tous les comptes privil\xE9gi\xE9\
        s.\n\nLes groupes \xAB op\xE9rateurs \xBB sont vides par d\xE9faut et ne devraient\
        \ contenir aucun membre."
      implementation_groups:
      - level_4
      translations:
        en:
          name: Privileged group members not in an authentication silo (Level 4)
          description: '# Vulnerability description


            Some privileged group members are not member of an authentication silo,
            or it''s not properly configured. The authentication policy silo must
            be enforced (`msDS-AuthNPolicySiloEnforced` must be set to 1).'
          annotation: "# Recommended measure\n\nAll privileged group members must\
            \ be in a properly configured authentication silo.\n\nThe \xAB operators\
            \ \xBB groups are empty by default and must not have any member.\n\n##\
            \ Context: privileged groups\n\nPrivileged groups include administrator\
            \ groups and operator groups which have full control over the Active Directory\
            \ forest either by design, or by granting themselves such privileges:\n\
            \n* \xAB *Administrators* (Administrateurs) \xBB;\n* \xAB *Domain Controllers*\
            \ (Contr\xF4leurs de domaine) \xBB;\n* \xAB *Schema Admins* (Administrateurs\
            \ du sch\xE9ma) \xBB;\n* \xAB *Enterprise Admins* (Administrateurs de\
            \ l'entreprise) \xBB;\n* \xAB *Domain Admins* (Administrateurs du domaine)\
            \ \xBB: these administrators are able to read the authentication database\
            \ and extract password hashes and other secrets of all privileged accounts;\n\
            * \xAB *Key Admins* (Administrateurs de cl\xE9s) \xBB and \xAB *Enterprise\
            \ Key Admins* (Administrateurs de cl\xE9s de l'entreprise) \xBB: these\
            \ administrators can set arbitrary values to attributes relating to Windows\
            \ Hello for Business, for all users except those protected by the `adminSDHolder`\
            \ mechanism. If certificate-based authentication has been enabled, they\
            \ can generate a certificate that they control, assign it to privileged\
            \ accounts (for instance, a domain controller), and log on as them;\n\
            * \xAB *Account Operators* (Op\xE9rateurs de compte) \xBB: these operators\
            \ can manage user accounts, machine accounts and groups except accounts\
            \ protected by the `adminSDHolder` mechanism;\n* \xAB *Server Operators*\
            \ (Op\xE9rateurs de serveur) \xBB: these operators can manage domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database;\n* \xAB *Backup Operators* (Op\xE9\
            rateurs de sauvegarde) \xBB: these operators can back up a domain controller,\
            \ which grants them the ability to recover privileged user secrets from\
            \ that backup;\n* \xAB *Print Operators* (Op\xE9rateurs d'impression)\
            \ \xBB: these operators can load arbitrary printer drivers on domain controllers,\
            \ which grants them the ability to recover privileged user secrets directly\
            \ from the authentication database (by loading a malicious driver)."
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_smartcard_expire_passwords-l4
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_smartcard_expire_passwords-l4
      name: "Comptes utilisateurs de carte \xE0 puce sans expiration de mot de passe\
        \ (Niveau 4)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nDes domaines ne positionnent\
        \ pas l'attribut `msDS-ExpirePasswordsOnSmartCardOnlyAccounts`."
      annotation: "# Recommandation\n\nDans le cadre de l'authentification par carte\
        \ \xE0 puce sur les domaines Windows, il est possible de configurer l'annuaire\
        \ Active Directory pour permettre au mot de passe de changer automatiquement\
        \ en respectant la politique mise en place. Ce changement automatique est\
        \ effectu\xE9 si l'attribut `msDS-ExpirePasswordsOnSmartCardOnlyAccounts`\
        \ de la racine des domaines est positionn\xE9. Cet attribut n'est pr\xE9sent\
        \ et actif que lorsque le niveau fonctionnel du domaine est <span style=\"\
        background-color:rgb(40, 167, 69);color:rgb(255, 255, 255)\">Windows 2016\
        \ / 2019 / 2022</span> ou sup\xE9rieur.\n\nIl est recommand\xE9 de positionner\
        \ l'attribut `msDS-ExpirePasswordsOnSmartCardOnlyAccounts` \xE0 la racine\
        \ des domaines, m\xEAme si les cartes \xE0 puce ne sont pas actuellement utilis\xE9\
        es."
      implementation_groups:
      - level_4
      translations:
        en:
          name: Missing password expiration for smart card users (Level 4)
          description: '# Vulnerability description


            Some domains do not set the `msDS-ExpirePasswordsOnSmartCardOnlyAccounts`
            attribute.'
          annotation: '# Recommended measure


            When smart card authentication is used in Windows domains, it is possible
            to set up the directory to automatically rotate the password so as to
            match the password policy enforced. That automatic rotation is automatically
            enforced if the `msDS-ExpirePasswordsOnSmartCardOnlyAccounts` attribute
            is set on the root of each domain. The aforementioned attribute is only
            defined and effective if the domain functional level is <span style="background-color:rgb(40,
            167, 69);color:rgb(255, 255, 255)">Windows 2016 / 2019 / 2022</span> or
            above.


            The `msDS-ExpirePasswordsOnSmartCardOnlyAccounts` attribute should be
            set at the root of each domain, even if smart cards are not currently
            used.'
    - urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:vuln_user_accounts_machineaccountquota-l4
      assessable: true
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:anssi-points-de-controle-active-directory:assessment_item_list
      ref_id: vuln_user_accounts_machineaccountquota-l4
      name: "Ajout de machines au domaine non limit\xE9 (Niveau 4)"
      description: "# Description de la vuln\xE9rabilit\xE9\n\nPar d\xE9faut les utilisateurs\
        \ authentifi\xE9s peuvent joindre 10 machines au domaine. Cette valeur est\
        \ contr\xF4l\xE9e par l'attribut `ms-DS-MachineAccountQuota` de la racine\
        \ du domaine.\n\nLes comptes machine ajout\xE9s ont alors pour propri\xE9\
        taire le compte utilis\xE9, lui offrant un contr\xF4le total dessus. La vuln\xE9\
        rabilit\xE9 CVE-2021-42287 utilisait des machines jointes pour r\xE9aliser\
        \ une \xE9l\xE9vation de privil\xE8ges."
      annotation: "# Recommandation\n\nPositionner l'attribut `ms-DS-MachineAccountQuota`\
        \ \xE0 0 \xE0 la racine des domaines concern\xE9s. La correction est g\xE9\
        n\xE9ralement effectu\xE9e \xE0 l'aide des consoles `dsa.msc`, `adsiedit.msc`\
        \ ou de l'utilitaire `ldp`."
      implementation_groups:
      - level_4
      translations:
        en:
          name: Unrestricted domain join (Level 4)
          description: '# Vulnerability description


            By default authenticated users may join up to 10 computers to the domain.
            This value is controlled by the `ms-DS-MachineAccountQuota` attribute
            in the root object,


            Machine accounts added that way are owned by the used account, offering
            it full control. The CVE-2021-42287 vulnerability used such machine account
            to elevate privileges.'
          annotation: '# Recommended measure


            Set the `ms-DS-MachineAccountQuota` attribute to 0 in the domain root
            objects. Fixing usually requires using `dsa.msc`, `adsiedit.msc` or the
            `ldp` utility.'
