Optimizing Network-User Scanning

This section describes optional configurations that prevent Key Manager from saving redundant network- user entries to its database, and from flooding network-user directories/filesystems.

Network users with access to many hosts result in duplicate user accounts in the Key Manager Database. Furthermore, if network home directories (such as those provided by NFS) are scanned on each host, large amounts of duplicate key data is saved to the database.

The following subsections describe ways you can prevent duplicate network-user and key data from cluttering your database.

Use Script-Based Scan in Local Mode

On hosts that use script-based scans, host scans can ignore network users who have no keys on the target hosts:

• On hosts using offline scans: Run the host utility with the scan-without-nfs or scan-local option. For example:

  # /path/to/ssh-mgr-host-utility.sh scan-without-nfs > hostname-scan.txt 2>&1

• On hosts using script-based scans: Set the host setting Full scan type (full_scan_type) to Scan only locally stored keys (without-nfs).

See section Access Requests with Directory Users in PrivX Key Manager User Portal Manual for an example about handling network users by scanning all network users on only one host but still being able to execute access requests for any user on any host.

Ignoring Network Users

You can set the host setting User listing command on Unix and Linux hosts to exclude network users. However, any excluded users and their keys are entirely ignored by Key Manager.

Set up Network Groups

Network groups allow network users as endpoints for access requests (made via User Portal), while only requiring network users to be scanned on one host in the network group.

Network groups are feasible in environments where a certain group of network users, and their home directories, are identical across multiple hosts, such as those provided by NFS. Hosts in network groups must support script-based scans (described in Choosing the Best Scan Method).

Figure 6.1. Network-group setup. Scanned users are in blue.

You can set up a network group as follows:

1. Identify the hosts that constitute a network group. For example, hosts where network users and their home directories are provided by the same directory and NFS servers.

   Choose a control host that represents the network users and network home directories found in the network group. Ideally, the control host is set up in high-availability mode.

   note

   If you ever need to change the control host, the replacement control host should have:

   • The same Key Manager login credentials as the former control host.

   • The same DNS name and IP address as the former control host.

   • The same unique ID file as the former control host.

   Otherwise, changing the control host breaks audit trails and raises unnecessary alerts.

2. Create host groups for the hosts in the network group:

   • Create a host group for the network group (top network group).

   • Create a host group for the control host (control-host group). This group must be a child of the top network group.

   • Create a host group for other hosts that belong to the network group (member-host group). This group must also be a child of the top network group.

   For more information about host-group management, see Host-Group Management.

   You should now have the following host groups with the following host-group hierarchy:

   |-- top network group
   |   |-- control-host group
   |   |-- member-host group

3. Set the host-group settings as follows:

   Settings for the top network group

   • Network directory name: An arbitrary name that identifies the network directory for this network group.

   • Relocation directories: Comma-separated list of path prefixes to which authorized keys have been relocated (using the Key Manager Relocate User Keys action).

   For example, if key relocation has been performed on three member hosts, and to the following directories:

   • /root/user_keys/authorized_keys/%u

   • /root/user_keys/%u

   • /opt/ssh/%u

   Then Relocation directories could be set to:

   /root/user_keys,/opt/ssh

   • Execute jobs using a script copied to the host, instead of over interactive SSH connection: Set this to Yes to enable script-based scans, necessary for distinguishing local and network users, and for controlling the full-scan scope.

   • Update host script automatically as needed: Set to Yes to allow Key Manager to automatically upload the host utility to hosts. If set to No, you must manually upload the host utility to all hosts.

   • Host script path: The path where the host utility is on hosts. If Key Manager is allowed to upload the host utility, the path must be accessible for the management user of each host. Otherwise, you must manually upload the host utility to this path on each host.

   For more information about setting up script-based scanning, see Enabling Script-Based Scans.

   Settings for the control-host group

   • Full scan type: Set this to Scan both locally and remotely stored keys. This way Key Manager scans all network users on the control host.

   Settings for the member-host group

   • Full scan type: Set this to Scan only locally stored keys.

4. Add hosts to the network group:

   • Deploy the control host to the control-host group.

   • Deploy the other hosts of the network group to the member-host group.

5. Finally, designate the control host. To do this via the GUI, display the details panel of the control host, click in the details panel, and set Control Host to Yes.

   note

   If the Control Host setting is unavailable, scan the host, then try again after the scan job finishes.

   For instructions about setting host attributes, see Configuring Host Attributes.