Recently I
worked with customer on implementation of new RBAC (Role Based Access Control)
for the purpose of allowing specific group of IT technicians to create and maintain
CAP (Common Area Phone).
Objective:
All CAP
accounts should be stored in specific OU. One or more
users should have permissions to create, modify or remove CAP accounts.
The first
step is to create new RBAC role. The detail description of the cmdlet can be
found here: http://technet.microsoft.com/en-us/library/gg398271.aspx.
As per
objective, we will create new RBAC role based on CsVoiceAdministrator, since
CAP properties management falls under Voice. However, the first step is to
create new Active Directory Universal Security Group. This is because the “identity”
of our custom RBAC must correspond one-to-one with Active Directory group object.
A new OU was
created where the CAP accounts will be placed.
Now we are
ready to construct our command:
New-CsAdminRole
–Identity “US-CAP-ADMIN” –Template CsVoiceAdministrator –UserScopes
"OU:ou=CAP,ou=US,DC=lynclog,DC=com"
…where
Identity parameter matches the name of the Universal Security Group we created
earlier, Template is CsVoiceAdministrator, and with UserScopes parameter we allow
execution only when the target for placement if the OU designated for CAP.
The above
command created our new RBAC role and narrowed the scope to the desired OU, but
we still have to define the type of objects will be allowed to be managed.
This article (http://technet.microsoft.com/en-us/library/gg425739.aspx)
details the Object types (and is the primary reason for this blog post as we
will see later).
***Previously
I created user account “CAPadmin” and added it to “US-CAP-ADMIN” universal
Security Group.
To grant permissions,
I will use the example from TechNet (http://technet.microsoft.com/en-us/library/gg425739.aspx)
Grant-CsOUPermission
–OU "OU=CAP,OU=US,DC=lynclog,DC=com" -ObjectType "user",
“contact”, "InetOrgPerson"
Next step is
to check the implementation.
- From a workstation where I logged as the “CAP administrator”, open PowerShell as Administrator run $Cred=Get-Credential
- Supply username and password for the account we want to test with
- Run $Session=New-PSSession -ConnectionUri https://dcpool.lynclog.com/OcsPowerShell -Credential $Cred
***dcpool.lynclog.com is the target pool where will perform the remote execution
Let’s now
create new CAP account and verify our implementation (the scope is not only to
manage CAP, but also to create and/or remove new CAP)
With the already established Remote Session, I ran New-CsCommonAreaPhone -LineUri tel:+14255559001 -RegistrarPool dcpool.lynclog.com -DisplayName "Building 14 Lobby" -OU "OU=CAP,OU=US,DC=lynclog,DC=com"
Interestingly, the command failed.
At this point
I went back to the basics, because my first thought was – “I am missing
something”. This article - http://technet.microsoft.com/en-us/library/hh849655(v=ocs.14).aspx
describes the changes made by Grant-CsOUPermissions over the AD objects.
Because my objective was to allow CAP Admins to create CAP account, and not only manage, I searched for “Create” permission throughout the article. Interestingly,
the only ObjectType with Create permission found is… Device.
Hmm, Grant-CsOUPermission
article above never mentioned about this parameter…
However, none
of the above would have Create permissions.
At this point
I faced complete still. None of the available parameters would have “Create”
permissions, but a parameter not mentioned (Device) would. I took a deep breath
and ran the following: Grant-CsOUPermission -OU "OU=CAP,OU=US,DC=lynclog,DC=com"
-ObjectType "device"
We also have Test-CsOUPermission cmdlet and so, when ran, it showed
ObjectType device = True
Now the command ran correctly.
The
conclusion is that if we want to grant Create permissions for new RBAC, ObjectType
“device” must be included.
