Confusion over IO (Inherit Only) ACE on Vista
Gerry Hickman
I created a simple application to show/change the ACEs of a DACL on a
FileSystem folder. Everything works as expected to list the ACEs, but
before I can proceed with adding new ACEs, I want to understand the
correct way of doing it.
In the past, I would just add the new ACE with inheritance flags, but I
notice on Vista, when using the official Microsoft Format command, they
actually create _two_ ACEs for each Trustee. Here is a dump of a default
FileSystem folder called 'udf' on a Vista D: drive
d:\udf BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
Notice each ACE is repeated! Apparently the second ACE is called
"Inherit Only" and does not apply to the folder upon which it is applied?
The "old" way of doing it for the Administrators ACE would look
something like this
BUILTIN\Administrators:(I)(OI)(CI)(RX)
My question is, WHY are there two ACEs for each Trustee?
--
Gerry Hickman (London UK)
Jialiang Ge [MSFT]
This is a very good question: Why are there two ACEs for each trustee
(Administrators, System, Authenticated Users, etc) in Windows Vista?
The default NTFS Discretionary Access Control List (DACL) settings are
changed in Windows Vista. This is documented in the KB article
Changes to the default NTFS Discretionary Access Control List (DACL)
settings in Windows Vista
http://support.microsoft.com/kb/949608
===================================
In Windows XP, the default DACL settings for the %systemroot% directory and
for the data drives are like this:
BUILTIN\Administrators Full control (OI)(CI)
, where there is only one entry for the Administrators group. The setting
is not only granted to the current dir, but also inherited by the sub dirs
and files.
When a user creates a folder in XP, the user will have "Full Control"
permission on "This folder only". So there is no inherit permission to
subfolders. When another user creates a new subfolder, the first user does
not have permission to modify the subfolder. (This explains the example at
the beginning of the KB article)
===================================
In Windows Vista, the default settings are changed:
BUILTIN\Administrators Full control
BUILTIN\Administrators Full control (OI)(CI)(IO)
The first line is the security setting of the current folder, and the
second line is the "Inherit Only (IO)" securities, and it "does not apply
to the folder upon which it is applied" as you understood. The two entries
allow us to separate the security of the current dir from the inheritance
security (OI)(CI)(IO). For example:
BUILTIN\Users Read and execute
BUILTIN\Users Generic read, generic execute (OI)(CI)(IO)
Does the above KB and explanation answer your questions? Please feel free
to tell me if you have any other questions or concerns.
Have a very nice day!
Regards,
Jialiang Ge (jia...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.
MSDN Managed Newsgroup support offering is for non-urgent issues where an
initial response from the community or a Microsoft Support Engineer within
2 business day is acceptable. Please note that each follow up response may
take approximately 2 business days as the support professional working with
you may need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations that require urgent,
real-time or phone-based interactions. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Gerry Hickman
Thank you for your help with this. I had read the KB article, but your text
below is more helpful.
The confusion was caused by using Vista as the test environment. I'm
actually only interested in how it works on Windows Server 2003 and Windows
Server 2008. The KB article appears to be about a fix for a design issue in
XP, I've never used XP, so I didn't know about the default DACLs.
Now I'm looking at Windows Server 2003 and Windows Server 2008, I notice
things are different to XP/Vista. Is there a KB article with the defaults
for server o/s?
Initial testing on 2003/2008 indicates they follow the same structure and it
looks like this for a sub-folder
\\tower\d$\ts1 BUILTIN\Administrators:(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
BUILTIN\Users:(I)(CI)(AD)
BUILTIN\Users:(I)(CI)(WD)
Note the very first entry "BUILTIN\Administrators:(F)", I do NOT like this!
Windows has created a hard coded ACL at the point the sub-folder was
created. If I create more sub-folders, I see the same problem.
Ultimately, what I'm trying to achieve is to add an ACE to a DACL that will
simply inherit down to all new sub-folders created below it. This is for
user's own homeDirectory shares and also for areas of corporate-wide mapped
drives where multiple users can create sub-folders in their own top-level
folders.
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:zw5gmDhS...@TK2MSFTNGHUB02.phx.gbl...
Jialiang Ge [MSFT]
The change of default DACL in Vista does not apply to Windows Server 2003
and Windows Server 2008. The default DACL settings in 2003 and 2008 are
similar to that in Windows XP, except one major difference: the very first
entry "BUILTIN\Administrators:(F)".
I don't think the very first entry "BUILTIN\Administrators:(F)" is a bad
idea. It appears there because of this Local Policy setting:
Windows Server 2003 -> Administrative Tools -> Local Security Policy ->
Local Policy -> Security Options -> System objects: Default owner for
objects created by members of the Administrators group.
In Windows 2003, the default value of this setting is "Administrators
group". Thus, if the folder was created by a member of the Administrators
group, the folder would be owned by "Administrators group", and the ACE
entry "BUILTIN\Administrators:(F)" would be added. The rest "Full Control"
ACEs are inherited from the parent folder:
BUILTIN\Administrators:(I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
This setting ensures that administrators could have better chance to
full-control the folder, even if the folder does not inherit ACE from its
parent.
In Windows XP, the default value of "System objects: Default owner for
objects created by members of the Administrators group" is "Object creator"
(see KB: http://support.microsoft.com/kb/318825/en-us), thus you do not see
the entry "BUILTIN\Administrators:(F)" in XP, instead, you see an
additional Full-control ACE for the creator.
Does this explanation answer your concerns on "BUILTIN\Administrators:(F)"?
If you really dislike it, you may consider changing the above security
option in Windows Server 2003.
> Ultimately, what I'm trying to achieve is to add an ACE to a DACL that
> will simply inherit down to all new sub-folders created below it. This
> is for user's own homeDirectory shares and also for areas of
> corporate-wide mapped drives where multiple users can create
> sub-folders in their own top-level folders.
It seems that what you are trying to do can be achieved with this option in
the dialog "Advanced Security Settings for <foldername>" of the
most-top-level folder:
"Replace permission entries on all child objects with entries shown here
that apply to child objects"
All subfolders and files will have all their permission entries reset to
the same permissions as the parent object. But please note: If you do this,
after you click Apply or OK, you cannot undo this operation if you click to
clear the check boxes. Please let me know whether you like this idea. I'm
researching to see how to do it programmatically.
Regards,
Jialiang Ge (jia...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Gerry Hickman
Thank you for the update on this. I think the two things as related to the
same problem.
1. The adding of the BUILTIN\Administrators:(F) ACL to every sub-folder on
Windows Server is done because inheritance might break, but it should not
break in the first place!
2. In my app I'd like to add an ACE that will inherit down for all existing
and newly created folders below it.
One thing I noticed while experimenting with this, is that if I set an
inheritable ACE at the top of a big tree of folders and files, there's a
long delay, and it seems the ACE has to be applied to every folder and file
below the root? I find this odd, because I thought inheritance was supposed
to solve the performance problems of having to apply the ACE all the way
down the tree...
Anyway, I have enough information for now, I found the Athorization section
of the SDK which covers this in some detail, so I'll set up some more
specific tests.
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:wYdgfTuS...@TK2MSFTNGHUB02.phx.gbl...
Jialiang Ge [MSFT]
> Windows Server is done because inheritance might break, but it should not
> break in the first place!
I agree. I'm also interested in why some inheritances break on your side. Do
your clients have the permission to set their folders or subfolders to not
inherit from the parent object? Does the break happen to many folders or
just few?
> One thing I noticed while experimenting with this, is that if I set an
> inheritable ACE at the top of a big tree of folders and files, there's a
> long delay, and it seems the ACE has to be applied to every folder and
> file below the root? I find this odd, because I thought inheritance was
> supposed to solve the performance problems of having to apply the ACE all
> the way down the tree...
It is because the ACEs of every nodes/subnodes under the root are being
reset to the new list. A simple & quick "inheritance" cannot solve the
problem because some sub-nodes may be set to not inherit ACE from the parent
object. The system needs to traverse every nodes, remove the "not inhert"
settings, and set the new values.
In addition, I just replied to your another thread "Delete File - Bypass
NTFS?", where you can find a solution to remove those folders without
resetting their ACEs.
Have a very nice day!
Regards,
Gerry Hickman
Regarding the question about Windows server adding
BUILTIN\Administrators:(F)
to new folders created by a member of the Administrators group. I did
not mean to imply we were seeing a problem of inheritance failure. We
are not seeing this problem. Your comment was:
"This setting ensures that administrators could have better chance to
full-control the folder, even if the folder does not inherit ACE from
its parent."
I find this strange. I'd expect everything to be controlled by
inheritance from the parent folders.
Thanks for the group policy tip, but I will leave it on default. I need
everything to work as standard Windows.
Gerry Hickman
Regarding inheritance flag being set on every folder and file:
> It is because the ACEs of every nodes/subnodes under the root are being
> reset to the new list. A simple & quick "inheritance" cannot solve the
> problem because some sub-nodes may be set to not inherit ACE from the parent
> object. The system needs to traverse every nodes, remove the "not inhert"
> settings, and set the new values.
OK, thanks. This makes sense.
Gerry Hickman
> BUILTIN\Administrators Full control
> BUILTIN\Administrators Full control (OI)(CI)(IO)
>
> The first line is the security setting of the current folder, and the
> second line is the "Inherit Only (IO)" securities, and it "does not apply
> to the folder upon which it is applied" as you understood. The two entries
> allow us to separate the security of the current dir from the inheritance
> security (OI)(CI)(IO).
Unfortunately, I still don't understand this. I do notice that it's a
very common scheme on Microsoft formatted volumes and I _think_
xcacls.vbs also creates ACE's in a similar way, but I don't know why.
I've also just tested creating a new ACE for WS1\LocalUser on a folder
called "testfolder" on the D drive of Windows Vista using the basic GUI,
and I do NOT see this behavior. Here are the two print-outs of the ACLs
on my folder before the change, and after the change:
testfolder BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
testfolder WS1\LocalUser:(OI)(CI)(M)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
Note that the GUI has added
WS1\LocalUser:(OI)(CI)(M)
only one ACE??
If I look at all other folders and files below this point, they have
correctly inherited the ACE, and if I create a new folder below this
point, it also inherits the ACE.
Jialiang Ge [MSFT]
I understand that you expected to see two ACE entries for WS1\LocalUser
after you added the user using the basic GUI of Explorer: one for the
current dir, and the other for inheritance.
In fact, the pattern
BUILTIN\Administrators Full control
BUILTIN\Administrators Full control (OI)(CI)(IO)
only applies to the "default" DACL of the Windows Vista data drive and the
system directory, in order to solve the problem of XP (see the Introduction
section of KB 949608).
It does not apply to our addition & edition of the DACL setting. Our own
addition & edition still follow the old pattern in Windows XP. Does it
answer your question of the only one ACE?
I understand your confusions. DACL settings are not very easy to
understand. If you have any other questions or concerns, please feel free
to tell me.
Regards,
Jialiang Ge (jia...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Gerry Hickman
> I understand that you expected to see two ACE entries for WS1\LocalUser
> after you added the user using the basic GUI of Explorer: one for the
> current dir, and the other for inheritance.
>
> In fact, the pattern
> BUILTIN\Administrators Full control
> BUILTIN\Administrators Full control (OI)(CI)(IO)
> only applies to the "default" DACL of the Windows Vista data drive and the
> system directory, in order to solve the problem of XP (see the Introduction
> section of KB 949608).
>
> It does not apply to our addition & edition of the DACL setting. Our own
> addition & edition still follow the old pattern in Windows XP.
My observation is that adding a new ACE to the DACL using the GUI does
not give the same result as the Microsoft Format.exe defaults.
My question is "which method is best"?
I now understand that the second "inherit only" ACE
BUILTIN\Administrators Full control (OI)(CI)(IO)
is similar to choosing "Subfolders Only" in the GUI, and as you said
earlier, this would allow the inheritance permissions to be controlled
separately to the permissions on the current folder.
I've also noticed the second (IO) ACE uses something called "Generic
Rights", set in the Access Mask. This isn't clear in Vista's icacls.exe,
or in the GUI. I don't think icacls.exe can display SDDL, which is
annoying, but you if you use the /save option you can get SDDL in a
file, and then you'll see the glorious detail:
D:AI
(A;OICI;0x1301bf;;;S-1-5-21-757889776-154207171-3172746879-1001)
(A;ID;FA;;;BA)
(A;OICIIOID;GA;;;BA)
(A;ID;FA;;;SY)
(A;OICIIOID;GA;;;SY)
(A;ID;0x1301bf;;;AU)
(A;OICIIOID;SDGXGWGR;;;AU)
(A;ID;0x1200a9;;;BU)
(A;OICIIOID;GXGR;;;BU)
My final question, is that I'm trying to combine the file access flags
to give me the "change" or "modify" right. From the SDDL above, I'd say
I'm looking for 0x1301bf, but which flags to combine?
As I understand it, these flags are defined in winnt.h, so for C++ I'd
include winnt.h, but I'm interested to know if there are any typelibs
that can be used with COM automation that define these constants.
Thanks for the help with this.
Jialiang Ge [MSFT]
> My observation is that adding a new ACE to the DACL using the GUI does not
> give the same result as the Microsoft Format.exe defaults.
>
> My question is "which method is best"?
I think it depends on your specific use of DACL. Having two ACEs allows us
to separate the security of the current dir from the inheritance. If your
business environment does not require the separation, we can use one ACE
entry. The default DACL setting configured by Format.exe is to solve the
problem of "Denise Smith and Brian in Windows XP".
> I've also noticed the second (IO) ACE uses something called "Generic
> Rights", set in the Access Mask. This isn't clear in Vista's icacls.exe,
> or in the GUI. I don't think icacls.exe can display SDDL, which is
> annoying, but you if you use the /save option you can get SDDL in a file,
> and then you'll see the glorious detail:
I understand your concerns. Another way to output the results in standard
Security Descriptor Definition Language (SDDL) is to use cacls with the /s
switch. However, cacls is a legacy command-line routine for investigating
and setting ACLs and is being replaced by icacls (though not very
thoroughly). I will convey your concerns to the owner of the tool, and
hopefully, it can be improved soon.
> D:AI
> (A;OICI;0x1301bf;;;S-1-5-21-757889776-154207171-3172746879-1001)
> (A;ID;FA;;;BA)
> (A;OICIIOID;GA;;;BA)
> (A;ID;FA;;;SY)
> (A;OICIIOID;GA;;;SY)
> (A;ID;0x1301bf;;;AU)
> (A;OICIIOID;SDGXGWGR;;;AU)
> (A;ID;0x1200a9;;;BU)
> (A;OICIIOID;GXGR;;;BU)
>
> My final question, is that I'm trying to combine the file access flags to
> give me the "change" or "modify" right. From the SDDL above, I'd say I'm
> looking for 0x1301bf, but which flags to combine?
0x1301bf is a combination of Read, Write, Append, ReadEA, WriteEA, Execute,
ReadAttr, WriteAttr, Del, RCtl, and Sync.
Read: 0x0001 (FILE_READ_DATA)
Write: 0x0002 (FILE_WRITE_DATA)
Append: 0x0004 (FILE_APPEND_DATA)
ReadEA: 0x0008 (FILE_READ_EA)
WriteEA: 0x0010 (FILE_WRITE_EA)
Execute: 0x0020 (FILE_EXECUTE)
ReadAttr: 0x0080 (FILE_READ_ATTRIBUTES)
WriteAttr: 0x0100 (FILE_WRITE_ATTRIBUTES)
Del: 0x00010000L (DELETE)
RCtl: 0x00020000L (READ_CONTROL)
Sync: 0x00100000L (SYNCHRONIZE)
The point is mentioned (though not very explicitly) in the article:
http://msdn.microsoft.com/en-us/magazine/cc982153.aspx
<quote>
System and admin are granted Read, Write, Append, ReadEA, WriteEA, Execute,
ReadAttr, WriteAttr, Del, RCtl, and Sync, = SDGRGWGX on C:\Windows.
</quote>
> As I understand it, these flags are defined in winnt.h, so for C++ I'd
> include winnt.h, but I'm interested to know if there are any typelibs that
> can be used with COM automation that define these constants.
I do not find a built-in COM component exposing these consts. I think you
would need to include <winnt.h>
> Thanks for the help with this.
It's surely my pleasure to answer your confusions.
Have a nice week!
Gerry Hickman
>> My question is "which method is best"?
>
> I think it depends on your specific use of DACL. Having two ACEs allows us
> to separate the security of the current dir from the inheritance. If your
> business environment does not require the separation, we can use one ACE
> entry. The default DACL setting configured by Format.exe is to solve the
> problem of "Denise Smith and Brian in Windows XP".
OK, I notice it's similar on Windows 7 too. My view is that XP was
broken, Vista and Windows 7 are fixed for home users, but Windows
Servers have more simplified (and arguably better) default layout.
> I understand your concerns. Another way to output the results in standard
> Security Descriptor Definition Language (SDDL) is to use cacls with the /s
> switch. However, cacls is a legacy command-line routine for investigating
> and setting ACLs and is being replaced by icacls (though not very
> thoroughly). I will convey your concerns to the owner of the tool, and
> hopefully, it can be improved soon.
OK, thanks. As you say, cacls is legacy, so I'd like to see the switch
added to icacls.exe
> 0x1301bf is a combination of Read, Write, Append, ReadEA, WriteEA, Execute,
> ReadAttr, WriteAttr, Del, RCtl, and Sync.
>
> Read: 0x0001 (FILE_READ_DATA)
> Write: 0x0002 (FILE_WRITE_DATA)
> Append: 0x0004 (FILE_APPEND_DATA)
> ReadEA: 0x0008 (FILE_READ_EA)
> WriteEA: 0x0010 (FILE_WRITE_EA)
> Execute: 0x0020 (FILE_EXECUTE)
> ReadAttr: 0x0080 (FILE_READ_ATTRIBUTES)
> WriteAttr: 0x0100 (FILE_WRITE_ATTRIBUTES)
> Del: 0x00010000L (DELETE)
> RCtl: 0x00020000L (READ_CONTROL)
> Sync: 0x00100000L (SYNCHRONIZE)
Perfect! Thanks.
> I do not find a built-in COM component exposing these consts. I think you
> would need to include <winnt.h>
OK, that's my finding also.
Gerry Hickman
My program is now able to report all details of Security Descriptors set on
NTFS FileSystem directories. BUT I've run into a problem I don't understand.
Each Security Descriptor has a set of control flags that determine things
like inheritance from the parent. There's a flag called
SE_DACL_AUTO_INHERITED
From reading the SDK, my understanding is that this flag did not exist on
NT4, but is set by default on Server 2003/2008/XP/Vista, such that if you
create a sub-folder it will inherit permissions from above. BUT when I look
at the bit flags on the Security Descriptor, I see
0x8004 (SE_SELF_RELATIVE | SE_DACL_PRESENT)
The 0x0400 flag is not set and SDDL doesn't show any inheritance. If I go
into Windows Explorer, untick the inheritance box and then re-tick the
inheritance box, the bit flags on the folder then become 0x8404 and the SDDL
shows AI.
I ran my tests on the D: drives of Windows 2003 server and Vista, which were
created with FORMAT.EXE
If I look at the C drive on the Vista machine, which was created by the o/s
installer, the flags on the folders are set to 0x8404.
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:zw5gmDhS...@TK2MSFTNGHUB02.phx.gbl...
Jialiang Ge [MSFT]
I have reproduced the problem in your description with the code:
DWORD dwRes = 0;
PACL pOldDACL = NULL;
PSECURITY_DESCRIPTOR pSD = NULL;
LPWSTR str = L"D:\\Test\\ ";
dwRes = GetNamedSecurityInfo(str, SE_FILE_OBJECT,
DACL_SECURITY_INFORMATION,
NULL, NULL, &pOldDACL, NULL, &pSD);
if (ERROR_SUCCESS == dwRes) {
SECURITY_DESCRIPTOR_CONTROL ctrl;
DWORD rev;
GetSecurityDescriptorControl(pSD, &ctrl, &rev);
printf("%X", ctrl);
}
The first run prints 0x8004 for D:\Test. After I uncheck&reset the
inheritance flag in Windows Explorer, the run prints 0x8404.
This looks like a product issue. I queried the problem in the product
database, and found some entries saying that
SE_DACL_AUTO_INHERITED/SE_SACL_AUTO_INHERITED should be set on the root of
a drive and be added to the default format template of format.exe. I am
going to ask the product group for more information about its status.
Gerry, may I know the business impact of this issue on your environment,
and your expectation of the result?
Thanks
Jialiang Ge (jia...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Gerry Hickman
Thank you for confirmation. The business impact is serious because it
relates to the correct setting of flags on all current and future NTFS file
systems.
I need to know why
SE_DACL_AUTO_INHERITED/SE_SACL_AUTO_INHERITED
flags are not set by default on a newly formatted partition, but most
important, I need to know how/why inheritance seems to be working without
it??
If I create a new folder, it appears to inherit the permissions from it's
parent, and the GUI indicates this also, but the flag in not set??
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:YPgiHSC...@TK2MSFTNGHUB02.phx.gbl...
Gerry Hickman
I now believe the two issues discussed in this thread are related. Earlier
we discussed how default folder permissions created by FORMAT.EXE consist of
two ACEs per group - one to set the explicit ACE, and one to control the
inheritance of child objects. We agreed the GUI does not show this, instead
it only shows one ACE with inheritance. icacls shows the two ACEs, but shows
ACE's on child folders with the (I) flag set.
BUT
Switching to cacls.exe and using the SDDL option, I get different readings
and the readings agree with my program. The readings appear to be saying
auto-inheritance is NOT enabled on this partition, and the "inherited" ACEs
are not really inherited! e.g. create a structure:
d:\
test
test
test
For each folder, view the security in the advanced GUI, then view the icacls
output, then view the cacls SDDL. I see three different things.
The crazy thing is that if I then use the GUI to add an ACE to d:\test\test,
it suddenly turns on auto-inheritance, and all the child ACEs now correctly
show the (I) flag.
It needs further testing, but my initial finding is that the Windows GUI and
icacls.exe are NOT showing accurate information. My other question remains;
why is auto-inheritance not enabled by default for new NTFS partitions.
"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message
news:uK39z3EX...@TK2MSFTNGP05.phx.gbl...
Gerry Hickman
I have created a simple batch file to demonstrate the problem. Note that
the output from icacls does not agree with the output from cacls.
@echo off
REM demonstrate Windows NTFS FileSystem auto-inheritance
REM icacls.exe and GUI do not agree with cacls.exe
if not exist "d:\" goto err1
if exist "d:\test" goto err2
md d:\test
md d:\test\test
md d:\test\test\test
icacls d:\test\test
echo.
cacls d:\test\test
goto end
:err1
echo "No D Drive Found!"
goto end
:err2
echo "d:\test already exists!"
goto end
:end
Jialiang Ge [MSFT]
I'm still waiting for the product group's response for this product issue.
Let me try to answer some of your follow-up questions:
======================================
1. Why is the output of cacls different from icalcs?
ICACLS is an upgrade of the CACLS tool. Running your bat file outputs these:
Icacls:
d:\test\test BUILTIN\Administrators:(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
etc.
Cacls:
d:\test\test BUILTIN\Administrators:(OI)(CI)F
BUILTIN\Administrators:F
You may wonder why the output of Cacls for Administrators differs from that
of Icacls in that Icacls has a flag (I) in
BUILTIN\Administrators:(I)(OI)(CI)(F):
(I) is a flag new in Icacls. It means that the ACE entry is inherited from
its parent. Cacls does not have this flag defined. By no means could we see
which ACEs are inherited from the parent in the output of Cacls. In other
words, Icalcs is providing us with more information than Cacls.
======================================
2. Why is the output of icacls different from Windows Explorer GUI?
The ACE list outputted by ICACLS always equals to the output of Windows
Explorer GUI (did you see any differences?). Our debate is focusing on the
option "Allow inheritable permissions from the parent to propagate to this
object and all child objects." in Windows Explorer GUI. The option
corresponds to the SE_DACL_AUTO_INHERITED flag in the security description
(i.e. dacl_flags in SD String Format
D:dacl_flags(string_ace1)(string_ace2)... (string_acen)
http://msdn.microsoft.com/en-us/library/aa379570(VS.85).aspx). As I said in
the last reply, this is a known product issue of NTFS. I am asking the
product group for more information, and will report back as soon as
possible.
=====================================
3. Why are the SDDL outputs from CACLS different after we reset the
permission propagation?
Test:
Step1. Create a folder d:\test\test.
Step2. Output the folder's SDDL using CACLS:
d:\test\test
"D:(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;;FA;;;BA)(A;OICIIO;GA;;;CO)(A
;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CI;DC;;;BU)"
Step3. Reset the permission propagation of D:\Test\Test in Windows Explorer
GUI.
Step4. Output the folder's SDDL using CACLS again:
d:\test\test
"D:AI(A;;FA;;;BA)(A;OICIID;FA;;;BA)(A;OICIID;FA;;;SY)(A;OICIIOID;GA
;;;CO)(A;OICIID;0x1200a9;;;BU)(A;CIID;LC;;;BU)(A;CIID;DC;;;BU)"
From the above test, we can see that, before the reset:
D:(A;;FA;;;BA)(A;OICI;FA;;;BA)
After the reset:
D:AI(A;;FA;;;BA)(A;OICIID;FA;;;BA)
The difference are:
A. the addition of AI.
AI means that the SE_DACL_AUTO_INHERITED flag is set.
http://msdn.microsoft.com/en-us/library/aa379570(VS.85).aspx.
B. the addition of ID in (A;OICIID;FA;;;BA).
ID means that it's an inherited (ACE INHERITED_ACE)
http://msdn.microsoft.com/en-us/library/aa374928(VS.85).aspx
The differences are still caused by the above-mentioned product issue. The
default DACL setting (before reset) is not correct. Resetting the
propagation fixes the DACL setting by adding the AI and ID flags.
=====================================
4. If the default DACL setting is not correct, why is the inheritance still
working fine?
This is the question that I'm asking the product group. I will report back
when I get the answer.
5. Why are SE_DACL_AUTO_INHERITED/SE_SACL_AUTO_INHERITED flags not set by
default on a newly formatted partition.
This is the known product issue mentioned above.
Regards,
Gerry Hickman
Thank you, but something looks wrong in your reply. In the first part of
your reply you say that cacls.exe is not able to show us the INHERITED_ACE
flag (0x10), but lower down you say it can, and that it displays it as ID. I
have inserted comments in your text below.
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:TXOpEApX...@TK2MSFTNGHUB02.phx.gbl...
> BUILTIN\Administrators:(I)(OI)(CI)(F):
>
> (I) is a flag new in Icacls. It means that the ACE entry is inherited from
> its parent. Cacls does not have this flag defined. By no means could we
> see
> which ACEs are inherited from the parent in the output of Cacls. In other
> words, Icalcs is providing us with more information than Cacls.
Above you say cacls.exe is NOT able to show us the INHERITED_ACE flag.
> Step4. Output the folder's SDDL using CACLS again:
> After the reset:
> D:AI(A;;FA;;;BA)(A;OICIID;FA;;;BA)
> The difference are:
> B. the addition of ID in (A;OICIID;FA;;;BA).
> ID means that it's an inherited (ACE INHERITED_ACE)
> http://msdn.microsoft.com/en-us/library/aa374928(VS.85).aspx
Above you say cacls.exe IS able to show us the INHERITED_ACE flag.
I am sorry if I have misunderstood something in your reply. My understanding
is that cacls.exe CAN show us the INHERITED_ACE flag.
Jialiang Ge [MSFT]
It was my fault. The wording was not clear to express my meaning.
Cacls has different forms of output:
Cacls d:\test\
This lists the basic DACL of the file, and it does not display ACE
INHERITED_ACE, even after we reset "inheritance propagation", according to
our test result. However, the new tool, icacls, can display INHERITED_ACE
rightly.
Cacls d:\test\ /S
This outputs the SDDL of the file, and it can display the ID flag after we
reset "inheritance propagation".
The first part in my last reply refers to Cacls d:\test\. You are right. I
should have not said "by no means could we see which ACEs are inherited
from the parent in the output of Cacls.". The SDDL output of Cacls can tell
us the INHERITED_ACE info. I should have made my meaning clearer.
For the fourth question "If the default DACL setting is not correct, why is
the inheritance still working fine?", I'm still waiting for the product
group's comments. If this issue is indeed very urgent, you may consider
creating a support incident in our Customer Service & Support department
(http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx). Because it
is a known issue of our product, the support incident will be free of
charge.
Gerry Hickman
Dear Jialiang Ge,
Thank you for the update. I think the confusion is because cacls.exe works
differently on Vista than on Windows Server 2003? If I use cacls.exe on
Vista, I can see inherited aces marked as (ID) even in "normal" output. On
Windows Server 2003, I do not see the ID flag in normal output.
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:1nmHNiYY...@TK2MSFTNGHUB02.phx.gbl...
Gerry Hickman
Could you try running my BAT file on a Vista workstation with a D drive.
When I run it, the results I see are unexpected.
d:\test\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
Successfully processed 1 files; Failed processing 0 files
d:\test\test BUILTIN\Administrators:F
BUILTIN\Administrators:(OI)(CI)(IO)F
NT AUTHORITY\SYSTEM:F
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
NT AUTHORITY\Authenticated Users:C
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)C
BUILTIN\Users:R
BUILTIN\Users:(OI)(CI)(IO)(special access:)
GENERIC_READ
GENERIC_EXECUTE
Note, there is no (ID) flags in the cacls.exe output, but there are (I)
flags in the icacls.exe output. Why?
Now "reset inheritance propogation" for d:\test\test (e.g. untick and then
re-tick the box in the GUI), then run
cacls.exe d:\test\test
The output says:
d:\test\test BUILTIN\Administrators:(ID)F
BUILTIN\Administrators:(OI)(CI)(IO)(ID)F
NT AUTHORITY\SYSTEM:(ID)F
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(ID)F
NT AUTHORITY\Authenticated Users:(ID)C
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(ID)C
BUILTIN\Users:(ID)R
BUILTIN\Users:(OI)(CI)(IO)(ID)(special access:)
GENERIC_READ
GENERIC_EXECUTE
Note the (ID) flags are now shown.
The important part of this test is the first output from icacls and cacls,
they do not agree...
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:1nmHNiYY...@TK2MSFTNGHUB02.phx.gbl...
Jialiang Ge [MSFT]
Thank you. I reproduce the problem with your demo. The product versions of
cacls in my Windows Vista and Windows Server 2003 are different.
Cacls (Vista): 6.0.6000.16386;
Cacls (Win2003): 5.2.3790.3959.
Cacls was upgraded. The upgrade might fix the problem that ID is not
displayed in Cacls of Windows 2003, and the output of Cacls in Windows
Vista conforms to the SDDL output, i.e. ID is added after we manually reset
the inheritance. Therefore, the major concern in this case is still the
question "If the default DACL setting is not correct, why is the
inheritance still working fine?". I'm still waiting for the product
Gerry Hickman
Thank you for the update.
I think something very strange is happening here! The output for Vista's
cacls.exe agrees with the flags in my program which indicate the flag
INHERITED_ACE is not set as default by FORMAT.EXE for new NTFS partitions on
Windows 2003/2008 and Vista. This is strange, but it's only a small part of
the problem. An other question is why sub-folder inheritance seems to work
without this flag, but...
The BIG question is why does the GUI and the ICACLS.EXE command line tool
show this flag as being set???
I would accept the GUI may be wrong, but surely ICACLS.EXE can't be wrong
too??
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:puUpPi%23YJH...@TK2MSFTNGHUB02.phx.gbl...
Jialiang Ge [MSFT]
I completely understand the questions, and I'm curious about the answer for
them too.
- Why does sub-folder inheritance seem to work without the flag
SE_DACL_AUTO_INHERITED?
- Why does the GUI and the ICACLS.EXE command line tool show this flag as
being set?
I have been trying to consult the NTFS and the security product groups,
but no valuable information is received yet. I understand that this issue
is very important to you, and I sincerely want to help you. I'm going to
strike the product group again today. On your side, may I suggest creating
a support incident in our Customer Service & Support department
(http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx)? Because it
is a known issue of our product, the support incident will be free of
charge. In this way, we may be able to find the answer for the questions
more efficiently.
Best Regards,
Gerry Hickman
My post of 05-01-2009 was not correct.
The flag INHERITED_ACE is part of the ACE_HEADER structure and relates to a
specific ACE. The flag SE_DACL_AUTO_INHERITED is part of the
SECURITY_DESCRIPTOR_CONTROL flags set on the SD.
A) The discussion about FORMAT.EXE relates to SE_DACL_AUTO_INHERITED not
being set by default.
B) The discussion about the output from CACLS.EXE and ICACLS.EXE relates to
the INHERITED_ACE flag being mis-reported.
C) The discussion about the GUI relates to both flags.
I also notice the PSDK talks about SE_DACL_AUTO_INHERITED in the context of
applying inheritance to _existing_ child objects, whereas my original
question was talking about creating _new_ child objects.
I also noticed the text in the CreateDirectory() API function.
http://msdn.microsoft.com/en-us/library/aa363855(VS.85).aspx
Note these two lines of text:
"The ACLs in the default security descriptor for a directory are inherited
from its parent directory."
"For backward compatibility purposes, CreateDirectory does not apply Windows
2000 inheritance rules when you specify a security descriptor in
lpSecurityAttributes. To support inheritance on current versions of Windows,
functions that query the security descriptor of this object may
heuristically determine and report that inheritance is in effect."
I think I need to research this more carefully and then post a new thread.
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:SAlaZO8b...@TK2MSFTNGHUB02.phx.gbl...
Jialiang Ge [MSFT]
to research this more carefully too. Please feel free to create a new
thread and we can continue the discussion.
Gerry Hickman
I have a small update on this.
I have saved the SDDL output from CACLS, ICACLS and WMI on Vista. The target
folder was the same in each case d:\TestFolder.
Note the output relating to inheritance is different!
Note also that CACLS and ICACLS do not appear to list the owner and primary
group in their SDDL?
Vista ICACLS d:\TestFolder
D:
(A;ID;FA;;;BA)
(A;OICIIOID;GA;;;BA)
(A;ID;FA;;;SY)
(A;OICIIOID;GA;;;SY)
(A;ID;0x1301bf;;;AU)
(A;OICIIOID;SDGXGWGR;;;AU)
(A;ID;0x1200a9;;;BU)
(A;OICIIOID;GXGR;;;BU)
Vista CACLS d:\TestFolder
D:
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;;0x1301bf;;;AU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;0x1200a9;;;BU)
(A;OICIIO;GXGR;;;BU)
WMI with SDDL helper classes d:\TestFolder
O:BA
G:DU
D:
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;;0x1301bf;;;AU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;0x1200a9;;;BU)
(A;OICIIO;GXGR;;;BU)
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:MTjpRoWc...@TK2MSFTNGHUB02.phx.gbl...
Gerry Hickman
I have an update on this.
As you noticed below, the SecurityDescriptor.ControlFlags are set to 0x8004
for folders on a newly created Windows partition. We also notice this
doesn't agree with the tick box in the GUI. We also notice ticking and
un-ticking the box changes the flag to 0x8404.
BUT
I also notice that adding any user with the GUI will also cause this flag to
jump from 0x8004 to 0x8404! After the flag changes, the o/s appears to
update all AceFlags for all ACEs residing below this folder, changing them
to become INHERITED_ACE.
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:YPgiHSC...@TK2MSFTNGHUB02.phx.gbl...
Jialiang Ge [MSFT]
If I understand it rightly, your finding on Jan 08 can explain ICACLS's ID
output:
<quote>
"For backward compatibility purposes, CreateDirectory does not apply
Windows
2000 inheritance rules when you specify a security descriptor in
lpSecurityAttributes. To support inheritance on current versions of
Windows,
functions that query the security descriptor of this object may
heuristically determine and report that inheritance is in effect."
</quote>
It appears that ICACLS heuristically determine and report that inheritance
is in effect for backward compatibility purposes.
>CACLS and ICACLS do not appear to list the owner and primary group in
>their SDDL?
I think so.
I'm consulting PG about the 0x8004 -> 0x8404 transition issue. Am I right
that your underlying purpose is to determine ID with WMI (without ICACLS)?
Gerry Hickman
> It appears that ICACLS heuristically determine and report that inheritance
> is in effect for backward compatibility purposes.
Here are my concerns:
1. ICACLS on Vista is the most recent tool to manage ACLs, but I don't
believe it shows accurate information.
2. I do not believe the Vista GUI is showing accurate information.
3. The default ControlFlags set for NTFS folders with the latest FORMAT.EXE
are 0x8004, not 0x8404.
4. ICACLS is not able to show SDDL on screen, nor does it list the owner and
primary group in it's SDDL.
5. SUBINACL is not certified for Vista/2008?
6. Win32_SecurityDescriptorHelper.Win32SDToSDDL() doesn't show INHERITED_ACE
flags?
Overall, the concern is that creating programmatic solutions is much more
difficult when the built-in o/s tools don't work as expected!
Thanks.