Deny _WRITE_ access to a file

Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

Hi all!

I want to make sure that a group of users can't WRITE a set of files
that they have to be able to READ. The files belonging to that set
might change over time, so I want to make it part of a logon script.

The problem is, I can use CACLS / XCACLS to DENY ALL access to the
file. or to GRANT read, write, etc privileges to the files.. But I
can't use them (or, probaby, I don't know how to do it) to just deny
write permissions for a given group.

Is there some util that I might use, or do I have to resort to VBS to
accomplish what I need to do? IF that's the case, HOW do I do it
(sadly, whie I'm quite adept at batch scripting, VBS is not my forte).

Thanks a lot.

Javier J
9 answers Last reply
More about deny _write_ access file
  1. Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

    You are correct that xcacls.exe does not offer the granularity
    for Deny settings that you are after.
    You can download xcacls.vbs from the Microsoft site
    http://www.microsoft.com/downloads/details.aspx?FamilyID=0ad33a24-0616-473c-b103-c35bc2820bda&DisplayLang=en
    This does support the granularity you are after.

    However, a better solution might be reorganizing storage
    so that files in this category are within a subdirectory of
    their current location, rather than mixed into files of the
    other permissions category within a single directory.
    --
    Roger Abell
    Microsoft MVP (Windows Security)
    MCSE (W2k3,W2k,Nt4) MCDBA
    "Javier J" <no.mail@please.no> wrote in message
    news:cvc321lamb3mjim61lkfadd8f72kcdhc39@4ax.com...
    > Hi all!
    >
    > I want to make sure that a group of users can't WRITE a set of files
    > that they have to be able to READ. The files belonging to that set
    > might change over time, so I want to make it part of a logon script.
    >
    > The problem is, I can use CACLS / XCACLS to DENY ALL access to the
    > file. or to GRANT read, write, etc privileges to the files.. But I
    > can't use them (or, probaby, I don't know how to do it) to just deny
    > write permissions for a given group.
    >
    > Is there some util that I might use, or do I have to resort to VBS to
    > accomplish what I need to do? IF that's the case, HOW do I do it
    > (sadly, whie I'm quite adept at batch scripting, VBS is not my forte).
    >
    > Thanks a lot.
    >
    > Javier J
  2. Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

    "Javier J" <no.mail@please.no> wrote in message
    news:cvc321lamb3mjim61lkfadd8f72kcdhc39@4ax.com...
    > Hi all!
    >
    > I want to make sure that a group of users can't WRITE a set of files
    > that they have to be able to READ. The files belonging to that set
    > might change over time, so I want to make it part of a logon script.
    >
    > The problem is, I can use CACLS / XCACLS to DENY ALL access to the
    > file. or to GRANT read, write, etc privileges to the files.. But I
    > can't use them (or, probaby, I don't know how to do it) to just deny
    > write permissions for a given group.

    As a logon script, your code will run in the context of the user. If he has
    sufficient privileges to DENY himself write access, he has sufficient
    privileges to REVOKE this denial.

    Similarly, if he has ONLY READ/WRITE, but not FULL, then the script will
    fail to modify the permissions.

    > Is there some util that I might use, or do I have to resort to VBS to
    > accomplish what I need to do? IF that's the case, HOW do I do it
    > (sadly, whie I'm quite adept at batch scripting, VBS is not my forte).

    Doing permissions at the granular level from VBScript can be quite a chore.
    I would recommend that, using a privileged account, you permit the folders
    (and existing file) such that normal users can only read, and cannot write.
    New files created there will then inherit the same permissions/restrictions
    automatically.

    /Al
  3. Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:uIPY%23uNHFHA.2936@TK2MSFTNGP15.phx.gbl...
    > You are correct that xcacls.exe does not offer the granularity
    > for Deny settings that you are after.

    In addition to that, also consider that it is often more appropriate to
    simply not grant write access rather than actually denying it.

    /Al

    > You can download xcacls.vbs from the Microsoft site
    >
    http://www.microsoft.com/downloads/details.aspx?FamilyID=0ad33a24-0616-473c-b103-c35bc2820bda&DisplayLang=en
    > This does support the granularity you are after.
    >
    > However, a better solution might be reorganizing storage
    > so that files in this category are within a subdirectory of
    > their current location, rather than mixed into files of the
    > other permissions category within a single directory.
    > --
    > Roger Abell
    > Microsoft MVP (Windows Security)
    > MCSE (W2k3,W2k,Nt4) MCDBA
    > "Javier J" <no.mail@please.no> wrote in message
    > news:cvc321lamb3mjim61lkfadd8f72kcdhc39@4ax.com...
    > > Hi all!
    > >
    > > I want to make sure that a group of users can't WRITE a set of files
    > > that they have to be able to READ. The files belonging to that set
    > > might change over time, so I want to make it part of a logon script.
    > >
    > > The problem is, I can use CACLS / XCACLS to DENY ALL access to the
    > > file. or to GRANT read, write, etc privileges to the files.. But I
    > > can't use them (or, probaby, I don't know how to do it) to just deny
    > > write permissions for a given group.
    > >
    > > Is there some util that I might use, or do I have to resort to VBS to
    > > accomplish what I need to do? IF that's the case, HOW do I do it
    > > (sadly, whie I'm quite adept at batch scripting, VBS is not my forte).
    > >
    > > Thanks a lot.
    > >
    > > Javier J
    >
    >
  4. Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

    Al is quite right in picking up on your mention of use in a
    login script - which skipped my attention.
    To do as you had planned you would need to do this in
    a startup/shutdown script, not login/logoff script.

    However, you really, really would IMO be better off by
    restructuring so that all files with this requirement are in
    a folder with appropriate grants, not mixed in with other
    files in a folder where the default NTFS permissions will
    need to be changed.

    --
    Roger Abell
    Microsoft MVP (Windows Security)
    MCSE (W2k3,W2k,Nt4) MCDBA
    "Javier J" <no.mail@please.no> wrote in message
    news:cvc321lamb3mjim61lkfadd8f72kcdhc39@4ax.com...
    > Hi all!
    >
    > I want to make sure that a group of users can't WRITE a set of files
    > that they have to be able to READ. The files belonging to that set
    > might change over time, so I want to make it part of a logon script.
    >
    > The problem is, I can use CACLS / XCACLS to DENY ALL access to the
    > file. or to GRANT read, write, etc privileges to the files.. But I
    > can't use them (or, probaby, I don't know how to do it) to just deny
    > write permissions for a given group.
    >
    > Is there some util that I might use, or do I have to resort to VBS to
    > accomplish what I need to do? IF that's the case, HOW do I do it
    > (sadly, whie I'm quite adept at batch scripting, VBS is not my forte).
    >
    > Thanks a lot.
    >
    > Javier J
  5. Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

    Hi!!

    Thanks a lot for the response.

    First of all, regarding LOGON SCRIPT, the mistake is mine: What I was
    trying to talk about was a STARTUP script (if I'm not mistaken, that
    script runs as BUILTIN\SYSTEM).

    I think I'd rather explain a bit more about the envirnoment so that
    it's clear of why I'm asking for such strange things:

    The situation is as follows: The PCs in question (Win 200 PRO, SP4+,
    W2000 Mixed Domain) "belong" to a group of users who, as part of their
    normal duties, have to handle sensitive information using an internal
    company app. To avoid undue information leakage, these users have
    *TWO* logon users for the domain, a highly restricted one that is used
    to run the corporate app/access sensitve information, and a "Normal"
    user for the rest of everyday tasks.

    The "normal" user can run all software EXCEPT the restricted app, and
    can work normally.

    The setup for the restricted user (using GPO, crypto software et al)
    is such that the restricted user only can run the "sensitive" app,
    they can't browse or "see" in Explorer the local folders, their
    profile is redirected to an encrypted network etc etc...

    Also, using an STARTUP batch script, the members of the restricted
    group have been DENIED access to different .exes that restricted users
    should not run (ftp.exe, telnet.exe and other) and folders they don't
    need access to. (Windows already protects system folders against
    accidental change). The problem is, there are a couple of folders on
    C:\ (such as c:\local_settings) that the user logon needs to be able
    to read, because it sets machine-specific config. (such as the
    building's mail server, the NT server, and suchlike)

    The problem is that the folder is set to be writeable by "Everyone".
    I'd like to be able to "change" it so "no write" for the users of this
    particular group. I can DENY access, but these users are part of
    "Everyone", so even if "RestrictedG" has only READ acces, as they are
    members of "Everyone"; they get to write there...

    Why am I exploring the "deny" route, instead of limiting the rights of
    "Everyone".. because there are some cases where the normal users has
    to be able to write, so "Everyone:W" is a valid permission.... as long
    as I could do something like "RestrictedG":DENY WRITE....

    I know that permission is "settable" (is that a word?) as it can be
    set usign (the "simple) NTFS Perms. tab... but to script it is what is
    driving me crazy!!

    Thanks a lot. Any help _WILL_ Be more than welocome!!

    Javier J

    On Mon, 28 Feb 2005 22:12:30 -0700, "Roger Abell" <mvpNOSpam@asu.edu>
    wrote:

    >Al is quite right in picking up on your mention of use in a
    >login script - which skipped my attention.
    >To do as you had planned you would need to do this in
    >a startup/shutdown script, not login/logoff script.
    >
    >However, you really, really would IMO be better off by
    >restructuring so that all files with this requirement are in
    >a folder with appropriate grants, not mixed in with other
    >files in a folder where the default NTFS permissions will
    >need to be changed.
  6. Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

    "Javier J" <no.mail@please.no> wrote in message
    news:vpf921h1j3tgiliegad4u4kj7e7urhl72l@4ax.com...
    > Hi!!
    >
    > Thanks a lot for the response.
    >
    > First of all, regarding LOGON SCRIPT, the mistake is mine: What I was
    > trying to talk about was a STARTUP script (if I'm not mistaken, that
    > script runs as BUILTIN\SYSTEM).
    >
    > I think I'd rather explain a bit more about the envirnoment so that
    > it's clear of why I'm asking for such strange things:
    >
    > The situation is as follows: The PCs in question (Win 200 PRO, SP4+,
    > W2000 Mixed Domain) "belong" to a group of users who, as part of their
    > normal duties, have to handle sensitive information using an internal
    > company app. To avoid undue information leakage, these users have
    > *TWO* logon users for the domain, a highly restricted one that is used
    > to run the corporate app/access sensitve information, and a "Normal"
    > user for the rest of everyday tasks.
    >
    > The "normal" user can run all software EXCEPT the restricted app, and
    > can work normally.
    >
    > The setup for the restricted user (using GPO, crypto software et al)
    > is such that the restricted user only can run the "sensitive" app,
    > they can't browse or "see" in Explorer the local folders, their
    > profile is redirected to an encrypted network etc etc...
    >
    > Also, using an STARTUP batch script, the members of the restricted
    > group have been DENIED access to different .exes that restricted users
    > should not run (ftp.exe, telnet.exe and other) and folders they don't
    > need access to. (Windows already protects system folders against
    > accidental change). The problem is, there are a couple of folders on
    > C:\ (such as c:\local_settings) that the user logon needs to be able
    > to read, because it sets machine-specific config. (such as the
    > building's mail server, the NT server, and suchlike)
    >
    > The problem is that the folder is set to be writeable by "Everyone".
    > I'd like to be able to "change" it so "no write" for the users of this
    > particular group. I can DENY access, but these users are part of
    > "Everyone", so even if "RestrictedG" has only READ acces, as they are
    > members of "Everyone"; they get to write there...
    >
    > Why am I exploring the "deny" route, instead of limiting the rights of
    > "Everyone".. because there are some cases where the normal users has
    > to be able to write, so "Everyone:W" is a valid permission.... as long
    > as I could do something like "RestrictedG":DENY WRITE....
    >
    > I know that permission is "settable" (is that a word?) as it can be
    > set usign (the "simple) NTFS Perms. tab... but to script it is what is
    > driving me crazy!!
    >
    > Thanks a lot. Any help _WILL_ Be more than welocome!!
    >
    > Javier J

    The xcacls.vbs will do what you are after, and, it will provide you
    with example of lines need to do it in your own script.

    Deny overrides Grant - where you discuss need for Everyone, but
    not the RestrictedG. The only thing is that you need to be very aware
    and careful about explicit vs inherited.
    Inherited or Explicit Deny overrides an Inherited Grant
    Explicit Deny overrides an Explicit Grant, but an Inherited
    Deny does not override an Explicit Grant.
    --
    Roger

    >
    > On Mon, 28 Feb 2005 22:12:30 -0700, "Roger Abell" <mvpNOSpam@asu.edu>
    > wrote:
    >
    > >Al is quite right in picking up on your mention of use in a
    > >login script - which skipped my attention.
    > >To do as you had planned you would need to do this in
    > >a startup/shutdown script, not login/logoff script.
    > >
    > >However, you really, really would IMO be better off by
    > >restructuring so that all files with this requirement are in
    > >a folder with appropriate grants, not mixed in with other
    > >files in a folder where the default NTFS permissions will
    > >need to be changed.
    >
  7. Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

    "Javier J" <no.mail@please.no> wrote in message
    news:vpf921h1j3tgiliegad4u4kj7e7urhl72l@4ax.com...
    > Hi!!
    >
    > Thanks a lot for the response.

    You are welcome...

    > First of all, regarding LOGON SCRIPT, the mistake is mine: What I was
    > trying to talk about was a STARTUP script (if I'm not mistaken, that
    > script runs as BUILTIN\SYSTEM).
    >
    > I think I'd rather explain a bit more about the envirnoment so that
    > it's clear of why I'm asking for such strange things:
    >
    > The situation is as follows: The PCs in question (Win 200 PRO, SP4+,
    > W2000 Mixed Domain) "belong" to a group of users who, as part of their
    > normal duties, have to handle sensitive information using an internal
    > company app. To avoid undue information leakage, these users have
    > *TWO* logon users for the domain, a highly restricted one that is used
    > to run the corporate app/access sensitve information, and a "Normal"
    > user for the rest of everyday tasks.

    Interesting. In our environment, any exceptionally privileged accounts are
    restricted in what they can do only by policies written on paper rather than
    being enforced by GPO. Admin accounts are not allowed to use the browser,
    but they are not actually prevented from doing so. We do not have any
    applications that need to be run in a context where the rest of the
    infrastructure is made inaccessible, so access to such apps is granted to
    normal user accounts.

    > The "normal" user can run all software EXCEPT the restricted app, and
    > can work normally.
    >
    > The setup for the restricted user (using GPO, crypto software et al)
    > is such that the restricted user only can run the "sensitive" app,
    > they can't browse or "see" in Explorer the local folders, their
    > profile is redirected to an encrypted network etc etc...

    .... still having some trouble envisioning how this type of operation can be
    configured without creating complications for adminstration. I mean, who
    here can list all of the files on a Windows system to which ANY user MUST
    have READ access? WRITE access?

    > Also, using an STARTUP batch script,

    Fine. But what if the system is not restarted between user sessions?

    > the members of the restricted
    > group have been DENIED access to different .exes that restricted users
    > should not run (ftp.exe, telnet.exe and other) and folders they don't
    > need access to. (Windows already protects system folders against
    > accidental change). The problem is, there are a couple of folders on
    > C:\ (such as c:\local_settings) that the user logon needs to be able
    > to read, because it sets machine-specific config. (such as the
    > building's mail server, the NT server, and suchlike)
    >
    > The problem is that the folder is set to be writeable by "Everyone".
    > I'd like to be able to "change" it so "no write" for the users of this
    > particular group. I can DENY access, but these users are part of
    > "Everyone", so even if "RestrictedG" has only READ acces, as they are
    > members of "Everyone"; they get to write there...

    The explicit DENY will generally override the ALLOW.

    > Why am I exploring the "deny" route, instead of limiting the rights of
    > "Everyone".. because there are some cases where the normal users has
    > to be able to write, so "Everyone:W" is a valid permission.... as long
    > as I could do something like "RestrictedG":DENY WRITE....
    >
    > I know that permission is "settable" (is that a word?) as it can be
    > set usign (the "simple) NTFS Perms. tab... but to script it is what is
    > driving me crazy!!

    I sympathize! But I fear that the approach may not be as bullet proof as you
    appear to need it to be.

    Apparently members of the restricted group can logon and establish their
    redirected session having only READ access to the "c:\local_settings\"
    folder. If it is possible to script a permissions change such that the
    folder remains read/write for everyone except for the restricted group who
    have read-only access, then surely it should be possible to apply that
    permission setting ONCE using the GUI, and just leave it at the setting you
    need.

    I tried this and it seemed to work, however, I had to put a checkmark beside
    WRITE in the DENY column. When I tried to DENY the MODIFY access, I found I
    could not do so without also denying READ, READ&EXECUTE, and LIST FOLDER
    CONTENTS. That would appear to be a limitation or constraint applied by the
    GUI itself.

    I would recommend that you try the following from the GUI: Everyone:W and
    RestrictedG:DENY WRITE, and then test the results to see if it achieves your
    purpose without causing problems for the restricated users.

    If that fails in any way, then I would suggest drilling down to the advanced
    tab and denying everything associated with being able to modify or write.

    If that fails in any way, then I would suggest playing with cacls or
    cacls.vbs to see if the extra granularity allows you to do what you want.

    If THAT fails, then, IMHO, you will be unable to accomplish this in a
    startup script. If it succeeds, then you will not need to do it in a startup
    script if you can configure the permissions of that folder as a default in
    your image, or as part of the restricted application installation process.


    /Al

    > Thanks a lot. Any help _WILL_ Be more than welocome!!
    >
    > Javier J
    >
    > On Mon, 28 Feb 2005 22:12:30 -0700, "Roger Abell" <mvpNOSpam@asu.edu>
    > wrote:
    >
    > >Al is quite right in picking up on your mention of use in a
    > >login script - which skipped my attention.
    > >To do as you had planned you would need to do this in
    > >a startup/shutdown script, not login/logoff script.
    > >
    > >However, you really, really would IMO be better off by
    > >restructuring so that all files with this requirement are in
    > >a folder with appropriate grants, not mixed in with other
    > >files in a folder where the default NTFS permissions will
    > >need to be changed.
    >
  8. Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

    On Tue, 1 Mar 2005 18:33:08 -0700, "Roger Abell" <mvpNOSpam@asu.edu>
    wrote:

    >"Javier J" <no.mail@please.no> wrote in message
    >news:vpf921h1j3tgiliegad4u4kj7e7urhl72l@4ax.com...
    >> Hi!!
    >>
    >> Thanks a lot for the response.
    >>
    >> First of all, regarding LOGON SCRIPT, the mistake is mine: What I was
    >> trying to talk about was a STARTUP script (if I'm not mistaken, that
    >> script runs as BUILTIN\SYSTEM).
    >>

    <...>

    >> The problem is that the folder is set to be writeable by "Everyone".
    >> I'd like to be able to "change" it so "no write" for the users of this
    >> particular group. I can DENY access, but these users are part of
    >> "Everyone", so even if "RestrictedG" has only READ acces, as they are
    >> members of "Everyone"; they get to write there...
    >>
    >> Why am I exploring the "deny" route, instead of limiting the rights of
    >> "Everyone".. because there are some cases where the normal users has
    >> to be able to write, so "Everyone:W" is a valid permission.... as long
    >> as I could do something like "RestrictedG":DENY WRITE....
    >>
    >> I know that permission is "settable" (is that a word?) as it can be
    >> set usign (the "simple) NTFS Perms. tab... but to script it is what is
    >> driving me crazy!!
    >>
    >> Thanks a lot. Any help _WILL_ Be more than welocome!!
    >>
    >> Javier J
    >
    >The xcacls.vbs will do what you are after, and, it will provide you
    >with example of lines need to do it in your own script.
    >
    >Deny overrides Grant - where you discuss need for Everyone, but
    >not the RestrictedG. The only thing is that you need to be very aware
    >and careful about explicit vs inherited.
    >Inherited or Explicit Deny overrides an Inherited Grant
    >Explicit Deny overrides an Explicit Grant, but an Inherited
    > Deny does not override an Explicit Grant.

    Thanks a lot. At the moment, I've managed to overcome the problem by
    isolating the folders where the needed .bat files are, and given
    "read" to Everyone, so the scripts are readable by all, and the "log
    to" folder .... well, I've used Deny for "RestrictedG", and I just
    live w/o standard logging for that group (instead, I'm using eventlog
    to log events to the system event log), but I'd like to be able to do
    thinks in not such-a-radical approach.

    JJ
  9. Archived from groups: microsoft.public.security,microsoft.public.win2000.security,microsoft.public.windows.server.scripting,microsoft.public.windows.server.security (More info?)

    On Wed, 2 Mar 2005 11:39:41 -0700, "Al Dunbar [MS-MVP]"
    <alan-no-drub-spam@hotmail.com> wrote:

    >
    >"Javier J" <no.mail@please.no> wrote in message
    >news:vpf921h1j3tgiliegad4u4kj7e7urhl72l@4ax.com...
    >> Hi!!
    >>
    >> Thanks a lot for the response.
    >
    >You are welcome...
    >
    >> First of all, regarding LOGON SCRIPT, the mistake is mine: What I was
    >> trying to talk about was a STARTUP script (if I'm not mistaken, that
    >> script runs as BUILTIN\SYSTEM).
    >>
    >> I think I'd rather explain a bit more about the envirnoment so that
    >> it's clear of why I'm asking for such strange things:
    >>
    >> The situation is as follows: The PCs in question (Win 200 PRO, SP4+,
    >> W2000 Mixed Domain) "belong" to a group of users who, as part of their
    >> normal duties, have to handle sensitive information using an internal
    >> company app. To avoid undue information leakage, these users have
    >> *TWO* logon users for the domain, a highly restricted one that is used
    >> to run the corporate app/access sensitve information, and a "Normal"
    >> user for the rest of everyday tasks.
    >
    >Interesting. In our environment, any exceptionally privileged accounts are
    >restricted in what they can do only by policies written on paper rather than
    >being enforced by GPO. Admin accounts are not allowed to use the browser,
    >but they are not actually prevented from doing so. We do not have any
    >applications that need to be run in a context where the rest of the
    >infrastructure is made inaccessible, so access to such apps is granted to
    >normal user accounts.
    >

    Hi!

    In the "normal" running of this org, that is the way things are. But
    this is a "small" group (around 50 users, max) that sometimes handle
    extremely sensitive (from the legal P.O.W.) info, so we have decided
    to try to go the "extra mile" and "really" restrict the things.

    Of course, the legal "threat" is still in place, but the consensus was
    that the user should also be "made aware" of the restricted naturea of
    the environment... If there is plenty of things that the user normally
    can do that can't be done, the user can't (honestly, justifibly) say
    "I was not aware of that"...


    >> The "normal" user can run all software EXCEPT the restricted app, and
    >> can work normally.
    >>
    >> The setup for the restricted user (using GPO, crypto software et al)
    >> is such that the restricted user only can run the "sensitive" app,
    >> they can't browse or "see" in Explorer the local folders, their
    >> profile is redirected to an encrypted network etc etc...
    >
    >... still having some trouble envisioning how this type of operation can be
    >configured without creating complications for adminstration. I mean, who
    >here can list all of the files on a Windows system to which ANY user MUST
    >have READ access? WRITE access?

    Well, basically it's not that difficult.
    Normal users only need read access to %windir% and to %programfiles%
    (ant that's the defaul windows user perms), and write access to their
    own user profile.

    So any other folder (for example, those hanging from C: that are _not_
    c:\winnt or c:\Program Files or c:\Documents and Settings) are the
    folders I worry about.

    As for the temporary folders, and swap file, and such, the system is
    set to clear them on shutdown, and the user profile can't "close
    session", only "restart".


    >> Also, using an STARTUP batch script,
    >
    >Fine. But what if the system is not restarted between user sessions?
    >

    Well, those policies are applied _each_ time the system boots, but a
    normal user shouldn't be able to change them (as they're not members
    of the admin group), so it's probably a bit of overkill to have the
    policies re-set on each machine boot...

    On user logon and logoff there is a more limited script that performs
    temporary file deletion and such niceties as we could think of...

    Also, we are exploring the possibility of forcing the user to reboot
    the computer when they logoff the "restricted user", but thats only on
    the drawing board at the moment.

    >> the members of the restricted
    >> group have been DENIED access to different .exes that restricted users
    >> should not run (ftp.exe, telnet.exe and other) and folders they don't
    >> need access to. (Windows already protects system folders against
    >> accidental change). The problem is, there are a couple of folders on
    >> C:\ (such as c:\local_settings) that the user logon needs to be able
    >> to read, because it sets machine-specific config. (such as the
    >> building's mail server, the NT server, and suchlike)
    >>
    >> The problem is that the folder is set to be writeable by "Everyone".
    >> I'd like to be able to "change" it so "no write" for the users of this
    >> particular group. I can DENY access, but these users are part of
    >> "Everyone", so even if "RestrictedG" has only READ acces, as they are
    >> members of "Everyone"; they get to write there...
    >
    >The explicit DENY will generally override the ALLOW.

    That's why I'm trying to "get" how to be able to selectively DENY some
    things, as I'd rather not deny everything :)

    >
    >> Why am I exploring the "deny" route, instead of limiting the rights of
    >> "Everyone".. because there are some cases where the normal users has
    >> to be able to write, so "Everyone:W" is a valid permission.... as long
    >> as I could do something like "RestrictedG":DENY WRITE....
    >>
    >> I know that permission is "settable" (is that a word?) as it can be
    >> set usign (the "simple) NTFS Perms. tab... but to script it is what is
    >> driving me crazy!!
    >
    >I sympathize! But I fear that the approach may not be as bullet proof as you
    >appear to need it to be.

    Well.... I am aware that there is no perfect solution to the problem.
    What I'm trying to do is to configuire the system so it's *notably*
    (at least, from my POV) more secure than it was, and to do so in such
    a way that the user's productivity does not suffer too much...

    >
    >Apparently members of the restricted group can logon and establish their
    >redirected session having only READ access to the "c:\local_settings\"
    >folder. If it is possible to script a permissions change such that the
    >folder remains read/write for everyone except for the restricted group who
    >have read-only access, then surely it should be possible to apply that
    >permission setting ONCE using the GUI, and just leave it at the setting you
    >need.
    >
    >I tried this and it seemed to work, however, I had to put a checkmark beside
    >WRITE in the DENY column. When I tried to DENY the MODIFY access, I found I
    >could not do so without also denying READ, READ&EXECUTE, and LIST FOLDER
    >CONTENTS. That would appear to be a limitation or constraint applied by the
    >GUI itself.
    >
    >I would recommend that you try the following from the GUI: Everyone:W and
    >RestrictedG:DENY WRITE, and then test the results to see if it achieves your
    >purpose without causing problems for the restricated users.

    YES! That's the final result I want to achieve, but using a script. I
    already have tested those changes on the GUI, the "problem" is getting
    the computers to that state w/o having to log-on to them.

    >If that fails in any way, then I would suggest drilling down to the advanced
    >tab and denying everything associated with being able to modify or write.
    >
    >If that fails in any way, then I would suggest playing with cacls or
    >cacls.vbs to see if the extra granularity allows you to do what you want.

    No, I only need to be able to do the same than in the "standard" file
    permission tab, BUT w/o doing it manually.

    >If THAT fails, then, IMHO, you will be unable to accomplish this in a
    >startup script. If it succeeds, then you will not need to do it in a startup
    >script if you can configure the permissions of that folder as a default in
    >your image, or as part of the restricted application installation process.
    >

    The issue here is that the install image is already "closed", and it
    depends on another dept. that I don't have "leverage" with. And that
    installation image could change with time (for instance, when new
    hardware is bought). What I am trying to do is to find a way to
    "transform" the image from the permssions-state that it has, to the
    one I want it to have, so that I can be confident that "accidents"
    don't happen (say, one of the Domain Admins logs on the computer, and
    makes some changes, or whatever). That's why I'm investigating
    software installation policies, permission change scripts and the
    like..

    The idea is to develop a "method" to be able to securize a given
    computer, not only a "lock this specific workstation" approach. And to
    minimize the manual intervention required. (as it is, it's still
    necessary to log on to the computer as local admin at least once, so
    that MS OUTLOOK is completely installed.... And I don't know why
    should it behave like that, it's.. odd and uncomfortable, to say the
    least)... BTW, if you know of any way of avoiding that, I'd be more
    than happy to hear it!! ;)


    >/Al
    >
    >> Thanks a lot. Any help _WILL_ Be more than welocome!!
    >>
    >> Javier J
    >>
    >> On Mon, 28 Feb 2005 22:12:30 -0700, "Roger Abell" <mvpNOSpam@asu.edu>
    >> wrote:
    >>
    >> >Al is quite right in picking up on your mention of use in a
    >> >login script - which skipped my attention.
    >> >To do as you had planned you would need to do this in
    >> >a startup/shutdown script, not login/logoff script.
    >> >
    >> >However, you really, really would IMO be better off by
    >> >restructuring so that all files with this requirement are in
    >> >a folder with appropriate grants, not mixed in with other
    >> >files in a folder where the default NTFS permissions will
    >> >need to be changed.
    >>
    >
Ask a new question

Read More

Security Windows Server Microsoft Windows