Active Directory Delegation of Control

No you don’t all need ‘Domain Admin’ rights, that includes you Mr IT Manager!

Users in the IT Helpdesk don’t all need ‘Domain Admin’ rights to perform daily tasks like password resets, user group changes and logging into users workstations for fixes. In addition to this they should also elevate rights and authenticate with another account in order to perform Active Directory (AD) administrative tasks, I wrote about this here. We can delegate special permissions to a security group in order for that group of members to be able to reset passwords and perform other AD related tasks. We can delegate this level of control on specific Organisation Units (OU), so for example all users under that OU can be managed by different levels of IT Support and there corresponding AD security group, i.e. a group for 1st line IT Support called ‘IT Helpdesk ‘, ‘2nd line IT support’ and ‘3rd line IT support’ and so on, so we can have different levels of control. This means we give the permission to a group and in turn members of that group can perform special functions on the users that reside in that particular OU. Thankfully Microsoft have thought about this and there is a fairly straightforward way of achieving it by setting a set of stock permissions on the OU. To do this we can use the ‘Delegation of Control’ wizard in AD Users and Computers.

Delegation of Control Wizard

Ideally we want to split out our standard domain user accounts for standard non privilege duties like reading email and using Microsoft Word, then have a separate admin accounts ie ‘Adam-adm’ or ‘Adamadmin’ for the administrative privileges. These admin accounts can then be used to rdp directly to a separate management server which has the various tools installed. Tools like the Remote Server Administration tool set which has Active Directory Users and computers, DHCP and DNS etc.

Don’t use security groups you already have in your environment, create new groups. This might seem like it adds an extra complexity and more groups. However, if you botch your permissions on a group you are using for another function its not going to end well. If you later need to reverse changes or delete the group you can without fear of affecting other functionality.

Create a group for the help desk ie ‘IT Helpdesk’ for 1 st line staff. This should be used for password resets and group modifications etc.

Create a group for 2nd line support ie, ‘2nd line IT Support’. This should be used for all of the above including all other additional user account modification activities.

You may want to combine the first two groups into just one ‘IT Support’ group for smaller IT Teams. The point here really is to split out the duties so your helpdesk staff don’t have Domain Admin rights, and you’re not running elevated domain rights on your daily laptop/desktop, the principle of least privilege first should apply here. Only give the minimum required, no more.

Create a group for full Admins/3rd line support ie ‘3rd line IT Support’. This should effectively be used for all of the above tasks and any additional.

Keep the below points in mind when using the Delegation of Control wizard in Active Directory:

  • Always delegate permissions on a new AD group, not on one that is already in use.
  • Once applied to an OU there is no wizard to undo the changes. Changes will need to be manually undone.
  • You can re-run the delegation wizard again on the same OU to add additional permission, just not take away.
  • You can remove a newly added group from the security tab of an OU if needs be, (effectively reversing the changes).
  • Avoid setting permissions on individual user objects even if there is only one user, add the user to a group and make the changes on the group not the user. This is in case you need to revert changes. In addition to this you can always remove the user from the group.

Lets walk though an example.

As an example of how we can achieve this lets walk through the below lab. In this example we are going to delegate control in AD for password resets and user group changes for the ‘IT Helpdesk’ group, so that members of this group can carry out these tasks on domain users in the HR OU.

Right click on the HR OU and select the top option ‘Delegate Control…’ the wizard should pop up like below:

AD Delegation of Control Wizard

Select Next, and you will be prompted to add the group you want to grant the permissions too. In this case we will grant permissions to ‘IT Helpdesk’ as below:

AD Delegation of Control Wizard add group

Select Next. Now we will add the specific permissions that we want the ‘IT Helpdesk’ to have on users in the HR OU.

In this instance we are going to select the top five check boxes as these are a reasonable set of tasks that we would want our helpdesk staff to be able to perform. This obviously may be different from organisation to organisation depending on size and separation of duties. We will go with this as an example for now. Microsoft makes this very easy by grouping these tasks together in the form of the check boxes. We can go more granular than this if needs be,  however for now we will continue with the pre-defined options.

AD Delegation add permissions

Select Next, then Finish.

You can verify your permissions be selecting the OU right clicking on properties, selecting the ‘Security’ tab, the group in question should have ‘special permissions’, select advanced, your will then be able to view the permissions. The top four Access Control Entries (ACE) will have been added.

AD Delegation permissions

In addition to this, select the ‘Effective Access’ tab, add the group and verify that the four permissions Create/delete Group objects and Create/delete User objects have a green tick next to them. (they are spread out, so scroll down)

AD Delegation permissions

AD Delegation permissions

As opposed to an alternative OU such as our ‘Admin’ OU which doesn’t have any delegation on it. The default permissions are as below:

AD Delegation permissions

AD Delegation permissions

 

The next thing to do is test the effective permissions to ensure the new ‘adm’ users of the ‘IT Helpdesk’ group can for example change a password of a user under the HR OU. It also worth testing this on a user account that isn’t in that OU so you can see the difference and error message that you will receive if you don’t have permission.

Et voila. I hope this helps. Remember test test test.

Privilege Separation please…

No please don’t run ‘Domain Admin’ for daily tasks like reading email… use separate accounts and enforce privilege separation.

Separate user accounts should be used to perform Administrative tasks in Active Directory. Its far from ideal to be logged in to your daily work laptop as a Domain Admin to perform your business as usual tasks like reading email and surfing Facebook at lunchtime…

Ideally we want privilege separation for our accounts. Split out standard domain user accounts for standard non privilege duties like reading email and using Microsoft Word, then have separate admin accounts ie ‘Adam-adm’ for administrative privileges. These admin accounts can then be used to rdp directly to a separate management server which has the Remote Server Administration Tools installed for programs like AD Users and Computers, DHCP and DNS.

In Addition to having separate Admin accounts, don’t automatically add the account to the ‘Domain Admins’ group if it doesn’t need this level of privilege, (it most likely doesn’t) . Use the principle of least privilege first and delegate control using the AD Delegation of Control wizard. Its pretty straightforward to use. I wrote an article about delegation of control in Active Directory here.

Creating realistic test user accounts in Active Directory test lab.

How to create realistic test user accounts in Active Directory test lab. Often when I’m working through certain lab scenarios I will want multiple realistic test users in Active Directory to work with. Yeah sad I know. However, for example if searching through users in PowerShell, modifying permissions or pentesting techniques like RID cycling etc you would ideally want realistic users with pre-populated data to search through. Sure you can create a quick script to create a bunch of accounts like user1 user2 user3, with Address1 Address2 and Address3 however I prefer to have a realistic environment to work in. After all, by working in a lab ultimately we are trying to mimicking an Enterprise environment or order to test something your working on. I wanted a quick simple was to do this. I came across this website by Helge Klein which does the trick. A PowerShell script to create realistic users with proper account names, first name, surname, address etc. In order to create realistic accounts you do require the information such as names and addresses which Helge supply’s in the form of a few text files.

You need to set a few variables at the beginning of the script:

Creating realistic test user accounts in Active Directory

Note you can set the user count variable $userCount to the amount of users you want in your lab.

Running the script results in the following:

Creating realistic test user accounts in Active Directory 2

And as we can see in ‘Active Directory Users and Computers’ we have our test users:

Creating realistic test user accounts in Active Directory 3

As always familiarise your self with the script be comfortable with what its doing! enjoy!

Active Directory Authentication for Cisco Devices – Routers and Switches

Cisco, AAA, Radius, Active Directory, Windows Server 2012 R2, NAP role, NPS its all going on!

Active Directory Authentication for Cisco DevicesJust a quick note to reference the following video on YouTube. This video demonstrates setting up Active Directory Authentication for Cisco Devices, such as Routers and Switches etc. This is using AAA on the router and RADIUS through the Network Access Policy (NAP) role in Windows Server 2012 R2, this in turn enables a Network Policy Server (NPS). The Windows server (the Radius Server) is registered in Active Directory which allows it to query the domain it is connected too for authenticating users in Active Directory to the Cisco IOS devices. You can control who has access to various network devices through rules created on the NPS. This can in turn be achieved in Active Directory via groups, binding those groups to privilege levels to pass through to deifferent devices.

For example you could have a group in AD called Network Admins which is tied to a prilivelge level 15 group rule in the NPS configuration. This rule would pass through the privilege level 15  setting through to the IOS configuration. Members of this AD group upon succesful authentication would then be granted privilege level 15 access on the router or switch.