2

The question

So, I have setup a new domain with two DC's. I'm trying to remove the Authenticated Users group from the one of the OU's and that works fine, however child objects do not update (they still have the Authenticated Users security groep applied) while inheritance is enabled:

OU topology:

OU topology

Top OU TestOU notice the Authenticated Users group is removed:

Test OU properties

Child1 security properties notice the Authenticated Users group:

Child1 security properties

Child1 advanced security notice the Disable inheritance button: Child1 advanced security

I have tried to clear all permissions on the Authenticated Users object and then apply to all descendants but that doesn't work...

There isn't a function either (although, not that I am aware of) to replace all child object permissions (as you can on filesystem level).

So, how do I get the inheritance working as I think it should?

7

The authenticated users in child1 are not there due to inheritance, they were added directly to the object. Probably you chose to copy the rights after removing the inheritance or they were there before.

You can see it, because the checkbox is not grey (right from authenticated users).

  • So - how am I able to fix this? Readding the Authenticated Users group and setting the apply to accordingly doesn't fix the issue. – Devator Nov 6 '14 at 13:24
  • 1
    can't you delete the authenticated users from child1? – marsh-wiggle Nov 6 '14 at 14:55
3

It's a bit late, considering when this question was posted, but I came across the same issue/question and thought it could be useful to post this. I had blocked inheritance on an OU, removed Authenticated Users, and when I created a new object (such as a group), Authenticated Users was added to the DACL for that group. See this doc

This is due to the default permissions applied to an object, which can be checked doing the following (this is a bit quick and dirty, but did the job for me):

  1. Open adsiedit.msc
  2. Navigate to object (such as CN=Organizational-unit)
  3. Copy the defaultSecuritydescriptor value (which is an SDDL string)
  4. Convert SDDL string to human readable ACEs (in PowerShell):

    $oldSddl = "insert value you copied in Step 3” 
    $ACLObject = New-Object -TypeName System.Security.AccessControl.DirectorySecurity 
    $ACLObject.SetSecurityDescriptorSddlForm($oldSddl) 
    $ACLObject.Access
    

Code was from this source

In theory could then replace this SDDL string (using a method, such as described in this article) and then paste this over the value from step 3. The usual caveats would apply about testing in test environment, having proper backups, etc, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.