Resetting C-drive permissions w/o damaging data, apps, user profil

[Guest]

In trying to tighten up security for file sharing two WinXP-ProSP2 systems in
a Workgroup (not Domain), I reset NTFS Special Permissions on overall hard
drives; I have since discovered this was a big mistake! Should I use
SECEDIT as described in KBID313222 to restore defaults in this situation?
Will it affect applications settings, data, or user profiles? What is
difference between this approach and using the predefined default security
template, setup security.inf?

 

[Guest]

KB 313222

Tried this on a test machine, and it did what it was supposed to. HST this
machine had no NTFS permissions (was setup on FAT and converted) not sure if
the same would apply with unusual permissions set.

As for the difference -- not sure.

For controlling access to shares I'd always advocate using share
permissions. Share permissions are more limited in scope, but behave more
predictably. The problem with folder-permissions is that they 'stick to'
files when the files are transferred elsewhere within the same tree, and this
causes no end of confusion.

If you _are_ going to set folder-permissions, then the classic pitfall is to
forget to include the Administrator(s) in the ACL. Make this mistake in a
good few places, and you'll find you've made yourself a load of grief. The
other thing to be careful of is not to create a situation in which the
contents can't be read under whatever account the system-backup runs. This is
less likely with tape but very possible with disk-to-disk (NAS) backup.

 

[Guest]

Ian--Thank you for sharing your experience with SECEDIT on FAT-to-NTFS, but I
think our new machines came formatted NTFS--Simple Permissions (that's not
FAT is it?), and I changed settings to NTFS--Special Permissions.

I agree with your advice to change only Sharing Permissions and not NTFS
Security Permissions. But I think the problem is not that I changed security
permissions just for user Documents and Settings but for the entire
"C"-drive, and I mistakenly pushed those changes down via inheritance to
folders/files in all sub-directories, including Program Files and Windows!
(My advice to others: never tamper while ignorant and tired.)

So before I create a bigger problem, I need to know if there is anything I
should know about using SECEDIT to reset defaults? For example, will I need
to reload apps?

 

[Steven L Umbach]

You can go ahead an use secedit as described in the KB but you may find that
user/group permissions that you had defined to be other than default
probably will be changed back to default which is a fairly secure setup but
may deny access to non default groups that you have added. An administer
will be able to logon to run/configure applications and manage ACLs. ---
Steve

 

[Guest]

Steve--Thank you; secedit is sounding better, but under the circumstances
which is the better solution, "secedit" or "setup security.inf" the
predefined security template? Will either do the job? If so, what are pros
and cons of each?--Al

 

[Steven L Umbach]

I believe the KB article will use a security template that is in the
\windows\repair folder that is used during computer original configuration
and probably is closer to what default setting would be than setup
security.inf. You could compare the two security templates with the Security
Configuration and Analysis mmc snapin or viewing them with the Security
template mmc snapin. Either way you may want to use the /areas filestore
switch to change just file permissions. --- Steve

 

[Guest]

Steve--Thank you; I plan to follow your suggestion and use secedit with the
areas filestore switch. Wishing you the blessing of Christmas--Al

 

[Steven L Umbach]

Sounds good. If you get time let me know if it does what you need or
t. --- Steve

 

[Guest]

Steve--I'm having trouble getting secedit/configure to function per
kbid3132220; it keeps returning to command prompt and opening help as if I
had entered %windir%\help\secedit.chm. I tried various syntax adjustments
such as space/no-space between parameter labels and filenames. I found that
the database file, secsetup.sdb did not exist in the windows root, the
windows\repair, or the windows\security\database directories, so I launched
mmc, snapped-in Security Configuration and Analysis tool and asked it to
analyze using secsetup.sdb with secsetup.inf template. That seemed to work
and generated the secsetup.sdb which I then tried to use with the
secedit/configure command, but still same result.
There must be something basic I'm failing to do. Any idea? Or, is it
possible that secedit works only with group policy in domain? Our two
Win-XP-Pro systems operate standalone or as peers in workgroup only w/o
server. Should I use different tool in my case? Regards--Al

 

[Steven L Umbach]

It should work and I just tried it on an XP Pro computer of mine to make
sure. I just copied and pasted the command from the KB article and added
/areas filestore to the end of the command. Below is the result. It does not
matter if it is a domain computer or not. --- Steve

D:\Documents and Settings\Steve>secedit /configure /cfg
%windir%\repair\secsetup
..inf /db secsetup.sdb /verbose /areas filestore

Task is completed. Some files in the configuration are not found on this
system
so security cannot be set/queried. It's ok to ignore.
See log %windir%\security\logs\scesrv.log for detail info.

D:\Documents and Settings\Steve>

 

[Guest]

Steve--Thank you; copy/paste did the trick! I was making a spacing syntax
error--sorry to trouble you. Happy New Year--Al

 

[Steven L Umbach]

Cool. I am a terrible typist. I always cut and paste where I can. Great that
you got it to work. --- Steve