UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21. Read more.
UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21.Read more.
Captain
Captain
352 views

AzureAD License Entitlement

Jump to solution

Hi! 

I have a Hybrid AzureAD environment, and I want to use AzureAD driver to assign O365 licenses.

According to Microsoft, there are different licences like:
- Office 365 "E1" licence: https://www.microsoft.com/en-us/microsoft-365/enterprise/office-365-e1?activetab=pivot%3aoverviewtab
- Office 365 "E3" licence: https://www.microsoft.com/en-us/microsoft-365/enterprise/office-365-e3?rtc=1&activetab=pivot:overviewtab
- Office 365 "F3" licence: https://www.microsoft.com/en-us/microsoft-365/enterprise/office-365-f3?rtc=1&activetab=pivot:overviewtab

but a RBPM Resource with licence entitlement only allows me to select Microsoft Products, such as :

 

- PROJECT_O365_P2 (ENTERPRISEPACK)
- EXCHANGE_S_FOUNDATION (POWER_BI_PRO_DEPT)
- SHAREPOINTWAC(OFFICESUBSCRIPTION)
- ..

 
 

 

 

Is there a way to -using a single resource- have a E1/E3/F3 license as an entitlement value?
If not...How should I proceed?
One idea (for example) is to create a role "E1" with N resources (each one for each product of E1 licence). But in this scenario, I have doubts if Microsoft would "count" these individual assignments as an E1 license.


Thanks in advance,

0 Likes
1 Solution

Accepted Solutions
Knowledge Partner Knowledge Partner
Knowledge Partner

So if I remember this correctly, it is kind of annoying.

On the MS API side, the way it worked was, you set an E1 style license, once, and then excluded the sub-bits that you did not want.  This led to the ludicrous situation where to grant perission inside a license, you would create an E1 license and exclude the entire list.  If MS added a new thingy type inside the main license, everyone had it, since you had to yet to explicitly exclude it.

I do not think this is a good license model. 

The original O365 driver basically had a GCV setting where you listed the bits to exclude.

In the Azure driver they (MF) tried to fix this odd model (MS).  They break it out into individual sub-elements which is nice.  In fact if you watch in trace, it seemed to me, that the shim gets back the whole list, and looks at what you set, and then does the grante E1 and then exclude everything you did not set. Which is kind of dumb but what else could you do?

So you want the original model.  🙂  Which you might change your mind on later. But time will tell.

In that case, create a Role with a Resource for each sub-element, and simply grant the Role instead.

 

View solution in original post

3 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

So if I remember this correctly, it is kind of annoying.

On the MS API side, the way it worked was, you set an E1 style license, once, and then excluded the sub-bits that you did not want.  This led to the ludicrous situation where to grant perission inside a license, you would create an E1 license and exclude the entire list.  If MS added a new thingy type inside the main license, everyone had it, since you had to yet to explicitly exclude it.

I do not think this is a good license model. 

The original O365 driver basically had a GCV setting where you listed the bits to exclude.

In the Azure driver they (MF) tried to fix this odd model (MS).  They break it out into individual sub-elements which is nice.  In fact if you watch in trace, it seemed to me, that the shim gets back the whole list, and looks at what you set, and then does the grante E1 and then exclude everything you did not set. Which is kind of dumb but what else could you do?

So you want the original model.  🙂  Which you might change your mind on later. But time will tell.

In that case, create a Role with a Resource for each sub-element, and simply grant the Role instead.

 

View solution in original post

Captain
Captain
Geoffc,

I agree with you: this is not a good licensing model.
However, in our particular RBAC model it would have been better to have the old entitlement model.

Thanks for your quick response!

Cheers,
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner
For a number of years Microsoft support group license assignment.
Driver doesn't support it "directly", but it still easy to implement.
1. Assign a specific license to the AAD group
2. Driver can manage users group membership (and as a result will manage license assignment).
This model is more close to the "traditional" RBAC model.
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.