Azure License Manager (ALM) is
...
an licensable module in the EmpowerID Suite that is designed to help organizations inventory their Azure licenses and expenses across multiple Azure tenants for cost reporting and allocation of license expenses
...
within their organization. To understand how Azure Licensing Manager can help your organization with the costs associated with Azure licenses, it is helpful to review how Azure provides
...
licensing.
For each Azure tenant, there exists one Azure Active Directory and in that Active Directory
...
an organization can enable various Microsoft products to license them. Each product includes one or more Service Plans, which are the components or the services that are offered in that product
...
like Office 365 Enterprise E3, Visio and Project.
...
If your organization chooses to subscribe to Office Enterprise E3
...
, that product becomes a subscription with a specified number of licensed users with a per user per month cost.
...
Azure Licensing Challenges
There are multiple challenges with managing license distribution and license reporting for organizations using Microsoft Office 365 and Azure. One key challenge is that when
...
a company subscribes to licenses with Azure and Office 365,
...
it can only subscribe once. For large organizations with multiple departments or business units using these licenses, there’s no real way to determine how many licenses are being consumed by
...
which units or to grant responsibility to groups
...
within the organization
...
manage who gets licenses, who can approve license assignments and to report how much of the organization’s license budget is being consumed by
...
the various business units.
The below example
...
provides a simple illustration of the challenges associated with determining how much of the total licensing costs
...
spent by an organization can be allocated to individual business units from the information available in Azure. As can be seen, there exists a company consisting of a headquarters department with two business units, one located in Germany and another located in the United States. The company has one Azure subscription for Office 365 Enterprise E3 and one subscription for Visio Online Plan 1. In the case of Office 365 Enterprise E3, there are 10,000 users at a list price of $20 per month, which is an annual expense of $2,400,000. Some of these licenses
...
are consumed by users in Germany, some
...
are consumed by users in the United States, and some
...
are consumed by users in the headquarters location. The question becomes, How many licenses are being consumed by each unit and how are those licenses being managed? With native Office 365 features, there’s no real way to
...
gather data that is intelligent enough to portion off those licenses to each
...
business unit to allow those units
...
to
...
see how much
...
they are spending or to allow them to manage their own license assignments. Azure Licensing Manager allows organizations to
...
gather the intelligence they view not just the total of their licensing costs, but to see who is driving costs and grant those entities the responsibility for managing license assignments.
How Does Azure Licensing Manager Help?
EmpowerID provides a very flexible cost and responsibility allocation mechanism within Azure License Manager called "license pools and bundles." License pools and bundles allow
...
an organization to break up
...
their subscriptions to match
...
their logical organization structure
...
.
License Pools and Bundles
...
Keeping with our previous example of a fictitious company consisting of a headquarters department
...
and business units
...
in both Germany and
...
the United States, the above illustration demonstrates how license pools and bundles give organizations visibility and control over licensing. In the example, the company has a total of 10,000 Office 365 Enterprise E3 licenses, one license pool and license pool owner for each business unit, as well as several license bundles with an allocated license count per bundle. So for example, the business unit in Germany
...
has been allocated 6,000 Office 365 Enterprise E3 licenses distributed to two license bundles, the “DE Standard Employees” and the “DE Interns” license bundles. The bundles themselves can have owners who can manage user and group assignments to the license bundles. All bundle owners determine who can have a license in the bundle and become the default approvers for license access requests to a license in their respective license bundles. By using license pools and bundles, the organization can set license cost controls, and bundle up the cost for a total expenditure allowed per license pool.
The below image provides an end-to-end flow of how Azure License Manager helps organizations visualize and control licensing costs. Azure (shown on the left), has a number of subscriptions the organization purchased, which in this case includes 10,000 Office 365 Enterprise E3 licenses and 800 Visio Plan 1 licenses. In the middle of the image, these licenses are logically divided into two license pools for cost allocations and expenditure—one pool for the business unit in Germany and another for the unit in the United States. Each license pool has assignable bundles, each with a specified number of user licenses mapped to a single Office or Azure product or a single subscription.
On the right side of the image, in the Azure tenant, each license bundle is mapped to a single Azure Active Directory group for fulfillment. That group has been configured for group-based licensing and is mapped to that same subscription with service plans enabled or disabled. So, in the Germany example, users in the DE Standard Employees license bundle are fulfilled by a licensed Office 365 Enterprise E-3 full group, which grants all service plans as enabled, whereas the license bundle for the DE Interns is mapped to a licensed Office 365 E-3 Limited group, which has two of those service plans disabled. The bundles deliver the same subscription, but have been configured and mapped to provide different features to their assignees.
License Bundles - Key Points
License bundles are the assignable policy object you create in EmpowerID in order to grant to users a subscription in Azure
Each license bundle creates a single Azure subscription and pushes the resultant assignees of the bundle into a single Azure AD
...
group
License bundles are mapped to a specific group in Azure that fulfills it
License bundles are
...
assignable policy
...
objects that can be assigned to any EmpowerID actor type, including users, groups, Management Roles, Business Roles,
...
License Bundle Eligibility
So license bundle assignees are about who will automatically receive the license. Any of those assignees will be automatically added to the license fulfillment queue and pushed into the mapped license bundle group in Azure AD to give them that license. Now you can also configure who should be eligible to receive a license bundle, so you might have many license bundles again broken down to match your organizational structure. So we have our license bundles in our pool in Germany. We have a license bundles and a pool in the United States. We've even maybe further broken those down the standard employee license bundle in Germany versus the intern license bundle. So we want control that if users are shopping for licenses, we don't want them to see license bundles that aren't really meant for them. So if I'm an intern in Germany, I should only see the Internet bundle if it wasn't automatically assigned to me or if maybe we have project or optional Microsoft products, we don't want those advertised to everyone, only to those individuals who could request them. So license bundle eligibility uses the same idea as the assignees where you can map out who should be eligible to receive a license, who should be excluded from that list and not be eligible. And then the engine calculates the result in eligibility. So eligibility is really a way to advertise specific licenses to the right people so that end users are not overwhelmed. They don't see too many licenses of the same type. And they they're not presented with options that they are not allowed to request. So you're advertising to these audiences which license bundles are relevant and requestable by them.
License Fulfillment Flow
License fulfillment is the process of taking the policies in EmpowerID about who should have which license bundles, and then making those changes out into your Azure tenant, adding those resulting users, Azure AD users, to the appropriate license groups, which are matched to each of those bundles. So again, we talked about EmpowerID calculating the resultant assignees for a license bundle, which takes all the assignees minus exclusions.
...
Now there's a job in EmpowerID we discussed called the "License Pool Compiler" and it is what looks at the resultant assignees for each license bundle. It also looks at the inventory data about who already has a license via a license group - so who's already in these license groups. It looks at this in the "GroupAccountLicensePoolServiceBundle" table. That's really what says which groups contain, which user accounts because of which license bundles. And it looks at that. It says, OK. The resultant assignees should be this. But these are the users that have this group membership already.
So, we can calculate the delta. And it adds those delta entries about which users need to be added and which users should be removed because they're not allowed to have that license bundle anymore. It adds, as is entries to the License Fulfillment Queue, which is stored in a table known as the "AZLicensePoolServiceBundlePersonChangeInbox." So, you might hear referred to as the license inbox. It's an inbox where items are added into the inbox for processing, additions of users to license groups and removals for users from license groups.
Now another job is monitoring this queue and grabbing them in batches for high volume processing. And it's called the "LicensePoolChangeInboxProcessor." So, it processes these inbox entries by grabbing them, calling out to the EmpowerID Azure AD SCIM App service in your tenant and making the call to add or remove users to and from the appropriate license groups. So, this is really the end-to-end of how that license fulfillment flow works.
Components of Azure Licensing Manager
Azure License Manager is an enterprise-scale, high-security product that can be run on premise or as Software-as-a-Service run by EmpowerID as Web and Application Server containers in the cloud or on premise. As shown below, it is comprised of components common to all EmpowerID connectors with several that are specific to the module. A high-level description of these components follows.
...
EmpowerID Azure AD SCIM App Service
EmpowerID provides a workflow that allows you to publish an App Service, known as the “EmpowerID Azure AD SCIM App Service,” to a connected Azure system. The EmpowerID Azure Active Directory SCIM App Service is a SCIM compliant REST API that you publish to Azure in order to inventory so that EmpowerID to interface with and communicate to your Azure Active Directory in order to inventory data about the users, groups and license assignments in those tenants. The app service is configured for Azure AD authentication and uses a managed identity (service principal) to communicate with the Graph API to perform actions in the tenant. These actions include tasks like retrieving license information and assigning and removing users to and from license groups.
EmpowerID Jobs
EmpowerID consists of a large number of jobs for very granular processing of different items such as inventory information, attribute flow, group membership, account lockout detection and even license assignment changes and stores that information in its SQL database or Identity Warehouse. Jobs can run across multiple servers in parallel to support even the largest environments. The key jobs for Azure License Manager include the following:
Job | Purpose of Job |
|---|---|
Inventory | This job is responsible for inventorying the users, groups, group memberships, attributes and other information in Azure Active Directory. It uses the Azure AD SCIM Microservice App Service mentioned above to retrieve this information. |
Inventory Inbox | This job claims and processes all the data contained in the AzureJSONInbox table in EmpowerID. This table is populated during inventory and stores inventoried information for all Azure-specific information such as license subscriptions, RBAC entities such as management groups, and information about license assignments. The job has two steps:
|
License Pool Compiler | This job processes each enabled license pool based on the schedule set for that license pool. It evaluates the assignments and the exclusions and compiles the resultant assignments of who should have that license bundle. This then results in creating entries in the license fulfillment queue, also known as the license inbox, to add or remove user accounts from Azure AD license groups that are mapped to each license bundle. It calculates the result of who should have that license bundle versus who is currently in that license group because of the license bundle and puts entries in the license fulfillment queue for who should be added to and who should be removed from a particular license bundle. |
License Pool Change Inbox Processor | This job reads the entries placed in the license fulfillment queue by the License Pool Compiler and connects to the Azure AD SCIM microservice to process those entries in your tenants, adding or removing users to and from license groups. |
...
The EmpowerID Identity Warehouse is comprised of a large number of tables for storing and maintaining information about each connected resource system and the objects in those systems, including those within the EmpowerID system itself. These tables are differentiated by resource type and have records corresponding to both inventoried and non-inventoried objects alike. For Azure AD, some examples of the former include the Azure_AccountLicense, Azure_GroupLicense, and Azure_ManagedIdentity tables, while examples of the latter include the OrgRole, OrgZone, and Person tables (these tables correspond to unique objects created in EmpowerID). When EmpowerID inventories an account store like Azure AD, it writes all resource objects in those systems—and the important attributes of those objects—to the appropriate table in the Identity Warehouse, adding the attributes of those objects as column values. In this way, user accounts are added to the Account table, account stores are added to the AccountStore table, Office 365 subscriptions are written to the Office365Subscription table, accounts belonging to an Office 365 subscription to the Office365SubscriptionAccount table, and so on.
Inventoried Data
The below image presents a high-level overview of how EmpowerID stores and gathers the inventory data it retrieves when connected to Azure.
...
On the right side of the image, we see our Azure tenant and on the left we see our EmpowerID instance—whether it's on premise or a SaaS instance. EmpowerID is running as Web and Application Server containers hosting inventory jobs that pull the data from Azure and stores it in the appropriate tables of the Identity Warehouse. Users from Azure Active Directory are stored in the Accounts table, groups in the Group table, and the products to which the tenant has subscribed in the AZLocalServiceBundle table. Additionally, detailed information about which users or groups are assigned to which of these subscriptions, as well as which of product features of the service plans are enabled or disabled on each of these assignments is stored in the AZAssigneeLocalServiceBundleService table. While the image shows just a few of the tables, it allows you to see the overall flow of how EmpowerID could securely communicate to an Azure App service running in your tenant, using a managed identity to talk to the Graph API to retrieve this information and to store it in the identity warehouse.
When EmpowerID inventories Azure AD, it creates an account in the EmpowerID Identity Warehouse for each Azure AD user account, a group for each Azure AD group, assigns group memberships to users based on their group memberships in Azure. Imported user information can be managed and synchronized with data in any connected back-end user directories.
Once connected, you can manage this data from EmpowerID in the following ways:
Account Management
Inventory Azure AD user accounts
Create, Update and Delete Azure AD user accounts
Enable and Disable Azure AD user accounts
Update passwords for Azure AD user accounts
Group Management
Inventory Azure AD groups
Inventory Azure AD group memberships
Create and Delete Azure AD groups
Add and Remove members to and from Azure AD groups
Attribute Flow
Users in Azure AD are inventoried as accounts in EmpowerID, which are then linked EmpowerID Person objects. The below table shows the attribute mappings of Azure AD user attributes to EmpowerID Person attributes.
...
Azure AD Attribute
...
Corresponding EmpowerID Attribute
...
Description
...
Name
...
Name
...
Name of the user
...
name.familyName
...
LastName
...
Last name of the user
...
name.givenName
...
FirstName
...
First name of the user
...
name.middleName
...
MiddleName
...
Middle name of the user
...
displayName
...
FriendlyName
...
Display Name of the user
...
name.honorificSuffix
...
GenerationalSuffix
...
...
title
...
Title
...
Title of the user
...
email[?(@type=='work')].value
...
...
Work email address of the user
...
['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User'].['department']
...
Department
...
Department of the user
...
['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User'].['EmployeeNumber']
...
EmployeeID
...
Employee ID of the user
...
addresses[?(@.type=='work')].streetAddress
...
StreetAddress
...
Street address of the user
...
addresses[?(@.type=='work')].locality
...
City
...
City in which the user resides or works
...
addresses[?(@.type=='work')].region
...
State
...
State in which the user resides or works
...
addresses[?(@.type=='work')].country
...
Country
...
Country of the user
...
addresses[?(@.type=='work')].postalCode
...
PostalCode
...
Postal code of the user
...
phoneNumbers[?(@.type=='home')].value
...
HomeTelephone
...
Home telephone of the user
...
preferredLanguage
...
PreferredLanguage
...
Preferred language of the user
...
phoneNumbers[?(@.type=='other')].value
...
Telephone
...
Telephone number for the person
...
phoneNumbers[?(@.type=='fax')].value
...
Fax
...
and Query-based Collections.
License bundles can have exclusion rules to prevent license assignments to certain people, as well as to enforce regulatory restrictions. Exclusion rules can be applied to any EmpowerID actor type.
License bundles can be requested by self-service users in the IT Shop
License Bundle Assignees
At the most basic level, license bundle assignees are the people who have been assigned to a license bundle and who should receive the license granted by the bundle. As mentioned in the key points above, license bundles can be assigned to any EmpowerID actor type. This gives you the power to make assignments to license bundles using any criteria that makes sense for your organization. License bundle assignees can be diverse as any or all of the following:
You can assign user accounts directly to a license bundle
You can assign a group in another system, such as those in an on-premise Active Directory, those in Amazon AWS, Salesforce, or ServiceNow, among others
You can assign Business Role and Locations to a license bundle, giving all people with that Business Role and Location a license
You can assign Management Roles to a license bundle, giving all people with that role a license
You can assign Query-based Collections (QBC) that return all users with a specific attribute value to a license bundle so that every user in each QBC gets a license
Beyond defining who should get the license bundle, you can apply exclusion rules to the bundle to define who should not receive a license. As with assignments, you can use the same actor types in your exclusion rules. Once a license bundle is defined with assignees and exclusion rules, ALM calculates the resultant set of license bundle assignees, which is everyone who should have the license, minus everyone who shouldn't have it. The end result is that everyone who is eligible for a license bundle will receive it. Azure License Manager adds each of these assignees to the License Fulfillment Queue and pushes them into the mapped license bundle group in Azure AD, which, in turn, gives them the actual license.
License Bundle Eligibility
Beyond defining who should receive a license bundle, ALM makes it possible for you to define who should be eligible to receive a license bundle. Returning to the example of the fictitious company mentioned earlier, consider how the structure of the company can benefit by defining license bundle eligibility. As you may remember, the organization has:
A headquarters department and two business units, one located in Germany and another located in the United States,
One Azure subscription for Office 365 Enterprise E3 with 10,000 users
One Azure subscription for Visio Online Plan 1
Additionally, using ALM the organization has created license pools and license bundles to match their organizational structure and Azure subscriptions. So, they have:
One license pool for Germany
One license pool for the United States
Four license bundles for Office 365 Enterprise E3:
A license bundle for standard employees in Germany
A license bundle for interns in Germany
A license bundle for standard employees in the United States
A license bundle for interns in the United States
Four license bundles for Visio Online Plan I:
A license bundle for standard employees in Germany
A license bundle for interns in Germany
A license bundle for standard employees in the United States
A license bundle for interns in the United States
It looks like the organization has their licensing situation in a much better position — and they do. However, currently users can see all bundles when shopping for licenses in the IT Shop. And if they are not careful enough, users in one business unit could request licenses meant for users in another business unit, or interns could request licenses meant for standard employees. Further, the organization could inadvertently grant these requests, which would present an inaccurate picture of business unit license usage. To help prevent this type of oversight, Azure License Manager uses what is known as Eligible Assignees to control which license bundles users can see when shopping for licenses. This keeps the organization from advertising license bundles to users who should not see those licenses. In this way, standard employees in Germany only see licenses that they can request, standard employees in the United States only see licenses they can request, interns in Germany only see licenses they can request and interns in the United States can only see licenses they can request. Each group only sees the licenses delegated to them by the respective license bundles.
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|