Re: Local admin user rights on remote DC
From: Steven L Umbach (n9rou_at_nospam-comcast.net)
Date: 10/16/04
- Previous message: Joe Richards [MVP]: "Re: Replacing domain SID on ACE's in DACL"
- In reply to: lvm: "Re: Local admin user rights on remote DC"
- Next in thread: Colin Nash [MVP]: "Re: Local admin user rights on remote DC"
- Reply: Colin Nash [MVP]: "Re: Local admin user rights on remote DC"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 16 Oct 2004 11:15:59 -0500
I missed that part of your requirements. To manually install software on a
domain controller, they will need to be a domain administrator. There simply
is no workaround. What may work is if you temporarily add them to the domain
admins group just to do that function and then remove them. Of course you
run the risk that they could do other admin functions like change policy,
permissions, or group memberships in the meantime. You could check group
membership later for the admin groups to make sure that they have not added
unauthorized accounts. While the principle of least needed privileges is a
core part of securing a network, most good employees have no desire to do
malicious acts to the network if given elevates privileges for a short
period of time and they may not even realize they have admin access. Using
Group Policy to deny their user accounts to specific mmc snapins they do not
need to use may also be helpful if you end up doing that to deter the idle
curious. Another option is if the software that needs to be installed are
.msi packages or can be converted to .msi packages, you can use Group Policy
Software Installation to "assign" those packages to the domain controllers.
See the link below for more info on that. --- Steve
http://www.microsoft.com/windows2000/techinfo/planning/management/swinstall.asp
-- Group Policy Software installation
"lvm" <lvm@erudict.com> wrote in message
news:bf012c14.0410150652.7e7208a7@posting.google.com...
> Hello,
>
> I have implemented the site specific OU's in the Domain controllers OU
> and created a global security group per site to group the site
> specific local admins. The deny policy is implemented like suggested,
> but we miss one important permission for the local admins: they can
> not install any software specific for the site (like antivirus,
> backup,...)
>
> In our case it is of secondary importance that local admins cannot
> logon when the DC is down as these DC's host an Exchange 2003 server.
> So the server must be up and running asap.
>
> regards,
>
> Luc
>
> "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
> news:<u40icImsEHA.904@TK2MSFTNGP11.phx.gbl>...
>> It probably would unless they can logon with cached credentials. It might
>> be
>> a good idea for them to have another regular domain account that did not
>> have membership in the denied group in case that happened. --- Steve
>>
>>
>> "Colin Nash [MVP]" <cnash x@x mvps.org> wrote in message
>> news:eCm4U8ksEHA.220@TK2MSFTNGP15.phx.gbl...
>> >
>> > "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
>> > news:%23A$y$lUsEHA.3788@TK2MSFTNGP15.phx.gbl...
>> >> Unfortunate there is no power user local equivalent on domain
>> >> controllers. Your options are delegation, privileged group membership
>> >> [server operators, etc], or user rights assignments. What may work is
>> >> if
>> >> you create a sub Organizational Unit for each site in the domain
>> >> controller container. Then create a global group for each site that
>> >> includes your site administrators. Then create a GPO for each sub OU
>> >> and
>> >> configure the user rights for deny logon locally, deny access this
>> >> computer from the network, and deny logon through Remote Desktop [if
>> >> available] to include the global groups from the other sites for the
>> >> site
>> >> administrators. Then move the domain controllers into the sub OU for
>> >> each
>> >> site. You would not have to configure any other settings for the GPO's
>> >> for the sites and they will still inherit the Domain Security Policy
>> >> settings except for what you define in each sub OU. Do NOT remove
>> >> domain
>> >> controllers out from the domain controller container structure, but
>> >> sub
>> >> Organizational Units of the domain controller container should work
>> >> fine.
>> >> If you are interested, try testing with one site first to see if users
>> >> in
>> >> the server operators, etc groups from another site are prevented from
>> >> managing restricted domain controllers through Computer Management,
>> >> Remote Dektop, command line, tc. --- Steve
>> >>
>> >>
>> >
>> > If you block the other admins from accessing the other DCs over the
>> > network, would this cause problems if they need to log on and the DCs
>> > at
>> > their own sites are down for some reason?
>> >
>> >
- Previous message: Joe Richards [MVP]: "Re: Replacing domain SID on ACE's in DACL"
- In reply to: lvm: "Re: Local admin user rights on remote DC"
- Next in thread: Colin Nash [MVP]: "Re: Local admin user rights on remote DC"
- Reply: Colin Nash [MVP]: "Re: Local admin user rights on remote DC"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|