Remédiation Active Directory avec Ping Castle

Utilisateurs ou ordinateurs inactifs

S-PwdLastSet-Cluster

S-PwdLastSet-45

S-PwdLastSet-90

S-DC-Inactive

S-PwdLastSet-DC

S-Inactive

S-C-Inactive

Topographie du réseau

S-DC-SubnetMissing

S-FirewallScript

Configuration des objets

S-C-PrimaryGroup

S-PrimaryGroup

S-Reversible

S-C-Reversible

S-NoPreAuth

S-NoPreAuthAdmin

S-DefaultOUChanged

S-PwdNotRequired

Des comptes utilisateurs n’ont pas besoin de mot de passe pour s’authentifier. Ce n’est pas grave pour les comptes désactivés, mais la configuration est anormale pour des comptes utilisateurs actifs. Pour chaque compte concerné, vous pouvez

Get-ADUser -Filter {(Enabled -eq $true) -and (UserAccountControl -band 32)} -Properties PasswordLastSet, LastLogonDate |
    Select-Object Name, SamAccountName, LastLogonDate, PasswordLastSet

S-PwdNeverExpires

Selon Ping Castle, il ne devrait avoir qu’un seul compte par domaine avec la case “Password never expires” cochée : le compte Administrateur par défaut (SID 500).

Pour résoudre cette vulnérabilité, il faut :

1. retravailler sa stratégie de mot de passe par défaut
2. déployer de nouvelles stratégies de mot de passe à grain fin si besoin
3. identifier tous les comptes avec un mot de passe qui n’expire jamais
4. assigner les comptes à une politique de mot de passe (par défaut ou ciblée)
5. définir des lots d’activation de l’expiration de mot de passe
6. communiquer aux utilisateurs et aux gestionnaires des comptes de services / comptes génériques sur :
   • les bonnes pratiques de sécurité
   • la procédure de changement de mot de passe
   • la nouvelle stratégie de sécurité
7. préparer la première vague de renouvellement de mot de passe avec le support informatique

Il est recommandé de lisser la charge au mieux (pas plus de 100 utilisateurs par semaine par exemple) pour éviter les pics d’appels au support informatique.

Rappel : dans ses recommandations relatives à l’authentification multifacteur et aux mots de passe, l’ANSSI ne recommande plus d’expiration régulière des mots de passe pour les comptes non sensibles (partie 4.4).

Voici un script pour lister l’intégralité des comptes avec un mot de passe qui n’expire jamais, en ajoutant une colonne “PasswordAge” qui affiche l’âge du mot de passe en jours :

$users = Get-ADUser -Filter {(PasswordNeverExpires -eq $true) -and (Enabled -eq $true)} -Properties PasswordLastSet, PasswordNeverExpires
$users |
    Select-Object Name, UserPrincipalName, PasswordLastSet,
        @{N='PasswordAge';E={[int](New-Timespan $_.PasswordLastSet).TotalDays}} |
    Sort-Object PasswordAge -Descending

Voici un exemple de résultat du script :

Il est tout à fait possible de “mettre la poussière sous le tapis” en basculant les comptes utilisateurs vers une PSO qui n’impose pas d’expiration de mot de passe. De cette manière, vous pourrez décocher la case sans avoir aucun impact à prévoir. En revanche, la sécurité du domaine ne sera pas améliorée.

S-KerberosArmoring

S-KerberosArmoringDC

S-JavaSchema

S-SIDHistory

S-TerminalServicesGPO

S-DefenderASR

S-FolderOptions

OS obsolètes

S-FunctionalLevel1 / S-FunctionalLevel3 / S-FunctionalLevel4

Ce point est similaire à toutes les DFL & FFL obsolètes, il regroupe donc les vulnérabilités suivantes :

Pour ça pas de miracles, il faut :

1. Monter de nouveaux contrôleurs de domaine
2. Basculer les rôles FSMO
3. Décommissionner les anciens contrôleurs de domaine
4. Faire la montée de version du domaine et de la forêt

S-DC-2000 / S-DC-2003 / S-DC-2008 / S-DC-2012

Ce point est similaire à tous les contrôleurs de domaine avec un OS obsolète, il regroupe donc les vulnérabilités suivantes :

Voici une commande pour lister tous les contrôleurs de domaine et leur système d’exploitation :

Get-ADDomainController -Filter * |
  Sort-Object OperatingSystem |
  Format-Table Name, OperatingSystem

Ce point est souvent lié aux vulnérabilités S-FunctionalLevel1 / S-FunctionalLevel3 / S-FunctionalLevel4.

Liens utiles :

• dcpromo dans Windows Server | Microsoft Learn
• Transfer or seize Operation Master roles - Windows Server | Microsoft Learn
• Comment rétrograder des contrôleurs de domaine et des domaines à l’aide de Server Manager ou de PowerShell | Microsoft Learn

S-OS-W10 / S-OS-2000 / S-OS-Win7 / S-OS-Win8 / S-OS-NT / S-OS-2003 / S-OS-2008 / S-OS-2012 / S-OS-Vista / S-OS-XP

Ce point est similaire à tous les OS obsolètes, il regroupe donc les vulnérabilités suivantes :

Voici une commande PowerShell pour faire l’inventaire par OS des comptes ordinateurs actifs :

Get-ADComputer -Filter {Enabled -eq $true} -Properties OperatingSystem |
    Group-Object OperatingSystem |
    Sort-Object Count -Descending

Pour la résolution, pas de miracles : il faut remplacer ou mettre à jour les ordinateurs concernés. Il s’agit souvent de payer une dette technique qui s’est accumulée sur plusieurs années et qui impacte lourdement l’organisation.

Le remplacement de ces OS est à initier dès le début du projet de remédiation, car il invoque plusieurs contacts techniques différents et a des implications dans certains applicatifs sensibles.

Pour la priorisation des tâches, il a deux choix possibles :

• soit procéder par ordre chronologique (2003 puis 2008 puis 2012 par exemple) pour réduire le score Ping Castle rapidement
• soit procéder par ordre de grandeur (commencer par les OS obsolètes les plus rares et finir par les plus communs) pour obtenir des victoires rapides

Voici un exemple de script pour lister l’ensemble des OS obsolètes. Le script est à adapter suivant votre contexte client :

Get-ADComputer -Filter {Enabled -eq $true} -Properties OperatingSystem, OperatingSystemVersion, LastLogonDate |
    Where-Object {
        $_.OperatingSystem -like 'Windows Server 2012*' -or
        $_.OperatingSystem -like 'Windows Server 2008*' -or
        $_.OperatingSystem -like 'Windows 7*' -or 
        $_.OperatingSystemVersion -in ('10.0 (17134)', '10.0 (18362)', '10.0 (18363)', '10.0 (19041)', '10.0 (19042)', '10.0 (19044)')} |
    Select-Object Name, Enabled, LastLogonDate, OperatingSystem, OperatingSystemVersion |
    Sort-Object OperatingSystem |
    Format-Table -AutoSize

Anciens protocoles d’authentification

S-AesNotEnabled

S-DesEnabled

Le chiffrement DES pour Kerberos est considéré comme très peu sécurisé. En 2016, on pouvait casser le chiffrement en une quinzaine de jours avec une carte graphique à environ 1000$.

De nos jours, on peut partir du principe qu’une trame chiffrée avec DES peut être cassée par n’importe quel attaquant en peu de temps.

Voici une commande pour lister les objets qui utilisent DES comme méthode de chiffrement pour Kerberos :

Get-ADObject -Filter {UserAccountControl -band 0x200000 -or msDs-supportedEncryptionTypes -band 3}

Pour résoudre ce point, il faut dresser la liste de tous les objets qui utilisent DES (fréquemment des comptes ordinateurs) et investiguer pour chaque objet. La plupart du temps, il s’agit d’une configuration pour la compatibilité avec une application.

La configuration de l’application doit être modifiée (si possible) et la case “Use Kerberos DES encryption types for this account” doit être décochée sur l’objet Active Directory.

Si vous ne faites que décocher la case sans modifier la configuration côté applicatif, le compte Active Directory pourra venir “recocher” la case.

Pour décocher la case en masse, voici la commande :

Get-ADObject -Filter {UserAccountControl -band 0x200000} | ForEach-Object {
    Set-ADAccountControl $_ -UseDESKeyOnly $false
}

Voici la documentation de Microsoft sur le sujet : Supprimer le chiffrement DES très peu sécurisé des comptes d’utilisateur | Microsoft Learn

S-SMB-v1

S-OldNtlm

Le meilleur article sur le sujet du NTLM (v1 et v2) est disponible ici : NTLM authentication: What it is and why it’s risky

Provisionnement

S-DCRegistration

S-ADRegistration

S-ADRegistrationSchema

Replication

S-Duplicate

Gestion de vulnérabilité

S-Vuln-MS14-068

S-Vuln-MS17_010

S-DC-NotUpdated

S-WSUS-UserProxy

S-WSUS-HTTP

S-WSUS-NoPinning

Anciens protocoles

T-Downlevel

T-AlgsAES

Filtrage des SID

T-SIDFiltering

SIDHistory

T-SIDHistorySameDomain

S-Domain$$$

T-SIDHistoryDangerous

T-SIDHistoryUnknownDomain

Imperméabilité des relations d’approbation

T-FileDeployedOutOfDomain

T-TGTDelegation

T-ScriptOutOfDomain

Relations d’approbation inactives

T-Inactive

Relation d’approbation avec Azure

T-AzureADSSO

J’ai déjà écrit un article technique sur le sujet disponible ici : Rotation du mot de passe de AZUREADSSOACC

Appropriation de comptes

P-Delegated

P-Kerberoasting

Au moins un compte à privilège porte des valeurs dans l’attribut servicePrincipalName. Cette configuration peut alors être utilisée par un attaquant pour usurper l’identité du compte avec l’attaque Kerberoasting.

Vous pouvez utiliser le script suivant pour trouver tous les comptes à haut privilèges avec un SPN :

Get-ADUser -Filter {adminCount -eq 1} -Properties servicePrincipalName |
    Where-Object {$_.ServicePrincipalName}

Le compte krbtgt portent naturellement le SPN kadmin/changepw : pas d’inquiétude à avoir là-dessus.

La plupart du temps, il s’agit de SPN qui pointent vers des instances SQL, comme par exemple :

• MSSQLSvc/SRV001.contoso.com:1433
• MSSQLSvc/SRV001.contoso.com
• MSSQLSvc/SRV002.contoso.com:1433
• MSSQLSvc/SRV002.contoso.com

Dans ce cas, la première chose est de vérifier que les serveurs/services indiqués dans le SPN existent toujours. Si ceux-ci n’existent plus, vous pouvez supprimer les valeurs correspondantes. Si les serveurs/services sont toujours utilisés, il vous reste deux choix :

1. Migrer tous les services associés au(x) compte(s) vers un autre compte de service avec moins de privilèges
2. Diminuer les privilèges du compte existant

P-AdminPwdTooOld

Au moins un compte à privilège possède un mot de passe vieux de trois ans ou plus. Voici un script pour les identifier rapidement :

Get-ADUser -Filter {(Enabled -eq $true) -and (adminCount -eq 1)} -Properties PasswordLastSet |
    Where-Object {$_.PasswordLastSet -lt (Get-Date).AddYears(-3)}

Ici, au moins deux méthodes pour tricher :

• Abuser de la réinitialisation du mot de passe par un administrateur
• Mettre à jour la date de changement de mot de passe

Tricher sur cette métrique fera plaisir à la fois à Ping Castle et à l’attaquant qui utilisera ce compte pour faire tomber votre domaine.

La méthode propre est évidemment de changer le mot de passe et/ou diminuer les permissions des comptes concernés.

P-ProtectedUsers

P-LogonDenied

C’est la première pierre du tiering model Active Directory. Sur cette métrique, c’est le groupe “Admins du domaine” qui est ciblé et qui devrait être interdit de connexion sur toutes les ressources du Tier 2 (ordinateurs personnels principalement).

Pour résoudre ce point, vous devez d’abord créer de nouveaux comptes à privilège qui ne sont pas administrateurs du domaine pour accéder aux ordinateurs personnels en tant qu’administrateur local.

Ensuite, vous pouvez créer une nouvelle GPO qui s’appliquera au moins sur les ordinateurs personnels de votre domaine, avec la configuration suivante : Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateurs

À voir si vous préférez faire une exception sur votre compte brise-glace pour qu’il puisse se connecter n’importe où.

Comme toutes les vérifications GPO de Ping Castle, à partir du moment où la GPO existe dans le domaine : le risque est considéré comme résolu. En réel, le périmètre d’application de la GPO a évidemment une importance majeure et celle-ci devrait être appliquée à toutes les ressources du Tier 2.

P-DisplaySpecifier

Vérification des ACL

P-DCOwner

P-DangerousExtendedRight

P-DsHeuristicsDoListObject

P-DNSAdmin

P-DNSDelegation

P-DelegationLoginScript

P-DelegationKeyAdmin

P-ExchangePrivEsc

P-ExchangeAdminSDHolder

P-DelegationFileDeployed

P-DelegationGPOData

P-DsHeuristicsAdminSDExMask

P-LoginDCEveryone

P-RecoveryModeUnprotected

Contrôle des comptes administrateurs

P-Inactive

P-AdminLogin

Cette vulnérabilité indique que le compte Administrateur par défaut (SID-500) a été utilisé récemment. Pour rappel : le compte Administrateur par défaut ne doit être utilisé qu’en cas de dernier recours, et vous devez utiliser des comptes nominatifs pour les actions quotidiennes sur le Tier 0.

Si l’usage de ce compte sort de ce contexte d’urgence absolue, vous devez :

• trouver la source de l’utilisation du compte avec l’évenement 4624
• arrêter l’utilisation de ce compte en fournissant une alternative (en suivant le principe du moindre privilège)
• réinitialiser le mot de passe du compte Administrateur

P-AdminNum

P-OperatorsEmpty

Chemins de contrôle

P-AdminEmailOn

P-ControlPathIndirectEveryone

P-ControlPathIndirectMany

Vérification des délégations

P-DelegationEveryone

P-UnkownDelegation

Des permissions dans Active Directory ne peuvent pas être résolues (SID orphelins), ce qui peut être expliqué par une délégation accordée à un objet d’un autre domaine Active Directory et/ou que le principal qui portait la permission à été supprimé.

Vous pouvez vérifier que la provenance des SID inconnus en les comparant aux DomainSID connus :

$domains = @()
$domains += (Get-ADDomain).DNSRoot
$domains += (Get-ADTrust -Filter *).Name
$domains | ForEach-Object {
    Get-ADDomain $_ | Select-Object DNSRoot, DomainSID
}

Et pour rechercher un SID dans la corbeille Active Directory, vous pouvez utiliser la commande suivante :

Get-ADObject -Filter {ObjectSID -eq 'S-1-5-21-1519513455-2607746426-4144247390-102133'} -IncludeDeletedObjects -Properties Modified

Pensez également à vérifier dans les SIDHistory lors votre recherche des SID orphelins.

P-DelegationDCt2a4d

P-DelegationDCa2d2

P-DelegationDCsourcedeleg

P-UnconstrainedDelegation

Changement irréversible

P-SchemaAdmin

P-UnprotectedOU

Certaines unités d’organisation ne sont pas protégées contre la suppression accidentelle. Vous pouvez résoudre facilement ce point avec le script suivant :

Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion |
    Where-Object {$_.ProtectedFromAccidentalDeletion -eq $false} |
    Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion:$true -Verbose

P-RecycleBin

Contrôle des privilèges

P-ServiceDomainAdmin

P-TrustedCredManAccessPrivilege

P-PrivilegeEveryone

Contrôleurs de domaine en lecture seule (RODC)

P-RODCRevealOnDemand

P-RODCAdminRevealed

P-RODCSYSVOLWrite

P-RODCNeverReveal

P-RODCAllowedGroup

P-RODCDeniedGroup

P-RODCKrbtgtOrphan

Audit

A-AuditPowershell

Création d’une nouvelle GPO ordinateurs “Audit PowerShell” à la racine du domaine avec la configuration suivante : Configuration ordinateur > Stratégies > Modèles d’administration > Composants Windows > Windows PowerShell

• Activer l’enregistrement des modules : Activé
  • Noms des modules : *
• Activer la journalisation de bloc de scripts PowerShell : Activé
  • Consigner les événements de début/de fin des appels de blocs de script : Activé

A-AuditDC

Sauvegarde

A-BackupMetadata

A-NotEnoughDC

Golden Ticket

A-Krbtgt

Vulnérabilités liées aux groupes restreints

A-MembershipEveryone

Reniflage du réseau

A-LMHashAuthorized

Ce paramètre a probablement été activé pour des raisons de compatibilité avec des vieilles versions de Windows Server (avant 2003). Si votre domaine ne contient plus de Windows Server 2000 ou antérieur, vous devriez pouvoir désactiver ce paramètre sans risque.

Plus d’information sur le hash LM ici : LM, NTLM, Net-NTLMv2, oh my!. A Pentester’s Guide to Windows Hashes | by Péter Gombos | Medium

A-DnsZoneAUCreateChild

Par défaut, le fait de créer un enregistrement DNS est autorisé pour tous les utilisateurs et ordinateurs du domaine (Authenticated Users). Une façon rapide de réduire le risque lié à cette vulnérabilité est de remplacer cette permission accordée à Authenticated Users par une permission ciblée sur Domain Computers. Pour certaines zones DNS, on peut même envisager de supprimer cette permission (à voir au cas par cas).

Le code proposé remplace les permissions données à Authenticated Users pour Domain Computers sur toutes les zones DNS. Il est inspiré ce celui de WS IT-Solutions (article en allemand).

# Get 'Domain Computers' group
$domainSID = (Get-ADDomain).DomainSID.Value
$domainComputers = [System.Security.Principal.NTAccount]::New((Get-ADGroup "$domainSID-515").SamAccountName)

# Get all dnsZones
$domainDn = (Get-ADDomain).DistinguishedName
$dnsZones = "CN=MicrosoftDNS,DC=DomainDnsZones,$DomainDn", "CN=MicrosoftDNS,DC=ForestDnsZones,$DomainDn" | ForEach-Object {
    Get-ADObject -Filter { objectClass -eq 'dnsZone' } -SearchBase $_ -Properties NTSecurityDescriptor
}

# Variables for permissions
$createChild = [System.DirectoryServices.ActiveDirectoryRights]::CreateChild
$allow = [System.Security.AccessControl.AccessControlType]::Allow

# Replace permissions for 'Authenticated Users' by 'Domain Computers'
$dnsZones | ForEach-Object {
    Write-Host $_.Name -ForegroundColor Yellow
    $acl = $_.NTSecurityDescriptor

    $acl.Access | Where-Object {
        $_.IdentityReference -eq 'NT AUTHORITY\Authenticated Users' -and
        $_.IsInherited -eq $false -and
        $_.ActiveDirectoryRights -eq $createChild -and
        $_.AccessControlType -eq $allow
    } | ForEach-Object {

        # Remove permission for 'Authenticated Users'
        $acl.RemoveAccessRuleSpecific($_)

        # Create and add permission for 'Domain Computers'
        $acl.AddAccessRule([System.DirectoryServices.ActiveDirectoryAccessRule]::New($domainComputers, $createChild, $allow))

        $updateAcl = $true
    }

    # Apply new ACL
    if ($updateAcl) {
        Write-Host "Modification have been made to the dnsZone!"
        Set-Acl -Path "AD:\$($_.DistinguishedName)" -AclObject $acl -Confirm:$false
    }

    $updateAcl = $false
}

A-DnsZoneUpdate2

A-DnsZoneUpdate1

A-NoGPOLLMNR

A-NTFRSOnSysvol

A-DCLdapSign

A-DCLdapsChannelBinding

A-SMB2SignatureNotEnabled

A-SMB2SignatureNotRequired

A-LDAPSigningDisabled

A-HardenedPaths

Suite à une CVE de 2015, il est nécessaire de renforcer les partages SYSVOL & NETLOGON d’attaques par spoofing (usurpation). Une GPO est attendue par Ping Castle pour résoudre la vulnérabilité.

La meilleure pratique est de créer une nouvelle GPO nommée “Chemins d’accès UNC renforcés” (par exemple), appliquée sur les contrôleurs de domaine avec la configuration suivante : Configuration ordinateur > Stratégies > Modèle d’administration > Réseau > Fournisseur réseau.

Vous pouvez activer le paramètre Chemin d’accès UNC renforcés et définir les valeurs suivantes :

Il existe un troisième paramètre RequirePrivacy=1 qui impose l’utilisation du chiffrement SMB, disponible seulement à partir de Windows 8 & Windows Server 2012. Si votre parc contient des OS plus anciens, n’ajoutez pas l’option.

Pour plus d’informations : Active Directory - Découverte des chemins UNC durcis

Pass-the-credential

A-SmartCardPwdRotation

Vous pouvez lister l’intégralité des objets qui requièrent l’utilisation d’une smart card avec la commande suivante :

Get-ADObject -Filter {UserAccountControl -band 262144}

En fonction des résultats obtenus, vous pouvez activer la fonctionnalité de rotation du hash de mot de passe automatique pour les comptes avec smart card sur votre domaine :

Set-ADObject (Get-ADDomain) -Replace @{ 'msDS-ExpirePasswordsOnSmartCardOnlyAccounts' = $true }

A-SmartCardRequired

A-ProtectedUsers

A-LAPS-Joined-Computers

A-LAPS-Not-Installed

A-DCRefuseComputerPwdChange

A-DC-Spooler

A-DC-WebClient

A-DC-Coerce

Récupération de mot de passe

A-ReversiblePwd

A-UnixPwd

A-PwdGPO

Reconnaissance

A-DsHeuristicsAllowAnonNSPI

A-DsHeuristicsAnonymous

A-AnonymousAuthorizedGPO

A-PreWin2000Anonymous

A-DnsZoneTransfert

A-NoNetSessionHardening

A-DsHeuristicsLDAPSecurity

A-DsHeuristicsDoNotVerifyUniqueness

A-PreWin2000AuthenticatedUsers

A-PreWin2000Other

A-RootDseAnonBinding

A-NullSession

Administrateurs temporaires

A-AdminSDHolder

Un ou plusieurs comptes n’ayant plus de privilèges ont encore la valeur 1 définie dans l’attribut adminCount. Cette valeur indique qu’un compte a fait partie d’un groupe à haut privilège (comme Domain Admins par exemple). Rien de grave a cela, il s’agit juste de vérifier que les comptes indiqués ont bien reçu leurs privilèges passés de manière légitime.

Voici une commande PowerShell pour nettoyer l’attribut sur les comptes illégitimes :

Get-ADUser -Filter {adminCount -eq 1} -Properties adminCount, NTSecurityDescriptor |
    Where-Object {$_.NTSecurityDescriptor.Access.IsInherited -eq $true} |
    Set-ADUser -Clear adminCount -Verbose

Et j’ai fait un article pour obtenir la date d’ajout/suppression d’un membre dans un groupe, ce qui peut être utile sur cette vulnérabilité : Trouver la date d’ajout d’un membre dans un groupe | LaBouaBouate.

Mots de passe faibles

A-LimitBlankPasswordUse

A-MinPwdLen

Une stratégie de mot de passe imposant moins de 8 caractères de long est présente dans le domaine. Le standard actuel dans les organisations est plutôt aux alentours de 12 caractères de long, et 8 caractères est considéré comme la limite basse. Pour résoudre cette vulnérabilité, vous n’avez qu’à augmenter le nombre de caractères minimum requis sur votre politique de mot de passe (Default Domain Password Policy ou Fine-grained Password Policy).

Modifier ce paramètre n’impacte pas les mots de passe qui ont déjà été définis, mais impactera tous les changements de mots de passe après modification de la politique. Il y a donc beaucoup de communication à faire en amont de ce changement pour éviter les impacts.

Pour modifier la Default Domain Password Policy à 12 caractères minimum :

Set-ADDefaultDomainPasswordPolicy -MinPasswordLength 12

Pour modifier la Fine-grained Password Policy nommée “Employees” à 12 caractères minimum :

Set-ADDefaultDomainPasswordPolicy -Identity 'Employees' -MinPasswordLength 12

A-Guest

Le compte “Invité” (Guest en anglais) est activé, ce qui permet à n’importe qui de se connecter à Active Directory. A moins d’une configuration spécifique, vous devez désactiver le compte au plus vite :

$domainSID = (Get-ADDomain).DomainSID
Set-ADUser -Identity "$domainSID-501" -Enabled:$false

A-NoServicePolicy

Aucune politique de mot de passe imposant une longueur minimum de 20 caractères n’a été trouvé (idéal pour les comptes de service). Si vous n’exécutez pas Ping Castle avec des privilèges d’administrateur du domaine, il est possible qu’il s’agissent d’un faux positif (la PSO existe mais vous ne la voyez pas). Vous pouvez lister les objets autorisés à lire les PSO avec la ligne de commande suivante :

$dn = "CN=Password Settings Container,CN=System,$((Get-ADDomain).DistinguishedName)"
(Get-ADObject $dn -Properties NTSecurityDescriptor).NTSecurityDescriptor.Access |
    Where-Object {$_.ActiveDirectoryRights -match 'ListChildren|GenericRead'} |
    Group-Object IdentityReference -NoElement |
    Format-Table -AutoSize

Et si vous n’avez pas de PSO pour les comptes de service, vous pouvez en créer une facilement avec la commande suivante :

$splat = @{
    # General settings
    Name = 'PSO - Service accounts'
    Description = 'Very strong passwords with longer lifetime'
    Precedence = 100
    ProtectedFromAccidentalDeletion = $true 
    # Password settings
    MaxPasswordAge = (New-TimeSpan -Days 370)
    MinPasswordAge = (New-TimeSpan -Days 1)
    MinPasswordLength = 20
    ComplexityEnabled = $true
    PasswordHistoryCount = 24
    ReversibleEncryptionEnabled = $false
    # Lockout settings
    LockoutDuration = (New-TimeSpan -Days 1)
    LockoutObservationWindow = (New-TimeSpan -Days 1)
    LockoutThreshold = 10
}
New-ADFineGrainedPasswordPolicy @splat