Re: Software restriction policies and Windows XP

Dear Steven,

thanks for your answer.
Does rsop.msc show that SRP are being applied and by the Group Policy you expect?

Answer: No!

There is a basic question. You can configure SRP by computer- and user
configuration. By default and computer configuration SRP is set to unrestrict
in the GPO. If you user loggon, what happend? Dose user configuration setting
overwritte the computer configuration for SRP? I found out, if I configure
SRP by computer configuration same like for user configuration and link this
GPO also to computer account, SRP works as expected! What's the order of GPO
in this case (last is computer configuration)?

I did a fault. By exclu. there was EXE. After I removed EXE loggon does not
work also not for local administrator. Now I only can loggon in safe mode.
How can I turn off the SRP for Computer- and User configuration? I deleted
the link in GPMC and moved computer account to another OU without any GPO.
After gpupdate on DC, the problem exists.

Thans.
Soheil

"Steven L Umbach" schrieb:

Does rsop.msc show that SRP are being applied and by the Group Policy you
expect? For hash rules you need to make sure that the hash is the same on
the client computer as you defined. You could also try a path rule for
word.exe as a test to see if that works or not. When tweaking SRP check the
application log on the client computer as often a SRP event will be recorded
that can help you troubleshoot why SRP does not work as expected. Also keep
in mind that shortcuts are also restricted by SRP. So if you are trying to
start word.exe via a desktop or menu shortcut it could be that the shortcut
itself is restricted. You can also try executing word.exe directly to see if
that is the case.

Steve


"Soheil" <Soheil@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F2AB0C2C-2487-437D-9306-58C65572D494@xxxxxxxxxxxxxxxx
Hi,

default security level is "Disallowed" by User Configuration. By
"Additinal
Rules" I created a new Hash Rule.

I did link that GPO to an OU with my users. When a user is logged on
Windows
XP Prof SP2, "Disallowed"

What works? "Disallowed" Software works. Nice!
What not works? The Hash Rule which should allowes starting of "word.exe".

I had a look on WinXP Prof. by gpedit.msc. If you look by "Local Computer
Policy" you'll find by "User configuration", "Windows Settings", "Security
Settings" no folder named "Software Restriction policies" (regardless of
logged on localy or not).

But if run rsop.msc on that WinXP Prof, the is a "Software Restrictin
Policies" folder.

Why the restriction policies works half? And why rsop shows not
"Disallowed"
as default level? Does have this to do with missing ADM Files or
permissions!?

Thanks for any help.
Soheil





.

Relevant Pages

  • Re: Software restriction policies and Windows XP
    ... I have never tried configuring both user and computer configuration for SRP ... GPO also to computer account, ... Rules" I created a new Hash Rule. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Prevent users running executables from pen drives
    ... | The fact that they are power users will not be a problem with SRP. ... XP Pro computers can have their ...
    (microsoft.public.win2000.security)
  • Re: Prevent users running executables from pen drives
    ... The fact that they are power users will not be a problem with SRP. ... XP Pro computers can have their ...
    (microsoft.public.win2000.security)
  • Re: Prevent users running executables from pen drives
    ... The best solution I know of would be to use XP Pro computers and Software Restriction ... SRP can be configured to allow users to run only authorized applications ... computer configuration they can also apply to local administrators if need be by ... XP Pro computers can have their Group Policy ...
    (microsoft.public.win2000.security)
  • Re: Computer componet of GP not being applied
    ... When you open the GPO for editing, ... Configuration and User Configuration. ... >> If you look at the properties of the OU in which the Terminal Server ... >>> It all seems to be linked to the local user groups on the terminal ...
    (microsoft.public.windows.group_policy)