Configuration Manager : attention aux permissions !

L’article publié début juillet par J.C. Hornbeck est loin d’être une légende urbaine : le support français est intervenu récemment pour rétablir une situation délicate chez un client, suite à une erreur de manipulation.

Dans les commentaires de l’article, il est possible de lire que ce serait une bonne pratique de ne pas installer de client ConfigMgr sur serveurs ConfigMgr. Dans le cas auquel je pense, le fait que les serveurs étaient équipés d’un agent a limité la casse : en effet, les serveurs ayant reçu la publication de la séquence de tâche pour se réinstaller sous un autre système d’exploitation, les points de gestion et de distribution ont été rendus inopérants. Ainsi, la séquence a-t-elle échoué rapidement et sans faire trop de dégâts.

Plutôt que de ne pas installer de clients, je profiterais des possibilités du modèle de délégation pour ne pas donner la possibilité de déployer quoi que ce soit sur le regroupement Tous les systèmes ou des équivalents. Je ne vois que très rarement de hiérarchies dans lesquelles les administrateurs de ConfigMgr ont des profils distincts des exploitants. Ce serait, pourtant, une bonne précaution.

Le modèle proposé par Microsoft à travers les groupes de sécurité existants par défaut repose sur un schéma à trois niveaux, minimum :

• Administrateur complet (Full Administrator)
• Administrateur de la sécurité (Security Administrator)
• Analyste en lecture seule (Read-only Analyst) et les autres rôles

Comme pour les groupes Administrateurs de l’Entreprise (Enterprise Admins) et Administrateurs du domaine (Domain Admins), les deux premiers groupes ne devraient contenir qu’un minimum d’utilisateurs ou de groupes. À défaut, ces utilisateurs ne devraient pas travailler avec des comptes ayant ces privilèges pour leurs activités récurrentes.