Permanently Changing Windows XP Security Settings?

pnutjam asks: "I have googled and perused several publications seeking an answer but I find no mention of this problem anywhere. I am running applications not designed for a multi-user environment on Windows XP. To allow standard users to run these applications I've modified permissions on files, folders, and registry keys. Whenever a computer with the modifications is rebooted, the permissions revert to their previous settings. It doesn't happen when the users log off, only when the computers are rebooted." When adjusting Windows XP to support such applications, how do you make permission changes so that they survive through a reboot?

Comments

An ACTUAL Answer to your question

[RGautier]

Likely changes are being made to permissions in the registry permissions on your machine due to security policy, which is implemented on the machine when it is turned on. You'll want to edit things that you want to change in the Control Panel, under Administrative Tools, in the icon that says "Local Security Policy" and I apologize for my compatriots who have been less than kind...

Something is wrong here.

[obeythefist]

When I first read this ask-for-help I thought it was a linux guy having a troll.

I've modified permissions on files, folders, and registry keys. Whenever a computer with the modifications is rebooted, the permissions revert to their previous settings.

Windows does not alter ACL's (access control lists) on files or folders at boot time. It is possible that you or someone else has configured a startup process or logon script (under Win2X active directory, computers can have logon scripts) that repermissions folders or files. I suggest either a full audit of the logon process or a rebuild to a standard windows (with latest patches, see www.windowsupdate.com).

Registry settings by default are not altered by the startup/shutdown process, but again there may be a group policy or logon script attached to the object in AD somehow that is launching a permissioning process, or inheriting a new registry hive, although this is exceedingly unlikely. Again, a complete rebuild would solve this.

If you do the rebuild and it does not help, check with your application support. From my 7 years of Windows drudgery and experience, 75% or more of "Windows" problems come from third party apps or PEBKACs.

If you're unwilling to do the build or the application support people can't help you, contact Microsoft. They're very expensive, but they are very good at what they do, despite what the Slashdot crowd would have you believe.