Ben Hatton
My feedback
-
77 votesBen Hatton
supported this idea
·
-
14 votesBen Hatton
supported this idea
·
-
13 votesBen Hatton
supported this idea
·
-
3,266 votes
Quick update,
We have been considering all of the risks and investigating the steps required to ensure we implement this feature with high positive impact and low to no negative impact.
After this investigation we have decided we will enable Pay-As-You-Go customers the option to configure a spending limit on a Pay-As-You-Go subscription, with appropriate safeguards and measures to prevent both service abuse and production service failure.
We have not yet finished determining the details of what this feature will look like, nor do we have a timeline for release, but we have heard your voices and have added this feature to our backlog.
Thanks for your continued feedback,
-Adam (Azure Billing Team)
Ben Hatton
supported this idea
·
-
42 votesstarted · 6 comments · Azure Active Directory » Privileged Identity Management · Flag idea as inappropriate… · Admin →
An error occurred while saving the comment Ben Hatton
supported this idea
·
-
130 votesstarted · 8 comments · Azure Active Directory » Privileged Identity Management · Flag idea as inappropriate… · Admin →Ben Hatton
supported this idea
·
An error occurred while saving the comment Ben Hatton
commented
There are some significant omissions from the ADMSPrivilegedRole commandlets that affect deprovisioning, I hope this can be fed into the development:
a) There is no remove- commandlet
b) Limiting resource query to 200 is a potential show stopper - PIM is most useful assigned at resource group level, not subscription level
c) There is no way to query all eligible assignments for a specific user without a grand iteration through everythingThe best workflow currently possible is to run the export for each subscription through the portal and then manually deprovision each assignment in portal.
Maybe the microsoft.graph module is a better way to go... Is AzureAD module going to continue to be developed?
-
577 votes
Update: We are currently working on enabling operational backup for blobs and the ETA for the limited preview is November ’20.
Do check out this short demo to catch a glimpse of what operational backup of blobs will offer: https://aka.ms/AB-BlobBackup
For more details, please reach out to us at AskAzureBackupTeam@microsoft.com
Ben Hatton
supported this idea
·
-
4 votesplanned · 0 comments · Azure Active Directory » Privileged Identity Management · Flag idea as inappropriate… · Admin →Ben Hatton
shared this idea
·
-
33 votesstarted · 1 comment · Azure Active Directory » Privileged Identity Management · Flag idea as inappropriate… · Admin →Ben Hatton
shared this idea
·
-
2,600 votes
We’re currently evaluating an option that will provide the functionality offered by nested groups, but removes the complexity nested groups adds. We appreciate your patience on this ask and want to ensure we deliver a solution that benefits all of our customers. Below are use cases that we’d like for you to stack rank, with #1 being priority for you. We thank you for the continued comments and feedback.
Use case A: nested group in a cloud security group inherits apps assignment
Use case B: nested group in a cloud security group inherits license assignment
Use case C: nesting groups under Office 365 groupsAn error occurred while saving the comment Ben Hatton
commented
CAB provided that C means Teams membership supports nested security groups as members.
Ben Hatton
supported this idea
·
-
31 votesBen Hatton
supported this idea
·
-
584 votes
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote which allows us to effectively prioritize your request against our existing feature list and also gives us insight into the potential impact of implementing the suggested feature
Ben Hatton
supported this idea
·
-
170 votestriaged · 8 comments · Networking » Azure Front Door Service · Flag idea as inappropriate… · Admin →Ben Hatton
supported this idea
·
-
51 votestriaged · 2 comments · Networking » Azure Front Door Service · Flag idea as inappropriate… · Admin →Ben Hatton
supported this idea
·
-
13 votesBen Hatton
supported this idea
·
-
6 votesBen Hatton
shared this idea
·
-
101 votesplanned · 2 comments · Networking » Azure Front Door Service · Flag idea as inappropriate… · Admin →Ben Hatton
supported this idea
·
-
284 votesstarted · 7 comments · Networking » Azure Front Door Service · Flag idea as inappropriate… · Admin →Ben Hatton
supported this idea
·
-
266 votes
Please consider using OData-to-OpenAPI converters like this one https://github.com/oasis-tcs/odata-openapi. Additional converters can be found on https://openapi.tools.
Ben Hatton
supported this idea
·
-
3 votesBen Hatton
supported this idea
·
An error occurred while saving the comment Ben Hatton
commented
This integration is problematic to say the least.
a) consent mechanism by-passes the normal 3rd Party AAD user consent security control;
b) consent UI does not provide full disclosure of what those permission grants mean;
c) permissions granted to linkedin exposes wildly inappropriate sensitive data and takes consent from a person who does not own that data;
d) linkedin branding inside the corporate boundary
e) freely exchanges data between a service designed to protect your information and one that is designed to sell your information
f) on by default (at least in some tenant types?)For those who haven't looked closely, these are the grants:
People.Read Read users' relevant people lists Allows the app to read a ranked list of relevant people of the signed-in user. The list includes local contacts, contacts from social networking, your organization's directory, and people from recent communications (such as email and Skype).
Calendars.Read Read user calendars Allows the app to read events in user calendars .
So basically Linkedin will have the permissions to find out who you've been meeting and communicating with, and why. And don't forget that they have permission to read any attachments to your calendar events too.
Providing ability to control access to data by third parties is fundamental to OAuth and AAD and this 'functionality' makes AAD a joke. This seriously damages the trust that Microsoft seemed to have been building with Azure and O365 - I wouldn't be surprised to see a run of public Data Breach notifications coming out of companies using O365.
Remove it entirely. This fails all 6 Microsoft Privacy Principals https://privacy.microsoft.com/en-GB/
FYI there is an export function in the portal that does exactly this, can be run at the subscription level and select to include all child resources. Doesn't work at Management Group though.