Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't create DomainAdmin Account to Domain #10096

Closed
hiblinux opened this issue Dec 12, 2024 · 6 comments
Closed

Can't create DomainAdmin Account to Domain #10096

hiblinux opened this issue Dec 12, 2024 · 6 comments

Comments

@hiblinux
Copy link

ISSUE TYPE
  • Questions
COMPONENT NAME
Create Account And Users
CLOUDSTACK VERSION
CloudStack 4.19.1.1 
SUMMARY

I have a Role named Domain Admin L2 with the Role Type of Admin and linked to the "admin l2" account in the ROOT domain (Csv rules attached).

The problem I encounter is that when I want to create a new account in the Sub-domain, let's call it ROOT/CS/Customer1, using the available default role named Domain Admin with Role Type DomainAdmin, an error appears stating 'can not create an account with access to more privileges they have themself.'

From the CSV i see the Domain Admin L2 role has more privileges than Domain Admin role.

What is wrong with what I'm doing?

image

Domain Admin_DomainAdmin.csv
Domain Admin L2_Admin.csv

Copy link

boring-cyborg bot commented Dec 12, 2024

Thanks for opening your first issue here! Be sure to follow the issue template!

@DaanHoogland
Copy link
Contributor

@hiblinux at first sight it doesn't look like you are doing anything wrong. Can you create the new account from a user in the root admin account?

@hiblinux
Copy link
Author

@DaanHoogland Yes i can create new account from the Root Admin.

But the situation need me to seperate the privileges of account, thats the reason i create new Role name "Domain Admin L2".

@DaanHoogland
Copy link
Contributor

Understood, there is a related PR out (that needs a volunteer to test it) #9173 . Maybe it solves your issue...

@BryanMLima
Copy link
Contributor

Hello, @hiblinux

First, I just want to clarify how ACS checks if a given role has permission to create another account. It will check if the caller account has permission (i.e., allow) to all APIs in the role used by the target account.

Using a diff checker tool, I managed to encounter some inconsistencies, that would fail this verification. The following APIs are denied for the role Domain Admin L2 and are allowed for the role DomainAdmin:

  • createDiskOffering
  • createServiceOffering
  • deleteDiskOffering
  • deleteServiceOffering
  • updateDiskOffering
  • updateServiceOffering
  • updateConfiguration

Even though the type of the role Domain Admin L2 is Admin and the role Domain Admin is of type DomainAdmin, ACS will fail in the validation of the APIs above; that's why you are receiving the message can not create an account with access to more privileges they have themself.

Now, about the why ACS does not allow this: escalation of privileges. If a user could create an account with more privileges than its own, then this is a security concern. Consider a scenario where a custom Root Admin was created with just read permissions. If ACS allowed this role to create another account with more permissions just because it is of type Admin, an attacker could you this to create a Root Admin with all permissions, which is not desired.

To tackle your problem specifically, you'll need to normalize the permissions of the APIs mentioned above (and others, if I missed something) for the custom role Domain Admin L2.

@DaanHoogland, I don't think this is a bug, it is working as expected.

@DaanHoogland
Copy link
Contributor

Good find @BryanMLima , @hiblinux please see the explanation above. It makes sense.

@DaanHoogland DaanHoogland removed this from the 4.19.2 milestone Dec 12, 2024
@apache apache locked and limited conversation to collaborators Dec 12, 2024
@DaanHoogland DaanHoogland converted this issue into discussion #10099 Dec 12, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants