This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Role Based Access Control overview
The Role Based Access Control (RBAC) feature lets you assign predefined roles or sets of permissions to Active Directory users and groups. These permissions control the level of access XenServer administrators have to servers and pools. RBAC is configured and deployed at the pool level. Because users acquire permissions through their assigned role, assign a role to a user or their group to give them the required permissions.
Using Active Directory accounts for XenServer user accounts
RBAC lets you restrict which operations different groups of users can perform. This control reduces the likelihood of inexperienced users making disastrous accidental changes. Assigning RBAC roles also helps prevent unauthorized changes to your resource pools for compliance reasons. To facilitate compliance and auditing, RBAC also provides an audit log feature and its corresponding Workload Balancing Pool Audit Trail report. For more information, see Audit Changes.
RBAC depends on Active Directory for authentication services. Specifically, XenServer keeps a list of authorized users based on Active Directory user and group accounts. As a result, you must join the pool to the domain and add Active Directory accounts before you can assign roles.
RBAC process
The standard process for implementing RBAC and assigning a user or group a role consists of the following steps:
- Join the domain.
- Add an Active Directory user or group to the pool.
- Assign (or modify) the user or group’s RBAC role.
Local super user
The local super user (LSU), or root, is a special user account used for system administration and has all rights or permissions. In XenServer, the local super user is the default account at installation. The LSU is authenticated by XenServer and not an external authentication service. If the external authentication service fails, the LSU can still log in and manage the system. The LSU can always access XenServer physical server through SSH.
RBAC roles
XenServer comes with six pre-established roles that are designed to align with different functions in an IT organization.
-
Pool Administrator (Pool Admin). This role is the most powerful role available. Pool Admins have full access to all XenServer features and settings. They can perform all operations, including role and user management. They can grant access to XenServer console. As a best practice, Citrix recommends assigning this role to a limited number of users.
Note:
The local super user (root) always has the Pool Admin role. The Pool Admin role has the same permissions as the local root.
If you remove the Pool Admin role from a user, consider also changing the server root password and rotating the pool secret. For more information, see Pool Security.
- Pool Operator (Pool Operator). This role is designed to let the assignee manage pool-wide resources. Management actions include creating storage, managing servers, managing patches, and creating pools. Pool Operators can configure pool resources. They also have full access to the following features: high availability, Workload Balancing, and patch management. Pool Operators cannot add users or modify roles.
- Virtual Machine Power Administrator (VM Power Admin). This role has full access to VM and Template management. They can choose where to start VMs. They have full access to the dynamic memory control features and the VM snapshot feature. In addition, they can set the Home Server and choose where to run workloads. Assigning this role grants the assignee sufficient permissions to provision virtual machines for VM Operator use.
- Virtual Machine Administrator (VM Admin). This role can manage VMs and Templates and access the storage necessary to complete these tasks. However, this role relies on XenServer to choose where to run workloads and must use the settings in templates for dynamic memory control and the Home Server. (This role cannot access the dynamic memory control features, make snapshots, set the Home Server or choose where to run workloads.)
- Virtual Machine Operator (VM Operator). This role can use the VMs in a pool and manage their basic lifecycle. VM Operators can interact with the VM consoles and start or stop VMs, provided sufficient hardware resources are available. Likewise, VM Operators can perform start and stop lifecycle operations. The VM Operator role cannot create or destroy VMs, alter VM properties, or server resources.
- Read-only (Read Only). This role can only view resource pool and performance data.
For information about the permissions associated with each role, see Definitions of RBAC roles and permissions. For information about how RBAC calculates which roles apply to a user, see Calculating RBAC roles.
Note:
When you create a user, you must first assign a role to the newly created user before they can use the account. XenServer does not automatically assign a role to the newly created user.
Related documentation
XenServer 8
Citrix Hypervisor 8.2 Cumulative Update 1
Share
Share
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.