Chapter Title: Active Directory

NAME:Gayatri.Thota

ROLL NO:226W1A43A8

BRANCH:CSE(AI)

Topic: Install OpenVPN Lab Ex. No: 1

1)Lab Scenario: (Problem Statement/Case Study/Use cases)

Installing OpenVPN for the attack, access and management.

2)Lab Objective: (Objective of the Lab Exercise)

To perform AD management and Directories, OpenVPN should be installed.

3)Lab Environment: (OS/Tools to be used)

Try Hack Me

4)Lab Tasks: (Questions)

To perform this, we need 7 days of Streak in Try Hack Me.

\5)Steps to achieve the task: (Windows)

1. Download and Install OpenVPN GUI

2. From THM(Try Hack Me), download the configuration file.
3. Import the generated file (ex.: filename.ovpn) into OpenVPN and click connect.
4. Once connected, try pinging 10.10.10.10 in command prompt. Data transfer communications
should happen. So that the local mechine is properly configured via OpenVPN.
5. After connecting, start the Mahine in THM.
 Chapter Title: Active Directory

Topic: User and Group Management Lab Ex. No: 2

1)Lab Scenario: (Problem Statement/Case Study/Use cases)

You are an Admin and you are tasked to manage Users and Groups

2)Lab Objective: (Objective of the Lab Exercise)

Your first task as the new domain administrator is to check the existing AD OUs and users, as
some recent changes have happened to the business. You have been given the following
organizational chart and are expected to make changes to the AD to match it:

3)Lab Environment: (OS/Tools to be used)

Try Hack Me – AD

4)Lab Tasks: (Questions)

To perform this, we need 7 days of Streak in Try Hack Me.

5)Steps to achieve the task:

Your first task as the new domain administrator is to check the existing AD OUs and users, as
some recent changes have happened to the business. You have been given the following
organisational chart and are expected to make changes to the AD to match it:
Deleting extra OUs and users
The first thing you should notice is that there is an additional department OU in your current
AD configuration that doesn't appear in the chart. We've been told it was closed due to
budget cuts and should be removed from the domain. If you try to right-click and delete
the OU, you will get the following error:

By default, OUs are protected against accidental deletion. To delete the OU, we need to
enable the Advanced Features in the View menu:
This will show you some additional containers and enable you to disable the accidental
deletion protection. To do so, right-click the OU and go to Properties. You will find a checkbox
in the Object tab to disable the protection:
Be sure to uncheck the box and try deleting the OU again. You will be prompted to confirm
that you want to delete the OU, and as a result, any users, groups or OUs under it will also be
deleted.

After deleting the extra OU, you should notice that for some of the departments, the users in
the AD don't match the ones in our organisational chart. Create and delete users as needed to
match them.

6)Output:

Screenshot for the traffic (Requests and Responses) captured

 Chapter Title: Active Directory

Topic: Managing Users in AD Lab Ex. No: 3

1)Lab Scenario: (Problem Statement/Case Study/Use cases)

You are tasked to give an user delegate control over another OU

2)Lab Objective: (Objective of the Lab Exercise)

To give a user cross functional access for the data management / data process functions.

3)Lab Environment: (OS/Tools to be used)

Try Hack Me – AD

4)Lab Tasks: (Questions)

To perform this, we need 7 days of Streak in Try Hack Me.

5)Steps to achieve the task:

Your first task as the new domain administrator is to check the existing AD OUs and users, as
some recent changes have happened to the business. You have been given the following
organisational chart and are expected to make changes to the AD to match it:
Deleting extra OUs and users
The first thing you should notice is that there is an additional department OU in your current
AD configuration that doesn't appear in the chart. We've been told it was closed due to
budget cuts and should be removed from the domain. If you try to right-click and delete
the OU, you will get the following error:

By default, OUs are protected against accidental deletion. To delete the OU, we need to
enable the Advanced Features in the View menu:
This will show you some additional containers and enable you to disable the accidental
deletion protection. To do so, right-click the OU and go to Properties. You will find a checkbox
in the Object tab to disable the protection:

Be sure to uncheck the box and try deleting the OU again. You will be prompted to confirm
that you want to delete the OU, and as a result, any users, groups or OUs under it will also be
deleted.

After deleting the extra OU, you should notice that for some of the departments, the users in
the AD don't match the ones in our organisational chart. Create and delete users as needed to
match them.
Delegation
One of the nice things you can do in AD is to give specific users some control over some OUs.
This process is known as delegation and allows you to grant users specific privileges to
perform advanced tasks on OUs without needing a Domain Administrator to step in.

One of the most common use cases for this is granting IT support the privileges to reset
other low-privilege users' passwords. According to our organisational chart, Phillip is in
charge of IT support, so we'd probably want to delegate the control of resetting passwords
over the Sales, Marketing and Management OUs to him.

For this example, we will delegate control over the Sales OU to Phillip. To delegate control
over an OU, you can right-click it and select Delegate Control:

This should open a new window where you will first be asked for the users to whom you want
to delegate control:

Note: To avoid mistyping the user's name, write "phillip" and click the Check Names button.
Windows will autocomplete the user for you.
Click OK, and on the next step, select the following option:
Click next a couple of times, and now Phillip should be able to reset passwords for any user in
the sales department. While you'd probably want to repeat these steps to delegate the
password resets of the Marketing and Management departments, we'll leave it here for this
task. You are free to continue to configure the rest of the OUs if you so desire.

Now let's use Phillip's account to try and reset Sophie's password. Here are Phillip's
credentials for you to log in via RDP:

Username phillip
Password Claire2008

Note: When connecting via RDP, use THM\phillip as the username to specify you want to log
in using the user phillip on the THM domain.While you may be tempted to go to Active
Directory Users and Computers to try and test Phillip's new powers, he doesn't really have
the privileges to open it, so you'll have to use other methods to do password resets. In this
case, we will be using Powershell to do so:

WindowsPowerShell(As Phillip)
PS C:\Users\phillip> Set-ADAccountPassword sophie -Reset -NewPassword (Read-
Host -AsSecureString -Prompt 'New Password') -Verbose

New Password: *********

VERBOSE: Performing the operation "Set-ADAccountPassword" on target
"CN=Sophie,OU=Sales,OU=THM,DC=thm,DC=local".

Since we wouldn't want Sophie to keep on using a password we know, we can also force a
password reset at the next logon with the following command:

WindowsPowerShell(as Phillip)
PS C:\Users\phillip> Set-ADUser -ChangePasswordAtLogon $true -Identity sophie
-Verbose

VERBOSE: Performing the operation "Set" on target

"CN=Sophie,OU=Sales,OU=THM,DC=thm,DC=local".

Log into Sophie's account with your new password and retrieve a flag
from Sophie's desktop.

Note: When connecting via RDP, use THM\sophie as the username to specify you want to log
in using the user sophie on the THM domain.
 Chapter Title: Active Directory

Topic: Managing Computers in AD Lab Ex. No: 4

1)Lab Scenario: (Problem Statement/Case Study/Use cases)

You are tasked to Manage the Computers by assigning new tasks

2)Lab Objective: (Objective of the Lab Exercise)

To create a new OUs and Manage the Computers allotted to different groups

3)Lab Environment: (OS/Tools to be used)

Try Hack Me – AD

4)Lab Tasks: (Questions)

To perform this, we need 7 days of Streak in Try Hack Me.

5)Steps to achieve the task:

By default, all the machines that join a domain (except for the DCs) will be put in the
container called "Computers". If we check our DC, we will see that some devices are already
there:
We can see some servers, some laptops and some PCs corresponding to the users in our
network. Having all of our devices there is not the best idea since it's very likely that you want
different policies for your servers and the machines that regular users use on a daily basis.

While there is no golden rule on how to organise your machines, an excellent starting point is
segregating devices according to their use. In general, you'd expect to see devices divided
into at least the three following categories:

1. Workstations
Workstations are one of the most common devices within an Active Directory domain. Each
user in the domain will likely be logging into a workstation. This is the device they will use to
do their work or normal browsing activities. These devices should never have a privileged
user signed into them.

2. Servers

Servers are the second most common device within an Active Directory domain. Servers are
generally used to provide services to users or other servers.

3. Domain Controllers

Domain Controllers are the third most common device within an Active Directory domain.
Domain Controllers allow you to manage the Active Directory Domain. These devices are
often deemed the most sensitive devices within the network as they contain hashed
passwords for all user accounts within the environment.

Since we are tidying up our AD, let's create two separate OUs
for Workstations and Servers (Domain Controllers are already in an OU created by
Windows). We will be creating them directly under the thm.local domain container. In the
end, you should have the following OU structure:

Now, move the personal computers and laptops to the Workstations OU and the servers to
the Servers OU from the Computers container. Doing so will allow us to configure policies for
each OU later.
 Chapter Title: Active Directory

Topic: Group Policies in AD Lab Ex. No: 5

1)Lab Scenario: (Problem Statement/Case Study/Use cases)

For each OU, we have to deploy separate policies and rules.

2)Lab Objective: (Objective of the Lab Exercise)

To deploy individual policies for each OU and we can push different configurations and security
baselines to users depending on their department.

3)Lab Environment: (OS/Tools to be used)

Try Hack Me – AD

4)Lab Tasks: (Questions)

To perform this, we need 7 days of Streak in Try Hack Me.

5)Steps to achieve the task:

Windows manages such policies through Group Policy Objects (GPO). GPOs are simply a
collection of settings that can be applied to OUs. GPOs can contain policies aimed at either
users or computers, allowing you to set a baseline on specific machines and identities.

To configure GPOs, you can use the Group Policy Management tool, available from the start
menu:
The first thing you will see when opening it is your complete OU hierarchy, as defined before.
To configure Group Policies, you first create a GPO under Group Policy Objects and then link
it to the OU where you want the policies to apply. As an example, you can see there are some
already existing GPOs in your machine:
We can see in the image above that 3 GPOs have been created. From those, the Default
Domain Policy and RDP Policy are linked to the thm.local domain as a whole, and
the Default Domain Controllers Policy is linked to the Domain Controllers OU only.
Something important to have in mind is that any GPO will apply to the linked OU and any sub-
OUs under it. For example, the Sales OU will still be affected by the Default Domain Policy.

Let's examine the Default Domain Policy to see what's inside a GPO. The first tab you'll see
when selecting a GPO shows its scope, which is where the GPO is linked in the AD. For the
current policy, we can see that it has only been linked to the thm.local domain:

As you can see, you can also apply Security Filtering to GPOs so that they are only applied to
specific users/computers under an OU. By default, they will apply to the Authenticated
Users group, which includes all users/PCs.

The Settings tab includes the actual contents of the GPO and lets us know what specific
configurations it applies. As stated before, each GPO has configurations that apply to
computers only and configurations that apply to users only. In this case, the Default Domain
Policy only contains Computer Configurations:
Feel free to explore the GPO and expand on the available items using the "show" links on the
right side of each configuration. In this case, the Default Domain Policy indicates really
basic configurations that should apply to most domains, including password and account
lockout policies:
Since this GPO applies to the whole domain, any change to it would affect all computers. Let's
change the minimum password length policy to require users to have at least 10 characters in
their passwords. To do this, right-click the GPO and select Edit:

This will open a new window where we can navigate and edit all the available configurations.
To change the minimum password length, go to Computer Configurations -> Policies -
> Windows Setting -> Security Settings -> Account Policies -> Password
Policy and change the required policy value:
As you can see, plenty of policies can be established in a GPO. While explaining every single of
them would be impossible in a single room, do feel free to explore a bit, as some of the
policies are straightforward. If more information on any of the policies is needed, you can
double-click them and read the Explain tab on each of them:
GPO distribution
GPOs are distributed to the network via a network share called SYSVOL, which is stored in
the DC. All users in a domain should typically have access to this share over the network to
sync their GPOs periodically. The SYSVOL share points by default to the C:\Windows\SYSVOL\
sysvol\ directory on each of the DCs in our network.

Once a change has been made to any GPOs, it might take up to 2 hours for computers to
catch up. If you want to force any particular computer to sync its GPOs immediately, you can
always run the following command on the desired computer:

WindowsPowerShell
PS C:\> gpupdate /force
Creating some GPOs for THM Inc.
As part of our new job, we have been tasked with implementing some GPOs to allow us to:

1. Block non-IT users from accessing the Control Panel.

2. Make workstations and servers lock their screen automatically after 5 minutes of user
inactivity to avoid people leaving their sessions exposed.

Let's focus on each of those and define what policies we should enable in each GPO and
where they should be linked.

Restrict Access to Control Panel

We want to restrict access to the Control Panel across all machines to only the users that are
part of the IT department. Users of other departments shouldn't be able to change the
system's preferences.

Let's create a new GPO called Restrict Control Panel Access and open it for editing.
Since we want this GPO to apply to specific users, we will look under User Configuration for
the following policy:
Notice we have enabled the Prohibit Access to Control Panel and PC settings policy.

Once the GPO is configured, we will need to link it to all of the OUs corresponding to users
who shouldn't have access to the Control Panel of their PCs. In this case, we will link
the Marketing, Management and Sales OUs by dragging the GPO to each of them:
Auto Lock Screen GPO

For the first GPO, regarding screen locking for workstations and servers, we could directly
apply it over the Workstations, Servers and Domain Controllers OUs we created
previously.

While this solution should work, an alternative consists of simply applying the GPO to the root
domain, as we want the GPO to affect all of our computers. Since
the Workstations, Servers and Domain Controllers OUs are all child OUs of the root
domain, they will inherit its policies.

Note: You might notice that if our GPO is applied to the root domain, it will also be inherited
by other OUs like Sales or Marketing. Since these OUs contain users only, any Computer
Configuration in our GPO will be ignored by them.

Let's create a new GPO, call it Auto Lock Screen, and edit it. The policy to achieve what we
want is located in the following route:
We will set the inactivity limit to 5 minutes so that computers get locked automatically if any
user leaves their session open. After closing the GPO editor, we will link the GPO to the root
domain by dragging the GPO to it:
Once the GPOs have been applied to the correct OUs, we can log in as any users in either
Marketing, Sales or Management for verification. For this task, let's connect via RDP using
Mark's credentials:

Username Mark
Password M4rk3t1ng.21

Note: When connecting via RDP, use THM\Mark as the username to specify you want to log in
using the user Mark on the THM domain.

If we try opening the Control Panel, we should get a message indicating this operation is
denied by the administrator. You can also wait 5 minutes to check if the screen is
automatically locked if you want.
Since we didn't apply the control panel GPO on IT, you should still be able to log into the
machine as any of those users and access the control panel.

Note: If you created and linked the GPOs, but for some reason, they still don't work,
remember you can run gpupdate /force to force GPOs to be updated.