[FEATURE] Extend the documentation with an example script on how to handle authenticating to multiple tenants by your own function

[tmaestrini]

I'd like to extend the existing documentation on how to handle authentication to multiple tenants by your own function.

At the time of opening this topic, there is a lack of documentation here with the note “content to follow”:
https://pnp.github.io/powershell/articles/handlingmultitenantauth#idea-1-create-your-own-function-to-encapsulate-the-connection-logic

As I've already wrote an appropriate solution (script) for this, I'd like to share it with the community by adding it to the documentation: https://gist.github.com/tmaestrini/d1110a325f079d66a3498e303aeca078

[gautamdsheth]

Thanks for this , it is indeed a work in progress at the moment.
@KoenZomers - something we can add ?

[KoenZomers]

Thanks @tmaestrini . Just didn't have to finish the article yet but wanted to put this out there already to at least provide directions to think about for possible solutions. There are probably more creative things one can do to make this situation a little easier. I appreciate your offer to help us in completing the documentation around this. I had a glance at your script. I like it. The only thing I'm wondering about myself is if it would be necessary to check if an AppReg exists. My idea was to keep it as simple as possible not to overwhelm people or make them think like yikes does it need this many lines of code for something I used to be able to do in 1 line before. Hope you get my point.

I have this sample in my drafts to suggest for the article.

Function Connect-PnPOnlineDevTenant
{
	Connect-PnPOnline
https://tenant.sharepoint.com/
-Interactive -ClientId xxxxxx-760b-4e70-9812-dad05bea2106
}

What do you think? Maybe use this most basic sample in the article and add a link to your Gist for more advanced scenarios?

[tmaestrini]

Hey @KoenZomers, thank you for your reply! That's absolutely fine with me. I don't get the purpose of the wrapping function in your example. Essentially, it's only about the parameter -ClientId and the according appReg id.

And that's where my script comes into play. My intention was more like: if I have to deal with multiple tenants (what I definitely have to as a consultant that works in multiple customers' tenants), I don't have to take care of the registered app in the respective tenant. The script will always look for the registered app (called "PnP.Powershell"), get its id and deals with the authN. You only have to enter the url you'd like to connect to, and the script deals the rest.

But feel free to offer this as a solution for more advanced scenarios (e.g. as a multi-tenant solution for consulting purposes 😄 … What do you think?

[KoenZomers]

Ah! That's why you're doing the Azure call. Now I get it :) I would say that's then yet another good method to achieve the same goal.

My sample is aimed at creating your own functions for each tenant, whether it be dev/test/acceptance or customer a/customer b/customer c and just wrap them into your own connect. By that, you don't need to know the appId, but just use the right connect and you're good to go. Wouldn't depend on all your customers having named the appreg similarly and doesn't need an extra Azure call.

Both options could definitely fit. And as mentioned, there are probably tons of other ways to achieve the same. The article is not meant to be lecturing on THE way to achieve it, but rather to inspire people on ways that could address it.

[tmaestrini]

Ah, cool! Now I got your idea as well! :)

Wouldn't depend on all your customers having named the appreg similarly and doesn't need an extra Azure call.

Definitely, valuable argument. 👍 Up to you to use my script or not. Thanks for the interesting short exchange! ✋

[murchelon]

Hi all ! Loving the discussion ! Here we are planning on creating 1 wrap function to connect. When called, we plan to pass only the tenant URL.
Inside the function, there will be code that will extract the tenant name (to use it when/if necessary).

Also (the main point here): The function will have an inside table with all URLs and its correspondent ClientID.
This table could be a lookup to somewhere else, but we plan to hard code inside the function.

This way, we will call only 1 function to connect, anywhere we need it, and the function will know the right ClientId.

This approach cames with the problem of maintenance of this URL/ClientID table. But, these IDs wont change often and for our case, its totaly manageble.

thanks all!