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?

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,