Inherited permissions from "Parent Object" ?

Question

_{Thursday, March 15, 2012 8:23 PM}

I've been looking through some of the older posts regarding this issue and no one seems to have a answer as to why it's happing.  It's easy to fix but only if you catch it.

Issue:  Wheather on server 2008 or 2003 we have found that the permissions on a file and folder were wrong based on the security inheritance rules.  The problem perrmission is a inherited permission with the "Intherited From" (advance security permissions tab on said file or folder) stating  "Parent Object" and nothing more.   The catch is we have no idea were this came from.

1 occurrence)  a users was moving a folder then had no access to it.  We found the folder and the permissions were for the most part correct except one entry (group A) was listed and (group b) wasn't.  (Group B) was suppose to be there because the folder was set to inherit, but it didn't.  (Group A) stated that it was inherited but it was not present on the parent folder.   Funny thing was the permissions works as stated, even though we have no idea how they got there.  Group A also stated that it was inherited from "Parent Object".

2 occurrence) a user created a new folder.  This time the folder inherited all the correct groups, but 1 of them had the wrong permissions.  The parent had the group with Read Only.  The folder created had it as Read/Write and again it stated it was inherited, and inherited from "Parent Object".

Now other inherited permisions state which folder it came from if it is applied correctly.  So this is where the "parent object" part is troubling. 

Both of these incidents are very troubling to us becasue it gives the wrong or more permissions then what was intended or desired.  And it was only after a user ran into a problem that we discovered it.  I'm now writing a script to see if I can find more of these occurances.  In any case this, in my opinion, is a major problem and a bug that needs to be addressed by Microsoft.   If system admins can't rely on the permissons to be applied correctly then we have to seriously reconsider Microsoft as a secure file system solution.

We believe we have narrowed down the problem to Windows Explorer, but we are still trying to recreate the problem.

If anyone have additional information on this issue please let us know.

Thank you

All replies (7)

_{Saturday, March 17, 2012 1:03 PM}

Hi,

I'm thinking if the issue is caused by some permission settings related to "This folder only" or "subfolders and files only" options on parent folder. For example if groupA has "Full Control - subfolders only" on parent folder, then it will have full control on a new created subfolder. So please provide the exact permission settings of the parent folder so that I could have a try to reproduce the issue.

TechNet Subscriber Support in forum |If you have any feedback on our support, please contact [email protected].

_{Monday, March 19, 2012 1:32 PM}

SG - security group

The only common thing between the 2 occurrences is the workstations are Windows XP sp3. 

Occurrence 1

This is the result from occurrence one above.  This is shared out through 2008 R2 DFS (domain).  ABE is enabled at DFS and share levels.  The File server is Windows 2008 R2 sp1.

Folder I (top level)

    SG1 - Full -This folder, subfolders and files

    SG2 -  Read & Execute   -  This Folder Only

 *   SG3 - Modify - This folder, subfolders and files*

    SG4 - Modify - This folder, subfolders and files

   Next folder down  (all rights inherited)

         SG1 - Full -This folder, subfolders and files

         SG2 -  Read & Execute   -  This Folder Only

         SG4 - Modify - This folder, subfolders and files

**         SG8 - Modify - Full -This folder, subfolders and files (shows inherited - from "Parent Object")**

Here a total different group was assigned rights that didn't have rights on the parent (SG8), and the group that was suppose to be there was missing(SG3).  SG8 was assigned similar rights on a neighboring folder at the top level.

In occurrence two this was the result.  This was just creating a new folder.

Shared through a map drive letter, added by a login script using "net use".   ABE is enabled on the share.   Here the server is windows Server 2003 R2 sp2

Folder I (top level)   (shared here)

    SG1 - Full -This folder, subfolders and files

    SG2 -  Read & Execute   -  This folder, subfolders and files

*    SG3 - Read & execute - This folder, subfolders and files*

    SG4 - Modify - This folder, subfolders and files

   Next folder down  (all rights inherited)

         SG1 - Full -This folder, subfolders and files

         SG2 -  Read & Execute   -  Full -This folder, subfolders and files

*         SG3 - Modified - This folder, subfolders and files (shows inherited form "Parent Object")*

          SG4 - Modify - This folder, subfolders and files

Here  SG3 was given more than they should have had.  Read only to Modified.

Any help on this would be fantastic.   Just knowing how this is occurring would be helpful.    One thing I didn't notice is on my windows 7 sp1 PC, if I look at the security permissions I can see in some cases "parent object"  on different (inherited from) columns on different folders.  But if I go directly to the server the permissions are stated correctly with the actual parent path listed in the (inherited from) column.

Thanks for taking the time to look at this.

_{Wednesday, September 12, 2012 12:33 PM}

Hi,

any news on this. I can observe this as well and I am not sure why NTFS behaves that way.

-Raimund

_{Tuesday, May 14, 2013 12:01 PM}

"Parent Object" can show up in permissions when the parent is a disk that is mounted to a mount point.  It's a bit confusing as there are two sets of permissions at the same "folder".  One set is the mount point path permissions and the other set belong to the disk. Example: you mount a disk to c:\mount\somedisk.  When you check properties of somedisk and go to the security tab, you see the permissions for the "folder".  To see the disk permissions, right click the folder and select properties and then on the General tab select the properties button.  From there you can the go to security to see the disk permissions.

FWIW, none of the permissions from the mount point path are inherited to the disk.

_{Tuesday, May 14, 2013 2:22 PM}

If one does a change to NTFS, and then aborts when the change is running you might run in to weird permissions.

icacls "Folder" /remove SG8
And then Ctrl-C in mid change.

Then some downlevel folders might have incorrect permissions.

Oscar Virot

_{Tuesday, March 3, 2020 12:43 PM}

We're having the same issue. Wondering what it means when the advanced permissions state "Inherited from Parent Object".The last 3 ACE's are not coming form the parent folder, no one knows where they're coming from:

_{Tuesday, April 7, 2020 8:18 PM}

Super old, but I've found that it also occurs when you change ownership on a directory.  The previous owner will have the Inherited from "Parent Object".