Security Template does not apply folder permissions

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Right now I have a folder that has some permissions directly on it. I
want to use a security template to modify it so that it does not have
any permissions directly on it and instead inherits permissions from
its parent.

I created a security template, and in the File System section I added
an entry for the folder. I checked the "Configure this file or folder
then" box, and then made sure there were no permissions in the Security
tab and that the Advanced section had the "Inherit from parent the
permission entries that apply to child objects" box checked.

Then I saved the template, went to Security Configuration and Analysis
and opened a database, imported the template, and then configured the
computer. But it didn't apply the template setting to the folder --
the folder still had permissions directly on it, and did not inherit
anything from its parent. I analyzed the computer, and in the File
System it did not have a green check mark or red X on the folder; it
just said "subitems defined".

As a side note, I did have an entry for a different folder in my
template (but that one was to directly define a permission onto the
folder). After configuring the computer, that setting was applied (it
showed the green check mark).

Anyone know why the security template doesn't work for a folder when I
want that folder to inherit permissions?
 
I have never tried doing it that way, find it an interesting approach
(configure, but with no grants, however specifying to receive
inheritables), and am unsure just what did (or not) happen.
However, on an XP fully up-to-date, I cannot repro what you see,
instead seeing the expected behavior (i.e. dir is left with only
inherited permission settings). Does your line in the template
look like the following? (i.e. does it have 0,"D:AR" ?)
"%SystemDrive%\Temp\test",0,"D:AR"

As said, I have not done this objective that way, but instead define
permissions at the parent and specify to configure the parent and
replace existing permissions on substructure with inheritables.
Now, your circumstance might make that not workable, if the parent
has for example three subfolders and the one you want set to purely
inherit is only one (you want the other three unchanged). In that case
you would add definitions for the other two ticked for Do not allow
permissions to be changed. This would not work out so well if you
have a hundred subdirs, all but of few of which should be left as is.
However, that will do it.

Roger
 
Roger said:
I have never tried doing it that way, find it an interesting approach
(configure, but with no grants, however specifying to receive
inheritables), and am unsure just what did (or not) happen.
However, on an XP fully up-to-date, I cannot repro what you see,
instead seeing the expected behavior (i.e. dir is left with only
inherited permission settings). Does your line in the template
look like the following? (i.e. does it have 0,"D:AR" ?)
"%SystemDrive%\Temp\test",0,"D:AR"
Click to expand...

I had originally encountered the problem on my XP laptop at home. Then
yesterday, I attempted to reproduce the problem on my XP machine at
work. But I couldn't reproduce it. However, I just did another test
on my work machine, and encountered the problem.

Here's what I did:

I created 4 directories:
- c:\testing\inherit_propagate (this was set to inherit perms from its
parent)
- c:\testing\inherit_replace (this was set to inherit perms from its
parent)
- c:\testing\noinherit_propagate (this had inheritance disabled, and
had some perms directly defined on it)
- c:\testing\noinherit_replace (this had inheritance disabled, and had
some perms directly defined on it)

(In addition, each of those directories contained 2 subdirectories for
the purpose of testing the Propagate and Replace options - one that
inherited, and one that did not inherit)

Then I created a security template and put 4 entries into the File
System section:
- one for c:\testing\inherit_propagate - I told it to disable
inheritance and directly define some perms, and then checked the
"Propagate" box
- one for c:\testing\inherit_replace - I told it to disable inheritance
and directly define some perms, and then checked the "Replace" box
- one for c:\testing\noinherit_propagate - I removed all directly
defined perms and checked the inheritance box, and then checked
"Propagate"
- one for c:\testing\noinherit_replace - I removed all directly defined
perms and checked the inheritance box, and then checked "Replace"

Then I saved the template, created a database, imported the template,
and configured the computer.

The c:\testing\inherit_propagate and c:\testing\inherit_replace
directories had the template applied properly. The
c:\testing\noinherit_propagate and c:\testing\noinherit_replace
directories were not affected at all.

I then analyzed the computer, and it reported the following:
- c:\testing\inherit_propagate - green check mark (however, it did not
put green check marks on the 2 subfolders for some reason)
- c:\testing\inherit_replace - green check mark, and also green check
marks on the 2 subfolders
- c:\testing\noinherit_propagate - nothing, and nothing on the 2
subfolders
- c:\testing\noinherit_replace - red X, but for some reason it put
green check marks on the 2 subfolders

Here is what the template looks like:

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[File Security]
"%SystemDrive%\testing\noinherit_replace",2,"D:AR"
"%SystemDrive%\testing\noinherit_propagate",0,"D:AR"
"%SystemDrive%\testing\delete_this_one",0,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"
"%SystemDrive%\testing\inherit_replace",2,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"
"%SystemDrive%\testing\inherit_propagate",0,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"

As said, I have not done this objective that way, but instead define
permissions at the parent and specify to configure the parent and
replace existing permissions on substructure with inheritables.
Now, your circumstance might make that not workable, if the parent
has for example three subfolders and the one you want set to purely
inherit is only one (you want the other three unchanged). In that case
you would add definitions for the other two ticked for Do not allow
permissions to be changed. This would not work out so well if you
have a hundred subdirs, all but of few of which should be left as is.
However, that will do it.
Click to expand...

Hmm, let me think about that.

Thanks for your help, Roger.
 
So I have to factor and group your test . . .

4 directories:

- c:\testing\inherit_propagate
(this was set to inherit perms from its parent)
template File System section:
I told it to disable inheritance
and directly define some perms,
and then checked the "Propagate" box
"%SystemDrive%\testing\inherit_propagate",0,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"
configure: had the template applied properly
post-configure analyze reported:
Click to expand...
green check mark, did not put green check marks on the 2 subfolders
comment:
that all seems normal; green check marks are placed where the
sddl requires a change, but it would result in no change.
the subfolders are not required to be changed (only if not aligned
to the spec)

- c:\testing\inherit_replace
(this was set to inherit perms from its parent)
template File System section:
I told it to disable inheritance
and directly define some perms,
and then checked the "Replace" box
"%SystemDrive%\testing\inherit_replace",2,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"
configure: had the template applied properly
post-configure analyze reported:
Click to expand...
green check mark, and also green check marks on the 2 subfolders
comment:
as before, here subfolders were specified to be replace (2) regardless
Admittedly placement of checkmarks is a little "peculiar" and
takes some getting used to. Also, be aware the the counts of
discrepancies is known to be highly obscure (actually I was told
by a member of that team that it is actually just plain in error as
the summing propagates up)

- c:\testing\noinherit_propagate
(this had inheritance disabled,
and had some perms directly defined on it)
template File System section:
I removed all directly defined perms
and checked the inheritance box,
and then checked "Propagate"
"%SystemDrive%\testing\noinherit_propagate",0,"D:AR"
configure: directories were not affected at all.
post-configure analyze reported:
Click to expand...
nothing, and nothing on the 2 subfolders
comment:
I do not repro this result
post-config analyze is green check, subdirs not checked
permissions are changed as expected, including the state
of the inheritance spec - but note, the non-inheriting subdir
is left unchanged (we are only propagating, not replacing
and that dir does not allow propagation onto it)

- c:\testing\noinherit_replace
(this had inheritance disabled,
and had some perms directly defined on it)
template File System section:
I removed all directly defined perms
and checked the inheritance box,
and then checked "Replace"
"%SystemDrive%\testing\noinherit_replace",2,"D:AR"
configure: directories were not affected at all.
post-configure analyze reported:
Click to expand...
red X, but green check marks on the 2 subfolders
comment:
I do not repro this result
post-config analyze is green checked, subdirs green checked
permissions are as expected, including the state of the
inheritance spec, and entire sturcture is purely inheriting
from its parent, all subdirs included


Notes:
I defined the structure to parallel you cases, used your
template slightly editied, but in all critical ways unchanged,
did an NTbackup of the empty structure of dirs, opened
sec database in imported template with clearing, analyzed
(at this point variances were
red x at each upper dir, red x on each non-inheriting sub dir
of a *_replace upper dir, green check on each inheriting sub
dir of a *_replace upper dir, plain unmarked folders for all
sub dirs of *_propagate
these are what I would expect)
then configured, and finally reanalyzed.



Roger said:
I have never tried doing it that way, find it an interesting approach
(configure, but with no grants, however specifying to receive
inheritables), and am unsure just what did (or not) happen.
However, on an XP fully up-to-date, I cannot repro what you see,
instead seeing the expected behavior (i.e. dir is left with only
inherited permission settings). Does your line in the template
look like the following? (i.e. does it have 0,"D:AR" ?)
"%SystemDrive%\Temp\test",0,"D:AR"
Click to expand...

I had originally encountered the problem on my XP laptop at home. Then
yesterday, I attempted to reproduce the problem on my XP machine at
work. But I couldn't reproduce it. However, I just did another test
on my work machine, and encountered the problem.

Here's what I did:

I created 4 directories:
- c:\testing\inherit_propagate (this was set to inherit perms from its
parent)
- c:\testing\inherit_replace (this was set to inherit perms from its
parent)
- c:\testing\noinherit_propagate (this had inheritance disabled, and
had some perms directly defined on it)
- c:\testing\noinherit_replace (this had inheritance disabled, and had
some perms directly defined on it)

(In addition, each of those directories contained 2 subdirectories for
the purpose of testing the Propagate and Replace options - one that
inherited, and one that did not inherit)

Then I created a security template and put 4 entries into the File
System section:
- one for c:\testing\inherit_propagate - I told it to disable
inheritance and directly define some perms, and then checked the
"Propagate" box
- one for c:\testing\inherit_replace - I told it to disable inheritance
and directly define some perms, and then checked the "Replace" box
- one for c:\testing\noinherit_propagate - I removed all directly
defined perms and checked the inheritance box, and then checked
"Propagate"
- one for c:\testing\noinherit_replace - I removed all directly defined
perms and checked the inheritance box, and then checked "Replace"

Then I saved the template, created a database, imported the template,
and configured the computer.

The c:\testing\inherit_propagate and c:\testing\inherit_replace
directories had the template applied properly. The
c:\testing\noinherit_propagate and c:\testing\noinherit_replace
directories were not affected at all.

I then analyzed the computer, and it reported the following:
- c:\testing\inherit_propagate - green check mark (however, it did not
put green check marks on the 2 subfolders for some reason)
- c:\testing\inherit_replace - green check mark, and also green check
marks on the 2 subfolders
- c:\testing\noinherit_propagate - nothing, and nothing on the 2
subfolders
- c:\testing\noinherit_replace - red X, but for some reason it put
green check marks on the 2 subfolders

Here is what the template looks like:

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[File Security]
"%SystemDrive%\testing\noinherit_replace",2,"D:AR"
"%SystemDrive%\testing\noinherit_propagate",0,"D:AR"
"%SystemDrive%\testing\delete_this_one",0,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"
"%SystemDrive%\testing\inherit_replace",2,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"
"%SystemDrive%\testing\inherit_propagate",0,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"

As said, I have not done this objective that way, but instead define
permissions at the parent and specify to configure the parent and
replace existing permissions on substructure with inheritables.
Now, your circumstance might make that not workable, if the parent
has for example three subfolders and the one you want set to purely
inherit is only one (you want the other three unchanged). In that case
you would add definitions for the other two ticked for Do not allow
permissions to be changed. This would not work out so well if you
have a hundred subdirs, all but of few of which should be left as is.
However, that will do it.
Click to expand...

Hmm, let me think about that.

Thanks for your help, Roger.
Click to expand...
 
the form I used really should have been:


- c:\testing\inherit_propagate
(this was set to inherit perms from its parent)
template File System section:
I told it to disable inheritance (i.e. D:P)
and directly define some perms (i.e += D:PAR(...)(.))
template application: <--- <--- new <---
checked the "Propagate" box (sic - selected radio) (ie += 0,"D:P...)
"%SystemDrive%\testing\inherit_propagate",0,"D:PAR(...)(.)
etc.
instead of :
template File System section:
I told it to disable inheritance
and directly define some perms,
and then checked the "Propagate" box

Also . . .
I have hint to suspect issue is part in expectations of
just what Propagate means as distinct from Replace.
Prior does not, later does overrule an inheritance block.
 
Roger said:
the form I used really should have been:


- c:\testing\inherit_propagate
(this was set to inherit perms from its parent)
template File System section:
I told it to disable inheritance (i.e. D:P)
and directly define some perms (i.e += D:PAR(...)(.))
template application: <--- <--- new <---
checked the "Propagate" box (sic - selected radio) (ie += 0,"D:P...)
"%SystemDrive%\testing\inherit_propagate",0,"D:PAR(...)(.)
etc.
instead of :
template File System section:
I told it to disable inheritance
and directly define some perms,
and then checked the "Propagate" box
Click to expand...

Thank you for taking the time to try to reproduce this, Roger.
Something is definitely going on, as I have encountered it on 2
different XP machines now. I will try to find a simpler setup that
causes the problem.

Also . . .
I have hint to suspect issue is part in expectations of
just what Propagate means as distinct from Replace.
Prior does not, later does overrule an inheritance block.
Click to expand...

I expect Propagate to mean that the permissions keep going down and
stops when it hits something that does not have the inherit box
checked. I expect Replace to force everything underneath to inherit
those permissions.
 
I just tried having one folder that did not inherit, and specified in
the template for that folder to inherit permissions. The SCaA did not
have any problems applying that to the folder.

So then I tried having 2 folders, and reproduced the problem. This was
the setup:

c:\testone - it did not inherit, and had one permission directly
defined on it - Everyone: Full Control (applies to this folder,
subfolders, and files)

c:\testone\inherit - it had no permissions directly on it, and
inherited from its parent

c:\testone\noinherit - it did not inherit, and had one permission
directly defined on it - MyUserAccount: Full Control (applies to this
folder, subfolders, and files)

Then I added 2 entries in the File System section of the template:
- c:\testone\inherit - I unchecked the inherit box, added a few
permissions, and had the Propagate box checked

- c:\testone\noinherit - I removed all permissions, checked the inherit
box, and had the Propagate box checked

I used SCaA to configure the computer, and it worked for
c:\testone\inherit, but not for c:\testone\noinherit.

An analysis showed c:\testone\inherit having a green check mark, and
c:\testone\noinherit having nothing.

I'm running version 5.1.2600.2180 of Security Configuration and
Analysis (same version number is reported for Security Templates too).
 
I can only check XP versions at moment but they are as
you have stated, and I have used prior scenario and .inf
on other machines today without reproducing results that
you report for that scenario.
 
Your case that failed for you here
c:\testone\noinherit
is as far as I can tell not materially different from
c:\testing\noinherit_propagate
case of prior scenario, either in setup, template rule,
or result you experience.

Again, I cannot trigger the behavior you report.
On how many systems can you have this happen?
 
Roger said:
Your case that failed for you here
c:\testone\noinherit
is as far as I can tell not materially different from
c:\testing\noinherit_propagate
case of prior scenario, either in setup, template rule,
or result you experience.
Click to expand...

Right, but just hoping I can create a scenario that will cause it to
fail for you. What about the parent directory? I set c:\testone (in
my latest test) and c:\testing (in my previous test) to have direct
permissions and not inherit anything. Is that what you had for your
test?

Again, I cannot trigger the behavior you report.
On how many systems can you have this happen?
Click to expand...

Two XP systems so far. There is a third XP system I can try Friday or
over the weekend.
 
What is on parent in my tests seem to have no effect, and I do
not see what codepath might exist in the SCaA binaries that
would care about these differences (algorithms would not
need to refer to parent context to determine application on
dir with a Filesystem rule in the template).

Nevertheless I have just restored prior scenario after having
set parent so that now these three cases have been tried
Parent ACLd with
a) some of each, inherited and explicit
b) inheritance blocked, some explicit grants
c) purely inheriting

In my case "parent" means "test" in c:\temp\test\noinherit_propagate
and inherited originates from c:, c:\temp, c:\temp\test if allowed
(and yes I did test with c:\temp blocking and not blocking inherit)

In all cases I am seeing the same results as I have previously.
 
Roger said:
What is on parent in my tests seem to have no effect, and I do
not see what codepath might exist in the SCaA binaries that
would care about these differences (algorithms would not
need to refer to parent context to determine application on
dir with a Filesystem rule in the template).

Nevertheless I have just restored prior scenario after having
set parent so that now these three cases have been tried
Parent ACLd with
a) some of each, inherited and explicit
b) inheritance blocked, some explicit grants
c) purely inheriting

In my case "parent" means "test" in c:\temp\test\noinherit_propagate
and inherited originates from c:, c:\temp, c:\temp\test if allowed
(and yes I did test with c:\temp blocking and not blocking inherit)

In all cases I am seeing the same results as I have previously.
Click to expand...

I just tried a 3rd XP machine.

TEST 1:

c:\test (inherited perms)
c:\test\noinherit (direct perms, and had the template try to get it to
inherit perms)
c:\test\yesinherit (inherited perms, and had the template try to give
it direct perms)

Configure computer was successful.


TEST 2:

c:\test2 (inherited perms)
c:\test2\inherit (inherited perms, and had the template try to give it
direct perms)
c:\test2\noinherit (direct perms, and had the template try to get it to
inherit perms)

Configure computer was successful.


TEST 3:

c:\test3 (direct perms)
c:\test3\inherit (inherited perms, and had the template try to give it
direct perms)
c:\test3\noinherit (direct perms, and had the template try to get it to
inherit perms)

This test failed, but in the opposite way of my earlier failures. This
time, c:\test3\noinherit actually did inherit perms after I did the
configure. But c:\test3\inherit was not affected (it still inherited
from its parent, and did not have the direct permissions applied to
it). After doing an analyze, and looking at c:\test3, it says
"Subitems defined" for Permission and Audit for the 2 subfolders, along
with 0 for Inconsistent Values, and the 2 subfolders have nothing on
them (no green checks or red Xs).
 
Well, I do not know what you have going on.

I paste in the inf I have been using below, which as you will
notice is essentially your from earlier post, but I have removed
the removethis excess. I assume that all directories named in
your inf actually do exist, that you can view their actual security
when in the template editor.

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[File Security]
"%SystemDrive%\Temp\test\noinherit_replace",2,"D:AR"
"%SystemDrive%\Temp\test\noinherit_propagate",0,"D:AR"
"%SystemDrive%\Temp\test\inherit_replace",2,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"
"%SystemDrive%\Temp\test\inherit_propagate",0,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"


be wary of the linewrap on last two lines
 
Roger said:
Well, I do not know what you have going on.

I paste in the inf I have been using below, which as you will
notice is essentially your from earlier post, but I have removed
the removethis excess. I assume that all directories named in
your inf actually do exist, that you can view their actual security
when in the template editor.

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[File Security]
"%SystemDrive%\Temp\test\noinherit_replace",2,"D:AR"
"%SystemDrive%\Temp\test\noinherit_propagate",0,"D:AR"
"%SystemDrive%\Temp\test\inherit_replace",2,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"
"%SystemDrive%\Temp\test\inherit_propagate",0,"D:PAR(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)"


be wary of the linewrap on last two lines
Click to expand...

Roger, would you be able to try one more test? I notice one difference
between your tests and my tests is that your parent folder is
underneath C:\Temp, while my parent folder is under the C:\ root. I
have tried your setup, and am not able to reproduce the problem. Would
you be able to try having a c:\test, c:\test\inherit, c:\test\noinherit
to see if that will cause the problem? Thanks.
 
[email protected] said:
Roger, would you be able to try one more test? I notice one difference
between your tests and my tests is that your parent folder is
underneath C:\Temp, while my parent folder is under the C:\ root. I
have tried your setup, and am not able to reproduce the problem. Would
you be able to try having a c:\test, c:\test\inherit, c:\test\noinherit
to see if that will cause the problem? Thanks.
Click to expand...

Oh, can you also make sure to try the c:\test with direct permissions?
 
Done.

I find it interesting that you cannot repro if you have an added
level of dir structure; but I cannot see why that would matter.

I have to report no change in behavior seen in trials you requested.

What I did . . .
restore c:\temp\test structure
move .\test so that it is c:\test
check\alter permissions on c:\test
3 cases: purely inheriting from c:, only explicit with no inheritance,
inheriting but with some added explicit grants
spot check that the permissions on the 12 dirs under c:\test are
as expected (i.e. the post restore move did not alter and changes
to grant state of c:\test properly reflected)
analyzed against template version with temp\ removed
configured, reanalyzed
observed post-configure analysis showed identically to previously
reported and spot checked the 12 dirs NTFS dialog, especially
those which you have reported do not configure as expected.
I experienced nothing unexpected.

Roger
 
Roger said:
Done.

I find it interesting that you cannot repro if you have an added
level of dir structure; but I cannot see why that would matter.

I have to report no change in behavior seen in trials you requested.

What I did . . .
restore c:\temp\test structure
move .\test so that it is c:\test
check\alter permissions on c:\test
3 cases: purely inheriting from c:, only explicit with no inheritance,
inheriting but with some added explicit grants
spot check that the permissions on the 12 dirs under c:\test are
as expected (i.e. the post restore move did not alter and changes
to grant state of c:\test properly reflected)
analyzed against template version with temp\ removed
configured, reanalyzed
observed post-configure analysis showed identically to previously
reported and spot checked the 12 dirs NTFS dialog, especially
those which you have reported do not configure as expected.
I experienced nothing unexpected.
Click to expand...

Thank you for trying, Roger.

This is perhaps an intermittent problem, as I just tried another test
(which had produced the problem the other day) and it worked fine.
 
Your issue is very troublesome, as it should either be working
100% or we should be able to pin the interruption of reliable
usage onto something.

Roger
 
Back
Top