AD Restricted Groups - Allowing DC access with Restricted Groups

Hey everyone,

Ive got a little question involving Restricted Groups in a Multi-Domain Forest.
Currently there is (1) W2k Mixed Mode Domains (2) W2k Native Domains, and (1) W2k3 Domain in the forest.  All of these domains are being migrated to 1 single parent  domain&that being the W2k3 Domain.
Until that is done, I have created special Security Groups in each domain to allow access to the other domains.  I do this because there are 3 companies in 17 location in 7 countries.  There is a head administrator in each company, but we share responsibilities.  For example, I have the awesome job of updating McAfee and Microsoft Patches on 2 of the 3 child companies as well as the new parent company that everyone is migrating to.  I need full access in the member servers and DCs.

So I created 2 groups:

If a local Domain Admin, such as me, needs access to in other domains, that user is added to the GG_ParentCompany_ChildCompany group.  That security group is a member of the UG_ParentCompany_ChildCompany which is the group that actually crosses the domains.
Its real easy when you think about it&if a domain admin in New Jersey needs access to servers in one of the sibling companies in another country&just add them to the GG_ParentCompany_ChildCompany group locally for their organization.

This cross-domain access works on member server in all of the sibling companies...just like we want it to&but the only Domain Controllers that users can logon to with their local domain accounts are in the new Parent Company W2k3 Domain.

For example:
childco\user can log on to ServerX in the domain named ParentDomain&both DCs and Member servers, but childco\user can only log on member servers in the SiblingDomain and not the DCs in the SiblingDomain.

Is this because of the schema types that are in place???  And is there a way to pull those Domain Admins over to sibling domains and allow them access without having to add the Security Groups from the sibling domains as local accounts on the Domain Controller servers?

Thanks a bunch,
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Nothing to do with schema, it's a matter of group scope.  Administrators is a local group, and thus can contain users/groups from other domains.  Domain Admins, on the other hand, is a global group, and can only contain users and global groups from within the same domain.  

Closest approximation of what you're describing is to add that Universal Group to the BUILTIN\Administrators group on your DCs - that makes them around 99% of a Domain Admin, give or take an implementation detail.  (Doing this will not automatically make them local admins on Domain-joined workstations, for example, as this is granted to Domain Admins and not BUILTIN\Administrators.)  

Make sense?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
inverted_2000Author Commented:
Yes it makes perfect sense.

When I created the restricted groups, and say I pulled a UG_ParentCompany_ChildCompany group over from say Germany and made it a member of "Administrators" local to my home domain in NC...I could use my Domain Admin Account from that Domain in Germany to log on to workstations and member servers without problem.

I guess I'll still need to add those Universal Groups to the Domain Controllers locally then?  But the member servers and workstations will be accessible without having to apply the UG's to the BUILTIN\Administrators.

That will work.

One last thing before I go on my way though is that...pulling these groups around is causing a lot of warning messages in the application logs.

This is exactly my issue here:

and warning messages are created every 5 minutes.  Is this because I had the Restricted Groups that I created members of both Administrators and Domain Admins?
Should I have it set a certain way to avoid these logs, or is that something we're just going to have to live with.  It's kind of scaring the other admins...especially the French one's (o:

Thanks a ton again for your help with this...I'm getting a ton on experience with all of this with your help.

inverted_2000Author Commented:
Hey Laura,

All this is confusing me again.

This article...especially Table 1, states that it will work...using W2k SP4 or newer...which we are.

This article says we can't pull GGs across domains to Restricted Groups:

Now that I'm getting these warning messages like you see in article (2) I can't get the cross domain access to work.  I wiped everything, Group, GPO, OU, etc off of all 4 domains.  

I started fresh with my home domain (W2k Native) and moved a GG over to the Default GPO in my new W2k3 domain.  I made that RG a member of various groups to try to get it to not produce a warning message in the application logs.  It won't work without making a warning log now...also...I can't log onto member servers like I could before I wiped everything out.  I built it back the same way...but it's not working the same.
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

inverted_2000Author Commented:
Okay...I got it to work by pulling the Domain Admins group across to the new domain as a Restricted Group...and making it a member of the Administrators in the new domain.  I gpupdated the individual servers and it allowed me to use my home local domain account to log on to member servers in the new domain.

Guess it is taking a little longer to update then I thought it should.

Anyway...I removed those groups and RGs because I don't want all of the Domain Admins in my local home domain to work in the new W2k3 domain.

I've recreated my groups and will sit on it for a day to let everything propregate.

Can you think of anyway we can resolve the 5min SceCli Warning Message that all of the servers will have if I roll this thing out?

The Warning Message states:
Source: SceCli
EventID: 1202
Security policies were propagated with warning. 0xd : The data is invalid.

Advanced help for this problem is available on Query for "troubleshooting 1202 events".

Thanks again Laura.
I'm not aware of any way to supress those error messages, sorry.  It's one of those implementation annoyances of a multi-domain forest (and why I try my darnedest to stick to a single-domain design if I have any say in the matter.)
inverted_2000Author Commented:
Check this out Laura,

I had been messing around with the RG on the Default Domain Policy and I also tried by creating a GPO and apply it at the site level with the RGs.  As we know, this caused the Warning Messages.

I removed those settings and applied directly at the OU with the servers instead of the Site Level or as a setting in the Default GPO, and it stopped making the Warning Messages.

I've got some more playing to do with it...but you've helped once again.

Thanks for everything,

inverted_2000Author Commented:
Actually the Warnings come back when I apply the GPO to the Builtin Domain Controllers OU.

I've done a RSoP on it:
The RG area states:
The policy engine did not attempt to configure the setting and check winlogon.log

winlogon.log states:
Configure Group Membership...
      No system mapping was found for CLT\UG_ParentCompany_ChildCompany.
      Group Membership configuration was completed with one or more errors.

I applied the GPO to Domain Controllers OU and I applied the setting inside of the Default Domain Controllers Policy.  Same thing either way.

Is this just because it doens't like this sort of thing, or it is protecting the DCs?

I'm really glad this issue is unfolding (o:

inverted_2000Author Commented:

Wait...wait wait wait!!!

If I simply add the UG_ParentCompany_Childcompany group to any sibling domain's BULTIN\Administrators group...I can log on to DCs and Member servers the the parent and sibling domains???

No need for any of this Restricted Groups stuff???
inverted_2000Author Commented:

I've wasted enough time with this...although this is not required in all 4 of our domains, I am going to achieve my goal of allowing Domain Admins from sibling and child domains access to member server and domain controllers by doing the following:

1)  Create a GPO with Restricted Goups that pull the administrators from other domains into the target domain by making them members of BUILTIN\Administrators and DOMAIN\Domain Admins.
This will allow RDP logons to Member Server and Workstations OUs.

2) Import the Universal Group from sibling and child domains in the BUILTIN\Administrators group in each target domain.
This will allow RDP logons to Domain Controller servers without using a GPO against the Default Domain Controller GPO that might cause SceCli errors as I described earlier.

I sure hope this helps someone out there.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2003

From novice to tech pro — start learning today.