Cross-domain security requirements?

[gordonf]

I successfully installed SCOM clients onto computers belonging to an external but trusted domain, but ran into authentication problems along the way. I had to change one trust relationship setting to make it work.

 

Here's what I found I had to do to make cross-domain installation and monitoring work:

 

* Changed my trust relationship from "External" to "Forest," to enable Kerberos authentication

* Open needed network firewall ports, as the external domain's network is separated by a firewall router deliberately

* Create an action account that matched a domain account in the external domain

* Changed the trust relationship to permit forest-wide authentication, as it was originally selective authentication

 

I'm comfortable with all of these except the last one. When I had selective authentication enabled, I would see event ID 20057 on the external domain PCs, indicating an error 0xC000413 (Authentication firewall); the external domain PCs were not permitted to log on to the SCOM management server.

 

Usually if I want to grant cross-domain logon permission I would go to the computer account and grant the "Allowed to Authenticate" permission to the external domain's account, but that alone didn't work. I granted that permission to the action account first, and when that didn't work I tried granting it to an external PC's computer account. Only after permitting forest-wide authentication did clients start reporting in by themselves.

 

If I want to restore selective authentication to this domain trust, what permissions do I need to grant to what accounts so SCOM clients can report in?

--

[barracuda]

Hi Gordon,

Have you ever been able to resolve this issue?

 

I am currently struggeling with the same issue and can't find any resolutions.

For security purposes I want to keep the selective authentication in the domain trusts at all cost.

 

Kind regards,

[AdinE]

Have either of you looked into using a Gateway server? It's like a SCOM Management Server, but used in DMZs, etc. The Agents report to it, the GW then compresses the data, and sends it back to the MS. This way only the communication between the Gateway and the MS are required.

[barracuda]

That is my last and final option, because I don't want to setup another (GW) server and also to install a Certificate Authority besides my Active Directory.

Meanwhile, I managed to get things working with the selective trust. I was on the right track, but it didn't work because of anoter issue which I will explain later.
first the solution to the required user permissions:
I did this by adding the SCOM action account and SCOM SQL Discovery and Monitoring account to the administrators group of the remote domain.
So, for example:

- HQ.local with an AD server and SCOM server.

- The remote domain is named DOMAIN1.local with its own Active Directory and servers in this domain which I want to monitor.
In de Active Directory of DOMAIN1.local; add the SCOM users, for example SCOM-ActionAccount.HQ.local and SCOM-SQL.HQ.local to the local administrators group (so the administrators.DOMAIN1.local group).
(keep in mind that the trust from DOMAIN1.local is being authenticated by only one (administrator) user account which is permitted to authenticate because of the selective trust in HQ.local. When adding users from the HQ domain these credentials will be asked automatically).

Now I am facing the real challenge... the servers in the external domains are having structural computernames which NetBios names seem to be conflicting.
example:
DC01.HQ.local
SRVDC01.DOMAIN1.local
SRVDC01.DOMAIN2.local

The two SRVDC01 domaincontrollers of DOMAIN1 and DOMAIN2 are using the same NetBios name. When I try to add SCOM permitted users from HQ.local into the SRVDC01.DOMAIN1.local or SRVDC01.DOMAIN2.local, only one domain is able to correctly see the users:
SRVDC01.DOMAIN1.local is able to see the SCOM-ActionAccount.HQ.local
SRVDC01.DOMAIN2.local is seeing some S-1-5 ID numbers (which stand for SCOM-ActionAccount.HQ.local).

When I validate the trust on SRVDC01.DOMAIN2.local... the issue turns the other way around:
SRVDC01.DOMAIN1.local is seeing some S-1-5 ID numbers (which stand for SCOM-ActionAccount.HQ.local).

SRVDC01.DOMAIN2.local is able to see the SCOM-ActionAccount.HQ.local


Any suggestions for the last following-up issue?