-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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. |
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. |
Can you provide more details how you did "Its included in the original Interactive Token request"? |
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. |
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. |
Hi @bcaulder8 Glad it is working for you now, thanks for letting us know, I'm closing the issue. |
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! |
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.
The text was updated successfully, but these errors were encountered: