In a locked-down Active Directory Domain Service (AD DS), Users and Computer objects are often placed in specific organizational units (OUs) with permissions inheritance disabled to help secure administrative delegation and to enable use of Group Policy objects (GPOs) to enforce security policies.
Domain preparation and server activation set the access control entries (ACEs) required by Office Communications Server 2007 R2. When permissions inheritance is disabled, the Office Communications Server security groups cannot inherit these ACEs. When these permissions are not inherited, Office Communications Server security groups cannot access settings, and the following two issues arise:
- To administer Users, InetOrgPersons, and Contacts, and to
operate servers, the Office Communications Server security groups
require ACEs set by the domain preparation procedure on each user’s
property sets, Real-time Communications (RTC), RTC User Search, and
Public Information. When permissions inheritance is disabled,
security groups do not inherit these ACEs and cannot manage servers
or users.
- To discover servers and pools, Office Communications Server
servers rely on ACEs set by activation on computer-related objects,
including the Microsoft Container and Server object. When
permissions inheritance is disabled, security groups, servers, and
pools do not inherit these ACEs and cannot take advantage of these
ACEs.
To address these issues, Office Communications Server provides an additional Active Directory preparation procedure called CreateLcsOuPermissions, available with the LcsCmd.exe command-line tool. This procedure sets required Office Communications Server ACEs directly on a specified container and the objects within the container.
Set Permissions for User,
InetOrgPerson, and Contact Objects after Running Domain
Preparation
In a locked-down Active Directory environment where
permissions inheritance is disabled, domain preparation does not
set the necessary ACEs on the containers holding Users or
InetOrgPerson objects within the domain. In this situation, you
must run LcsCmd.exe with the CreateLcsOuPermissions action on each
container that has User or InetOrgPerson objects for which
permissions inheritance is disabled. If you have a central forest
topology, you must also perform this procedure on the container
that holds Contact objects. (For details about central forest
topologies, see
This procedure adds the required ACEs directly on the specified containers and the User or InetOrgPerson objects within the container.
User rights equivalent to DomainAdmins group membership are required to perform this procedure. If the authenticated user ACEs have also been removed in the locked-down environment, you must grant this account read-access ACEs on the relevant containers in the forest root domain as described in Authenticated User Permissions Are Removedor use an account that is a member of the EnterpriseAdmins group.
-
Log on to a computer joined to the domain with an account that is a member of the DomainAdmins group or that has equivalent user rights.
-
Open a command prompt and then run:
Copy Code
LcsCmd.exe /domain[:<FQDN of domain where the OUs are located>] /action:CreateLcsOuPermissions /ou:<DN name for the OU container relative to the domain root container DN> /objectType:<type of object to create Office Communications Server ACEs for – user, InetOrgPerson, contact, AppContact>
For example:
Copy Code
LcsCmd.exe /domain /action:CreateLcsOuPermissions /ou:”OU=usersOU” /objectType:user
-
In the log file, look for <Success>Execution Result at the end of each task to verify that the permissions were set, and then close the log window. Or, you can run the following command to determine whether the permissions were set:
Copy Code
LcsCmd.exe /domain[:<FQDN of domain where the OUs are located>] /action:CheckLcsOuPermissions /ou:<DN name for the OU container relative to the domain root container DN> /objectType:<type of object – user, InetOrgPerson, contact, AppContact
Set Permissions for Computer
Objects after Running Domain Preparation
In a locked-down Active Directory environment where permissions inheritance is disabled, domain preparation does not set the necessary ACEs on the containers that hold Computer objects within the domain. In this situation, you must run LcsCmd.exe with the CreateLcsOuPermissions action on each container that has computers running Office Communications Server with permissions inheritance is disabled. The /objecttypeparameter specifies the object type.
This procedure adds the required ACEs directly on the specified containers.
User rights equivalent to DomainAdmins group membership are required to perform this procedure. If the authenticated user ACEs have also been removed, you must grant this account read-access ACEs on the relevant containers in the forest root domain as described in Authenticated User Permissions Are Removedor use an account that is a member of the EnterpriseAdmins group.
-
Log on to the domain computer with an account that is a member of the DomainAdmins group or that has equivalent user rights.
-
Open a command prompt and then run:
Copy Code
LcsCmd.exe /domain[:<FQDN of domain where the computer OU is located>] /action:CreateLcsOuPermissions /ou:<DN name for the computer OU container relative to the domain root container DN> /objectType:<computer>
For example:
Copy Code
LcsCmd.exe /domain:resources.corp.woodgrovebank.com /action:CreateLcsOuPermissions /ou:”OU=computersOU” /objectType:computer
-
In the log file, look for <Success>Execution Result at the end of each task and verify that there are no errors, and then close the log. Or, you can run the following command to determine whether the permissions were set:
Copy Code
LcsCmd.exe /domain[:<FQDN of domain where the computer OU is located>] /action:CheckLcsOuPermissions /ou:<DN name for the computer OU container relative to the domain root container DN> /objectType:<computer>
Note:If you run domain preparation on the forest root domain in a locked-down Active Directory environment, be aware that Office Communications Server requires access to the Active Directory Schema and Configuration containers.
If the default authenticated user permission is removed from the Schema or the Configuration containers in AD DS, only members of the Schema Admins group or EnterpriseAdmins group are permitted to access this container. Because Setup.exe, LcsCmd.exe, and the snap-in require access to these containers, Setup and installation of the administrative tools fails unless the user running installation has user rights equivalent to Schema Admins and EnterpriseAdmins group membership.
To remedy this situation, you must grant RTCUniversalGlobalReadOnly group access to the Schema and Configuration containers.