Each OU in the OU hierarchy has associated security groups.

Security groups permissions are inherited down the chain in the OU hierarchy. For example, users added to a security group for a Facility OU have the privileges of that security group for all Instance OUs contained in that Facility OU.

Each OU has the following security groups:

• Config Security Group

• Setup Security Group

In addition to the preceding list, Instance OUs also contain the Service Security Group.

Warning

Microsoft limits the number of cascading groups in the OU hierarchy. For more information, see Microsoft Active Directory Maximum Limits - Scalability article at http:/​/​technet.microsoft.com/​en-us/​library/​active-directory-maximum-limits-scalability(v=WS.10).aspx.

Warning

Users who are local administrators for the server automatically can perform configuration tasks. Therefore, only users who are members of the Setup Security Group must be local administrators.

A security group is a collection of domain users to whom you grant a set of permissions to perform tasks with system software.

For each security group, you add domain users, who are granted privileges to the functions controlled by that security group. Users are given membership in the security groups to enable permission to the application. You can create these users in other OUs in this domain, or in any trusted domain.

Note	The user who creates the Cisco Root OU automatically becomes a member of the Setup Security Group for the Cisco Root OU. In effect, this user is granted privileges to all Unified ICM tasks in the domain.

Security Groups:

• Similar groups at each level of the hierarchy allow users to be granted permission to multiple Instances.

• Are nested so that:

  • A similar group from the Parent OU is a member of each group.

  Figure 2. Security Group Nesting
  
  

• Use AD Domain Local Security Groups.

The function names of the security groups are Setup, Config, and Service. Group names must be unique in AD. Combining the names of levels of the hierarchy with the function name helps allow a unique name to be generated.

Names of the security groups created by OUs at various levels include:

• Root: Cisco_ICM_<function>

• Facility: <Facility>_<function>

• Instance: <Facility>_<Instance>_<function>

NetBIOS names truncate if needed and random digits are appended.

Security Group Members:

• You can add any user from a trusted domain to a group.

• Group nesting allows for groups outside the OU hierarchy.

The Config Security Group controls access privileges to the common Unified ICM configuration tasks.

Domain users whom you added to a Config Security Group have access to the following applications at that point in the OU hierarchy and below:

• Configuration Manager

  Note	Config users can only perform AD operations using the User List tool (provided they have AD permissions to do so). Members of the Setup Group automatically have the permissions required to use the User List tool.

• Script Editor

• Internet Script Editor

• Database Access

  • SQL Permission granted to the Configuration group instead of to individual users. Database access is given explicitly to the Instance level group. Group nesting gives this access to Facility and Root configuration members.

  Added to the GeoTelGroup role on the Administration & Data Server DB.

  Note	For Administration & Data Server DBs only. Not for Logger DBs and HDSs.

The Setup Security Group controls rights to run:

• Installation and Setup Tools

• Configuration Manager

Users who are members of the Setup Security Group can:

• Install instances and software components.

• Add users to security groups.

• Create service accounts.

• Manage OUs, groups, users, and permissions.

Note	The Setup Security Group is automatically made a member of the Config for that Unified ICM instance.

The Setup group at each level is given AD permissions to the parent OU.

Figure 3. Setup Security Group permissions

For more information see the chapter Service Account Manager.

OUs are nested as described in the preceeding section, with the Root OU containing Facility OUs, which contain Instance OUs. For Unified ICM, the Cisco Root OU is the "Cisco_ICM" OU. As OUs have associated security groups, the nesting of OUs allow the nesting of access rights. Members of a security group have all the access rights granted to that same security group at lower levels in the hierarchy.

Examples:

If you make a user a member the Root Setup security group (see Root Setup Security Group Member Permissions/Access Rights following), that user has the following permissions/access rights:

• Permissions/access rights in the Root Setup security group.

  This also grants permissions/access rights for this user in the:

  • Facility Setup group

  • Instance Setup group

• Permissions/access rights in the Root Config security group.

  This also grants permissions/access rights for this user in the:

  • Facility Config group

  • Instance Config group

Figure 4. Root Setup Security Group Member Permissions/Access Rights

Making a user a member of the Root Config security group grants permissions/access rights in that security group as well as the Facility and the Instance Config security groups.

Figure 5. Root Config Security Group Member Permissions/Access Rights

Members of a Facility security group have all the permissions/access rights granted to Instance OUs nested within that Facility. However, members of those Instance OUs security groups do not necessarily have the permissions/access rights granted to their containing Facility OU.

A member of the Instance Setup security group is granted permissions/access rights only to the Instance level security groups (Setup and Config).

Figure 6. Facility/Instance Setup Security Group Member Permissions/Access Rights

In the following illustrations, a member the Facility Config security group has permissions/access rights to that security group and the Instance Config security group. However, a member of the Instance Config security group only has permissions/access rights to that security group.

Figure 7. Facility/Instance Config Security Group Member Permissions/Access Rights

This hierarchy allows you to define security with maximum flexibility. For example, you can grant permissions/access rights at the Facility OU level, so those users have access to a set of instances. You can then define permissions for instance administrators at the Instance OU level, and those users would not have access to the other instances.

Note	You cannot move an Instance from one Facility to another.

The Service Security Group is a security group generated automatically for Instance OUs. It exists at the Instance level only. The Service Security Group controls access between the system software components.

Note	The Service Security Group is not exposed to users for the Domain Manager. You do not have to perform any tasks related to it.

The group has a SQL login and is a member of the GeoTelAdmin role on the following databases:

• Logger SideA DB

• Logger SideB DB

• Administration & Data Server DB

• HDS

• Outbound Option DB

The Service Account Manager creates Service Logon Accounts in the Instance OU for the following services:

• Logger

• Distributor

• Tomcat

Service Logon Accounts

• You do not have to randomly generate passwords. You can provide passwords and save them in AD or on the local machine, or save them on both.

• Passwords are 64 characters long and include:

  • English upper case characters (A..Z)

  • English lower case characters (a..z)

  • Base 10 digits (0..9)

  • Non-alphanumeric characters (! @ # % ^ & * ( ) [ ] { } ` ~ - + ? . , ; : ' < >)

• Are added to local Administrators group.

• Are given rights to Logon as a Service.

• DNS names are comprised of: <Instance component machine>

  Possible components are the:

  • Distributor (NetBIOS name is Distrib)

  • LoggerA

  • LoggerB

  • Tomcat

• NetBIOS names are comprised of: <instance component-#####>

  where ##### is used to represent digits added to ensure the NetBIOS name is comprised of the full 20 characters allowed to help ensure, but not guarantee its uniqueness. The list of possible components is the same as those for the DNS names except as indicated above.