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.
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.
Back to our example, say I have a People OU, and all my human accounts are in the Employees OU.
Then I'm going to create a service account for this application to use to make its calls back to AD. So I'll create a new account - ldapsync - and put it in the Service Accounts OU. Typically the userid and password for this account would go into the application's config file (the password being encrypted of course).
Now the fun part. Suppose the vendor says that the application needs to read all user account information AND write back information in the "Comments" attribute of each user. You could put the account in Account Operators, but that is still an overgrant of access, so let's delegate instead. Lets give LDAPSync Manager exactly what it needs (and nothing more!). Remember, it needs these two things:
Remember what I said about classes? Well "user" is a class, and both human accounts AND service accounts are in the "user" class, so you need to know if it needs write access to ALL user accounts, or just human accounts. You ask the vendor. Vendor fesses up and says, well, really just humans. Good! Progress.
<soapbox> Push your vendors! Do not take "well, it just needs Domain Admins" as an answer. NO IT DOESN'T. If you are getting that answer it is probably from a tier 1 support person just trying to close the ticket. Make your vendor work for your business! You're paying them gobs of money for their product, so make them tell you exactly what it needs! It's best for your security and best for your environment. </soapbox>
So now we delegate. Right Click the "Employees" OU and select "Delegate Control" (do this as a Domain Admin on a DC of course,and in your test environment first. You do have a test domain setup, right? ...right?):
Choose Next, then add the ldapsync manager account. Best practice here really is to create a new group and add the group. That way you can just drop users in and out of the group to grant them that access. For this example though, we'll just use the ldapsync user. Click "Add" and type in the userid in the field, click OK.
Click Next. Now we run into a limitation of the delegation wizard. We can only do one major task at once. We'll come back to this in a minute. For now we just want to select "Read all user information".
Click Next, and then Finish. Way to go - you're half way there, now we need to delegate the second requirement - write access to the comment attribute of user objects. Here's where you can get crazy with delegation. Go through the process again. Right Click Employees > Delegate Control > Next > Add ldapsync > Next. You should be here:
This time, we're going to select "Create a custom task to delegate" > Next. Select "Only the following objects in the folder". Remember what I said about classes? Well here's where you're going to get a whole bunch of them. Scroll all the way down to the bottom of the list and select "User objects". We don't want to delegate access to everything now do we?
Click Next. Remember you were asked to allow write access to the Comments field. Well the "Comments" field is a property in the user class, so select the "Property Specific" checkbox. In the list that follows, scroll down and select "Write Comment" (you already granted it Read access above). The click Next > Finish.
Done!
Now if go into the Employees OU, right click a user > Properties > Security tab > Advanced button. Sort the columns by "Name" (just click the "Name" button), then scroll down until you see the "ldapsync" entries. There should be two of them. This is due to how Active Directory categorizes permissions (that's a whole 'nother topic :-). The bottom one says "Read all user information", but if you double click the top one and scroll down, here's what you'll see:
"Write Comment" is selected and it's grayed out. That's because the permission is being inherited from the Employees OU. This is good because we want those perms to be inherited by all user objects.
Congrats, you're done!
There really all there is to it. Still confused? Leave a comment below and I'll reply. Have a look here for another good example on delegation.
Bottom line? Select a typical use case for your environment and play with it (again, in your test domain) until you get it right. It's not hard. Don't be afraid to fail, and when you do, try harder! 🙂
Until next time!
@curi0usJack
