Hi guys.
I'm using WAM in MSAL.NET, and I'm hoping to perform a silent id token acquisition via IWA specifically - based off windows credentials, before a user has manually entered their credentials into a wam broker prompt.
The machine is domain-joined, it's talking to the domain controller, and it has a valid kerberos TGT. The domain controller has AADC set up in password hash sync mode, with SSO enabled. The user was first created in AD and synced like that to AAD. The oauth app has been granted full admin consent within the login user's tenant, and it's specifically set to "work or school accounts in any tenant". The WAM public client app has been told to use the Operating system account. The user has no problem logging into other online microsoft services using their credentials.
Performing an AcquireTokenSilent
operation with verbose logging results in this error: Error Code 3400073293, 'Account type is unknown.'. I am seriously struggling to find any further details on this error by searching.
https://learn.microsoft.com/en-gb/entra/msal/dotnet/acquiring-tokens/desktop-mobile/integrated-windows-authentication has this disclaimer:
Federated users only, i.e. those created in an Active Directory and backed by Microsoft Entra ID. Users created directly in Microsoft Entra ID, without AD backing - managed users - cannot use this auth flow.
-
My user was definitely created in AD and sync'd up, so I was expecting this to be fine. However, when I use the discovery url, https://login.microsoftonline.com/common/userrealm/<user identifier>?api-version=2.0 , the result says managed.
So, two things, I suppose -
- a) can anyone shine any more specific light on this error? Without further context, it doesn't mean much to me.
- b) Why is my user 'managed' when it seems to meet the criteria specified on that docs page? Is IWA simply impossible without using ADFS, or are there other methods to make this work? Any details that would help me understand this distinction would be appreciated.
I am aware that WAM's broker token cache is effectively able to supply Single Sign On once a user has actually manually entered credentials into the interactive broker prompt, but for a particular usecase this isn't adequate - I want to be sure of the identity of the logged in windows account specifically.
Thanks for any assistance you can provide!