Reader question: How do I setup iOS devices after disabling app permissions consent for my users?

I continue to get great feedback and questions from our readership lately. Keep it up! I love to field these questions and use them to improve my literature. This person (who is also an MVP) also wished to remain anonymous, and had a couple of good questions regarding my Azure AD Best Practices Checklist. We’ll just go with the first question here today.

ITProMentor.com Contact
Alex.. this is [REDACTED]. First… THANK YOU for your super awesome Azure checklist. It’s just downright amazing and we implemented every last piece of it. That being said we have TWO sticky problems remaining… which maybe you want to examine and make a blog entry out of. Please do not quote me or give me credit.. just do it anonymously if you choose to investigate. :-) Problem 1: We closed off Applications acceptance; but still want iOS to be able to get email. By application acceptance, I mean when a user agrees to have some third party service connect to their account like this:

Our “dumb” workaround was: Re-open application acceptance, make sure all the people using iOS devices got email as expected (with oAuth + 2fa connection) then re-close the door to applications acceptance. This works for now, but if we hire 10 new people and they want to use the iOS app, it seems I have to re-open the door for them. Maybe your blog can show how to keep application acceptance closed but give permission to KNOWN people to use iOS.

In case you don’t know what we’re talking about yet: It is possible to grant third-party applications “permissions” to interact with data that is in Office 365. There are many perfectly acceptable use cases for this. One of those is: whenever you are setting up a new user with an iPhone for the first time, Apple’s iCloud service has to ask for permissions to interact with that user’s data in Office 365. That’s fine.

The screenshot above was an example of adding a different third party app (Adobe Sign). Also fine. You will notice that this prompt applies specifically to one user account–the account that is requesting use of the app. That is because this user is a “standard” user, and not a global admin, so we have kicked off what is known as the “user-initiated” workflow in OAuth. This grants permissions only to specific users.

However, the best practices checklist says to turn this user-initiated workflow off. The reason is, malware can also be disguised as legitimate apps and trick users into granting the bad guys permissions they shouldn’t have. Ruh-roh, Raggy. Go to Azure AD > Enterprise applications > User settings. Disable the option Users can consent to apps…

Once you disable the ability for users to request a “user-initiated” approval workflow, then your standard user accounts can no longer add applications, or indeed, even setup iPhones if they need to. Whatever are we to do?!

Well, it should tell you what to do after you are denied–you need an admin account. Luckily there is an “admin-initiated” workflow as well. This workflow is a bit different however, because it will ask the admin to grant app permissions for the entire organization.

So that means that an admin account can complete this request once and it covers everyone else, forever after. Subsequent people who attempt to add this app should not need to approve its permissions requests, because an admin has already done so on their behalf.

So to answer your question, reader: when you turn this setting off on a new tenant, you can simply use an iOS device (one time) to quickly add an administrator account, and set the approval for the entire organization. You can easily remove the account after you are done with this approval process. Subsequent users will not be bothered.

You can also use the Permissions blade on the application within Azure AD > Enterprise applications, where you will find an easy button called Grant admin consent for <Company name>.

It’s also a good place to review who has already granted consent (see the User consent tab) as well as to review permissions that the app has requested.

But what if I don’t want to grant EVERYONE permissions for this application?

The reader didn’t actually ask this, but in case anyone was wondering… There is a way to deal with this type of request also. Granted, most of the time, like with iOS devices, it’s easy enough to just blanket issue a statement, “Go ahead and approve this app–it’s okay org-wide.” But if you have an app that is NOT approved org-wide for some reason, then you can do the following.

After you have initiated an organization-wide approval via an admin account, find the application within Azure AD > Enterprise applications.

Next go to the Properties blade. Find the option called User assignment required? The default is No. You want to move this to Yes. At the top, click Save.

The reason you do this is simple: so that most users do not have access to use the app by default. And therefore the outside app also cannot access the data behind any old user account, either–only those to whom the app is assigned. Therefore, the users who need this application to function would need to be explicitly assigned under the Users and groups blade.

Note that group-based assignment is a feature of Azure AD Premium (otherwise you need to assign individual users).

I hope this clears up that first question. Make no mistake, when you are tightening down the hatches, you can end up affecting user experience, so it is also good to know how to mitigate those issues, when they come up. Thanks for helping me to improve my literature, anonymous MVP person.

I’ll get to your other question(s) soon. Stay tuned.