dotnet
Tenant ID getting mangled
On a fresh deployment, using the install utility and ARM template, the admin app is mangling the tenant ID. Specifically it's combining common with the actual tenant ID to produce something like the following (actual tenant ID redacted):
System.Net.Http.HttpRequestException: Response status code does not indicate success: 400 (BadRequest). ---> Microsoft.IdentityModel.Clients.ActiveDirectory.AdalException: {"error":"invalid_request","error_description":"AADSTS90002: Tenant commonactualtenantid not found. This may happen if there are no active subscriptions for the tenant. Check with your subscription administrator.\r\nTrace ID: 4cef0c66-fd72-4852-9378-308f8f142b00\r\nCorrelation ID: 815618e0-6ccb-41de-af08-96086ba8de9e\r\nTimestamp: 2018-08-22 22:01:58Z","error_codes":[90002],"timestamp":"2018-08-22 22:01:58Z","trace_id":"4cef0c66-fd72-4852-9378-308f8f142b00","correlation_id":"815618e0-6ccb-41de-af08-96086ba8de9e"}: Unknown error
Instead of using the actual tenant, or just using the common tenant, it's concatenating the two. I've attempted re-deploying, and manually modifying the appsettings.json on the service. The appsettings file has the correct tenant ID, but it continues to concatenate common to the front of it.
Hi @kudakeru, I'm sorry to hear that.
I'm a bit confused as to the sequence of events and what was modified where.
The appsettings.json from the service should not need to be modified at all. The configurable values override that and are stored in the settings key vault that was created.
As far as I know, the only place the common endpoint is used is in the InstallUtility for login. After that, it shouldn't be anywhere else, and it's not one of the parameters stored in Key Vault.
Can you please clarify what the sequence of steps were?
Thanks for taking the time. We started by running the install utility, setting the necessary parameters in the ARM deploy template, and then running the ARM template deployment. We ran into some permissions issues because we were trying to use a keyvault in a different resource group, but that was easy to fix. This was when we ran into the issue with the tenant ID not being found.
In trying to troubleshoot that, I've attempted modifying the appsettings.json file directly through the resource explorer in Azure, and modifying the file via FTP. I've also tried a complete redeploy. The tenant ID has always been set to the correct value, but for some reason it's still trying to combine common with the actual tenant ID.
On Wed, Aug 22, 2018 at 5:30 PM, Oren Novotny [email protected] wrote:
Hi @kudakeru https://github.com/kudakeru, I'm sorry to hear that.
I'm a bit confused as to the sequence of events and what was modified where.
The appsettings.json from the service should not need to be modified at all. The configurable values override that and are stored in the settings key vault that was created.
As far as I know, the only place the common endpoint is used is in the InstallUtility for login. After that, it shouldn't be anywhere else, and it's not one of the parameters stored in Key Vault.
Can you please clarify what the sequence of steps were?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/onovotny/SignService/issues/45#issuecomment-415231980, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjCH4I7GCwVW_5jLE1YHMgRTH6InCTJks5uTfeUgaJpZM4WIfrv .