Default groups and security permissions

When a new Domain Controller is created the Default groups (Domain admins,
Enterprise Admins, Schema admins etc) under the OU users are also created.

if you see the security tab for each of them, specailly Domain admins,
Enterprise Admins you will see that the Administrators groups has the check
mark on all permissions except for Full controll. Isn't this a flaw, let's
say you need to grant permissions to an user to manage the domain
controllers. Any user member of the built-in\administrators can go and
elevate permissions to domain admins, enterprise admins etc.

Has anyone noticed this or has a workaround?

[dkumar]

default permission is enough to manage DC, it should work , TRY

Hello Xavier,

That's the reason no normal user should be granted permissions to DCs, use
only administrators whom you trust. Normally no "normal" user should logon
to a DC.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> When a new Domain Controller is created the Default groups (Domain
> admins, Enterprise Admins, Schema admins etc) under the OU users are
> also created.
>
> if you see the security tab for each of them, specailly Domain admins,
> Enterprise Admins you will see that the Administrators groups has the
> check mark on all permissions except for Full controll. Isn't this a
> flaw, let's say you need to grant permissions to an user to manage the
> domain controllers. Any user member of the built-in\administrators can
> go and elevate permissions to domain admins, enterprise admins etc.
>
> Has anyone noticed this or has a workaround?
>

Hi Meinolf,
Yes, I am aware of that, however I am sure there are many people with the
requirement of delegating permissions to help desk on DCs for operations only
like a standalone server (restart a service, uninstall a program etc) which I
have found a way to do it. However I was trying to find a better solution and
it's when I found the permissions for the default groups.
Would it be safe to remove the administrators groups in the security tab for
the Domain Admins, Enterprise Admins, and Schema Admins to prevent a member
of Administrators evelate permissions himself/herself? Has anyone tried it
before?
--
XER


"Meinolf Weber [MVP-DS]" wrote:

>
> That's the reason no normal user should be granted permissions to DCs, use
> only administrators whom you trust. Normally no "normal" user should logon
> to a DC.
>
> Best regards
>
> Meinolf Weber
> Disclaimer: This posting is provided "AS IS" with no warranties, and confers
> no rights.
> ** Please do NOT email, only reply to Newsgroups
> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>
>
> > When a new Domain Controller is created the Default groups (Domain
> > admins, Enterprise Admins, Schema admins etc) under the OU users are
> > also created.
> >
> > if you see the security tab for each of them, specailly Domain admins,
> > Enterprise Admins you will see that the Administrators groups has the
> > check mark on all permissions except for Full controll. Isn't this a
> > flaw, let's say you need to grant permissions to an user to manage the
> > domain controllers. Any user member of the built-in\administrators can
> > go and elevate permissions to domain admins, enterprise admins etc.
> >
> > Has anyone noticed this or has a workaround?
> >
>
>
> .
>

"Lobo" <Lobo@discussions.microsoft.com> wrote in message news:873E89B2-5F13-45FD-9D48-A3EF01890E05@microsoft.com...
> Hi Meinolf,
> Yes, I am aware of that, however I am sure there are many people with the
> requirement of delegating permissions to help desk on DCs for operations only
> like a standalone server (restart a service, uninstall a program etc) which I
> have found a way to do it. However I was trying to find a better solution and
> it's when I found the permissions for the default groups.
> Would it be safe to remove the administrators groups in the security tab for
> the Domain Admins, Enterprise Admins, and Schema Admins to prevent a member
> of Administrators evelate permissions himself/herself? Has anyone tried it
> before?
> --
> XER
>
>

They are called protected groups. If you try to change it, the AdminSDHolder function will revert it back.

AdminSDHolder, Protected Groups and SDPROP
http://technet.microsoft.com/en-us/m...minholder.aspx

AdminSDHolder
http://blogs.dirteam.com/blogs/jorge...05/16/981.aspx

The idea is to not allow anyone other than Domain Admins on a DC. If they need to create users, administer any otehr part of AD, delegate the permissions and install the support tools (either adminpak or RSAT tools) on the delegated user's workstation.

--
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, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

Yes but I am referring to do something similar according to this MS document
that you can modify the AdminSDHolder and revoke permissions for protected
groups (page 154).

Best Practices for Delegating Active Directory Administration
http://www.microsoft.com/downloads/d...displaylang=en
--
XER


"Ace Fekay [MVP-DS, MCT]" wrote:

> "Lobo" <Lobo@discussions.microsoft.com> wrote in message news:873E89B2-5F13-45FD-9D48-A3EF01890E05@microsoft.com...
> > Hi Meinolf,
> > Yes, I am aware of that, however I am sure there are many people with the
> > requirement of delegating permissions to help desk on DCs for operations only
> > like a standalone server (restart a service, uninstall a program etc) which I
> > have found a way to do it. However I was trying to find a better solution and
> > it's when I found the permissions for the default groups.
> > Would it be safe to remove the administrators groups in the security tab for
> > the Domain Admins, Enterprise Admins, and Schema Admins to prevent a member
> > of Administrators evelate permissions himself/herself? Has anyone tried it
> > before?
> > --
> > XER
> >
> >
>
> They are called protected groups. If you try to change it, the AdminSDHolder function will revert it back.
>
> AdminSDHolder, Protected Groups and SDPROP
> http://technet.microsoft.com/en-us/m...minholder.aspx
>
> AdminSDHolder
> http://blogs.dirteam.com/blogs/jorge...05/16/981.aspx
>
> The idea is to not allow anyone other than Domain Admins on a DC. If they need to create users, administer any otehr part of AD, delegate the permissions and install the support tools (either adminpak or RSAT tools) on the delegated user's workstation.
>
> --
> 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, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
> Microsoft Certified Trainer
> Microsoft MVP - Directory Services
>
> If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.
>
>
>
> .
>

"Lobo" <Lobo@discussions.microsoft.com> wrote in message news:E7A8F444-ECA0-4723-B292-21CB761EF9ED@microsoft.com...
> Yes but I am referring to do something similar according to this MS document
> that you can modify the AdminSDHolder and revoke permissions for protected
> groups (page 154).
>
> Best Practices for Delegating Active Directory Administration
> http://www.microsoft.com/downloads/d...displaylang=en
> --
> XER

I didn't know that. You didn't mention that earlier. No, I'm sorry I have not tried to modify this feature. I've found delegation to be sufficient for what I've designed in the past, even for a 5000 user, multi-domain forest. We just never give anyone that is not a domain admin access to a DC and provide the adminpak tools to ONLY provide the ADUC console and nothing else. Kind of like increased security within design parameters. Anytime a mod if attempted, it complicates things, especially trying to support it later down the line, including if there is sufficient documentation. I've seen that before, including with modifying registery settings for multihomed DCs. later on, when something comes up and wondering why registration doesn't work when an IP change is made, the admins go crazy to figure out why, and after a couple of weeks, they've found it was due to a registry change. Not that I am trying to talk you out of it or not, I'm just noting what can occur, and my preferences (including many others), to try not to modify default functionality.

Ace

Ace,
Thanks for your response. I know what you mean about not changing
"defaults", unfortunately the customer has these requirements and if it's
done it will be under they decision.
I was actually wondering if someone has ever actually tried something
similar like the granular delegation in that MS document. if it's functional
or just complicates things at the end without achieving the delgation goals
--
XER


"Ace Fekay [MVP-DS, MCT]" wrote:

> "Lobo" <Lobo@discussions.microsoft.com> wrote in message news:E7A8F444-ECA0-4723-B292-21CB761EF9ED@microsoft.com...
> > Yes but I am referring to do something similar according to this MS document
> > that you can modify the AdminSDHolder and revoke permissions for protected
> > groups (page 154).
> >
> > Best Practices for Delegating Active Directory Administration
> > http://www.microsoft.com/downloads/d...displaylang=en
> > --
> > XER
>
> I didn't know that. You didn't mention that earlier. No, I'm sorry I have not tried to modify this feature. I've found delegation to be sufficient for what I've designed in the past, even for a 5000 user, multi-domain forest. We just never give anyone that is not a domain admin access to a DC and provide the adminpak tools to ONLY provide the ADUC console and nothing else. Kind of like increased security within design parameters. Anytime a mod if attempted, it complicates things, especially trying to support it later down the line, including if there is sufficient documentation. I've seen that before, including with modifying registery settings for multihomed DCs. later on, when something comes up and wondering why registration doesn't work when an IP change is made, the admins go crazy to figure out why, and after a couple of weeks, they've found it was due to a registry change. Not that I am trying to talk you out of it or not, I'm just noting what can occur, and my preferences
(including many others), to try not to modify default functionality.
>
> Ace
>
>
> .
>

Hello Lobo,

Sorry for being that late, but as Ace already stated i also never changes
the defaults. If the customer still want's it, create a lab, maybe from the
production and test it first to see what's going on.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> Ace, Thanks for your response. I know what you mean about not changing
> "defaults", unfortunately the customer has these requirements and if
> it's done it will be under they decision. I was actually wondering if
> someone has ever actually tried something similar like the granular
> delegation in that MS document. if it's functional or just complicates
> things at the end without achieving the delgation goals
>
> "Ace Fekay [MVP-DS, MCT]" wrote:
>
>> "Lobo" <Lobo@discussions.microsoft.com> wrote in message
>> news:E7A8F444-ECA0-4723-B292-21CB761EF9ED@microsoft.com...
>>
>>> Yes but I am referring to do something similar according to this MS
>>> document that you can modify the AdminSDHolder and revoke
>>> permissions for protected groups (page 154).
>>>
>>> Best Practices for Delegating Active Directory Administration
>>>
>>> http://www.microsoft.com/downloads/d...id=631747a3-79
>>> e1-48fa-9730-dae7c0a1d6d3&displaylang=en
>>>
>>> --
>>>
>>> XER
>>>
>> I didn't know that. You didn't mention that earlier. No, I'm sorry I
>> have not tried to modify this feature. I've found delegation to be
>> sufficient for what I've designed in the past, even for a 5000 user,
>> multi-domain forest. We just never give anyone that is not a domain
>> admin access to a DC and provide the adminpak tools to ONLY provide
>> the ADUC console and nothing else. Kind of like increased security
>> within design parameters. Anytime a mod if attempted, it complicates
>> things, especially trying to support it later down the line,
>> including if there is sufficient documentation. I've seen that
>> before, including with modifying registery settings for multihomed
>> DCs. later on, when something comes up and wondering why registration
>> doesn't work when an IP change is made, the admins go crazy to figure
>> out why, and after a couple of weeks, they've found it was due to a
>> registry change. Not that I am trying to talk you out of it or not,
>> I'm just noting what can occur, and my preferences
>>
> (including many others), to try not to modify default functionality.
>
>> Ace
>>
>> .
>>

"Lobo" <Lobo@discussions.microsoft.com> wrote in message news:85D4BB8F-4C06-469A-B5D5-8A268428C4F5@microsoft.com...
> Ace,
> Thanks for your response. I know what you mean about not changing
> "defaults", unfortunately the customer has these requirements and if it's
> done it will be under they decision.
> I was actually wondering if someone has ever actually tried something
> similar like the granular delegation in that MS document. if it's functional
> or just complicates things at the end without achieving the delgation goals
> --
> XER

I second Meinolf's suggestion. Try it in a test lab.

Ace

Ace/Meinolf,
There's no other choice but testing in a lab I guess. Thanks for your input.
If anyone else has done something similar, I'd appreciate your comments.
--
XER


"Ace Fekay [MVP-DS, MCT]" wrote:

> "Lobo" <Lobo@discussions.microsoft.com> wrote in message news:85D4BB8F-4C06-469A-B5D5-8A268428C4F5@microsoft.com...
> > Ace,
> > Thanks for your response. I know what you mean about not changing
> > "defaults", unfortunately the customer has these requirements and if it's
> > done it will be under they decision.
> > I was actually wondering if someone has ever actually tried something
> > similar like the granular delegation in that MS document. if it's functional
> > or just complicates things at the end without achieving the delgation goals
> > --
> > XER
>
> I second Meinolf's suggestion. Try it in a test lab.
>
> Ace
>
>
> .
>

"Lobo" <Lobo@discussions.microsoft.com> wrote in message news:A7ADB142-47F0-4AB0-88C5-A29FAC35B6C0@microsoft.com...
> Ace/Meinolf,
> There's no other choice but testing in a lab I guess. Thanks for your input.
> If anyone else has done something similar, I'd appreciate your comments.
> --
> XER
>

You are welcome. The best way to do it in a lab is to use VMs.

Ace