One of the things we Microsoft FIM/MIM folks find ourselves doing of late is having to find ways of automating Office 365 license assignment for our “hybrid” (AD+AAD) customers, initially as part of provision the initial Exchange Online mailbox which requires that initial Enterprise license.

Microsoft’s AADConnect “identity bridge” solution superseded DirSync, and more recently AADSync, as the preferred solution for hybrid enterprises, bringing with it support for the many multi-forest/single tenant scenario which was once the domain of FIM and the Windows Azure Active Directory (WAAD) connector.  There was hope that with this would come an automation option for license management, but to date there has been no answer forthcoming.  Consequently most have adopted a PowerShell-scripted approach utilising the Office365 PowerShell API, assigning licenses with a post-AAD sync step, and perhaps even automating this based on on-premises AD group membership.

Until now a certain client’s FIM 2010 solution has performed just this function, but while it performs its role admirably, it presently only goes as far as assigning the initial E3 license applicable for an active user, and revoking all licenses on termination, it does not extend to managing all licenses in between those 2 events.  While there is some extensibility to the model, configuration has been a little messy – requiring ongoing maintenance of the relationship between groups and their associated O365 SKU (and optional “disabled plans”). The FIM 2010 configuration solution consisted of

• The standard WAAD and AD connectors that formed the original DirSync configuration, but with a custom Metaverse design;
• An LDIF MA to import user.memberOf (not an available attribute for the OOTB AD MA) for each O365 license group for which an entitled user is a member; and
• A PowerShell MA to set the “isLicensed” property to true/false for active/inactive users respectively, and at the same time assign the correct SKU/disabled plan combination applicable for newly provisioned AAD user accounts.

While the automated management of the group membership in this particular instance was already taken care of, I needed to find an alternative approach that was not only more extensible, but was also

• more flexible
• more granular in its entitlement management, and
• more administrator-friendly.

While an Office Premium feature (still in preview???) goes some of the way to achieving this through the use of role groups, this was not able to tick all the boxes the customer was looking for.  Furthermore, the FIM 2010 configuration which originally replaced DirSync now needed to be swapped out with AADConnect, and in order to keep the AADConnect design as close to OOTB as possible, I needed to relocate the license management to another MIM instance which was performing another identity synchronisation role for the same AD user base.  This is where I thought of that rather unloved component of the Windows Server OS – Microsoft Authorization Manager, or AzMan.

What is AzMan and how can it help?

Microsoft Authorization Manager (AzMan) is a component of the Windows operating system which allows a consistent model to be used for driving application access.

“AzMan is a role-based access control (RBAC) framework that provides an administrative tool to manage authorization policy and a runtime that allows applications to perform access checks against that policy. The AzMan administration tool (AzMan.msc) is supplied as a Microsoft Management Console (MMC) snap-in.”

As a result of recent enhancements to the framework and its API, this lends itself quite nicely to modelling roles and groups for O365 licensing and license assignment.

The AzMan model and UI (MMC snap-in) allows groups of users (either LDAP or built-in groups) to be mapped to roles, which in turn are made up of sub-roles, tasks, sub-tasks and operations.  With the AD license groups already taken care of, this provides an easy way of matching existing groups to roles.  Now all that had to be done was to

1. design a suitable AzMan data structure to allow unambiguous O365 enterprise user license assignment; and
2. design a way to dynamically translate changes in the AD group memberships to corresponding O365 license assignments in AAD using MIM synchronisation.

What will the new solution look like?

The following is a conceptual overview of the architecture to get you thinking:

In my next post I will describe my AzMan data model, share a simple script to extract the data in a way that MIM can consume it, as well as the MIM extensions (custom MAs) which deliver the desired outcomes.