A conflict does not have to live inside one system. Somebody who can raise a purchase order in one system and approve the payment in another holds a genuine segregation of duties conflict, and neither system sees it. Analyzing each system separately reports nothing, because in isolation each grant is legitimate.
Cross-system analysis combines a person's permissions across every loaded system and evaluates the ruleset against the union.
What it needs
Two things: the systems loaded as separate data sources, and a way to tell that an account in one is the same person as an account in another.
Identity is the hard part
Account names rarely match across a landscape. The same person may be JSMITH in one system, SMITH_J in another, and a numeric ID in a third. Without a mapping, the analysis sees three unrelated users and the combined conflict never fires.
Supply a USER_CANONICAL_MAPPING file on each data source:
| Column | Meaning |
|---|---|
User ID | The account name in this system |
Canonical Name | The person that account belongs to |
The file must have exactly these two columns. An account with no mapping row becomes its own canonical identity, so partial mapping is valid and sensible: map the populations that matter and leave service accounts alone.
Running it
- Load every system in scope as its own data source
- Place the canonical mapping file on each
- In the analysis criteria, enable Cross system
- Select all the systems to combine under System
- Run the analysis
Cross-system evaluation applies to users analysis. Roles analysis remains per-system, because a role exists in one system and its design cannot be cross-system by nature. A business role bundling roles from several systems is the cross-system case at the role layer, handled through IAM business roles.
Rulesets for cross-system risks
A cross-system risk is one whose functions name different systems. The System column of each ruleset row states where that function is expected to be exercised, so a rule with one function in ERP_PROD and another in S4_PROD fires only on a user holding both.
System values must match your data source names exactly. This is the most common reason a cross-system rule silently never fires. See Creating Custom Rulesets.
Reading the result
Two columns carry the identity distinction:
User IDis the canonical identity, the personLocal User IDis the account in the individual system
They are identical when no mapping applies and differ where a canonical name resolves to a different local account. On a cross-system finding, the detailed report shows one canonical user with rows attributed to several systems and several local accounts, which is exactly the evidence needed to explain the conflict to each system's owner.
Simulating across systems
A simulated new user needs a canonical name for cross-system work. Without one, the same simulated person defined in two systems is treated as two users and the cross-system conflict between them is not reported. See Simulating New Roles and Users.
Verifying coverage
Before trusting a cross-system result, confirm the mapping actually landed. A mapping file that was not recognized, because of a third column or a renamed header, produces a clean-looking analysis that quietly reports nothing cross-system. Check the data source Info tab for the mapping table and its row count. See Managing Data Sources.