Using access control inheritance in Active Directory

By controlling how Active Directory allows security properties to be inherited, you can save yourself a lot of work.


Every Active Directory object has associated with it a security descriptor property that protects the object. Within the security descriptor you can control a discretionary access control list (DACL) that in turn contains a list of access control entities (ACEs). It's those ACEs that protect the object. Each ACE grants or denies access to specified property of the object to a user or group. If you're interested in the gory details, see the

Requires Free Membership to View

Access Control Model page on the Microsoft Developer's site, which provides links to some great detailed discussions of the mechanisms at work, including the interaction between threads and securable objects.

Each time you want to change the access control settings of an object, you need to manipulate the nTSecurityDescriptor property of the object using a 10-step procedure spelled out at http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/adsi/glsecur2_8hpw.htm. In practice, you would not explicitly manipulate the access control properties of every object, you would rely on inheritance to do the work for you instead. By controlling how Active Directory objects inherit ACEs, you can allow the system to automatically set the security status of objects as users create them.

The easiest way to administer access control is by establishing the access rules high up in the object tree and then allow inheritance to propagate the rules down the tree as objects are added. For example, you can add a collection of ACEs to the DACL of an organization unit object and have those security parameters inherited by every object created as a child of the organizational unit.

Every time you create an Active Directory object, a security descriptor is created for the object whether you explicitly specify one or not. If you do not specify a descriptor, the new object inherits all the ACEs from its parent object plus any ACEs from the default DACL. If you don't want a child to inherit ACEs, set the SE_DACL_PROTECTED bit in the security descriptor's control register.

You can also control inheritance of permissions on a per-ACE basis using AceFlags:

This flag causes the ACE to be inherited down in the tree.
This flag causes the ACE to be inherited down only one level in the tree.
This flag causes the ACE to be ignored on the object it is specified on and only be inherited down and be effective where it has been inherited.

Kevin Sharp is president of Accurate Information Inc. He has years of experience as a system administrator with various operating systems, and is a member of the Institute of Electrical and Electronic Engineers.

Did you like this tip? Drop us a line and let us know.

Related Book

Mission-Critical Active Directory Architecting a Secure and Scalable Infrastructure
Author : Micky Balladelli and Jan De Clercq
Publisher : Digital Press
Published : Mar 2001
Summary :
Learn from Compaq's own Active Directory experts techniques and best practices for creating a secure and scalable network foundation for Windows 2000 and Exchange 2000.

This was first published in May 2001

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.