You are welcome...
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"...
... 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".
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 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
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
ENY 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!!
