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).
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.