Microsoft login page freezes for existing users after upgrading from ADAL to MSAL

[dbanik]

Recently we upgraded our app from ADAL to MSAL. While the new app launches and works fine for new users, the Microsoft login page freezes for existing users (who were already enrolled into MAM policy using ADAL app). My understanding was that since the Keychain sharing cache is common (adalcache), this transition would be smoother. Is that understanding wrong for some reason?

One thing to note is with ADAL, we did not have the ADALClientId key added to the info plist and I think it was enrolling by creating a default ClientID. After upgrading to MSAL, we had to add the ADALClientId and ADALRedirectUri under the IntuneMAMSettings dictionary key of Info Plist file. Can this be the reason for the up login screen to freeze up?

How to fix the issue for users who were already enrolled?

[oldalton]

@ShruthiAchutha, can you take a look?

[ShruthiAchutha]

@dbanik have you completed the steps at https://docs.microsoft.com/en-us/mem/intune/developer/app-sdk-get-started#give-your-app-access-to-the-intune-app-protection-service-optional?

There is some additional guidance related to MSAL & MAM here https://docs.microsoft.com/en-us/mem/intune/developer/app-sdk-ios#special-considerations-when-using-msal.

If neither of those help, have you integrated the app with Intune diagnostic console as described at https://docs.microsoft.com/en-us/mem/intune/developer/app-sdk-ios#how-can-i-troubleshoot-my-app? If so, can you share the MAM log file from the app for an existing user?

[dbanik]

@ShruthiAchutha we had that setup already, screenshot below. Please note that the MAM worked perfectly fine with ADAL and it works fine for any new user who had never logged into the app before.

My theory is - users who had already enrolled with ADAL's default clientID is unable to login using MSAL login as now we have added the ADALClientId specifically in the IntuneMAMSettings .

[ShruthiAchutha]

@dbanik Can you share MAM log files to investigate this further? That will have the MSAL logs that should provide more insight.
[edit] If you don't already have diagnostic console integrated, I would suggest trying the registration below. This will enable your clientID to query for the resource that's used in the login page that's different from what's in https://docs.microsoft.com/en-us/mem/intune/developer/app-sdk-get-started#give-your-app-access-to-the-intune-app-protection-service-optional.

[msintuneappsdk]

Please email msintuneappsdk@microsoft.com with your app's Client ID. We'll get you approved for that resource.

[dbanik]

@ShruthiAchutha I am trying to access console logs by using Microsoft Edge but I don't see our Intune app listed in the option. I have sent a email to msintuneappsdk@microsoft.com with our app's Client ID.

[bblia]

@ShruthiAchutha @msintuneappsdk Hi, I work with @dbanik. our client ID was already registered back in March.

[dbanik]

@ShruthiAchutha We were able to get MAM diagnostics and the processor dump from the device with the app in hanged state. I am attaching both the files below. PFA.

From the diagnostics, it's clear that the loginAndEnrollAccount api finds an enrolled account but then goes into a hanged state. Looking at the processor dump, it's clear that there is some kind of deadlock or endless recursive calls between MSAL and IntuneMAMSwift. This renders the UI almost non-responsive.

MAM Diagnostics Logs:
MAMDiagnostics.pdf

Instruments Profile from Xcode
Relate Freezeup.trace.zip

Screenshot from the Instruments profile

[Kyle-Reis]

Hey @dbanik, I just tested moving from ADAL to MSAL and calling loginAndEnrollAccount without unenrolling the account enrolled with ADAL, and I was unable to reproduce this. Here are some questions I have:

• Which versions of ADAL, MSAL and Intune are you testing with?
• How are you calling loginAndEnrollAccount? Immediately on app launch? Are you specifying a UPN or just providing nil?

[dbanik]

@Kyle-Reis Thanks for the update.

• ADAL v4.0.3, MSAL v1.1.1, IntuneMAMSwift v12.2.0
• Yes we are calling from app launch. We are not specifying any UPN, we are using nil. Here is the code we call - IntuneMAMEnrollmentManager.instance().loginAndEnrollAccount(nil).

[Kyle-Reis]

@dbanik, could you let us know if you still see this issue when transitioning from current ADAL/Intune versions in your public release to Intune 12.4.0 + MSAL 1.1.2? Thanks.

[bblia]

@Kyle-Reis issue is still present. The only difference is we see these two dialogs, in the following order:

Clicking through the dialogs takes forever too. The screen is hung up/frozen while they are presented.

[Kyle-Reis]

Hey @bblia, I'm going top try and reproduce this again. Just to confirm, you are upgrading from:

Intune 12.2.0 + ADAL 4.0.3 with all default AAD setting configured in IntuneMAMSettings

To:
Intune 12.4.0 + MSAL 1.1.2 with custom ADALClientId and ADALRedirectUri configured in IntuneMAMSettings

Some additional questions:
Where exactly in the launch process are you calling loginAndEnrollAccount? didFinishLaunchingWithOptions?
Does your application support multiple windows on iOS 13?

[bblia]

Yes, those are the proper versions.

loginAndEnrollAccount is being called in didFinishLaunchingWithOptions, yes.

Does your application support multiple windows on iOS 13? yes.

[bblia]

I've been wrestling with this all day. Some additional things to note:

commenting out loginAndEnrollAccount yields slightly different results but still presents a serious underlying problem. It drops us straight into our app but the page is still freezing/terrible in the same way we were seeing for the microsoft authentication screens in the screenshots. The CPU/memory usage just climbs and climbs in both cases until we kill the app.

The only thing that seems to help the hangup is completely removing the IntuneMAMSwift frameworks, but then obviously IntuneMAM doesn't work :)

My guess is that the frameworks are potentially playing very poorly with MSAL? Not sure. Please let me know what else we can try or what other info we can provide.

[bblia]

More info:

Tried another hack. I used the default client ID (found via old sign in attempts with the ADAL version in our azure portal logs, for application name Intune Applications) in IntuneMAMSettings for ADALClientId and everything works just fine. Switching back to our custom client id, everything hangs up again.

[ShruthiAchutha]

Any chance we could get access to your ipa without the MAM SDK in it? We could try wrapping it and see if we can repro. That will allow us to debug the issue.

[bblia]

We would need to go through an NDA to be able to do that.

Please note, this issue isn't occurring for all users. We have two people who are able to reproduce it consistently (myself, and a user who is helping us test). The other engineers on our team do not see the problem. That's why we think it has to do with a bad cache registration, or something of that sort.

[ShruthiAchutha]

In that case can we get complete MAM diagnostic file as that would have the details about MAM cache? MAMDiagnostics.pdf that you shared doesn't have much usable data, it doesn't even look like its generated by MAM. The best option is to implement the diagnostic API to get the log file generated by MAM SDK. Is that an option?

[bblia]

@ShruthiAchutha please let me know if this helps and if i can provide any additional logs. I captured these after a fresh install of the MSAL build we originally found the issue on. This build is using theolder version of MSAL and Intune -- MSAL v1.1.1, IntuneMAMSwift v12.2.0.

IntuneMAMDiagnosticFiles 3.txt

[ShruthiAchutha]

These are just logs from the Edge app, not yours. How are you capturing logs? Edge won't be able to capture MAM logs from non-Microsoft apps.

[bblia]

@ShruthiAchutha Can you point me to some documentation so I can get you what you're looking for? I tried searching for implementing diagnostic apis but all I found were the instructions around using the edge app to capture mam logs.

[bblia]

I think I figured it out -- I added IntuneMAMDiagnostConsole.display() to our app. Neat! This build is running MSAL 1.1.2.

Here is what I got it to spit out (it's super large):
IntuneMAMDiagnosticFiles 6.txt

[Kyle-Reis]

Hey @bblia, thanks for the logs! I see this error come up a few times: "IntuneMAM: ActionExtensionHooks: OpenInActionExtension set on non-Action Extension". It looks like you may have "OpenInActionExtension" specified under the IntuneMAMSettings of your main app's Info.plist. Could you remove that? Could you also tell me if AutoEnrollOnLaunch is enabled there? Thanks!

[bblia]

hey @Kyle-Reis we actually don't have anything regarding OpenInActionExtension in IntuneMAMSettings. We have:

as well as ADALClientId and ADALRedirectUri.

[Kyle-Reis]

Hey @bblia, would it be possible to get an instruments profile of the issue with MSAL 1.1.2 and Intune 12.4.0? Thanks

[bblia]

Intune12.4.0MSAL1.1.2.trace.zip

@Kyle-Reis Here you go.

[jasoncoolmax]

@Kyle-Reis could you help @bblia to take a look at the trace? :)

[Kyle-Reis]

Hi @bblia, just to get some more clarity here, is the issue that the UI becomes very slow, but does eventually show login prompt and user is able to login? Or is the user completely blocked? Reason for my asking is that I noticed in the screenshots you shared the login UI is there. I was under the impression from @dbanik's original comment that the login UI just never displayed. The trace shows that the calls between MSAL and Intune appear to be logging related. Intune registers to receive logging messages from ADAL/MSAL and writes those log statements to the Intune MAM SDK logs. Processing/handling the log statements seems to be where the bulk of the time in the trace you shared is being spent. We've recently made some performance fixes in this area specifically so I think our next release should help with this.

[bblia]

@Kyle-Reis The issue is that the app completely hangs up and becomes unusable, and eventually crashes (no stack trace) if you don't force close out. Sometimes it crashes before the login UI manages to load, sometimes it does make it there. In all cases it is not usable. You can enter in credentials maybe 1 letter per 30 seconds but I've actually never successfully gotten in, because things crash by the time I can even type in my full email. Additionally, we have brokered authentication working and I should able to skip that screen completely (which works fine for ADAL) but for whatever reason in this build it loads the login UI/freezes.

Another thing to note is that this doesn't happen for everyone. For example, it doesn't happen to @dbanik but it does happen to me as well as a tester at one of our customer organizations (we have someone there who helps validate any major change builds). We have tried to consider any possibilities in differences between our devices or environments but nothing to note.

Regarding the log statements, is there a way for me to disable that so I can validate? When will the next release be available?

[Kyle-Reis]

Hi @bblia, try setting MSALGlobalConfig.loggerConfig.logLevel to MSALLogLevelNothing before calling loginAndEnrollAccount.

[bblia]

@Kyle-Reis sadly did not seem to make a difference

[Kyle-Reis]

Hey @bblia, could you share a trace with MSAL logging disabled? Also, are you building the debug or release scheme of MSAL?

[bblia]

ReleaseMsal1.1.2Intune12.0.4.trace.zip
DebugMsal1.1.2Intune12.0.4.trace.zip

Here's one of each, same behavior in both.

[Kyle-Reis]

Hi @bblia, I believe I've found the root cause of this issue and I'm working on a fix now. Basically, Intune both logs an error and creates a telemetry event (although the event does not actually get sent for 3rd party apps) when MSAL does not return an MSALAccount object for the user. In the process of populating the telemetry object's fields, we try to pull the MSALAccount object again and it leads to the same error being logged and another event being created. I'm guessing that this happens because the MSALPublicClientApplication instance that we call accountForUsername:error: on is initiated using the new client ID, and so MSAL is unable to pull an MSALAccount from the cache that is associated with the new client ID. It's not clear to me why all users don't experience this issue. Perhaps it's related to device hardware/system resources. On newer/faster devices, users are probably able to complete enrollment before CPU/memory are used up, at which point MSAL returns the MSALAccount object, ending the loop.

[bblia]

@Kyle-Reis based on your explanation, that sounds like a reasonable cause. Fingers crossed, and I'm happy to help you validate it whenever its ready.

Regarding why its not happening to everyone, I wish I knew. @dbanik and I have the exact same phone (iphone 11 pro with 256g capacity). only difference is i'm on verizon and he's on t-mobile, but i've tried w/ data off as well. so 🤷 really no idea

[Kyle-Reis]

@bblia, is it possible that @dbanik might already have had a token in the cache when they tested?

[dbanik]

@Kyle-Reis I had tried deleting/reinstalling the app. I was prompted to Microsoft Login page and was able to sign in fine without any issues or slowness.

[Kyle-Reis]

Hi @dbanik and @bblia, could you try out the latest release of the Intune SDK (version 12.6.1)? I think that should address this issue.

[bblia]

hi @Kyle-Reis, I believe everything is now working as expected. I no longer hang and am able to get through and get an app policy.

We do have brokered auth configured, and the first run after bumping to the new versions prompted me to enter in my microsoft credentials even though I'm signed in to the Authenticator app already. After signing in, I was unable to see this happen again and brokered auth seems to work correctly after subsequent uninstalls/reinstalls/etc.

Would that first time login prompt expected somehow, maybe related to the account enrollment situation I was in? I just want to make sure there aren't any related regressions.

[Kyle-Reis]

@bblia, I think you may have been prompted for credentials because the account you were signed in with is targeted with Intune authentication policy. When that is the case, the user must enter their credentials after the app has been inactive for the timeout interval specified by the admin.

[Kyle-Reis]

Great to hear the hang is now resolved!

[oldalton]

Resolving as fixed. Please reopen if needed.