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?

> 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.

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?

--
aws


"Ian" wrote:

> > 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.
>
>

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


"Al Small" <AlSmall@discussions.microsoft.com> wrote in message
news:5B3D539F-A2DD-4682-B024-14EC0DAD3CF5@microsoft.com...
> 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?
>
> --
> aws
>
>
> "Ian" wrote:
>
>> > 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.
>>
>>

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" wrote:

> 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
>
>
> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> news:5B3D539F-A2DD-4682-B024-14EC0DAD3CF5@microsoft.com...
> > 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?
> >
> > --
> > aws
> >
> >
> > "Ian" wrote:
> >
> >> > 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.
> >>
> >>
>
>
>

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


"Al Small" <AlSmall@discussions.microsoft.com> wrote in message
news:A3091279-1332-446C-B4CB-2F73D51C3EE9@microsoft.com...
> 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" wrote:
>
>> 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
>> Ls. ---
>> Steve
>>
>>
>> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> news:5B3D539F-A2DD-4682-B024-14EC0DAD3CF5@microsoft.com...
>> > 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?
>> >
>> > --
>> > aws
>> >
>> >
>> > "Ian" wrote:
>> >
>> >> > 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.
>> >>
>> >>
>>
>>
>>

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" wrote:

> 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
>
>
> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> news:A3091279-1332-446C-B4CB-2F73D51C3EE9@microsoft.com...
> > 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" wrote:
> >
> >> 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
> >> Ls. ---
> >> Steve
> >>
> >>
> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> >> news:5B3D539F-A2DD-4682-B024-14EC0DAD3CF5@microsoft.com...
> >> > 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?
> >> >
> >> > --
> >> > aws
> >> >
> >> >
> >> > "Ian" wrote:
> >> >
> >> >> > 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.
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

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


"Al Small" <AlSmall@discussions.microsoft.com> wrote in message
news99023D4-9A1F-4F30-9A87-5E26CB0B402D@microsoft.com...
> 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" wrote:
>
>> 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
>>
>>
>> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> news:A3091279-1332-446C-B4CB-2F73D51C3EE9@microsoft.com...
>> > 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" wrote:
>> >
>> >> 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
>> >> Ls. ---
>> >> Steve
>> >>
>> >>
>> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> >> news:5B3D539F-A2DD-4682-B024-14EC0DAD3CF5@microsoft.com...
>> >> > 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?
>> >> >
>> >> > --
>> >> > aws
>> >> >
>> >> >
>> >> > "Ian" wrote:
>> >> >
>> >> >> > 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.
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

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" wrote:

> Sounds good. If you get time let me know if it does what you need or
> t. --- Steve
>
>
> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> news99023D4-9A1F-4F30-9A87-5E26CB0B402D@microsoft.com...
> > 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" wrote:
> >
> >> 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
> >>
> >>
> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> >> news:A3091279-1332-446C-B4CB-2F73D51C3EE9@microsoft.com...
> >> > 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" wrote:
> >> >
> >> >> 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
> >> >> Ls. ---
> >> >> Steve
> >> >>
> >> >>
> >> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
> >> >> news:5B3D539F-A2DD-4682-B024-14EC0DAD3CF5@microsoft.com...
> >> >> > 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?
> >> >> >
> >> >> > --
> >> >> > aws
> >> >> >
> >> >> >
> >> >> > "Ian" wrote:
> >> >> >
> >> >> >> > 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.
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

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>


"Al Small" <AlSmall@discussions.microsoft.com> wrote in message
news:711E1ACE-61FE-463F-8CCB-F9F6734CE6D6@microsoft.com...
> 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" wrote:
>
>> Sounds good. If you get time let me know if it does what you need or
>> t. --- Steve
>>
>>
>> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> news99023D4-9A1F-4F30-9A87-5E26CB0B402D@microsoft.com...
>> > 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" wrote:
>> >
>> >> 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
>> >>
>> >>
>> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> >> news:A3091279-1332-446C-B4CB-2F73D51C3EE9@microsoft.com...
>> >> > 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" wrote:
>> >> >
>> >> >> 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
>> >> >> Ls. ---
>> >> >> Steve
>> >> >>
>> >> >>
>> >> >> "Al Small" <AlSmall@discussions.microsoft.com> wrote in message
>> >> >> news:5B3D539F-A2DD-4682-B024-14EC0DAD3CF5@microsoft.com...
>> >> >> > 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?
>> >> >> >
>> >> >> > --
>> >> >> > aws
>> >> >> >
>> >> >> >
>> >> >> > "Ian" wrote:
>> >> >> >
>> >> >> >> > 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.
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>