Learn how to clear NSR peer certificates for component authentication in Dell NetWorker. This tutorial covers the nsrauth mechanism and the process of generating unique credentials for NetWorker hosts. Follow along as we demonstrate how to manage NSR Peer Information resources and troubleshoot authentication issues to ensure secure communication between NetWorker hosts.
Dell NetWorker: How to create the peer certificates used for component authentication. NetWorker hosts and daemons use the nsrauth mechanism to authenticate components and users, and to verify hosts. This is based on Transport Security Layer Protocol. The first time NetWorker nsrexecd process starts on a host.
The process creates some unique credentials for that host. These unique credentials are kept in NetWorkers NSRLA resource which is stored in the nsrexec database on every NetWorker machine, and is used to uniquely identify each NetWorker host.
When a NetWorker host communicates with other NetWorker hosts, the nsrauth process creates an NSR Peer Information resource in the nsrexec database of the target host that contains local host authentication credentials for the initiating host.
As part of the communication, the target host compares the local host authentication credentials with the information which is stored in the local in this or peer information. Then it does a comparison of that peer information and the authentication information and if the information matches an SSL connection, so, a secure connection is created between the two machines.
Because the peer information matches, if the peer information doesn’t match, then the communication is cut and the communication is dropped between the two hosts, and there is no further communication that happens.
If there is no NSR Peer resource on the target machine, then a new one will be created based on the credentials which are sent across as part of the authentication mechanism. Let’s look at a concrete example now of how this affects NetWorker backups. If we look in in NetWorker Management Console, we see a failed backup.
We can then look in the logs to see exactly which logs we need to check out to see where this backup has failed, and to look for the significant error message that might indicate a failure. Here we see an example of an error indication that happens which calls this backup to fail.
This is the sort of error indication that we can get from NetWorker that will indicate that there’s been a problem either communicating between the two hosts or authenticating between the two hosts. So it’s an example of something that can happen if the authenticate information isn’t in sync between the two NetWorker hosts.
In this case, we use the “nsradmin” command on the network machine, and we clear the peer information that corresponds to this communication. So we need to clear the peer information on both sides. Starting on the NetWorker server. “.type: NSR Peer information” and delete.
We will type Y to delete the peer information which corresponds to the btest17 machine, which is the client machine. In our communication example, when we see from the error message above. Typing n for all the other peer information which we don’t want to delete.
We’re going to do the same thing on the NetWorker client side. “nsradmin -p”. “.type: NSR Peer Information”. And we’re going to delete the peer information which corresponds to the NetWorker server in this case which is backupnw1.
In this way we have cleared the peer information on both sides of this client server communication. And we can retest the backup to confirm that communication can now happen correctly between the two machines, with NetWorker automatically creating new NSR Peer resources on both sides.
