User access to chat rooms is managed by both scope and membership; you can use scope to limit which users are eligible to be added as members of a chat room, but users must be members of a chat room to be able to post and read messages.
The scope of a category determines which users can be made members of the category and of the chat rooms it contains. When you install Group Chat, the root category is created with a scope equal to the entire domain in Active Directory Domain Services (AD DS). A subcategory can have a scope that is different from that of its parent category (if the settings of the parent category allow it). However, the subcategory can never have a broader scope than its parent; it can only narrow the parent category’s scope or retain the identical scope. Therefore, as you go down the category tree, scope is always broadest at the root category. It either narrows or stays the same as you go further down each branch.
Chat rooms operate under the rules of scope, but you set scope only on the category level. A chat room always inherits the scope of its parent category.
Active Directory Domain Services and Group Chat
Office Communications Server Group Chat relies on Active Directory Domain Services for the pool of internal users that are to use group chat. After you install Group Chat, you add domains of users and user groups to the root category scope. You can then add these users and groups to the scope and membership of your categories and chat rooms.
You can also enable federated users to access chat rooms. Because federated users are not defined in Active Directory Domain Services, you must explicitly provision federated users by using the Group Chat Administration Tool. For details about federated users, see Setting Scope for the Root Category.
How Category Membership Works
The scope of a category specifies all the users and groups who can be members of a chat room in that category.
Categories can also have a members list list. Defining a members list for a category has the following benefits:
- All chat rooms (and subcategories) of this category inherit the
members list from the parent category, unless the chat room manager
chooses to override it. This way, if you create many chat rooms in
a category, you don’t have to define membership for each one.
- A user who is a member of a category can create new chat rooms
within that category. This feature can also be disabled at the
category level if the administrator wants to restrict the creation
of new chat rooms in that category.
The scope of the root category must include all users who will use any chat room in your organization. Federated users who are to have access to any chat rooms must also be included in the root category scope.
If you will be allowing any access to federated users, we recommend that you first create two subcategories under the root category: one for chat rooms that will be available to all users, including federated users, and the other for all chat rooms that will be restricted to your organization’s employees. Then in the top-level subcategory for the chat rooms restricted to your employees, narrow the scope so that federated users are not listed.
In the top-level subcategory for chat rooms that will be open to federated users, you may want to restrict file transfers.
Within each of these two main branches, create further levels of categories according to your organization’s structure and needs. As you do this, we recommend that you leave the scope as broad as possible in each category level, only restricting scope when it is necessary for security. This way, if you need to provide additional access to a chat room, you can add members to the channel instead of adjusting the scope, which can affect other chat rooms.
Narrowing Scope to User Groups
When you add a domain to the root category scope, the user groups whose group objects are contained in that domain are made available to you to specify as members of categories and chat rooms on the server.
However, these groups are not automatically made available to you for the purpose of defining scope. The reason for this restriction is that Group Chat enforces a rule that scope can only be narrowed by subcategories. If a subcategory were permitted to define its scope with a user group that is not explicitly named on the parent category's scope, this rule would be violated. The violation occurs because the membership list of a user group is not constrained to the scope list of the parent category. The only way to ensure that all members of a user group are in scope on the parent category is to add the user group to the scope of the parent category explicitly. For this reason, it is recommended that you use Active Directory containers such as domains and organizational units for defining scope as a general rule. If it is necessary to use a user group for the purpose of defining scope, you must add the user group the scope of the root category, as well as all subcategories that are in the path.
Groups with Users from Multiple Domains
Only members of domains to which you specifically grant access can join chat rooms. Domains that you add to the scope of a category can contain user groups that include members from other domains. If you add one of these groups to the members list of a category or channel, and not all the domains that contain the group’s members are in the scope of the category, only the members whose domain is in the scope have access to the chat room.
Example of Using Scope for Ethical Walls
An ethical wall is a construct that separates two groups within one company from communicating with one another. The purpose of the ethical wall is to maintain ethical standards and avoid conflicts of interest. Ethical walls are used in several types of industries, including financial services industries. For example, in a large investment company, employees in the investment advisory group should be separated from those in the mergers group, so that there is no appearance of insider trading using knowledge of upcoming mergers before they are announced.