Le groupe Protected Users : des protections fortes pour les comptes privilégiés, à déployer avec méthode
Introduit avec Windows Server 2012 R2, le groupe Protected Users applique automatiquement un ensemble de restrictions à ses membres. C'est l'une des mesures les plus rentables pour protéger les comptes d'administration, et pourtant nous le trouvons vide dans la majorité des annuaires audités. Il faut dire qu'un déploiement précipité peut bloquer des administrateurs : la méthode compte.
Ce que le groupe apporte
Les protections s'appliquent à deux niveaux : sur les appareils où le membre ouvre une session (à partir de Windows 8.1 et Windows Server 2012 R2), et sur les contrôleurs de domaine lorsque le niveau fonctionnel du domaine est au moins Windows Server 2012 R2.
| Protection | Effet |
|---|---|
| Pas d'authentification NTLM | Le compte ne peut s'authentifier qu'en Kerberos ; le hachage NT n'est plus exploitable pour une authentification NTLM. |
| Pas de DES ni de RC4 en pré-authentification Kerberos | Seul AES est utilisé, ce qui complique les attaques hors ligne. |
| Pas de délégation | Le compte ne peut être délégué, ni en délégation non contrainte ni en délégation contrainte. |
| TGT de courte durée | Les tickets TGT ont une durée de vie de quatre heures, non renouvelables au-delà, sauf stratégie d'authentification spécifique. |
| Pas de mise en cache côté client | Pas de vérificateur d'ouverture de session mis en cache, pas de délégation d'identifiants par défaut via CredSSP, pas de mot de passe en clair conservé par WDigest. |
Ces protections ne sont pas configurables individuellement : l'appartenance au groupe les active toutes.
Qui mettre dans le groupe
Les candidats naturels sont les comptes nominatifs d'administration de haut niveau : membres des Admins du domaine, des Administrateurs de l'entreprise, des Administrateurs du schéma, des Administrateurs, et plus largement tous les comptes de niveau 0. Les comptes d'administration de serveurs peuvent suivre une fois l'expérience acquise.
À l'inverse, n'y placez jamais :
- les comptes d'ordinateur et les comptes de service, y compris les gMSA : les services dépendent souvent de la délégation ou de NTLM et cesseraient de fonctionner ;
- les comptes qui doivent ouvrir une session hors connexion, par exemple sur un portable, puisque le vérificateur mis en cache disparaît ;
- tous vos comptes d'urgence : gardez au moins un compte de secours hors du groupe, fortement protégé par ailleurs, pour ne pas perdre l'accès en cas de problème Kerberos.
Les pièges fréquents
Applications qui exigent NTLM. Certaines consoles, appliances ou connexions par adresse IP plutôt que par nom retombent sur NTLM. Pour un membre de Protected Users, elles échouent. Recensez ces usages avant d'ajouter les comptes, par exemple grâce à l'audit NTLM sur les contrôleurs de domaine.
Durée de session. Avec un TGT de quatre heures, les administrateurs doivent parfois se réauthentifier en cours de journée. C'est voulu, mais il faut l'expliquer.
Niveau fonctionnel insuffisant. Si le domaine est encore à un niveau fonctionnel antérieur à 2012 R2, seules les protections côté client s'appliquent. L'absence d'erreur ne garantit donc pas l'efficacité.
Environnements RC4. Les comptes dont les clés AES n'ont jamais été générées, parce que leur mot de passe n'a pas été changé depuis la migration vers un niveau fonctionnel 2008 ou supérieur, ne pourront plus s'authentifier. Changez leur mot de passe avant de les ajouter.
Déployer par vagues. Commencez par un ou deux comptes d'administrateurs volontaires, observez une semaine d'usage réel, puis étendez. Surveillez les journaux d'échec d'authentification dédiés sur les contrôleurs de domaine pendant chaque vague.
Compléter plutôt que remplacer
Protected Users ne remplace ni le cloisonnement par niveaux, ni les postes d'administration dédiés. Un administrateur qui ouvre une session sur un poste compromis reste exposé : son TGT est dérobable pendant sa durée de validité. Le groupe se combine utilement avec l'option « Le compte est sensible et ne peut pas être délégué », avec les stratégies d'authentification et avec Credential Guard.
Ce qu'un audit vérifie
- la présence des comptes privilégiés nominatifs dans Protected Users ;
- l'absence de comptes de service et de comptes d'ordinateur dans le groupe ;
- le niveau fonctionnel du domaine, condition des protections côté contrôleur ;
- l'existence d'un compte d'urgence documenté et surveillé ;
- la dépendance résiduelle des comptes privilégiés à NTLM ou à RC4.