Module 4

This module is about limiting the privileges of administrative accounts. The idea is that an
account should just have the necessary permissions to perform its tasks, nothing more.

The least-privilege administrative model approach is an important part of your defense in depth
strategy.

At the end of these exercises you will be able to identify incorrect permissions in the directory
and improve the security of domain-joined systems.

Last update - 2019-03-08

A. The mysterious permission

Scenario
As the domain administrator of Contoso, you have been called to help out in a permission
incident. This time, it is not the helpdesk complaining about their lack of permissions, it is
Norma from the security team who claims that there are, I quote: "mysterious permissions on
some users, like Alyssa Roy". So, let's see what this mystery is all about.

1. Log on to CONTOSO - DC01.

Use the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

2. Right-click on the start button and click Run. In the Run window, type dsa.msc and click
OK.
 3. In the Active Directory Users and Computers console, click the View menu and click
Advanced Features. This will enable the Security tab on the objects.
4. In the console, expand contoso.com/Accounts/Users. Double-click on Alyssa Roy.

5. In the Alyssa Roy Properties window, click the Security tab. Then click on the
Advanced button. In the list of permission entries select Vickie Fergusson Adm
(v.fergusson.adm@contoso.com).

You can see Vickie has been set here directly (the permission was not inherited from the
OU).
6. Click Remove, then click OK, and once back in the Alyssa Roy Properties window, click
OK.

At this point, you contact Norma and tell her that the mystery is solved. Someone must have
added Vickie into the security tab of Alyssa. But as soon as you tell her the good news, she tells
you about those other accounts, recently created, which also have this mysterious ACE. You’ve
decided to test it yourself.

7. In the Active Directory Users and Computers console, expand

contoso.com/Accounts/Users. Right-click on Users, click New then User. Enter the
following information:

First name TestACE

Full name TestACE
User logon name TestACE
User logon name (pre-Windows 2000) TestACE

8. Click Next. Leave all password fields blank, uncheck User must change password at
next logon and check Account is disabled. Click Next then Finish.
9. We do not need to set a password if we create a disabled user.
10. Double-click on the user you have just created and click on the Security tab. Scroll down
the list of permissions and you should see that Vickie Fergusson is here again!

You guessed it (or not, but just pretend you did). She must have been hardcoded in the default
security descriptor of the user class right in the schema. Let's check!

9. Right-click on the start button and click Command Prompt.

 10. In the command prompt, run regsvr32 schmmgmt.dll and when the RegSvr32 pop-up
appears, click OK.
11. Still in the same command prompt, run mmc. In the opening console, click File, then
Add/Remove Snap-in…. In the Add or Remove Snap-ins window, select Active
Directory Schema (the second in the list on the left) and click Add >. Then click OK.
12. Browse Active Directory Schema [dc01.contoso.com]/Classes and double-click on the
User class on the right.

13. In the user Properties window, click the Default Security tab.

14. Select Vickie Fergusson ADm (v.fergusson@contoso.com) and click Remove. Then
click OK.

Only the members of the Schema Admins group can do this modification. But as
you saw in module 3, our account is a permanent member of this group. Which is
not a good practice at all! This group should be empty all the time… Else things
such as modifications of the default security descriptors can happen!

15. Close all the windows (click No if you are asked to save the console's configuration) and
sign out of DC01.

If you are about to take a break, make sure you save your labs before!

B. Disappearing delegation
Scenario
You are the domain administrator of Contoso. This time, it is the help desk complaining that they
don't have the permissions on a specific account: Samantha Mellor. Instead of just doing the job,
you will fix the permissions and tell the helpdesk they can do theirs!

1. Log on to CONTOSO - DC01.

Use the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

2. Right-click on the start button and click Run. In the Run window, type dsa.msc and
click OK.
3. In the Active Directory Users and Computers console, browse to
contoso.com/Accounts/Users. Double-click on Samantha Mellor (we assumed you
have enabled the Advanced Features in order to be able to see the Security tab on
objects).
4. In the Samantha Mellor Properties window, click the Security tab. Then click on the
Advanced button. Scroll all the way down the list of permissions. You should see that
none of them are inherited. Somebody must have disabled the inheritance. Click the
Enable Inheritance button and click OK. A permission warning tells you that it is about
to add 66 new entries. Click Yes. Then click OK to close the Samantha Mellor
Properties window.

You tell the helpdesk you fixed the permissions and you go back to your Solitaire game that you
had to pause just for them.

Now you have two options.

1. You can wait an hour.

2. You run the following PowerShell script to simulate you waited for an hour. Right-click
on the start button and click Run. In the Run window, type powershell and click OK.
Run:

PowerShell
$rootdse = New-Object
System.DirectoryServices.DirectoryEntry("LDAP://RootDSE")
$rootdse.usepropertycache = $false
$rootdse.put("RunProtectAdminGroupsTask",1)
$rootdse.setinfo()

This is triggering the adminSDHolder protection task right now rather than the every hour
schedule.

5. In the Active Directory Users and Computers console, browse back to

contoso.com/Accounts/Users. Double-click on Samantha Mellor, click the Security
tab and click on the Advanced button.
You see that the permissions are back to what they were before you re-enabled the inheritance.
The account must be protected by the adminSDHolder.

6. In the Samantha Mellor Properties window, click the Attribute Editor tab. You see the
adminCount attribute is set to one:

Click OK.

Let's see who are the other accounts protected by the adminSDHolder.

7. In the Active Directory Users and Computers console, right-click on contoso.com then
click Find. It will open a Find Users, Contacts, and Groups window.
8. In the Find drop-down menu, change Users, Contacts, and Groups to Custom Search.
Then click on the Advanced tab and enter the following LDAP query filter
(adminCount=1) and click Find Now. You should see 31 objects. Some are users (this
includes Samantha Mellor), some are groups, some are computers (!). It does not mean
they are still protected users but they were at some point.
9. Right-click on the start button and click Run. In the Run window type
\\WIN10\C$\Tools\Scans\201810311056_Domain_Report.html. In the opening
HTML document, look for Samantha Mellor (use the CTRL+F shortcut to perform a
search in the page).
 Samantha is a member of the group DG3, which is a member of the group DG, which is a
member of the Domain Admins group which is protected by the adminSDholder.

10. Close all windows and sign out of DC01.

If you are about to take a break, make sure you save your labs before!

C. Create reports on your delegation model

Scenario
You are the domain administrator of Contoso. You just got out of a meeting with the identity and
security team during which they asked you about your documented delegation model for OUs
and objects in the EMEA domain. Well, you know it. Helpdesk knows it. To some extent, we all
know it. But it isn't really "documented". In order to tackle this request, you decide to first create
a report of all delegations set in contoso.com.

1. Log on to CONTOSO - DC01.

Use the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

2. Right-click on the start button and click Run. In the Run window, type powershell.
3. In the PowerShell console, run the following

PowerShell
Set-Location \Tools\DACL
.\ADACLScan.ps1

4. In the AD ACL Scanner window, click List Domains. In the Select a domain window,
click DC=emea,DC=contoso,DC=com and click OK. Back in the Connect tab, click
Connect. In the Nodes section, click DC=emea,DC=contoso,DC=com. By default, the
Advanced/Scan Options tab is selected. In the Scan Depth section, click Subtree. In the
View in report section, check Skip Default Permissions and Skip Protected
Permissions. Then click Run Scan.
This report shows you all custom delegations (not in the default security descriptors of
the OU class). Some of them are actually made by the AD installation, the others are the
result of manual operations. For example:

Close the Report.

5. It looks pretty cool. You decide to use it on contoso. In the Connect tab, click List
Domains. In the Select a domain window, click DC=contoso,DC=com and click OK.
Back in the Connect tab, click Connect. In the Nodes section, click
DC=contoso,DC=com. In the Output Options section, select the option CSV File and
click Run Scan. The result will be saved in C:\Tools\DACL:

Do not close the AD ACL Scanner window.

6. Right-click on the start button and click Run. In the Run window, type dsa.msc and click
OK.
7. In the Active Directory Users and Computers console, browse to contoso.com/_Admins
and right-click on the Service Accounts OU and click Delegate control. In the
Delegation of Control Wizard window, click Next. Click Add…, type Help Desk and
click Check Names then OK. Back in the Delegation of Control Wizard window, click
Next. Check the first task Create, delete, and manage user accounts and click Next.
Then click Finish.
8. Return to the AD ACL Scanner window, in the Compare section (right side of the
window), check Enable Compare. Then click on Select Template, pick the csv file you
created before (in C:\Tools\DACL) and click Open. Check the Use nodes from template
box, then click Run Scan. You should see the delta in yellow:

9. Close all windows and sign out of DC01.

If you are about to take a break, make sure you save your labs before!

D. Mitigate lateral movement

Scenario
As seen in modules 1 and 2, lateral movement is a common technique used by attackers to spread
in the environment. As the domain administrator of Contoso, you need to do your due diligence
and limit this type of technique as much as you can. The priority item brought up by Norma (by
now, she is your new best friend) is to deploy LAPS. So, let's do it!

1. Log on to CONTOSO - DC01.

Use the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

2. Open File Explorer and browse to the folder C:\Tools\LAPS. Double-click on

LAPS.x64. When the Local Administrator Password Solution Setup window appears,
click Next. Check I accept the terms in the license agreement without actually reading
the said license agreement and click Next. Expand the AdmPwd GPO Extension
dropdown menu and click Entire feature will be unavailable. Expand the drop-down
menu on Management Tools and then click Entire feature will be installed on local
hard drive. This should look like this:

Click Next and click Install. Once the installation is over, click Finish.

3. Right-click on the start button and click Run. In the Run window, type powershell.
4. In the PowerShell console, run the following

PowerShell
Import-module AdmPwd.PS
Update-AdmPwdADSchema
 5. You will create a Workstations OU and enable LAPS just for this OU and grant only
Norma access to them. In the PowerShell console, run the following:
6. New-ADOrganizationalUnit -Name Workstations
7. Set-AdmPwdComputerSelfPermission -OrgUnit
"OU=Workstations,DC=contoso,DC=com"
Set-AdmPwdReadPasswordPermission -OrgUnit
"OU=Workstations,DC=contoso,DC=com" -AllowedPrincipals
"CONTOSO\NormaLuser"

We will add the binaries of LAPS in SYSVOL because we do not have a tool to deploy MSI
packages in our lab.

6. Right-click on the start button and click Run and click Command Prompt (admin). Run
the following commands:
7. mkdir C:\Windows\SYSVOL\domain\LAPS &
copy C:\Tools\LAPS\LAPS.x64.msi C:\Windows\SYSVOL\domain\LAPS

8. Right-click on the start button and click Run. In the Run window, type gpmc.msc.
9. Browse to Forest: contoso.com/Domains/contoso.com and right-click on the
Workstations OU. Click Create a GPO in this domain, and Link it here…. In the
New GPO window, enter the name LAPS Deployment and Configuration and click
OK.
10. Still in the Group Policy Management console, browse to Forest:
contoso.com/Domains/contoso.com/Group Policy Objects then right-click on the GPO
LAPS Deployment and Configuration and click Edit.
11. In the Group Policy Management Editor console, browse to Computer
Configuration/Policies/Software Settings. Right-click on Software installation and
click New then Package. Enter the File name:
\\contoso.com\SYSVOL\contoso.com\LAPS\LAPS.x64.msi and click Open. Leave the
default setting (Assigned) and click OK.
It might take a little while (a few seconds) and you should see your package listed:

12. Still in the Group Policy Management Editor console, browse to Computer
Configuration/Policies/Administrative Templates/LAPS. Double-click on Password
 settings, enable the setting and in the Comment section type: These settings were
approved by Norma Luser. Then enter the following options:

Password Complexity Large Letters

Password Length 8
Password Age (Days) 1

13. (Yes, this is a very weird policy, but eh! That's a lab!) Click OK.

14. Double click on Name of administrator account to manage, click Enabled and in the
Options section, type LocalAdmin (that's the name of the local admin account on your
workstations as the default administrator account was disabled) then click OK.

15. Double-click on Enable local admin password management, click Enabled and OK.
Then close the Group Policy Management Editor console.
16. Now we are going to move Norma's computer into the new OU. Right-click on the start
button and click Run. In the Run window, type dsa.msc. Expand
contoso.com/Computers, right-click on WIN10 and click Move. In the Move window,
select the Workstations OU and click OK.
17. Now we ask Norma to update GPO and restart her machine. Log on to CONTOSO -
WIN10.

Use the following credentials:

Username CONTOSO\NormaLuser
Password Pa$$w0rd

18. Right-click on the start button and click Run. In the Run window, type cmd /k
gpupdate /force and click OK. Note the message from gpupdate. Once the machine
has restarted, use the following credentials to connect:

Username CONTOSO\NormaLuser
Password Pa$$w0rd

19. Right-click on the start button and click Run. In the Run window, type cmd /k
gpupdate /force.
20. We are forcing application of policies again to force the password to be changed
now. In a real production deployment, you would just wait until policies get
refreshed. But here, we are not patient!
21. Right-click on the start button and click Shut down or sign out and click Restart.
22. Once the machine has restarted, log back on to CONTOSO - DC01.

Use the following credentials:

 Username CONTOSO\Administrator
Password Pa$$w0rd

23. Right-click on the start button and click Run. In the Run window, type powershell.
24. In the PowerShell console, run Get-AdmPwdPassword -ComputerName WIN10.
You can continue and play with the other options and commands of LAPS if you'd like.

This was the last exercise for this module.

Thank you for implementing a safer delegation model!

See you in the next module!