Headline:
Permissions to only allow impersonation on the subtenant users
Description:
Master tenant users to be able to impersonate users in all subtenants, but not be able to impersonate users that are present in the master tenant.
A different function, but related… I have been chatting with a partner who mentioned that it would be nice to be able to select a subset of tenants where a root user could impersonate.
For example, with a Morpheus deployment of a root tenant and 5 subtenants, a user in the root tenant would be able to impersonate users from Tenant 1, Tenant 2, and Tenant 3; but not be able to impersonate users from Tenant 4 or Tenant 5. The applicability of this is in MSP environments, where a single Morpheus deployment might serve hundreds of subtenants. Different teams in the MSP organization might be “named” to certain tenants or might be named to a team which primarily looks after one type of tenant but not others (e.g. “Finance and Banking” or other restricted tenants).
Any thoughts on that? It seems like it would be very related to developing the original request.
1 Like
@btrapier This will be tremendously appreciated by most MSP customers.
For some, this is a road blocker for compliance reasons and some of our projects can’t move forward.
As Morpheus is used for way more than just one purpose, different Tenants are managed by different teams.
While the impersonation feature is a priceless help for support teams, it opens a very significant security issue. Customers of MSP sites are not protected if their workloads are accessible by teams that are not supposed to see it. If we had a way to setup which support team will see which tenant, then we can close this security gap.
Hi,
This would be a great feature, maybe also the possibility to switch off impersonation at all.
For certain security oriented sites this would be mandatory.
Ofcourse there are certain boundaries, but an admin with too many rights can do a lot of harm, even unintended, so lessening the scope of admins is certainly appreciated.
I could imagine a Security Tenant inside a large company doesn’t want to have top level admins to be able to interfere with their services. Sometimes even an unknown feature which is selected at master tenant can harm a subtenant when wrongfully applied.
Regards, Edward
Renato @Censi I met with Product this week; this capability hasn’t progressed on the priority list yet; but, while we are having the discussion, is something like this what we are thinking?
@wabbas / @EdwardVanHazendonk would this also work for your architectures?
Hi @btrapier,
We have a question about the picture.
Normally groups are only existing within 1 tenant, how is group Customers Blue able to exist in 2 Tenants?
Will groups be multitenant afterwards, or is this a trick with binding the same directory on multiple tenants with a different role/group binding per tenant?
Best regards,
Edward van Hazendonk
sr Linux Engineer
Cortexia B.V.
e: edward.van.hazendonk@cortexia.nl
w: www.cortexia.nl
I wonder if there are any process on this topic “not be able to impersonate users that are present in the master tenant”.
As of now if I need to impersonate into subtenant users I need to get permission right for doing general impersonation.
When I have that then after logging into master tenant I can impersonate into another user in same master tenant (which makes no sense as I already logged in with privileges assigned to me).
So in this case this is security flaw, after logging with less priviledged account you can gain master admin priviledges.