One of the most frequent questions I get from my CircleCityCon/DerbyCon Active Directory talk goes something like "You recommend that we delegate permissions in AD (as opposed to just dropping everything in Domain Admins), but I just inherited this domain and have no idea what delegation is. Help?"

Well good news: 1) Delegation in AD isn't hard. Trust me. 2) You can delegate just about anything, making delegation your best friend from a security standpoint........

There is a key point to understand before we get into this. Objects in Active Directory each have a class. Very similar to a programming class, an Active Directory class is just a construct that defines the properties (also known as "attributes") of an object. These classes and attributes are defined in the Active Directory schema. Think of the schema as the dictionary which defines each class. In this dictionary, you can add news classes, and change the "definition" of existing classes.

If you are reading this you are probably a Domain Admin (DA) or have similar rights, so you are likely editing users/groups all the time. The reason why a user in Active Directory is a user is because that object is associated with the user class in the AD schema. The User class has properties we all know like description, manager, group membership etc. More on that later.

So, let's dive into delegation. Delegation is just what you would think it is: delegating permissions to a specified user or group.

OUR SCENARIO

Let's assume for our example that you have an application called LDAPSync Manager that wants to integrate with Active Directory and read all user information (a la Sharepoint). It's going to synchronize user information with it's own database and keep everything up to date by crawling your domain daily. You *could* add the application's service account to Domain Admins, but that would be a terrible overgranting of access and could lead to a whole host of problems. So instead of doing that, you find out exactly what the application really needs for permissions, and you delegate that access to the id that the application is using.

How would you go about doing that? First, I suggest is that you ask the vendor what rights are absolutely necessary. No vendor worth their salt will say "We must have Domain Admin!". It's just not true. They might say, we need to be able to read all your user information. That's fine - we can work with that. Hopefully your domain is organized in such a fashion that all your people are under one OU. Never in my years of domain administration have I *ever* granted a vendor account Domain Admins privs. It just isn't necessary.

STEP BY STEP

Back to our example, say I have a People OU, and all my human accounts are in the Employees OU.