See all of the top support solutions for our most common issues here
Hi everyone, Arvind Kr. Rana here. We’ve seen this issue come up a couple of times so I wanted to give it a mention here just in case you run into it. The problem is that you may notice that a System Center Configuration Manager 2007 (ConfigMgr 2007) Secondary Site Server is unable to do any type of AD discovery in another forest. The forest trust is working fine, and you may see some errors in the adsysdis.log on the secondary site server similar to the following:
ERROR: Failed to bind to 'LDAP://domainname/rootDSE' (0x8007203B) ERROR: Failed to enumerate directory objects in AD container LDAP://FQDN SMS_AD_SYSTEM_DISCOVERY_AGENT 11/16/2011 1:41:10 PM 4688 (0x1250) STATMSG: ID=5204 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_AD_SYSTEM_DISCOVERY_AGENT" SYS=machine name SITE=site name PID=2252 TID=4688 GMTDATE=Wed Nov 16 19:41:10.771 2011 ISTR0="LDAP://FQDN" ISTR1="A local error has occurred.~~" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_AD_SYSTEM_DISCOVERY_AGENT 11/16/2011 1:41:10 PM 4688 (0x1250)
We checked the trust between the two forests, we have forest trust, and found the trust to be working just fine. I was able to access the resources or the users of the either forest.
The Central site server and the Primary site server were able to do any type of AD discovery fine from any other trusted forests.
We then found the following error in the adsysdis.log which seems to point to an authentication issue:
ERROR: Failed to bind to 'LDAP://domainname/rootDSE' (0x8007203B) ERROR: Failed to enumerate directory objects in AD container LDAP://FQDN
We examined and found the DNS name resolution to be working fine on the secondary site server so we then enabled Netmon to take a network capture. After triggering adsysdis.dll by running the AD system discovery we found the following errors in the Netmon trace:
0 2389 2:42:40 AM 12/17/2011 67.9452322 10.136.1.12 10.136.1.13 TCP TCP:Flags=...A..S., SrcPort=Kerberos(88), DstPort=57753, PayloadLen=0, Seq=2509066299, Ack=1957022246, Win=64240 ( Negotiated scale factor 0x0 ) = 64240 0 2390 2:42:40 AM 12/17/2011 67.9452487 10.136.1.13 10.136.1.12 TCP TCP:Flags=...A...., SrcPort=57753, DstPort=Kerberos(88), PayloadLen=0, Seq=1957022246, Ack=2509066300, Win=513 (scale factor 0x8) = 131328 1595 2391 2:42:40 AM 12/17/2011 67.9452920 10.136.1.13 10.136.1.12 KerberosV5 KerberosV5:TGS Request Realm: DOMAIN.LOCAL Sname: ldap/srv-msk-dc.domain.local/domain.local 0 2392 2:42:40 AM 12/17/2011 67.9453753 10.136.1.12 10.136.1.13 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=57753, PayloadLen=0, Seq=2509066300, Ack=1957023841, Win=64240 (scale factor 0x0) = 64240 172 2393 2:42:40 AM 12/17/2011 67.9462934 10.136.1.12 10.136.1.13 KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_POLICY (12) 0 2394 2:42:40 AM 12/17/2011 67.9463337 10.136.1.13 10.136.1.12 TCP TCP:Flags=...A...F, SrcPort=57753, DstPort=Kerberos(88), PayloadLen=0, Seq=1957023841, Ack=2509066472, Win=512 (scale factor 0x8) = 131072 0 2395 2:42:40 AM 12/17/2011 67.9463952 10.136.1.12 10.136.1.13 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=57753, PayloadLen=0, Seq=2509066472, Ack=1957023842, Win=64240 (scale factor 0x0) = 64240 0 2396 2:42:40 AM 12/17/2011 67.9464449 10.136.1.12 10.136.1.13 TCP TCP:Flags=...A.R.., SrcPort=Kerberos(88), DstPort=57753, PayloadLen=0, Seq=2509066472, Ack=1957023842, Win=0 (scale factor 0x0) = 0 12 2397 2:42:40 AM 12/17/2011 67.9465423 System 10.136.1.13 10.136.1.12 LDAPMessage LDAPMessage:Unbind Request, MessageID: 803 0 2398 2:42:40 AM 12/17/2011 67.9465752 System 10.136.1.13 10.136.1.12 TCP TCP:Flags=...A...F, SrcPort=57752, DstPort=LDAP(389), PayloadLen=0, Seq=1915435841, Ack=3623185621, Win=513 (scale factor 0x8) = 131328
Everything seemed to be setup fine and the trust is also working fine. Also this problem did not affect all ConfigMgr 2007 site servers, but only this secondary site server.
It turns out that this issue was due to the "Selective authentication trust" between these two forests, as in the case of the Selective authentication trust the secondary site server or any other object has to be given required permissions manually in the other forests domain exclusively.
Once you manually give permissions to the secondary site server machine account in the other forest domain’s active directory, and then purge the old Kerberos tickets using the klist tool from the secondary site server or restart the secondary site server, the server gets the new ticket and the new access token which have the new permissions to enumerate the other forests Active Directory to do any type of discovery (as we know that the machine account is used for discoveries).
This problem can also manifest itself in other ways such as when the central or the primary or any other machine is not able to see or access the resources from the other forests or domains. This issue can be fixed by manually giving the permissions to that object on the desired resource. In the case of Selective authentication trust though the forest trust you can even validate it, but the trust is only for the objects that have been given permissions manually to the resource. In a case of Discovery, the adsource.dll impersonates itself as the machine account of the site server, so the machine account should have the right permissions in Active Directory.
The TechNet article below articulates the permissions required and the complete flow of all type of the discoveries in ConfigMgr 2007:
Arvind Rana | Senior Support Engineer
App-V Team blog: http://blogs.technet.com/appv/ AVIcode Team blog: http://blogs.technet.com/b/avicode ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ DPM Team blog: http://blogs.technet.com/dpm/ MED-V Team blog: http://blogs.technet.com/medv/ OOB Support Team blog: http://blogs.technet.com/oob/ Opalis Team blog: http://blogs.technet.com/opalis Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/ SCMDM Support Team blog: http://blogs.technet.com/mdm/ SCVMM Team blog: http://blogs.technet.com/scvmm Server App-V Team blog: http://blogs.technet.com/b/serverappv Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/ The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/ The Forefront TMG blog: http://blogs.technet.com/b/isablog/ The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
You'll find ADSYSDIS.LOG in the LOGS folder residing in your ConfigMgr installation folder.
If you cannot find it there then that component has never run or logging for that component has been turned off, here's how to check out if logigng is enabled:
List of logs files in case its helpful:
Cheers Rana , Good info to share with all :)