Sign in with
Sign up | Sign in
Your question

SUS/WSUS & Software Restriction Policies

Last response: in Windows XP
Share
Anonymous
July 25, 2005 1:06:59 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

Hello all, here's a good one!

I am running SUS and software restriction policies on my domain. Problem
seems that any patches that are approved get downloaded and run from a
randomly generated directory off the C drive. My software restriction
policy is locked down with ONLY the know file paths added to the rules list.
i.e I have c:\program files locked down only allowing certain sub dirs to
run.

I notice the initial file getting blocked is update.exe. I allow this file
to execute only to find another one blocked... I dont want to have to make
exceptions for every file in every future update. Any to make matters even
more fun it seems the folder name where the patches are extracted to is a
randomly generated name that changes EVERY time! Is there any solution for
this? I can't imagine MS not allowing these two great features to not play
nice together!


First error:
Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has been
restricted by your Administrator by the default software restriction policy
level.

After allowing update.exe I get:
Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has been
restricted by your Administrator by the default software restriction policy
level.
Anonymous
July 25, 2005 1:07:00 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

"DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:

My first thought is that your policy may be a bit too restrictive.

Anyway, consider moving to WSUS. It deposits all the updates in sub-dirs in
a structure inside the windows dir. You can then have your policy allow
execution of anything under that sub-dir.


> Hello all, here's a good one!
>
> I am running SUS and software restriction policies on my domain.
> Problem seems that any patches that are approved get downloaded and
> run from a randomly generated directory off the C drive. My software
> restriction policy is locked down with ONLY the know file paths added
> to the rules list. i.e I have c:\program files locked down only
> allowing certain sub dirs to run.
>
> I notice the initial file getting blocked is update.exe. I allow this
> file to execute only to find another one blocked... I dont want to
> have to make exceptions for every file in every future update. Any to
> make matters even more fun it seems the folder name where the patches
> are extracted to is a randomly generated name that changes EVERY time!
> Is there any solution for this? I can't imagine MS not allowing
> these two great features to not play nice together!
>
>
> First error:
> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has been
> restricted by your Administrator by the default software restriction
> policy level.
>
> After allowing update.exe I get:
> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has been
> restricted by your Administrator by the default software restriction
> policy level.
>
>
>
Anonymous
July 26, 2005 12:53:30 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

I have it posted in 4 groups... just included them all in this reply.

My users are all local admins so doing that would null the whole policy.




"woef" <woef20@hotmail.com> wrote in message
news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
> maybe a question for this newsgroup
> microsoft.public.windows.server.update_services
>
> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>wouldn't run at all: my users don't have right to install anything).
>> So, Could you set your policy to allow SYSTEM and Administrators to run
>> from any path?
>>
>> --
>> HIH
>> RØ
>>
>>
>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>> Thanks for the response Asher
>>>
>>> I agree my policy is VERY restrictive; but it was ultimately not my
>>> decision to lock them down this much. Needless to say, I have tweaked
>>> the policy so that only approved applications run. I have 1200 users
>>> able to do their work as if there is no policy at all. Bottom line is
>>> if they are doing their work, they shouldnt have any problems :) 
>>>
>>> Migrating to WSUS is in my plans but I need more time to setup a test
>>> server.
>>>
>>> Anyone else have any ideas?
>>>
>>>
>>>
>>> I do plan to migrate to WSUS shortly
>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>
>>>> My first thought is that your policy may be a bit too restrictive.
>>>>
>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>> sub-dirs in
>>>> a structure inside the windows dir. You can then have your policy allow
>>>> execution of anything under that sub-dir.
>>>>
>>>>
>>>>> Hello all, here's a good one!
>>>>>
>>>>> I am running SUS and software restriction policies on my domain.
>>>>> Problem seems that any patches that are approved get downloaded and
>>>>> run from a randomly generated directory off the C drive. My software
>>>>> restriction policy is locked down with ONLY the know file paths added
>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>> allowing certain sub dirs to run.
>>>>>
>>>>> I notice the initial file getting blocked is update.exe. I allow this
>>>>> file to execute only to find another one blocked... I dont want to
>>>>> have to make exceptions for every file in every future update. Any to
>>>>> make matters even more fun it seems the folder name where the patches
>>>>> are extracted to is a randomly generated name that changes EVERY time!
>>>>> Is there any solution for this? I can't imagine MS not allowing
>>>>> these two great features to not play nice together!
>>>>>
>>>>>
>>>>> First error:
>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has been
>>>>> restricted by your Administrator by the default software restriction
>>>>> policy level.
>>>>>
>>>>> After allowing update.exe I get:
>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has been
>>>>> restricted by your Administrator by the default software restriction
>>>>> policy level.
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>
Related resources
Anonymous
July 26, 2005 2:34:02 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

I'll throw my .02 in here as well.

The policy is /TOO/ restrictive.

Furthermore, it causes more problems than it can possibly solve.

"Locking down" a workstation to the extent being attempted requires an
in-depth understanding of the operation of various aspects of the operating
system, update methodologies, application installation processes, and a
dozen other elements.

My best suggestion is to /REMOVE/ the policies, and let the system do its
job of protecting itself with the provided security tools.

"DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
news:emPY%23DekFHA.3148@TK2MSFTNGP09.phx.gbl...
>I have it posted in 4 groups... just included them all in this reply.
>
> My users are all local admins so doing that would null the whole policy.
>
>
>
>
> "woef" <woef20@hotmail.com> wrote in message
> news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
>> maybe a question for this newsgroup
>> microsoft.public.windows.server.update_services
>>
>> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
>> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>>wouldn't run at all: my users don't have right to install anything).
>>> So, Could you set your policy to allow SYSTEM and Administrators to run
>>> from any path?
>>>
>>> --
>>> HIH
>>> RØ
>>>
>>>
>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>>> Thanks for the response Asher
>>>>
>>>> I agree my policy is VERY restrictive; but it was ultimately not my
>>>> decision to lock them down this much. Needless to say, I have tweaked
>>>> the policy so that only approved applications run. I have 1200 users
>>>> able to do their work as if there is no policy at all. Bottom line is
>>>> if they are doing their work, they shouldnt have any problems :) 
>>>>
>>>> Migrating to WSUS is in my plans but I need more time to setup a test
>>>> server.
>>>>
>>>> Anyone else have any ideas?
>>>>
>>>>
>>>>
>>>> I do plan to migrate to WSUS shortly
>>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>>
>>>>> My first thought is that your policy may be a bit too restrictive.
>>>>>
>>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>>> sub-dirs in
>>>>> a structure inside the windows dir. You can then have your policy
>>>>> allow
>>>>> execution of anything under that sub-dir.
>>>>>
>>>>>
>>>>>> Hello all, here's a good one!
>>>>>>
>>>>>> I am running SUS and software restriction policies on my domain.
>>>>>> Problem seems that any patches that are approved get downloaded and
>>>>>> run from a randomly generated directory off the C drive. My software
>>>>>> restriction policy is locked down with ONLY the know file paths added
>>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>>> allowing certain sub dirs to run.
>>>>>>
>>>>>> I notice the initial file getting blocked is update.exe. I allow
>>>>>> this
>>>>>> file to execute only to find another one blocked... I dont want to
>>>>>> have to make exceptions for every file in every future update. Any
>>>>>> to
>>>>>> make matters even more fun it seems the folder name where the patches
>>>>>> are extracted to is a randomly generated name that changes EVERY
>>>>>> time!
>>>>>> Is there any solution for this? I can't imagine MS not allowing
>>>>>> these two great features to not play nice together!
>>>>>>
>>>>>>
>>>>>> First error:
>>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has
>>>>>> been
>>>>>> restricted by your Administrator by the default software restriction
>>>>>> policy level.
>>>>>>
>>>>>> After allowing update.exe I get:
>>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has been
>>>>>> restricted by your Administrator by the default software restriction
>>>>>> policy level.
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Anonymous
July 26, 2005 4:08:03 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

You obviously don't understand my environment and the level of security we
require here, the DoD would not take your answer for 1 minute. Thanks for
your .02 but Software Restriction Policies DO work and when setup properly
the machine will run without a problem.

I do understand all the items you have listed (minus the dozen other
"elements") and quite frankly they do not apply. You see, SRP is designed
to prevent a lot of the things you have mentioned. I have my desktops
working fine besides this SUS issue due to the randomly generated folder
name created when a patch is installed. With my in-depth understanding of
the items you listed, I have been able to create a ruleset GPO that allows
the OS to function and the APPROVED apps to run. I have not had a complaint
from not one of my 1200 users which tells me I have implemented SRP
successfully.

I have decided to push forward with WSUS ahead of my plans to rememdy this
situation. Not worth the time trying to work around an issue like this when
SUS is going to be replaced anyway.

Cheers!

"Lawrence Garvin" <onsitechsolutions@news.postalias> wrote in message
news:%23VLsXefkFHA.1464@TK2MSFTNGP14.phx.gbl...
> I'll throw my .02 in here as well.
>
> The policy is /TOO/ restrictive.
>
> Furthermore, it causes more problems than it can possibly solve.
>
> "Locking down" a workstation to the extent being attempted requires an
> in-depth understanding of the operation of various aspects of the
> operating system, update methodologies, application installation
> processes, and a dozen other elements.
>
> My best suggestion is to /REMOVE/ the policies, and let the system do its
> job of protecting itself with the provided security tools.
>
> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
> news:emPY%23DekFHA.3148@TK2MSFTNGP09.phx.gbl...
>>I have it posted in 4 groups... just included them all in this reply.
>>
>> My users are all local admins so doing that would null the whole policy.
>>
>>
>>
>>
>> "woef" <woef20@hotmail.com> wrote in message
>> news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
>>> maybe a question for this newsgroup
>>> microsoft.public.windows.server.update_services
>>>
>>> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
>>> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>>>wouldn't run at all: my users don't have right to install anything).
>>>> So, Could you set your policy to allow SYSTEM and Administrators to run
>>>> from any path?
>>>>
>>>> --
>>>> HIH
>>>> RØ
>>>>
>>>>
>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>>>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>>>> Thanks for the response Asher
>>>>>
>>>>> I agree my policy is VERY restrictive; but it was ultimately not my
>>>>> decision to lock them down this much. Needless to say, I have tweaked
>>>>> the policy so that only approved applications run. I have 1200 users
>>>>> able to do their work as if there is no policy at all. Bottom line is
>>>>> if they are doing their work, they shouldnt have any problems :) 
>>>>>
>>>>> Migrating to WSUS is in my plans but I need more time to setup a test
>>>>> server.
>>>>>
>>>>> Anyone else have any ideas?
>>>>>
>>>>>
>>>>>
>>>>> I do plan to migrate to WSUS shortly
>>>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>>>
>>>>>> My first thought is that your policy may be a bit too restrictive.
>>>>>>
>>>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>>>> sub-dirs in
>>>>>> a structure inside the windows dir. You can then have your policy
>>>>>> allow
>>>>>> execution of anything under that sub-dir.
>>>>>>
>>>>>>
>>>>>>> Hello all, here's a good one!
>>>>>>>
>>>>>>> I am running SUS and software restriction policies on my domain.
>>>>>>> Problem seems that any patches that are approved get downloaded and
>>>>>>> run from a randomly generated directory off the C drive. My
>>>>>>> software
>>>>>>> restriction policy is locked down with ONLY the know file paths
>>>>>>> added
>>>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>>>> allowing certain sub dirs to run.
>>>>>>>
>>>>>>> I notice the initial file getting blocked is update.exe. I allow
>>>>>>> this
>>>>>>> file to execute only to find another one blocked... I dont want to
>>>>>>> have to make exceptions for every file in every future update. Any
>>>>>>> to
>>>>>>> make matters even more fun it seems the folder name where the
>>>>>>> patches
>>>>>>> are extracted to is a randomly generated name that changes EVERY
>>>>>>> time!
>>>>>>> Is there any solution for this? I can't imagine MS not allowing
>>>>>>> these two great features to not play nice together!
>>>>>>>
>>>>>>>
>>>>>>> First error:
>>>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has
>>>>>>> been
>>>>>>> restricted by your Administrator by the default software restriction
>>>>>>> policy level.
>>>>>>>
>>>>>>> After allowing update.exe I get:
>>>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has been
>>>>>>> restricted by your Administrator by the default software restriction
>>>>>>> policy level.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Anonymous
July 26, 2005 11:33:34 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

I know that no organization would impose so much security as to make the
normal operation of the function allegedly being secured /dysfunctional/.

That is, in effect, what you have done by trying to lock down parts of the
filesystem that are designed by the operating system to be used /by/ the
operating system.

You do what you want. You're right, I don't understand it. I don't want to
understand it.

I'm merely pointing out that such efforts will result in much heartbreak and
headache.

As for what the DoD may or may not do... unless your pay grade is higher
than what mine was, I'm fairly confident in knowing what the DoD will or
will not accept in terms of "homegrown" security measures.


"DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
news:o G6iqwfkFHA.1440@TK2MSFTNGP14.phx.gbl...
> You obviously don't understand my environment and the level of security we
> require here, the DoD would not take your answer for 1 minute. Thanks for
> your .02 but Software Restriction Policies DO work and when setup properly
> the machine will run without a problem.
>
> I do understand all the items you have listed (minus the dozen other
> "elements") and quite frankly they do not apply. You see, SRP is designed
> to prevent a lot of the things you have mentioned. I have my desktops
> working fine besides this SUS issue due to the randomly generated folder
> name created when a patch is installed. With my in-depth understanding
> of the items you listed, I have been able to create a ruleset GPO that
> allows the OS to function and the APPROVED apps to run. I have not had a
> complaint from not one of my 1200 users which tells me I have implemented
> SRP successfully.
>
> I have decided to push forward with WSUS ahead of my plans to rememdy this
> situation. Not worth the time trying to work around an issue like this
> when SUS is going to be replaced anyway.
>
> Cheers!
>
> "Lawrence Garvin" <onsitechsolutions@news.postalias> wrote in message
> news:%23VLsXefkFHA.1464@TK2MSFTNGP14.phx.gbl...
>> I'll throw my .02 in here as well.
>>
>> The policy is /TOO/ restrictive.
>>
>> Furthermore, it causes more problems than it can possibly solve.
>>
>> "Locking down" a workstation to the extent being attempted requires an
>> in-depth understanding of the operation of various aspects of the
>> operating system, update methodologies, application installation
>> processes, and a dozen other elements.
>>
>> My best suggestion is to /REMOVE/ the policies, and let the system do its
>> job of protecting itself with the provided security tools.
>>
>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>> news:emPY%23DekFHA.3148@TK2MSFTNGP09.phx.gbl...
>>>I have it posted in 4 groups... just included them all in this reply.
>>>
>>> My users are all local admins so doing that would null the whole policy.
>>>
>>>
>>>
>>>
>>> "woef" <woef20@hotmail.com> wrote in message
>>> news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
>>>> maybe a question for this newsgroup
>>>> microsoft.public.windows.server.update_services
>>>>
>>>> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
>>>> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>>>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>>>>wouldn't run at all: my users don't have right to install anything).
>>>>> So, Could you set your policy to allow SYSTEM and Administrators to
>>>>> run from any path?
>>>>>
>>>>> --
>>>>> HIH
>>>>> RØ
>>>>>
>>>>>
>>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>>>>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>>>>> Thanks for the response Asher
>>>>>>
>>>>>> I agree my policy is VERY restrictive; but it was ultimately not my
>>>>>> decision to lock them down this much. Needless to say, I have
>>>>>> tweaked the policy so that only approved applications run. I have
>>>>>> 1200 users able to do their work as if there is no policy at all.
>>>>>> Bottom line is if they are doing their work, they shouldnt have any
>>>>>> problems :) 
>>>>>>
>>>>>> Migrating to WSUS is in my plans but I need more time to setup a test
>>>>>> server.
>>>>>>
>>>>>> Anyone else have any ideas?
>>>>>>
>>>>>>
>>>>>>
>>>>>> I do plan to migrate to WSUS shortly
>>>>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>>>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>>>>
>>>>>>> My first thought is that your policy may be a bit too restrictive.
>>>>>>>
>>>>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>>>>> sub-dirs in
>>>>>>> a structure inside the windows dir. You can then have your policy
>>>>>>> allow
>>>>>>> execution of anything under that sub-dir.
>>>>>>>
>>>>>>>
>>>>>>>> Hello all, here's a good one!
>>>>>>>>
>>>>>>>> I am running SUS and software restriction policies on my domain.
>>>>>>>> Problem seems that any patches that are approved get downloaded and
>>>>>>>> run from a randomly generated directory off the C drive. My
>>>>>>>> software
>>>>>>>> restriction policy is locked down with ONLY the know file paths
>>>>>>>> added
>>>>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>>>>> allowing certain sub dirs to run.
>>>>>>>>
>>>>>>>> I notice the initial file getting blocked is update.exe. I allow
>>>>>>>> this
>>>>>>>> file to execute only to find another one blocked... I dont want to
>>>>>>>> have to make exceptions for every file in every future update. Any
>>>>>>>> to
>>>>>>>> make matters even more fun it seems the folder name where the
>>>>>>>> patches
>>>>>>>> are extracted to is a randomly generated name that changes EVERY
>>>>>>>> time!
>>>>>>>> Is there any solution for this? I can't imagine MS not allowing
>>>>>>>> these two great features to not play nice together!
>>>>>>>>
>>>>>>>>
>>>>>>>> First error:
>>>>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has
>>>>>>>> been
>>>>>>>> restricted by your Administrator by the default software
>>>>>>>> restriction
>>>>>>>> policy level.
>>>>>>>>
>>>>>>>> After allowing update.exe I get:
>>>>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has
>>>>>>>> been
>>>>>>>> restricted by your Administrator by the default software
>>>>>>>> restriction
>>>>>>>> policy level.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Anonymous
July 27, 2005 9:59:35 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

Hi there

I wonder if allowing all executables signed by Microsoft would be an
acceptable solution. I haven't tested this, but I think it could work.

I find the notion that you allow free administrative access to workstations,
but apply a software restriction policy mildly amusing. What's to stop
these administrators removing or overriding your software restriction policy
locally, and running unauthorised applications? Sure, Group Policy will
place the policy back after (by default) 90 minutes plus or minus 30, but
they can still do it.

Oli


"DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
news:o G6iqwfkFHA.1440@TK2MSFTNGP14.phx.gbl...
> You obviously don't understand my environment and the level of security we
> require here, the DoD would not take your answer for 1 minute. Thanks for
> your .02 but Software Restriction Policies DO work and when setup properly
> the machine will run without a problem.
>
> I do understand all the items you have listed (minus the dozen other
> "elements") and quite frankly they do not apply. You see, SRP is designed
> to prevent a lot of the things you have mentioned. I have my desktops
> working fine besides this SUS issue due to the randomly generated folder
> name created when a patch is installed. With my in-depth understanding
> of the items you listed, I have been able to create a ruleset GPO that
> allows the OS to function and the APPROVED apps to run. I have not had a
> complaint from not one of my 1200 users which tells me I have implemented
> SRP successfully.
>
> I have decided to push forward with WSUS ahead of my plans to rememdy this
> situation. Not worth the time trying to work around an issue like this
> when SUS is going to be replaced anyway.
>
> Cheers!
>
> "Lawrence Garvin" <onsitechsolutions@news.postalias> wrote in message
> news:%23VLsXefkFHA.1464@TK2MSFTNGP14.phx.gbl...
>> I'll throw my .02 in here as well.
>>
>> The policy is /TOO/ restrictive.
>>
>> Furthermore, it causes more problems than it can possibly solve.
>>
>> "Locking down" a workstation to the extent being attempted requires an
>> in-depth understanding of the operation of various aspects of the
>> operating system, update methodologies, application installation
>> processes, and a dozen other elements.
>>
>> My best suggestion is to /REMOVE/ the policies, and let the system do its
>> job of protecting itself with the provided security tools.
>>
>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>> news:emPY%23DekFHA.3148@TK2MSFTNGP09.phx.gbl...
>>>I have it posted in 4 groups... just included them all in this reply.
>>>
>>> My users are all local admins so doing that would null the whole policy.
>>>
>>>
>>>
>>>
>>> "woef" <woef20@hotmail.com> wrote in message
>>> news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
>>>> maybe a question for this newsgroup
>>>> microsoft.public.windows.server.update_services
>>>>
>>>> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
>>>> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>>>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>>>>wouldn't run at all: my users don't have right to install anything).
>>>>> So, Could you set your policy to allow SYSTEM and Administrators to
>>>>> run from any path?
>>>>>
>>>>> --
>>>>> HIH
>>>>> RØ
>>>>>
>>>>>
>>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>>>>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>>>>> Thanks for the response Asher
>>>>>>
>>>>>> I agree my policy is VERY restrictive; but it was ultimately not my
>>>>>> decision to lock them down this much. Needless to say, I have
>>>>>> tweaked the policy so that only approved applications run. I have
>>>>>> 1200 users able to do their work as if there is no policy at all.
>>>>>> Bottom line is if they are doing their work, they shouldnt have any
>>>>>> problems :) 
>>>>>>
>>>>>> Migrating to WSUS is in my plans but I need more time to setup a test
>>>>>> server.
>>>>>>
>>>>>> Anyone else have any ideas?
>>>>>>
>>>>>>
>>>>>>
>>>>>> I do plan to migrate to WSUS shortly
>>>>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>>>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>>>>
>>>>>>> My first thought is that your policy may be a bit too restrictive.
>>>>>>>
>>>>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>>>>> sub-dirs in
>>>>>>> a structure inside the windows dir. You can then have your policy
>>>>>>> allow
>>>>>>> execution of anything under that sub-dir.
>>>>>>>
>>>>>>>
>>>>>>>> Hello all, here's a good one!
>>>>>>>>
>>>>>>>> I am running SUS and software restriction policies on my domain.
>>>>>>>> Problem seems that any patches that are approved get downloaded and
>>>>>>>> run from a randomly generated directory off the C drive. My
>>>>>>>> software
>>>>>>>> restriction policy is locked down with ONLY the know file paths
>>>>>>>> added
>>>>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>>>>> allowing certain sub dirs to run.
>>>>>>>>
>>>>>>>> I notice the initial file getting blocked is update.exe. I allow
>>>>>>>> this
>>>>>>>> file to execute only to find another one blocked... I dont want to
>>>>>>>> have to make exceptions for every file in every future update. Any
>>>>>>>> to
>>>>>>>> make matters even more fun it seems the folder name where the
>>>>>>>> patches
>>>>>>>> are extracted to is a randomly generated name that changes EVERY
>>>>>>>> time!
>>>>>>>> Is there any solution for this? I can't imagine MS not allowing
>>>>>>>> these two great features to not play nice together!
>>>>>>>>
>>>>>>>>
>>>>>>>> First error:
>>>>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has
>>>>>>>> been
>>>>>>>> restricted by your Administrator by the default software
>>>>>>>> restriction
>>>>>>>> policy level.
>>>>>>>>
>>>>>>>> After allowing update.exe I get:
>>>>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has
>>>>>>>> been
>>>>>>>> restricted by your Administrator by the default software
>>>>>>>> restriction
>>>>>>>> policy level.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Anonymous
July 27, 2005 11:43:43 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

That is a good idea but I wonder if all MS executables are signed?

As for the other statement, I agree with you 100%. I made that point across
before I was told to go ahead with the implementation. It basically came
down to the fact that if we catch someone circumventing the policy they will
have no "excuses" as to why they are running unauthorized apps. In the past
the regulations always stated strict penalties but nobody acted on them and
the users made up bogus excuses. We are all adults and it is basically a
trust thing and if someone wants to mess around they will suffer the
consequences.

Thanks for your input...


"Oli Restorick [MVP]" <oli@mvps.org> wrote in message
news:o BFxTyskFHA.3260@TK2MSFTNGP10.phx.gbl...
> Hi there
>
> I wonder if allowing all executables signed by Microsoft would be an
> acceptable solution. I haven't tested this, but I think it could work.
>
> I find the notion that you allow free administrative access to
> workstations, but apply a software restriction policy mildly amusing.
> What's to stop these administrators removing or overriding your software
> restriction policy locally, and running unauthorised applications? Sure,
> Group Policy will place the policy back after (by default) 90 minutes plus
> or minus 30, but they can still do it.
>
> Oli
>
>
> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
> news:o G6iqwfkFHA.1440@TK2MSFTNGP14.phx.gbl...
>> You obviously don't understand my environment and the level of security
>> we require here, the DoD would not take your answer for 1 minute. Thanks
>> for your .02 but Software Restriction Policies DO work and when setup
>> properly the machine will run without a problem.
>>
>> I do understand all the items you have listed (minus the dozen other
>> "elements") and quite frankly they do not apply. You see, SRP is
>> designed to prevent a lot of the things you have mentioned. I have my
>> desktops working fine besides this SUS issue due to the randomly
>> generated folder name created when a patch is installed. With my
>> in-depth understanding of the items you listed, I have been able to
>> create a ruleset GPO that allows the OS to function and the APPROVED apps
>> to run. I have not had a complaint from not one of my 1200 users which
>> tells me I have implemented SRP successfully.
>>
>> I have decided to push forward with WSUS ahead of my plans to rememdy
>> this situation. Not worth the time trying to work around an issue like
>> this when SUS is going to be replaced anyway.
>>
>> Cheers!
>>
>> "Lawrence Garvin" <onsitechsolutions@news.postalias> wrote in message
>> news:%23VLsXefkFHA.1464@TK2MSFTNGP14.phx.gbl...
>>> I'll throw my .02 in here as well.
>>>
>>> The policy is /TOO/ restrictive.
>>>
>>> Furthermore, it causes more problems than it can possibly solve.
>>>
>>> "Locking down" a workstation to the extent being attempted requires an
>>> in-depth understanding of the operation of various aspects of the
>>> operating system, update methodologies, application installation
>>> processes, and a dozen other elements.
>>>
>>> My best suggestion is to /REMOVE/ the policies, and let the system do
>>> its job of protecting itself with the provided security tools.
>>>
>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>>> news:emPY%23DekFHA.3148@TK2MSFTNGP09.phx.gbl...
>>>>I have it posted in 4 groups... just included them all in this reply.
>>>>
>>>> My users are all local admins so doing that would null the whole
>>>> policy.
>>>>
>>>>
>>>>
>>>>
>>>> "woef" <woef20@hotmail.com> wrote in message
>>>> news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
>>>>> maybe a question for this newsgroup
>>>>> microsoft.public.windows.server.update_services
>>>>>
>>>>> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
>>>>> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>>>>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>>>>>wouldn't run at all: my users don't have right to install anything).
>>>>>> So, Could you set your policy to allow SYSTEM and Administrators to
>>>>>> run from any path?
>>>>>>
>>>>>> --
>>>>>> HIH
>>>>>> RØ
>>>>>>
>>>>>>
>>>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>>>>>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>>>>>> Thanks for the response Asher
>>>>>>>
>>>>>>> I agree my policy is VERY restrictive; but it was ultimately not my
>>>>>>> decision to lock them down this much. Needless to say, I have
>>>>>>> tweaked the policy so that only approved applications run. I have
>>>>>>> 1200 users able to do their work as if there is no policy at all.
>>>>>>> Bottom line is if they are doing their work, they shouldnt have any
>>>>>>> problems :) 
>>>>>>>
>>>>>>> Migrating to WSUS is in my plans but I need more time to setup a
>>>>>>> test server.
>>>>>>>
>>>>>>> Anyone else have any ideas?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I do plan to migrate to WSUS shortly
>>>>>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>>>>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>>>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>>>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>>>>>
>>>>>>>> My first thought is that your policy may be a bit too restrictive.
>>>>>>>>
>>>>>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>>>>>> sub-dirs in
>>>>>>>> a structure inside the windows dir. You can then have your policy
>>>>>>>> allow
>>>>>>>> execution of anything under that sub-dir.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hello all, here's a good one!
>>>>>>>>>
>>>>>>>>> I am running SUS and software restriction policies on my domain.
>>>>>>>>> Problem seems that any patches that are approved get downloaded
>>>>>>>>> and
>>>>>>>>> run from a randomly generated directory off the C drive. My
>>>>>>>>> software
>>>>>>>>> restriction policy is locked down with ONLY the know file paths
>>>>>>>>> added
>>>>>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>>>>>> allowing certain sub dirs to run.
>>>>>>>>>
>>>>>>>>> I notice the initial file getting blocked is update.exe. I allow
>>>>>>>>> this
>>>>>>>>> file to execute only to find another one blocked... I dont want to
>>>>>>>>> have to make exceptions for every file in every future update.
>>>>>>>>> Any to
>>>>>>>>> make matters even more fun it seems the folder name where the
>>>>>>>>> patches
>>>>>>>>> are extracted to is a randomly generated name that changes EVERY
>>>>>>>>> time!
>>>>>>>>> Is there any solution for this? I can't imagine MS not allowing
>>>>>>>>> these two great features to not play nice together!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> First error:
>>>>>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has
>>>>>>>>> been
>>>>>>>>> restricted by your Administrator by the default software
>>>>>>>>> restriction
>>>>>>>>> policy level.
>>>>>>>>>
>>>>>>>>> After allowing update.exe I get:
>>>>>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has
>>>>>>>>> been
>>>>>>>>> restricted by your Administrator by the default software
>>>>>>>>> restriction
>>>>>>>>> policy level.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Anonymous
August 3, 2005 12:17:24 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

Then logistically, if they're all adults, and it's a trust thing, then you
shouldn't need to place software restriction policies on local admins that
can run a script every 5 minutes to keep your policy settings from applying.
I had one enterprising user who was trusted to have local admin rights
running a script so the screensaver would not engage after 15 minutes. He
lost his local admin rights, and still manages to do his job... just with a
screensaver kicking in.

Just out of curiosity, what sort of 'action' is taken when a user has
unauthorized programs on their computer? At my place, I've 'informed'
directors of people in this case... to no avail. Come back a week later,
heck, a day later and the app is on the computer (again!)... or was it even
removed in the first place?

Ken

"DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
news:eZDQ4TwkFHA.3568@TK2MSFTNGP10.phx.gbl...
> That is a good idea but I wonder if all MS executables are signed?
>
> As for the other statement, I agree with you 100%. I made that point
> across before I was told to go ahead with the implementation. It
> basically came down to the fact that if we catch someone circumventing the
> policy they will have no "excuses" as to why they are running unauthorized
> apps. In the past the regulations always stated strict penalties but
> nobody acted on them and the users made up bogus excuses. We are all
> adults and it is basically a trust thing and if someone wants to mess
> around they will suffer the consequences.
>
> Thanks for your input...
>
>
> "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
> news:o BFxTyskFHA.3260@TK2MSFTNGP10.phx.gbl...
>> Hi there
>>
>> I wonder if allowing all executables signed by Microsoft would be an
>> acceptable solution. I haven't tested this, but I think it could work.
>>
>> I find the notion that you allow free administrative access to
>> workstations, but apply a software restriction policy mildly amusing.
>> What's to stop these administrators removing or overriding your software
>> restriction policy locally, and running unauthorised applications? Sure,
>> Group Policy will place the policy back after (by default) 90 minutes
>> plus or minus 30, but they can still do it.
>>
>> Oli
>>
>>
>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>> news:o G6iqwfkFHA.1440@TK2MSFTNGP14.phx.gbl...
>>> You obviously don't understand my environment and the level of security
>>> we require here, the DoD would not take your answer for 1 minute.
>>> Thanks for your .02 but Software Restriction Policies DO work and when
>>> setup properly the machine will run without a problem.
>>>
>>> I do understand all the items you have listed (minus the dozen other
>>> "elements") and quite frankly they do not apply. You see, SRP is
>>> designed to prevent a lot of the things you have mentioned. I have my
>>> desktops working fine besides this SUS issue due to the randomly
>>> generated folder name created when a patch is installed. With my
>>> in-depth understanding of the items you listed, I have been able to
>>> create a ruleset GPO that allows the OS to function and the APPROVED
>>> apps to run. I have not had a complaint from not one of my 1200 users
>>> which tells me I have implemented SRP successfully.
>>>
>>> I have decided to push forward with WSUS ahead of my plans to rememdy
>>> this situation. Not worth the time trying to work around an issue like
>>> this when SUS is going to be replaced anyway.
>>>
>>> Cheers!
>>>
>>> "Lawrence Garvin" <onsitechsolutions@news.postalias> wrote in message
>>> news:%23VLsXefkFHA.1464@TK2MSFTNGP14.phx.gbl...
>>>> I'll throw my .02 in here as well.
>>>>
>>>> The policy is /TOO/ restrictive.
>>>>
>>>> Furthermore, it causes more problems than it can possibly solve.
>>>>
>>>> "Locking down" a workstation to the extent being attempted requires an
>>>> in-depth understanding of the operation of various aspects of the
>>>> operating system, update methodologies, application installation
>>>> processes, and a dozen other elements.
>>>>
>>>> My best suggestion is to /REMOVE/ the policies, and let the system do
>>>> its job of protecting itself with the provided security tools.
>>>>
>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>>>> news:emPY%23DekFHA.3148@TK2MSFTNGP09.phx.gbl...
>>>>>I have it posted in 4 groups... just included them all in this reply.
>>>>>
>>>>> My users are all local admins so doing that would null the whole
>>>>> policy.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "woef" <woef20@hotmail.com> wrote in message
>>>>> news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
>>>>>> maybe a question for this newsgroup
>>>>>> microsoft.public.windows.server.update_services
>>>>>>
>>>>>> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
>>>>>> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>>>>>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>>>>>>wouldn't run at all: my users don't have right to install anything).
>>>>>>> So, Could you set your policy to allow SYSTEM and Administrators to
>>>>>>> run from any path?
>>>>>>>
>>>>>>> --
>>>>>>> HIH
>>>>>>> RØ
>>>>>>>
>>>>>>>
>>>>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>>>>>>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>>>>>>> Thanks for the response Asher
>>>>>>>>
>>>>>>>> I agree my policy is VERY restrictive; but it was ultimately not my
>>>>>>>> decision to lock them down this much. Needless to say, I have
>>>>>>>> tweaked the policy so that only approved applications run. I have
>>>>>>>> 1200 users able to do their work as if there is no policy at all.
>>>>>>>> Bottom line is if they are doing their work, they shouldnt have any
>>>>>>>> problems :) 
>>>>>>>>
>>>>>>>> Migrating to WSUS is in my plans but I need more time to setup a
>>>>>>>> test server.
>>>>>>>>
>>>>>>>> Anyone else have any ideas?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I do plan to migrate to WSUS shortly
>>>>>>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>>>>>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>>>>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>>>>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>>>>>>
>>>>>>>>> My first thought is that your policy may be a bit too restrictive.
>>>>>>>>>
>>>>>>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>>>>>>> sub-dirs in
>>>>>>>>> a structure inside the windows dir. You can then have your policy
>>>>>>>>> allow
>>>>>>>>> execution of anything under that sub-dir.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hello all, here's a good one!
>>>>>>>>>>
>>>>>>>>>> I am running SUS and software restriction policies on my domain.
>>>>>>>>>> Problem seems that any patches that are approved get downloaded
>>>>>>>>>> and
>>>>>>>>>> run from a randomly generated directory off the C drive. My
>>>>>>>>>> software
>>>>>>>>>> restriction policy is locked down with ONLY the know file paths
>>>>>>>>>> added
>>>>>>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>>>>>>> allowing certain sub dirs to run.
>>>>>>>>>>
>>>>>>>>>> I notice the initial file getting blocked is update.exe. I allow
>>>>>>>>>> this
>>>>>>>>>> file to execute only to find another one blocked... I dont want
>>>>>>>>>> to
>>>>>>>>>> have to make exceptions for every file in every future update.
>>>>>>>>>> Any to
>>>>>>>>>> make matters even more fun it seems the folder name where the
>>>>>>>>>> patches
>>>>>>>>>> are extracted to is a randomly generated name that changes EVERY
>>>>>>>>>> time!
>>>>>>>>>> Is there any solution for this? I can't imagine MS not allowing
>>>>>>>>>> these two great features to not play nice together!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> First error:
>>>>>>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has
>>>>>>>>>> been
>>>>>>>>>> restricted by your Administrator by the default software
>>>>>>>>>> restriction
>>>>>>>>>> policy level.
>>>>>>>>>>
>>>>>>>>>> After allowing update.exe I get:
>>>>>>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has
>>>>>>>>>> been
>>>>>>>>>> restricted by your Administrator by the default software
>>>>>>>>>> restriction
>>>>>>>>>> policy level.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Anonymous
August 3, 2005 1:54:43 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

"Trust" is a word that should never be used - in any context - in any
security policy. "Trust" is what you rely on when you have no
security policies at all...

On Wed, 3 Aug 2005 08:17:24 -0400, "Ken B" <none@microsoft.com> wrote:

>Then logistically, if they're all adults, and it's a trust thing, then you
>shouldn't need to place software restriction policies on local admins that
>can run a script every 5 minutes to keep your policy settings from applying.
>I had one enterprising user who was trusted to have local admin rights
>running a script so the screensaver would not engage after 15 minutes. He
>lost his local admin rights, and still manages to do his job... just with a
>screensaver kicking in.
>
>Just out of curiosity, what sort of 'action' is taken when a user has
>unauthorized programs on their computer? At my place, I've 'informed'
>directors of people in this case... to no avail. Come back a week later,
>heck, a day later and the app is on the computer (again!)... or was it even
>removed in the first place?
>
>Ken
>
>"DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>news:eZDQ4TwkFHA.3568@TK2MSFTNGP10.phx.gbl...
>> That is a good idea but I wonder if all MS executables are signed?
>>
>> As for the other statement, I agree with you 100%. I made that point
>> across before I was told to go ahead with the implementation. It
>> basically came down to the fact that if we catch someone circumventing the
>> policy they will have no "excuses" as to why they are running unauthorized
>> apps. In the past the regulations always stated strict penalties but
>> nobody acted on them and the users made up bogus excuses. We are all
>> adults and it is basically a trust thing and if someone wants to mess
>> around they will suffer the consequences.
>>
>> Thanks for your input...
>>
>>
>> "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
>> news:o BFxTyskFHA.3260@TK2MSFTNGP10.phx.gbl...
>>> Hi there
>>>
>>> I wonder if allowing all executables signed by Microsoft would be an
>>> acceptable solution. I haven't tested this, but I think it could work.
>>>
>>> I find the notion that you allow free administrative access to
>>> workstations, but apply a software restriction policy mildly amusing.
>>> What's to stop these administrators removing or overriding your software
>>> restriction policy locally, and running unauthorised applications? Sure,
>>> Group Policy will place the policy back after (by default) 90 minutes
>>> plus or minus 30, but they can still do it.
>>>
>>> Oli
>>>
>>>
>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>>> news:o G6iqwfkFHA.1440@TK2MSFTNGP14.phx.gbl...
>>>> You obviously don't understand my environment and the level of security
>>>> we require here, the DoD would not take your answer for 1 minute.
>>>> Thanks for your .02 but Software Restriction Policies DO work and when
>>>> setup properly the machine will run without a problem.
>>>>
>>>> I do understand all the items you have listed (minus the dozen other
>>>> "elements") and quite frankly they do not apply. You see, SRP is
>>>> designed to prevent a lot of the things you have mentioned. I have my
>>>> desktops working fine besides this SUS issue due to the randomly
>>>> generated folder name created when a patch is installed. With my
>>>> in-depth understanding of the items you listed, I have been able to
>>>> create a ruleset GPO that allows the OS to function and the APPROVED
>>>> apps to run. I have not had a complaint from not one of my 1200 users
>>>> which tells me I have implemented SRP successfully.
>>>>
>>>> I have decided to push forward with WSUS ahead of my plans to rememdy
>>>> this situation. Not worth the time trying to work around an issue like
>>>> this when SUS is going to be replaced anyway.
>>>>
>>>> Cheers!
>>>>
>>>> "Lawrence Garvin" <onsitechsolutions@news.postalias> wrote in message
>>>> news:%23VLsXefkFHA.1464@TK2MSFTNGP14.phx.gbl...
>>>>> I'll throw my .02 in here as well.
>>>>>
>>>>> The policy is /TOO/ restrictive.
>>>>>
>>>>> Furthermore, it causes more problems than it can possibly solve.
>>>>>
>>>>> "Locking down" a workstation to the extent being attempted requires an
>>>>> in-depth understanding of the operation of various aspects of the
>>>>> operating system, update methodologies, application installation
>>>>> processes, and a dozen other elements.
>>>>>
>>>>> My best suggestion is to /REMOVE/ the policies, and let the system do
>>>>> its job of protecting itself with the provided security tools.
>>>>>
>>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>>>>> news:emPY%23DekFHA.3148@TK2MSFTNGP09.phx.gbl...
>>>>>>I have it posted in 4 groups... just included them all in this reply.
>>>>>>
>>>>>> My users are all local admins so doing that would null the whole
>>>>>> policy.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "woef" <woef20@hotmail.com> wrote in message
>>>>>> news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
>>>>>>> maybe a question for this newsgroup
>>>>>>> microsoft.public.windows.server.update_services
>>>>>>>
>>>>>>> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
>>>>>>> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>>>>>>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>>>>>>>wouldn't run at all: my users don't have right to install anything).
>>>>>>>> So, Could you set your policy to allow SYSTEM and Administrators to
>>>>>>>> run from any path?
>>>>>>>>
>>>>>>>> --
>>>>>>>> HIH
>>>>>>>> RØ
>>>>>>>>
>>>>>>>>
>>>>>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>>>>>>>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>>>>>>>> Thanks for the response Asher
>>>>>>>>>
>>>>>>>>> I agree my policy is VERY restrictive; but it was ultimately not my
>>>>>>>>> decision to lock them down this much. Needless to say, I have
>>>>>>>>> tweaked the policy so that only approved applications run. I have
>>>>>>>>> 1200 users able to do their work as if there is no policy at all.
>>>>>>>>> Bottom line is if they are doing their work, they shouldnt have any
>>>>>>>>> problems :) 
>>>>>>>>>
>>>>>>>>> Migrating to WSUS is in my plans but I need more time to setup a
>>>>>>>>> test server.
>>>>>>>>>
>>>>>>>>> Anyone else have any ideas?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I do plan to migrate to WSUS shortly
>>>>>>>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>>>>>>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>>>>>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>>>>>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>>>>>>>
>>>>>>>>>> My first thought is that your policy may be a bit too restrictive.
>>>>>>>>>>
>>>>>>>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>>>>>>>> sub-dirs in
>>>>>>>>>> a structure inside the windows dir. You can then have your policy
>>>>>>>>>> allow
>>>>>>>>>> execution of anything under that sub-dir.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hello all, here's a good one!
>>>>>>>>>>>
>>>>>>>>>>> I am running SUS and software restriction policies on my domain.
>>>>>>>>>>> Problem seems that any patches that are approved get downloaded
>>>>>>>>>>> and
>>>>>>>>>>> run from a randomly generated directory off the C drive. My
>>>>>>>>>>> software
>>>>>>>>>>> restriction policy is locked down with ONLY the know file paths
>>>>>>>>>>> added
>>>>>>>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>>>>>>>> allowing certain sub dirs to run.
>>>>>>>>>>>
>>>>>>>>>>> I notice the initial file getting blocked is update.exe. I allow
>>>>>>>>>>> this
>>>>>>>>>>> file to execute only to find another one blocked... I dont want
>>>>>>>>>>> to
>>>>>>>>>>> have to make exceptions for every file in every future update.
>>>>>>>>>>> Any to
>>>>>>>>>>> make matters even more fun it seems the folder name where the
>>>>>>>>>>> patches
>>>>>>>>>>> are extracted to is a randomly generated name that changes EVERY
>>>>>>>>>>> time!
>>>>>>>>>>> Is there any solution for this? I can't imagine MS not allowing
>>>>>>>>>>> these two great features to not play nice together!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> First error:
>>>>>>>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has
>>>>>>>>>>> been
>>>>>>>>>>> restricted by your Administrator by the default software
>>>>>>>>>>> restriction
>>>>>>>>>>> policy level.
>>>>>>>>>>>
>>>>>>>>>>> After allowing update.exe I get:
>>>>>>>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has
>>>>>>>>>>> been
>>>>>>>>>>> restricted by your Administrator by the default software
>>>>>>>>>>> restriction
>>>>>>>>>>> policy level.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
Anonymous
August 3, 2005 1:59:39 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

<VBG>

What an /excellent/ definition of "trust"!

"JeffG" <not_here@mail.com> wrote in message
news:p ki1f11mvq5gt9bbtp07q0sun086d1ph9p@4ax.com...
> "Trust" is a word that should never be used - in any context - in any
> security policy. "Trust" is what you rely on when you have no
> security policies at all...
Anonymous
August 4, 2005 2:14:44 PM

Archived from groups: microsoft.public.softwareupdatesvcs,microsoft.public.windows.group_policy,microsoft.public.windows.server.update_services,microsoft.public.windowsxp.security_admin (More info?)

That is very true and I agree. There needs to be stiffer penalties for user
who violate the rules... If your users are educated about policies then you
can ignore the "I didn't know" answers and seek disciplinary action. We
recently held mandatory expo's that educated our users. This is all part of
the process and it seems that the upper management is going to actually
enforce the penalties for anyone who tries to "work around" the restriction
policy. Only time will tell...

To answer your question about the action taken... It all depends... If I
catch it personally, I uninstall it and tell the user not to do it again...
If I find it again, I tell their supervisor.... If our IDS system picks it
up, for example something trying to access an external server on a specific
port; our network security team files a formal ticket which goes through all
chains of command and eventually gets the user into a sit down meeting...
Lots of paper-work and other politics play into account depending on the
persons status. This part here is going to change I believe since many
people have gotten a slap on the wrist because they are key personnel. Now
that they know they shouldn't be doing this, they should catch a beating...
I guess I'll have to wait and see.

BTW - WSUS working great now!



"Ken B" <none@microsoft.com> wrote in message
news:u0vrPVCmFHA.2656@TK2MSFTNGP14.phx.gbl...
> Then logistically, if they're all adults, and it's a trust thing, then you
> shouldn't need to place software restriction policies on local admins that
> can run a script every 5 minutes to keep your policy settings from
> applying. I had one enterprising user who was trusted to have local admin
> rights running a script so the screensaver would not engage after 15
> minutes. He lost his local admin rights, and still manages to do his
> job... just with a screensaver kicking in.
>
> Just out of curiosity, what sort of 'action' is taken when a user has
> unauthorized programs on their computer? At my place, I've 'informed'
> directors of people in this case... to no avail. Come back a week later,
> heck, a day later and the app is on the computer (again!)... or was it
> even removed in the first place?
>
> Ken
>
> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
> news:eZDQ4TwkFHA.3568@TK2MSFTNGP10.phx.gbl...
>> That is a good idea but I wonder if all MS executables are signed?
>>
>> As for the other statement, I agree with you 100%. I made that point
>> across before I was told to go ahead with the implementation. It
>> basically came down to the fact that if we catch someone circumventing
>> the policy they will have no "excuses" as to why they are running
>> unauthorized apps. In the past the regulations always stated strict
>> penalties but nobody acted on them and the users made up bogus excuses.
>> We are all adults and it is basically a trust thing and if someone wants
>> to mess around they will suffer the consequences.
>>
>> Thanks for your input...
>>
>>
>> "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
>> news:o BFxTyskFHA.3260@TK2MSFTNGP10.phx.gbl...
>>> Hi there
>>>
>>> I wonder if allowing all executables signed by Microsoft would be an
>>> acceptable solution. I haven't tested this, but I think it could work.
>>>
>>> I find the notion that you allow free administrative access to
>>> workstations, but apply a software restriction policy mildly amusing.
>>> What's to stop these administrators removing or overriding your software
>>> restriction policy locally, and running unauthorised applications?
>>> Sure, Group Policy will place the policy back after (by default) 90
>>> minutes plus or minus 30, but they can still do it.
>>>
>>> Oli
>>>
>>>
>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>>> news:o G6iqwfkFHA.1440@TK2MSFTNGP14.phx.gbl...
>>>> You obviously don't understand my environment and the level of security
>>>> we require here, the DoD would not take your answer for 1 minute.
>>>> Thanks for your .02 but Software Restriction Policies DO work and when
>>>> setup properly the machine will run without a problem.
>>>>
>>>> I do understand all the items you have listed (minus the dozen other
>>>> "elements") and quite frankly they do not apply. You see, SRP is
>>>> designed to prevent a lot of the things you have mentioned. I have my
>>>> desktops working fine besides this SUS issue due to the randomly
>>>> generated folder name created when a patch is installed. With my
>>>> in-depth understanding of the items you listed, I have been able to
>>>> create a ruleset GPO that allows the OS to function and the APPROVED
>>>> apps to run. I have not had a complaint from not one of my 1200 users
>>>> which tells me I have implemented SRP successfully.
>>>>
>>>> I have decided to push forward with WSUS ahead of my plans to rememdy
>>>> this situation. Not worth the time trying to work around an issue like
>>>> this when SUS is going to be replaced anyway.
>>>>
>>>> Cheers!
>>>>
>>>> "Lawrence Garvin" <onsitechsolutions@news.postalias> wrote in message
>>>> news:%23VLsXefkFHA.1464@TK2MSFTNGP14.phx.gbl...
>>>>> I'll throw my .02 in here as well.
>>>>>
>>>>> The policy is /TOO/ restrictive.
>>>>>
>>>>> Furthermore, it causes more problems than it can possibly solve.
>>>>>
>>>>> "Locking down" a workstation to the extent being attempted requires an
>>>>> in-depth understanding of the operation of various aspects of the
>>>>> operating system, update methodologies, application installation
>>>>> processes, and a dozen other elements.
>>>>>
>>>>> My best suggestion is to /REMOVE/ the policies, and let the system do
>>>>> its job of protecting itself with the provided security tools.
>>>>>
>>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>>>>> news:emPY%23DekFHA.3148@TK2MSFTNGP09.phx.gbl...
>>>>>>I have it posted in 4 groups... just included them all in this reply.
>>>>>>
>>>>>> My users are all local admins so doing that would null the whole
>>>>>> policy.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "woef" <woef20@hotmail.com> wrote in message
>>>>>> news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
>>>>>>> maybe a question for this newsgroup
>>>>>>> microsoft.public.windows.server.update_services
>>>>>>>
>>>>>>> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
>>>>>>> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>>>>>>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>>>>>>>wouldn't run at all: my users don't have right to install anything).
>>>>>>>> So, Could you set your policy to allow SYSTEM and Administrators to
>>>>>>>> run from any path?
>>>>>>>>
>>>>>>>> --
>>>>>>>> HIH
>>>>>>>> RØ
>>>>>>>>
>>>>>>>>
>>>>>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>>>>>>>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>>>>>>>> Thanks for the response Asher
>>>>>>>>>
>>>>>>>>> I agree my policy is VERY restrictive; but it was ultimately not
>>>>>>>>> my decision to lock them down this much. Needless to say, I have
>>>>>>>>> tweaked the policy so that only approved applications run. I have
>>>>>>>>> 1200 users able to do their work as if there is no policy at all.
>>>>>>>>> Bottom line is if they are doing their work, they shouldnt have
>>>>>>>>> any problems :) 
>>>>>>>>>
>>>>>>>>> Migrating to WSUS is in my plans but I need more time to setup a
>>>>>>>>> test server.
>>>>>>>>>
>>>>>>>>> Anyone else have any ideas?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I do plan to migrate to WSUS shortly
>>>>>>>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>>>>>>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>>>>>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>>>>>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>>>>>>>
>>>>>>>>>> My first thought is that your policy may be a bit too
>>>>>>>>>> restrictive.
>>>>>>>>>>
>>>>>>>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>>>>>>>> sub-dirs in
>>>>>>>>>> a structure inside the windows dir. You can then have your policy
>>>>>>>>>> allow
>>>>>>>>>> execution of anything under that sub-dir.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hello all, here's a good one!
>>>>>>>>>>>
>>>>>>>>>>> I am running SUS and software restriction policies on my domain.
>>>>>>>>>>> Problem seems that any patches that are approved get downloaded
>>>>>>>>>>> and
>>>>>>>>>>> run from a randomly generated directory off the C drive. My
>>>>>>>>>>> software
>>>>>>>>>>> restriction policy is locked down with ONLY the know file paths
>>>>>>>>>>> added
>>>>>>>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>>>>>>>> allowing certain sub dirs to run.
>>>>>>>>>>>
>>>>>>>>>>> I notice the initial file getting blocked is update.exe. I
>>>>>>>>>>> allow this
>>>>>>>>>>> file to execute only to find another one blocked... I dont want
>>>>>>>>>>> to
>>>>>>>>>>> have to make exceptions for every file in every future update.
>>>>>>>>>>> Any to
>>>>>>>>>>> make matters even more fun it seems the folder name where the
>>>>>>>>>>> patches
>>>>>>>>>>> are extracted to is a randomly generated name that changes EVERY
>>>>>>>>>>> time!
>>>>>>>>>>> Is there any solution for this? I can't imagine MS not
>>>>>>>>>>> allowing
>>>>>>>>>>> these two great features to not play nice together!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> First error:
>>>>>>>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe
>>>>>>>>>>> has been
>>>>>>>>>>> restricted by your Administrator by the default software
>>>>>>>>>>> restriction
>>>>>>>>>>> policy level.
>>>>>>>>>>>
>>>>>>>>>>> After allowing update.exe I get:
>>>>>>>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has
>>>>>>>>>>> been
>>>>>>>>>>> restricted by your Administrator by the default software
>>>>>>>>>>> restriction
>>>>>>>>>>> policy level.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
!