manged or federated - x-client-SKU header makes a difference

[lnhzd]

hello guys,

This is a question related to IWA flow - I am trying to understand the protocol a bit more: I understand as part of the IWA protocol it will make a userealm request and to check if user account is managed or federated in the response. I've come across some really weird behavior:

the two requests (for the same user) returns different result depends on x-client-SKU headers are included or not:

let testuser1@mydomain.co.uk as an example (I've replaced the real domain)

GET https://login.microsoftonline.com/common/userrealm/testuser1@mydomain.co.uk?api-version=1.0 HTTP/1.1 Host: login.microsoftonline.com Accept: application/json x-client-SKU: MSAL.Desktop x-client-Ver: 4.13.0.0 x-client-CPU: x64 x-client-OS: Microsoft Windows NT 6.2.9200.0

This returns a response and with account_type = federated.

GET https://login.microsoftonline.com/common/userrealm/testuser1@mydomain.co.uk?api-version=1.0 HTTP/1.1 Host: login.microsoftonline.com Accept: application/json

This request returns a response with account_type = Managed

the only difference is presence/unpresence of x-client-SKU headers, is this behavior documented somewhere please?

I fully understand this is not a MSAL issue, but just curious how these headers become significant. since @bgavrilMS pasted the same user discovery url in the other post which can be opened via browser (i.e. headers not presented) so I'm under the impression that you guys would expect behavior to be the same?

If this is the wrong place to ask could you please point me to the right place.

Thanks a lot.

[lnhzd]

Just to add, I asked this question as this may relate to an issue we saw a while ago - I cannot reproduce it anymore but can quickly describe it here: on the same machine, with the same account: 1) run a console app with IWA flow, using MSAL.net: exception thrown and the error is about I'm a manged user. 2) In SSMS: select authentication method as "Active Directory - Integrated" - logged in successfully (as far as I'm aware SSMS Active Directory Integrated authentication method will make a userealm request too, followed by the same saml bearer assertion flow )

I cannot re produce this issue anymore because after a while 1) just magically worked. But do wonder if it was the different value of x-client-SKU (msal vs ssms) makes a difference from my observation today.

Thanks.

[bgavrilMS]

You are right, the server has different behaviour based on x-client-SKU and x-client-Ver :(. This was done so as not to break backwards compatibility with non-MSAL libraries or apps calling the server on their own.

I believe the version needs to be at least 4 for this client-SKU for "seamless SSO" to work.

We do not document these feature flags, as these are implementation details. We do not expect developers to replicate IWA calls, as it is quite complex, so "seamless SSO" is only supported via MSAL libraries. Do you have a scenario where you cannot a MSAL library?

[lnhzd]

Thanks for your reply all makes sense, is it correct to think if the AAD is configured with ADFS then it's always federated with/without headers, x-client-SKU and x-client-Ver are only significant in the AAD where SSO is enabled because this is only supported since version 4?

"Do you have a scenario where you cannot a MSAL library?" like what I said in the previous reply: msal.net (4.9.0) and ssms made the same call to https://login.microsoftonline.com/common/userrealm/myaccount@mydomain.co.uk?api-version=1.0 HTTP/1.1 msal returns managed, while ssms returns federated. (must be due to different headers but I cannot tell why and I'm pretty sure it was 4.9.0 referenced.) After a few weeks time it resolves itself, i.e.: both msal and ssms start returning federated.

If you could shed light on this it's great, or if it's purely environment issue then I'm happy to close this question based on your last answer.

Thanks a lot.

[bgavrilMS]

Yes, Integrated Windows Auth is a pretty complex flow which the team copied from ADAL. But since most of us were new to the team, we did not have enough context into Seamless SSO and we did not test this scenario originally. After customers complained that seamless SSO was not working with MSAL, we realized that a feature flag needed to be set on the server (i.e. AAD knows to return "managed" if x-client-ver is >4 and x-client-sku is MSAL.NET). That's why you saw the issue resolve itself.

We are looking at using a more robust mechanism for feature flagging in the future, as this is often a problem, especially when new MSAL libraries are created (e.g. java, python)

[lnhzd]

Thanks a lot!