Centralized Management Group

A centralized management group (CMG) is a group of Screens that can be deployed throughout your organization. A CMG is managed with a set of configuration objects through an Administration Station or several Administration Stations.

• Primary Screen - Policies and all configuration objects reside on a specific Screen called the CMG's primary Screen. The centralized management group's primary Screen manages itself, as well as the centralized management group's secondary Screens. It is configured with all the common objects and rules for all the Screens in the centralized management group. The primary Screen can be administered locally or from a remote Administration Station, or both. Each primary Screen can nominally support up to 20 secondary Screens, although there is no hard limit. It is limited only by performance.

• Secondary Screens - The default configuration on the secondary is only the initial setup policy that was created during installation of the software so that the primary Screen could communicate with it. You cannot directly edit a policy on a secondary Screen, once that Screen has joined a CMG.

Logging

The logs are stored in a circular buffer on each Screen. You can download them to the Administration Station for analysis, archival, etc. Although no central logging mechanism exists for a global view of the logs on the individual Screens in a centralized management group, the secondary Screens make some basic emergency administration possible. For example, if the primary Screen is down for service, you can select a specific Screen and view its log.

If you have configured your centralized management group with multiple Screens and the Screens' names differ from the host name, be sure to use the correct host name if you want to view the information for that Screen. This name must match the host name in the /etc/hosts file.

Common Objects Used in Centralized Administration

Centralized administration requires secure communication among the Screens. This information is contained in the screen object. On the primary Screen, screen objects must exist for all the Screens. On each secondary Screen, Screen objects must exist for that secondary and the primary Screen.

Once you successfully activate a configuration from the primary Screen, it will replace objects on the secondary. If these new objects are incorrect, you may not be able to activate additional configurations centrally. If so, you can manually activate an old configuration on the secondary, fix the errors on the primary, and then activate the configuration again.

Creating Common Objects and Policies for Multiple Screens

When creating common objects and policies for multiple Screens, the object or policy rule by default applies to all Screens controlled by that primary Screen. You can restrict an object or rule to a single Screen by specifying its name in the Screen field in objects and rules.

While you could restrict all your objects and rules to a single Screen, the power of centralized administration comes when you can use common objects and rules to apply to multiple Screens.

Most common objects are applicable to all Screens, but sometimes an object such as an address object called Inside may be different on different Screens. In this case, make the names unique by adding a suffix or prefix to the name (for example Inside-East and Inside-West) rather than using the Screen option to restrict the scope of the object.

Interface Objects

You generally need to limit interface objects to a specific Screen because the names must be the name of the network interface on that system. Because the names of these objects must match those of the Solaris network devices they configure, use the Screen entry in the interface object to restrict that object to a single Screen.

Policies

Policies for a centralized management group are the same as any other policies and consist of a set rules that control the behavior of the centralized management group. You set up rules for the entire centralized management group of Screens using the administration GUI.

Policies and all configuration objects reside on the primary Screen. The primary Screen pushes the rules that apply to the remote Screens out to the Secondary Screens when the policy is activated. Each rule in the policy can be applied to all Screens or just one.

The policy is sent over an encrypted connection to the secondary Screens. The policy is then complied locally on each secondary Screen. The compiled policy is stored on the primary Screen.

The primary Screen "pings" the secondary Screens before it activates a policy and sends the administrator a message if there is a problem. The primary can push a policy to the other secondary Screens in a centralized management group even if one of the secondary Screens doesn't respond to the ping. A policy that is being pushed out to the secondary Screens is activated in parallel on all the secondary Screens. The primary Screen does not have to wait for each secondary Screen to compile the policy separately before sending it out to the next secondary Screen.

You cannot edit an activated policy on the primary Screen. You also cannot directly edit a policy from a Secondary Screen.