Expansion of user roles
under review
B
Bryce Skelton
This would be amazing. We have an issue where techs may need to approve an exclusion for troubleshooting, but we wouldn't want to give full access to everything else. The current issue is not everyone is as security conscious so there would be significant overhead in auditing tenant settings to ensure nothing was improperly adjusted. If we could do RBAC or make our own custom roles and pick and choose access to various components that would be a game changer and allow our internal security team to expand the access for other techs that we currently limit.
T
Thomas Welch
The best model I can think of would be to allow the creation of custom roles where Account-level, Global client-org, and Individual client-org permissions can be individually assigned to the role. Allowing the use of custom role names could allow integration with SSO so that IdP group memberships can automatically determine roles and permissions.
Our org is deeply invested in Entra as our IdP so using our existing Entra group memberships to assign roles and permissions in Huntress would be the ideal solution. Even better if SSO could automatically provision/deprovision users so we can manage identity solely in our IdP during user on/off-boarding.
It's common for c-staff to request access to things like Huntress, especially if they get copied on alerts. SSO would at the client-org level would be great. This could allow us to automate creating organization users and granting them permissions based on Entra group memberships. It could be easily integrated with the M365 tenant mapping process.
J
Jason Boyd
Granular permissions are really needed. As others have commented, we need the ability to assign part of our MSP team with the ability to manage some items (isolate, de-isolate, Defender exclusions) for every client individually, but not globally.
J
Josh Spern
As others have said, the ability to granularly assign permissions is very much needed. The "Security Engineer" role as it stands today is too permissive.
Eric Henry
under review
J
Jeff Custer
We would like to be able to disallow account-level access changes for Account-level users (example, not be able to set an exclusion for a country...for ALL organizations), or maybe even allow ONLY user-level access changes for Account-level users (our technicians who currently have the "Security Engineer" role). Another way to put this is: We need the ability to granularly assign permissions per role. In addition, adding the ability to granularly assign organization-level permissions (for internal IT users at the larger clients) so they can do things like set travel exclusions for VPN/Location Escalations for their org, for example.
E
Emma Santiago
Feedback from a partner we recieved:
I know Huntress has been talking about removing the Security Engineer role completely for Organizational level, but maybe that should be the equivalent of the current admin role, while the admin role is modified to actually allow for all actions. I'm unclear as I don't believe I've run into this issue before, for most clients we do the management of the escalations at the account level, but I would still expect that if I make an internal organization's power user an admin for the organization it would still allow them to resolve escalations. Otherwise, I'm not sure what the point of that role would be? For that client specifically, they found that new VPN connection was unexpected, but they were unable to create a new ITDR rule to effectively take action on the alert.
E
Eyal Gallico
We need roles for different techs to manage different companies
Chad Perrier
We need Finance Role to be allowed to sync subscriptions so they can update Agreement qty. and manage agreements. Since this is not enabled, it forces an admin to intervene during the billing process due to lack of permissions.
J
Jon Cole
We need the ability as an MSP to set Account users to access a subset of organizations. AutoElevate has a feature where we can say "This user can access all organizations EXCEPT [list one or more organizations in the account]". We don't want our regular techs being able to affect our internal systems but be able to affect our clients.
Load More
→