Slimmer dan CoPilot

Tijdens het schrijven van code via bijvoorbeeld PowerShell gebruik je hier en daar wat hulp van CoPilot. Als er dan een onverklaarbare foutmelding verschijnt, vraag je weer CoPilot om hulp. CoPilot gaat dan letterlijk en figuurlijk de eigen code analyseren. Wonder boven wonder is er dan altijd iets dat beter kan. Gelukkig is de mens nog altijd slimmer dan CoPilot. Neem dit stukje code om bijvoorbeeld een client secret aan een Azure AD app registratie toe te voegen.

Function Add-AzureAdSecret {

    # Check for existing application and create secret if necessary
    try {
        $app = Get-MgApplication -Filter "displayName eq '$appName'"
        if (-not $app) {
            Write-Host "App registration does not exist. Skipping creation of secret."
        } else {
            Write-Host "App registration exists. Creating secret."

            $passwordCredential = @{
                displayName = $secretDisplayName
                startDateTime = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ssZ")
                endDateTime = (Get-Date).AddYears(2).ToString("yyyy-MM-ddTHH:mm:ssZ")
            }

            # Add the password credential to the application
            $newPassword = Add-MgApplicationPassword -ApplicationId $app.Id -PasswordCredential $passwordCredential
            $appSecret = $newPassword.SecretText

            # Update environment variables based on keys in the hashtable
            if ($variables.ContainsKey('Crm:ClientId') -and $variables.ContainsKey('Crm:ClientSecret')) {
                $azureAdParameters = @{
                    'Crm:ClientId' = $app.AppId
                    'Crm:ClientSecret' = $appSecret
                }
            } elseif ($variables.ContainsKey('CrmClientId') -and $variables.ContainsKey('CrmClientSecret')) {
                $azureAdParameters = @{
                    'CrmClientId' = $app.AppId
                    'CrmClientSecret' = $appSecret
                }
            } else {
                Write-Host "No matching environment variable keys found. Skipping environment variable update."
                return
            }

            Write-Host "Generated Client Secret: $appSecret. Now updating environment variables"
            $redirect = (Update-AzFunctionAppSetting -Name $azureFunctionName -ResourceGroupName $resourceGroup -AppSetting $azureAdParameters) 2>$null
            Write-Host "Updated the Azure function with a client secret of two years"
        }
    } catch {
        Write-Error "Failed to create or retrieve the application or secret. Error details: $_"
    }
}
# End Function Add-AzureAdSecret    } catch {
        Write-Error "Failed to create or retrieve the application or secret. Error details: $_"
    }
}

Toch niet slimmer dan Copilot?

It seems like the script is encountering issues when adding the client secret via script. Here are a few potential reasons and solutions:

Error Handling: Enhance the error handling in the script to capture more detailed error messages. This can help identify the exact point of failure.

Timing Issue: There might be a delay in the propagation of the new secret. Try adding a short delay after creating the secret before using it in the subsequent steps.

Permissions: Ensure that the script has the necessary permissions to create and update secrets. Verify the role assignments and permissions for the service principal.

Environment Variables Update: The script might not be updating the environment variables correctly. Double-check the logic for updating the environment variables and ensure they are being set properly.

Start-Sleep -Seconds 10  # Adding delay

Daarna weer een nieuwe response

Unfortunately, I can’t directly verify which secret is correct or incorrect based on the values provided. However, here are some steps you can take to troubleshoot:

Check for Typographical Errors: Ensure there are no typos or extra spaces in the secret values.
Expiration: Verify that the secret hasn’t expired. You can check the expiration date in the Azure portal.
Permissions: Ensure the secret has the necessary permissions to access the resources.
Consistency: Make sure the secret is correctly set in the environment variables and matches the one in Azure AD.

If you manually change the secret and it works, it might be worth regenerating the secret and updating your script with the new value. This often resolves unexpected issues.

Mijn response richting CoPilot

The first two were created via script, while the others are created by hand via the portal.

t3D8Q~v9c5arpv.tuV_UXx7Cx-GlFCe2yFKE-d
eW9lM8Q~Wvb1uTi0bnTyVxjeFPkkRg62.Uw
Xox8Q~QmKph~Lmwhwt6LcDXjplEZInVD4YBErcyg
Uqa8Q~Fdr.qwV6-VC5w9~F3VqA4WQ3_IeyqqhccL

Could it be that the following code generates wrong secrets (CoPilot had daar nog niet aan gedacht en gelukkig is de mens toch nog iets slimmer dan CoPilot)

$passwordCredential = @{
                displayName = $secretDisplayName
                startDateTime = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ssZ")
                endDateTime = (Get-Date).AddYears(2).ToString("yyyy-MM-ddTHH:mm:ssZ")
            }

            $newPassword = Add-MgApplicationPassword -ApplicationId $app.Id -PasswordCredential $passwordCredential
            $appSecret = $newPassword.SecretText

Wederom een response van CoPilot

It seems like the issue might be related to how the secrets are generated via the script. Here are a few things to consider:

Propagation Delay: There might be a delay in the propagation of the new secret. Adding a short delay after creating the secret might help.

Date Format: Ensure that the date format used in the script is correct and matches the expected format. The ToString("yyyy-MM-ddTHH:mm:ssZ") format should be fine, but it’s worth double-checking.

Permissions: Verify that the script has the necessary permissions to create and update secrets. The service principal running the script should have the Application.ReadWrite.All or Directory.ReadWrite.All permissions1.

Secret Length and Complexity: Sometimes, the generated secrets might not meet the complexity requirements. Ensure that the secrets generated by the script are sufficiently complex.

Mijn vraag hoe de date format te analyseren. Dat kon volgens CoPilot via een nieuw script.

Yes, you can verify the expiration date and time of the client secret using the Azure AD Graph API. Here’s how you can do it:

Retrieve Application Details: Use the Get-MgApplication cmdlet to retrieve the details of the application, including the passwordCredentials property which contains the expiration date.
Check Expiration Date: Inspect the endDateTime property of the passwordCredentials to verify the expiration date and time.

Here’s a sample script to help you verify the expiration date and time:

# Connect to Microsoft Graph
Connect-MgGraph -TenantId $TenantId -Scopes "User.Read","Application.ReadWrite.All","Directory.ReadWrite.All" -NoWelcome

# Retrieve application details
$app = Get-MgApplication -Filter "displayName eq '$appName'"

# Check expiration date of client secrets
foreach ($credential in $app.passwordCredentials) {
    Write-Host "Secret Display Name: $credential.displayName"
    Write-Host "Start Date: $credential.startDateTime"
    Write-Host "End Date: $credential.endDateTime"
}

De date format was perfect volgens de output.

CoPilot gaf echter niet op

Your code for setting the endDateTime looks correct. It uses the AddYears method to add two years to the current date and formats it in the ISO 8601 format (yyyy-MM-ddTHH:mm:ssZ). This should work as expected.

Tot slot. De oplossing was deze:

$passwordCredential = @{
displayName = $secretDisplayName
startDateTime = (Get-Date)
endDateTime = (Get-Date).AddYears(2)
}

Meer informatie over bijvoorbeeld Add-MgApplicationPassword vind je op de Microsoft site. Informatie over de auteur vind je op de site van Digitale Mels.

Happy Scripting 🙂