AD User Mapping¶
Analysis Models in Analysis Models - Power BI that support built-in RLS (Row Level Security) require some user setup to be made.
RLS is these models is based in Role definitions. Each role has a unique name and the role typically defines:
- Permissions
- Included members
- RLS filter expressions
The RLS filter is a DAX expression that will basically compare the current user with a table of users that contains info about permissions for each user.
The user->permission handling is built into the models. The information is retrieved from IFS Cloud.
Even if users are defined in IFS Cloud to be part of a company, defined as GL users, project members, site members etc., these users will not by default get access. Only users that are defined on the AD User Mappings will be considered by the different RLS implementations.
The reason is to make sure that the IFS user identity, also called Fnd User, is correctly mapped to an AD user that a tabular model can retrieve via DAX functions as USERNAME() and USERPRINCIPLENAME().
For many installations, the AD User Identity will be represented by the UPN, i.e. the User Principle Name. The UPN for the user then needs to be mapped to the Fnd User identity. If the principle name is used, then the DAX filter must use the function USERPRINCIPLENAME().
For same installations it will be possible to also use a domain name as e.g.
In 24R1, following models have inbuilt RLS in Analysis Models - Power BI.
-
General Ledger
-
Employee Analysis
Info
Cash Planning, Group Reporting and Salary Review Analysis Models will be available in a future release of Analysis Models - Power BI.
AD User Mappings are grouped into sections based on the functional areas of the Analysis Models.
-
Finance - User mappings related to the built-in roles delivered by IFS for General Ledger model.
-
HCM - User mappings related to the built-in roles delivered by IFS for Employee Analysis model.
-
Custom - User mappings related to any custom roles created.
For the above mentioned models, the necessary access-related information should be generated and stored in respective tables. This approach was taken to minimize the time taken for the access detail data load. Background jobs should be created to accomplish this and for more information please refer to Refresh and Re-Generate AD User Access.
To generate access for a selected set of users at any time use the following commands by selecting each user.
- Generate Access for General Ledger Code Combinations
- Generate Access for Employee Analysis