Une licence vous manque… et aucune autre ne peut être assignée.

Michelin s’est trouvé dans cette situation avec les logiciels Microsoft. En toile de fond, la mise en place d’un nouveau processus d’attribution des licences, basé sur des groupes Active Directory.

À l’origine, un système d’attribution directe

Lorsque l’entreprise avait adopté Office 365 il y a une dizaine d’années, l’attribution était directe, via le centre d’administration ou via des scripts PowerShell. Elle reposait sur des bundles de licences correspondant à des profils de travailleurs.

Pour stocker ces profils, il fut décidé d’exploiter les attributs d’extension d’Active Directory – sinon utilisés notamment pour la synchronisation de boîtes Exchange locales. Ces attributs étaient synchronisés vers Azure Active Directory.
Le script principal, exécuté sur site de manière périodique, détectait les nouveaux utilisateurs, lisait les attributs associés et assignait les licences correspondantes.

Dans le cadre des recrutements, les attributs étaient définis par les systèmes RH, dans AD (initialement de façon indirecte, en passant par l’annuaire interne). Dans les autres cas (freelances, mobilité interne, comptes spécifiques…), ils l’étaient via un portail de provisionnement interne.

Ce système présentait des limites. Parmi elles, la complexification progressive du script principal (ajout/modification de profils, altération de la logique métier sous-jacente). Par ailleurs, ce dernier étant planifié et non orienté événements, il existait toujours un décalage vis-à-vis des outils amont, amplifié par l’intervalle de synchronisation de 30 minutes d’AAD Connect.

Cette approche n’empêchait plus globalement pas les admins d’attribuer n’importe quelle licence à un utilisateur, au-delà ce celles dont il était censé bénéficier.

L’approche basée sur les groupes, concrétisée en deux temps

Dans ce contexte, Michelin a entrepris de basculer vers une approche basée sur les groupes, à l’échelle de son locataire (aujourd’hui quelque 120 000 sièges). Il en faisait déjà usage pour quelques services comme Copilot.

L’idée initiale était de créer un groupe dynamique dans AAD pour chaque profil. Le groupe « Knowledge Worker », par exemple, serait défini par la formule (user.extensionAttribute13 – eq « Knowledge Worker »). Chaque groupe se verrait ensuite assigner les licences correspondant au profil. L’ensemble pourrait alors remplacer progressivement les licences assignées directement.

Quelques jours après la mise en production, il fut constaté que l’absence d’un type de licence suffisait à bloquer l’attribution des autres au sein d’un groupe. Un problème non identifié lors des tests… et non documenté, à la connaissance de Michelin.

L’approche « un groupe par profil » fut par conséquent abandonnée, au profit d’un système plus modulaire associant un groupe à chaque combinaison « profil(s) + type de licence ».
Chaque groupe comprend donc une licence et l’ensemble des profils censés en bénéficier. Par exemple, GP-AAD-USR-LICENSE-E1_SDFA, qui associe les profils « Standard » (SD) et « Functional Account » (FA) à la licence Office 365 E1.

Dix profils ont été définis :

L’ensemble est en production depuis quelques mois. Reste à traiter certains cas problématiques comme les comptes cloud-only.

Illustration générée par IA

The post Comment Michelin a modernisé la gestion de ses licences Microsoft appeared first on Silicon.fr.