Are there useful powershell cmdlets / rest apis?
Yes, but per my test, we need to do that into two parts.
1.Set the Sign-on URL
, to do this, we need to call Microsoft Graph - Update serviceprincipal
.
In the Graph Explorer, use the request below.
PATCH https://graph.microsoft.com/beta/servicePrincipals/<object-id of the service principal>
{
"loginUrl": "https://azure.signtest.link"
}
Note: In the request above, you need to use the object-id of the service principal(Enterprise application), not the AD App(App registeration). You can find it in the Azure AD in the portal -> Enterprise Application
-> find your Tableau Server
-> get the Object ID
like below.
2.Set the Identifier
and Reply URL
, we could do this via Powershell Set-AzureADApplication
.
Sample:
$Identifiers = @(
"http://www.tableau.com/products/server",
"https://azure.idtest.link"
)
$ReplyUrls = @(
"https://azure.rptest.link/wg/saml/SSO/index.html"
)
Set-AzureADApplication -ObjectId <object-id of the AD App> -IdentifierUris $Identifiers -ReplyUrls $ReplyUrls
For the object-id of the AD App
, navigate to the Azure AD in the portal -> App registrations
-> find your Tableau Server
. After running the command, the settings will map to the enterprise application.
Check the result in the portal:
Update:
Not sure if it is a bug, if I create a new app without setting the Identifier
and Reply URL
manually in the portal, then just use the powershell above to set them, they will not map to the portal.
But if we check the service principal(enterprise application) directly via Microsoft Graph, we can see the powershell actually affected the service principal.
If we configure the settings manually in the portal first, then use the powershell to update them with other values, it works.
And it looks there is no way to set the Default Reply URL
via powrshell or API, if we set the Reply URL
which is different from the one set manually in the portal, it will have a prompt like below.
But if we look into it, actually the Default
option is checked.
Update2:
Eventually, I find the trick, it is not a bug, we just need to set the preferredSingleSignOnMode
for the service principal first via Microsoft Graph, then we won't need to configure that in the portal manually.
Sample:
PATCH https://graph.microsoft.com/beta/servicePrincipals/<object-id of the service principal>
{
"preferredSingleSignOnMode":"saml",
"loginUrl": "https://azure.signtest.link"
}