Using access control inheritance in Active Directory

Admins can increase productivity by using Active Directory to manage how objects inherit access control entities.

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

Procedure:

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 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:

ADS_ACEFLAG_INHERIT_ACE
This flag causes the ACE to be inherited down in the tree.
ADS_ACEFLAG_NO_PROPAGATE_INHERIT_ACE
This flag causes the ACE to be inherited down only one level in the tree.
ADS_ACEFLAG_INHERIT_ONLY_ACE
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

Dig deeper on Microsoft Active Directory Design and Administration

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

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:

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close