creator/owner NTFS permissions

Archived from groups: microsoft.public.win2000.security (More info?)

The question is - how do we deny the Creator of a Folder the ability to
change ntfs permissions on folders they create?

We have a large amount of shared disk storage for users and groups to use
for their work files. We set up a basic folder structure based on
organization and job function with permissions typically to either
change(R/W) or read(R/O) based mainly on groups. Users/groups do not have
the option to change permissions for the folders we create. For support and
sys admin work IT needs access to all the folder (VERY rarely otherwise) and
this is OKed by our company policies. As the storage grows and evolves,
users create new folders in areas they have rights to and that is fine.
However, we have the occasional curious user who feels the need and
discovers the ability to change permissions for the folders they create -
they are that ubermensch, the CREATOR/OWNER. They often take away system
rights, etc and backups and other things don't work. It seems from our
experimenting that they need Full Control (both Change Permissions and Take
Ownership) to create a new folder. We see folders with all rights taken
away; we have to take ownership to see the empty permissions list.
Inevitably these users are those most in need of support, like file
restores, because they like to "do things." We don't find out that they've
been messing with permissions until there is a problem. By then the horse
is long gone, out the wide-open barn door. We can only shrug while they
wail about "how we could let them do that to themselves." Other than the
larger cultural issue of getting people to take intelligent responsiblity
for their actions, we're looking for a solution to our little problem - how
to close the barn door.
3 answers Last reply
More about creator owner ntfs permissions
  1. Archived from groups: microsoft.public.win2000.security (More info?)

    As long as they are the owner you can't. So either you can take ownership
    away from them via batch files with file utulities such as fileacl or you
    can restrict their access to the security page in folder/file propertiesand
    restrict their use of command line utilities such as cacls, xcacls, fileacl,
    etc.

    Windows XP has a Group Policy setting to disable the security tab on folder
    properties and you can use Software Restriction Policies to disable the use
    of executeables with certificate, hash, or patch rules. You can mange XP Pro
    Group Policy settings in a Windows 2000 domain in a couple of ways with one
    being from an XP Pro domain computer. The link below shows more details on
    that.

    http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/mngwinxp.mspx

    For Windows 2000 computers it is more difficult to implement, but see the
    two links below.

    http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b303153
    http://support.microsoft.com/default.aspx?scid=kb;en-us;193826 --- works on
    W2K also.

    To prevent users from running Windows applications, you can populate the
    disallowed Windows Applications list in Group Policy under user
    configuration/administrative templates/system. Be sure to read the full
    explaination of what that setting does and test out entries to see if it
    works or not for a particular .exe. While there you may also want to disable
    the command prompt and registry editing for users again after reading the
    full explaination as disabling the command prompt can cause some scripts to
    fail. If a user renames an executeable, they will be able to bypass that GP
    setting that resticts it. --- Steve

    "jack schweigel" <CauldronXX@yahoo.com> wrote in message
    news:us4fhF4iEHA.3972@tk2msftngp13.phx.gbl...
    > The question is - how do we deny the Creator of a Folder the ability to
    > change ntfs permissions on folders they create?
    >
    > We have a large amount of shared disk storage for users and groups to use
    > for their work files. We set up a basic folder structure based on
    > organization and job function with permissions typically to either
    > change(R/W) or read(R/O) based mainly on groups. Users/groups do not have
    > the option to change permissions for the folders we create. For support
    and
    > sys admin work IT needs access to all the folder (VERY rarely otherwise)
    and
    > this is OKed by our company policies. As the storage grows and evolves,
    > users create new folders in areas they have rights to and that is fine.
    > However, we have the occasional curious user who feels the need and
    > discovers the ability to change permissions for the folders they create -
    > they are that ubermensch, the CREATOR/OWNER. They often take away system
    > rights, etc and backups and other things don't work. It seems from our
    > experimenting that they need Full Control (both Change Permissions and
    Take
    > Ownership) to create a new folder. We see folders with all rights taken
    > away; we have to take ownership to see the empty permissions list.
    > Inevitably these users are those most in need of support, like file
    > restores, because they like to "do things." We don't find out that
    they've
    > been messing with permissions until there is a problem. By then the horse
    > is long gone, out the wide-open barn door. We can only shrug while they
    > wail about "how we could let them do that to themselves." Other than the
    > larger cultural issue of getting people to take intelligent responsiblity
    > for their actions, we're looking for a solution to our little problem -
    how
    > to close the barn door.
    >
    >
  2. Archived from groups: microsoft.public.win2000.security (More info?)

    The Ayn Rand-esque issue of ownership is interesting; just because someone
    'creates' something, why can they destroy or disable it? Should they be
    allowed to? I built my own house, but, as far as I can tell, I can't burn
    it down or even contravene the codes to which it was built if I want to make
    a change. Is there any chance that MS will 'fix' this, so that there is a
    true enterprise/server implementation where the network/system/policies can
    control permissions activity? Because of company IT policy you might even
    want to allow creator/owner to have full control, but make the option
    available to deny that and still have the file system work. A Vax or AS400
    does this just fine, but Windows is still in the "Personal" computing realm.
    Oh, joy; to be free, nothing left to lose (except your files)! Thank you,
    Janis.


    "Steven L Umbach" <n9rou@N0sPaM-comcast.net> wrote in message
    news:P9yXc.67500$Fg5.40748@attbi_s53...
    > As long as they are the owner you can't. So either you can take ownership
    > away from them via batch files with file utulities such as fileacl or you
    > can restrict their access to the security page in folder/file
    > propertiesand
    > restrict their use of command line utilities such as cacls, xcacls,
    > fileacl,
    > etc.
    >
    > Windows XP has a Group Policy setting to disable the security tab on
    > folder
    > properties and you can use Software Restriction Policies to disable the
    > use
    > of executeables with certificate, hash, or patch rules. You can mange XP
    > Pro
    > Group Policy settings in a Windows 2000 domain in a couple of ways with
    > one
    > being from an XP Pro domain computer. The link below shows more details on
    > that.
    >
    > http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/mngwinxp.mspx
    >
    > For Windows 2000 computers it is more difficult to implement, but see the
    > two links below.
    >
    > http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b303153
    > http://support.microsoft.com/default.aspx?scid=kb;en-us;193826 --- works
    > on
    > W2K also.
    >
    > To prevent users from running Windows applications, you can populate the
    > disallowed Windows Applications list in Group Policy under user
    > configuration/administrative templates/system. Be sure to read the full
    > explaination of what that setting does and test out entries to see if it
    > works or not for a particular .exe. While there you may also want to
    > disable
    > the command prompt and registry editing for users again after reading the
    > full explaination as disabling the command prompt can cause some scripts
    > to
    > fail. If a user renames an executeable, they will be able to bypass that
    > GP
    > setting that resticts it. --- Steve
    >
    > "jack schweigel" <CauldronXX@yahoo.com> wrote in message
    > news:us4fhF4iEHA.3972@tk2msftngp13.phx.gbl...
    >> The question is - how do we deny the Creator of a Folder the ability to
    >> change ntfs permissions on folders they create?
    >>
    >> We have a large amount of shared disk storage for users and groups to use
    >> for their work files. We set up a basic folder structure based on
    >> organization and job function with permissions typically to either
    >> change(R/W) or read(R/O) based mainly on groups. Users/groups do not
    >> have
    >> the option to change permissions for the folders we create. For support
    > and
    >> sys admin work IT needs access to all the folder (VERY rarely otherwise)
    > and
    >> this is OKed by our company policies. As the storage grows and evolves,
    >> users create new folders in areas they have rights to and that is fine.
    >> However, we have the occasional curious user who feels the need and
    >> discovers the ability to change permissions for the folders they create -
    >> they are that ubermensch, the CREATOR/OWNER. They often take away system
    >> rights, etc and backups and other things don't work. It seems from our
    >> experimenting that they need Full Control (both Change Permissions and
    > Take
    >> Ownership) to create a new folder. We see folders with all rights taken
    >> away; we have to take ownership to see the empty permissions list.
    >> Inevitably these users are those most in need of support, like file
    >> restores, because they like to "do things." We don't find out that
    > they've
    >> been messing with permissions until there is a problem. By then the
    >> horse
    >> is long gone, out the wide-open barn door. We can only shrug while they
    >> wail about "how we could let them do that to themselves." Other than the
    >> larger cultural issue of getting people to take intelligent responsiblity
    >> for their actions, we're looking for a solution to our little problem -
    > how
    >> to close the barn door.
    >>
    >>
    >
    >
  3. Archived from groups: microsoft.public.win2000.security (More info?)

    I believe it is also a security issue in that an administrator can not access files
    that he does not have permissions to unless he first takes ownership which would be
    evidence that the file has been accessed by that administrator and no longer the
    original creator. It would be nice if the owner would also have to be an
    administrator in order to change permissions however or at least have that available
    as an option. --- Steve


    "jaxon" <CauldronXX@yahoo.com> wrote in message
    news:O2qP2BqjEHA.3712@TK2MSFTNGP15.phx.gbl...
    > The Ayn Rand-esque issue of ownership is interesting; just because someone
    > 'creates' something, why can they destroy or disable it? Should they be allowed
    > to? I built my own house, but, as far as I can tell, I can't burn it down or even
    > contravene the codes to which it was built if I want to make a change. Is there
    > any chance that MS will 'fix' this, so that there is a true enterprise/server
    > implementation where the network/system/policies can control permissions activity?
    > Because of company IT policy you might even want to allow creator/owner to have
    > full control, but make the option available to deny that and still have the file
    > system work. A Vax or AS400 does this just fine, but Windows is still in the
    > "Personal" computing realm. Oh, joy; to be free, nothing left to lose (except your
    > files)! Thank you, Janis.
    >
    >
    > "Steven L Umbach" <n9rou@N0sPaM-comcast.net> wrote in message
    > news:P9yXc.67500$Fg5.40748@attbi_s53...
    >> As long as they are the owner you can't. So either you can take ownership
    >> away from them via batch files with file utulities such as fileacl or you
    >> can restrict their access to the security page in folder/file propertiesand
    >> restrict their use of command line utilities such as cacls, xcacls, fileacl,
    >> etc.
    >>
    >> Windows XP has a Group Policy setting to disable the security tab on folder
    >> properties and you can use Software Restriction Policies to disable the use
    >> of executeables with certificate, hash, or patch rules. You can mange XP Pro
    >> Group Policy settings in a Windows 2000 domain in a couple of ways with one
    >> being from an XP Pro domain computer. The link below shows more details on
    >> that.
    >>
    >> http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/mngwinxp.mspx
    >>
    >> For Windows 2000 computers it is more difficult to implement, but see the
    >> two links below.
    >>
    >> http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b303153
    >> http://support.microsoft.com/default.aspx?scid=kb;en-us;193826 --- works on
    >> W2K also.
    >>
    >> To prevent users from running Windows applications, you can populate the
    >> disallowed Windows Applications list in Group Policy under user
    >> configuration/administrative templates/system. Be sure to read the full
    >> explaination of what that setting does and test out entries to see if it
    >> works or not for a particular .exe. While there you may also want to disable
    >> the command prompt and registry editing for users again after reading the
    >> full explaination as disabling the command prompt can cause some scripts to
    >> fail. If a user renames an executeable, they will be able to bypass that GP
    >> setting that resticts it. --- Steve
    >>
    >> "jack schweigel" <CauldronXX@yahoo.com> wrote in message
    >> news:us4fhF4iEHA.3972@tk2msftngp13.phx.gbl...
    >>> The question is - how do we deny the Creator of a Folder the ability to
    >>> change ntfs permissions on folders they create?
    >>>
    >>> We have a large amount of shared disk storage for users and groups to use
    >>> for their work files. We set up a basic folder structure based on
    >>> organization and job function with permissions typically to either
    >>> change(R/W) or read(R/O) based mainly on groups. Users/groups do not have
    >>> the option to change permissions for the folders we create. For support
    >> and
    >>> sys admin work IT needs access to all the folder (VERY rarely otherwise)
    >> and
    >>> this is OKed by our company policies. As the storage grows and evolves,
    >>> users create new folders in areas they have rights to and that is fine.
    >>> However, we have the occasional curious user who feels the need and
    >>> discovers the ability to change permissions for the folders they create -
    >>> they are that ubermensch, the CREATOR/OWNER. They often take away system
    >>> rights, etc and backups and other things don't work. It seems from our
    >>> experimenting that they need Full Control (both Change Permissions and
    >> Take
    >>> Ownership) to create a new folder. We see folders with all rights taken
    >>> away; we have to take ownership to see the empty permissions list.
    >>> Inevitably these users are those most in need of support, like file
    >>> restores, because they like to "do things." We don't find out that
    >> they've
    >>> been messing with permissions until there is a problem. By then the horse
    >>> is long gone, out the wide-open barn door. We can only shrug while they
    >>> wail about "how we could let them do that to themselves." Other than the
    >>> larger cultural issue of getting people to take intelligent responsiblity
    >>> for their actions, we're looking for a solution to our little problem -
    >> how
    >>> to close the barn door.
    >>>
    >>>
    >>
    >>
    >
    >
Ask a new question

Read More

NTFS Permissions Windows