Azure AD Connect, internal domains and effective user names

[asok]

Hi,

I have a client with a tabular model that are now moving to Power BI for visualisation.

However, their active directory setup causes us problems. They have an internal domain "xyz.emea.int" and usernames like 12345. So logging in to their domain would be 12345@xyz.emea.int. Email addresses are more "user firendly", like bill.gates@companyX.se

We have installed the ssas power bi connector, as a test we created an ad user bill.gates@companyX.se and got it working. But that's not an option for the rest of the 300 existing users...

So, what we've so far is that we are syncronzing the email attribute  using Azure AD Connect (advise from local microsoft). However, effective user name is still sent as bill.gates@companyX.se to SSAS.

We can't change the internal logins from 12345@xyz.emea.int to bill.gates@companyX.se due to other systems relying on the structure, and also Power Bi is not important enough to restructure the entire AD.

How to we get Azure AD and Power Bi to translate bill.gates@companyX.se to 12345@xyz.emea.int?

[Greg_Deckler]

Well, according to this:

https://support.powerbi.com/knowledgebase/articles/505324-troubleshooting-power-bi-analysis-service-...

Your username and domain name have to match between what is returned to Power BI and what is in your on-premises AD. So, you need the username to be 12345 and the domain to be xyz.emea.int.

[asok]

But it also says that:

"If you used an .onmicrosoft.com email address with Power BI, you may need to set up DirSync between your on-premises Active Directory and Azure Active Directory. "

Which is what I am trying to do...

[Greg_Deckler]

Here is an article that goes further in-depth about that:

https://support.powerbi.com/knowledgebase/articles/546004-power-bi-analysis-services-connector-in-de...

[asok]

Yes, I've read that. Doesn't help me though, unless I am missing out on something. Power BI still sends the external domain name (like onmicrosoft.com) to SSAS even though I am syncronizing with Azure AD.

[Greg_Deckler]

Well, it seems like what you ultimately want is for people to be able to login to Azure AD/Power BI with 12345@xyz.emea.int, which would then be able to resolve correctly with internal AD. In theory, and I am not a UPN expert, but you could create a local UPN for "CompnayX.se" so that people could logon locally as something like "12345@CompanyX.se". I don't see how "first.last@anything" is ever going to work, because that's not their username.

Ultimately, the problem seems to be a dirsync one in how you are mapping fields. You probably want to post something on TechNet to get this resolved. The easiest thing to do would be to sync "12345@xyz.emea.int" into the email address field of Azure AD so that users logon with that and then this should all work without the need of UPN's, etc., but I am not a dirsync expert either. A place to start would be:

https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect/

I think that the main issue is that Microsoft sort of assumes that if your on-prem domain is "domain.com" then your users logon with "username@domain.com" and that is also their email address. However, in the real world, this simply is not always the case.

[asok]

Thanks, well yes it could definitely be a dirsync / azure ad connect issue. I'll try posting something there, hope they won't say it's a Power BI issue...  

In my experience, basically all big companies have their ad set up this way, based on best practices from ms 10-15 years ago 😃   

[cwalch]

Did you solve the problem, because it's the same that we have.

[fbrossard]

Do you know if your client is using ADFS?

In this case, check your ADFS / Azure AD settings http://goo.gl/NKdlJL

You can also take a look at the authentication policy settings http://goo.gl/yQgJ4r

Good luck.