================================
By default, permissions are inherited in AD. What it means is if you create a new object, it will get its ACLs from its parent container and the default ACL defined by schema for the class. For example, if "everyone" has "read" permission on an OU, then by default, "everyone" has "read" permission on any newly created downlevel OUs and objects.
You can change this behavior by clearing the checkbox "allow inheritable permissions....." on an AD object's properties windows, Security page. But as I said earlier, that box is checked on everything by default. If you delegate control to a group or a user on a specific level, the user/group is being delegated will automatically gets the same permissions against the downlevel objects.
So far everything what I have said should still make sense to you. And you would logically think that if you open the properties of an OU, add a user to have write permission, you should see that that user has write permission on downlevel objects. Surprisingly, that is not the case!
Hmm..., what is wrong here? So the inheriting model doesn't work anymore? Confusing, uh?
To understand all these, you have to understand that AD doesn't "copy" everything it has on one level to next level. It copies only "inheritable permissions" to downlevel. Then what is a "inheritable permission"?
If you click on Advance button on Security page, you will see the details of permissions on this object, each single entry(ACE) has an attribute of "this permission applies to", and the options are "this object only", "this object and the children", etc. Now you should have a kind of sense how it works, right? Change the type to be "this object and the children", you will eventually the permission you defined on this level will populate into downlevel object - as expected. And Delegation Control Wizard will take care of this for you.