Support Extended RBAC in Center

[lurendrejer]

Describe the bug When hosting a XCP-farm to clients you have no control over - you can't give them "special RBAC roles".

To Reproduce Steps to reproduce the behavior:

1. Log on to Xen-pool, give special permisions to a user via: xe subject-role-add
2. Open XCP-Center, try to use the given priviledge.
3. Say hello to a "SUDO-popup box" - that can be disabled by the client via regedit
4. Have a lousy time explaining to thousands of non-domain-joined PC owners to run a certain reg-script mentioned here: https://support.citrix.com/article/CTX126442

Expected behavior To not have SUDO-popups activated as default.

Screenshots / Logfiles

XCP-ng Center:

• XCP-ng Center Version: Latest - and everything before it (xencenter 5-7 also)
• Desktop OS: Windows

XCP-ng Server

• Hardware: HP
• XCP-ng Version: 7.6

Additional context Every special permission set on the servers, does not work without having the "DontSudo" options set in the client registry. hklm/software/xcp-ng/XCP-Center/DontSudo=True. If an admin takes the time to create advanced permissions schemes, he would expect them to work without having to contact pool-users afterwards. Every action the user takes, that involves the new permissions - will just fail after the user fails to give sudo/root credentials.

The following reg-script solves the problem, when run on the users PC.

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\XCP-ng\XCP-ng Center] "DontSudo"="True"

[borzel]

@lurendrejer can you please add more context... I don't get the whole thing...

what does this sentence mean? -> When hosting a XCP-farm to clients you have no control over - you can't give them "special RBAC roles".

[lurendrejer]

Hi, sorry!

RBAC roles are special permissions assigned to groups or users. Think of them as "fine grained" access to the XCP-Pool. An admin can assign a certain user access to perform a certain task.

When the user tries to perform these RBAC-actions - he will be prompted for the root password (and the action will fail). Except if he sets the "DontSudo" flag on his own pc - then XCP-Center just performs the actions as the currently logged in user.

[lurendrejer]

I can give you access to a farm with a limited user if it helps you. You will only have the ability to perform admin-tasks after editing your local registry as described in the Citrix-article.

[lurendrejer]

I don't know if this can be replicated with a offline copy of my pool-db. I'll be happy to help with anything you might need.

[borzel]

@lurendrejer just explain, how do you configure such ACLs?

[lurendrejer]

Hi. I'll try to explain it a little better than the Citrix article :)(https://support.citrix.com/article/CTX126442)

A short guide would be:

1. Join pool to domain.
2. Add AD-user to pool via xcp-center -> users.
3. Assign a predifined role via xcp-center.
4. log into the pool master and add additional role-features via 'xe subject-role-add' command.

As an example: Allowing vm operators to add virtual interfaces would look like this: xe subject-role-add uuid=66bda296-fbfd-aaa7-0568-73e8d3b962c5 role-name=vif.plug xe subject-role-add uuid=66bda296-fbfd-aaa7-0568-73e8d3b962c5 role-name=vif.unplug xe subject-role-add uuid=66bda296-fbfd-aaa7-0568-73e8d3b962c5 role-name=vif.create xe subject-role-add uuid=66bda296-fbfd-aaa7-0568-73e8d3b962c5 role-name=vif.destroy xe subject-role-add uuid=66bda296-fbfd-aaa7-0568-73e8d3b962c5 role-name=vm.set_name_label

[lurendrejer]

If this is done correctly, xcp-center crashes if you try to edit the added user via the gui afterwards. (Also described in the Citrix article)

I'm writing from my phone, spelling might be completely off.

[lurendrejer]

The best possible solution would be to rewrite the permissions / users interface. To support all the xen/xcp permissions instead.

I'll upload a document containing all the supported permissions when I get to a computer.

[lurendrejer]

Try searching the Citrix article for :

If the registry key is not applied and a user attempts to complete an action for an assigned permission, they receive the following screen shot:

[lurendrejer]

All the permissions Xenserver/Xen/XCP supports is contained in this PDF-document. vdocuments.mx_ctx126441-available-role-based-access-control-permissions-for-xenserver.pdf

XCP-center only supports the following roles:

XCP-centers role editor crashes if you assign any of the 'extended permissions from the PDF' to a given user/group.

[olivierlambert]

FYI, before doing ACLs in Xen Orchestra, we took a deep look into the XAPI ACLs. But it was so limited that we decided to use our own ACLs in the end. I'm not saying this is your solution, but just take a look if it can answer your needs :)

[lurendrejer]

Hi. Xenorchestra could be a solution, but not having RDP integration is a no-go. When a few hundred users connect via console/vnc everything grinds to a halt :)

My real issue, is that the default functionality of xencenter/xcp-center assumes that a pool-admin has access to the clients. The SUDO-box should not be enabled as a default option - or at least have an option to just enter the users own credentials, not those of a more privelidged user.

[olivierlambert]

RDP integration: do you mean you use that as a kind of remote desktop solution? In theory, consoles are here to provide basic solution to do maintenance operation, not to work remotely (XenDesktop or equivalent does this role). Maybe I missed something? (sorry if it's a dumb question, I have 0 experience in Windows environment/usage)

[lurendrejer]

Hi Olivier :)

XCP-Center switches to low-bandwidth/CPU-usage protocols if available. When connecting to *nix servers, it changes from VNC to SSH and on Windows it uses RDP.

[olivierlambert]

Yeah I know that, but I mean what's the use case? Those consoles are meant for maintenance operations only, not to be remote working solution.

[lurendrejer]

IT-students. We roll out 100's of machines, they use them any way the see fit - for a week We remove them afterwards.

We are going off-topic, but i've requested some sort of EDU-license for XOSAN in the past, but you don't do that im afraid :(

[olivierlambert]

Okay so it's a kind specific use case :) In XO, it's meant more as "maintenance" console to let people reboot them for example, not to actually work on it. Thanks for the feedback :)

Regarding XOSAN, we could always talk in private to see what we can do, send a email to sales at vates dot fr

[lurendrejer]

@borzel I'm sorry that we went off topic. Did I supply you with enough info? A workaround could be to just set the registry value when installing via the msi.

/from the phone

[lurendrejer]

This rabbithole is even deeper. I gave my read-only users access to the console, via RBAC - the XCP-ng Center console just tells them that "Read only users doesn't have console access to vm's", even though their users does. It doesn't even 'try' to show the console. It just figures "hey, they can't". I find the behavior odd, since the gui does support showing actions in the log that the user tried to access - but was denied.

So, on a more generel note - I might just like the interface to not make assumptions about what permissions a user has, in general. :) All in all, it seems rather backwards - having the GUI control permissions, instead of the backend.

[borzel]

ok, i did understand your issue but have not enought time to test and debug this out :-/ Maybe someone else has time and motivation to make this work for you? Contributions are welcome!

[borzel]

As I have no spare time I close this :-(