Os objetos podem ter várias permissões, mas podem ter apenas uma permissão para cada usuário ou grupo. Por exemplo, uma permissão pode especificar que GroupAdmin tenha a função de Administrador em um objeto. Outra permissão pode especificar que o GroupVMAdmin tem a função de Administrador de Máquina Virtual no mesmo objeto. No entanto, o grupo GroupVMAdmin não pode ter outra permissão para o mesmo GroupVMAdmin neste objeto.
Um objeto filho herda as permissões de seu pai se a propriedade propagate do pai estiver definida como true. Uma permissão definida diretamente em um objeto filho substitui a permissão no objeto pai. Consulte Exemplo 2: permissões secundárias substituindo as permissões principais.
Se várias funções de grupo forem definidas no mesmo objeto e um usuário pertencer a dois ou mais desses grupos, duas situações serão possíveis:
- Nenhuma permissão para o usuário é definida diretamente no objeto. Nesse caso, o usuário obtém a união das permissões que os grupos têm no objeto.
- Uma permissão para o usuário é definida diretamente no objeto. Nesse caso, as permissões para o usuário têm precedência sobre todas as permissões de grupo.
Exemplo 1: Herança de permissão de vários grupos
Este exemplo ilustra como um objeto pode herdar várias permissões de grupos que recebem permissão em um objeto pai.
Neste exemplo, duas permissões são atribuídas no mesmo objeto para dois grupos diferentes.
- O PowerOnVMRole pode ligar máquinas virtuais.
- O SnapShotRole pode tirar snapshots de máquinas virtuais.
- O PowerOnVMGroup recebe a pasta PowerOnVMRole na VM, com a permissão definida para propagar para objetos filho.
- O SnapShotGroup recebe o SnapShotRole na pasta VM, com a permissão definida para propagar para objetos filho.
- O usuário 1 não recebe privilégios específicos.
O usuário 1, que pertence ao PowerOnVMGroup e ao SnapShotGroup, faz login. O usuário 1 pode ligar e tirar snapshots da VM A e da VM B.
Exemplo 2: permissões secundárias substituindo as permissões principais
Este exemplo ilustra como as permissões atribuídas a um objeto filho podem substituir as permissões atribuídas a um objeto pai. Você pode usar esse comportamento de substituição para restringir o acesso do usuário a áreas específicas do inventário.
Neste exemplo, as permissões são definidas em dois objetos diferentes para dois grupos diferentes.
- O PowerOnVMRole pode ligar máquinas virtuais.
- O SnapShotRole pode tirar snapshots de máquinas virtuais.
- O PowerOnVMGroup recebe a pasta PowerOnVMRole na VM, com a permissão definida para propagar para objetos filho.
- O SnapShotGroup recebe o SnapShotRole na VM B.
O usuário 1, que pertence ao PowerOnVMGroup e ao SnapShotGroup, faz login. Como o SnapShotRole é atribuído em um ponto inferior na hierarquia do que o PowerOnVMRole, ele substitui o PowerOnVMRole na VM B. O usuário 1 pode ligar a VM A, mas não pode tirar snapshots. O usuário 1 pode tirar snapshots da VM B, mas não pode ligá-la.
Exemplo 3: Função de usuário que substitui a função de grupo
Este exemplo ilustra como a função atribuída diretamente a um usuário individual substitui os privilégios associados a uma função atribuída a um grupo.
Neste exemplo, as permissões são definidas no mesmo objeto. Uma permissão associa um grupo a uma função, a outra permissão associa um usuário individual a uma função. O usuário é um membro do grupo.
- O PowerOnVMRole pode ligar máquinas virtuais.
- O PowerOnVMGroup recebe a pasta PowerOnVMRole na VM.
- O usuário 1 recebe a função NoAccess na pasta VM.
O usuário 1, que pertence ao PowerOnVMGroup, faz login. A função NoAccess concedida ao Usuário 1 na Pasta VM substitui a função atribuída ao grupo. O usuário 1 não tem acesso à pasta VM ou às VMs A e B. As VMs A e B não são visíveis na hierarquia para o usuário 1.
