Commvault Component outside an Active Directory Domain

  • 14 December 2021
  • 9 replies

Userlevel 2
Badge +5


I wanted to check what people’s thoughts were about keeping the Commvault components outside of the Active Directory Domain to reduce the risks of being compromised in case of a security breach, e.g. compromised AD Domain Admin credentials. 

I’ve had some customers ask me about this and wanted to check with the community.



9 replies

Userlevel 7
Badge +23

Interesting question, and curious to see what others think.

Would these be communicated with via IP then, or just names off the AD list?

A point to consider is that there are so many ransomware protection features within CV, that it might be more trouble than it’s worth, unless the customers are making this change beyond CV.

Badge +1

Hello Jeremy !

We have been running some of our CommCell environments on Windows WorkGroup servers separated from our Active Directory for that reason for a couple of years, and it works fine.

The main challenge is OS maintenance for the servers, but we have found that using SaltStack to maintain the OS is a good solution for this.

The other issue we have found is when you need to use service users for forinstance SharePoint AccessPoint servers thats an issue because Service users does not really exist on WorkGroup servers.

A better solution is possibly to create a separated Active Directory to be used only for your backup environment. Then you will have all the features and tools which comes with AD, and you can maintain an air-gap between the two AD’s.



Kjell Erik Furnes

Userlevel 2
Badge +5

Hi @Kjell Erik Furnes

Thanks. That’s really good feedback. I’ll keep that in mind!

@Mike Struening: I will definitely let them know Commvault has several ransomware protection features in place, so they shouldn’t worry too much;


Userlevel 7
Badge +23

This should help with that conversation.  It’s an article I put together that goes over quick easy features you can enable to further protect against ransomware:

Getting those implemented are HUGE helps!!


I’ve been looking into this as well. Having suffered a ransomware attack with compromised domain admins makes we want to separate them as much as possible. (our enviro isn’t large so a little extra OS maintenance is worth it)


We will be doing this in the New Year as part of ransomware protection.


As far as I can see as long as name resolution for client comms is working and the Commserve can still utilise the domain accounts needed to access things like Exchange/Vmware/AD, the management servers do not need to be in an AD domain.

Userlevel 4
Badge +7

My concern with standalone (non-AD) servers is the additional management.  Are you going manage policies for password complexity, lockout rules, firewall settings, disabling removable media, disabling protocols, etc. on a per server basis?  The more independent servers you need to manage, the greater the risk of some critical security settings being missed.

Someone suggested using a separate domain for the CV environment.  This alleviates much of my concern with using standalone servers.  Setup your policies in only two places and you’re good; and you could even lockdown your backup environment even tighter.

Either way, access to the CV app/data is more critical.  Rebuilding a CS or your MAs is a pretty trivial task, but the data being managed is irreplaceable.  Pick a model which you’re comfortable with managing, and then make sure you’re following all of the best practice guidelines for securing access to your CV environment, creating 3-2-1 copies and using ransomware protection and immutable storage options where feasible and appropriate.



Howdo.  Yes I can see your point and we are addressing the other parts too.   AD is just so hackable though, even if in its own domain the management server would be more vulnerable.


Our Media Agents and Libraries are not domain joined.  The Commcell is.  Definitely a smart move.