Discussion:
Domian Local into Domain Admins Group
(too old to reply)
Cosmo
2009-11-16 09:02:02 UTC
Permalink
How do I make a 'Domain Local' security group which contains a Universal
group from another domain, a member of the Global 'Domain Admins' group?

DL's can't become a member of GG's
Marcin
2009-11-16 12:16:12 UTC
Permalink
Cosmo,
you can not. Domain global groups can contain only users and global groups
from the same domain...
If you need to grant Domain Admins equivalent privileges to accounts from
other domains, add them to the domain local Administrators group and local
Administrators groups on all domain member computers...

hth
Marcin
Post by Cosmo
How do I make a 'Domain Local' security group which contains a Universal
group from another domain, a member of the Global 'Domain Admins' group?
DL's can't become a member of GG's
Paul Bergson [MVP-DS]
2009-11-16 13:26:55 UTC
Permalink
I think you already answered your own question. See the link below for the
group scope rules.

http://technet.microsoft.com/en-us/library/cc755692(WS.10).aspx
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
Post by Cosmo
How do I make a 'Domain Local' security group which contains a Universal
group from another domain, a member of the Global 'Domain Admins' group?
DL's can't become a member of GG's
Ace Fekay [MCT]
2009-11-16 14:29:22 UTC
Permalink
Post by Cosmo
How do I make a 'Domain Local' security group which contains a Universal
group from another domain, a member of the Global 'Domain Admins' group?
DL's can't become a member of GG's
If the domain and forest are both in Windows 2003 Functional Mode or better,
you would follow the "AGGUDLP" rule, which means:

Add users to Globl Groups, which can be nested into another Global Group,
which can be added to a Universal Group, which can be nested into another
Universal Group, which can be added to a Domain Local Group, you then
provide permissions to.

In that directon, and not the other way around. The article Paul posted
explains it in more detail.
--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA
2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.
Cosmo
2009-11-20 08:38:02 UTC
Permalink
Thank you all for your responses :-)

As the AD 'Builtin\Adminstrators' only provides local admin rights on DC's,
how do I make trusted security groups from other domains a member of my local
'Domain Admin' group?

As the 'Domain Admin' group is a GG, it can only contain members from the
the local domain.
Ace Fekay [MCT]
2009-11-20 13:33:04 UTC
Permalink
Post by Cosmo
Thank you all for your responses :-)
As the AD 'Builtin\Adminstrators' only provides local admin rights on DC's,
how do I make trusted security groups from other domains a member of my local
'Domain Admin' group?
As the 'Domain Admin' group is a GG, it can only contain members from the
the local domain.
That's correct, the AD 'Builtin\Adminstrators' have complete and
unrestricted access to the computer/domain. Read the description under the
General Tab of the AD 'Builtin\Adminstrators.'

Keep in mind, it is a Domain Local group. Because of that, you can add
users, global and universal groups from its own domain and any trusted
domain, as well as other Domain Local group from its own domain (this is
called "nesting") providing anyone that has been added to the Local
Adminstrators group complete and unrestricted access to the DC and domain
resources (including all DCs, member servers and client machines).

And you are correct that you cannot add a Local Group to a Global Group, but
you can add a Global Group to a Domain Local group, hence is the basis of
the AGGUDLP guideline. Basicaly, it's ADDLP, but because of nesting, you can
also look at it as AGGUDLP, or even ADDUUDLDLP, etc.

I'll try to explain it again in better detail using ADDULDP that I
originally explained:

AGGUDLP:
A: Add a user
G: to a Global Group
G: which can be nested into another Global Group
U: which then can be added to a Universal Group, (which can also be nested
into another
Universal Group),
DL: which can be added to a Domain Local Group,
P: you then provide permissions to the Domain Local Group.

Because of the multi-level nesting into the Domain Local Group, any
permissions or rights you give the Domain Local Group (or that has them by
default such as the Administrators Domain Local Group), the users in any of
the groups that are nested, will have those permissions and rights.

By default, the Domain Admins group has already been added to the
Administrators Domain Local group, which is where the Domain Admins group
gains it's powers.

This guideline and Microsoft 'best practice' rule has been around since the
original NT 3.1 days, not including Universals of course, because that came
out with Windows 2000.

Keep in mind, this is a just a guideline. You can do it any way you want. I
like this because as a company grows, it helps because you don't have 500
users in a resource, which takes the system longer to enumerate, rather
simply one group SID which offers extremely fast enumeration.

You can also simply add a user directly to a resource (printer, folder,
etc), or simply add the Domain Local Group to the resource, and provide
permissions to the Domain local Group, and once you add other groups or
users to the Local Group, they gain the permissions and rights on the local
group.

Here is more info:

Understanding & Effectively Using AGDLP
http://troy.computertraining.edu/index.php/understanding-effectively-using-agdlp

AGDLP - From Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/AGDLP

AGLP Group Model:
http://groups.google.com/group/microsoft.public.cert.exam.mcse/browse_thread/thread/ba80bb522c13798b/56de1bc78d48dafc?lnk=st&q=aglp&rnum=1#56de1bc78d48dafc

And to add a Global or Universal group from a trusted domain, you go into
YOUR Domain Local Group, click Add, change "Location" to the trusted domain,
and choose their Domain Global Group. Matter of fact, you will see
everything on the trusted side except their Local Groups, because the system
will not allow to add Local Groups to other Local grouups in other domains.
If clicking on the Location button doesn't show the trusted domain, then the
trust is not setup correctly.

I hope that all makes sense.

Ace
Paul Bergson [MVP-DS]
2009-11-20 13:55:33 UTC
Permalink
You can manage multiple domains within your forest, with a single user
account, by using the Enterprise Administrators Universal group.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
Post by Cosmo
Thank you all for your responses :-)
As the AD 'Builtin\Adminstrators' only provides local admin rights on DC's,
how do I make trusted security groups from other domains a member of my local
'Domain Admin' group?
As the 'Domain Admin' group is a GG, it can only contain members from the
the local domain.
Paul Bergson [MVP-DS]
2009-11-20 14:15:10 UTC
Permalink
I should have preficed this in that I assume you are only going to place a
sinle Admin in this group that , don't use this with light thought. This is
to manage ALL aspects of the domain. Again, use with care.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
Post by Paul Bergson [MVP-DS]
You can manage multiple domains within your forest, with a single user
account, by using the Enterprise Administrators Universal group.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
Post by Cosmo
Thank you all for your responses :-)
As the AD 'Builtin\Adminstrators' only provides local admin rights on DC's,
how do I make trusted security groups from other domains a member of my local
'Domain Admin' group?
As the 'Domain Admin' group is a GG, it can only contain members from the
the local domain.
Cosmo
2009-11-23 10:01:02 UTC
Permalink
Thank you all for your very informative responses.

So to summarize:
An enterprize wide solution for providing a consistent 'Domain Admin' model
can be achieved by -> Placing the various GG security groups into the 'Domain
Admins' GG and then make this group a member of the 'Enterprise Admins' DL
group, which automatically becomes a member of all 'Local Admins' group
(including DC's) within the Forest.
Paul Bergson [MVP-DS]
2009-11-23 13:23:35 UTC
Permalink
No. Just follow Ace's advice, it is simpler and better security. I was
looking at it from the wrong perspective. Don't use the EA group.

The administrators group is a domain local group. Say you would like all
domain admins from the root of your domain to be admins in a child domain.
Open up ADUC in the child domain and bring up the administrators domain
local group, click add, click the Locations button and select the root
domain to change the focus. Select the domain admins group and click ok.
Now the domain admins group from the root should be a member of the domain
local administrators group in the child domain.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
Post by Cosmo
Thank you all for your very informative responses.
An enterprize wide solution for providing a consistent 'Domain Admin' model
can be achieved by -> Placing the various GG security groups into the 'Domain
Admins' GG and then make this group a member of the 'Enterprise Admins' DL
group, which automatically becomes a member of all 'Local Admins' group
(including DC's) within the Forest.
Ace Fekay [MCT]
2009-11-23 13:54:31 UTC
Permalink
Post by Paul Bergson [MVP-DS]
No. Just follow Ace's advice, it is simpler and better security. I was
looking at it from the wrong perspective. Don't use the EA group.
The administrators group is a domain local group. Say you would like all
domain admins from the root of your domain to be admins in a child domain.
Open up ADUC in the child domain and bring up the administrators domain
local group, click add, click the Locations button and select the root
domain to change the focus. Select the domain admins group and click ok.
Now the domain admins group from the root should be a member of the domain
local administrators group in the child domain.
--
Paul Bergson
I don't believe Cosmo read my response in it's entirety or may not entirely
understand the gest of it.

To add to your response Paul, and possibly to make it easier for Cosmo to
understand, in summary:

****
If you want an account to have EA, simply add the user or group (universal
or global) from any domain or trusted domain, to the 'Builtin\Adminstrators'
group in the forest root.
****

That's it.

Ace
Cosmo
2009-11-24 21:21:04 UTC
Permalink
Thanks for the claification. The method I'll use is:

Make the Forest root Domain Admins group a member of the various child
domains local administrators group.

For interest sake, what additional AD rights does the Enterprise Admin group
provide over the Domain Admin?
Ace Fekay [MCT]
2009-11-25 04:27:50 UTC
Permalink
Post by Cosmo
Make the Forest root Domain Admins group a member of the various child
domains local administrators group.
Why do you want to do that?
Are you trying to give the Forest Root Domain admins access to the child
domains? The forest root domain admins ALREADY have the ability to
administer all child domains.

This is because the forest root Domain Admins is part of the EA group by
default.

Maybe I am missing the end results. Can you elaborate on your intentions?
Post by Cosmo
For interest sake, what additional AD rights does the Enterprise Admin group
provide over the Domain Admin?
The forest Domain Admin is alread part of the EA. The EA has carte blanche
over the WHOLE forest.

Ace
Paul Bergson [MVP-DS]
2009-11-25 13:45:10 UTC
Permalink
The thing is it isn't recommended that anyone stay in the EA group for an
extended period of time, instead the recommendation is to provide local
admin access if needed on a daily basis. Of course I can't seem to find the
info related to this.

There are certain system configuration settings that only the Enterprise
Admin can perform, such as in the configuration of the naming context in AD.
I believe that within PKI there are things only the EA can do. I would just
hand out the least set of privileges and go from there.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
Post by Ace Fekay [MCT]
Post by Cosmo
Make the Forest root Domain Admins group a member of the various child
domains local administrators group.
Why do you want to do that?
Are you trying to give the Forest Root Domain admins access to the child
domains? The forest root domain admins ALREADY have the ability to
administer all child domains.
This is because the forest root Domain Admins is part of the EA group by
default.
Maybe I am missing the end results. Can you elaborate on your intentions?
Post by Cosmo
For interest sake, what additional AD rights does the Enterprise Admin group
provide over the Domain Admin?
The forest Domain Admin is alread part of the EA. The EA has carte blanche
over the WHOLE forest.
Ace
Ace Fekay [MCT]
2009-11-25 15:00:54 UTC
Permalink
Post by Paul Bergson [MVP-DS]
The thing is it isn't recommended that anyone stay in the EA group for an
extended period of time, instead the recommendation is to provide local
admin access if needed on a daily basis. Of course I can't seem to find
the info related to this.
There are certain system configuration settings that only the Enterprise
Admin can perform, such as in the configuration of the naming context in
AD. I believe that within PKI there are things only the EA can do. I
would just hand out the least set of privileges and go from there.
--
That's actually stated in the AD design courseware, too. I will have to look
for an article on that. However, here's a good thread on it.
http://www.petri.co.il/forums/showthread.php?t=22311

Ace
Cosmo
2009-11-25 20:16:01 UTC
Permalink
I'll provide you with the full story. I have inherited an enterprise
consisting of 8 Forests and 12 domains, all managed under a very locked down
AD Delegation model (as per the MS Whitepaper on this topic). The Enterprise
and Domain Admins have basically no rights, as it is all AD role based. This
seems like a very good appraoch, but to have local admin rights on all
servers, currently I'm a member of 700 Windows security groups -> which is an
absolute nightmare to manage !!

My proposed solution is to bring back the standard Domain Admin groups
throughout the entire enterprise. Current the DA group is a member of
nothing, hence the reason it has no powers.

So, that's the reason I'm thinking of making the Forest root Domain Admins
group a member of the various child Domains Local Builtin\Administrators
group (i.e. Manage the entire enterprise just with our Forest root Domain
Admin accounts), rather then the current 'x' number of AD Role based user
accounts.
Ace Fekay [MCT]
2009-11-26 00:10:42 UTC
Permalink
Post by Cosmo
I'll provide you with the full story. I have inherited an enterprise
consisting of 8 Forests and 12 domains, all managed under a very locked down
AD Delegation model (as per the MS Whitepaper on this topic). The Enterprise
and Domain Admins have basically no rights, as it is all AD role based. This
seems like a very good appraoch, but to have local admin rights on all
servers, currently I'm a member of 700 Windows security groups -> which is an
absolute nightmare to manage !!
My proposed solution is to bring back the standard Domain Admin groups
throughout the entire enterprise. Current the DA group is a member of
nothing, hence the reason it has no powers.
So, that's the reason I'm thinking of making the Forest root Domain Admins
group a member of the various child Domains Local Builtin\Administrators
group (i.e. Manage the entire enterprise just with our Forest root Domain
Admin accounts), rather then the current 'x' number of AD Role based user
accounts.
So you are saying this is setup this way in all 8 forests? Then you will
have to do that for each forest. And I assume there are two-way forest
trusts between them? That requires some attention, too. By default the
forest root domain Domain Administrators group is part of EA. So that was
stripped. In a good security design, the domain administrator members would
be very limited, possibly to one or two people, so I don't know why this was
done that way in your infrastructure.If you wanted to lock it down further,
and I don't know exactly which whitepaper you read (you didn't post it), but
I would have opt for an empty root design, where only one or two admins have
access at the top level, and each division or locale with their own child
domain would have their own admins that have no access to the forest root
anyway, so this EA stripping action wouldn't have been required.

I bet other things were changed, as well, and you would have to carefully
weigh all changes and come up with a plan to get everything back to default,
if that is your end results requirements.

And thanks for posting this info. It shed a lot of light on why you were
asking your questions the way you did.

Ace
Cosmo
2009-11-26 21:06:02 UTC
Permalink
It's all coming together.

I'll reinstate the Domain Admin roles throughout the enterprise, as the
current sys admin model is not working. Plus, leave all the other AD Role
Based roles alone (eg. FnP Admins, IIS Admins, Sharepoint Admins, etc..)

I'll take your advise and implement the following:

Place only the three Enterprise Admin users within the Enterprise Forest
Root Domain Admin group and this GG will be a member of all the various lower
child domain's 'Builtin\Administrators' group.

Whereas, the lower Forest root Domain Admins GG for that Forest, which again
will be members of the lower domain's 'Builtin\Administrators' group.

PS: The current AD Role Based model is exactly per the MS W2K AD Delegation
Whitepaper.

Thanks Ace and Paul for your fantastic assistance. Much appreciate :-)

Cheers,
Cosmo
Ace Fekay [MCT]
2009-11-27 04:08:15 UTC
Permalink
Post by Cosmo
It's all coming together.
I'll reinstate the Domain Admin roles throughout the enterprise, as the
current sys admin model is not working. Plus, leave all the other AD Role
Based roles alone (eg. FnP Admins, IIS Admins, Sharepoint Admins, etc..)
Place only the three Enterprise Admin users within the Enterprise Forest
Root Domain Admin group and this GG will be a member of all the various lower
child domain's 'Builtin\Administrators' group.
Whereas, the lower Forest root Domain Admins GG for that Forest, which again
will be members of the lower domain's 'Builtin\Administrators' group.
PS: The current AD Role Based model is exactly per the MS W2K AD Delegation
Whitepaper.
Thanks Ace and Paul for your fantastic assistance. Much appreciate :-)
Cheers,
Cosmo
The delegation papers have different scenarios. I can understand going with
their recommendation, but it surely complicates things, as you've seen. :-)

You are welcome. Let us know if you have any other questions. We'll be more
than happy to help.

Cheers!

Ace
Paul Bergson [MVP-DS]
2009-11-27 13:09:24 UTC
Permalink
Glad to help. :-)
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
Post by Ace Fekay [MCT]
Post by Cosmo
It's all coming together.
I'll reinstate the Domain Admin roles throughout the enterprise, as the
current sys admin model is not working. Plus, leave all the other AD Role
Based roles alone (eg. FnP Admins, IIS Admins, Sharepoint Admins, etc..)
Place only the three Enterprise Admin users within the Enterprise Forest
Root Domain Admin group and this GG will be a member of all the various lower
child domain's 'Builtin\Administrators' group.
Whereas, the lower Forest root Domain Admins GG for that Forest, which again
will be members of the lower domain's 'Builtin\Administrators' group.
PS: The current AD Role Based model is exactly per the MS W2K AD Delegation
Whitepaper.
Thanks Ace and Paul for your fantastic assistance. Much appreciate :-)
Cheers,
Cosmo
The delegation papers have different scenarios. I can understand going
with their recommendation, but it surely complicates things, as you've
seen. :-)
You are welcome. Let us know if you have any other questions. We'll be
more than happy to help.
Cheers!
Ace
Loading...