Authentication across 2 way External Forest Trust - SCOM

Hi experts,

Having real troubles getting my SCOM server to discover and manage a server on a different forest.

The situation is a little complicated so let me explain.

We have two forests which have a two way trust, everything resolves via pings etc, DNS conditional forwarders have been setup and are correct.

We have Forest ABC which contains one domain called Domain-A

We have Forest B which contains a forest root domain called SYSROOT.LOCAL and a TREE domain called CORE.LOCAL.

SCOM is in the CORE.LOCAL domain.

I have created a service account for scom call "servscom" and this account is in the core.local tree domain. I have created a group called "Cross forest Admins" which is in the forest root called sysroot.local. Servscom is a member of Cross_forest_admins.

Cross_forest_admins has been added to "Administrators" in the other forest. Therefore as far as i can see i should have access to do a discovery and install a scom agent on a machine in the other forest.

Can anyone see why discovery fails on scom? or if its easier to explain, can anyone advise me on what rights a scom server requires on another machine to be able to manage it?

thankyou in advance
Who is Participating?
ToxaconConnect With a Mentor Commented:
Oh, well, try

hslockdown Primary_Management_Group /R "NT AUTHORITY\SYSTEM"

Open in new window


hslockdown Primary_Management_Group /A "NT AUTHORITY\SYSTEM"

Open in new window

depending on the domain configuration. /R removes it from the explicit deny list or alternatively /A adds explicit permission. Set permissions on every DC. After setting restart Health Service.
SCOM needs to authenticate with Kerberos. If if does not work you must install trusted certificate for cross-forest scenario.

Is the client able to communicate with RMS?
IT_DeptAuthor Commented:
having read documentation on technet i dont believe i need a gateway server or certificates. I have a two way trust set up, everything pings and has connectivity and DNS forwarders are set up. I installed the agent on the server in another forest and it said it was healthy for a good few minutes.

Can someone explain to me why i need certificates becuase at the moment im leaning away from thinking i need them, however if i do i would like to know what the reason for this is?
We Need Your Input!

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!

I took a second glance at the problem and noticed that you have added your cross_forest_admins to Administrators group of the other domain. That group does not have access to other machines than domain controllers. Domain Admins will be granted full control to domain member machines.

Based on that, your servscom account does not have adequate permissions on the other domain machines. As it does not have permissions, it can't do a computer verification and therefore it cannot discover anything. I think that this is the most likely reason.
IT_DeptAuthor Commented:
The server  I have mentioned that I am having problems with is a domain controller itself.

Also in your other point you mention adding servscom to domain admins. This is not possible, you cant add resources from another forest into domain admins. I have just tried it again and only my source forest appears.
Ummm, I didn't say add servscom to Domain Admins. I said that Administrators do not have access to domain members like Domain Admins do.

Will it start to work if you install the SCOM client manually along with Oomads?

If you log in to your SCOM server with the SCOM account, are you able to fully manage the other domain? You should have full control. Also use Kerbtray to see if you have Kerberos working ok for the foreign forest.
IT_DeptAuthor Commented:
Thanks for that Toxacon and sorry for the confusion on my part.

I have created a restricted groups GPO which is now adding SYSROOT_Cross_Forest_admins to the local admins on all member servers and i can now manage member machines in the other forest.

I still cannot manage domain controllers in the other forest though. My cross forest admins group is a member of administrators on the other forest which i would think should be enough.

I have just gone through health explorer and navigated to the only red "X" which is the Runas authorization check. the error message is :

The health service blocked access to the windows credential NT AUTHORITY\SYSTEM because it is not authorized on management group Primary_Management_Group. You can run the HSLockdown tool to change which credentials are authorized.

any ideas what could be causing this?
IT_DeptAuthor Commented:
Thanks Toxacon, im getting closer to solving this now.

I have added NT AUTHORITY\SYSTEM  and restarted the health service. Almost immediately the greyed out machine on the other domain in the other forest came back to say healthy apart from  on the agent status which is now a yellow warning sign.

I have ran a health explorer and found the yellow warning relates to the Runas account monitoring check. I now have the following error:

The Health Serivce cannot verify the future validity of the Runas account CORExxx\servscom for management group Primary_Management_Group due to an error retrieving information from the Active Directory (for domain accounts) or the local security authority(for local accounts) The error is the network address is invalid.

I have just added servscom to the allowed list and restarted the health service but this has not changed anything. Any clues as to what is causing this?
IT_DeptAuthor Commented:

I have just found what I would describe at best a "work around" which seems really rubbish but works. I have gone on to the DC in the other forest that Im trying to manage and added in the DNS SUFFIX of the other domain. I did this in the advanced tcp/ip settings on the DNS tab.

Surely there is a way around this, otherwise it seems I will need another group policy to add the suffix to all domain machines?

Is this purely Microsoft design and is this expected behaviour?
You could also try to create servscom account to both forests with the same password.
IT_DeptAuthor Commented:
Thanks Toxacon, much appreciated
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.