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.

La techno est prête, ne manquent plus que des SoC compatibles : officiellement, on en est là avec l’accélération hardware pour BitLocker.

Cette fonctionnalité est intégrée dans Windows 11 25H2 (déployé depuis octobre) et 24H2 (avec la mise à jour de septembre). D’une part, elle décharge le CPU des opérations cryptographiques en les confiant à un moteur annexe dédié. De l’autre, elle permet, sur le même principe que les HSM, de générer, d’encapsuler et d’utiliser les clés de chiffrement en bloc dans une enclave matérielle – ce qui réduit leur exposition en RAM.

Des SoC Intel pour commencer

Les premières puces à prendre en charge l’accélération matérielle pour BitLocker sont les Core Ultra Series 3 (Panther Lake), qu’Intel devrait lancer au CES (5-9 janvier).

L’algorithme XTS-AES-256 sera utilisé par défaut. Sur les configurations compatibles, si un utilisateur ou un script spécifie un algo ou une taille de clé non géré, BitLocker basculera vers l’implémentation logicielle. Microsoft entend modifier ce comportement au printemps en augmentant automatiquement la taille de clé si nécessaire.

Au-delà de la sécurité, le mécanisme est censé améliorer les performances. En particulier sur les disques NVMe, qui atteignent désormais des débits tels que l’empreinte CPU des opérations cryptographiques peut devenir perceptible.

Dans ses propres tests – évidemment effectués en « configuration idéale » -, Microsoft a plus que doublé les débits en lecture et en écriture en activant l’accélération matérielle pour BitLocker. Il affirme également avoir économisé, en moyenne, 70 % de cycles CPU.

À consulter en complément :

SaaS et chiffrement : Microsoft 365 ciblé par un appel à la vigilance
Windows 11 : l’étau se resserre sur les comptes locaux
Agent 365 : après l’orchestration, Microsoft promet l’encadrement de l’IA agentique

Illustration générée par IA

The post BitLocker bientôt dopé à l’accélération matérielle appeared first on Silicon.fr.