New-VIPermission at ESX host root

[Guy_Chapman]

EMC ControlCenter requires a local account on the ESX host for discovery. In order to do this I need to create a permission at the host root level. I can do this with New-VIPermission -Entity (Get-VMHost) but the permission it reates is broken in some way. It works, I can log on, but the entity is clearly wrong.

The fault becomes evident if I try to delete the permission: an error is thrown (whether I use PowerCLI or the GUI)

• The EntityID for the root permission is Folder-ha-folder-root

• The EntityID for the permission created as above is HostSystem-ha-host

• The entityID for a permission created using the GUI is ComputeResource-ha-compute-res, Folder-ha-folder-root, HostSystem-ha-host, ResourcePool-ha-root-pool

What Entity should I be passing in New-VIPermission to create a valid permission at this level?

[LucD]

How did you create the account on the ESX host ? With the New-VMHostAccount cmdlet ?

The New-VIPermission requires this account in the -Principal parameter.

And you should connect (Connect-VIServer) to the ESX server, not the vCenter.

Perhaps you could show us the script you are using ?

[Guy_Chapman]

It's not so much that you /should/ connect direct to the host as that the VIPermission cmdlets are simply not available unless you do.

The group was created using New-VMHostAccount -Group ControlCenter

The account was created using New-VMHostAccount -User -Id -AssignGroups ControlCenter

The role was created using New-VIRole -Name ControlCenter -Privilege ( Get-VIPrivilege -PrivilegeItem "Browse datastore" )

The permission was created using New-VIPermission -Entity (Get-VMHost) -Role ControlCenter -Principal ControlCenter -Propagate:$true

This works, in that I can log on using the ControlCenter user account and password and I can then browse the datastore but if I try to remove the permission I get an error on the console log: Remove entity permission; A specified parameter was not correct . entity

The PowerCLI error text is

Remove-VIPermission : 14/01/2010 10:38:18 Remove-VIPermission 52123a0d-b04d-3c9e-7feb-3b254800ca2a A specified

parameter was not correct.

entity

At line:1 char:20

+ Remove-VIPermission <<<< -Permission $sgPermission

So, the entity reference is wrong and I can't work out how to grab a handle to the right entity, or even which entity that might be.

[LucD]

You're right there is indeed something wrong with the Remove-VIPermission cmdlet.

I could reproduce the problem.

[LucD]

Noticed something strange, after you have set the permission do

$perm = Get-VIPermission | where {$_.Role -eq "ControlCenter"}

In my test environment this returned 3 objects.

EntityId             Role                      Principal       IsGroup Propagate
--------             ----                      ---------       ------- ---------
ComputeResource-h... ControlCenter             test            False   True
HostSystem-ha-host   ControlCenter             test            False   True
ResourcePool-ha-r... ControlCenter             test            False   True

If I do a Remove-VIPermission on the first object (entity ComputeResource-ha-compute-res), the permission is removed and there are no error messages.

Remove-VIPermission -Permission $perm[0]

Do you see the same behavior ?

[ykalchev]

Actually New-VIPermission creates invalid permission because when you're connected directly to esx host and all permissions should be set on the host root folder and parent ComputeResource object.

You can try to set permission on the root folder as workaround because the compute resource is mainly for the case where you want to assign non-propogate permissions to the host.

New-VIPermission -Entity (Get-Folder -NoRecursion) -Role ControlCenter -Principal ControlCenter -Propagate:$true

Regards,

Yasen

[Guy_Chapman]

Yes, that is certainly interesting.

Part of the problem is in the original permission assigment itself. The script I've used to do that lokos like this:

If ((Get-VIPermission -Principal ControlCenter2).Role -notcontains "ControlCenter2" ) {
  write-host "Assigning permission on $($sgServer.Name)"
  New-VIPermission  -Entity (Get-VMHost) -Role ControlCenter2 -Principal ControlCenter2 -Propagate:$true
}

So I need to fix that to assign the correct entity in the first place, obviously.

I saw the code snippet you posted earlier,

$authMgr = Get-View (Get-View ServiceInstance).Content.AuthorizationManager
$entity = Get-Folder ha-folder-root | Get-View
$authMgr.RemoveEntityPermission($entity.MoRef,"ControlCenter",$true)

So by the looks of it I need to use something similar to set the permission in the first place. The obvious does not work, so now I know I don't know how to set up the permission correctly.

I tried this:

New-VIPermission  -Entity (Get-Folder ha-folder-root) -Role ControlCenter2 -Principal ControlCenter2 -Propagate:$true

it gave the following output:

New-VIPermission : 14/01/2010 13:28:16    New-VIPermission    52641409-e13d-37c7-f867-d33f1dbe8ff5    Object reference
not set to an instance of an object.
At line:1 char:19
+   New-VIPermission  <<<<  -Entity (Get-Folder ha-folder-root) -Role ControlCenter2 -Principal ControlCenter2 -Propaga
te:$true

[Guy_Chapman]

That comes back with this error:

New-VIPermission : 14/01/2010 13:33:27    New-VIPermission    52641409-e13d-37c7-f867-d33f1dbe8ff5    Object reference not set to an instance of an object.
At line:1 char:17
+ New-VIPermission  <<<< -Entity (Get-Folder -NoRecursion) -Role ControlCenter -Principal ControlCenter -Propagate:$true

[LucD · Accepted solution]

Try this

$authMgr = Get-View (Get-View ServiceInstance).Content.AuthorizationManager
$entity = Get-Folder ha-folder-root | Get-View
$perm = New-Object VMware.Vim.Permission
$perm.entity = $entity.MoRef
$perm.group = $true
$perm.principal = "ControlCenter"
$perm.propagate = $true
$perm.roleId = ($authMgr.RoleList | where {$_.Name -eq "ControlCenter"}).RoleId
$authMgr.SetEntityPermissions($entity.MoRef,$perm)

Worked for me.

[Guy_Chapman]

Brilliant, thanks. Obviously I will have to get to grips with both parts of the CLI. Anyway, here's the code as finished:

# Script to add the required user and roles for EMC ControlCenter discovery
$erroractionpreference = "SilentlyContinue"
$sgServer = Connect-VIServer -Server emealonbc11 -User root -Password <password>
# Does the ControlCenter role exist? If not, create it
If (!( $sgRole = Get-VIRole -Name ControlCenter )){
  write-host "Creating ControlCenter role on $($sgServer.Name)"
  $sgRole = New-VIRole -Name ControlCenter -Privilege ( Get-VIPrivilege -PrivilegeItem "Browse datastore" )
}
# Does the ControlCenter group exist? If not, create it
If (!( $sgGroup = Get-VMHostAccount -Group ControlCenter )) {
  write-host "Creating ControlCenter group on $($sgServer.Name)"
  New-VMHostAccount -Group ControlCenter
}
# Does the eccuser account exist? If so, check group membership, if not create it
If ( $sgAccount = Get-VMHostAccount -User -ID eccuser ) {
  If ( $sgAccount.Groups -notcontains "ControlCenter" ) {
    write-host "Assigning eccuser to ControlCenter group on $($sgServer.Name)"
    $sgAccount |Set-VMHostAccount -AssignGroups "ControlCenter"
  }
} else {
  write-host "Creating eccuser account on $($sgServer.Name)"
  New-VMHostAccount -User -Id eccuser -Password <password> -Description "EMC ControlCenter discovery" -AssignGroups "ControlCenter"
}
# Does the permission apply at the root level? If not, assign the permission
If ((Get-VIPermission -Principal ControlCenter).Role -notcontains "ControlCenter" ) {
  write-host "Assigning permission on $($sgServer.Name)"
  $sgAuthMgr = Get-View (Get-View ServiceInstance).Content.AuthorizationManager
  $sgEntity = Get-Folder ha-folder-root | Get-View
  $sgPerm = New-Object VMware.Vim.Permission
  $sgPerm.entity = $sgEntity.MoRef
  $sgPerm.group = $true
  $sgPerm.principal = "ControlCenter"
  $sgPerm.propagate = $true
  $sgPerm.roleId = ($sgAuthMgr.RoleList | where {$_.Name -eq "ControlCenter"}).RoleId
  $sgAuthMgr.SetEntityPermissions($sgEntity.MoRef,$sgPerm)
}
Disconnect-VIServer -Confirm:$false

Only one anomaly remains: the permission is set to propagate but it is not, in fact, propagated. I'm guessing this is down to a behind the scenes action kicked off by the GUI and not prompted by the CLI. If you uncheck and then check propagate, it propagates. I will wait a few minutes and see if the propagation occurs automagically.

Thanks enormously for your help.