> Tech > Cache-cache avec les permissions Active Directory

Cache-cache avec les permissions Active Directory

Tech - Par Joern Wettern - Publié le 26 septembre 2011
email

Lorsque vous vous penchez sur des problèmes de sécurité essentiels, il est facile de passer à côté des petits détails. Cet article aborde l’un de ces aspects secondaires : l’objet AdminSDHolder dans Active Directory.

Cache-cache avec les permissions Active Directory

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é.

Cache-cache avec les permissions Active Directory

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.

Pour aller Plus loin sur AD avec les experts @ITPROFR :

ChatGPT : bénédiction ou malédiction pour la sécurité d’AD ? (itpro.fr)

Les 4 piliers de la sécurité Active Directory · iTPro.fr

Les fondements de la sécurité Active Directory · iTPro.fr

Téléchargez cette ressource

Reporting Microsoft 365 & Exchange

Reporting Microsoft 365 & Exchange

Comment bénéficier d’une vision unifiée de vos messageries, protéger vos données sensibles, vous conformer aisément aux contraintes réglementaires et réduire votre empreinte carbone ? Testez la solution de reporting complet de l’utilisation de Microsoft 365 et Exchange en mode Cloud ou on-premise.

Tech - Par Joern Wettern - Publié le 26 septembre 2011

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT