Microsoft Fabric Community Conference 2025, March 31 - April 2, Las Vegas, Nevada. Use code FABINSIDER for a $400 discount.
Register nowGet inspired! Check out the entries from the Power BI DataViz World Championships preliminary rounds and give kudos to your favorites. View the vizzies.
Solved! Go to Solution.
I recently setup the SSAS Connector for a non-O365 client. Everything that @Seth_C_Bauer provided as reference is relevant. Even without O365, you will still have an Azure AD domain (<something>.onmicrosoft.com). In order to login to Power BI with your @companyname.com account, will need to go through the Azure AD steps at portal.office.com or in Azure Management to verify your company's domain. This has to be done regardless of whether you want to manage users independently as "cloud" users or whether you either want password sync or single sign-on by syncing with Azure AD Connect.
Once the domain has been added and verified, you can setup the SSAS Connector. The only change that you would need to make in local AD would be to change each user's domain from <companyname>.local to @companyname.com. This does not change their sign-on in the format domain\user, so they are still able to access everything in the domain as before. It does allow the local and Power BI login domains to match so that you do not receive the Effective User Name mismatch error.
@bdelaney well first, you need to get things synced up to use Azure AD. Then i would direct you to the in depth article here where it talks about setting things up in different domains with trust between them. Personally, the answer provided at the bottom of that support page doesn't give me the warm fuzzies about implementing outside one domain:
Question: What if I install the Power BI Analysis Services Connector on a computer in a different domain from my Analysis Services server?
Answer: No guarantees here. It all depends on the trust relationship between the two domains. If the two different domains are in a trusted domain model, then the Connector might be able to connect to the Analysis Services server and the effective user name can be resolved. If not, either the connection or effective username resolution can fail.
Hmm, I guess I should have worded that differently. You did not answer my question. This is only about the scenario of using the SSAS connector to an OnPrem server. I'm not even talking about Azure SQL DBs.
And the organization is not an Office 365 customer, but our domain is real and we all have domain email accounts.
I know about syncing Office 365 accounts and Azure (WAAD), but that is not part of my scenario here.
@bdelaney Hmm. ok. Let's baseline a few things.
1) Power BI is a Service that sits on top of 0365/Azure. If you sign up for Power BI, you are using Azure AD. If you need to sync your company, you need to make sure that is done appropriately prior to setting up a connector or anything.
2) All Tabular SSAS connections from the Power BI Service are to on-prem SSAS instances. There is no "SSAS Cloud Service".
Even SSAS instances set up on Azure VM's are considered "on-prem".
I would encourage you to read these pages.
Security - https://powerbi.microsoft.com/en-us/documentation/powerbi-admin-power-bi-security/
Administering Power BI - https://powerbi.microsoft.com/en-us/documentation/powerbi-admin-administering-power-bi-in-your-organ...
I recently setup the SSAS Connector for a non-O365 client. Everything that @Seth_C_Bauer provided as reference is relevant. Even without O365, you will still have an Azure AD domain (<something>.onmicrosoft.com). In order to login to Power BI with your @companyname.com account, will need to go through the Azure AD steps at portal.office.com or in Azure Management to verify your company's domain. This has to be done regardless of whether you want to manage users independently as "cloud" users or whether you either want password sync or single sign-on by syncing with Azure AD Connect.
Once the domain has been added and verified, you can setup the SSAS Connector. The only change that you would need to make in local AD would be to change each user's domain from <companyname>.local to @companyname.com. This does not change their sign-on in the format domain\user, so they are still able to access everything in the domain as before. It does allow the local and Power BI login domains to match so that you do not receive the Effective User Name mismatch error.
@deldersveld thanks, that is what I was looking for. Your detailed explanation exactly fits my scenario.
@Seth_C_Bauer sorry if I did not explain my question that well. Appreciate the references you included in your response.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code FABINSIDER for a $400 discount!
Check out the February 2025 Power BI update to learn about new features.
User | Count |
---|---|
60 | |
34 | |
30 | |
27 | |
27 |
User | Count |
---|---|
52 | |
52 | |
37 | |
15 | |
12 |