azure-sdk-for-python
azure-sdk-for-python copied to clipboard
Azure
Challenge resource wrong URL for On-Premise Azure Stack Hub
- Package Name: Not sure, but it's in this code: https://github.com/Azure/azure-sdk-for-python/blob/e88458b491d573ca5421b68968589bbf42f66e51/sdk/keyvault/azure-keyvault-secrets/azure/keyvault/secrets/_shared/challenge_auth_policy.py#L103
PS C:\Users\VMAdmin> pip list
Package Version
--------------------------- ---------
adal 1.2.7
azure-common 1.1.28
azure-core 1.26.1
azure-identity 1.12.0
azure-keyvault 4.2.0
azure-keyvault-certificates 4.6.0
azure-keyvault-keys 4.7.0
azure-keyvault-secrets 4.6.0
azure-mgmt-compute 29.0.0
azure-mgmt-core 1.3.2
azure-mgmt-keyvault 10.1.0
azure-mgmt-network 22.2.0
azure-mgmt-resource 22.0.0
azure-mgmt-storage 21.0.0
certifi 2022.12.7
cffi 1.15.1
charset-normalizer 2.1.1
cryptography 38.0.4
haikunator 2.1.0
idna 3.4
importlib-metadata 5.2.0
isodate 0.6.1
msal 1.20.0
msal-extensions 1.0.0
msrest 0.7.1
msrestazure 0.6.4
oauthlib 3.2.2
packaging 22.0
pip 20.1.1
portalocker 2.6.0
pycparser 2.21
PyJWT 2.6.0
python-certifi-win32 1.6.1
python-dateutil 2.8.2
pywin32 305
requests 2.28.1
requests-oauthlib 1.3.1
setuptools 47.1.0
setuptools-scm 7.1.0
six 1.16.0
tomli 2.0.1
typing-extensions 4.4.0
urllib3 1.26.13
wrapt 1.14.1
zipp 3.11.0
-
Package Version: Refer to the above.
-
Operating System: Windows Server 2016 datacenter
-
Python Version: 3.7.9
Describe the bug Due to a feature introduced in this September 22, 2022 commit: https://github.com/Azure/azure-sdk-for-python/commit/fe6841289a45be0e89404b04332b8f7b78921c16#diff-74dfc21536b65f2d85c7666248d3fe92e7580bbab14ff778b65437dd75062f61R102
Running Key Vault secrets on Azure Stack Hub (ASH), version 2209, as in the below: https://github.com/Azure-Samples/Hybrid-Python-Samples/blob/a30c816fde75856e8b7ed55beff2917cd9e5b100/keyvault/example.py#L115
Causes the following error:
ValueError: The challenge resource 'adminvault.azlr.onmicrosoft.com' does not match the requested domain. Pass `verify_challenge_resource=False` to your client's constructor to disable this verification. See https://aka.ms/azsdk/blog/vault-uri for more information.
This is because the resource_domain variable here:
https://github.com/Azure/azure-sdk-for-python/blob/e88458b491d573ca5421b68968589bbf42f66e51/sdk/keyvault/azure-keyvault-secrets/azure/keyvault/secrets/_shared/challenge_auth_policy.py#L103
Has the value adminvault.azlr.onmicrosoft.com.
While the value of request_domain variable here:
https://github.com/Azure/azure-sdk-for-python/blob/e88458b491d573ca5421b68968589bbf42f66e51/sdk/keyvault/azure-keyvault-secrets/azure/keyvault/secrets/_shared/challenge_auth_policy.py#L107
Has the value purple-bread-4613.adminvault.northwest.azs-longhaul-04.selfhost.corp.microsoft.com
This error did not occur in earlier versions of ASH environment.
The error message includes a link to: https://devblogs.microsoft.com/azure-sdk/guidance-for-applications-using-the-key-vault-libraries/
According to the blog, a work-around is to exclude the check by passing verify_challenge_resource=False, but I am wondering what does disabling the check do exactly? What if a user still wants the check, but not the error? Should this just be false always for Python SDK when using ASH? It should be mentioned that other SDKs work on ASH without this error, although I don't know if they also make this check.
To Reproduce Steps to reproduce the behavior: Run the following code (instructions for set-up is in the root README, and instructions for specific samples in the folder-specific README): https://github.com/Azure-Samples/Hybrid-Python-Samples/blob/a30c816fde75856e8b7ed55beff2917cd9e5b100/keyvault/example.py#L115
Expected behavior Should not throw an error.
Hi @TheOnlyWei, thank you for opening an issue! It looks like you've correctly dug into the source of the error; the resource we're seeing in the service's authentication challenge (adminvault.azlr.onmicrosoft.com) doesn't match the resource we're making a request to (purple-bread-4613.adminvault.northwest.azs-longhaul-04.selfhost.corp.microsoft.com). Because of the challenge resource verification feature, azure-keyvault-secrets is raising an error when the latter string doesn't end with the former string.
This challenge response verification is pretty unique to Key Vault -- most services don't have a challenge-based authentication scheme like this, and as the blog post you linked to mentions, there was a particular reason for adding this check to Key Vault interactions. That's most likely why other SDKs aren't seeing any errors.
You mentioned that
This error did not occur in earlier versions of ASH environment.
Do you mean that the same azure-keyvault-secrets package version, in another ASH environment, was able to make this request without raising an error? Or do you mean that this operation worked in the past, with an earlier ASH version (and possibly an earlier azure-keyvault-secrets version)?
Hi @mccoyp I don't remember the azure-keyvault-secrets version used in the past. But it seems the reason the errors didn't occur is because of the code I linked was recently introduced.
Would you advise for users using Azure Python SDK for ASH to always pass verify_challenge_resource=False when using Key Vault? Or should there be some fix for this so ASH users can use Azure Python SDK on ASH without needing to always pass verify_challenge_resource=False?
@TheOnlyWei I'm not personally familiar with ASH, so I don't know if I can necessarily make a recommendation. Based on documentation, it looks like the service lets you use Azure resources across datacenters -- which may be why a Key Vault's challenge resource wouldn't match the resource's request URL. In that case, it may be necessary to pass verify_challenge_resource=False in order to use Key Vault clients in this environment.
My general advice would be to only disable challenge resource verification when necessary, and to avoid doing so with user-provided Key Vault endpoints (as the blog post mentions). If you're providing your own vault endpoints, and/or the specifics of the service architecture require it, passing verify_challenge_resource=False to client constructors is the preferred method of avoiding these errors.
@mccoyp Okay, I will wait for further input from someone more familiar with ASH. Because at this point, it seems without always passing verify_challenge_resource=False for ASH environments I am using currently, the functionality of setting and getting Key Vault secrets would throw the error above.
Thank you for your feedback. This has been routed to the support team for assistance.
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @sijuman, @sarathys, @bganapa, @rakku-ms.
Issue Details
- Package Name: Not sure, but it's in this code: https://github.com/Azure/azure-sdk-for-python/blob/e88458b491d573ca5421b68968589bbf42f66e51/sdk/keyvault/azure-keyvault-secrets/azure/keyvault/secrets/_shared/challenge_auth_policy.py#L103
PS C:\Users\VMAdmin> pip list
Package Version
--------------------------- ---------
adal 1.2.7
azure-common 1.1.28
azure-core 1.26.1
azure-identity 1.12.0
azure-keyvault 4.2.0
azure-keyvault-certificates 4.6.0
azure-keyvault-keys 4.7.0
azure-keyvault-secrets 4.6.0
azure-mgmt-compute 29.0.0
azure-mgmt-core 1.3.2
azure-mgmt-keyvault 10.1.0
azure-mgmt-network 22.2.0
azure-mgmt-resource 22.0.0
azure-mgmt-storage 21.0.0
certifi 2022.12.7
cffi 1.15.1
charset-normalizer 2.1.1
cryptography 38.0.4
haikunator 2.1.0
idna 3.4
importlib-metadata 5.2.0
isodate 0.6.1
msal 1.20.0
msal-extensions 1.0.0
msrest 0.7.1
msrestazure 0.6.4
oauthlib 3.2.2
packaging 22.0
pip 20.1.1
portalocker 2.6.0
pycparser 2.21
PyJWT 2.6.0
python-certifi-win32 1.6.1
python-dateutil 2.8.2
pywin32 305
requests 2.28.1
requests-oauthlib 1.3.1
setuptools 47.1.0
setuptools-scm 7.1.0
six 1.16.0
tomli 2.0.1
typing-extensions 4.4.0
urllib3 1.26.13
wrapt 1.14.1
zipp 3.11.0
-
Package Version: Refer to the above.
-
Operating System: Windows Server 2016 datacenter
-
Python Version: 3.7.9
Describe the bug Due to a feature introduced in this September 22, 2022 commit: https://github.com/Azure/azure-sdk-for-python/commit/fe6841289a45be0e89404b04332b8f7b78921c16#diff-74dfc21536b65f2d85c7666248d3fe92e7580bbab14ff778b65437dd75062f61R102
Running Key Vault secrets on Azure Stack Hub (ASH), version 2209, as in the below: https://github.com/Azure-Samples/Hybrid-Python-Samples/blob/a30c816fde75856e8b7ed55beff2917cd9e5b100/keyvault/example.py#L115
Causes the following error:
ValueError: The challenge resource 'adminvault.azlr.onmicrosoft.com' does not match the requested domain. Pass `verify_challenge_resource=False` to your client's constructor to disable this verification. See https://aka.ms/azsdk/blog/vault-uri for more information.
This is because the resource_domain variable here:
https://github.com/Azure/azure-sdk-for-python/blob/e88458b491d573ca5421b68968589bbf42f66e51/sdk/keyvault/azure-keyvault-secrets/azure/keyvault/secrets/_shared/challenge_auth_policy.py#L103
Has the value adminvault.azlr.onmicrosoft.com.
While the value of request_domain variable here:
https://github.com/Azure/azure-sdk-for-python/blob/e88458b491d573ca5421b68968589bbf42f66e51/sdk/keyvault/azure-keyvault-secrets/azure/keyvault/secrets/_shared/challenge_auth_policy.py#L107
Has the value purple-bread-4613.adminvault.northwest.azs-longhaul-04.selfhost.corp.microsoft.com
This error did not occur in earlier versions of ASH environment.
The error message includes a link to: https://devblogs.microsoft.com/azure-sdk/guidance-for-applications-using-the-key-vault-libraries/
According to the blog, a work-around is to exclude the check by passing verify_challenge_resource=False, but I am wondering what does disabling the check do exactly? What if a user still wants the check, but not the error? Should this just be false always for Python SDK when using ASH? It should be mentioned that other SDKs work on ASH without this error, although I don't know if they also make this check.
To Reproduce Steps to reproduce the behavior: Run the following code (instructions for set-up is in the root README, and instructions for specific samples in the folder-specific README): https://github.com/Azure-Samples/Hybrid-Python-Samples/blob/a30c816fde75856e8b7ed55beff2917cd9e5b100/keyvault/example.py#L115
Expected behavior Should not throw an error.
| Author: | TheOnlyWei |
|---|---|
| Assignees: | mccoyp |
| Labels: |
|
| Milestone: | - |
@navba-MSFT I am actually part of the team and some of the people those people no longer on that team. I will probably be most familiar with this issue. Do you know where this requirement came from? Obviously, the current implementation isn't seamless for ASH, and I am just wondering if ASH users should always pass verify_challenge_resource=False to get around the issue due to URL mismatch.
@TheOnlyWei @navba-MSFT from a Key Vault perspective, passing verify_challenge_resource=False to client constructors will be necessary if the resource arrangement requires it -- like in the case described in this issue. The resource verification check was added to Key Vault clients to prevent authentication information leaks, primarily in the case where external users provide their own Key Vault endpoints.
I'm avoiding making a general recommendation that users always disable this feature because I don't know if ASH setups always conflict with resource verification checks (as opposed to only conflicting in particular setups). For cases like the one you've described, disabling this check is recommended. In general, if the vault endpoints you're using are trusted, disabling the check is fine.
I would ask ASH folks to review the feature guidance at https://aka.ms/azsdk/blog/vault-uri and make a recommendation to their users based on what the service requires and what the Key Vault team has recommended (for example, validating that user-provided vault URIs are legitimate if challenge resource verification is disabled).
Hi @TheOnlyWei. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.
Hi @TheOnlyWei, since you haven’t asked that we “/unresolve” the issue, we’ll close this out. If you believe further discussion is needed, please add a comment “/unresolve” to reopen the issue.