Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App Protection Policy Required Conditional Access remediation and Graph API scope (Calendars.Read) #431

Closed
bcaulder8 opened this issue May 6, 2024 Discussed in #430 · 7 comments
Assignees

Comments

@bcaulder8
Copy link

bcaulder8 commented May 6, 2024

IntuneMAMDiagnosticFilesplatform.log

Discussed in #430

Originally posted by bcaulder8 May 4, 2024
Hello,

We have an Azure AD application that we created to allow our mobile application to enroll and be protected by Intune. Part of the functionality we would also like to be able to use is the Calendars.Read so we added that to our Azure AD application.

Now we also are supporting the "Require App Protection Policy" Conditional Access Remediation flow and adding the "protapp" capability which all works fine. We can enroll in Intune and receive the compliance. But we are struggling to figure out once that is done how do we get an Access Token that has the Calendars.Read permission - we can't do it Interactively because that fires off MS Authenticator which is not an Intune App Protected application....so we seem to loop into the remediation flow. Unless there's something we are missing with how we call this - MSAL makes the decision to use MS Authenticator but is not recognizing that we are Enrolled or maybe I have something configured wrong where it doesn't know it is from our bundle ID.

I tried silently to get the token after remediation for the User.Read and Calendars.Read scopes...but we get a 50002 which I believe means a token with the Calendars.Read scope is not cached anywhere. I try with just the User.Read scope and it passes successfully.

Looking for guidance - thanks!

Also, I made some adjustments to the WAGR app to reproduce the issue and get some logs if that helps to diagnose.

@wangxiaoms wangxiaoms self-assigned this May 8, 2024
@wangxiaoms
Copy link

Hi, in the login remediation flow, did you add the Calendars.Read scope in authentication request? The scope should be requested in the login flow to get user consent.

@bcaulder8
Copy link
Author

bcaulder8 commented May 8, 2024

Hi - most likely not. Not sure if I am seeing a way to include it in the remediateComplianceForIdentity flow. Could you point me the right direction there?

Its included in the original Interactive Token request and the Silent request after the remediation of course but not positive how to force that in the remediation flow.

@wangxiaoms
Copy link

Can you provide more details how you did "Its included in the original Interactive Token request"?

@bcaulder8
Copy link
Author

bcaulder8 commented May 9, 2024

Hi - Sure! I am using the WAGR example application (https://github.com/msintuneappsdk/wagr) which requests both Calendars.Read and User.Read scopes. But note the original application example does not seem to use or attempt to read the Calendar via Graph later. So I modified the Logout button logic to grab a token Silently after the remediation to verify the scope was there. If not, then I try interactively again (just copied the other code for this part). That again fails with the need remediation error. I attached my changes as well in the zip file - I also added my sign-in error logs if that helps.

It makes me think either there's something wrong with my user's configuration or something else.

Screenshot 2024-05-09 at 8 20 44 AM

SettingsViewController.m.zip

SignInErrors_WAGR.xlsx.zip

@bcaulder8
Copy link
Author

I think we may have figured it out. That WAGR application uses the older remediate method vs. the new remediateComplianceForAccountId. Once I updated the libraries I was able to get the token.

@wangxiaoms
Copy link

Hi @bcaulder8 Glad it is working for you now, thanks for letting us know, I'm closing the issue.

@bcaulder8
Copy link
Author

One final comment. It was not the call using the Account ID that fixed it. It was updating to the latest Intune and MSAL SDKs. It works for the call using UPN as well. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants