Re: Restricted User Group

From: Will (westes-usc_at_noemail.nospam)
Date: 11/06/05

  • Next message: Steven L Umbach: "Re: Restricted User Group" 
    Date: Sun, 6 Nov 2005 12:46:06 -0800

    Why would I consider it a feature to have a user who authenticates as *any*
    valid user on my domain through Run As to be granted yet another permission
    that I didn't know was there and that I didn't want her to have?

    It's hard enough to secure a Microsoft computer when you think in terms of
    just two groups: Users and Administrators. There are six or seven places
    on the file system you need to change, numerous places in the registry, and
    then you have to debug both registry and file system for specific
    applications that need to execute under User control on a given computer.
    If I leave Restricted in as you describe it here, now I have to contend with
    someone who is a simple user suddently being granted elevated privileges on
    the system simply because they reauthenticated to the system via Run As?
    That creates an obvious back door into the registry for anyone who
    understands its weak spots better than I do. I don't suppose you know of a
    whitepaper on the subject of Run As or Restricted? No doubt removing it
    will have some side effect, and I want to understand it better. But I'm
    not seeing anything here I would call a customer benefit or a feature.
    Maybe it is an unpleasant and necessary hack.

    The reason I don't like "Authenticated Users" is that it will accept any
    user with a token from any domain in your forest. If you have a lower
    security environment like a lab, now anyone on one of those machines has
    access to many resources on all of your Domains. So in order to avoid the
    risk of one rogue user exposing one machine on your network by compromising
    the Users group on that one machine, you have instead exposed every
    computing resource on your network. That's not a good tradeoff!

    What would be a really nice tool would be a service that audits the contents
    of groups on every machine of a network. If it finds any group that
    doesn't match specific criteria, then it immediately notifies an
    administrator. It might even be proactive in removing certain userids
    from certain groups, and you give a good example of one you might want to
    exclude: guests. If anyone knows of such an audit tool/service, I would
    appreciate a URL to it. 

    -- 
Will
"Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
news:%23hpWBwp4FHA.252@TK2MSFTNGP15.phx.gbl...
> When you use runas the restricted identity is added to your security
token.
> Restricted identity has limited permissions in access control lists and
> apparently it is there to insure that the user using runas has those
needed
> permissions in case you do not as the account you are logged on with.
System
> permissions do not apply to a user even if the user is using runas. From
> what I can tell if I use runas and specify an administrator account the
> operating system will let me run that particular application as an
> administrator but it does not change my security token to reflect
membership
> in the administrators group in order to protect the operating system from
> using administrator powers beyond running that specific application.
> Personally I don't see or have not heard or read of any risk in leaving
> restricted in the ACLs configured by default and would leave it alone so
as
> to not interfere with someone using runas. If you do not want to use runas
> for some reason the disable the secondary logon service. Certainly you
> should remove users/authenticates users/everyone from any ACL's where the
> result will be in users having excessive permissions in the spirit of
> principle of least privilege. Authenticated users has the advantage in
that
> it's membership can not be managed and will never contain anonymous or
> guests. It is possible for the guest account to be added to the users
group
> and that could be disastrous if the guest account was enabled.  NSA
security
> guides recommend using authenticated users when you want to grant access
to
> the general population.  --- Steve
>
>
>
> "Will" <westes-usc@noemail.nospam> wrote in message
> news:usNuwGp4FHA.700@TK2MSFTNGP15.phx.gbl...
> > Thanks for the definition of Restricted in the ACL lists.   I'm finding
> > this
> > entity in many of the registry ACLs.   If SYSTEM is already in the ACL,
> > why
> > would I also want to grant privileges to Restricted?    If I am using
Run
> > As
> > on a binary, won't the binary run in the security context of a specific
> > user
> > account, and wouldn't it be better to just have the ACLs refer to
specific
> > user groups rather than some generic entity?    I generally remove all
> > references to "Authenticated Users" in my ACLs since that and Everyone
> > grant
> > far too permissive access to resources.    I find that running with
Users
> > if
> > you want to have domain users access resources locally is usually
> > sufficient.
> >
> > In the case of Restricted, wouldn't it be enough to grant Administrators
> > and
> > SYSTEM access to all of the ACLs and just avoid Restricted?
> >
> > -- 
> > Will
> >
> >
> > "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
> > news:uKESv5o4FHA.2524@TK2MSFTNGP10.phx.gbl...
> >>      Restricted  An identity used by a process that is executed in a
> >> restricted security context. When you launch a program in Windows XP
> >> Professional with the graphical RunAs utility, selecting "Protect my
> >> computer and data from unauthorized program activity runs the program
> >> with
> > a
> >> restricted token that contains the S-5-12 SID.
  • Next message: Steven L Umbach: "Re: Restricted User Group"
    • Quantcast