- Software Restriction Policy
- Posted by rasdr on November 3rd, 2005
We have some software restriction policies on our domain which disallow
users from running chat software, some of our prohibited software list, as
well as games. We were attempting today to add a hash for the installer
file for Real Player 10, which we don't want users in the domain installing
on their workstations (if they have admin privileges).
We're finding that the hashes for the executable that runs a program (ie:
realplay.exe) work just fine, but we're unable to restrict the installer
file from running. It's as if the has rule is totally ignored.
Does anybody have any suggestions as to what might be the reason for this?
- Posted by Steven L Umbach on November 3rd, 2005
What you might try to set up a test computer that has very restrictive
settings for Software Restriction Policies such as one with the default
disallowed rule [and you may need to lockdown from there] and then try to
install Real Player on it as a regular user assuming that is what your
general user population is to have a similar user experience. When the
installation fails look in the application log to see the name of the
executable that was denied and try creating a hash rule for that file. One
of my computers is locked down pretty tight so I tried to download and
install Real Player and this is what I found in the application log
indicating that
RealPlayer10-5GOLD_bb[1].exe may be a file to try and restrict. --- Steve
Event Type: Warning
Event Source: Software Restriction Policies
Event Category: None
Event ID: 866
Date: 11/2/2005
Time: 8:00:28 PM
User: N/A
Computer: STEVE-XP
Description:
Access to D:\Documents and Settings\Steve\Local Settings\Temporary Internet
Files\Content.IE5\6789SBCV\RealPlayer10-5GOLD_bb[1].exe has been restricted
by your Administrator by location with policy rule
{dd369e61-f6f5-4e21-8ce3-58c8257ddc15} placed on path D:\Documents and
Settings\
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
"rasdr" <bogus.email@bogusaddress.com> wrote in message
news:11miojuea6oc918@corp.supernews.com...
> We have some software restriction policies on our domain which disallow
> users from running chat software, some of our prohibited software list, as
> well as games. We were attempting today to add a hash for the installer
> file for Real Player 10, which we don't want users in the domain
> installing on their workstations (if they have admin privileges).
>
> We're finding that the hashes for the executable that runs a program (ie:
> realplay.exe) work just fine, but we're unable to restrict the installer
> file from running. It's as if the has rule is totally ignored.
>
> Does anybody have any suggestions as to what might be the reason for this?
>
- Posted by rasdr on November 3rd, 2005
Thanks for the suggestion....I'll give it a shot at work tomorrow.
"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
news:rMCdnVr9rv7h5PTeRVn-jw@comcast.com...
> What you might try to set up a test computer that has very restrictive
> settings for Software Restriction Policies such as one with the default
> disallowed rule [and you may need to lockdown from there] and then try to
> install Real Player on it as a regular user assuming that is what your
> general user population is to have a similar user experience. When the
> installation fails look in the application log to see the name of the
> executable that was denied and try creating a hash rule for that file. One
> of my computers is locked down pretty tight so I tried to download and
> install Real Player and this is what I found in the application log
> indicating that
> RealPlayer10-5GOLD_bb[1].exe may be a file to try and restrict. --- Steve
>
> Event Type: Warning
> Event Source: Software Restriction Policies
> Event Category: None
> Event ID: 866
> Date: 11/2/2005
> Time: 8:00:28 PM
> User: N/A
> Computer: STEVE-XP
> Description:
> Access to D:\Documents and Settings\Steve\Local Settings\Temporary
> Internet Files\Content.IE5\6789SBCV\RealPlayer10-5GOLD_bb[1].exe has been
> restricted by your Administrator by location with policy rule
> {dd369e61-f6f5-4e21-8ce3-58c8257ddc15} placed on path D:\Documents and
> Settings\
>
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
>
>
> "rasdr" <bogus.email@bogusaddress.com> wrote in message
> news:11miojuea6oc918@corp.supernews.com...
>> We have some software restriction policies on our domain which disallow
>> users from running chat software, some of our prohibited software list,
>> as well as games. We were attempting today to add a hash for the
>> installer file for Real Player 10, which we don't want users in the
>> domain installing on their workstations (if they have admin privileges).
>>
>> We're finding that the hashes for the executable that runs a program (ie:
>> realplay.exe) work just fine, but we're unable to restrict the installer
>> file from running. It's as if the has rule is totally ignored.
>>
>> Does anybody have any suggestions as to what might be the reason for
>> this?
>>
>
>
- Posted by Rhonda Rasmussen on November 8th, 2005
I didn't have a chance to attempt this at work until today. It seems
that I left one very important thing out of the equation. We are still
running SP1 on our corporate desktops. Software restriction events for
SP1 systems are logged in the system events, so if a non-admin user was
attempting to run a restricted package, there are no events logged in
the system events because non-admins are unable to write there.
Since I had an SP2 system in my lab, I attempted the SRP on that system
and found that it works just fine under SP2 when hashing the installer
itself. It seems to be an issue isolated to SP1 only.
If you can think of anything else that we might try, I'd appreciate
hearing about it. We do have MS Premier support, so at some point this
week, we'll likely open an incident with them anyways. Thanks for all
your help Steven.
Steven L Umbach wrote:
>What you might try to set up a test computer that has very restrictive
>settings for Software Restriction Policies such as one with the default
>disallowed rule [and you may need to lockdown from there] and then try to
>install Real Player on it as a regular user assuming that is what your
>general user population is to have a similar user experience. When the
>installation fails look in the application log to see the name of the
>executable that was denied and try creating a hash rule for that file. One
>of my computers is locked down pretty tight so I tried to download and
>install Real Player and this is what I found in the application log
>indicating that
>RealPlayer10-5GOLD_bb[1].exe may be a file to try and restrict. --- Steve
>
>Event Type: Warning
>Event Source: Software Restriction Policies
>Event Category: None
>Event ID: 866
>Date: 11/2/2005
>Time: 8:00:28 PM
>User: N/A
>Computer: STEVE-XP
>Description:
>Access to D:\Documents and Settings\Steve\Local Settings\Temporary Internet
>Files\Content.IE5\6789SBCV\RealPlayer10-5GOLD_bb[1].exe has been restricted
>by your Administrator by location with policy rule
>{dd369e61-f6f5-4e21-8ce3-58c8257ddc15} placed on path D:\Documents and
>Settings\
>
>For more information, see Help and Support Center at
>http://go.microsoft.com/fwlink/events.asp.
>
>
>"rasdr" <bogus.email@bogusaddress.com> wrote in message
>news:11miojuea6oc918@corp.supernews.com...
>
>
>>We have some software restriction policies on our domain which disallow
>>users from running chat software, some of our prohibited software list, as
>>well as games. We were attempting today to add a hash for the installer
>>file for Real Player 10, which we don't want users in the domain
>>installing on their workstations (if they have admin privileges).
>>
>>We're finding that the hashes for the executable that runs a program (ie:
>>realplay.exe) work just fine, but we're unable to restrict the installer
>>file from running. It's as if the has rule is totally ignored.
>>
>>Does anybody have any suggestions as to what might be the reason for this?
>>
>>
>>
>
>
>
>
- Posted by rasdr on November 8th, 2005
I didn't have a chance to attempt this at work until today. It seems that
I left one very important thing out of the equation. We are still running
SP1 on our corporate desktops. Software restriction events for SP1 systems
are logged in the system events, so if a non-admin user was attempting to
run a restricted package, there are no events logged in the system events
because non-admins are unable to write there.
Since I had an SP2 system in my lab, I attempted the SRP on that system and
found that it works just fine under SP2 when hashing the installer itself.
It seems to be an issue isolated to SP1 only.
If you can think of anything else that we might try, I'd appreciate hearing
about it. We do have MS Premier support, so at some point this week, we'll
likely open an incident with them anyways. Thanks for all your help Steven.
"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
news:rMCdnVr9rv7h5PTeRVn-jw@comcast.com...
> What you might try to set up a test computer that has very restrictive
> settings for Software Restriction Policies such as one with the default
> disallowed rule [and you may need to lockdown from there] and then try to
> install Real Player on it as a regular user assuming that is what your
> general user population is to have a similar user experience. When the
> installation fails look in the application log to see the name of the
> executable that was denied and try creating a hash rule for that file. One
> of my computers is locked down pretty tight so I tried to download and
> install Real Player and this is what I found in the application log
> indicating that
> RealPlayer10-5GOLD_bb[1].exe may be a file to try and restrict. --- Steve
>
> Event Type: Warning
> Event Source: Software Restriction Policies
> Event Category: None
> Event ID: 866
> Date: 11/2/2005
> Time: 8:00:28 PM
> User: N/A
> Computer: STEVE-XP
> Description:
> Access to D:\Documents and Settings\Steve\Local Settings\Temporary
> Internet Files\Content.IE5\6789SBCV\RealPlayer10-5GOLD_bb[1].exe has been
> restricted by your Administrator by location with policy rule
> {dd369e61-f6f5-4e21-8ce3-58c8257ddc15} placed on path D:\Documents and
> Settings\
>
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
>
>
> "rasdr" <bogus.email@bogusaddress.com> wrote in message
> news:11miojuea6oc918@corp.supernews.com...
>> We have some software restriction policies on our domain which disallow
>> users from running chat software, some of our prohibited software list,
>> as well as games. We were attempting today to add a hash for the
>> installer file for Real Player 10, which we don't want users in the
>> domain installing on their workstations (if they have admin privileges).
>>
>> We're finding that the hashes for the executable that runs a program (ie:
>> realplay.exe) work just fine, but we're unable to restrict the installer
>> file from running. It's as if the has rule is totally ignored.
>>
>> Does anybody have any suggestions as to what might be the reason for
>> this?
>>
>
>
- Posted by Steven L Umbach on November 8th, 2005
Interesting. I don't have an SP1 computer right now. Make sure that the hash
has not changed if a new or different version is being access by users and
you could also try a path rule if you know the path that they are using
which probably is what you see in the SRP Event ID you are seeing in the
application log if you are accessing the file that same way as the users
are. The path rule could be for a specific file, a specific extension such
as *.exe, or any file protected by SRP. A more brute force way would be to
disallow users from executing any content in specific folders in their user
profile or their whole user profile. On my home computers I have a path rule
for disallowed to c:\documents and settings\ as another step to help prevent
malware/spyware from being installed on my computer. --- Steve
"rasdr" <bogus.email@bogusaddress.com> wrote in message
news:11n002u987aut8e@corp.supernews.com...
> I didn't have a chance to attempt this at work until today. It seems that
> I left one very important thing out of the equation. We are still running
> SP1 on our corporate desktops. Software restriction events for SP1
> systems are logged in the system events, so if a non-admin user was
> attempting to run a restricted package, there are no events logged in the
> system events because non-admins are unable to write there.
>
> Since I had an SP2 system in my lab, I attempted the SRP on that system
> and found that it works just fine under SP2 when hashing the installer
> itself. It seems to be an issue isolated to SP1 only.
>
> If you can think of anything else that we might try, I'd appreciate
> hearing about it. We do have MS Premier support, so at some point this
> week, we'll likely open an incident with them anyways. Thanks for all
> your help Steven.
>
> "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
> news:rMCdnVr9rv7h5PTeRVn-jw@comcast.com...
>> What you might try to set up a test computer that has very restrictive
>> settings for Software Restriction Policies such as one with the default
>> disallowed rule [and you may need to lockdown from there] and then try to
>> install Real Player on it as a regular user assuming that is what your
>> general user population is to have a similar user experience. When the
>> installation fails look in the application log to see the name of the
>> executable that was denied and try creating a hash rule for that file.
>> One of my computers is locked down pretty tight so I tried to download
>> and install Real Player and this is what I found in the application log
>> indicating that
>> RealPlayer10-5GOLD_bb[1].exe may be a file to try and restrict. ---
>> Steve
>>
>> Event Type: Warning
>> Event Source: Software Restriction Policies
>> Event Category: None
>> Event ID: 866
>> Date: 11/2/2005
>> Time: 8:00:28 PM
>> User: N/A
>> Computer: STEVE-XP
>> Description:
>> Access to D:\Documents and Settings\Steve\Local Settings\Temporary
>> Internet Files\Content.IE5\6789SBCV\RealPlayer10-5GOLD_bb[1].exe has been
>> restricted by your Administrator by location with policy rule
>> {dd369e61-f6f5-4e21-8ce3-58c8257ddc15} placed on path D:\Documents and
>> Settings\
>>
>> For more information, see Help and Support Center at
>> http://go.microsoft.com/fwlink/events.asp.
>>
>>
>> "rasdr" <bogus.email@bogusaddress.com> wrote in message
>> news:11miojuea6oc918@corp.supernews.com...
>>> We have some software restriction policies on our domain which disallow
>>> users from running chat software, some of our prohibited software list,
>>> as well as games. We were attempting today to add a hash for the
>>> installer file for Real Player 10, which we don't want users in the
>>> domain installing on their workstations (if they have admin privileges).
>>>
>>> We're finding that the hashes for the executable that runs a program
>>> (ie: realplay.exe) work just fine, but we're unable to restrict the
>>> installer file from running. It's as if the has rule is totally
>>> ignored.
>>>
>>> Does anybody have any suggestions as to what might be the reason for
>>> this?
>>>
>>
>>
>
>
- Posted by Steven L Umbach on November 8th, 2005
Another thought is to verify that the settings for SRP have propagated to
the computers where the SRP is not working. The best way would be to run
Resultant Set of Policy in logging mode for the computer/user in question.
This can be done from a Windows 2003 domain controller or on the XP Pro
computer itself. --- Steve
"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
news:dZadnbHvQonpj-3eRVn-jw@comcast.com...
> Interesting. I don't have an SP1 computer right now. Make sure that the
> hash has not changed if a new or different version is being access by
> users and you could also try a path rule if you know the path that they
> are using which probably is what you see in the SRP Event ID you are
> seeing in the application log if you are accessing the file that same way
> as the users are. The path rule could be for a specific file, a specific
> extension such as *.exe, or any file protected by SRP. A more brute force
> way would be to disallow users from executing any content in specific
> folders in their user profile or their whole user profile. On my home
> computers I have a path rule for disallowed to c:\documents and settings\
> as another step to help prevent malware/spyware from being installed on my
> computer. --- Steve
>
>
> "rasdr" <bogus.email@bogusaddress.com> wrote in message
> news:11n002u987aut8e@corp.supernews.com...
>> I didn't have a chance to attempt this at work until today. It seems
>> that I left one very important thing out of the equation. We are still
>> running SP1 on our corporate desktops. Software restriction events for
>> SP1 systems are logged in the system events, so if a non-admin user was
>> attempting to run a restricted package, there are no events logged in the
>> system events because non-admins are unable to write there.
>>
>> Since I had an SP2 system in my lab, I attempted the SRP on that system
>> and found that it works just fine under SP2 when hashing the installer
>> itself. It seems to be an issue isolated to SP1 only.
>>
>> If you can think of anything else that we might try, I'd appreciate
>> hearing about it. We do have MS Premier support, so at some point this
>> week, we'll likely open an incident with them anyways. Thanks for all
>> your help Steven.
>>
>> "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
>> news:rMCdnVr9rv7h5PTeRVn-jw@comcast.com...
>>> What you might try to set up a test computer that has very restrictive
>>> settings for Software Restriction Policies such as one with the default
>>> disallowed rule [and you may need to lockdown from there] and then try
>>> to install Real Player on it as a regular user assuming that is what
>>> your general user population is to have a similar user experience. When
>>> the installation fails look in the application log to see the name of
>>> the executable that was denied and try creating a hash rule for that
>>> file. One of my computers is locked down pretty tight so I tried to
>>> download and install Real Player and this is what I found in the
>>> application log indicating that
>>> RealPlayer10-5GOLD_bb[1].exe may be a file to try and restrict. ---
>>> Steve
>>>
>>> Event Type: Warning
>>> Event Source: Software Restriction Policies
>>> Event Category: None
>>> Event ID: 866
>>> Date: 11/2/2005
>>> Time: 8:00:28 PM
>>> User: N/A
>>> Computer: STEVE-XP
>>> Description:
>>> Access to D:\Documents and Settings\Steve\Local Settings\Temporary
>>> Internet Files\Content.IE5\6789SBCV\RealPlayer10-5GOLD_bb[1].exe has
>>> been restricted by your Administrator by location with policy rule
>>> {dd369e61-f6f5-4e21-8ce3-58c8257ddc15} placed on path D:\Documents and
>>> Settings\
>>>
>>> For more information, see Help and Support Center at
>>> http://go.microsoft.com/fwlink/events.asp.
>>>
>>>
>>> "rasdr" <bogus.email@bogusaddress.com> wrote in message
>>> news:11miojuea6oc918@corp.supernews.com...
>>>> We have some software restriction policies on our domain which disallow
>>>> users from running chat software, some of our prohibited software list,
>>>> as well as games. We were attempting today to add a hash for the
>>>> installer file for Real Player 10, which we don't want users in the
>>>> domain installing on their workstations (if they have admin
>>>> privileges).
>>>>
>>>> We're finding that the hashes for the executable that runs a program
>>>> (ie: realplay.exe) work just fine, but we're unable to restrict the
>>>> installer file from running. It's as if the has rule is totally
>>>> ignored.
>>>>
>>>> Does anybody have any suggestions as to what might be the reason for
>>>> this?
>>>>
>>>
>>>
>>
>>
>
>