I have a very interesting licensing scenario I recently ran into surrounding using the deny permission. With the move to D365FO, the deny permission allows for explicitly revoking access to an object, this in turn, should also impact the licensing to a user, role, duty, or privilege. To test this I set up the following scenario:
1. I found a menu item that has different licenses for the ViewUserLicense and MaintainUserLiecense parameters, I found the BankAccountTable menu item display. It has a MaintainUserLicense of Operations and a ViewUserLicense as Universal (Team Member). This means that a user/role with Read access to the BankAccountTable menu item will require a Team Member license and a user/role with Update, Create, or Delete permission to this object will require an Operations license.
2. I created the following privileges
-
- One that grants full control to the object – FPFullAccessBankAccount
- One that denies all access to the object – FPDenyAllAccessBankAccount
- One that denies Create, Update, and Delete to the object – FPDenyCUDBankAccount
3. Assign these privileges to a role in different combinations and then validating the results in the View Permission report as well as the User and Role licensing reports
Scenario #1 – Assign FPFullAccessBankAccount privilege to role
As expected, the license type required for the role is Operations.
Scenario #2 – Assign FPFullAccessBankAccount and FPDenyAllAccessBankAccount to role
Also as expected, if you deny permission to this object this role will no longer require an Operations license.
Scenario #3 – Assign FPFullAccessBankAccount and FPDenyCUDBankAccount to a role
The combination of these privileges assigned to the same role will make the comprehensive access to this object to be Read. I would have expected this combination of access to then require a Team Member license but it appears that D365FO is reporting this role to require an Operations license.
Conclusion
So there are two options:
- This is a bug and the deny permission should be taken into account with determining licensing but is currently not
- This is not a bug and unless you remove the access entirely, D365FO only looks at the Grant access to the object to determine licensing
With the difference in pricing between an Operations level license ($190 user/month), Activity ($50 user/month), and Team Member ($8 user/month) the monetary impact of this can be quite large. In any case it is important to keep this in mind when trying to modify your security to control license requirements.
Note: I also repeated the tests above only granting Update and Create access to the object and the results remained the same, just in case the rogue Correct grant access (there is literally no way to deny this access from the AOT or UI without denying access to the object entirely) was causing erroneous results or different levels of access caused different outcomes.
Hi Alex,
I don’t think this is a bug, but during implementation you have to be careful and be aware what exactly you assign within a role or multiple roles. The highest assignment of menu items with a certain license type determines the license. The deny option could only impact the effective access. I had seen this before and took action to lower the license SKU for a company.
So, the examples in your post should make people more aware of license impacts. In that way it is a very valuable post.
Alex – I wanted to rekindle this old post, as the topic is relevant again with the new licensing enforcement changes!
Did we ever figure out if this deny access should affect licensing? It seems very odd that the licensing isn’t reduced, if access is taken away via the deny.
I am seeing the same ‘issue’ now, with the PPAC reporting. If I take away access to an object, the PPAC reporting is still showing that I have access to the object. The Security Governance ‘License Usage Summary’ report is also showing effective entitlement to the object, when a deny access is added to the user.
(FYI – the FastPath tool is showing no license required when the deny access is added to the user, as I would have expected)
Mike,
As you confirmed, I have seen no change in the license analysis surrounding the Deny permission not being taken into account. If a user is completely denied access to an object, the license reporting appears to be correct. However if a ‘partial deny’ is applied, this does not seem to be correctly being reported (eg: a user is assigned Delete permission to an object in Role A but then denied Delete, Create, and Update permissions to that object in Role B effectively leaving them with Read access to the object). The license analysis only looks at access assigned, it does not appear that ‘effective access’ is being analyzed.
I have raised this issue before a couple different times with Microsoft and I do not believe there is any roadmap for addressing this concern. I have always argued that effective access should be used during any user access / license analysis and have written the Fastpath reports in that way to show what the user is actually assigned and therefore what the user should be required to have from a license perspective based on that effective access.
Thanks for confirmation.
I will raise this with MSFT too. Seems like a massive hole if they are now enforcing licenses based on ‘user access to securable objects’. Maybe Deny is not a highly utilized scenario…
That’s the main push back I have gotten, that the use case for the Deny permission is for ‘denying the entire object’ not just part of the access.
My counter point has been, D365 allows for partial denies so all business processes based on this should use the effective permission.
Feel free to let me know if I can help push this issue along.