If there is a trust between the domains, and the domain1.com account has access to the relavant resources in domain2.com, that should be it. As a test, add the domain1.com account as a local admin on a workstation in domain2, kill all open sessions to the workstation (reboot if necessary), and try to administer it.
All domains are child domains of a parent domain, so trust is there. I added the domain admins of Domain2 to the local admins built in group in AD for domain1.
I can connect to a PC in domain 1 with my credentials from domain2, but I do not have control, or I get an error about not being a local admin of the machine.
Try changing you authentication type. Depending on domain security policy, it may not like cross-domain NTLM.
SolarWinds support is basically telling me that my scenario will not work the way I want it to.
This is my Scenario:
Can you explain of point me
to an KB that explains what Dameware authentication requirements are needed for
cross-domain use. I have one top level forest domain with multiple child
domains. We are domain admin members of a child domain and need access to
another child domain. We currently create accounts in other child domains to
gain access, but these have been eliminated due to security. What settings need
to be configured in remote child domain for users in my domain to access
computers in remote locations with their current credentials?
This was the response:
In regards of your case,
the existing credentials need to be already created in AD groups.
Unfortunately, you cannot modify these settings in DW in order to access to
such domains. DW will work only with the groups that have those credentials
The requirements to use DameWare in a cross-domain environment are functionally no different than it is to use any other application or service in a cross-domain environment.
If you can map a drive to a resource in Domain2 using your Domain1 password, everything else should work exactly the same.
If you cannot map a drive to a resource in Domain2 using your Domain1 password, the problem is not with DameWare. :-)
These are standard Microsoft Windows cross-domain authentication policies that apply here. Pretty much anything anybody has written about cross-domain access in the past 10 years would be applicable. Based on everything I've read here, I'd go back and explicitly verify that there is a valid parent-child trust in place. Sometimes I've seen people create subdomains, in name, but not actually create them as a child of the parent domain. It looks like a parent-child relationship because of the naming, but internally in Active Directory it's not.
One note here with respect to this statement:
I added the domain admins of Domain2 to the local admins built in group in AD for domain1.
I do not have control, or I get an error about not being a local admin of the machine.
If you added the Domain2 domain account to the LOCAL Administrators group of a PC in Domain1, you do need to reboot the PC in order for those new group memberships to take effect. A domain PC evaluates domain account SIDS in local groups during machine account domain authentication.
If you added the Domain2 domain account to a DOMAIN Security Group that was already a member of the LOCAL Administrators group, it should not be necesary to restart the PC, however, just as with any other domain security group, you'll need to log off and back on to the domain in order to get the proper Group SIDs in your token.