Issues with Intune SSO post-wrapping with tool

[paulpopiel]

We have an iOS application that has been setup with MSAL. Our MSAL login + Azure AD configuration works standalone with no problems.

However once we apply the iOS Intune wrapping tool as per: https://docs.microsoft.com/en-us/mem/intune/developer/app-wrapper-prepare-ios

We run into the following issues.

1) If we apply the wrapping using the standard command using the default ADAL settings (i.e. omitting the -aa, -ac, -ar paramaters), then we face the following error:

As we understanding it, the app id referenced in this error (i.e. 6c7e8096-f593-4d72-807f-a5f86dcc9c77) is the built-in default Intune MAM app registration. However we see no way of actually gaining access or configuring this in anyway to set redirect/reply urls.

2) If we apply the following parameters: -aa "https://login.microsoftonline.com/[tenant-id]" -ac "[client-id]" -ar “msauth.[bundle-id]://auth”

(as per our existing MSAL configuration, which works standalone)

we then get the following error:

Any guidance as to what we may be missing or doing wrong would be greatly appreciated.

[Kyle-Reis]

Hi @paulpopiel, it sounds like you have source code access for this app? is there a technical reason for the decision to wrap the app instead of integrating the Intune SDK?

[paulpopiel]

Hi @Kyle-Reis We are using Flutter and there is no Intune SDK pub package for it as far as we are aware.

[Kyle-Reis]

Hi @paulpopiel, could you try removing the quotes around the values specified for custom AAD settings in command line? Depending on how the quotes were entered, they may be getting treated as part of the setting value and leading to issues

[paulpopiel]

I have lodged a service request with our deployment team to try this and will report back later. Fingers crossed its that simple.

[paulpopiel]

Hi @Kyle-Reis We tried a few different things and ultimately the following setup got past the MSALErrorDomain error:

-aa login.microsoftonline.com/[tenant-id]
-ac [client-id]
-ar msauth.[bundle-id]://auth

(i.e. dropping the quotes and also the https:// from the authority url)

However we are now presented with the following error:

We understand this is a standard Intune error:

Our Intune team is looking into the remediation, however in the meantime any pointers or assistance to guide us in the right direction would also be much appreciated. NOTE: this is the UAT version of the app. Is it recommended to turn off or bypass the Intune auth (or the app protection policies) for UAT versions?

[Kyle-Reis]

Hi @paulpopiel, this error is shown when the user is not targeted with app protection policies for the app. Does the UAT version of the app have a different bundle ID from the production version? Apps are targeted for policy based on bundle ID, so your team may need add the UAT bundle ID to the list of targeted apps in addition to the production version.

[paulpopiel]

Hi @Kyle-Reis , we have confirmed that both the user and the policy exist. However one thing I did notice is that the app is created through the following process: https://docs.microsoft.com/en-us/mem/intune/apps/lob-apps-ios Noting that the bundle id is never manually specified (although it does show up correctly as per the uploaded IPA subsequently in the apps list in Intune). When editing the policy, when adding a custom app (LOB app) - searching by the bundle id doesnt show any results, but the app does appear when searching by the name assigned during the creation above.

Which makes me wonder, is the policy potentially tied to the IPA file that is uploaded, and not just to the associated bundle id? Note that we get the error during side-load testing (i.e. before the wrapped IPA is actually updated/re-uploaded in Intune).

Note: to be clear the app and policy were created against a previous version of the app/IPA which was wrapped without the use of the -aa -ac -ar parameters.

[Kyle-Reis]

Hey @paulpopiel, when IPAs are uploaded for distribution via Company Portal, the app name will appear in app protection policy targeting UI as you've mentioned. Under the hood though, all targeting is based on bundle ID. Endpoint Manager is able to get the bundle ID for the app from the Info.plist inside of the uploaded .ipa file.

Does the UAT version of this app use the same bundle ID as the production version? If not, the bundle ID may need to be added to the list of targeted apps in the policy settings.

[paulpopiel]

Hi @Kyle-Reis, yes the UAT version has a different bundle id, however both it and the production version have both been added as separate apps in Intune. Likewise each has its own policy created, each targeting the respective version (i.e. a production policy as well as a uat policy).

[Kyle-Reis]

Hi @paulpopiel, is the UAT policy also targeted to a user group which contains the account you are using to test the app?

[paulpopiel]

Hi @Kyle-Reis Yes we have also checked this and confirmed that this is setup correctly. P.s. thank you for your time and patience in trying to help us identify the issue.

[Kyle-Reis]

@paulpopiel, No problem! :) could you check if the following settings on the app protection policy are configured differently? If so could you share what they are set to?

[paulpopiel]

@Kyle-Reis yep looks to be the same:

[paulpopiel]

@Kyle-Reis - side question related to the original error we are facing in production, i.e. the following error where the IPA was wrapped with default parameters (without the use of -aa, -ac, -ar)

We have more details from the AAD monitoring sign in logs related to this error:

any ideas as to what could be causing this? Some extra context: everything was working fine for a number of months (8-9 months) and then recently this error started to get reported, with the number of users ramping up (i.e. not all at same time) reporting the interactive prompt with the error above. Although now we suspect that this error was always happening, just that it was also happening silently and subsequently not blocking the app from proceeding to its own MSAL auth flow.

[paulpopiel]

Just found the following: https://docs.microsoft.com/en-us/troubleshoot/mem/intune/error-query-intune-data-warehouse Could this be related/similar in any way? (Not sure if there is any link between Intune Data Warehouse and the built-in "Intune Applications" app referenced above)

[paulpopiel]

@Kyle-Reis Apologies for the spam, but also found this: https://github.com/AzureAD/microsoft-authentication-library-for-objc/issues/905

Which basically seems to be the same error we faced.

Interestingly I open the Info.plist file from the wrapped IPA and it seems all these values are being set correctly...

[paulpopiel]

@Kyle-Reis One last thing: https://docs.microsoft.com/en-gb/mem/intune/developer/app-sdk-get-started#give-your-app-access-to-the-intune-app-protection-service-optional

I'm not sure if we have done the above (would need to check with our AAD team), but could this potentially cause the "App Not Set Up: This app has not been set up for you to use. Contact your IT administrator for help" error if it hasn't been set up?

[Kyle-Reis]

Hi @paulpopiel, the latest version of the app wrapper does not inject ADAL when the app already links to MSAL. With MSAL, using custom client ID and redirect URI for Intune enrollment is required due to strict redirect URI format enforced by MSAL which is based on individual app's bundle ID.

If the above steps have not been followed to give the app access to the Intune MAM service, that is likely the root cause of the "Account Not Setup" error.

[paulpopiel]

Hi @Kyle-Reis

the latest version of the app wrapper does not inject ADAL when the app already links to MSAL. With MSAL, using custom client ID and redirect URI for Intune enrollment is required due to strict redirect URI format enforced by MSAL which is based on individual app's bundle ID.

Thank you very much for that clarification. That confirm the use of the -aa, -ac, -ar parameters is required and we will continue down that path.

If the above steps have not been followed to give the app access to the Intune MAM service, that is likely the root cause of the "Account Not Setup" error.

Fingers crossed. I will raise a Service Request with our AAD team to check and add (if missing) the above access and report back.

[paulpopiel]

We have confirmed the Intune MAM service permissions are NOT present in the AAD app registration.

Have raised a service request to have this addressed and will report whether this solves the 'Account not setup' error post-wrapping.

Thanks again.

[paulpopiel]

@Kyle-Reis - So we applied the Intune MAM API permission to AAD. There was no impact initially, although it seems that it took a few hours (24+ roughly) for those permissions to propagate through. Interestingly though, it doesnt seem to be working for all our users.

Specifically the Intune policy for the UAT version of the app has two groups assigned:

• Our application team UAT group
• The India based service teams own internal testing group

All our users in the application team have managed to install the app and the policies are detected and login works. However users from our service team are still getting the 'Account Not Setup' error when checking for policy.

Initially I thought it may have something to do with the Intune groups, however we had them remove me from the application UAT group and added to theirs, and I still managed to login fine without the error.

We are a bit baffled now as to what may be causing their users to have issues and not ours. The only real differentiator that we have identified is that we are all Australia based, and they are in India... although I dont see how that can have any effect.

Any ideas?

[Kyle-Reis]

Hi @paulpopiel, it sounds like this may be a matter of the added API permission not fully propagating to all servers. Is the team in India still seeing the issue?

[paulpopiel]

Hi @Kyle-Reis , they are still facing the same error this morning. Is it common for AAD API permissions to take this long (days) to propagate? and for there to be such a differentiation between regions?

[Kyle-Reis]

@paulpopiel, it shouldn't take that long. Do the accounts that the India team is testing with have an Intune license assigned to them? If not, MAM enrollment would fail, which would also produce this error.

[paulpopiel]

@Kyle-Reis I will check on this tomorrow with the Intune team. However, these users have had no issues with the pre-existing ADAL based apps that have been deployed. Unless there is some key difference in relation to this with ADAL vs MSAL? (excuse my ignorance on this subject)

[paulpopiel]

@Kyle-Reis All users by default have the Office 365 E3 license assigned to them with Intune enabled, so thats not the cause of the India team members still getting the 'Account Not Set Up' error.

[paulpopiel]

@Kyle-Reis - we decided to roll the dice and went ahead with a production deployment with the current setup, hoping it was an isolated case with the 'Account Not Set Up' issue just with our India team members.

We have had reports of users who previously had the original 'reply URL' error having solved that problem, which is great. But we are unfortunately starting to get a small handful of reports from users now experiencing the new 'Account Not Set Up' error.

What other scenarios could potentially cause this 'Account Not Set Up' error? Is there any potential interaction with SSO with previous enrollments/tokens from other Apps setup with ADAL that could somehow trigger this? we are grasping at straws at this stage.

[paulpopiel]

@Kyle-Reis - another (separate although potentially related) issue: On a fresh device (out of the box setup, with only Company Portal and Authenticator installed. i.e no existing application enrolments or tokens.

When we run the app we get:

Has this got anything to do with:

AutoEnrollOnLaunch	Boolean	Specifies whether the app should attempt to automatically enroll on launch if an existing managed identity is detected and it has not yet done so. Defaults to NO.Notes: If no managed identity is found or no valid token for the identity is available in the MSAL cache, the enrollment attempt will silently fail without prompting for credentials, unless the app has also set MAMPolicyRequired to YES.

specifically: " If no managed identity is found or no valid token for the identity is available in the MSAL cache, the enrollment attempt will silently fail"

[paulpopiel]

@Kyle-Reis - apologies, spamming again.

Following on from the fresh device scenario:

Interestingly when we then install and login to a different company app, and then come back to ours - we no longer get the above 'unexpected failure', but now get the 'Account Not Set Up' error.

So not sure how the majority of our user base is actually not getting this error in production. Is there some sort of interaction with previous enrolments/tokens, either coming from previous version or from other apps....

Hope this leads to potentially shedding some further light and maybe some new ideas as to what the issue may be?

[Kyle-Reis]

Hi @paulpopiel, could you follow these instructions to collect Intune logs for the app and send them to me along with a copy of the wrapped app's Info.plist at KyleReis@microsoft.com? It sounds like there may be a problem with the AAD settings configured which is leading to the "Unexpected Failure". However, when another one of your apps app has already acquired a token, we're able to access the MAM service silently without prompting the user for credentials, but there is some other problem which is leading to the "Account Not Setup" error.

[paulpopiel]

Hi @Kyle-Reis - email sent with the requested files. Thank you very much for the assistance.

[Kyle-Reis]

Closing out this issue as root cause was determined (missing "https://" in the authority URI).

[OmarHassan25]

Closing out this issue as root cause was determined (missing "https://" in the authority URI).

@Kyle-Reis i have the same issue with ny wrapped application, domainerrorcode - 50000, my authority uri contains the https part,.. . Could you please help what may cause the issue?

[OmarHassan25]

We have an iOS application that has been setup with MSAL. Our MSAL login + Azure AD configuration works standalone with no problems.

However once we apply the iOS Intune wrapping tool as per: https://docs.microsoft.com/en-us/mem/intune/developer/app-wrapper-prepare-ios

We run into the following issues.

1. If we apply the wrapping using the standard command using the default ADAL settings (i.e. omitting the -aa, -ac, -ar paramaters), then we face the following error:

As we understanding it, the app id referenced in this error (i.e. 6c7e8096-f593-4d72-807f-a5f86dcc9c77) is the built-in default Intune MAM app registration. However we see no way of actually gaining access or configuring this in anyway to set redirect/reply urls.

2. If we apply the following parameters: -aa "https://login.microsoftonline.com/[tenant-id]" -ac "[client-id]" -ar “msauth.[bundle-id]://auth”

(as per our existing MSAL configuration, which works standalone)

we then get the following error:

Any guidance as to what we may be missing or doing wrong would be greatly appreciated.

@paulpopiel i have the msaldomainerror 50000, could you please advise how you fixed it?