Good evening, I have a problem with an application created and published by another person.
The application stopped working, no one realized that the secrets in the App Registrations were expired so I renewed them. Now if I try to start the application, I got this error message:
Unhandled exception. Microsoft.Extensions.Configuration.AzureAppConfiguration.KeyVaultReferenceException: ClientSecretCredential authentication failed: A configuration issue is preventing authentication - check the error message from the server for details. You can modify the configuration in the application registration portal. See https://aka.ms/msal-net-invalid-client for details. Original exception: AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app 'xxxxxxxxxxxxxxxxxxxx'.
The application is linked to App configuration and App Configuration is linked to Key Vault. I suppose I have to update somewhere the value of the secrets renewed but I can’t find where!!!
It’s probably something absolutely silly but I’m starting now with Azure and I can’t solve the problem! Can anyone please give me a hint? Thanks!
Looks like your application cannot authenticate with your Key Vault. In your application code, as part of AddAzureAppConfiguration call, you should have a call of ConfigureKeyVault, which specifies how you want your application to authenticate with your Key Vault. I guess the token credential you used there became invalid due to the secret rotation.
You can find more information about how to grant your application to access your Key Vault from this link:
https://learn.microsoft.com/en-us/azure/azure-app-configuration/use-key-vault-references-dotnet-core?tabs=core5x#grant-your-app-access-to-key-vault
Related
We have created an orchestration of pipelines with configurable linked datasources. These datasources have a parameter where we can enter the name of a secret and it will search in our keyvault for that secret. This is all configured in the UI. No programming necessary. And it works beautifully.
For some reason however it sometimes stops working when looking up secrets to write to an sql-table. And when it stops working, it stops all ETL-processes.
The error we receive is:
Failed to get the secret from key vault, secretName: xxxxx, secretVersion: , vaultBaseUrl: https://xxxxxxx.vault.azure.net/. The error message is: Acquire MI token from AAD failed. ErrorCode: request_throttled, Message: Your app has been throttled by AAD due to too many requests. To avoid this, cache your tokens see https://aka.ms/msal-net-throttling..
I don't see huge numbers of requests in the logging. I can't find anything suggesting this is a common problem.
I'm looking for either an answer on why this is happening so I can think of a solution OR possible solutions.
One possible solution could be to retrieve the secret in the beginning of the ETL-process and passing it on as a parameter to the proper activity. However, from a security standpoint that is not very safe as parameters are passed on and logged in clear text.
I've created an App Registration in Azure. I've then created a secret, and copied the value. The value doesn't contain any characters that need to be URL Encoded.
I've then granted the App Registration permissions on the downstream API that i want to call, via the "Expose an API" functionality - adding it to "Authorized Client Applications", and granting it a "Read" role.
I've then set a Redirect URL that matches the localhost i'm running it from, and enabled Implicit & Hybrid flows.
Once done, i've configured the API that i'm calling the downstream API from, in the same way that i've configured another previously (In fact, i just swapped the values out in AppSettings.json for testing purposes - so i know it's setup correctly, as it works with other values)
I've done this before - but the difference was that we had an Enterprise App behind the App Registration, and this time we do not. (I just wanted an App Registration to Authorise with).
So - the error i receive is always:
AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app
Any ideas as to where i may have gone wrong here?
I should mention that i've tried to generate several different Client Secrets, with varying expiration times, and ensured that none contain odd characters that i've seen mentioned before (hence the url-encoding comment above).
In addition, i've compared the two app registrations (as mentioned, the one backed by Enterprise App), and found no relevant differeces - but one works, and the other not.
EDIT: These are the steps i've taken to setup the App Registration:
https://learn.microsoft.com/en-us/azure/databricks/dev-tools/api/latest/aad/service-prin-aad-token#--provision-a-service-principal-in-azure-portal
I've then granted that app rights to call another API.
Still, it insists the Client Secret is wrong.
I followed instructions here: https://learn.microsoft.com/en-us/azure/vpn-gateway/openvpn-azure-ad-tenant
And also double checked same instructions here https://www.youtube.com/watch?v=Ur0WNjnXJrU
Everything went fine. When I download the Azure VPN Client, and import the xml profile that Azure gave me, I log in, and then i get an error
Failure in acquiring AAD Token: Keyset does not exist
Why is it asking about a keyset? Nowhere did I set up certs. This is Azure AD Authentication type (not Radius and not Azure Certificate type which asks for root certs). So there is no place to select a cert. And the instructions do not indicate a certificate is needed with this Azure AD Authentication type.
Inside the VPN profile azurevpnconfig.xml, I can see a
<serversecret>[...]</serversecret>
and
<cert>
<hash>[...]</hash>
<issuer
i:nil="true" />
</cert>
where did those come from? I never set up any keys or certs. Is it just part of Azure?
The cause was the cached user/pass on the Microsoft Login. Instead of clicking in my remembered login in the list they provide, I clicked "Log in as different user", and I was able to log in. This may be due to MFA which is on.
Completely non-helpful error messages though!
The app
I have a web application on Microsoft Azure. The client is written in Vue.js and hosted via a Windows App Service. The server is built using Azure Functions, and hosted via a Linux Azure Functions App.
Both the client App Service and the server Function App use built-in authentication ("Easy Auth"), with Active Directory configured as the identity provider. I am able to log into each, separately, via AD.
Until recently, I was also able to make authenticated requests from the client to the server. The client has
"loginParameters": [
"response_type=code id_token",
"scope=openid offline_access api://<Application (client) ID>/user_impersonation"
]
in its authsettingsV2 and generated tokens' aud have the correct application ID. Passing the access_token from the client's /.auth/me response as a bearer token in requests to the server used to work.
The problem
I made a few configuration changes today, tested authentication, found that it was no longer working, and backed them out. Unfortunately, reverting those changes didn't fix the issue and generated tokens are no longer being accepted by Easy Auth on the server:
{
"code": 401,
"message": "IDX10205: Issuer validation failed. Issuer: '[PII is hidden. For more details, see https:\/\/aka.ms\/IdentityModel\/PII.]'. Did not match: validationParameters.ValidIssuer: '[PII is hidden. For more details, see https:\/\/aka.ms\/IdentityModel\/PII.]' or validationParameters.ValidIssuers: '[PII is hidden. For more details, see https:\/\/aka.ms\/IdentityModel\/PII.]'."
}
Okay, so the issuer is not in the list of valid issuers. But Azure hides personally identifiable information in exceptions by default so I can't see the issuer or any of the valid issuers.
One option appears to be:
If you need to see the full information present in exceptions, please set IdentityModelEventSource.ShowPII to true
but this looks like a reference for configuring authentication myself using C#. I don't see any way to change this setting when using Easy Auth.
Maybe I can access raw logs. Let's see, I should be able to see this information by enabling application logging:
If you enable application logging, you will see authentication and authorization traces directly in your log files
To enable application logging for Linux apps or custom containers in the Azure portal, navigate to your app and select App Service logs.
But that option is not available:
A lot of the Function App documentation links to App Service documentation, so it would seem that Function Apps are a special kind of App Service App, but maybe not. The preceding quote is from App Service documentation, but I got there following links from Azure Function App documentation.
Alright, let's see if there's a way to enable application logging for Function Apps. Azure Monitor Logs look promising, but none of the generated logs appear to be about Easy Auth. I just see messages about the service starting. Maybe that's because, on Linux apps, Easy Auth runs in an isolated environment and therefore wouldn't be included in diagnostic logs:
The authentication and authorization module runs in a separate container, isolated from your application code.
So… how can I get more details about this error? Easy Auth is recommended as an option for authentication with Function Apps, and I'd hope that there's a way to get more information about what's happening.
I have seen Azure App Service Authentication / Authorization returns HTTP 401 IDX10205: Issuer validation failed and have already set accessTokenAcceptedVersion to null in the manifest. That Q&A helped me get the token passing working in the first place, and I have not changed that value.
I am trying to use custom policy to create a passwordless signin/signup flow in azure b2c. I have modified this sample a little bit and using it. So now I am able to see the login and signup screens but when I am trying to login or signup , the process starts and goes ahead but finally it gives me an error saying - AADB2C: Encryption key must be a 256-bit key error. The user signup actually happens behind the scenes because I am not able to use the same email id again to signup, so the issue is with the sigin operation actually.
I checked this answer but it did not help.
Have been trying to find the solution for very long time. Desperately need some help. Thanks.
Likely you have created the B2C Policy Key (TokenSigningContainer) incorrectly.
Delete the B2C Policy Keys that you have setup.
Run the setup tool here - It will reprovision the B2C starter pack, and create the keys automatically if they do not exist.
Run the quick deploy for this passwordless sample here.
As you said you have checked the provided answer but can you check again the key created from the following uri? The error suggest that there is an issue while key was created. If possible delete the key and recreate it with same name used in code.
I had this same problem. My issue was the encryption key was set to signing instead of Encryption.
When creating the Signing, and Encryption Key's under the Policy Keys section of the Identity Experience Framework. Please double check that they are both of type RSA and that the "signing" key is configured for signing, and the encryption key is configured for encryption.