Désactiver un compte built-in administrateur dans un environnement Active Directory est tout simplement inutile.
Cette action de désactivation est pratiquée par beaucoup, alors qu’elle ne rime vraiment à rien !
Elle est inefficace parce que le compte built-in administrateur (le compte RID-500 ou built-in administrator en englais également) est tout simplement à la fois un compte spécifique et stratégique.
Comportement du compte built-in administrateur
Que ce soit au niveau du domaine ou d’une machine membre du domaine Active Directory, le compte built-in a une particularité que les autres comptes n’ont pas :
- L’appartenance native au groupe des administrateurs,
- L’impossibilité de casser cette appartenance,
- La désignation comme un compte de Recovery (c’est quelque part le compte maître),
- L’impossibilité de verrouiller le mot de passe, même après moult tentatives erronées a priori. C’est typiquement le scénario d’une attaque en mode « brute force ».
Ce dernier caractère est probablement la raison la plus plausible qui pousse certains à désactiver à tort ce compte RID-500. Quoi qu’il en soit, c’est une fausse bonne idée !
Le danger et les risques
Partant de ces constats, la désactivation du compte built-in administrateur engendre donc plus de risques que cela n’apporte de sécurité.
Tout autre compte alternatif remplaçant ce compte administrateur est un compte utilisateur ajouté au groupe des administrateurs.
Cela est valable pour un domaine Active Directory comme pour une machine membre dudit domaine.
En retirant l’appartenance au groupe des administrateurs, le compte administrateur alternatif perd fatalement ses privilèges.
C’est un peu comme si l’on scie la branche sur laquelle on est assis.
Finalement, ce n’est pas un hasard s’il est nativement impossible de retirer le compte built-in administrateur du groupe des administrateurs.
Le risque est le suivant : vous pouvez vous trouver avec un compte built-in administrateur désactivé en ayant en parallèle les autres potentiels comptes administrateurs alternatifs devenus des simples utilisateurs du domaine. Je vous laisse librement imaginer la suite des scénarios.
Faut-il renommer le compte administrateur ?
Oui, mais un renommage sec prévaut un coup d’épée dans l’eau.
Lors des phases de reconnaissance, un attaquant raisonne par SID et non en nom de compte (samAccountName ou éventuellement UPN).
Un renommage accompagné d’un rangement du compte built-in administrateur dans une OU T0 spécifique aura déjà un peu plus de sens.
L’OU est spécifique dans la mesure où les droits par défaut en lecture seule, que n’importe quel autre compte a, doivent être purement et simplement retirés. Il faudra donc un privilège spécifique pour pouvoir lire les attributs du compte RID-500.
C’est largement plus simple, efficace et smart qu’un changement de nom et/ou une désactivation.
Méthode de sécurisation
Afin de sécuriser chaque compte local built-in administrateur des machines Windows du domaine, vous pouvez mettre en œuvre LAPS, Microsoft LAPS ou Windows LAPS.
Cet outil permet de garantir un mot de passe fort et une rotation cyclique de ce dernier. C’est simple et efficace pour sécuriser.
Vous pouvez onboarder chaque compte built-in administrateur également dans un bastion de type CyberArk. La rotation du mot de passe peut être alors assurée à l’aide du module CPM. Qui peut le plus, peut le moins.
Quant au compte built-in administrateur du domaine Active Directory, vous avez la possibilité d’utiliser CyberArk également ou de confier à des personnes une partie du mot de passe.
Dans le second cas, l’utilisation du compte administrateur nécessite donc la présence de chaque individu détenant une part du mot de passe.
Ce sera certainement un escape game le jour du PRA, mais ce sera toujours mieux qu’un compte RID-500 désactivé.
Le compte built-in administrateur du domaine (RID-500) doit :
- Être Membre du groupe « Protected Users ».
- Avoir l’attribut « Account is sensitive and cannot be delegated » activé,
- Être classé dans une OU T0 avec des ACL/ACE spécifiques (droits et permission moins permissifs en tout cas),
- Avoir un mot de passe bien durci via FGPP (PSO) et AADPP (enfin Microsoft Entra Password Protection) ou une quorum formé pas des humains responsables,
- Ne pas être utilisé quotidiennement (il faut penser RBAC pour les tâches administratives quotidiennes).
Recommandation de l’éditeur
Pour terminer, l’éditeur recommande sans ambigüité, enfin depuis peu maintenant 😲, de maintenir activé le compte RID-500. C’est la seule bonne façon de mener à bien une opération de Forest Recovery, sous-entendu que c’est le prérequis d’un PRA.
Ce qui veut dire que sans ce prérequis, je me demande même si le support est assuré vis-à-vis de l’éditeur en cas de demande d’assistance. Je ne parierai pas là-dessus !
Ce qui est certain est que c’était une erreur d’avoir prétendu le contraire pendant une courte période.
Conclusion
Le compte built-in administrateur doit être maintenu activé. Le désactiver n’a rien de sécuritaire, bien au contraire : cela apporte des risques.
Il faut mettre en place les bons mécanismes pour assurer régulièrement la rotation du mot de passe.
En parallèle, il faut traquer et cadrer l’utilisation du compte built-in administrateur. Le SIEM, le SOC et le CSIRT doivent être au taquet.
Enfin, la comparaison du compte built-in administrateur Windows avec le compte root *nix est du domaine de la bêtise. Il faut savoir comparer ce qui est comparable.
Voilà mes conseils et mon REX quant à la bonne gestion des comptes built-in RID-500. Ce sont les mêmes depuis la version alpha d’Active Directory, en 1996 si ma mémoire est bonne. De la chance ou une bonne prise de conscience dès le départ ? 🤔😊
Pour le reste, dans un environnement Novell, c’était du non-sens de désactiver le compte built-in admin. Vous n’avez probablement pas connu le BIND et le NDS, les ancêtres de l’Active Directory.