We (us.com) have a forest trust with newly acquired partner (them.com).
SID filtering disabled.
us.com has a site and DC in their location. All of their IP subnets are part
of that site definition.
It was decided to migration workstations before users in our migration plan.
User accounts to be migrated in future, but first we are migrating
workstations.
All clients are XP SP2 or better.
Cross-forest access to file shares and printers on member servers from both
forests is working by add global groups from one forest to a domain local
group in the other forest.
A them.com workstation is unjoined from it's domain and joined to us.com.
(but stays in it's same physical location and retains it's same IP address.
So during this transition period of our migration. A them.com user will log
on to the same workstation they've always used, with their them.com user
account, but that workstation is now a member of us.com. This way the user
can continue to use the local profile they are accustomed to until we use
the QUEST tools to migrate the user and local profile later.
Problem. There is an application (call it "appl1") which "requires" local
admin access on the local computer to run properly. But we have not been
able to make that work. It's unloke this is the only app that will require
some kind elevated access on the workstation and so we are looking for a
consistent practice for meeting these requirements.
Things we've tried...
-We created an us.com\APPL1 domain local group, containing the
them.com\APPL1Users global group, then added the us.com\APPL1 domain local
group to the local administrators group.
-We also tried same as above but added individual them.com\username accounts
to us.com\APPL1 domain local group
-We also tried adding the them.com\username to the local administrators
group.
None of these configurations have yielded admin rights on the workstations.
When adding accounts (users or groups) to a local group on a workstation,
the object picker does not enumerate the trusted domain (them.com), but
using the them.com\username syntax will work for adding the user object. So
we CAN add the account to the local group in the GUI, but the net effect
does not yield admin rights on the workstation.
Is this normal? Can you only grant admin rights via local group membership
if the user has an account in the same domain as the computer account? Is
the winlogon process able to include access tokens from the trusted forest?
Thank you for any help you can provide.
|