Featured Image courtesy Miguel Á. Padriñán.

I recently ran into a small issue with this blog. The credentials that Github workflows use to deploy the application had expired. As someone who doesn’t login to Azure on a daily basis and whose primary role is not application development on the cloud, I did not see this coming.

So my Github action to deploy this blog failed with the following message:

AADSTS7000222: The provided client secret keys for app '***' are expired. Visit the Azure portal to create new keys for your app: https://aka.ms/NewClientSecret, or consider using certificate credentials for added security: https://aka.ms/certCreds.
Trace ID: bd3c9b5a-5677-4dbf-9136-78883da00700
Correlation ID: cdd461df-0722-4770-9b9a-d97e29181d94
Timestamp: 2022-04-18 18:07:59Z

I understood that a credential had expired, which logically meant that I had to reset the credentials for the account/service principal that was being used by the continuous deployment setup for this blog.

The problem was: I didn’t know which service principal was used! Nor did I remember how I created it in the first place. How do I reset the credentials for an account I don’t remember?

Resetting credential on Azure Portal

If you head to Azure portal > Azure Active Directory > App Registrations, you’ll be able to see all the applications that have been registered with Active Directory for logging in using whatever means you might have configured.

Click on the Sign-in logs on the left hand side navigation pane. This will allow you to view a list of log-ins and failures. For me, I knew it was a service principal, so I chose Service Principal sign-ins to find out which one failed. And I found it!

Sign-in logs

Now that I found the service principal, all I had to do was reset the credential. And I searched for credential reset from microsoft’s logs and found the following command and executed it.

az ad sp credential reset --name "myawesomeblog.a99.net.bool.winux.com"
{
  "appId": "646bb884-c39e-4906-a8da-3157cd11fa6a",
  "name": "myawesomeblog.a99.net.bool.winux.com",
  "password": "dpTF3q#JW8ZjXZLaEOEBi2_3yCLNiDzn6C8",
  "tenant": "a3b8ff66-42a9-4cf0-8e7b-40c1455bc635"
}

Obviously all the GUIDs and fully qualified names in the example are garbled and not real.

The JSON object output seemed like the thing I needed. And I tried replacing the Github actions secret.

Little did I know that this wasn’t really what was required for az login to work. The build action failed action. So looking back at how my Github actions actually logged into Azure, I realised that the command I used then was az ad sp create-for-rbac. So I understood that the output of the earlier command clearly didn’t match this one’s output.

So the right way to reset credentials was to run the create-for-rbac command with the right set of arguments:

  • name - this is the name of the service principal
  • role - as a contributor
  • scopes - the full url of the resource group
  • sdk-auth - this controls the output result in compatible with Azure SDK auth file.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

az ad sp create-for-rbac --name "myawesomeblog.a99.net.bool.winux.com" --role contributor \
                            --scopes /subscriptions/3301904f-eee1-4fa8-b8bf-63ec987ba470/resourceGroups/myawesomeblog \
                            --sdk-auth
The underlying Active Directory Graph API will be replaced by Microsoft Graph API in Azure CLI 2.37.0. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
Option '--sdk-auth' has been deprecated and will be removed in a future release.
Found an existing application instance of "646bb884-c39e-4906-a8da-3157cd11fa6a". We will patch it
Creating 'contributor' role assignment under scope '/subscriptions/3301904f-eee1-4fa8-b8bf-63ec987ba470/resourceGroups/myawesomeblog'
  Role assignment already exists.

The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
{
  "clientId": "7d38beef-6844-434e-994c-2e99fa413dd2",
  "clientSecret": "dpTF3q#JW8ZjXZLaEOEBi2_3yCLNiDzn6C8",
  "subscriptionId": "3301904f-eee1-4fa8-b8bf-63ec987ba470",
  "tenantId": "a3b8ff66-42a9-4cf0-8e7b-40c1455bc635",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

Here again, all the GUIDs and fully qualified names in the example are garbled and not real.

Now if you pasted the JSON output of this command into the Github action secret that you configured for your build, you achieve great success! My build was back up and running and I could forget all this again.