hoping to get some clarity on service principal use in non expiring pbi behavior

[db042190]

Hi i just reread dinesh's excellent post at https://community.fabric.microsoft.com/t5/Service/2-of-3-steps-done-for-non-expiring-id-in-pbi/m-p/4... more closely.   Can he or the community shed a bit more light?   We have a non expiring AD id (i think what dinesh calls a managed or user acct) being used as creds to alleviate the normal credential expiration issues in pbi.   We want to take this to the next level so that upon report/dashboard republishing  by our users, existing connections (semantic model conns) dont get broken.

Is Dinesh saying our current non expiring AD ID cant be leveraged to do this (ie be a service principal also) in option 1 or 2?  Or it can   by simply adding a secret or cetificate to Azure?  If we arent interested in embedded or api, and we already have pro licenses and gateway admin cooperation, do we need anything else like Azure key vault (possibly at the cost schedule shown there)?  Do i understand that key vault's value is "safe keeping" but not exactly required to do all this?   I apologize, this became confusing to me and i'm trying to beter understand.

without embedded and api, options 1 and 2 seem identical to a company where every employee has pro anyway, and we have the cooperation of the gateway admins.

[v-agajavelly]

Hi @db042190 ,

Have you had a chance to review the suggestions shared earlier? If yes, please let us know your progress. If not, kindly share where you’re facing challenges we’re happy to assist you further.

Regards,
Akhil.

[db042190]

still no response (afaik) to my 9/15 request for clarity.   

[v-agajavelly]

Hi @db042190 ,

Just checking back in did the details shared above help clarify your questions around Key Vault and service principal setup? Let us know if you were able to try this out or if you’re running into anything else, happy to help further.

Regards,
Akhil.

[db042190]

looking at this now.    bear with me.

[v-agajavelly]

Hi @db042190 ,

Hey As asked from you,
1. Is Azure Key Vault required, or just recommended?

Azure Key Vault is not strictly required, but it is highly recommended. It offers secure storage of credentials like client secrets and enables automated certificate rotation. So while you could store secrets directly in Azure AD, leveraging Key Vault will improve security and manageability. bellow is the official document.
Azure Key Vault Overview - Azure Key Vault | Microsoft Learn
2. Are there additional steps after creating the SP?

Once the SP is created and given a secret or certificate.

• Ensure the SP has been granted the necessary API permissions in Azure AD.
• The SP must be assigned sufficient access to relevant Power BI workspaces or semantic models.
• Optional but recommended: store the SP credentials in Azure Key Vault instead of hardcoding.

bellow is the official document.
Create Azure service principals using the Azure CLI | Microsoft Learn
Use Azure service principals with Azure PowerShell | Microsoft Learn

Please let us know if you have any other further queries on issue. happy to help you.

Regards,
Akhil.

[db042190]

thx Akhil, i can only ask this in my own words before reading the docs ...1) after a cert or secret is assigned to a non expiring USERID in azure, is it (the userid) officially a service principal?,  2) if we dont use api's currently, and dont care about cli and powershell right now,  and that USERID is ALREADY the credential we use in a handful of pbi dashboards, and that userid was made an SP,  can we assume there are no more steps required before the next re publish by our user on one of those  dashboards works seamlessly without breaking the report? ie he doesnt have to contact IT to reset the connection.   ie the type (i think there are a few options ) of authorization used on such a dashboard need not change prior to the next re publish.  

we already get that there is maintenance going forward on expiring certs and / or secrets  in azure but we believe at the moment that is worth the price if we stay ahead of the game when it comes to a smoothe experience for our users going forward.

[v-agajavelly · Accepted solution]

Hi @db042190 ,

We ran into this exact situation recently, so I wanted to share what we learned in case it helps others.

1.If I assign a secret or cert to a non-expiring Azure AD user, is it now a Service Principal?

Nope. A user account stays a user account even if you assign a secret or cert to it. A Service Principal (SP) is something different: it’s created through an App Registration in Azure AD (now Microsoft Entra ID). That SP is tied to an application identity, not a human user. So you can’t “convert” a user into an SP just by adding a secret.

If you want a true SP, you’ll need to.

• Register a new app in Azure AD
• Generate a client secret or certificate
• Use that app’s identity (App ID + secret/cert) to authenticate

2.If we’re already using that user ID in Power BI dashboards, and we “make it an SP,” will republishing still work without breaking anything?

If you’re still using the same user account (not a real SP), and you just added a secret or cert to it, then yes your dashboards should continue to work as long as.

• The user still has access to the datasets/workspaces
• The credentials haven’t expired
• Nothing else (like tenant settings or gateway configs) has changed

So in that case, your next republish should go through without needing to reset the connection or involve IT.

But, if you switch to a real SP (App Registration), then you’ll likely need to.

• Update the data source credentials in Power BI
• Possibly rebind the dataset or update the gateway connection
• Make sure the SP has the right permissions

Final suggestion's from my end.

You're absolutely right that managing cert/secret expiration is a tradeoff. But if you stay ahead of it, it’s worth it for the smoother experience and better security. Just be clear on whether you're sticking with a user account or moving to a true SP because Power BI treats them very differently.

Regards,
Akhil.

[db042190]

thx Akhil,  regarding

it sounds like you are saying i dont need an sp to mitigate the conn breaking on next republish.  That a regular id with secret or cert would work just as well.    But isnt it true that if one of our users who isnt an admin republishes his own report that already uses that non sp that now has a cert or secret , that action will break the conn ?   That the only way for the conn not to break and for him to be allowed to republish without knowing the non sp pswd is that it has to an sp?     I'm doing my best, sorry. 

[GilbertQ]

Hi @db042190 

What I would recommend is that very soon all user accounts will need to have Multi Factor enabled. What this means is that when the token expires or has to be re-authenticated you will not only need the password but also the multi factor code. This has to be inputted.

While using a service principal it will not require multi factor and is the recommened path!

[db042190]

thx Gilbertq.   Im not sure that addresses the question of republishing breaking conns etc on which non expiring ids are already being uised.   And whether non expiring ids can also be service principals.   But thank you.

[GilbertQ]

Hi there,

As far as I'm aware, when republishing it should not break existing connections when using service principles. The other option is to test it out with an existing test model to make sure it works as expected.

[db042190]

Gilbertq, the question is whether the existing userid can simply be turned into a service principal by giving it a secret or certificate in azure.  We already know getting this right will prevent conns from breaking on republish.   The other 2 underlying questions atre 1) do we really need the vault feature too, 2) is there another step after the secret or cert is associated, maybe an atrtribute (auth type?) on the existing semantic model conns themselves, the conns that already use this non expiring id to generate pbi dashboards and reports.   the reason its not so simple and we cant simply "test" ,for us ,is that we have to get other people involved in doing this and cant send them on wild goose chases.   

[collinq]

Hi @db042190 ,

In the interest of getting the attention of @v-dineshya I have added them here! 

[db042190]

thank you collinq.

[db042190]

I'd like to clarify one other item.   Lets say the existing id can also be a service principal.   And mostly what needs to be done to do that is to add a secret or certificate to that id in azure.   Will those reports that already use our nonexpiring/elevated id magically just stop breaking conns when republished by our users?  or do we need to perhpas re enter the id and/or set a settings attribute (maybe type of auth) differently or maybe create a different conn?