Introduction
This article details the process of troubleshooting Azure Web App connection issues due to expired client secrets in Dynamics 365. We'll cover the steps we took to identify the problem, our strategy to fix it, and an optional better practice of using Azure Key Vault to manage client secrets.
Identifying the Problem
Our application hosted on Azure Web App was encountering connection issues. The error message was "Localhost: 44371 refuses to connect," implying that the redirect URI for our application was misconfigured or pointing to an invalid address.
On further investigation, we found an expired client secret in Azure Active Directory (AAD), which caused authentication failures. The expiration of the client secret meant that our application couldn't authenticate correctly with Dynamics 365.
The Resolution Steps (Please be aware that the required licenses for those steps are Visual Studio, Azure Subscription, the required security role for Azure Active Directory is 'Cloud Application Administrator', or the Owner of the App: Leigh.Fitzpatrick@metisc.com.au , Alan.Toogood@metisc.com.au)
Here's what we did to resolve the problem:
Identified the Expired Client Secret: In the Azure portal, under Azure Active Directory (https://entra.microsoft.com/), we navigated to App Registrations (MiResources - Prod), then to Certificates & secrets. Here, we saw several expired client secrets and a valid one (The valid one will expire 02/07/2025). If all the available Client Secrets are expired, please use the + New Client Secret to get a new one, store it, and please be aware that the secret value will only be visible the first time it got created.
Updated the Web.config file: Go to DevOps (Summary - Overview (azure.com)), Repos, and then Files. Download the Project Via the little three dots Dropdown Menu, Download as Zip. Then we should unzip the file, open the .sln file (MiResources.sln) in Visual Studio. The VS version as of the article is written is VS Enterprise 2022.
Then navigate to Web.config file, find the line " <add key="xrmconnection" value="AuthType=ClientSecret;RequireNewInstance=false;Url=https://metisc.crm6.dynamics.com/;ClientId=8d413b59-26b3-4697-8653-478d34da08b6;ClientSecret=xxxxxxxxxxxxxxxxxxxxxxx;LoginPrompt=Never;" />" The length of the ClientSecret might change or be different. Change ClientSecret with the updated/new/valid one.
Then navigate to Web.mcs-prod.config file, find the line " <add key="xrmconnection" value="AuthType=ClientSecret;RequireNewInstance=false;Url=https://metisc.crm6.dynamics.com/;ClientId=8d413b59-26b3-4697-8653-478d34da08b6;ClientSecret=xxxxxxxxxxxxxxxxxxxxxxx;LoginPrompt=Never;" />" The length of the ClientSecret might change or be different. Change ClientSecret with the updated/new/valid one.
Right click on the MiResources.UI, Build.
Wait after the build finished, then Right click on the MiResources.UI again, click on Publish.
In the publish page, click on More actions, in the drop down menu, click on the Edit
In the pop up window, click on the Connection on the left hand side, in the Password field, the password is: bPXHhAKPkxclcLdGeE2cnMcd6FyomlTyvhwk7zQ9TepaoZ1P5Wwbv9RcDgwY.
Optional (Have to access from Alan's account Alan.Toogood@metisc.com.au) This password can be found from Azure Portal (https://portal.azure.com/) -> mcs-resourcing app (https://portal.azure.com/#@metisc.com.au/resource/subscriptions/e939e531-d1e6-4b3c-a224-c0eb88fb460e/resourceGroups/mcs-resourceplanning-rg/providers/Microsoft.Web/sites/mcs-resourcing/appServices) -> Deployment -> Deployment Center -> FTPS credentials -> Application scope -> Password -> click on the eye icon to show the password.
In the same window, click on the Settings on the left hand side, in the Configuration field, select Mcs-Prod from the drop down.
Click Save from the bottom.
Click Publish at the top right corner. The website should open automatically after publish, check if the website is working properly.
Commit the changes to DevOps if everything is working fine.
Updated the Redirect URI: In the Azure portal, under Azure Active Directory, in App Registrations, found MiResources - Prod, we navigated to Authentication. In the Redirect URIs section, we updated the localhost address to the URL where our application was hosted (https://mcs-resourcing.azurewebsites.net).
Published the Web App Again: In Visual Studio, we published our application to Azure Web App.
After these steps, the connection issue was resolved.
Better Practice - Using Azure Key Vault
Azure Key Vault provides a more efficient and secure method of managing client secrets. It allows the centralized management of secrets, secret versioning, secure secret access, and auditing.
Instead of having the client secret hard-coded within the application or stored in less secure locations, the client secret can be placed in Azure Key Vault. The application can then retrieve the client secret directly from the vault, reducing the risk of the secret being exposed.
Furthermore, with Azure Key Vault, alerts can be configured to notify the necessary parties before the expiration of the secrets, ensuring they are updated on time.
Conclusion
While this case revolved around the Azure Web App refusing connection due to an expired client secret, it's crucial to recognize the potential benefit of Azure Key Vault in managing client secrets. This tool not only provides a more secure secret management system but also helps avoid potential disruptions in service due to expired secrets, enhancing the overall security of your Dynamics 365 setup.