Video Screencast Help

Authentication across multipl domains and vCenters

Created: 15 Dec 2012 • Updated: 10 Feb 2013 | 9 comments
This issue has been solved. See solution.


I have been playing with netbackup 7.5 for a few weeks and I'm trying to figure out how I can work with multiple domains and multiple vCenters from an Authentication perspective.

Multiple vCenters

We have multiple vCenters, I can see that under "Media and Device Management" I can go to Credentials, Virtual Machine Servers and add all vCenters. However, when I create a new backup job policy tyoe "VMWare". there is no option to tell the policy which vcenter to use.


Multiple Domains - Agent Based.

My understanding is that I should create a backup account for each domain example "domain1\backupsvc1", "domain2\backupsvc2" and run the netbackup client service on each box in that domain with this user. However, where do I add these accounts on my master/media servers so that these user accounts from the different domains can write backups to my media servers?



Comments 9 CommentsJump to latest comment

captain jack sparrow's picture

Just to clarify few things

If you have multiple vCenter servers spreaded across multiple domains, are you sure NBU does not asks you for which vCenter to choose?

It does explores vCenter, Datacenter , ESX, and Virtual machines hence you should be able to choose which guest to choose from which vCenter


For authentication perspective, You are good on configuring services with respective domain accounts. If all domains are member of same forest, you can have them added under local administrative group of Master server

Also do add them under credentials for respective vCenter to authenticate

Let us know if above helps

 Cheers !!!



maxsven's picture

Hi Captain Jack,


on vCenter, you are right, if I try to browse for the VM, it will let me select which vCenter.

back to the multiple domain question. the domains are not in the same forest, so adding the accounts to the local group on the master server won't work. I was wondering if there is a different way that this authentication can behandled (i.e through a broker...etc.)

captain jack sparrow's picture

If there is trust in between then yes it should work by means of authentication broker , AS THEY TRUST EACH OTHER, . But if there is no trust then i doubt it would work. (ideally without trust it would not work)

moreover does client resolves NBU and vice versa?


 Cheers !!!



RLeon's picture


You can see which vCenter credential will be used on the Clients tab. You can see it easier if you use "select manually" instead of using the Query Builder to select the VMs. This is basically what the Captain said.

As for the domains, know that unlike other backup solutions (even Backup Exec), NetBackup does not really depend on domains and domain accounts.
NetBackup primarily operates under the Local System account, which in the Windows world has the highest security access level to the system, even higher than the local administrator account.

By default, the Nbu client service on clients run under the Local System account, unless you change it to something else, such as a domain admin account. You would normally only need to change its account to give it access rights to applications. E.g., you have to do this with SQL, Exchange and Sharepoint backups.

Even then, the Master and Media Servers still do not need to be part of the client's domain/forest. All that really matters is that the Nbu client service on that client is already running a domain account that allows it access to the application data.
Once the Nbu client service has read all that it wanted to from the application, it will send this data to whoever it wants, and to whoever accepts. This "whoever" just so happens to be a Nbu Master/Media server on the network that doesn't even need to be a member in that domain, or any domains.
In a way, the Nbu client is like a... mischievous ware (with the highest credentials!). Once you let it in, it grabs all your things then send them off somewhere.

maxsven's picture

Hi Rleon,

This is starting to make a lot of sense now..

two questions for you, from a "permissions" perspective, say NTFS in the windows world, is the client in domain A in this case pushing the data master server in domain B? how will it write to the media server if it has no NTFS permissions on the media server?

the other question, are you able to point me to the netbackup doco that explain the local system account/domain account at the client end? (pretty much what you have explained above?)

RLeon's picture

The Local System Account has more privileges than a local Administrator account, which explains why NetBackup services use it as the default account.
From the perspective of a NetBackup Client Service, it is a good accout to use because the account grants all rights to the host it is responsible for backing up. I.e., so that it won't have access right problems trying to backup something, somewhere on the host.

However, sometimes you will have to change the NetBackup Client Service account to something like a domain admin account. You will find this necessary when trying to backup Application Level items such as those from AD, SQL, Exchange and Sharepoint.

That is because applications such as those have their own credential/rights requirements that are not granted by the Local System Account. The domain admin account usually has them, which is why for these applications the domain admin account is usually recommended.
In a way, you could say that the Local System Account is strictly for accessing local items, while application data are not strictly "local". Because conceptually, applications "detach" from the host on which they are running on, as separated entities inside your network.

Using the AD as an example, the NetBackup admin guide Vol1 has the following to say.
You will also find this requirement in other NetBackup application agent guides. (SQL, Exchange, etc.)

The NetBackup Client Service must be configured to log on as an account with domain privileges.
To perform granular backups and restores of the Active Directory,
the NetBackup Legacy Client Service (bpinetd) must run under the domain
administrator account on the Active Directory domain controller or ADAM server.
By default, bpinetd runs under the Local System account.


It does not matter whether the master/media server is in the same domain as the client it is trying to backup, or if the master/media is in any domain at all.
Whatever account you assigned to the NetBackup Client Service on the client should have full access rights to its host's NTFS volumes.

So now that it has all the NTFS files, what does it do? It sends them to the media server who asks.
Would that create NTFS permission problems? No, because the client is not writing directly to the NTFS volume on the media server. For all intents and purposes, the client is only sending "NetBackup data" to the media server - an Application Level activity.
Once the media server receives this "NetBackup data" - that has nothing to do with the file system or NTFS - it does whatever it wants with it, such as storing it on disk, or tape, as "Netbackup data". (Referred to as the backup images)

In the case of disk storage units, it is the media server that is writing to its host's NTFS volume, not the remote client.

It is useful to remember that NetBackup itself - including all master/media/client services on all hosts - is also an application. It also has its own Application Level "rules" and activities that are separated from the underlying hosts it is running on.

maxsven's picture

makes perfect sense... however, what happens when you are restoring BACK to the client?

This case, you need an account to have enough rights to write databack to the client, so if the client is running as a local system account in the client domain, or as a domain account that is not defined at the master/media server, how will this restore "write" be permitted?

RLeon's picture

It's just the same thing in reverse. The media server reads the data from the backup images (from the disk that it has access rights to), sends them as NetBackup data over the network to the NetBackup Client Service running on the target remote client.
The NetBackup Client Service receives the Netbackup data, and writes it to the disk it has access rights to, i.e., its own local NTFS volume.

The "un-packaged" NetBackup data just so happens to be some NTFS files with some built-in permissions, which just so happens to have came from the same client in the first place; now they are just written back in the form of a restore task.

Again, during restore the media server does not write directly to the client's file system, just as the client does not write directly to the media server's file system during a backup.