Conditional Access blocks authentication due to unknown device platform

[chlowell]

Entra ID Conditional Access enables tenants to block authentication based on originating device platform as determined by User-Agent strings (feature documentation). Azure CLI evidently doesn't set User-Agent for its token requests--they have the default from requests e.g. python-requests/2.31.0. This doesn't identify any platform, so Conditional Access considers such requests to originate from unknown platforms. The Azure CLI therefore can't authenticate in a tenant having a policy blocking unknown platforms even when used from a known and allowed platform. (From Azure/azure-sdk-for-go/issues/22155)

[yonzhan]

Thank you for opening this issue, we will look into it.

[rayluo]

@chlowell , I am toying with the idea of MSAL (Python) using a user agent as msal-python/1.27.0 (linux) where the "linux" part will come from Python's sys.platform. I am even thinking of simply making it the built-in behavior (so that we do not have to introduce an optional user_agent parameter in the entire calling stack). But then it may also result in that value overrides whatever default value (if any) currently used by Azure Identity's http pipelines. I think that is reasonable, but want to double check with you that Azure Identity does not have a hard dependency on user-agent.

[chlowell]

What you describe sounds like reasonable default behavior to me but custom transports should still have full control over HTTP requests. It's okay for MSAL to set headers before handing a request off to the transport, which can then overwrite them, but not to alter a request afterward (if that's even possible). User-Agent in particular is important for Azure Identity because we use it for telemetry.

[rayluo]

What you describe sounds like reasonable default behavior to me but custom transports should still have full control over HTTP requests. It's okay for MSAL to set headers before handing a request off to the transport, which can then overwrite them, but not to alter a request afterward (if that's even possible). User-Agent in particular is important for Azure Identity because we use it for telemetry.

A quick update here.

• As an implementation detail, MSAL Python does not currently accept a customizable headers parameter. So, it will probably just remain that way. This also means MSAL Python's downstream layers (neither Azure CLI nor Azure Identity) will be able to set user-agent in the "normal way" today.
• MSAL Python will set a user-agent before making the http request, as discussed above.
• It is indeed the underlying http layer (i.e. "transports in the Azure Identity parlance) that have full control on whether to honor its headers input. In that sense, it is OK - although unexpected - that the transport layer will overwrite MSAL Python's hardcoded user-agent. But since MSAL Python does not really have a hard dependency on its user-agent behavior, that is OK. It will be implemented inside MSAL Python.