Re: Security Treats

From: Oli Restorick [MVP] (oli_at_mvps.org)
Date: 09/29/04 

Date: Wed, 29 Sep 2004 22:42:53 +0100

When I said "Make sure your workstation accounts reside in an OU", that may
have been confusing. What I meant was the computer accounts for your
workstations, or more simply, the computer objects.

Cheers

Oli

"Oli Restorick [MVP]" <oli@mvps.org> wrote in message
news:OEWxewmpEHA.3572@TK2MSFTNGP10.phx.gbl...
> That may be a possibility (although I understood that it wasn't all that
> easy), but it wasn't what I was thinking.
>
> Think about your machine and what happens when you log in. When you log
> in, several programs can start in the background, because they're in the
> computer's "startup" group, or other launching points.
>
> Now, imagine that a malicious user wants to gain domain admin access. All
> he has to do is to make a script that will add a new user to the domain
> and give that user domain admin rights, make that script launch when
> somebody logs in and then persuade an administrator to come over and fix
> some "problem". When they log in, the administrator unwittingly gives
> away domain admin.
>
> This isn't a bug or a problem in Windows and Microsoft aren't going to
> "fix" this.
>
> Now, it may be the case that you don't give your users the power user or
> administrator level access to the local machine that's required to cause
> things to run when somebody logs into a machine.
>
> That's good, but there are two reasons why this is not enough. The first
> is that there's nearly always a gap between what you think is true and
> what is actually true. You may think that nobody has power user or
> administrator to any machines, but this is an common way to make some
> poorly-written software run.
>
> The other reason is that if sombody has physical access to your computer,
> they can change the way that computer behaves. Sure, it may take some
> effort, but given the right software, it's actually not difficult to gain
> local admin access given physical access to a machine.
>
> So, how should you change your ways and still allow you or your helpdeesk
> people to do their job? If you have group policy, it's fairly easy.
>
> Create a new security group and call it, say, "Helpdesk". Create some
> workstation admin accounts and place them in the group.
>
> Make sure your workstation accounts reside in an OU (rather than the
> default "computers" container) and create a new group policy object on
> that OU.
>
> Then, create a new Group Policy object and set up a computer startup
> script
> (Computer Configuration | Windows Settings | Scripts (Startup/Shutdown) |
> Startup
>
> For name, use "net"
> For parameters, use "localgroup administrators domain\helpdesk /add"
>
> This will execute the command "net localgroup administrators
> domain\helpdesk /add" each time a machine affected by the policy boots.
>
> Additionally, you should aim to not even log in at your own workstation
> with domain admin credentials. You can do this and still allow your
> regular accouunt to do day-to-day activities such as creating users and
> resetting passwords by using the delegation of control wizard. If you do
> this, make sure you always delegate permissions to a group, rather than
> individual users.
>
> Hope this helps
>
> Oli
>
>
>
>
>
>
> <anonymous@discussions.microsoft.com> wrote in message
> news:2d7b01c4a4a6$3bb831b0$a301280a@phx.gbl...
>> Oli - why?
>> I realize it creates a local domain admin profile. Is
>> this so that someone doesn't use L0ft or the like to
>> extract the password? Thanks.
>
>

Relevant Pages

  • Re: Security Treats
    ... imagine that a malicious user wants to gain domain admin access. ... the administrator unwittingly gives away ... If you have group policy, ... Make sure your workstation accounts reside in an OU (rather than the default ...
    (microsoft.public.win2000.security)
  • Re: Security Filtering does not work correctly in GPO
    ... Did you removed the Authenticated Users from apply GPO ... Systems Administrator ... "Scope-Setting" in the Group Policy object. ... The domain admin shouln't receive this settings. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Security Treats
    ... imagine that a malicious user wants to gain domain admin access. ... > somebody logs in and then persuade an administrator to come over and fix ... If you have group policy, ... > workstation admin accounts and place them in the group. ...
    (microsoft.public.win2000.security)
  • Re: Security Filtering does not work correctly in GPO
    ... And the domain admin is NOT a member of this group. ... "User Group" has applied to the administrator, because i could not open any ... Also i supplied this GPO with a Security Filter so that the settings ... "Scope-Setting" in the Group Policy object. ...
    (microsoft.public.windows.server.active_directory)