Partager via


Comment empêcher vos administrateurs d’outrepasser votre politique de mot de passe (fr-FR)

 

 

Cet article explique comment il est possible d’outrepasser une politique de mot de passe et comment remédier à ce problème.

 

Introduction

Imaginez : Vous avez mis en place des Fine-Grained Password Policies (FGPP) pour vos comptes d'administration et vos comptes de service. Les FGPP sont bien configurées et appliquées, tout va bien dans le meilleur des mondes. Puis vous décidez de faire un audit sur vos comptes Active Directory, et là, vous vous apercevez que certains comptes de service et d'administration ont un mot de passe qui n'expire jamais ... Ils ne respectent donc pas la politique de mot de passe que vous avez définie avec vos FGPP.

Nous allons donc voir pourquoi il est possible d'outrepasser la politique de mot de passe que vous avez définie via vos FGPP et comment éviter ce type de transgression.

 

Attribut UserAccountControl et droits etendus

L’état d’un compte Active Directory est renseigné dans l’attribut UserAccountControl. Lorsque l’on modifie l’état d’un compte, par exemple en le désactivant, on modifie l’attribut UserAccountControl. Plus précisément, on modifie certains flags de l'attribut UserAccountControl.

Pour notre problématique, nous allons nous intéresser aux 3 flags suivants :

  • UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED : permet un stockage du mot de passe en utilisant un chiffrement réversible
  • UF_DONT_EXPIRE_PASSWD : permet de configurer un mot de passe sans expiration
  • UF_PASSWD_NOTREQD : permet d’utiliser un mot de passe vide

 
La configuration de ces flags a donc une incidence direct sur la politique de mot de passe des comptes.

Si vous voulez plus d'informations sur les différentes valeurs que peut prendre l'attribut UserAccountControl : How to use the UserAccountControl flags to manipulate user account properties

Les droits de modification de ces flags sont gérés par les 3 droits étendus suivant :

 

Ces droits étendus sont configurés à la racine du domaine. Il faut savoir que par défaut ces droits sont autorisés pour le groupe 'Utilisateurs Authentifiés" mais qu'il faut bien évidemment les droits de modification de l'attribut UserAccountControl pour les configurer.

 

Mise en situation

J'ai un domaine avec la politique de mot de passe par défaut et utilisateur standard (cthomas).

Cet utilisateur a les propriétés AllowReversiblePasswordEncryption, PasswordNeverExpires et PasswordNotRequired à la valeur "False"

 

J’ai maintenant un utilisateur du HelpDesk (HelpDeskUser01) à qui j’ai délégué la gestion des utilisateurs de manière assez large (création, suppression et modification des comptes utilisateurs) .

Cet utilisateur a donc les droits de modification de l'attribut UserAccountControl, il peut donc transgresser la politique de mot de passe définie pour cet utilisateur.

 

Identification des comptes avec ces flags

On peut utiliser des commandes Powershell avec le filtre LDAP suivant en remplaçant XXX par la valeur décimale du flag (voir : How to use the UserAccountControl flags to manipulate user account properties) :

(&(objectCategory=person)(userAccountControl:1.2.840.113556.1.4.803:=XXX))

Get-ADUser -LDAPFilter "(&(objectCategory=person)(userAccountControl:1.2.840.113556.1.4.803:=128))" -Properties AllowReversiblePasswordEncryption

Get-ADUser -LDAPFilter "(&(objectCategory=person)(userAccountControl:1.2.840.113556.1.4.803:=65536))" -Properties PasswordNeverExpires

Get-ADUser -LDAPFilter "(&(objectCategory=person)(userAccountControl:1.2.840.113556.1.4.803:=32))" -Properties PasswordNotRequired  

 

Remediation de la problematique

Pour empêcher vos administrateur d’outrepasser votre politique de mot de passe, il faut leur interdire l’utilisation des droits étendus que nous avons vu précédemment au niveau du domaine.

Plusieurs solutions sont possibles et dépendent de votre méthodologie d’implémentation de la délégation d’administration.

Vous pouvez décider de créer un groupe par droit étendu (pour être très granulaire), un groupe pour les 3 droits étendus ou utiliser un groupe de profil de délégation déjà existant.

Dans cet article j’utilise un groupe de profil déjà existant.

 

Plusieurs solutions sont possibles pour effectuer la remédiation.

Vous pouvez passer par l’assistant graphique pour configurer un Deny sur les 3 droits étendus.


 

Vous pouvez aussi le faire en Powershell.

Remarque : Si vous n’avez jamais effectuer de délégation d’administration Active Directory avec Powershell, je vous conseille de consulter au préalable l’article du wiki suivant : Powershell et la délégation d’administration Active Directory : les bases (fr-FR)

Voici un exemple de code Powershell qui permet d'effecteur la modification.

Import-Module ActiveDirectory

$RootDSE = Get-ADRootDSE

$HelpDeskGroup = Get-ADGroup "HelpDesk"

### Getting Class And Attribute GUID

$GuidMap = @{}

Get-ADObject -SearchBase ($RootDSE.SchemaNamingContext) -LDAPFilter "(schemaidguid=*)" -Properties lDAPDisplayName,schemaIDGUID |% {

    $GuidMap[$_.lDAPDisplayName]=[System.GUID]$_.schemaIDGUID

    }

### Getting Extended Rights GUID

$ExtendedRightsMap = @{}

Get-ADObject -SearchBase ($RootDSE.ConfigurationNamingContext) -LDAPFilter "(&(objectclass=controlAccessRight)(rightsguid=*))" -Properties displayName,rightsGuid | % {

    $ExtendedRightsMap[$_.displayName]=[System.GUID]$_.rightsGuid

    }

[System.Security.Principal.SecurityIdentifier] $SID = $HelpDeskGroup.SID

[System.DirectoryServices.ActiveDirectoryRights] $ADRights = "ExtendedRight"

[System.Security.AccessControl.AccessControlType] $AccCtrlType = "Deny"

[System.GUID] $GUID =  $ExtendedRightsMap["Unexpire Password"]

$ACE01 = New-Object -TypeName System.DirectoryServices.ActiveDirectoryAccessRule -ArgumentList $SID,$ADRights,$AccCtrlType,$GUID

[System.Security.Principal.SecurityIdentifier] $SID = $HelpDeskGroup.SID

[System.DirectoryServices.ActiveDirectoryRights] $ADRights = "ExtendedRight"

[System.Security.AccessControl.AccessControlType] $AccCtrlType = "Deny"

[System.GUID] $GUID =  $ExtendedRightsMap["Enable per user reversibly encrypted password"]

$ACE02 = New-Object -TypeName System.DirectoryServices.ActiveDirectoryAccessRule -ArgumentList $SID,$ADRights,$AccCtrlType,$GUID

[System.Security.Principal.SecurityIdentifier] $SID = $HelpDeskGroup.SID

[System.DirectoryServices.ActiveDirectoryRights] $ADRights = "ExtendedRight"

[System.Security.AccessControl.AccessControlType] $AccCtrlType = "Deny"

[System.GUID] $GUID =  $ExtendedRightsMap["Update password not required bit"]

$ACE03 = New-Object -TypeName System.DirectoryServices.ActiveDirectoryAccessRule -ArgumentList $SID,$ADRights,$AccCtrlType,$GUID

$ObjectDN = (Get-ADDomain).DistinguishedName

$ACL = Get-Acl ("AD:\ + $ObjectDN)

$ACL.AddAccessRule($ACE01)

$ACL.AddAccessRule($ACE02)

$ACL.AddAccessRule($ACE03)

$ACL|Set-ACL -Path ("AD:\ + $ObjectDN)

 

La stratégie à adopter concernant ces 3 droits étendus dépend de la stratégie de mot de passe que vous avez définie et si vous voulez la verrouiller complètement.

Attention toutefois si vous utilisez des comptes configurés avec le paramètre PasswordNeverExpires (compte de service par exemple, même si ce n'est pas une bonne pratique), vous ne pourrez plus configurer ce paramètre.
D'autre part, les comptes déjà configurés avec un des 3 flags ne seront pas remédiés avec cette modification.