| Author | Messages | |
bwatson
Posts:0
 | | 06/02/2007 1:26 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
So I have completed our major data migration of our company
home folders from one Netapp filer to a new one. The root folder that
contained the home folders had very simple permissions set of Domain Admins –
Full Control and a custom security group called Filer Admins – Full Control.
All I needed to do in the end was give each user modify rights over their own
home folder. So I ran this batch script to do so…
for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G DOMAIN\%%f:C
Worked beautifully, set the proper user on the correct
folder with modify rights as it should be while maintaining the other
permissions they were inheriting from the parent folder as I intended. However…
upon checking the home folders to ensure they were set properly, each folder
would give me this error message each time I would click on the security tab...
(I edited out the name of the folder in the error
message)
Upon clicking OK, the security permissions would indeed be
set properly and the folders/files within the home folder were inheriting
permissions properly. So I checked another folder, same error, same
result after clicking OK. So I checked yet another home folder, and
before I checked the security permissions, I looked at the permissions within
one of the home folders. Sure enough, the existing files/folders were not
yet inheriting any sort of permissions related to my batch script, they were
only inheriting permissions from the root folder (Domain Admins – Full Control
and Filer Admins – Full Control). Oddly enough however, if I
created any new test files/folders, these new files/folders DO inherit the
proper permissions including the modify rights for the individual user.
However the existing files/folders would not be fixed until I went to the root
home folder, checked the security tab, and clicked OK.
Has anyone seen this before? And does anyone have any
idea on what I can look at to script a solution for all the home folders?
Otherwise I’m looking at a very long and very manual process.
Thanks,
~Ben | | | |
| bwatson
Posts:0
| | 06/02/2007 1:36 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Actually, now that I look at the
permissions with xcacls, the permissions are slightly different between a
folder that has not yet been “fixed” through the error message, and
one that has been “fixed”. Folder name = User name for our
home folder structure.
Fixed Folder…
T:\xcacls fixed
T:\fixed DOMAIN\fixed:(OI)(CI)C
DOMAIN\Domain Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
Broken Folder…
T:\xcacls broken
T:\broken DOMAIN\Domain
Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
DOMAIN\broken:(OI)(IO)C
DOMAIN\broken:(CI)C
Basically, after I try and check
the permissions through the security tab, I get that error message, I click OK,
and magically the permissions change from Broken to Fixed from my example
above.
Hopefully someone might be able
to explain the differences between these two folder permissions and how best to
tackle it.
Thanks,
~Ben
From: WATSON, BEN
Sent: Friday, June 01, 2007 10:27 PM
To: 'ActiveDir@mail.activedir.org'
Subject: [OT] Have you seen this ACL error before?
So I have completed our major data migration of our company
home folders from one Netapp filer to a new one. The root folder that
contained the home folders had very simple permissions set of Domain Admins
– Full Control and a custom security group called Filer Admins –
Full Control. All I needed to do in the end was give each user modify
rights over their own home folder. So I ran this batch script to do
so…
for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G
DOMAIN\%%f:C
Worked beautifully, set the proper user on the correct
folder with modify rights as it should be while maintaining the other
permissions they were inheriting from the parent folder as I intended.
However… upon checking the home folders to ensure they were set
properly, each folder would give me this error message each time I would click
on the security tab...
(I edited out the name of the folder in the error
message)
Upon clicking OK, the security permissions would indeed be
set properly and the folders/files within the home folder were inheriting
permissions properly. So I checked another folder, same error, same
result after clicking OK. So I checked yet another home folder, and
before I checked the security permissions, I looked at the permissions within
one of the home folders. Sure enough, the existing files/folders were not
yet inheriting any sort of permissions related to my batch script, they were
only inheriting permissions from the root folder (Domain Admins – Full
Control and Filer Admins – Full Control). Oddly enough however, if
I created any new test files/folders, these new files/folders DO inherit the
proper permissions including the modify rights for the individual user.
However the existing files/folders would not be fixed until I went to the root
home folder, checked the security tab, and clicked OK.
Has anyone seen this before? And does anyone have any
idea on what I can look at to script a solution for all the home folders?
Otherwise I’m looking at a very long and very manual process.
Thanks,
~Ben | | | |
| listmail
Posts:822
| | 06/02/2007 2:11 AM |
| v\:* {
BEHAVIOR: url(#default#VML)
}
o\:* {
BEHAVIOR: url(#default#VML)
}
w\:* {
BEHAVIOR: url(#default#VML)
}
.shape {
BEHAVIOR: url(#default#VML)
}
@font-face {
font-family: Cambria Math;
}
@font-face {
font-family: Calibri;
}
@font-face {
font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"
}
LI.MsoNormal {
FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"
}
DIV.MsoNormal {
FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P.MsoAcetate {
FONT-SIZE: 8pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; mso-style-priority: 99; mso-style-link: "Balloon Text Char"
}
LI.MsoAcetate {
FONT-SIZE: 8pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; mso-style-priority: 99; mso-style-link: "Balloon Text Char"
}
DIV.MsoAcetate {
FONT-SIZE: 8pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; mso-style-priority: 99; mso-style-link: "Balloon Text Char"
}
SPAN.BalloonTextChar {
FONT-FAMILY: "Tahoma","sans-serif"; mso-style-priority: 99; mso-style-link: "Balloon Text"; mso-style-name: "Balloon Text Char"
}
SPAN.EmailStyle19 {
COLOR: windowtext; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle20 {
COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
page: Section1
}
There was a change in the ACL format in Windows 2000 which
allowed for what I call prioritized inheritance. I.E. Depending on where the ACE
was inherited from, the permission may or may not be able to be overrided. We
all know how a DENY overrides a GRANT, people are starting to grasp (at least in
the AD world) that an inherited DENY can be overridden by an explicit GRANT.
Some folks are now also starting to understand that a DENY inherited from level
1 can be overridden by an inherited GRANT inherited from level 1.2. I.E. The
"closer" the ACE is to the object, the more powerful the ACE in respect to
whether or not it will be effective on the object.
The thing is though that the low level ACL editor API will
let you write the ACLs in any old order you want and there is a fixed order in
which things should be written. The order of the ACEs should be
Assuming
L1
L2
L3
Object
----------------------------------------| Explicit Deny
ACEs for Object
|--------------------------------------------------------------------------------|
Explicit Grant ACEs for Object
|----------------------------------------========================================All
following ACEs are inherited on
Object========================================------------------------------------------|
Explicit Inheritable Deny ACEs for L3
|------------------------------------------------------------------------------------|
Explicit Inheritable Grant ACEs for
L3|------------------------------------------------------------------------------------|
Explicit Inheritable Deny ACEs for L2
|------------------------------------------------------------------------------------|
Explicit Inheritable Grant ACEs for
L2|------------------------------------------------------------------------------------|
Explicit Inheritable Deny ACEs for L1 |
------------------------------------------------------------------------------------|
Explicit Inheritable Grant ACEs for
L1|------------------------------------------
What you see on the folder prior to XCACLS is
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl
f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards
(joe@joeware.net)
May 2007
Obj Name: f:\temp\test\test2 SD Size :
132 SD CRC : 0xbd2cf47a Owner
: S-1-5-32-544 OwnerSID : S-1-5-32-544
Group :
S-1-5-21-1862701446-4008382571-2198042679-513 GroupSID :
S-1-5-21-1862701446-4008382571-2198042679-513DACL Prot'd:
FALSE DACL Size: 68 DACL CRC : 0xa755d9d2 DACL
AceCount: 2 ACEs 001)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-32-544
002)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-21-3260367365-2193829723-2103023026-1016
The command completed successfully.
Then after the xcacls command you see
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl
f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards
(joe@joeware.net)
May 2007
Obj Name: f:\temp\test\test2 SD Size :
264 SD CRC : 0x6c407ecc Owner
: S-1-5-32-544 OwnerSID : S-1-5-32-544
Group :
S-1-5-21-1862701446-4008382571-2198042679-513 GroupSID :
S-1-5-21-1862701446-4008382571-2198042679-513 DACL Prot'd:
FALSE DACL Size: 200 DACL CRC : 0x52d1293f DACL
AceCount: 4 ACEs 001)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-32-544
002)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-21-3260367365-2193829723-2103023026-1016
003)
ACCESS_ALLOWED;INHERIT_ONLY|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2198042679-21229
004)
ACCESS_ALLOWED;CONTAINER_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2198042679-21229
The command completed
successfully.
and then after Explorer reorders the ACEs (and removes one
redundant ACE)
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl
f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards
(joe@joeware.net)
May 2007
Obj Name: f:\temp\test\test2 SD Size :
168 SD CRC : 0x9e5883c1 Owner
: S-1-5-32-544 OwnerSID : S-1-5-32-544
Group :
S-1-5-21-1862701446-4008382571-2198042679-513 GroupSID :
S-1-5-21-1862701446-4008382571-2198042679-513 DACL Prot'd:
FALSE DACL Size: 104 DACL CRC : 0x7959a728 DACL
AceCount: 3 ACEs 001)
ACCESS_ALLOWED;CONTAINER_INHERIT|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2198042679-21229
002)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-32-544
003)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-21-3260367365-2193829723-2103023026-1016
The command completed successfully.
Notice the difference in the ordering in all of
those?
The issue comes down to xcacls not being updated after the
change in how ACLs were set up to properly reflect the inheritance
model.
There is another place where ACEs are purposely misordered
but it is in Active Directory and they came up with a fancy name for it...
Non-canonical ordering of ACEs. i.e. Non-Standard Ordering of ACEs. This is for
hidden DL membership for Exchange. They toss a couple of explicit GRANT RP ACEs
for the member attribute for Exchange Servers and Account Operators in front of
a DENY RP for the member attribute for Everyone. This still breaks ACL tools
that aren't aware that Exchange did this. Or actually what it does is if the ACL
of that group is touched by the tool that doesn't understand, the ACL can be
reordered which means the membership is suddenly visible... ADUC had a problem
with that for a while if you recall as well. I caught when I was first
investigating how hidden membership was handled as I needed to make sure it was
secure and I dumped the RAW ACL and was like WTF.... Of course I didn't depend
on it, instead I buried the groups I needed protected under a protected OU.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON,
BENSent: Saturday, June 02, 2007 1:36 AMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] [OT] Have you
seen this ACL error before?
Actually, now that I look at the
permissions with xcacls, the permissions are slightly different between a folder
that has not yet been “fixed” through the error message, and one that has been
“fixed”. Folder name = User name for our home folder
structure.
Fixed
Folder…
T:\xcacls
fixed
T:\fixed
DOMAIN\fixed:(OI)(CI)C
DOMAIN\Domain
Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
Broken
Folder…
T:\xcacls
broken
T:\broken DOMAIN\Domain
Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
DOMAIN\broken:(OI)(IO)C
DOMAIN\broken:(CI)C
Basically, after I try and check
the permissions through the security tab, I get that error message, I click OK,
and magically the permissions change from Broken to Fixed from my example
above.
Hopefully someone might be able
to explain the differences between these two folder permissions and how best to
tackle it.
Thanks,
~Ben
From: WATSON, BEN
Sent: Friday, June 01, 2007 10:27 PMTo:
'ActiveDir@mail.activedir.org'Subject: [OT] Have you seen this ACL
error before?
So I have completed our major data migration of our company
home folders from one Netapp filer to a new one. The root folder that
contained the home folders had very simple permissions set of Domain Admins –
Full Control and a custom security group called Filer Admins – Full
Control. All I needed to do in the end was give each user modify rights
over their own home folder. So I ran this batch script to do
so…
for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G
DOMAIN\%%f:C
Worked beautifully, set the proper user on the correct folder
with modify rights as it should be while maintaining the other permissions they
were inheriting from the parent folder as I intended. However… upon
checking the home folders to ensure they were set properly, each folder would
give me this error message each time I would click on the security
tab...
(I edited out the name of the folder in the error
message)
Upon clicking OK, the security permissions would indeed be
set properly and the folders/files within the home folder were inheriting
permissions properly. So I checked another folder, same error, same result
after clicking OK. So I checked yet another home folder, and before I
checked the security permissions, I looked at the permissions within one of the
home folders. Sure enough, the existing files/folders were not yet
inheriting any sort of permissions related to my batch script, they were only
inheriting permissions from the root folder (Domain Admins – Full Control and
Filer Admins – Full Control). Oddly enough however, if I created any new
test files/folders, these new files/folders DO inherit the proper permissions
including the modify rights for the individual user. However the existing
files/folders would not be fixed until I went to the root home folder, checked
the security tab, and clicked OK.
Has anyone seen this before? And does anyone have any
idea on what I can look at to script a solution for all the home folders?
Otherwise I’m looking at a very long and very manual process.
Thanks,
~Ben | | | |
| CrawfordS
Posts:128
| | 06/02/2007 4:32 AM |
| Now, that you mention it, I have seen that. I had forgotten about it, but that was one of the major reasons I used FileACL to set the perms.
It's apparently a known problem Windows 2000, not sure about 2003
http://support.microsoft.com/kb/822790
________________________________
From: ActiveDir-owner@mail.activedir.org on behalf of WATSON, BEN
Sent: Fri 6/1/2007 11:36 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
Actually, now that I look at the permissions with xcacls, the permissions are slightly different between a folder that has not yet been "fixed" through the error message, and one that has been "fixed". Folder name = User name for our home folder structure.
Fixed Folder...
T:\xcacls fixed
T:\fixed DOMAIN\fixed:(OI)(CI)C
DOMAIN\Domain Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
Broken Folder...
T:\xcacls broken
T:\broken DOMAIN\Domain Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
DOMAIN\broken:(OI)(IO)C
DOMAIN\broken:(CI)C
Basically, after I try and check the permissions through the security tab, I get that error message, I click OK, and magically the permissions change from Broken to Fixed from my example above.
Hopefully someone might be able to explain the differences between these two folder permissions and how best to tackle it.
Thanks,
~Ben
From: WATSON, BEN
Sent: Friday, June 01, 2007 10:27 PM
To: 'ActiveDir@mail.activedir.org'
Subject: [OT] Have you seen this ACL error before?
So I have completed our major data migration of our company home folders from one Netapp filer to a new one. The root folder that contained the home folders had very simple permissions set of Domain Admins - Full Control and a custom security group called Filer Admins - Full Control. All I needed to do in the end was give each user modify rights over their own home folder. So I ran this batch script to do so...
for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G DOMAIN\%%f:C
Worked beautifully, set the proper user on the correct folder with modify rights as it should be while maintaining the other permissions they were inheriting from the parent folder as I intended. However... upon checking the home folders to ensure they were set properly, each folder would give me this error message each time I would click on the security tab...
error.JPG
(I edited out the name of the folder in the error message)
Upon clicking OK, the security permissions would indeed be set properly and the folders/files within the home folder were inheriting permissions properly. So I checked another folder, same error, same result after clicking OK. So I checked yet another home folder, and before I checked the security permissions, I looked at the permissions within one of the home folders. Sure enough, the existing files/folders were not yet inheriting any sort of permissions related to my batch script, they were only inheriting permissions from the root folder (Domain Admins - Full Control and Filer Admins - Full Control). Oddly enough however, if I created any new test files/folders, these new files/folders DO inherit the proper permissions including the modify rights for the individual user. However the existing files/folders would not be fixed until I went to the root home folder, checked the security tab, and clicked OK.
Has anyone seen this before? And does anyone have any idea on what I can look at to script a solution for all the home folders? Otherwise I'm looking at a very long and very manual process.
Thanks,
~Ben | | | |
| listmail
Posts:822
| | 06/03/2007 2:23 AM |
| You could do something like
subinacl /file PATH /revoke=SECPRIN /grant=SECPRIN=C
Also fileacl or setacl could likely be used.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
Sent: Sunday, June 03, 2007 3:36 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
Excellent information Joe, that certainly helps me to understand better why
this happened and hopefully how to avoid it in the future.
Any thoughts on how to repair the ACLs through the CLI so I can script a
solution? Manually fixing each folder through Explorer isn't a solution I
look forward to. :(
Thanks,
~Ben
_____
From: ActiveDir-owner@mail.activedir.org on behalf of joe
Sent: Sat 6/2/2007 11:11 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
There was a change in the ACL format in Windows 2000 which allowed for what
I call prioritized inheritance. I.E. Depending on where the ACE was
inherited from, the permission may or may not be able to be overrided. We
all know how a DENY overrides a GRANT, people are starting to grasp (at
least in the AD world) that an inherited DENY can be overridden by an
explicit GRANT. Some folks are now also starting to understand that a DENY
inherited from level 1 can be overridden by an inherited GRANT inherited
from level 1.2. I.E. The "closer" the ACE is to the object, the more
powerful the ACE in respect to whether or not it will be effective on the
object.
The thing is though that the low level ACL editor API will let you write the
ACLs in any old order you want and there is a fixed order in which things
should be written. The order of the ACEs should be
Assuming
L1
L2
L3
Object
----------------------------------------
| Explicit Deny ACEs for Object |
----------------------------------------
----------------------------------------
| Explicit Grant ACEs for Object |
----------------------------------------
========================================
All following ACEs are inherited on Object
========================================
------------------------------------------
| Explicit Inheritable Deny ACEs for L3 |
------------------------------------------
------------------------------------------
| Explicit Inheritable Grant ACEs for L3|
------------------------------------------
------------------------------------------
| Explicit Inheritable Deny ACEs for L2 |
------------------------------------------
------------------------------------------
| Explicit Inheritable Grant ACEs for L2|
------------------------------------------
------------------------------------------
| Explicit Inheritable Deny ACEs for L1 |
------------------------------------------
------------------------------------------
| Explicit Inheritable Grant ACEs for L1|
------------------------------------------
What you see on the folder prior to XCACLS is
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards (
joe@joeware.net) May 2007
Obj Name: f:\temp\test\test2
SD Size : 132
SD CRC : 0xbd2cf47a
Owner : S-1-5-32-544
OwnerSID : S-1-5-32-544
Group : S-1-5-21-1862701446-4008382571-2198042679-513
GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
DACL Prot'd: FALSE
DACL Size: 68
DACL CRC : 0xa755d9d2
DACL AceCount: 2
ACEs
001)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
2-544
002)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
1-3260367365-2193829723-2103023026-1016
The command completed successfully.
Then after the xcacls command you see
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards (
joe@joeware.net) May 2007
Obj Name: f:\temp\test\test2
SD Size : 264
SD CRC : 0x6c407ecc
Owner : S-1-5-32-544
OwnerSID : S-1-5-32-544
Group : S-1-5-21-1862701446-4008382571-2198042679-513
GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
DACL Prot'd: FALSE
DACL Size: 200
DACL CRC : 0x52d1293f
DACL AceCount: 4
ACEs
001)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
2-544
002)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
1-3260367365-2193829723-2103023026-1016
003)
ACCESS_ALLOWED;INHERIT_ONLY|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-40
08382571-2198042679-21229
004)
ACCESS_ALLOWED;CONTAINER_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2
198042679-21229
The command completed successfully.
and then after Explorer reorders the ACEs (and removes one redundant ACE)
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards (
joe@joeware.net) May 2007
Obj Name: f:\temp\test\test2
SD Size : 168
SD CRC : 0x9e5883c1
Owner : S-1-5-32-544
OwnerSID : S-1-5-32-544
Group : S-1-5-21-1862701446-4008382571-2198042679-513
GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
DACL Prot'd: FALSE
DACL Size: 104
DACL CRC : 0x7959a728
DACL AceCount: 3
ACEs
001)
ACCESS_ALLOWED;CONTAINER_INHERIT|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-18627014
46-4008382571-2198042679-21229
002)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
2-544
003)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
1-3260367365-2193829723-2103023026-1016
The command completed successfully.
Notice the difference in the ordering in all of those?
The issue comes down to xcacls not being updated after the change in how
ACLs were set up to properly reflect the inheritance model.
There is another place where ACEs are purposely misordered but it is in
Active Directory and they came up with a fancy name for it... Non-canonical
ordering of ACEs. i.e. Non-Standard Ordering of ACEs. This is for hidden DL
membership for Exchange. They toss a couple of explicit GRANT RP ACEs for
the member attribute for Exchange Servers and Account Operators in front of
a DENY RP for the member attribute for Everyone. This still breaks ACL tools
that aren't aware that Exchange did this. Or actually what it does is if the
ACL of that group is touched by the tool that doesn't understand, the ACL
can be reordered which means the membership is suddenly visible... ADUC had
a problem with that for a while if you recall as well. I caught when I was
first investigating how hidden membership was handled as I needed to make
sure it was secure and I dumped the RAW ACL and was like WTF.... Of course I
didn't depend on it, instead I buried the groups I needed protected under a
protected OU.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
Sent: Saturday, June 02, 2007 1:36 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
Actually, now that I look at the permissions with xcacls, the permissions
are slightly different between a folder that has not yet been "fixed"
through the error message, and one that has been "fixed". Folder name =
User name for our home folder structure.
Fixed Folder...
T:\xcacls fixed
T:\fixed DOMAIN\fixed:(OI)(CI)C
DOMAIN\Domain Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
Broken Folder...
T:\xcacls broken
T:\broken DOMAIN\Domain Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
DOMAIN\broken:(OI)(IO)C
DOMAIN\broken:(CI)C
Basically, after I try and check the permissions through the security tab, I
get that error message, I click OK, and magically the permissions change
from Broken to Fixed from my example above.
Hopefully someone might be able to explain the differences between these two
folder permissions and how best to tackle it.
Thanks,
~Ben
From: WATSON, BEN
Sent: Friday, June 01, 2007 10:27 PM
To: 'ActiveDir@mail.activedir.org'
Subject: [OT] Have you seen this ACL error before?
So I have completed our major data migration of our company home folders
from one Netapp filer to a new one. The root folder that contained the home
folders had very simple permissions set of Domain Admins - Full Control and
a custom security group called Filer Admins - Full Control. All I needed to
do in the end was give each user modify rights over their own home folder.
So I ran this batch script to do so...
for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G DOMAIN\%%f:C
Worked beautifully, set the proper user on the correct folder with modify
rights as it should be while maintaining the other permissions they were
inheriting from the parent folder as I intended. However... upon checking
the home folders to ensure they were set properly, each folder would give me
this error message each time I would click on the security tab...
error.JPG
(I edited out the name of the folder in the error message)
Upon clicking OK, the security permissions would indeed be set properly and
the folders/files within the home folder were inheriting permissions
properly. So I checked another folder, same error, same result after
clicking OK. So I checked yet another home folder, and before I checked the
security permissions, I looked at the permissions within one of the home
folders. Sure enough, the existing files/folders were not yet inheriting
any sort of permissions related to my batch script, they were only
inheriting permissions from the root folder (Domain Admins - Full Control
and Filer Admins - Full Control). Oddly enough however, if I created any
new test files/folders, these new files/folders DO inherit the proper
permissions including the modify rights for the individual user. However
the existing files/folders would not be fixed until I went to the root home
folder, checked the security tab, and clicked OK.
Has anyone seen this before? And does anyone have any idea on what I can
look at to script a solution for all the home folders? Otherwise I'm
looking at a very long and very manual process.
Thanks,
~Ben | | | |
| bwatson
Posts:0
| | 06/03/2007 3:35 AM |
| Excellent information Joe, that certainly helps me to understand better why this happened and hopefully how to avoid it in the future.
Any thoughts on how to repair the ACLs through the CLI so I can script a solution? Manually fixing each folder through Explorer isn't a solution I look forward to. :(
Thanks,
~Ben
________________________________
From: ActiveDir-owner@mail.activedir.org on behalf of joe
Sent: Sat 6/2/2007 11:11 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
There was a change in the ACL format in Windows 2000 which allowed for what I call prioritized inheritance. I.E. Depending on where the ACE was inherited from, the permission may or may not be able to be overrided. We all know how a DENY overrides a GRANT, people are starting to grasp (at least in the AD world) that an inherited DENY can be overridden by an explicit GRANT. Some folks are now also starting to understand that a DENY inherited from level 1 can be overridden by an inherited GRANT inherited from level 1.2. I.E. The "closer" the ACE is to the object, the more powerful the ACE in respect to whether or not it will be effective on the object.
The thing is though that the low level ACL editor API will let you write the ACLs in any old order you want and there is a fixed order in which things should be written. The order of the ACEs should be
Assuming
L1
L2
L3
Object
----------------------------------------
| Explicit Deny ACEs for Object |
----------------------------------------
----------------------------------------
| Explicit Grant ACEs for Object |
----------------------------------------
========================================
All following ACEs are inherited on Object
========================================
------------------------------------------
| Explicit Inheritable Deny ACEs for L3 |
------------------------------------------
------------------------------------------
| Explicit Inheritable Grant ACEs for L3|
------------------------------------------
------------------------------------------
| Explicit Inheritable Deny ACEs for L2 |
------------------------------------------
------------------------------------------
| Explicit Inheritable Grant ACEs for L2|
------------------------------------------
------------------------------------------
| Explicit Inheritable Deny ACEs for L1 |
------------------------------------------
------------------------------------------
| Explicit Inheritable Grant ACEs for L1|
------------------------------------------
What you see on the folder prior to XCACLS is
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards (joe@joeware.net ) May 2007
Obj Name: f:\temp\test\test2
SD Size : 132
SD CRC : 0xbd2cf47a
Owner : S-1-5-32-544
OwnerSID : S-1-5-32-544
Group : S-1-5-21-1862701446-4008382571-2198042679-513
GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
DACL Prot'd: FALSE
DACL Size: 68
DACL CRC : 0xa755d9d2
DACL AceCount: 2
ACEs
001) ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-32-544
002) ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-21-3260367365-2193829723-2103023026-1016
The command completed successfully.
Then after the xcacls command you see
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards (joe@joeware.net ) May 2007
Obj Name: f:\temp\test\test2
SD Size : 264
SD CRC : 0x6c407ecc
Owner : S-1-5-32-544
OwnerSID : S-1-5-32-544
Group : S-1-5-21-1862701446-4008382571-2198042679-513
GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
DACL Prot'd: FALSE
DACL Size: 200
DACL CRC : 0x52d1293f
DACL AceCount: 4
ACEs
001) ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-32-544
002) ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-21-3260367365-2193829723-2103023026-1016
003) ACCESS_ALLOWED;INHERIT_ONLY|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2198042679-21229
004) ACCESS_ALLOWED;CONTAINER_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2198042679-21229
The command completed successfully.
and then after Explorer reorders the ACEs (and removes one redundant ACE)
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards (joe@joeware.net ) May 2007
Obj Name: f:\temp\test\test2
SD Size : 168
SD CRC : 0x9e5883c1
Owner : S-1-5-32-544
OwnerSID : S-1-5-32-544
Group : S-1-5-21-1862701446-4008382571-2198042679-513
GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
DACL Prot'd: FALSE
DACL Size: 104
DACL CRC : 0x7959a728
DACL AceCount: 3
ACEs
001) ACCESS_ALLOWED;CONTAINER_INHERIT|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2198042679-21229
002) ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-32-544
003) ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-21-3260367365-2193829723-2103023026-1016
The command completed successfully.
Notice the difference in the ordering in all of those?
The issue comes down to xcacls not being updated after the change in how ACLs were set up to properly reflect the inheritance model.
There is another place where ACEs are purposely misordered but it is in Active Directory and they came up with a fancy name for it... Non-canonical ordering of ACEs. i.e. Non-Standard Ordering of ACEs. This is for hidden DL membership for Exchange. They toss a couple of explicit GRANT RP ACEs for the member attribute for Exchange Servers and Account Operators in front of a DENY RP for the member attribute for Everyone. This still breaks ACL tools that aren't aware that Exchange did this. Or actually what it does is if the ACL of that group is touched by the tool that doesn't understand, the ACL can be reordered which means the membership is suddenly visible... ADUC had a problem with that for a while if you recall as well. I caught when I was first investigating how hidden membership was handled as I needed to make sure it was secure and I dumped the RAW ACL and was like WTF.... Of course I didn't depend on it, instead I buried the groups I needed protected under a protected OU.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
Sent: Saturday, June 02, 2007 1:36 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
Actually, now that I look at the permissions with xcacls, the permissions are slightly different between a folder that has not yet been "fixed" through the error message, and one that has been "fixed". Folder name = User name for our home folder structure.
Fixed Folder...
T:\xcacls fixed
T:\fixed DOMAIN\fixed:(OI)(CI)C
DOMAIN\Domain Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
Broken Folder...
T:\xcacls broken
T:\broken DOMAIN\Domain Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
DOMAIN\broken:(OI)(IO)C
DOMAIN\broken:(CI)C
Basically, after I try and check the permissions through the security tab, I get that error message, I click OK, and magically the permissions change from Broken to Fixed from my example above.
Hopefully someone might be able to explain the differences between these two folder permissions and how best to tackle it.
Thanks,
~Ben
From: WATSON, BEN
Sent: Friday, June 01, 2007 10:27 PM
To: 'ActiveDir@mail.activedir.org'
Subject: [OT] Have you seen this ACL error before?
So I have completed our major data migration of our company home folders from one Netapp filer to a new one. The root folder that contained the home folders had very simple permissions set of Domain Admins - Full Control and a custom security group called Filer Admins - Full Control. All I needed to do in the end was give each user modify rights over their own home folder. So I ran this batch script to do so...
for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G DOMAIN\%%f:C
Worked beautifully, set the proper user on the correct folder with modify rights as it should be while maintaining the other permissions they were inheriting from the parent folder as I intended. However... upon checking the home folders to ensure they were set properly, each folder would give me this error message each time I would click on the security tab...
error.JPG
(I edited out the name of the folder in the error message)
Upon clicking OK, the security permissions would indeed be set properly and the folders/files within the home folder were inheriting permissions properly. So I checked another folder, same error, same result after clicking OK. So I checked yet another home folder, and before I checked the security permissions, I looked at the permissions within one of the home folders. Sure enough, the existing files/folders were not yet inheriting any sort of permissions related to my batch script, they were only inheriting permissions from the root folder (Domain Admins - Full Control and Filer Admins - Full Control). Oddly enough however, if I created any new test files/folders, these new files/folders DO inherit the proper permissions including the modify rights for the individual user. However the existing files/folders would not be fixed until I went to the root home folder, checked the security tab, and clicked OK.
Has anyone seen this before? And does anyone have any idea on what I can look at to script a solution for all the home folders? Otherwise I'm looking at a very long and very manual process.
Thanks,
~Ben | | | |
| matheesha
Posts:34
| | 06/03/2007 3:57 AM |
| Erm... What are the chances of objacl been released to the public? ;-)
Cheers
M@
On 03/06/07, joe wrote:
> You could do something like
>
> subinacl /file PATH /revoke=SECPRIN /grant=SECPRIN=C
>
>
> Also fileacl or setacl could likely be used.
>
> joe
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
> Sent: Sunday, June 03, 2007 3:36 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
>
> Excellent information Joe, that certainly helps me to understand better why
> this happened and hopefully how to avoid it in the future.
>
> Any thoughts on how to repair the ACLs through the CLI so I can script a
> solution? Manually fixing each folder through Explorer isn't a solution I
> look forward to. :(
>
> Thanks,
> ~Ben
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org on behalf of joe
> Sent: Sat 6/2/2007 11:11 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
>
> There was a change in the ACL format in Windows 2000 which allowed for what
> I call prioritized inheritance. I.E. Depending on where the ACE was
> inherited from, the permission may or may not be able to be overrided. We
> all know how a DENY overrides a GRANT, people are starting to grasp (at
> least in the AD world) that an inherited DENY can be overridden by an
> explicit GRANT. Some folks are now also starting to understand that a DENY
> inherited from level 1 can be overridden by an inherited GRANT inherited
> from level 1.2. I.E. The "closer" the ACE is to the object, the more
> powerful the ACE in respect to whether or not it will be effective on the
> object.
>
> The thing is though that the low level ACL editor API will let you write the
> ACLs in any old order you want and there is a fixed order in which things
> should be written. The order of the ACEs should be
>
> Assuming
> L1
> L2
> L3
> Object
>
> ----------------------------------------
> | Explicit Deny ACEs for Object |
> ----------------------------------------
> ----------------------------------------
> | Explicit Grant ACEs for Object |
> ----------------------------------------
> ========================================
> All following ACEs are inherited on Object
> ========================================
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L3 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L3|
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L2 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L2|
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L1 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L1|
> ------------------------------------------
>
> What you see on the folder prior to XCACLS is
>
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
> Obj Name: f:\temp\test\test2
> SD Size : 132
> SD CRC : 0xbd2cf47a
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 68
> DACL CRC : 0xa755d9d2
> DACL AceCount: 2
> ACEs
> 001)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 002)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
>
>
> The command completed successfully.
>
> Then after the xcacls command you see
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
> Obj Name: f:\temp\test\test2
> SD Size : 264
> SD CRC : 0x6c407ecc
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 200
> DACL CRC : 0x52d1293f
> DACL AceCount: 4
> ACEs
> 001)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 002)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
> 003)
> ACCESS_ALLOWED;INHERIT_ONLY|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-40
> 08382571-2198042679-21229
> 004)
> ACCESS_ALLOWED;CONTAINER_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2
> 198042679-21229
>
>
> The command completed successfully.
>
> and then after Explorer reorders the ACEs (and removes one redundant ACE)
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
> Obj Name: f:\temp\test\test2
> SD Size : 168
> SD CRC : 0x9e5883c1
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 104
> DACL CRC : 0x7959a728
> DACL AceCount: 3
> ACEs
> 001)
> ACCESS_ALLOWED;CONTAINER_INHERIT|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-18627014
> 46-4008382571-2198042679-21229
> 002)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 003)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
>
>
> The command completed successfully.
>
>
> Notice the difference in the ordering in all of those?
>
> The issue comes down to xcacls not being updated after the change in how
> ACLs were set up to properly reflect the inheritance model.
>
>
> There is another place where ACEs are purposely misordered but it is in
> Active Directory and they came up with a fancy name for it... Non-canonical
> ordering of ACEs. i.e. Non-Standard Ordering of ACEs. This is for hidden DL
> membership for Exchange. They toss a couple of explicit GRANT RP ACEs for
> the member attribute for Exchange Servers and Account Operators in front of
> a DENY RP for the member attribute for Everyone. This still breaks ACL tools
> that aren't aware that Exchange did this. Or actually what it does is if the
> ACL of that group is touched by the tool that doesn't understand, the ACL
> can be reordered which means the membership is suddenly visible... ADUC had
> a problem with that for a while if you recall as well. I caught when I was
> first investigating how hidden membership was handled as I needed to make
> sure it was secure and I dumped the RAW ACL and was like WTF.... Of course I
> didn't depend on it, instead I buried the groups I needed protected under a
> protected OU.
>
>
>
> joe
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
> Sent: Saturday, June 02, 2007 1:36 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
>
>
> Actually, now that I look at the permissions with xcacls, the permissions
> are slightly different between a folder that has not yet been "fixed"
> through the error message, and one that has been "fixed". Folder name =
> User name for our home folder structure.
>
>
>
> Fixed Folder...
>
> T:\xcacls fixed
>
> T:\fixed DOMAIN\fixed:(OI)(CI)C
>
> DOMAIN\Domain Admins:(OI)(CI)F
>
> DOMAIN\FilerAdmins:(OI)(CI)F
>
>
>
> Broken Folder...
>
> T:\xcacls broken
>
> T:\broken DOMAIN\Domain Admins:(OI)(CI)F
>
> DOMAIN\FilerAdmins:(OI)(CI)F
>
> DOMAIN\broken:(OI)(IO)C
>
> DOMAIN\broken:(CI)C
>
>
>
> Basically, after I try and check the permissions through the security tab, I
> get that error message, I click OK, and magically the permissions change
> from Broken to Fixed from my example above.
>
>
>
> Hopefully someone might be able to explain the differences between these two
> folder permissions and how best to tackle it.
>
>
>
> Thanks,
>
> ~Ben
>
>
>
> From: WATSON, BEN
> Sent: Friday, June 01, 2007 10:27 PM
> To: 'ActiveDir@mail.activedir.org'
> Subject: [OT] Have you seen this ACL error before?
>
>
>
> So I have completed our major data migration of our company home folders
> from one Netapp filer to a new one. The root folder that contained the home
> folders had very simple permissions set of Domain Admins - Full Control and
> a custom security group called Filer Admins - Full Control. All I needed to
> do in the end was give each user modify rights over their own home folder.
> So I ran this batch script to do so...
>
>
>
> for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G DOMAIN\%%f:C
>
>
>
> Worked beautifully, set the proper user on the correct folder with modify
> rights as it should be while maintaining the other permissions they were
> inheriting from the parent folder as I intended. However... upon checking
> the home folders to ensure they were set properly, each folder would give me
> this error message each time I would click on the security tab...
>
>
>
> error.JPG
> 0[OT]%20Have%20you%20seen%20this%20ACL%20error%20before_x003F_.EML/1_multipa
> rt/image001.jpg>
>
>
>
> (I edited out the name of the folder in the error message)
>
>
>
> Upon clicking OK, the security permissions would indeed be set properly and
> the folders/files within the home folder were inheriting permissions
> properly. So I checked another folder, same error, same result after
> clicking OK. So I checked yet another home folder, and before I checked the
> security permissions, I looked at the permissions within one of the home
> folders. Sure enough, the existing files/folders were not yet inheriting
> any sort of permissions related to my batch script, they were only
> inheriting permissions from the root folder (Domain Admins - Full Control
> and Filer Admins - Full Control). Oddly enough however, if I created any
> new test files/folders, these new files/folders DO inherit the proper
> permissions including the modify rights for the individual user. However
> the existing files/folders would not be fixed until I went to the root home
> folder, checked the security tab, and clicked OK.
>
>
>
> Has anyone seen this before? And does anyone have any idea on what I can
> look at to script a solution for all the home folders? Otherwise I'm
> looking at a very long and very manual process.
>
>
>
> Thanks,
>
> ~Ben
>
>
>
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| listmail
Posts:822
| | 06/03/2007 11:11 AM |
| Once it is in a shape I want it to be in it will make it to the public. :)
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Matheesha
Weerasinghe
Sent: Sunday, June 03, 2007 3:58 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] [OT] Have you seen this ACL error before?
Erm... What are the chances of objacl been released to the public? ;-)
Cheers
M@
On 03/06/07, joe wrote:
> You could do something like
>
> subinacl /file PATH /revoke=SECPRIN /grant=SECPRIN=C
>
>
> Also fileacl or setacl could likely be used.
>
> joe
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
> Sent: Sunday, June 03, 2007 3:36 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
>
> Excellent information Joe, that certainly helps me to understand better
why
> this happened and hopefully how to avoid it in the future.
>
> Any thoughts on how to repair the ACLs through the CLI so I can script a
> solution? Manually fixing each folder through Explorer isn't a solution I
> look forward to. :(
>
> Thanks,
> ~Ben
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org on behalf of joe
> Sent: Sat 6/2/2007 11:11 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
>
> There was a change in the ACL format in Windows 2000 which allowed for
what
> I call prioritized inheritance. I.E. Depending on where the ACE was
> inherited from, the permission may or may not be able to be overrided. We
> all know how a DENY overrides a GRANT, people are starting to grasp (at
> least in the AD world) that an inherited DENY can be overridden by an
> explicit GRANT. Some folks are now also starting to understand that a DENY
> inherited from level 1 can be overridden by an inherited GRANT inherited
> from level 1.2. I.E. The "closer" the ACE is to the object, the more
> powerful the ACE in respect to whether or not it will be effective on the
> object.
>
> The thing is though that the low level ACL editor API will let you write
the
> ACLs in any old order you want and there is a fixed order in which things
> should be written. The order of the ACEs should be
>
> Assuming
> L1
> L2
> L3
> Object
>
> ----------------------------------------
> | Explicit Deny ACEs for Object |
> ----------------------------------------
> ----------------------------------------
> | Explicit Grant ACEs for Object |
> ----------------------------------------
> ========================================
> All following ACEs are inherited on Object
> ========================================
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L3 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L3|
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L2 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L2|
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L1 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L1|
> ------------------------------------------
>
> What you see on the folder prior to XCACLS is
>
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
> Obj Name: f:\temp\test\test2
> SD Size : 132
> SD CRC : 0xbd2cf47a
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 68
> DACL CRC : 0xa755d9d2
> DACL AceCount: 2
> ACEs
> 001)
>
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 002)
>
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
>
>
> The command completed successfully.
>
> Then after the xcacls command you see
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
> Obj Name: f:\temp\test\test2
> SD Size : 264
> SD CRC : 0x6c407ecc
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 200
> DACL CRC : 0x52d1293f
> DACL AceCount: 4
> ACEs
> 001)
>
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 002)
>
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
> 003)
>
ACCESS_ALLOWED;INHERIT_ONLY|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-40
> 08382571-2198042679-21229
> 004)
>
ACCESS_ALLOWED;CONTAINER_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2
> 198042679-21229
>
>
> The command completed successfully.
>
> and then after Explorer reorders the ACEs (and removes one redundant ACE)
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
> Obj Name: f:\temp\test\test2
> SD Size : 168
> SD CRC : 0x9e5883c1
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 104
> DACL CRC : 0x7959a728
> DACL AceCount: 3
> ACEs
> 001)
>
ACCESS_ALLOWED;CONTAINER_INHERIT|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-18627014
> 46-4008382571-2198042679-21229
> 002)
>
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 003)
>
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
>
>
> The command completed successfully.
>
>
> Notice the difference in the ordering in all of those?
>
> The issue comes down to xcacls not being updated after the change in how
> ACLs were set up to properly reflect the inheritance model.
>
>
> There is another place where ACEs are purposely misordered but it is in
> Active Directory and they came up with a fancy name for it...
Non-canonical
> ordering of ACEs. i.e. Non-Standard Ordering of ACEs. This is for hidden
DL
> membership for Exchange. They toss a couple of explicit GRANT RP ACEs for
> the member attribute for Exchange Servers and Account Operators in front
of
> a DENY RP for the member attribute for Everyone. This still breaks ACL
tools
> that aren't aware that Exchange did this. Or actually what it does is if
the
> ACL of that group is touched by the tool that doesn't understand, the ACL
> can be reordered which means the membership is suddenly visible... ADUC
had
> a problem with that for a while if you recall as well. I caught when I was
> first investigating how hidden membership was handled as I needed to make
> sure it was secure and I dumped the RAW ACL and was like WTF.... Of course
I
> didn't depend on it, instead I buried the groups I needed protected under
a
> protected OU.
>
>
>
> joe
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
> Sent: Saturday, June 02, 2007 1:36 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
>
>
> Actually, now that I look at the permissions with xcacls, the permissions
> are slightly different between a folder that has not yet been "fixed"
> through the error message, and one that has been "fixed". Folder name =
> User name for our home folder structure.
>
>
>
> Fixed Folder...
>
> T:\xcacls fixed
>
> T:\fixed DOMAIN\fixed:(OI)(CI)C
>
> DOMAIN\Domain Admins:(OI)(CI)F
>
> DOMAIN\FilerAdmins:(OI)(CI)F
>
>
>
> Broken Folder...
>
> T:\xcacls broken
>
> T:\broken DOMAIN\Domain Admins:(OI)(CI)F
>
> DOMAIN\FilerAdmins:(OI)(CI)F
>
> DOMAIN\broken:(OI)(IO)C
>
> DOMAIN\broken:(CI)C
>
>
>
> Basically, after I try and check the permissions through the security tab,
I
> get that error message, I click OK, and magically the permissions change
> from Broken to Fixed from my example above.
>
>
>
> Hopefully someone might be able to explain the differences between these
two
> folder permissions and how best to tackle it.
>
>
>
> Thanks,
>
> ~Ben
>
>
>
> From: WATSON, BEN
> Sent: Friday, June 01, 2007 10:27 PM
> To: 'ActiveDir@mail.activedir.org'
> Subject: [OT] Have you seen this ACL error before?
>
>
>
> So I have completed our major data migration of our company home folders
> from one Netapp filer to a new one. The root folder that contained the
home
> folders had very simple permissions set of Domain Admins - Full Control
and
> a custom security group called Filer Admins - Full Control. All I needed
to
> do in the end was give each user modify rights over their own home folder.
> So I ran this batch script to do so...
>
>
>
> for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G DOMAIN\%%f:C
>
>
>
> Worked beautifully, set the proper user on the correct folder with modify
> rights as it should be while maintaining the other permissions they were
> inheriting from the parent folder as I intended. However... upon
checking
> the home folders to ensure they were set properly, each folder would give
me
> this error message each time I would click on the security tab...
>
>
>
> error.JPG
>
0[OT]%20Have%20you%20seen%20this%20ACL%20error%20before_x003F_.EML/1_multipa
> rt/image001.jpg>
>
>
>
> (I edited out the name of the folder in the error message)
>
>
>
> Upon clicking OK, the security permissions would indeed be set properly
and
> the folders/files within the home folder were inheriting permissions
> properly. So I checked another folder, same error, same result after
> clicking OK. So I checked yet another home folder, and before I checked
the
> security permissions, I looked at the permissions within one of the home
> folders. Sure enough, the existing files/folders were not yet inheriting
> any sort of permissions related to my batch script, they were only
> inheriting permissions from the root folder (Domain Admins - Full Control
> and Filer Admins - Full Control). Oddly enough however, if I created any
> new test files/folders, these new files/folders DO inherit the proper
> permissions including the modify rights for the individual user. However
> the existing files/folders would not be fixed until I went to the root
home
> folder, checked the security tab, and clicked OK.
>
>
>
> Has anyone seen this before? And does anyone have any idea on what I can
> look at to script a solution for all the home folders? Otherwise I'm
> looking at a very long and very manual process.
>
>
>
> Thanks,
>
> ~Ben
>
>
>
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| lists1
Posts:6
| | 06/05/2007 9:19 AM |
| Hi Ben,
look at the script in the following KB:
http://support.microsoft.com/kb/279682/en-us
Take that ReorderDACL subcommand, and you can integrate this into xcacls or
create your own script which is doing this.
Note that if you have any VISTA-Clients in your company you can also use
ICACLS which doesn't have the issue you described. You can either use it
instead of XCACLS, or in case you've already created your folders you can
use it with the /Verify-Parameter.
Gruesse - Sincerely,
Ulf B. Simon-Weidner
Profile & Publications:
http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811
D
Weblog:
http://msmvps.org/UlfBSimonWeidner
Website:
http://www.windowsserverfaq.org
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
Sent: Sonntag, 3. Juni 2007 03:36
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
Excellent information Joe, that certainly helps me to understand better why
this happened and hopefully how to avoid it in the future.
Any thoughts on how to repair the ACLs through the CLI so I can script a
solution? Manually fixing each folder through Explorer isn't a solution I
look forward to. :(
Thanks,
~Ben
_____
From: ActiveDir-owner@mail.activedir.org on behalf of joe
Sent: Sat 6/2/2007 11:11 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
There was a change in the ACL format in Windows 2000 which allowed for what
I call prioritized inheritance. I.E. Depending on where the ACE was
inherited from, the permission may or may not be able to be overrided. We
all know how a DENY overrides a GRANT, people are starting to grasp (at
least in the AD world) that an inherited DENY can be overridden by an
explicit GRANT. Some folks are now also starting to understand that a DENY
inherited from level 1 can be overridden by an inherited GRANT inherited
from level 1.2. I.E. The "closer" the ACE is to the object, the more
powerful the ACE in respect to whether or not it will be effective on the
object.
The thing is though that the low level ACL editor API will let you write the
ACLs in any old order you want and there is a fixed order in which things
should be written. The order of the ACEs should be
Assuming
L1
L2
L3
Object
----------------------------------------
| Explicit Deny ACEs for Object |
----------------------------------------
----------------------------------------
| Explicit Grant ACEs for Object |
----------------------------------------
========================================
All following ACEs are inherited on Object
========================================
------------------------------------------
| Explicit Inheritable Deny ACEs for L3 |
------------------------------------------
------------------------------------------
| Explicit Inheritable Grant ACEs for L3|
------------------------------------------
------------------------------------------
| Explicit Inheritable Deny ACEs for L2 |
------------------------------------------
------------------------------------------
| Explicit Inheritable Grant ACEs for L2|
------------------------------------------
------------------------------------------
| Explicit Inheritable Deny ACEs for L1 |
------------------------------------------
------------------------------------------
| Explicit Inheritable Grant ACEs for L1|
------------------------------------------
What you see on the folder prior to XCACLS is
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards (
joe@joeware.net) May 2007
Obj Name: f:\temp\test\test2
SD Size : 132
SD CRC : 0xbd2cf47a
Owner : S-1-5-32-544
OwnerSID : S-1-5-32-544
Group : S-1-5-21-1862701446-4008382571-2198042679-513
GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
DACL Prot'd: FALSE
DACL Size: 68
DACL CRC : 0xa755d9d2
DACL AceCount: 2
ACEs
001)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
2-544
002)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
1-3260367365-2193829723-2103023026-1016
The command completed successfully.
Then after the xcacls command you see
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards (
joe@joeware.net) May 2007
Obj Name: f:\temp\test\test2
SD Size : 264
SD CRC : 0x6c407ecc
Owner : S-1-5-32-544
OwnerSID : S-1-5-32-544
Group : S-1-5-21-1862701446-4008382571-2198042679-513
GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
DACL Prot'd: FALSE
DACL Size: 200
DACL CRC : 0x52d1293f
DACL AceCount: 4
ACEs
001)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
2-544
002)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
1-3260367365-2193829723-2103023026-1016
003)
ACCESS_ALLOWED;INHERIT_ONLY|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-40
08382571-2198042679-21229
004)
ACCESS_ALLOWED;CONTAINER_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2
198042679-21229
The command completed successfully.
and then after Explorer reorders the ACEs (and removes one redundant ACE)
F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
ObjACL V01.00.00cpp BETA Joe Richards (
joe@joeware.net) May 2007
Obj Name: f:\temp\test\test2
SD Size : 168
SD CRC : 0x9e5883c1
Owner : S-1-5-32-544
OwnerSID : S-1-5-32-544
Group : S-1-5-21-1862701446-4008382571-2198042679-513
GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
DACL Prot'd: FALSE
DACL Size: 104
DACL CRC : 0x7959a728
DACL AceCount: 3
ACEs
001)
ACCESS_ALLOWED;CONTAINER_INHERIT|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-18627014
46-4008382571-2198042679-21229
002)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
2-544
003)
ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
1-3260367365-2193829723-2103023026-1016
The command completed successfully.
Notice the difference in the ordering in all of those?
The issue comes down to xcacls not being updated after the change in how
ACLs were set up to properly reflect the inheritance model.
There is another place where ACEs are purposely misordered but it is in
Active Directory and they came up with a fancy name for it... Non-canonical
ordering of ACEs. i.e. Non-Standard Ordering of ACEs. This is for hidden DL
membership for Exchange. They toss a couple of explicit GRANT RP ACEs for
the member attribute for Exchange Servers and Account Operators in front of
a DENY RP for the member attribute for Everyone. This still breaks ACL tools
that aren't aware that Exchange did this. Or actually what it does is if the
ACL of that group is touched by the tool that doesn't understand, the ACL
can be reordered which means the membership is suddenly visible... ADUC had
a problem with that for a while if you recall as well. I caught when I was
first investigating how hidden membership was handled as I needed to make
sure it was secure and I dumped the RAW ACL and was like WTF.... Of course I
didn't depend on it, instead I buried the groups I needed protected under a
protected OU.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
Sent: Saturday, June 02, 2007 1:36 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
Actually, now that I look at the permissions with xcacls, the permissions
are slightly different between a folder that has not yet been "fixed"
through the error message, and one that has been "fixed". Folder name =
User name for our home folder structure.
Fixed Folder...
T:\xcacls fixed
T:\fixed DOMAIN\fixed:(OI)(CI)C
DOMAIN\Domain Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
Broken Folder...
T:\xcacls broken
T:\broken DOMAIN\Domain Admins:(OI)(CI)F
DOMAIN\FilerAdmins:(OI)(CI)F
DOMAIN\broken:(OI)(IO)C
DOMAIN\broken:(CI)C
Basically, after I try and check the permissions through the security tab, I
get that error message, I click OK, and magically the permissions change
from Broken to Fixed from my example above.
Hopefully someone might be able to explain the differences between these two
folder permissions and how best to tackle it.
Thanks,
~Ben
From: WATSON, BEN
Sent: Friday, June 01, 2007 10:27 PM
To: 'ActiveDir@mail.activedir.org'
Subject: [OT] Have you seen this ACL error before?
So I have completed our major data migration of our company home folders
from one Netapp filer to a new one. The root folder that contained the home
folders had very simple permissions set of Domain Admins - Full Control and
a custom security group called Filer Admins - Full Control. All I needed to
do in the end was give each user modify rights over their own home folder.
So I ran this batch script to do so...
for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G DOMAIN\%%f:C
Worked beautifully, set the proper user on the correct folder with modify
rights as it should be while maintaining the other permissions they were
inheriting from the parent folder as I intended. However... upon checking
the home folders to ensure they were set properly, each folder would give me
this error message each time I would click on the security tab...
error.JPG
(I edited out the name of the folder in the error message)
Upon clicking OK, the security permissions would indeed be set properly and
the folders/files within the home folder were inheriting permissions
properly. So I checked another folder, same error, same result after
clicking OK. So I checked yet another home folder, and before I checked the
security permissions, I looked at the permissions within one of the home
folders. Sure enough, the existing files/folders were not yet inheriting
any sort of permissions related to my batch script, they were only
inheriting permissions from the root folder (Domain Admins - Full Control
and Filer Admins - Full Control). Oddly enough however, if I created any
new test files/folders, these new files/folders DO inherit the proper
permissions including the modify rights for the individual user. However
the existing files/folders would not be fixed until I went to the root home
folder, checked the security tab, and clicked OK.
Has anyone seen this before? And does anyone have any idea on what I can
look at to script a solution for all the home folders? Otherwise I'm
looking at a very long and very manual process.
Thanks,
~Ben | | | |
| matheesha
Posts:34
| | 06/05/2007 11:01 AM |
| Just to add to Ulf's comments icacls is also available in Windows
Server 2003 SP2. I havent used it. But I see no reason (technical) why
you cannot extract the icacls.exe from the SP2 package and use as
required.
Cheers
M@
On 05/06/07, Ulf B. Simon-Weidner wrote:
> Hi Ben,
>
>
>
> look at the script in the following KB:
>
>
> http://support.microsoft.com/kb/279682/en-us
>
>
>
> Take that ReorderDACL subcommand, and you can integrate this into xcacls or
> create your own script which is doing this.
>
>
>
> Note that if you have any VISTA-Clients in your company you can also use
> ICACLS which doesn't have the issue you described. You can either use it
> instead of XCACLS, or in case you've already created your folders you can
> use it with the /Verify-Parameter.
>
>
>
> Gruesse - Sincerely,
>
> Ulf B. Simon-Weidner
>
> Profile & Publications:
> 2F1214C811D>
> http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811
> D
> Weblog:
> http://msmvps.org/UlfBSimonWeidner
> Website:
> http://www.windowsserverfaq.org
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
> Sent: Sonntag, 3. Juni 2007 03:36
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
>
>
> Excellent information Joe, that certainly helps me to understand better why
> this happened and hopefully how to avoid it in the future.
>
>
>
> Any thoughts on how to repair the ACLs through the CLI so I can script a
> solution? Manually fixing each folder through Explorer isn't a solution I
> look forward to. :(
>
>
>
> Thanks,
>
> ~Ben
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org on behalf of joe
> Sent: Sat 6/2/2007 11:11 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
> There was a change in the ACL format in Windows 2000 which allowed for what
> I call prioritized inheritance. I.E. Depending on where the ACE was
> inherited from, the permission may or may not be able to be overrided. We
> all know how a DENY overrides a GRANT, people are starting to grasp (at
> least in the AD world) that an inherited DENY can be overridden by an
> explicit GRANT. Some folks are now also starting to understand that a DENY
> inherited from level 1 can be overridden by an inherited GRANT inherited
> from level 1.2. I.E. The "closer" the ACE is to the object, the more
> powerful the ACE in respect to whether or not it will be effective on the
> object.
>
>
>
> The thing is though that the low level ACL editor API will let you write the
> ACLs in any old order you want and there is a fixed order in which things
> should be written. The order of the ACEs should be
>
>
>
> Assuming
>
> L1
> L2
> L3
> Object
>
>
>
> ----------------------------------------
> | Explicit Deny ACEs for Object |
> ----------------------------------------
> ----------------------------------------
> | Explicit Grant ACEs for Object |
> ----------------------------------------
> ========================================
> All following ACEs are inherited on Object
> ========================================
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L3 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L3|
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L2 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L2|
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L1 |
>
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L1|
> ------------------------------------------
>
> What you see on the folder prior to XCACLS is
>
>
>
>
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
>
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
>
>
> Obj Name: f:\temp\test\test2
> SD Size : 132
> SD CRC : 0xbd2cf47a
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 68
> DACL CRC : 0xa755d9d2
> DACL AceCount: 2
> ACEs
> 001)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 002)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
>
>
>
>
> The command completed successfully.
>
>
>
> Then after the xcacls command you see
>
>
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
>
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
>
>
> Obj Name: f:\temp\test\test2
> SD Size : 264
> SD CRC : 0x6c407ecc
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 200
> DACL CRC : 0x52d1293f
> DACL AceCount: 4
> ACEs
> 001)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 002)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
> 003)
> ACCESS_ALLOWED;INHERIT_ONLY|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-40
> 08382571-2198042679-21229
> 004)
> ACCESS_ALLOWED;CONTAINER_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2
> 198042679-21229
>
>
>
>
> The command completed successfully.
>
>
>
> and then after Explorer reorders the ACEs (and removes one redundant ACE)
>
>
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
>
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
>
>
> Obj Name: f:\temp\test\test2
> SD Size : 168
> SD CRC : 0x9e5883c1
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 104
> DACL CRC : 0x7959a728
> DACL AceCount: 3
> ACEs
> 001)
> ACCESS_ALLOWED;CONTAINER_INHERIT|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-18627014
> 46-4008382571-2198042679-21229
> 002)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 003)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
>
>
>
>
> The command completed successfully.
>
>
>
>
>
> Notice the difference in the ordering in all of those?
>
>
>
> The issue comes down to xcacls not being updated after the change in how
> ACLs were set up to properly reflect the inheritance model.
>
>
>
>
>
> There is another place where ACEs are purposely misordered but it is in
> Active Directory and they came up with a fancy name for it... Non-canonical
> ordering of ACEs. i.e. Non-Standard Ordering of ACEs. This is for hidden DL
> membership for Exchange. They toss a couple of explicit GRANT RP ACEs for
> the member attribute for Exchange Servers and Account Operators in front of
> a DENY RP for the member attribute for Everyone. This still breaks ACL tools
> that aren't aware that Exchange did this. Or actually what it does is if the
> ACL of that group is touched by the tool that doesn't understand, the ACL
> can be reordered which means the membership is suddenly visible... ADUC had
> a problem with that for a while if you recall as well. I caught when I was
> first investigating how hidden membership was handled as I needed to make
> sure it was secure and I dumped the RAW ACL and was like WTF.... Of course I
> didn't depend on it, instead I buried the groups I needed protected under a
> protected OU.
>
>
>
>
>
>
>
> joe
>
>
>
>
>
> --
>
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
> Sent: Saturday, June 02, 2007 1:36 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
> Actually, now that I look at the permissions with xcacls, the permissions
> are slightly different between a folder that has not yet been "fixed"
> through the error message, and one that has been "fixed". Folder name =
> User name for our home folder structure.
>
>
>
> Fixed Folder...
>
> T:\xcacls fixed
>
> T:\fixed DOMAIN\fixed:(OI)(CI)C
>
> DOMAIN\Domain Admins:(OI)(CI)F
>
> DOMAIN\FilerAdmins:(OI)(CI)F
>
>
>
> Broken Folder...
>
> T:\xcacls broken
>
> T:\broken DOMAIN\Domain Admins:(OI)(CI)F
>
> DOMAIN\FilerAdmins:(OI)(CI)F
>
> DOMAIN\broken:(OI)(IO)C
>
> DOMAIN\broken:(CI)C
>
>
>
> Basically, after I try and check the permissions through the security tab, I
> get that error message, I click OK, and magically the permissions change
> from Broken to Fixed from my example above.
>
>
>
> Hopefully someone might be able to explain the differences between these two
> folder permissions and how best to tackle it.
>
>
>
> Thanks,
>
> ~Ben
>
>
>
> From: WATSON, BEN
> Sent: Friday, June 01, 2007 10:27 PM
> To: 'ActiveDir@mail.activedir.org'
> Subject: [OT] Have you seen this ACL error before?
>
>
>
> So I have completed our major data migration of our company home folders
> from one Netapp filer to a new one. The root folder that contained the home
> folders had very simple permissions set of Domain Admins - Full Control and
> a custom security group called Filer Admins - Full Control. All I needed to
> do in the end was give each user modify rights over their own home folder.
> So I ran this batch script to do so...
>
>
>
> for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G DOMAIN\%%f:C
>
>
>
> Worked beautifully, set the proper user on the correct folder with modify
> rights as it should be while maintaining the other permissions they were
> inheriting from the parent folder as I intended. However... upon checking
> the home folders to ensure they were set properly, each folder would give me
> this error message each time I would click on the security tab...
>
>
>
> error.JPG
> 5d%20%5bOT%5d%20Have%20you%20seen%20this%20ACL%20error%20before_x003F_.EML/1
> _multipart/image001.jpg>
>
>
>
> (I edited out the name of the folder in the error message)
>
>
>
> Upon clicking OK, the security permissions would indeed be set properly and
> the folders/files within the home folder were inheriting permissions
> properly. So I checked another folder, same error, same result after
> clicking OK. So I checked yet another home folder, and before I checked the
> security permissions, I looked at the permissions within one of the home
> folders. Sure enough, the existing files/folders were not yet inheriting
> any sort of permissions related to my batch script, they were only
> inheriting permissions from the root folder (Domain Admins - Full Control
> and Filer Admins - Full Control). Oddly enough however, if I created any
> new test files/folders, these new files/folders DO inherit the proper
> permissions including the modify rights for the individual user. However
> the existing files/folders would not be fixed until I went to the root home
> folder, checked the security tab, and clicked OK.
>
>
>
> Has anyone seen this before? And does anyone have any idea on what I can
> look at to script a solution for all the home folders? Otherwise I'm
> looking at a very long and very manual process.
>
>
>
> Thanks,
>
> ~Ben
>
>
>
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| bwatson
Posts:0
| | 06/05/2007 11:51 AM |
| Thanks for the heads up Ulf! I'm going to look into the icacls command, especially now that Matheesha brought up that it was available in the Win2k3SP2 package.
Thanks,
~Ben
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Matheesha Weerasinghe
Sent: Tuesday, June 05, 2007 8:01 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] [OT] Have you seen this ACL error before?
Just to add to Ulf's comments icacls is also available in Windows
Server 2003 SP2. I havent used it. But I see no reason (technical) why
you cannot extract the icacls.exe from the SP2 package and use as
required.
Cheers
M@
On 05/06/07, Ulf B. Simon-Weidner wrote:
> Hi Ben,
>
>
>
> look at the script in the following KB:
>
>
> http://support.microsoft.com/kb/279682/en-us
>
>
>
> Take that ReorderDACL subcommand, and you can integrate this into xcacls or
> create your own script which is doing this.
>
>
>
> Note that if you have any VISTA-Clients in your company you can also use
> ICACLS which doesn't have the issue you described. You can either use it
> instead of XCACLS, or in case you've already created your folders you can
> use it with the /Verify-Parameter.
>
>
>
> Gruesse - Sincerely,
>
> Ulf B. Simon-Weidner
>
> Profile & Publications:
> 2F1214C811D>
> http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811
> D
> Weblog:
> http://msmvps.org/UlfBSimonWeidner
> Website:
> http://www.windowsserverfaq.org
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
> Sent: Sonntag, 3. Juni 2007 03:36
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
>
>
> Excellent information Joe, that certainly helps me to understand better why
> this happened and hopefully how to avoid it in the future.
>
>
>
> Any thoughts on how to repair the ACLs through the CLI so I can script a
> solution? Manually fixing each folder through Explorer isn't a solution I
> look forward to. :(
>
>
>
> Thanks,
>
> ~Ben
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org on behalf of joe
> Sent: Sat 6/2/2007 11:11 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
> There was a change in the ACL format in Windows 2000 which allowed for what
> I call prioritized inheritance. I.E. Depending on where the ACE was
> inherited from, the permission may or may not be able to be overrided. We
> all know how a DENY overrides a GRANT, people are starting to grasp (at
> least in the AD world) that an inherited DENY can be overridden by an
> explicit GRANT. Some folks are now also starting to understand that a DENY
> inherited from level 1 can be overridden by an inherited GRANT inherited
> from level 1.2. I.E. The "closer" the ACE is to the object, the more
> powerful the ACE in respect to whether or not it will be effective on the
> object.
>
>
>
> The thing is though that the low level ACL editor API will let you write the
> ACLs in any old order you want and there is a fixed order in which things
> should be written. The order of the ACEs should be
>
>
>
> Assuming
>
> L1
> L2
> L3
> Object
>
>
>
> ----------------------------------------
> | Explicit Deny ACEs for Object |
> ----------------------------------------
> ----------------------------------------
> | Explicit Grant ACEs for Object |
> ----------------------------------------
> ========================================
> All following ACEs are inherited on Object
> ========================================
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L3 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L3|
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L2 |
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L2|
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Deny ACEs for L1 |
>
> ------------------------------------------
> ------------------------------------------
> | Explicit Inheritable Grant ACEs for L1|
> ------------------------------------------
>
> What you see on the folder prior to XCACLS is
>
>
>
>
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
>
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
>
>
> Obj Name: f:\temp\test\test2
> SD Size : 132
> SD CRC : 0xbd2cf47a
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 68
> DACL CRC : 0xa755d9d2
> DACL AceCount: 2
> ACEs
> 001)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 002)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
>
>
>
>
> The command completed successfully.
>
>
>
> Then after the xcacls command you see
>
>
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
>
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
>
>
> Obj Name: f:\temp\test\test2
> SD Size : 264
> SD CRC : 0x6c407ecc
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 200
> DACL CRC : 0x52d1293f
> DACL AceCount: 4
> ACEs
> 001)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 002)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
> 003)
> ACCESS_ALLOWED;INHERIT_ONLY|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-1862701446-40
> 08382571-2198042679-21229
> 004)
> ACCESS_ALLOWED;CONTAINER_INHERIT;0x1301bf;;;S-1-5-21-1862701446-4008382571-2
> 198042679-21229
>
>
>
>
> The command completed successfully.
>
>
>
> and then after Explorer reorders the ACEs (and removes one redundant ACE)
>
>
>
> F:\temp>f:\dev\bdscpp\objacl\release_Build\objacl f:\temp\test\test2
>
>
>
> ObjACL V01.00.00cpp BETA Joe Richards (
> joe@joeware.net) May 2007
>
>
>
> Obj Name: f:\temp\test\test2
> SD Size : 168
> SD CRC : 0x9e5883c1
> Owner : S-1-5-32-544
> OwnerSID : S-1-5-32-544
> Group : S-1-5-21-1862701446-4008382571-2198042679-513
> GroupSID : S-1-5-21-1862701446-4008382571-2198042679-513
> DACL Prot'd: FALSE
> DACL Size: 104
> DACL CRC : 0x7959a728
> DACL AceCount: 3
> ACEs
> 001)
> ACCESS_ALLOWED;CONTAINER_INHERIT|OBJECT_INHERIT;0x1301bf;;;S-1-5-21-18627014
> 46-4008382571-2198042679-21229
> 002)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-3
> 2-544
> 003)
> ACCESS_ALLOWED;CONTAINER_INHERIT|INHERITED|OBJECT_INHERIT;0x1f01ff;;;S-1-5-2
> 1-3260367365-2193829723-2103023026-1016
>
>
>
>
> The command completed successfully.
>
>
>
>
>
> Notice the difference in the ordering in all of those?
>
>
>
> The issue comes down to xcacls not being updated after the change in how
> ACLs were set up to properly reflect the inheritance model.
>
>
>
>
>
> There is another place where ACEs are purposely misordered but it is in
> Active Directory and they came up with a fancy name for it... Non-canonical
> ordering of ACEs. i.e. Non-Standard Ordering of ACEs. This is for hidden DL
> membership for Exchange. They toss a couple of explicit GRANT RP ACEs for
> the member attribute for Exchange Servers and Account Operators in front of
> a DENY RP for the member attribute for Everyone. This still breaks ACL tools
> that aren't aware that Exchange did this. Or actually what it does is if the
> ACL of that group is touched by the tool that doesn't understand, the ACL
> can be reordered which means the membership is suddenly visible... ADUC had
> a problem with that for a while if you recall as well. I caught when I was
> first investigating how hidden membership was handled as I needed to make
> sure it was secure and I dumped the RAW ACL and was like WTF.... Of course I
> didn't depend on it, instead I buried the groups I needed protected under a
> protected OU.
>
>
>
>
>
>
>
> joe
>
>
>
>
>
> --
>
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of WATSON, BEN
> Sent: Saturday, June 02, 2007 1:36 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] [OT] Have you seen this ACL error before?
>
> Actually, now that I look at the permissions with xcacls, the permissions
> are slightly different between a folder that has not yet been "fixed"
> through the error message, and one that has been "fixed". Folder name =
> User name for our home folder structure.
>
>
>
> Fixed Folder...
>
> T:\xcacls fixed
>
> T:\fixed DOMAIN\fixed:(OI)(CI)C
>
> DOMAIN\Domain Admins:(OI)(CI)F
>
> DOMAIN\FilerAdmins:(OI)(CI)F
>
>
>
> Broken Folder...
>
> T:\xcacls broken
>
> T:\broken DOMAIN\Domain Admins:(OI)(CI)F
>
> DOMAIN\FilerAdmins:(OI)(CI)F
>
> DOMAIN\broken:(OI)(IO)C
>
> DOMAIN\broken:(CI)C
>
>
>
> Basically, after I try and check the permissions through the security tab, I
> get that error message, I click OK, and magically the permissions change
> from Broken to Fixed from my example above.
>
>
>
> Hopefully someone might be able to explain the differences between these two
> folder permissions and how best to tackle it.
>
>
>
> Thanks,
>
> ~Ben
>
>
>
> From: WATSON, BEN
> Sent: Friday, June 01, 2007 10:27 PM
> To: 'ActiveDir@mail.activedir.org'
> Subject: [OT] Have you seen this ACL error before?
>
>
>
> So I have completed our major data migration of our company home folders
> from one Netapp filer to a new one. The root folder that contained the home
> folders had very simple permissions set of Domain Admins - Full Control and
> a custom security group called Filer Admins - Full Control. All I needed to
> do in the end was give each user modify rights over their own home folder.
> So I ran this batch script to do so...
>
>
>
> for /F %%f in ('type c:\users.txt') do xcacls %%f /E /G DOMAIN\%%f:C
>
>
>
> Worked beautifully, set the proper user on the correct folder with modify
> rights as it should be while maintaining the other permissions they were
> inheriting from the parent folder as I intended. However... upon checking
> the home folders to ensure they were set properly, each folder would give me
> this error message each time I would click on the security tab...
>
>
>
> error.JPG
> 5d%20%5bOT%5d%20Have%20you%20seen%20this%20ACL%20error%20before_x003F_.EML/1
> _multipart/image001.jpg>
>
>
>
> (I edited out the name of the folder in the error message)
>
>
>
> Upon clicking OK, the security permissions would indeed be set properly and
> the folders/files within the home folder were inheriting permissions
> properly. So I checked another folder, same error, same result after
> clicking OK. So I checked yet another home folder, and before I checked the
> security permissions, I looked at the permissions within one of the home
> folders. Sure enough, the existing files/folders were not yet inheriting
> any sort of permissions related to my batch script, they were only
> inheriting permissions from the root folder (Domain Admins - Full Control
> and Filer Admins - Full Control). Oddly enough however, if I created any
> new test files/folders, these new files/folders DO inherit the proper
> permissions including the modify rights for the individual user. However
> the existing files/folders would not be fixed until I went to the root home
> folder, checked the security tab, and clicked OK.
>
>
>
> Has anyone seen this before? And does anyone have any idea on what I can
> look at to script a solution for all the home folders? Otherwise I'm
> looking at a very long and very manual process.
>
>
>
> Thanks,
>
> ~Ben
>
>
>
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
.+- 0jq.+- 0ˊEKj!ibbןjm | | | |
|
|