Lorsque vous vous penchez sur des problèmes de sécurité essentiels, il est facilede passer à côté des petits détails. Cet article aborde l’un de ces aspects secondaires : l’objet AdminSDHolder dans Active Directory.
Ce dossier est issu de notre publication IT Pro Magazine (09/10). Pour consulter les schémas et illustrations associés, rendez-vous dans le club abonnés.
Il y a peu, j’ai redécouvert un comportement obscur d’Active Directory alors que je devais configurer ActiveSync sur un serveur Exchange 2010 pour un utilisateur équipé d’un iPhone. Un message m’a signalé que le compte d’utilisateur dans AD n’avait pas les permissions héritées nécessaires requises par Exchange Server pour créer un objet représentant l’iPhone. Au cours de mes vérifications, j’ai constaté que les permissions étaient en place au niveau du domaine mais, à l’examen des paramètres de sécurité de l’objet utilisateur, j’ai constaté que l’héritage avait été désactivé.
Ce phénomène m’a paru étrange car la case à cocher était activée pour d’autres objets utilisateurs. J’ai activé l’héritage mais, quelques minutes plus tard, le paramètrea mystérieusement disparu. J’ai réalisé rapidement d’où venait le problème. L’utilisateur en question était membre du groupe Admins du domaine (Domain Admins) et l’héritage des permissions avait été désactivé en raison d’un mécanisme AD obscur chargé de protéger les comptes utilisateur avec privilèges.
Lors de la conception initiale d’Active Directory, les développeurs de Microsoft étaient préoccupés par le fait que les permissions à l’échelle du domaine puissent mettre en danger la sécurité des comptes nécessitant un niveau de protection accru. Par exemple, si vous autorisez le personnel du help desk à réinitialiser les mots de passe utilisateurs dans votre domaine, qu’est-ce qui les empêcherait de modifier les mots de passe administrateurs et d’interdire à ces derniers l’accès au domaine ? Dans une structure AD bien organisée, vous pouvez éviter ce problème en délégant les permissions uniquement pour certaines entités organisationnelles (OU) et en déplaçant tous les comptes avec privilèges vers une OU distincte. Néanmoins, soyons réalistes, la majorité des sociétés placent tous les utilisateurs dans une seule OU, et quiconque en mesure de modifier les objets représentant des utilisateurs lambda peut aussi modifier les objets représentant les administrateurs.
Pour éviter ce type de phénomène, un processus s’exécute toutes les heures sur les contrôleurs de domaine et désactive l’héritage des permissions au niveau de tous les objets utilisateurs membres de certains groupes avec privilèges. Le processus remplace toutes les permissions existantes par celles définies dans un modèle. Ainsi, des permissions au niveau du domaine qui, par inadvertance, autoriseraient un compte utilisateur sans privilèges à modifier un compte avec privilèges seront annulées en un maximum d’une heure. Par exemple, même si vous octroyez des permissions de niveau domaine permettant à votre personnel de help desk de modifier les mots de passe, ils ne pourront pas toucher au mot de passe de l’administrateur dès l’exécution suivante du processus d’arrière-plan.
La Threat Intelligence (TI) rassemble des données, des informations et des analyses détaillées, dans le but de fournir aux RSSI des informations pertinentes, précises et exploitables pour lutter contre les attaques et d'autres problèmes liés à la cybersécurité. Découvrez dans ce Guide comment maximiser les bénéfices de la TI pour votre organisation.
