AX 2012 Security Unwrapped Series - Security Tidbits

This post will unwrap some miscellaneous Security Tidbits.   Some of the items noted are repeats of what I've posted already in this series, but thought to consolidate list here.

Management Reporter:
Management reporter inherits its security from the user's Dynamics AX security. Below are the access levels in Management Reporter and the privilege/duty that will grant MR access.

BI Cubes and associated AX reports:
Standard AX cubes are built and loaded using background jobs.  Several reports in AX access the BI cubes to create the report.  Many (but not all) of the reports have the word statistical in the report name.  To access these reports requires some additional access to be set up.  The BI cubes reside on the SSAS server, that server has role groups that the user must be a member to access the cube and hence access the statistical report.  The error you will receive if the user does not have access is:
"Either the user, <domain>\<userid>, does not have access to the Dynamics AX database, or the database does not exist." Below is a list of the various role groups:

Blocking users from Journals:
You can setup secondary access to limit the set of users that have access to posting inventory and general ledger journals.  This is done by defining user groups and using the "Blocking" feature on the journal name setup form.  Refer to my prior post: Security Unwrapped Series: Supplemental Setups for details.

Limiting users to specific organizations (aka legal entities):
By default when assigning access, the user will have access to all organizations.  If you want to limit them to specific organization (or legal entities), you can by granting by organization.  See my prior post: Security Unwrapped Series: Explaining the Security Menu for details.

Purchase requisition access:
By granting the Employee role to a user gives them access to create purchase requisitions.  However there is additional setups required before they can create a purchase requisition.  The navigation path is: Procurement and sourcing\setup\Policies\Purchase requisition permissions,

Each legal entity they are allowed to create a requisition in must be discretely granted - choose the view "By requester" and add the specific legal entities:

You can also grant an individual to create purchase requisitions in behalf of another person - choose the view - By preparer and choose the individuals they will be preparing purchase requisitions for:

Preventing updates to approved BOMs:
You can block updates to approved bills of materials by updating a parameter setting in the Inventory Management module.  Please refer to Kelly Kane's AX Soup blog entry: Don't Change my BOMs!

Other miscellaneous items:

1.  System administrator role can only be assigned by another System administrator.  Security administrators cannot assign this role to a user.
2.  Deleting a role, duty, privilege, or process in the UI does not delete the AOT security object.  You must go to the AOT to perform the delete.  If this is not done, it will cause a compile error.
3.  Enterprise portal also has its own security.  (I have not yet played with this, so will not add any details right now.  BUT expect it someday in the future!)
4.  Nesting roles is allowed and compiles without issue.  However the security add-in tool will only display correctly.  See my prior post: Security Unwrapped Series: Security Add-in Features for more details.
5.  When using the UI, your security elements will be in the USR layer.  When moving to Dynamics 365, this will be an issue.  This is because in Dynamics 365 security is compiled and stored as metadata.  To retain the security changes in the AOT, you will need to have a developer access the AOT to make the changes permanent.