NetBackup™ Security and Encryption Guide

Verifying primary server settings

Running bpnbat -whoami and specifying the computer credentials, tells in what domain a host is registered and the name of the computer the certificate represents.

  bpnbat -whoami -cf 
    "install_path\netbackup\var\vxss\credentials\
   primary.company.com
    "Name: primary.company.com
   Domain: NBU_Machines@primary.company.com
   Issued by: /CN=broker/OU=root@primary.company.com/O=vx
   Expiry Date: Oct 31 20:17:51 2007 GMT
   Authentication method: Veritas Private Security
   Operation completed successfully.

If the domain listed is not NBU_Machines@primary.company.com, consider running bpnbat -addmachine for the name in question (primary). The command is run on the computer that serves the NBU_Machines domain (primary).

Then, on the computer where you want to place the credentials, run: bpnbat -loginmachine

Establishing root credentials

If you have problems setting up either the authentication server or authorization server, and the application complains about your credentials as root: ensure that the $HOME environmental variable is correct for root.

Use the following command to detect the current value:

echo $HOME

This value should agree with root's home directory, which can be typically found in the /etc/passwd file.

Note that when switching to root, you may need to use:

su -

instead of only su to correctly condition the root environment variables.

Expired credentials message

If your credential has expired or is incorrect, you may receive the following message while running a bpnbaz or bpnbat command:

Supplied credential is expired or incorrect. Please
reauthenticate and try again.

Run bpnbat -Login to update an expired credential.

Useful debug logs

The following logs are useful to debug NetBackup Access Control:

On the primary: admin, bpcd, bprd, bpdbm, bpjobd, bpsched

On the client: admin, bpcd

Access control: nbatd, nbazd.

See the NetBackup Troubleshooting Guide for instructions on proper logging.

Where credentials are stored

The NetBackup Authentication and Authorization credentials are stored in the following directories:

UNIX:

User credentials: $HOME/.vxss

Computer credentials: /usr/openv/var/vxss/credentials/

Windows:

<user_home_dir>\Application Data\VERITAS\VSS

How system time affects access control

Credentials have a birth time and death time. Computers with large discrepancies in system clock time view credentials as being created in the future or prematurely expired. Consider synchronizing system time if you have trouble communicating between systems.

NetBackup Authentication and Authorization ports

The NetBackup Authentication and Authorization daemon services use ports 13783 and 13722 for back-level media server and clients. The services use PBX connections.

You can verify that the processes are listening with the following commands:

Authentication:

UNIX

netstat -an | grep 13783

Windows

netstat -a -n | find "13783"

Authorization:

UNIX

netstat -an | grep 13722

Windows

netstat -a -n | find "13722"

Stopping NetBackup Authentication and Authorization daemons for Shared Services

When the NetBackup Authentication and Authorization services are stopped, stop authorization first, then stop authentication.

UNIX -Use the following commands.

To stop authorization use the term signal as shown in the example:

   # ps -fed |grep nbazd
     root 17018     1 4 08:47:35 ?     0:01 ./nbazd
     root 17019 16011 0 08:47:39 pts/2 0:00 grep nbazd
    # kill 17018

To stop authentication use the term signal as shown in the example:

   # ps -fed |grep nbatd
     root 16018     1 4 08:47:35 ?     0:01 ./nbatd
     root 16019 16011 0 08:47:39 pts/2 0:00 grep nbatd
    # kill 16018

Windows

Use the Services utility that Windows provides, since these services do not appear in the NetBackup Activity Monitor.

If you lock yourself out of NetBackup

You can lock yourself out of the NetBackup Administration Console if access control is incorrectly configured.

If this lockout occurs, use vi to read the bp.conf entries (UNIX) or regedit (Windows) to view the Windows registry in the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\NetBackup\
CurrentVersion\config

You can look to see if the following entries are set correctly: AUTHORIZATION_SERVICE, AUTHENTICATION_DOMAIN, and USE_VXSS.

The administrator may not want to use NetBackup Access Control or does not have the authorization libraries installed. Make certain that the USE_VXSS entry is set to Prohibited, or is deleted entirely.

Backups of storage units on media servers might not work in an NBAC environment

The host name of a system in NetBackup domain (primary server, media server, or client) and host name that is specified in the bp.conf file should be the same.

Using the nbac_cron utility

Use the nbac_cron.exe utility to create identities under which to run cron or at jobs.

For more information about the nbac_cron utility:

See About the nbac_cron utility.

nbac_cron.exe is found in the following location:

UNIX -/opt/openv/netbackup/bin/goodies/nbac_cron

Windows -install_path\netbackup\bin\goodies\nbac_cron.exe

For detailed information about using the nbac_cron utility:

See Using the nbac_cron utility.

Enabling NBAC after a recovery on Windows

Use the following procedure to manually enable NBAC after a recovery on Windows.

In cluster installations the setupmaster might fail

A known issue exists in the case of cluster installations, where the configuration file is on a shared disk, the setupmaster might fail.

Known issue on a cluster if shared security services (vxatd or vxazd) are clustered along with the primary server

A known issue exists on a cluster if shared security services (vxatd or vxazd) are clustered along with the primary server. When executing the bpnbaz -SetupMaster command and setting up security (NBAC), freeze the shared security services service groups persistently where applicable or offline the services (but make sure their shared disk is online), and run the setupmaster command.

Known issue in a clustered primary server upgrade with NBAC, that all the AUTHENTICATION_DOMAIN entries in thebp.conf file are updated with the primary server virtual name as the authentication broker

A known issue exists where in a clustered primary server upgrade with NBAC, all the AUTHENTICATION_DOMAIN entries in thebp.conf file are updated with the primary server virtual name as the authentication broker. If any domain entry is present that refers to a different authentication broker other than the primary server (and the primary server does not service that domain), that entry needs to be manually removed from the bp.conf file.

Known issue relating to access control failures and short and long host names

A known issue exists that includes failures with respect to access control. Determine if the short and long host names are properly resolvable and are resolving to the same IP address.

Known issue in a cluster upgrade with NBAC when the broker profile has ClusterName set to the virtual name of AT

A known issue exists in a cluster upgrade with NBAC when the broker profile has ClusterName set to the virtual name of AT. This is migrated as-is to the embedded broker. The embedded broker has UseClusterNameAsBrokerName set to 1 in its profile. When a request is sent for broker domain maps, it uses the virtual name of the shared AT as the broker name. The bpnbaz -GetDomainInfosFromAuthBroker returns none. In upgrades, the bp.conf file is updated to have the NetBackup virtual name.

Known issue of multiple instances of bpcd causing a possible error

A known issue exists where the bpnbaz -SetupMedia command, bprd uses the AT_LOGINMACHINE_RQST protocol to talk with bpcd on the destination box. A new instance of bpcd is spawned. After the command completes it tries to free a char array as a regular pointer possibly causing bpcd to core dump on the client side. Functionality should not be lost as this bpcd instance is only created temporarily and exits normally. The parent bpcd is unaffected.

Known issue with clusters using shared AT with configuration files on the shared drive

A known issue exists with clusters that use a shared AT with configuration files on the shared drive. Unhooking shared services only works on the node where this shared drive is accessible. Unhook fails on the remaining nodes. The implication of this is that while doing a bpnbaz -SetupMaster to manage remote broker parts fail. You will have to manually configure passive nodes. Run bpnbaz -SetupMedia for each passive node.

Known issue relating to database utilities supporting NBAZDB

A known issue exists in which some database utilities support and other database utilities do not.

The following database utilities support NBAZDB: nbdb_backup, nbdb_move, nbdb_ping, nbdb_restore, nbdb_unload, and nbdb_admin.

The dbadm utility does not support NBAZDB.