SAP BI 4.2 SP05: secWinAD where AD username != BI AccountName

[WalterK]

Hi,

We have a SAP BI 4.2 SP05 environment where the AD username ("123456") does not match the BI AccountName ("FLAST") and we want to use SSO for BI launchpad and Analysis for Office.

Which attribute does the BI user update use to "map" the users? In our scenario we cannot use userid as they are different. Email address is a unique identifier.

[BasicTek]

mapping uses the samaccount name in AD, the LDAP plugin will allow other variables but the AD plugin is hard coded to just the SAMaccountnanem. In the future they are talking about enhancing this to allow naming via 1-2 other variables such as email address for other types of authentication such as SAML, ADFS, etc But I haven't see that yet don't have any information on which version it may appear in just that it is in discussions.

[WalterK]

Hi Tim,

Thanks for the feedback, this is exacly the limitation that we are trying to solve. sAMaccountname does not match the (existing) SAP userid, that is used in BI and the backend systems. We have now decided to use the LDAP plugin where the attributes can be mapped, but that means we'll have to do without SSO to BI Launchpad (and AfO).

Cheers, Walter

[WalterK]

Hi Tim,

In this scenario we have an established BI system using secEnt (i.e. "FLAST") and need to configure secWinAD SSO. However the AD userids (i.e. "123456") do *not* match the existing usernames, so the automatic merging will not work.

The email address property is maintained for BI users, and matches the AD, so if we could somehow merge the userids based on this property that would be a great help. From your response the BI product doesn't do this, manual mappings need to be maintained, or there might be some custom tools that can help here (https://answers.sap.com/questions/736450/sap-businessobjects-assignment-of-user-aliases-sap.html)

Regards, Walter

[BasicTek]

If you are going to login via SSO then the login name of the account must match the technology used for SSO (in your case AD), you can attach any alias to the account but ensure nothing renames the account. In theory renaming the account should work, but I have seen cases where it causes problems, so to avoid potential problems the AD account should be the username in all cases, and other username based on enterprise, SAP or LDAP should be attached.

Now without any common username the auto mapping features of the plugin will not work, but we have 3rd party and consulting tools out there that may be able to assist in pairing accounts with non like usernames. See more about that in this thread

-Tim