Ben Hatton
My feedback
-
4 votesBen Hatton
supported this idea
·
-
3 votesBen Hatton
shared this idea
·
-
81 votes
valid suggestion subject to upvote
Ben Hatton
supported this idea
·
-
3 votesBen Hatton
shared this idea
·
-
755 votes
Thank you for all the votes and feedback. We have started work on this and the capability will be supported soon. If you would like to get in touch with us to discuss your scenarios, please fill this form: https://aka.ms/ApplicationGatewayCohort
Ben Hatton
supported this idea
·
-
4 votesBen Hatton
supported this idea
·
-
8 votes
Can you give a bit more detail about why you would want to block 3rd party apps? Why are there 3rd party apps registered in your directory, that you want to block? I’m just wondering if there is a bigger issue here. Please add any feedback to the Azure feedback item.
Thanks
Ben Hatton
supported this idea
·
Ben Hatton
shared this idea
·
-
8 votes
Today you can set a conditional access policy on “Microsoft Azure Management”, which will apply to any client requesting access tokens to the Azure Management API. This includes the Azure portal (https://portal.azure.com) and Azure PowerShell (e.g. Login-AzureRmAccount).
It does not apply to Azure AD PowerShell. To apply a conditional access policy to Azure AD PowerShell (e.g. Connect-MsolService and Connect-AzureAD, for the MSOnline and AzureAD modules, repsectively), you must target the “All cloud apps”, which means all sign-ins for the targeted users must satisfy the MFA requirement. The main reason for this is that the AzureAD PowerShell module is a thin wrapper around the Azure AD Graph API, which is also used by the vast majority of Azure AD-integrated apps (e.g. Office 365, Azure, etc.) out there.
Thus, even if there was a way to set a policy on “Azure AD Graph API” (there isn’t), the…
Ben Hatton
supported this idea
·
Ben Hatton
commented
Hi Philippe,
I want to call out a related problem since you highlight use of policy against "Microsoft Azure Management". When I configure this, I also as a side effect cause access to powerapps to be forced to MFA (unknown what other o365 apps might be similarly affected). This is unacceptable burden on end users for what is supposed to be a policy to protect privileged administration access only. Would very much appreciate your viewpoint and suggestion on this issue. Surely Oauth token requests to graph api can't be considered "Azure Management" activity...?
Thanks and regards,
Ben -
6 votesBen Hatton
commented
Extending this, I can confirm that MFA via conditional access against "Microsoft Azure Management" also fails, as the setting will force MFA for (at least) powerapps.
Get your act together please - perfoming an OAuth login or obtaining a token for Graph API is not Microsoft Azure Management - It's end-user interaction with AAD.Ben Hatton
supported this idea
·
-
121 votes
Thank you for the feedback! This is in the backlog and we are looking into this. We don’t have an ETA yet, but we will share once we have one. Please keep voting if this feature matters to you.
Ben Hatton
commented
As a workaround, a module to invoke REST API has been contributed by Jos Lieben:
[apologies for previous now deleted post, didn't sufficiently read what I was suggesting]
Ben Hatton
supported this idea
·
-
6 votesBen Hatton
commented
I think you folk have misunderstood how DF works. The data factory instance region is not related to where data is processed. Data movement is between the data sources and the activity runtime only.
-
3 votesBen Hatton
supported this idea
·
-
1,080 votes
Still no news to share, just to add that we are investigating options on modifications for the App Service multi-tenant offering with enhanced capabilities.
Thanks,
OdedBen Hatton
supported this idea
·
-
270 votesBen Hatton
supported this idea
·
-
3 votesBen Hatton
supported this idea
·
-
4 votes
We have started worked on this features. For an initial release, we’re thinking on allowing admins to select the set of permissions users will be able to consent.
Ben Hatton
commented
The concepts you have here are perfect, thanks I'm in edu.au so we have a challenging userbase that doesn't respond well to global settings.
Ben Hatton
shared this idea
·
-
11 votesBen Hatton
supported this idea
·
-
48 votes
We’re continuing design work in this area.
Ben Hatton
supported this idea
·
-
11 votesBen Hatton
commented
Yes, exactly this. Being able to drill down to see the actual policy violation detail would be super.
Simpler approaches for an interim release: Allow each policy instance in an initiative to be individually named, or expose the parameter values against each instance in the compliance list,Ben Hatton
supported this idea
·
-
193 votes
We plan to start work on this in the next 6 months. Please note we don’t have timing on when it would be available for customers.
Ben Hatton
supported this idea
·
Hi,
The bigger issue is that there is no effective approach to control which 3rd party applications can be registered in the directory. We can either turn on user consent control, which allows all 3rd party apps to be registered and make requests for delegated permissions; or turn it off, which blocks all third party apps from being registered. On top of that, once consent control is turned off, there is no simple way to add delegated consent for selected users (can be done by rest api only).
The problem with 3rd party apps is that users (even highly technical users) have very poor visibility to distinguish a 'safe' app from a malicious app, and ongoing management of consent is not an easy activity for average non-technical users. Consequently, we want to be able to ensure that only pre-screened apps can be granted delegated consent.
Regards,
Ben