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

Mr. Obscure!

[delus10n0]

Hey, let's post an Ask Slashdot question asking about Windows XP security/settings, and fail to mention:

1) What application we're using that requires these settings.

2) What our user setup is like. Are the users in the "Users" group, or the "Administrators" group? Are they part of the local machine, or a networked setup of users?

3) Where this application is being installed to. Have we tried other locations? What permissions does it need?

4) What you are doing exactly to remove permissions; what users/groups?

Maybe with the details, we can provide a more proper answer. K thanks bye.

Use WMI

[Ropati]

This isn't really a fix, but it is a way around your problem. Set up a script using WMI to change all your permissions, shares and registry entries. Place the script in the startup folder and forget about it.

Download the script samples and modify as necessary from:
http://www.microsoft.com/technet/community/ scriptc enter/sampscr.mspx

Policy Objects

[Oriumpor]

GPO's are there for this purpose. If you can't afford licensing then I'd say you need to read up on VB scripting.

Don't get me wrong, I'm not saying you need to become a genious in it to do this stuff... but not knowing GPO's and VBS is like not knowing RC's and #!/bin/sh.

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.

experts exchange

[Scottarius]

try asking this question at experts exchange. You'll find people there will be much more helpful with this issue.

Better to call Psychic Friends Network

[Futurepower(R)]

Those with experience know that if you have a difficult Microsoft technical support question, it is better to ask the Psychic Friends Network. They don't know the answer either, but they are more friendly and less expensive.

I've asked 3 questions of MS Tech support recently, and got 0.00 useful answers. For anyone who would like more accuracy in that number, it was 0.00000000000 useful answers.

Microsoft technical support people not only cannot answer your question, but they are prevented by the Microsoft management hierarchy from communicating with anyone who would know the answer.

Also, permissions policy in NTFS has some bugs, apparently. (Mentioned by someone else, earlier. I've encountered quirkiness, also.) There is at least one policy setting in Windows XP that says, "Only works in Windows 2000".

Often a commercial company will not tell the truth about bugs. That's why I like Open Source people. They are honest about bugs. I reported 3 bugs in the NET USE command in Windows XP, and Microsoft Technical Support refused to do anything about it. Too much paperwork to report bugs, I guess.

use security templates

[sahtanax]

start => run => mmc
file => add snap-in
add => security templates

set your file / registry / services info in the template. save it as .inf

then apply the template
secedit /configure /cfg myfile.inf /db myfile.sdb /log myfile.log

that will compile the inf into a sdb [security db], and apply it. any result will be written to the log. by convention...

sdb location:
%windir%\security\Database

logs:
%windir%\security\logs

inf:
%windir%\security\templates ...where "%windir%" is the windows install dir... i.e. C:\windows or C:\winnt

bonus: the templace [myfile.inf] can then be copied and applied to any other win2k+ workstation /server.

Re:Domain

[BrynM]

Is the custom app hard coded to those directories? If, by some lucky chance it's not on the C drive, you can have it shared and then map it to a network drive to make it think it's running from the right location (you can mount a local share).

You may also want to check out this MS article about creating junction points. It's the "proper" way to link directories, but don't try anythong too complicated or you will just screw up NTFS. By complicated I mean trying to link different sub-directories inside linked directories.

While you're at MS, take a close look at LinkD on the 2K Resource Kit. That may be just the ticket for making that custom app run from a server or from a different directory. If you don't have the ResKit, you can grab LinkD and other tools from the free offerings from the ResKit. I've used it inside a batch file wrapper for onery custom apps that clients insist on. Be sure to have the batch file un-link the directory at the end or un-link it if it exists at startup. NTFS doesn't like to have a bunch of these around or mangled. Here's the LinkD syntax:

linkd source [/d] [destination] [/?]

Where:

source
displays the Windows 2000 name targeted by source.
source [destination]
links source to destination (target), which can be any valid Windows 2000 directory name, device name, or object name.
source [/d]
deletes source, regardless of whether a link to a destination exists for that source.
/?
prints this help message. Type linkd /? | more to see all the help text.
LinkD's syntax is case-insensitive. If a source or destination name contains a space, the name must be surrounded by quotation marks. All characters in both the source and destination names must be in the ASCII character set; usage of Unicode characters is not supported.

A tool to be careful with, but a handy one.