Running Veeam Collector in an Untrusted Domain

[jeremy.hagan]

Hi,

I am preparing to upgrade my Veeam MP installation from 6.5 to 8.0. Our current architecture has all Veeam components installed on a dedicated server in 3 environments. One where the management server is and two untrusted domains managed through SCOM gateways and certificates.

Since we need to move the Veeam VE service to the SCOM MS, then the service account that the collector runs under needs authenticated access to this server. According to this post:
post123545.html?hilit=untrusted%20domain#p123545

The solution is to run the Veeam Collector under a local Windows account (not an AD account) and to synchronise the user name and password across all collectors and the SCOM MS server. Is this still the supported solution for version 8?

Regards,
Jeremy.

[sergey.g]

Hi Jeremy,

Wait, but how does it work right now? If you collectors in the untrusted environment, they already should have non-domain service accounts, right? Could you just provide more details about your architecture?

Generally, such a configuration that you mentioned should work. However, there could be circumstances (AD policies, Firewalls) when it doesn't. For such cases there is another workaround - install VES on each gateway server. This solution indroduces some downsides, but it works regardless of AD policies and doesn't require any network communications besides SCOM-related.

I guess if you provide more invormation about current architecture we can tell more.
Thanks.

[jeremy.hagan]

Hi,

I've had more of a think about it and think I have a solution, but your email above gives me another option. Here is what I was thinking:

Current (Veeam 6.5) Architecture
SCOM Management Server in One domain. Dedicated machine with Veeam Collector, UI and VE co-homed and connected to vCenter in this domain. Then there is a second machine which is just a collector. All service accounts are domain accounts. 1 account each for VE, Collector and vCenter access account. Each made a member of the local Veeam users group on the Veeam collector.

SCOM gateway in untrusted domain. Dedicated machine with Veeam Collector, UI and VE connected to vCenter in Untrusted domain. Then there is a second machine which is just a collector. All service accounts are domain accounts. 1 account each for VE, Collector and vCenter access account. Each made a member of the local Veeam users group on the Veeam collector.

So essentially the Central domain and the untrusted domain have the same architecture except the central domain has SCOM management servers and the Untrusted domain has SCOM gateways.

Proposed Architecture

• Remove the Veeam components from the Untrusted domain. Manage the vCenter in the untrusted domain from the VE in the central domain, opening the required port (443) to the untrusted vCenter.
• Move the VE component from the dedicated Veeam server to the SCOM Management Server in the central domain.

The only assumption that the above solution relies on is that you can enter credentials for the vCenter account from any domain. Since authentication is done via normal vSphere APIs then I assume this is possible. The additional load from removing the collectors in the untrusted domain would be negligible (6 additional ESXi hosts).

[sergey.g]

Hi,

The architechture you described will work (vCenter doesn't need to be from a trusted domain, just make sure to keep this VC in a separate Monitoring Group, so that colelction jobs for the untrsuted vcenter don't failover to the trusted domain) and will be probably even easier to manage because of a single management service, however I think you'll also need Collector <-> VE communicatiosn to be opened between gateway and Management Server with VE, it should be incomming traffic to VE port (some additional ports are required for support logs collection, but you can live without this)

In case you absolutely have to keep everything as it is right now, you can contact our Tech Support department - there is a special build which could be installed on a Gateway server, it lacks some functionality and may not be supported in future versions, but can still be used if there are no other options.

Let me know how it goes or contact our support - they'll be able to assist you with your deployment.
Thanks.

[jeremy.hagan]

Thanks Sergey. I'm prepared to open the ports between the collector and the VE/SCOM MS. No probelms there. In fact the solution with consolidating the collectors is better since I don't need to open up inbound ports from the gateway network (which is less trusted) to the internal network (which is more trusted). All the traffic will be initiated on the trusted network to the gateway network.