Software Restriction Hash

[Klose]

My GP Machine software restriction hash prevents a user
from installing an applicaiton OK , but still allows the
local admin to install it.
The option was set to ALL USERS, so the local admins
could not bypass it.

Why doesn't this work?

 

[Steven L Umbach]

I assume this is an XP Pro or W2003 machine as SRP do not work on W2K
machines. Possibly the administrator is using a different version of the
application that does not correspond to the hash. See link below for more
details on SRP as you may also want to try path rules in addition to
ash. -- Steve

http://www.microsoft.com/technet/tr...et/prodtechnol/winxppro/maintain/rstrplcy.asp

 

[klose]

Hi Steve,

It is a 2003 AD domain and GP.
These policies are being applied on XP Pro.

I am already working from the white paper you referred and have been
reviewing your similar related posts.
There is some other issue going on.

The hash was created, in this case AOL V9, in the machine GP policy.
The same copy of the software was moved to the XP pro client and tested. The
hash is an exact match.
I have been testing this GP on a test container and new GP with only these
options. The user and the machine are both getting this GP applied and
confirmed with gpupdate/result.

Specifically, the option which prevents local admins is not working.
When a regular user logs on, they are prevented to install. When a local
admin logs on, they can freely install the software.

The path rule could be used, and I have not tried that yet. But the Hash
should block the install. I prefer to get the hash working to prevent the
exe from running at all.

I wonder if there is some other local or GP that overides this local admin
rule.

 

[Steven L Umbach]

OK. I have not tried it with machine configuration yet. From your post it sounds as
if the user the policy is not being applied to is logging onto the local machine as
local administrator and not the domain as a regular user who also is in the local
administrators group on that computer. Since it is a machine policy, that would lead
me to also believe it should affect all users on that computer logging into the local
machine or the domain. What happens when a domain user that is also in the local
administrators group logs onto that machine? Are they denied access to run that
application? Of course restricting any local administrator is extremely difficult as
they can do things like create local administrator accounts and unjoin computers from
the domain. --- Steve

 

[noreply.tklose]

Update:
I opened a ticket with MS and we found a security bug.
Software restriction hashes do not work on digitally
signed files.
When you create the hash policy against the file, you do
not get the true hash value.
The true hash can not seen unless you use a md5 hash
utility. You can try this on Winzip v8 or aol V9 files.

You can manully edit the registry to fix each one on a
local machine, but we have not found a work around to do
this through group policy yet. Perhaps I have to create a
custom policy and I will continue to experiment with
this....

Right click the properties of the file to see if it is
digitally signed.

This could be a serious threat as a managed computer
network can not protect a rouge install of a digitally
signed file!

-----Original Message-----
OK. I have not tried it with machine configuration yet. From your post it sounds as
if the user the policy is not being applied to is

logging onto the local machine as

local administrator and not the domain as a regular user who also is in the local
administrators group on that computer. Since it is a

machine policy, that would lead

me to also believe it should affect all users on that

computer logging into the local

machine or the domain. What happens when a domain user that is also in the local
administrators group logs onto that machine? Are they denied access to run that
application? Of course restricting any local

administrator is extremely difficult as

they can do things like create local administrator

accounts and unjoin computers from

 

[Steven L Umbach]

Wow! Thanks for the update. I hope they are working on a quick resolution
and thanks so much for posting this info so we all can know what is going
on. --- Steve