Chapter 16: Domains

Home Prev	InControl 4.00.02 Administration Guide	Next

Domains Allow Configuration Object Sharing

The Global Domain always exists in a cOS Core configuration by default and this is used to share cOS Core configuration objects amongst all devices. It is often the case that a set of configurations objects need to be shared amongst a limited subset of the devices defined to InControl. In this situation, a new Domain can be defined.

	Important: Try to keep the Global Domain small
Although it may seem convenient to keep as much as possible in the global domain, this is not recommended since InControl operations such as opening configurations and deployment can become much slower. The recommended approach is to only place objects in the Global Domain or sub-domains when they absolutely have to be there. If an object is only needed in one firewall then keep it as a locally defined object unique to that firewall's configuration.

Important: Try to keep the Global Domain small

Although it may seem convenient to keep as much as possible in the global domain, this is not recommended since InControl operations such as opening configurations and deployment can become much slower.

The recommended approach is to only place objects in the Global Domain or sub-domains when they absolutely have to be there. If an object is only needed in one firewall then keep it as a locally defined object unique to that firewall's configuration.

Domains are Specific to InControl

The domain concept is only available in InControl. The domain concept is not available if using the Web Interface or the CLI to perform administration tasks.

However, it is still possible to switch to managing configurations using those other interfaces even though they were originally configured using domains.

Domains are Initially Empty

Both the Global Domain and any new, created domains have the same, default object structure. However, this structure is initially empty and must be filled with any objects that are to be shared.

Adding Domains

Adding a domain can be done in one of two ways:

Press the Create button in the Firewalls tab and choose Domain.

Alternatively, right-click the global domain in the Firewalls tab navigation tree and choose Create > Domain.

This results in a dialog being displayed so that the name of the new domain can be entered and the parent of the domain selected.

The default parent for a new domain is the Global Domain as shown below.

However, it is then possible to create further sub-domain levels. The screenshot below shows a domain called My_Subdomain defined under My_Domain which is itself defined under the global domain.

Once defined, any new domain has a set of objects which are similar to the set found in the global domain. This object set then applies only to the devices defined within that domain and takes precedence over the same objects found at higher levels. Below is the object navigation tab for My_Subdomain.

	Tip: Configuration revision numbers
	The revision number for the above tab is 0:1. This means that these configuration objects have been edited once by InControl (the initial creation) and zero times by the Web Interface or by the CLI via SSH.

The domain arrangement means that:

The objects in any domain are available to all devices within the domain, including any defined within any sub-domains.
It follows that the objects in the global domain are available to all devices.

Name Duplication

cOS Core does not allow the same object name to be used twice in a hierarchy of domains and is flagged as an error in InControl.

For example, a Service object called my_service in the global domain cannot coexist with another Service called my_service in a domain or device at a lower level.

Checking Domains Out and In

Not only is it possible to check out an individual device, it is also possible to check out any domain and apply version control to its contents.

When a domain is checked out, only the domain itself is checked out Any subdomains or firewalls within that domain are not also automatically checked out.

When the domain is checked in, any changes made to objects in the domain that are used by devices under the domain are deployed by the InControl server. In other words, the configurations affected by changes in their parent domains are automatically updated.

Editing Domain Objects Directly or Indirectly

A domain configuration can have its contents edited in the same way that a firewall configuration is edited. The domain configuration can be opened, its contents changed and those changes saved.

However, when editing a firewall configuration that contains objects inherited from a domain, it can be inconvenient to exit the firewall configuration just to open and edit the domain. In the firewall editing interface, InControl provides the ability to directly edit inherited objects without opening the parent domain. This is done by clicking the inherited object which will open a new pane to show its current value. Pressing the Edit button will allow these values to be changed. This is shown below for an inherited IP object which is being used in a firewall IP rule set.

Applying Domain Changes to Checked Out Devices

If domain changes have to be applied to a firewall that is already checked out by another InControl user then the changes are queued by the InControl server until the firewall is checked back in. At that point, the InControl will attempt to apply the queued changes.

Resolving Object Collisions

If the name of an object in the domain is the same as an object in one of the domain's child firewalls, it will not be possible to check in and deploy the firewall until this duplication is resolved. This is done with the Resolve Collision dialog which forces a choice of which duplicate to keep. The example below shows the dialog listing one collision where the object name mgmtnet is duplicated.

Such collisions could occur because of a name change or new object creation in a firewall or a domain.

	Note: Some upgrades require extra measures for collisions
In some cases of upgrading InControl, the object collision resolution mechanism described above will be unable to deal with certain collision problems where a domain object name is the same as the name on a firewall. This can occur specifically when the two colliding objects are at different hierarchy levels in the domain and firewall. For example, one object is in an address book folder in the domain but is at the top level of the address book on the firewall. A symptom of this is alert messages continue to appear, one alert for the collision in the domain and a separate alert for the collision in the firewall. In this case, the actions to take are as follows: Change the object name manually on the firewall. This will remove the collision alert for the firewall but not the alert for the domain. Edit the colliding domain object name but do not change it or enter OK. Instead, press the Cancel button to leave editing. This will remove the remaining alert for the domain.

Note: Some upgrades require extra measures for collisions

In some cases of upgrading InControl, the object collision resolution mechanism described above will be unable to deal with certain collision problems where a domain object name is the same as the name on a firewall. This can occur specifically when the two colliding objects are at different hierarchy levels in the domain and firewall. For example, one object is in an address book folder in the domain but is at the top level of the address book on the firewall. A symptom of this is alert messages continue to appear, one alert for the collision in the domain and a separate alert for the collision in the firewall.

In this case, the actions to take are as follows:

Change the object name manually on the firewall. This will remove the collision alert for the firewall but not the alert for the domain.
Edit the colliding domain object name but do not change it or enter OK. Instead, press the Cancel button to leave editing. This will remove the remaining alert for the domain.

Unlike firewalls, imported domains do not also require a cOS Core upgrade procedure to be applied as the second step. Domain objects can therefore be accessed and edited directly after the import. However, any objects from the domain that are used in an imported firewall get automatically duplicated in the child firewall configuration. After the firewall cOS Core version is upgraded but before it can be deployed, the Resolve Collision dialog described above will appear in order to choose which duplicate to keep.

Viewing Inherited Objects in Configurations

When a Configure tab is opened for editing a particular firewalls configuration, objects that are inherited from InControl domains are not, by default, shown. However, they can be viewed by pressing the Show Inherited Objects button in the tab's toolbar ribbon.

When enabled, the configuration display will include inherited objects. The screenshot below shows an example cOS Core address book on a given firewall where the inherited domain folder called MyDomainFolder is displayed along with the inherited objects that the folder contains (note that all inherited rows are in italics).

Like non-inherited objects, it is possible to open an edit pane for an inherited object, but this will provide a link to edit the parent domain instead of allowing the object to be changed directly.

Flagging Unused Domain Objects

By default, if a domain object is edited and it is not used in any firewall configurations, a warning message is displayed.

One reason for this warning is the 8.nn import procedure mentioned above. After an 8.nn datasource is imported but before any devices in the datasource are upgraded, imported domain objects can be edited but they will not appear to be used yet in the child firewalls. The warning is a reminder of this.

This warning message can be disabled by clicking the checkbox in the message or clicking a checkbox in the Client Settings dialog (see Chapter 5, The Client Interface).

Domains and the Local Firewall Configurations

It is important to understand that domains are logical constructs that only exist within InControl and their purpose is to manage objects common to more than one configuration. However, at the local firewall level, individual configurations themselves are not aware that a configuration object may be in a domain, although it should be noted that such domain objects will be marked as read-only in the firewall.

The CLI is only used to directly manipulate objects in a single configuration on a single firewall and therefore cannot be used to manipulate domains. In addition, if a domain object is not used by a particular firewall within that domain, then the object will not exist in the firewall's configuration and cannot be manipulated using the CLI.

Deleting Firewalls from a Domain

When a firewall is deleted from a domain, the objects in the firewall's configuration which were inherited from the domain will remain in the firewall's configuration and will function as before. However, by default, these objects will remain as read-only and therefore cannot be altered or deleted using a local firewall interface.

Deleting such read-only objects is discussed in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/336137021