ConfigMgr SCCM Untrusted Forest AD System Discovery Issue. The most complex and multi-tiered environments require performing AD System Discovery across untrusted forests.
Recently, I’ve faced an issue with untrusted forest AD system discovery. Using Active Directory Forest Account, I can publish MP details into the “System Management” container of the untrusted forest.
So, name resolution and firewall ports are fine between the forests or Domain Controllers. This is one of the interesting real-world scenarios I came across.
ConfigMgr SCCM Untrusted Forest AD System Discovery Issue
When I tried to enable Active Directory System Discovery in SCCM 2012, it was not working. I had a look at “adsysdis.log,” and as always, log files are very helpful in SCCM 2012. Following were the errors I could see in the discovery process log.
INFO: Processing search path: ‘LDAP://OU=COMPUTERS,DC=SCCMUAT,DC=ACNCONFIGMGR’.
INFO: Impersonating user [SCCMUAT\SVC_CM12_AD_FOREST] to discover objects.
INFO: Full synchronization requested
ERROR: Failed to bind to ‘LDAP://OU=COMPUTERS,DC=SCCMUAT,DC=ACNCONFIGMGR’ (0x8007054B)
INFO: CADSource::fullSync returning 0x8007054B
INFO: Reverting from impersonated user to default user.
ERROR: Failed to enumerate directory objects in AD container LDAP://OU=COMPUTERS,DC=SCCMUAT,DC=ACNCONFIGMGR
Some more details about the configuration of AD system Discovery. I’ve configured AD system discovery to discover the systems in the untrusted forests. As you know, I need to provide container path or LDAP query details, I’ve given the LDAP query “LDAP://OU=COMPUTERS,DC=configmgr1,DC=com”.
I was getting the following error 0x8007054B, and that error translates to “The specified domain either does not exist or could not be contacted.” Now, what ….ConfigMgr SCCM Untrusted Forest AD System Discovery Issue.
It’s almost a clear error message, which means the system or site server cannot find the domain details. How to resolve this? I’m not excellent in Active Directory, to be honest. ConfigMgr SCCM Untrusted Forest AD System Discovery Issue.
Troubleshoot – SCCM Untrusted Forest AD System Discovery Issue
As mentioned at the start of this post, I don’t have any other external issues with the site server and untrusted forest. Also, I’m able to publish MP details into an untrusted forest Active Directory.
Sitecomp.log came to help me again in this scenario. How? I wanted to find out how MP details are getting published to the untrusted forests and how the communication is taking place between the site server and untrusted forest. So, in sitecomp.log, I could see the following entries.
Processing forest ConfigMgr1.com.
Publishing account user account configmgr1\SVC_CM12_AD_FOREST will be used
Searching for the System Management Container.
LDAP://ACNCMRFOR.ConfigMgr1.com/CN=System Management,CN=System,DC=configmgr1,DC=com container exists.
FIX – SCCM Untrusted Forest AD System Discovery Issue
Oh, yes. You could see it was using the following LDAP query to communicate with untrusted forest.
After seeing that LDAP query, I could relate that with the AD System Discovery configuration. I’ve added the remote forest domain controller name to the LDAP query of AD system Discovery, and it started working !!! The LDAP query used is given below.
You can get more details in the “adsysdis.log” file (below). Remember, the site server or local DNS should resolve the names of the systems discovered from the untrusted forests.
Otherwise, the systems you’ve discovered don’t appear in the CM 12 console.
DNS records or name resolutions must be in place to create DDRs (Data Discovery Record) for all discovered systems. ConfigMgr SCCM Untrusted Forest AD System Discovery Issue.
INFO: Search provider = ‘LDAP’
INFO: Domain controller = ‘ACNCMRFOR.configmgr1.com’
INFO: Succeed to cached binding for LDAP://ACNCMRFOR.configmgr1.com/RootDSE
INFO: Include groups option will be ignored during incremental discovery.
INFO: search filter = ‘(&(uSNChanged>=93223)(|(objectCategory=group)(&(objectClass=user)(objectCategory=computer))))’
INFO: ads path = ‘LDAP://ACNCMRFOR.configmgr1.com/OU=COMPUTERS,DC=configmgr1,DC=com’
INFO: Bound to ‘LDAP://ACNCMRFOR.configmgr1.com/OU=COMPUTERS,DC=configmgr1,DC=com’
INFO: successfully completed directory search
INFO: AD Discovery under container LDAP://ACNCMRFOR.configmgr1.com/OU=COMPUTERS,DC=configmgr1,DC=com found 0 objects
INFO: ——– Finished to process search scope (LDAP://ACNCMRFOR.configmgr1.com/OU=COMPUTERS,DC=configmgr1,DC=com) ——–
Improved Securiy with Kerberos – Comment from Pavel Yurenev
Microsoft continuously works on improving the security protocols. One of the directions is to use Kerberos instead of NTLM – and therefore use FQDNs instead of NetBIOS domain names.
Instead of specifying the domain controller name in the LDAP path, better try the following solution:
1) Install 2022-02 Cumulative Update for Windows on ConfigMgr Site Server
2) Specify the discovery and publishing accounts as FQDN\DiscoveryUser instead of NetBIOS\DiscoveryUser:
Anoop is Microsoft MVP! He is a Device Management Admin with more than 20 years of experience (calculation done in 2021) in IT. He is Blogger, Speaker, and Local User Group HTMD Community leader. His main focus is on Device Management technologies like SCCM 2012, Current Branch, and Intune. He writes about ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc.