Delegating permissions across domains using Domain Local groups does not work as expected with vCenter Server or vRealize Automation
search cancel

Delegating permissions across domains using Domain Local groups does not work as expected with vCenter Server or vRealize Automation

book

Article ID: 341628

calendar_today

Updated On:

Products

VMware Aria Suite VMware vCenter Server

Issue/Introduction

This article provides guidance on using Domain Local groups within your Active Directory domain when using Active Directory (Integrated Windows Authentication) identity source with your vCenter Single Sign-On, Platform Services Controller, or vRealize Automation Center infrastructure.

Environment

VMware vCenter Server Appliance 6.0.x
VMware vRealize Automation 6.2.x
VMware vCenter Server Appliance 5.5.x
VMware vCenter Server 6.0.x
VMware vCloud Automation Center for Server 6.0.x
VMware vCenter Server 5.5.x
VMware vCloud Automation Center for Server 6.1.x

Cause

Domain Local groups can only be used to delegate rights for resources located in the same domain that the vCenter Single Sign-On, Platform Services Controller or vRealize Identity Appliance server resides in; this behavior is by design, which conforms with Microsoft Active Directory group permission semantics.

Note: vCenter Single Sign-On, Platform Services Controller and vRealize Identity Appliance all utilize the same Single Sign-On (SSO) stack.

When you connect to one of the above authentication services through their respective clients (e.g. vSphere Web Client, vRealize Automation Center), SSO performs a Windows API call to the domain that the SSO service resides in. If the user is a member of a local group in another domain, the Security Identifier (SID) of that local group is not included in the security token generated by the Active Directory request from SSO. As a result, SSO is not be aware of that group membership required for SAML token creation and the user does not gain the required access. This is due to the Domain Local group construct only being able to be utilized by resources in its local domain, of which SSO is not an available resource.

Use the following model as an example environment:


Example 1:
  • Domain A and Domain B are in the same forest
  • User 1 belongs to Domain A
  • Domain Local Group B is a Domain Local group in Domain B
  • vCenter Single Sign-On is installed in Domain A

    When vCenter Single Sign-On obtains an authentication token from the Windows Host Operating System the token only contain Domain Local Groups from Domain A.
Reproduction Steps:
  1. Add User 1 to Domain Local Group B
  2. Through the vSphere Web Client connected to the vCenter Single Sign-On, grant permissions to some vSphere resource (e.g. vCenter Server) to Domain Local Group B.
  3. Attempt to log into the vSphere Web Client with User 1. Observe that the user has no permissions to the resource(s) granted.
  4. Attempt to log into the vSphere Client with User 1. Observe the error You do not have permission to login to the server: vCenter_Server_FQDN

Example 2:
  • Domain A and Domain B are in the same forest
  • User 2 belongs to Domain B.
  • Domain Local Group A is a Domain Local group in Domain A
  • vCenter Single Sign-On is installed in Domain A

    When vCenter Single Sign-On obtains an authentication token from the Windows Host Operating System the token only contain Domain Local Groups from Domain A, of which Domain Local Group A is one of them.
Reproduction Steps:
  1. Add User 2 to Domain Local Group A
  2. Through the vSphere Web Client connected to the vCenter Single Sign-On, grant permissions to some vSphere resource (e.g. vCenter Server) to Domain Local Group A.
  3. Attempt to log into the vSphere Web Client with User 2. Observe that you are able to access the resource properly from the vSphere Web Client as this is a local resource.
  4. Attempt to log into the vSphere Client with User 2. Observe that you are able to access the resource properly from the vSphere Client as this is a local resource.

For more information about Domain Local groups, see the Microsoft TechNet Group scope.

Resolution

In order to delegate permissions across domains, perform one of the following options per your internal IT requirements:

  • Use Universal groups to delegate authentication and authorization to cross-domain users. Using the Universal groups, grant permissions to vSphere resource (e.g. vCenter Server). For guidance on changing scope types in Microsoft Active Directory, see the Microsoft TechNet Group scope article, section Changing group scope in the Understanding Active Directory guide.

  • If vCenter Single Sign-On, Platform Services Controller or vRealize Identity Appliance are installed local to the Domain Local group, authorization and authentication are granted as expected.

    Note: The preceding links were correct as of August 25th, 2015. If you find the link is broken , provide a feedback and a VMware employee will update the link.


Additional Information

vCenter Server または vRealize Automation では Domain Local グループを使用してドメインを超えて権限を委任しても想定どおりに機能しない