search

AzureAD / microsoft-authentication-library-for-python

Microsoft Authentication Library (MSAL) for Python makes it easy to authenticate to Microsoft Entra ID. General docs are available here https://learn.microsoft.com/entra/msal/python/ Stable APIs are documented here https://msal-python.readthedocs.io. Questions can be asked on www.stackoverflow.com with tag "msal" + "python".
https://stackoverflow.com/questions/tagged/azure-ad-msal+python
Other
757 stars 192 forks source link

First try to acquire access token in synapse always get connection timeout #533

Open qinl-li opened 1 year ago

qinl-li commented 1 year ago

To give you a little background, we have pipelines in the azure synapse that pulls data from kusto and we are flagged in S360 for ESTSR.

We have followed the guidelines to apply changes to adopt ESTSR. Code is here:

But it doesn't get us cleared.

We noticed the following, it always failed on the first attempt to get access token and you can see the error below:

2023-01-30 09:03:40,041 - ServiceTraceLog_Collector - [get_sp_access_token() : 13] Attempting to obtain an access token... Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7fee02ebe828>, 'Connection to 169.254.169.254 timed out. (connect timeout=3)')': /metadata/instance/compute/location?format=text&api-version=2021-01-01 2023-01-30 09:03:46,596 - ServiceTraceLog_Collector - [get_sp_access_token() : 25] Access token successfully acquired

We are wondering does it prevent the change to take effect? Any advice? thanks in advance!

rayluo commented 1 year ago

So, your app somehow only collects its own log? Normally, Python's default log behavior is to also show underlying module's log, which will then reveal these MSAL logs. Long story short, when using region auto-detection, MSAL currently tries to find an environment variable REGION_NAME, and then attempts a detection request to that 169.254.169.254 endpoint which is only available on Azure VMs. If neither detection was successful, MSAL falls back to use non-regional endpoint. That is probably why your code change "doesn't get you cleared".

I do not know how or whether Azure Synapse supports region auto-detection (CC: @bgavrilMS, do you know?). Meanwhile, @qinl-li if you know the region your app is running in, you can choose to explicitly provide that region name by azure_region="my_region_name".

P.S.: @qinl-li , it is cool to see a Synapse Workspace can embed Python scripts inside a json configuration file. Does that mean the script will be run in each click, therefore short-lived? In that case, indeed you will need to figure out a way to persist token cache.

qinl-li commented 1 year ago

@rayluo Thanks for your prompt response! That is what we suspected. I just tried with azure_region="my_region_name", and it gave me the same error. I also filed an ICM for the synapse team and I'll update them with the information and see how they respond.

for your last question, in the workspace, you would see multiple cells and each cell contains a block of code, and you can run each cell. And yes, we need to figure out a way to persist token cache

rayluo commented 1 year ago

I just tried with azure_region="my_region_name", and it gave me the same error.

After you specifying a region, MSAL is getting token from that region. You still see that unpleasant log message only because, even after being told to use a specific region, MSALs will still attempt to do auto-detection, just to see whether your specified value matches the detection result. Unfortunately, that validation behavior would cause that same error message (and same 6 seconds latency). @bgavrilMS , what is your thought on this one?