icacls inheritance options
cellardoor
Does anyone have any more information on how the following inheritance
options should be used in icacls?
"Inheritance rights may precede either Perm form, and they are applied only
to directories:
(OI): object inherit
(CI): container inherit
(IO): inherit only
(NP): do not propagate inherit"
I want to use icacls on all of our Windows Server 2003 servers to add the
permissions of our regional admins. I've done a few tests but I'm just unsure
what inheritance options I should use.
I'm familiar with the terms object and container in Active Directory but
have not heard this being used where files and folders are concerned.
I tested with the following command...
icacls.exe D:\Projects\* /t /grant "UK Admins":(OI)(CI)F
I'm hoping you can help me to understand if (OI) and (CI) are both necessary
or even if I should be adding (IO) to the mix too.
Cheers!
Cellardoor
cellardoor
"UK Admins":(OI)(CI)F
and even trying it with /grant:r
will apply the permissions all the way through the file structure with child
objects getting the newly applied permission twice in affect. Once through
inheritence and once explicity defined.
Is there no way to make it not apply the permission explicity if it now gets
it from its parent? I'm sure I had this same problem with xcacls too. Sure I
could try it without the /t switch but when I ran the sysinternals accesschk
command to find all the files and folders this group didn't have access to,
it was 1000's.
It surely means you are forever more reliant on this tool to manage
permissions because if I later wanted to remove a permission from z folder it
would still be explicity defined on all the sub folders. So I can't just
remove it on the parent and expect it to take care of the child objects.
How does everyone else deal with this?
Cheers,
Cellardoor
Roger Abell [MVP]
news:450F36DE-6933-407C...@microsoft.com...
> I've also noticed, using the following cmd icacls.exe D:\Projects\* /t
> /grant
> "UK Admins":(OI)(CI)F
>
> and even trying it with /grant:r
>
> will apply the permissions all the way through the file structure with
> child
> objects getting the newly applied permission twice in affect. Once through
> inheritence and once explicity defined.
>
> Is there no way to make it not apply the permission explicity if it now
> gets
> it from its parent? I'm sure I had this same problem with xcacls too. Sure
> I
> could try it without the /t switch but when I ran the sysinternals
> accesschk
> command to find all the files and folders this group didn't have access
> to,
> it was 1000's.
>
do not use the /t option
read the icacls /? syntax: /t causes the operation to be applied at all of
the
relevant substructure
If what you apply (without /t) is inhertable then it will be stopped only
at the points in the substructure where inheritance is blocked.
> It surely means you are forever more reliant on this tool to manage
> permissions because if I later wanted to remove a permission from z folder
> it
> would still be explicity defined on all the sub folders. So I can't just
> remove it on the parent and expect it to take care of the child objects.
>
Sure. That is an implication if you have set the added permissions
explicitly everywhere, but as you seem to understand, that is not a
good approach.
Usually one knows what the permissions should be throughout a
storage structure, which means that you know if there are places
where inheritance is (supposed to be) blocked, and so you can just
issue another icacls to add a grant at those new inheritance points
(i.e. again without the /t)
Roger Abell [MVP]
Calling filesystem folders containers and files objects pre-exists Active
Directory (which adopted the uniform use of the terminology).
Thre are some lower-level discussions of NTFS filesystem inheritance
flags in the MSDN library documentation.
The OI, IO, CI are pretty standard, having existed since NTFS started.
IO menas that the ace is defined on the parent but has impact only on the
accesses calculated on the sibling structure, whereas NP is basically
the reverse that the ace only has impact on accesses based on a calculation
of permissions where the NP ace is set.
One very good way to start to get familiar with these is to just use the
gui NTFS permissions dialog to set some exotic combinations using the
advanced view's Applies to dropbox and then use icacls to report what
was the resulting ace(s)
Roger
cellardoor
to do it without the /t switch.
I've also been using a sysinternals cmd called accesschk to look for any top
level directories that the group doesn't have permission to.
Still, I thought there might be a way of insructing the cmd to only apply
permissions if they aren't already set. It still seems to apply them
explicitly even if they are already inherited from above. Not too much of a
big deal now though as I'm only setting the permissions on top level
directories rather than everything. I spose my workaround is to apply it to
the drive first, then do an accesschk command on the top level folders on the
drive to see which ones don't have access. Which should indicate to me the
ones that don't have inheritance turned on.
Or, I wonder. Is there a tool to look for all the folders that have the
inheritance flag turned off, that would work recursively?
My problem is, we are dealing with files that have been migrated to new
servers a few times down the years, and different admins have dealt with
permissions in different ways. It's like the permissions never actually get
cleaned up. I would love to reset them and apply no inheritance only where
needed but it would be too much work and would involve consulting managers of
different offices which I imagine would take time to get feedback. Maybe
something to work towards in the future.
cellardoor
say I still don't fully understand when to use each one. I just know that
(OI) and (CI) seem to produce the result closest to what I want. I will just
have to do some more testing until it clicks.
Al Dunbar
> Thanks for the input Roger. I pretty much came to the same conclusion
> myself,
> to do it without the /t switch.
>
> I've also been using a sysinternals cmd called accesschk to look for any
> top
> level directories that the group doesn't have permission to.
>
> Still, I thought there might be a way of insructing the cmd to only apply
> permissions if they aren't already set. It still seems to apply them
> explicitly even if they are already inherited from above. Not too much of
> a
> big deal now though as I'm only setting the permissions on top level
> directories rather than everything. I spose my workaround is to apply it
> to
> the drive first, then do an accesschk command on the top level folders on
> the
> drive to see which ones don't have access. Which should indicate to me the
> ones that don't have inheritance turned on.
>
> Or, I wonder. Is there a tool to look for all the folders that have the
> inheritance flag turned off, that would work recursively?
>
> My problem is, we are dealing with files that have been migrated to new
> servers a few times down the years, and different admins have dealt with
> permissions in different ways.
This sounds strikingly familiar...
> It's like the permissions never actually get
> cleaned up. I would love to reset them and apply no inheritance only where
> needed but it would be too much work and would involve consulting managers
> of
> different offices which I imagine would take time to get feedback. Maybe
> something to work towards in the future.
Ah, if only permission management were simple enough that company policy
could be set to use it in a consistent and effective way!
We have gone through various server o/s migrations, and have found that the
resulting permission structure can differ based not only on the different
ways that permissions have been handled, but (apparently) also on the
sequencing of the various changes, either to NTFS itself, or which clients
were used to adjust permissions after a migration.
/Al
Roger Abell [MVP]
Hmmm. Sounds like it didn't help out as much as I had hoped.
(OI)(CI) attribution means this is so here and everywhere it can inherit
onto
for both files (OI) and folders (CI). That combination is pretty common
such
as for the generic rights many admins limit themselves to in the non-Advance
NTFS dialog that actually do cover a fair perrcentage of use cases.
If one added (IO) it no longer applies "here" but only the inheriting area.
Roger Abell [MVP]
> Thanks for the input Roger. I pretty much came to the same conclusion
> myself,
> to do it without the /t switch.
>
Yea, the /t was saying to do what you didn't want.
> I've also been using a sysinternals cmd called accesschk to look for any
> top
> level directories that the group doesn't have permission to.
>
> Still, I thought there might be a way of insructing the cmd to only apply
> permissions if they aren't already set. It still seems to apply them
That would be a very useful option.
> explicitly even if they are already inherited from above. Not too much of
> a
> big deal now though as I'm only setting the permissions on top level
> directories rather than everything. I spose my workaround is to apply it
> to
> the drive first, then do an accesschk command on the top level folders on
> the
> drive to see which ones don't have access. Which should indicate to me the
> ones that don't have inheritance turned on.
>
If you are setting up a storage one can also restructure so inheritance
blocking
is not used and perhaps use DFS to present a user image that differs.
> Or, I wonder. Is there a tool to look for all the folders that have the
> inheritance flag turned off, that would work recursively?
>
One can just check the flag in the security descriptor, even just from
script.
> My problem is, we are dealing with files that have been migrated to new
> servers a few times down the years, and different admins have dealt with
> permissions in different ways. It's like the permissions never actually
> get
Hmmm, yes that does introduce complexities (no choices in structuring, and
especially if some was ever NT 4 or maybe even early W2k one cannot
always trust the flags about inheritance/inherited being as expected in the
security descriptors)
> cleaned up. I would love to reset them and apply no inheritance only where
> needed but it would be too much work and would involve consulting managers
> of
> different offices which I imagine would take time to get feedback. Maybe
> something to work towards in the future.
Understood (overmuch). At least capture from your present efforts the
enumeration of points where inheritance is altered. As those mark one
category of the major spots where use cases change (the other is where
new grants (aces actually, grant or deny) get explicitly added (onto what
is being inherited). You would have a good start on an initial design
structuring to (factor about, dfs consolidate, and) present for use case
review by those managers.
Roger