Azure SDK for python behind a corporate proxy

[ArturSyl]

Type of issue

Code doesn't work

Description

Hello,

We are using a proxy and we intercept login.microsoftonline.com to verify which tenants users are going. However here when we intercept this request user get's error that ssl certificate is invalid. The proxy certificate is added to trusted root certificate so it works correctly for browser but not from Visual Studio. We tried whitelisting for ssl certificate bypass login.microsoftonline.com/tenantID but it fails, it only works when bypassing the whole login.microsoftonline.com which is not a good solution as we lose the tenants visibility in proxy.

Can you share how to use this code in VS behind a proxy ?

Cheers,
Arthur

Page URL

https://learn.microsoft.com/en-gb/python/api/azure-identity/azure.identity.clientsecretcredential?view=azure-python

Content source URL

https://github.com/MicrosoftDocs/azure-docs-sdk-python/blob/main/docs-ref-autogen/azure-identity/azure.identity.ClientSecretCredential.yml

Document Version Independent Id

03ee17be-6659-76b6-bcc1-44b2cb64b094

Article author

@lmazuel

Metadata

• ID: 71fdf00e-23cc-b602-03c7-072d908d1f44

[xiangyan99]

Thanks for reaching out.

Could you help give more details about:
"it works correctly for browser but not from Visual Studio"?

[github-actions]

Hi @ArturSyl. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[github-actions]

Hi @ArturSyl, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[ArturSyl]

Hello,

Apology for delayed response.

Normally in company we test connection in browser and in application. Here the user in VS is trying to obtain secret password using your azure sdk for python script. However there can be a situation that our policy blocks the connection due to specifing rule in place. This is why if possible we test also in browser and verify the logs. In browser we don't use azure sdk we just go to vault and check if connection is proper and we can verify the connectivity to the website.

However when using azure sdk for python user issues a connect request to login.microsoftonline.com which we ssl intercept on proxy and here it fails. This is probably request for azure environment. We use login.microsoftonline.com for proxy authentication and all O365 apps and it works correctly but here there is something maybe in the method of the request that it fails. In logs we only see the connection through VS is there, it's allowed but size in bytes is different.

The problem is we don't know why your azure sdk fails with login.microsoftonline.com through proxy. Is there a method to bypass the proxy, point to proxy (so we are sure that whole traffic always hits proxy), is there a token generated through your request that proxy strips, is your code validating if there is men in middle attack (proxy is a main in the middle device) and blocks the sending of some token etc.

In short.... how we can we approach your script when user is behind corporate proxy.

Thank you and happy holidays.

[xiangyan99]

Happy new year!

Thanks for sharing the information.

You can specify the proxy information when creating the credential object.

e.g.:

cred = ClientSecretCredential(proxies={'http': 'http://10.10.1.10:3148'})

please let us know if it does not work.

[github-actions]

Hi @ArturSyl. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[ArturSyl]

Hello, We tried this but it did not work. Our proxy lurks on the network level, you might say it's a bit of a transparent type of proxy, it steals the traffic the user is generating on port 80 + 443 and pushes it to the proxy. We can see the traffic in wireshark(tool for looking at packets) and we can that proxy got the traffic but the part for login.microsoftonline.com fails. It's only when we stop decrypting the traffic for this domain for your app when it starts to work. Normally this can happen when there is some token hidden tricks or some specific form of authentication and both of them don't like men in the middle to look at what they are doing or when some secure features are enable and when men in the middle is noticed they trigger and break the connection. Cheers. Artur wt., 2 sty 2024 o 18:32 Xiang Yan ***@***.***> napisał(a):

…

Happy new year! Thanks for sharing the information. You can specify the proxy information when creating the credential object. e.g.: cred = ClientSecretCredential(proxies={'http': 'http://10.10.1.10:3148'}) please let us know if it does not work. — Reply to this email directly, view it on GitHub <#33607 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMEHNFUSBTETHVIOSOGLWJ3YMRACZAVCNFSM6AAAAABAZNLBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZUGMZTAMZZGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Pozdrawiam, Artur

[xiangyan99]

Adding @rayluo for more insights.

[rayluo]

I don't really have a specific suggestion here.

1. On the one hand, Azure SDK's underlying auth library - MSAL - supports a proxies parameter. You can probably try it by this one-liner (currently containing incomplete proxies setting which you will need to adjust):

   python -c "import msal; print(msal.ConfidentialClientApplication('your_client_id', client_credential='your_secret', proxies=...).acquire_token_for_client(['your_scope']))"

   You can try this to see whether it works in your proxy environment.

2. On the other hand, that parameter in MSAL only works when using the default http client which is based on requests. But, AFAIK, Azure SDK uses its own http client, so, the test above may not mean anything in terms of the Azure SDK's behavior.

[xiangyan99]

@ArturSyl

Could you help to try the code Ray provided:

python -c "import msal; print(msal.ConfidentialClientApplication('your_client_id', client_credential='your_secret').acquire_token_for_client(['your_scope']))"

and let us know if it works?

[github-actions]

Hi @ArturSyl. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[ArturSyl]

Hey Xiang, I will send the code to the user, will update the setup tomorrow if he has time or next week and I will get back to you guys. Thank you nevertheless for swift replies on the topic. Cheers, Artur czw., 4 sty 2024 o 17:10 Xiang Yan ***@***.***> napisał(a):

…

@ArturSyl <https://github.com/ArturSyl> Could you help to try the code Ray provided: python -c "import msal; print(msal.ConfidentialClientApplication('your_client_id', client_credential='your_secret').acquire_token_for_client(['your_scope']))" and let us know if it works? — Reply to this email directly, view it on GitHub <#33607 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMEHNFWC3UFMVXX7FYJLZU3YM3H7DAVCNFSM6AAAAABAZNLBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGM3DCNRQGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Pozdrawiam, Artur

[github-actions]

Hi @ArturSyl. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[github-actions]

Hi @ArturSyl, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[ArturSyl]

Hey Guys, I think we can close it for now. We found a workaround, not great but working. We disabled ssl interception for login.microsoftonline for the devs working with azure sdk. czw., 18 sty 2024 o 22:34 github-actions[bot] ***@***.***> napisał(a):

…

Hi @ArturSyl <https://github.com/ArturSyl>, we're sending this friendly reminder because we haven't heard back from you in *7 days*. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within *14 days* of this comment the issue will be automatically closed. Thank you! — Reply to this email directly, view it on GitHub <#33607 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMEHNFXU4PV2TNC6ZT52N3TYPGIOHAVCNFSM6AAAAABAZNLBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZGIZTONJUGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Pozdrawiam, Artur