Cross-Forest - IADsGroup::Add receiving error 80072030 "There is no such object on the server"

  • Article

Problem:

 

When running a script to add a user from forest Fabrikam, to a domain local group in forest Microsoft, you will receive an error as follows:

80072030 "There is no such object on the server"

This is a snippet of the code we tried to perform the procedure:

=================================================
set objGroup = GetObject("LDAP:// microsoft.com /cn=Domain Local Group,ou=Test,dc=microsoft,dc=com")
set objUser = GetObject("LDAP://fabrikam.com/cn=Vishal Joshi,ou=CrossDomainTestOU,dc=fabrikam,dc=com")

wscript.echo "Group:" & objgroup.adspath & vbcrlf & "User:" & objUser.adspath

objGroup.add(objUser.adspath)
===================================================

If the domains are in two forests with a two way trust and running at 2003 native forest functional level, it will not work.

You will have no trouble using Active Directory Users & Computers to add the user to the group.

The echo works in all the above scenarios, so you know that the GetObject is working. The script will always fail on the objGroup.add.

Even adding the serverbind to the LDAP requests the script will not work.

Also running under the user who has enough right’s on both domains.

Resolution:

 

We need to use the LDAP://<SID=S-1-5-21-2052111302-2139871995-839522115-1115> format while adding the user

Something like

objGroup.add(“LDAP://<SID=S-1-5-21-2052111302-2139871995-839522115-1115>”)

What happens when you use the SID bind string, it creates a place holder.

If you provide the path, it tries to verify the object and retrieve the SID to create the FSP, because the FSP is what is added to the local domain group.

It did not check to see if the SID was valid... it just accepted it because it was a valid SID. Meaning, it was the correct size with the correct number of sub authorities.

So it’s the callers responsibility to send the right SID to this call.

Since the user is in a foreign forest, the object will not represented in local GC. So the foreign user should be added to the local domain group using the SID of the user object instead of distinguished name.