AD Object Permission Inheriting Behavior

================================

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.

Exchange Event ID 9582, Virtual Memory vs. physical memory

WinMag Article ID 547743

seemingly simple, namely "stupid", but hard-to-find-answer questions for beginners.

=========================================

More than often I was confused by a very basic concept that may be too simple for a guru but I just couldn't find a definite/clear answer ANYWHERE, and it slowed down my learning progress a lot. So, I am listing a few below, hoping that can help others who are experiencing similar problems.

1. do I have to have a MX record on my internal DNS for Exchange servers?
Answer: no. You don't. MX record is used only for people from Internet sending email to your organization.

2. Local Administrator, Domain Administrator, Administrators, and Domain Admins
1). "Administrator" is a built-in account that you can't disable/delete but can rename
2). If you are in a domain, you will have both "domain\administrator" and local "computer$\administrator" account. The one you see in Active Directory Users and Computers is domain administrator, while the one you see in Local Users and Groups is local Administrator. Note: on a Domain Controller, there is not Local Users and Groups anymore, and you will use only the one you see in ADUC, which is domain administrator (having local administrator permissions at the same time)
3). "Administrator" is not the same as LocalSystem
4). "Administrators" is a built-in local group for local administrators. "Domain Admins" is a built-in group for domain administrators.
5). By default, member of "domain admins" is also member of local "administrators"
6). You can put any one into "domain admins" and "administrators", they then get the permissions respectively