Registry Name Service and Database Synchronization

Endpoint Privilege Management for Unix and Linux has historically required manual or customer-developed processes to copy policy from one policy server to another to make sure that failover and load balancing were addressed. Endpoint Privilege Management for Unix and Linux has historically required manual or customer-developed processes to copy encryption key files from one host to another to ensure no interruption in communication between its components. Hostnames or IP addresses were hard-coded into the settings file on every client and server to detail which servers provided services for each client. Although the use of DNS could mitigate some of these issues, day-to-day maintenance of these settings and policy configuration across multiple hosts remains arduous and open to user error.

As a solution to these problems, a flexible and powerful Registry Name Service incorporating Database Synchronization has been developed and integrated into Endpoint Privilege Management to provide advanced failover and load balancing automatically, centralized role based management, and the ability to form groups of clients that share configuration or policy based on role or business organization.

Service Groups and Planning

The Registry Name Service provides the product with a method of addressing and locating other components of the BeyondInsight product within the enterprise. Each category of service, including Endpoint Privilege Management for Unix and Linux Policy Authorization, Logging Services, and the Registry Name Service itself, have distinct groups which are comprised of a single primary server and zero or more secondary servers.

The primary host accepts all the configuration changes within that specified Service Group and automatically synchronizes these changes to the secondary service hosts. Other functions, such as authorization or data retrieval, are available from any of the secondary hosts within the Service Group, providing effective load balancing for clients.

Each host that makes up the Service Group is defined in the Registry Name Service database, including primary and secondary servers and clients. This allows every host within the BeyondInsight enterprise to identify every machine that will make up its Service Group. This also allows a more fine-grained control of licenses within the product.

When upgrading or installing a new BeyondInsight enterprise and incorporating the Registry Name Service, the first server installed becomes the Primary Registry Name Server. This creates a repository with the default groups of registry_name_service, dflt_pbpolicy_service, dflt_log_service, dflt_sudopolicy_service, dflt_logarch_service, and dflt_fim_service.

Once the primary Registry Name Sever has been installed, the administrator is free to define more Service Groups to allow multiple areas of the enterprise to work and be administered autonomously. Then, for each Service Group, the administrator can start installing the primary servers, secondary servers, and finally the clients. As soon as a host is added to a Service Group and its role within the group is defined, it will be available to use. Secondary servers are provided with configuration from the primary, and clients are aware of service providers immediately.

There can only be one Registry Name Service group.

Hosts are members of one instance of each type of Service Group that is available. For example, a typical BeyondInsight policy client is a member of a single BeyondInsight Policy Service Group and a single Endpoint Privilege Management Log Services Group. Within each of these groups the primary and secondary servers provide the load balancing and failover required by mission-critical environments.

Command Line Configuration

The configuration of the Registry Name Service is provided through the enhanced pbdbutil command line utility. New categories have been added.

--svc is used on the Primary Registry Name Server to configure the Registry Name Service Groups:

Usage pbdbutil --svc [<options>] [ <file> <file> ...]
-u '{ "svcgname" : "name", params... }' Create/Update Registry Name Service Group.
-u '{ "cn" : "hname", params... }' Create/Update Registry Name Service Host.
-u '{ "cn" : "hname", "uuid" : "", params... }' Create/Update external Host in Registry Name Service.
              [--bycn hname] Specify existing common name to update (change to the cn and uuid specified in -u, optional)
-u '{ "svcgname" : "name", "cn" : "hname", params... }' Add/Update Registry Name Service Host to Service Group.
-g '{ "svcgname" : "name" }' Retrieve Registry Name Service Group information.
-g '{ "primary" : "name" }' Lookup the Primary Server within the Registry Name Service Group.
-g '{ "cn" : "name" }' Retrieve Registry Name Service Host information by host common name.
-g '{ "uuid" : "name" }' Retrieve Registry Name Service Host information by UUID.
-d '{ "svcgname" : "name" }' Delete Registry Name Service Group.
-d '{ "svcgname" : "name", "cn" : "name" }'

Remove a host from Registry Name Service Group.

After deleting a server from registry name service group (registry_name_service), execute the following command to force a service cache update on all servers and clients.

# pbadmin --scache -R --all

-d '{ "cn" : "name" }' Delete Registry Name Service Host by host common name.
     [--remove] Remove the Registry Name Service Host completely from the database (optional) .
-z <oldgrp> <newgrp> Rename Registry Name Service Group.
-l [<wildcard(s)>] List all the Registry Name Service Groups that match wildcards.
    -l Add an extra -l to list Servers in the Registry Name Service Groups.
        -l Add a third -l to list all hosts in the Registry Name Service Groups.
-L [<wildcard(s)>] List all the Hosts that match wildcards.
    -L Add an extra -L to list Service Group membership and role.
-p <svcgrp> <host>

Promote host to Primary Service within the specified Registry Name Service Group.

After promoting a server in registry name service group (registry_name_service), execute the following command to force a service cache update on all servers and clients.

# pbadmin --scache -R --all

-N [[<cn> [<port>]] Create and initialize Primary Registry Name Service database.
-n Create new Registry Name Service database.

 

--scache is used on all hosts that are subscribed to the Registry Name Service and enables the interrogation of the local host Registry Name Service cache:

Usage pbdbutil --scache [<options>] [ <file> <file> ...]
--cn Retrieve Common Name from the Registry Name Service.
-w Retrieve my Registry Name Service information.
-l List all the locally cached Registry Name Service entries.
-s <[-|+]attribute> Sort the list of records by attribute name (ascending/descending).
-R

Refresh the local Registry Name Service cache.

    --all

Refresh all hosts registered to Registry Name service using REST services.

Refreshing all host's service cache database is recommended after making changes in registry name service group.

    --host[s] <hostname1> [<hostname2>... <hostnameN>] Refresh on listed hosts using REST services.
-N { param }

Create and initialize the Primary Registry Name cache database where the { param } argument is formatted JSON with parameters:

  • "hostname" : "host1": Hostname of the Registry Manager REST service.
  • "port" : 24351: Port of the Registry Manager REST service.
  • "appid" : "appid": App ID of the Registry Manager REST service.
  • "appkey" : "xxx-xxx-xxx": App key of the Registry Manager REST service.
-m <msg> Specify message (required when change management enabled).

 

--dbsync provides information regarding the status of Database Synchronization on primary servers:

Usage pbdbutil --dbsync [<options>] [ <file> <file> ...]
-l List Database Synchronization history.
-l [<dbfile(s)>]

List outstanding Database Synchronization entries.

-c <dbfile(s)> Clear the outstanding synchronization entries from database.
-R <svc> [<cn>] Resynchronize database for specified service. Starting with v10.3.0, issuing a pbdbutil --dbsync -R initiates a database synchronization immediately, instead of waiting for the next dbsyncrefresh time (as it was done prior to 10.3.0).
    --force Force synchronize the cfg files for the specified service.
-A <svcgname> <...> Set databases in Service Group(s) as being automatically synchronized.
-X <svcgname> <...> Unset databases in Service Group(s) as being automatically synchronized.