Deepu-
You will be hard pressed to find a perfect solution for every
scenario you
have. Security is a combination of elements. You need to ensure
first that
users are not administrators on their workstations. Next, you
need to ensure
that the file system and registry are as secure as possible, so
that it is
difficult for the user to move things around or change things to
their
liking. Finally, you need to control what code is installed and
run on a
system. Each of these lines of defense requires a fair bit of
work and even
then, if your users need to run a lot of applications as a
function of their
job, you will find it hard to reach your goal.
But, for the purposes of this discussion, let's try to get you
closer. First
off, is cmd.exe allowed to run? If not, then scripts won't run.
Also, when
you create SRP policy, MS adds some default registry path rules
that
basically allow core Windows components and anything in Program
Files to
run. Did you leave those rules in place or delete them?
If you want to control what the user can run, but, as you say
below, "it's
not feasible to block all exe's as user may have to install some
files or
they may need some exe to run externally..." then you are
cross-purposes to
your goal. If the user can install code willy-nilly and that's
ok, then you
will never be able to successfully control what they can do.
At this point, you might want to look into 3rd party products
that perhaps
have more flexibility than SRP. For example, while I haven't used
it, I know
that Bit9 (www.bit9.com) helps in this area.
Darren
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Deepu
Sent: Wednesday, July 23, 2008 10:47 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Office Blockage...
Hi Darren,
Even after removing the vbs and cmd extension. We can't run cmd
files.
Let's assume even if starts working. it's not feasible to block
all exe's as user may have to install some files or they may
need
some exe to run externally...
So using this method will be a problem for us...
Also let me know why the script is not running even after
removing
the cmd and vbs extension...
Thx...
On Wed, 23 Jul 2008 Deepu wrote :
>Hi Darren,
>
>I have even tried the whitelist mode. But doing so blocks all
exe
>and even it doesn't allow to run vbs (scripts) which are
>necessary to run.
>
>There may be some exe's which user should run.. So, allowing
this
>policy doesnot works...
>
>Thanks...
>
>------------------------------------------------------
>
>On Wed, 23 Jul 2008 Darren Mar-Elia wrote :
>>Deepak-
>>Have you considered using Software Restriction Policy in
>>whitelist mode?
>>That is, set the default level to disallowed and then only
allow
>>a specified
>>pre-approved set of executables?
>>
>>Darren
>>
>>-----Original Message-----
>> From: gptalk-bounce@xxxxxxxxxxxxx
>>[mailto:gptalk-bounce@xxxxxxxxxxxxx] On
>>Behalf Of Deepu
>>Sent: Wednesday, July 23, 2008 7:39 AM
>>To: gptalk@xxxxxxxxxxxxx
>>Subject: [gptalk] Office Blockage...
>>
>>Hi Friends,
>>
>>I am in a great problem. I would really appreciate if anyone
>>can
>>help me at the earliest:
>>
>>Problem: I want to block some executables like access.exe,
>>publisher.exe and communicator.exe using group policy.
>>
>>Now the problem is i can't use Software Restriction Policy
>>using
>>hash rule as the hash will change everytime microsoft
patches
>>or
>>release service pack for office 2007.
>>
>>Secondly if i use Software Restriction Policy using path
rule.
>>The
>>user can simply copy the exe to alternate location and can
run
>>the
>>program with ease.
>>
>>So,i would really appreciate if anyone can help me to solve
>>this
>>issue, as the user can't open the above mentioned exe from
>>anywhere. I want to implement it using group policy. A
custom
>>ADM/ADMX will also work... Please guide me if possible...
>>
>>Waiting for your reply...
>>Deepak Kumar...
>>India...
>>
>>***********************
>>You can unsubscribe from gptalk by sending email to
>>gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the
Subject
>>field OR by
>>logging into the freelists.org Web interface. Archives for
the
>>list are
>>available at //www.freelists.org/archives/gptalk/
>>************************
>>
>>***********************
>>You can unsubscribe from gptalk by sending email to
>>gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the
Subject
>>field OR by logging into the freelists.org Web interface.
>>Archives for the list are available at
>>//www.freelists.org/archives/gptalk/
>>************************
>
>***********************
>You can unsubscribe from gptalk by sending email to
>gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the
Subject
>field OR by logging into the freelists.org Web interface.
>Archives for the list are available at
>//www.freelists.org/archives/gptalk/
>************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
field OR by
logging into the freelists.org Web interface. Archives for the
list are
available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
field OR by logging into the freelists.org Web interface.
Archives for the list are available at
//www.freelists.org/archives/gptalk/
************************
