Re: disclosure the administrative password

From: James Eaton-Lee (james.mailing_at_gmail.com)
Date: 02/08/05

  • Next message: Tyson Leslie: "RE: Password Protected Screen Saver and Administrative Password"
    To: Mike Groh <lists@mikegroh.net>
    Date: Tue, 08 Feb 2005 21:44:12 +0000
    
    

    Mike,

    If you create an account in the domain which your workstations are a
    part of and only make it a member of the 'administrators' group (not
    enterprise or domain admins), this user should have access as local
    administrator only - but to *all* machines (ie. they have access as a
    local admin to your domain controllers and servers).

    What you'll need to do in order to give people access solely
    workstations, therefore, is to specifically create a group *just* for
    local administrators of workstations. This method (rather than simply
    adding users to administrators for the entire domain) is far more
    powerful, and much less clumsy - allowing you to, for instance, revoke
    the privileges of the whole group in order to remove the policy with one
    alteration, instead of having to remove every user from the
    administrators group in a hurry.

    In order to accomplish this, you would need to do the following:

    i) Create an OU for your workstations and stick them in it (eg. the
    Workstations OU)
    [NOTE: you could also apply the following to an existing OU or multiple
    existing OUs.]

    i) Create a group for your workstation admins (eg. stationadmins)

    ii) Create a new group policy (right click on Workstations OU,
    Properties, group Policy, New) with a name which makes sense (eg.
    stationadminpolicy).

    iii) Click on 'Edit' for your new group policy. Navigate to the
    'Computer Configuration'>'Windows Settings'>'Restricted Groups'

    The Restricted groups policy allows you to restrict or allow different
    groups of users to be members of different groups; create a new group
    called 'administrators'. In the properties (Configure membership) window
    for this policy, the top box (Members of this group) defines who is a
    member of the restricted group (which is called administrators) which
    you have created. In this box, add your new group (stationadmin), and
    any other groups on the domain who you want to be a member of the local
    administrators group (domain\domain administrators, domain\enterprise
    administrators, domain\administrators).

    IMPORTANT: If you set this policy for an OU *WITHOUT* adding the other
    groups on the domain which you want to be members of the local
    administrators group, then the 'other groups' (such as enterprise
    administrators) will *NOT* be members of the local administrators group,
    as the Restricted Group policy will override the windows default. For
    this reason, I recommend that you test this thoroughly first on a test
    OU!

    This defines your policy to your group (stationadmins) rather than to
    individual users, which is 'best practice' for Group Policy.

    Hope this helps! Let me know if you have any queries about this or have
    any other queries!

     - James.

    On Mon, 2005-02-07 at 21:46 -0800, Mike Groh wrote:
    > The workstation admin idea sounds good to me. I want to do it in my
    > network. Is there a way to easily push this policy to the workstations.
    > Win2k3 server (AD) and XP workstations? I'm assuming it would involve
    > GPO but I have very little experience with it.
    >
    > Thank You,
    >
    > -Mike
    >
    >
    > d.pigna@email.it wrote:
    >
    > > Hi Boris
    > >
    > > What about something like:
    > >
    > > 1) Create a WorkstationAdmin who has admin privileges on workstations
    > > (local admin), and NOT on servers, active directory, network folders,
    > > etc...
    > > This will ensure, if the password is compromised, that only your
    > > workstations will be at risk.
    > >
    > > 2) If you have several OUs and several Local
    > > Administrators/Supervisors, create different WorkstationAdmins.
    > > Again: the lowest number of machines compromised in case someone will
    > > get this password.
    > >
    > > 3) Change this password(s) EVERY DAY. Or every hour.
    > >
    > >
    > > A question from my side, now.
    > >
    > > How many times these operations are performed every day???
    > >
    > > Everyday operations have to be easy and fast. In this case, I suggest
    > > you to give your Supervisors a wide range of "freedom".
    > > Otherwise you'll get a call everytime a normal maintenance operation
    > > is performed on a remote, lonely and unuseful machine (something you
    > > don't want to happen).
    > > It's better to have 5 workstations compromised every year - that need
    > > to be reinstalled - than 50 calls every day.
    > >
    > > How many workstations/LocalAdmins do you have???
    > >
    > > Is there a REAL security risk in your environment? Who can be really
    > > dangerous for you? If you're at risk, and you have to protect sensible
    > > information, you'll need to give up on usability, and go for the
    > > security (i.e. change LocalAdmins passwords everyday).
    > > If you don't have something really important to protect... c'mon, just
    > > make LocalAdmin life easy.
    > >
    > > If you're managing 10.000 machines in a high school, what data are you
    > > trying to protect on every single workstation? PPT files for the art
    > > teacher and some stupid videos downloaded from students?? ;-)
    > > Let them play, and mess up!
    > >
    > >
    > > It could be nice to have a final report on this question...
    > > Something that will put together all these suggestions and try to line
    > > out a security model (from very weak to very strong) for different
    > > security needs.
    > >
    > > Hope this helped.
    > > Davide
    > >
    > >
    > >
    > > Boris Skoblo wrote:
    > >
    > >>
    > >>>> Hi All,
    > >>>>
    > >>>> There is a usual situation: on normal users computers ( W2k and
    > >>>> Winxp ) an administrator should perform an administrative actions
    > >>>> (for example, with help RunAs) thus the administrative password is
    > >>>> entered. Do exist a potential possibility that on the user's computer
    > >>>> there is keylogger.
    > >>>>
    > >>>>
    > >>>> What ways to perform administrative operations exist, thus not
    > >>>> endangering disclosure the administrative password? There are some
    > >>>> limitations:
    > >>>>
    > >>>> 1. usage of smarts-cards and others hardvare devices are not
    > >>>> applicable .
    > >>>>
    > >>>> 2. performed operations cannot be delegated for various reasons
    > >>>>
    > >>>> 3. keylogger is custom designed and any of existing protective
    > >>>> software yet does not find out it
    > >>>>
    > >>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    > >>>
    > >>>
    > >
    > >
    > >
    > > ---------------------------------------------------------------------------
    > >
    > > ---------------------------------------------------------------------------
    > >
    > >
    > >
    > >
    >
    >
    > ---------------------------------------------------------------------------
    > ---------------------------------------------------------------------------
    >

    ---------------------------------------------------------------------------
    ---------------------------------------------------------------------------


  • Next message: Tyson Leslie: "RE: Password Protected Screen Saver and Administrative Password"

    Relevant Pages

    • Re: Administrators Group in Local Users and Groups
      ... I had it set up right, it just took a while to get out to the workstations. ... > right click on restricted groups and select new group (For the local ... this group name should be - administrators) and key in the ... Select add on the Members of this group and then ...
      (microsoft.public.windows.server.active_directory)
    • RE: Customize User Rights for Domain Admins Group
      ... workstation administrators members of the Domain Admins group for them to ... Add your new group and Domain Admins. ... Then link this GPO to your OU's that contain your workstations and your ...
      (microsoft.public.windows.server.active_directory)
    • Re: help desk authority
      ... Use a Restricted Groups feature of the Group Policy to include a ... HelpDeskAdmins group (or whatever the name is for the group where your ... apply this policy to an OU with all workstations they need to manage. ... >> from (currently in the administrators group). ...
      (microsoft.public.windows.server.active_directory)
    • Re: Local Group Recursion, Creation, and GP
      ... Rather than using scripts to populate local groups (e.g. Administrators) consider using ... administer them largely by Group Policy. ... the system never allows members of System Specialists to log in. ...
      (microsoft.public.windows.group_policy)
    • Re: Desktop Support Members / Active Directory
      ... local Administrators Group., allowing members of the Desktop Support Group ... administrator access on user workstations. ... I have tested this by using restricted groups via Group Policy, ...
      (microsoft.public.windows.server.active_directory)