Skip to content

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:

  1. Permissions
  2. Included members
  3. 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 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. \ as the AD User Identity. If the domain user name is used, then the DAX filter must use the function USERNAME().

Analysis Models with inbuilt RLS

During this release, following models have inbuilt RLS in Analysis Models - Power BI.

  • Cash Planning

  • Employee Analysis

  • General Ledger

  • Group Reporting

  • Salary Review Analysis

  • Revenue Recognition

  • Inventory

  • Sales

    ​

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, Cash Planning , Group Reporting and Revenue Recognition models.

  • HCM - User mappings related to the built-in roles delivered by IFS for Employee Analysis and Salary Review Analysis models.

  • SCM - User mappings related to the built-in roles delivered by IFS for Sales and Inventory models.

  • Custom - User mappings related to any custom roles created.

AD User Identity mapping can be done based the below claim type setting.

When a User is added in the AD User Mappings page (Fnd User column), the AD User Identity is auto-populated based on the relevant User details. This is a suggested value, and it can be changed if required. In this scenario, the AD User Identity value against the user will be based on the system parameter claim and the Embed User Name Claim type can be switched accordingly as required.

  • When the claim type is upn (configured in the Setup Parameters page), the USERPRINCIPALNAME() DAX function will give the same value as the value in the Directory ID field of the relevant Fnd User (in the Users page).
  • When the claim type is emailaddress (configured in the Setup Parameters page), the USERPRINCIPALNAME() DAX function will give the same value the value in the User Email field of the relevant Fnd User (in the Users page).

Embed User Name Claim type = UPN

In the below image, claim type is set to upn, therefore the Directory ID is populated as the AD User Identity.

AD User Identity Value

Embed User Name Claim type = Email Address

In the below image, claim type is set to emailaddress, therefore the User Email is populated as the AD User Identity.

AD User Identity Value

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 (for General Ledger Model)
  • Generate Access for Internal Ledger Code Combinations (for General Ledger Model)
  • Generate Access for Employee Analysis
  • Generate Access for Cash Planning
  • Generate Access for Salary Review Analysis
  • Generate Access for Group Reporting

(It is not required to generate access for the Revenue Recognition Model, as only company access RLS is implemented.)