The IT Professional's Guide to Active Directory and Microsoft Entra ID: Authentication, Authorization, and Group?Policies
Colton Hicks
Cybersecurity Professional | SOC Analyst | Passionate About Cloud Infrastructure, Incident Response & Vulnerability Management
IT professionals guard the confidentiality of an organization’s most valuable resources.
Managing a company’s resources is a lot like protecting a garden near a busy street. Just like a gardener wouldn’t want strangers wandering through flowerbeds and trampling on their plants, we don’t want unauthorized users poking around our systems. That’s how we end up with critical risks?—?data breaches, financial loss, and reputational damage.
Active Directory and Microsoft Entra ID are the digital gates that decide who can enter and who must be kept out.
They’re both Identity and Access Management (IAM) systems that preserve the confidentiality of our network resources.
These systems determine who enters by authenticating user identities. They also ensure the right level of access by authorizing roles and permissions. And we, the gatekeepers, are responsible for setting up, monitoring, and adjusting these access controls to match the ever-evolving needs of an organization.
In this project, I’ll walk through the nuts and bolts of common IT helpdesk tasks for Active Directory and Microsoft Entra ID.
Active Directory & Microsoft Entra ID: The Brains Behind Your Identity and Access Management
Active Directory is a Microsoft Windows database that contains users, computers, groups and other network objects.
Think of it as the brain of an organization’s on-premise Identity and Access Management system. It organizes and processes information to maintain the confidentiality of our systems. And it can also enforce various computer or user configurations across the network (a task called Group Policy Management).
Active Directory can only function when it’s running on a Domain Controller (DC).
A Domain Controller is the main server in charge of enforcing Active Directory’s access controls and configurations across the network.
It’s like the central nervous system, passing signals between Active Directory (the brain) and the network resources. These resources?—?like servers, computers, and databases?—?are like the body’s organs that carry out essential tasks. And, much like the human body, these resources must be connected under the same network. This is called “the domain.”
Being on the same domain is like saying everything’s connected under one network, working together like the biological parts nested within the human body, each doing its job to keep things running smoothly.
Let’s say someone’s trying to access a Windows Workstation.
The Domain Controller receives the logon attempt and checks the username and password against the Active Directory database. If it’s correct, access is granted based on the user’s role. And all of this happens without the user knowing.
Without Active Directory, we wouldn’t have a centralized way to authenticate and authorize user access across the domain.
But now, as the world shifts to cloud environments, Microsoft Entra ID steps in as an important player.
Entra ID is an Azure service that manages users, groups, and access to cloud resources. Think of Entra ID as the brain of an organization’s cloud-based Identity and Access Management (IAM) system. It’s the cloud counterpart to Active Directory, but with broader capabilities to manage identities across various cloud services and applications. We can even synchronize on-premise Active Directory with Entra ID to create a hybrid environment.
However, that’s beyond the scope of this lab.
Now that we have a high-level understanding of Active Directory and Entra ID, we’re ready to get our hands dirty. We’ll walk through a project where we:
Let’s get started.
Creating a Traditional Active Directory Lab Environment in Azure?Cloud
We’ll begin by setting up our lab environment in Azure.
We’ll start by spinning up a Windows Server 2019 Datacenter and a Windows Workstation Virtual Machine (VM). Then, we’ll promote the Datacenter to a Domain Controller, which will automatically install Active Directory on it. Once that’s in place, we’ll configure our lab environment to connect our Domain Controller and Windows Workstation under the same domain. I’ll name it "ADlab(.)com" for simplicity.
Here’s what our setup will look like:
Let’s start by creating our Domain Controller.
This will give us the ability to manage all user logins, permissions, and access to network resources from one place. To do this, we’ll need to deploy a Windows Server 2019 Datacenter. This is a version of Microsoft’s server operating system that supports enterprise-level management (we can’t install Active Directory on a Windows 10 Pro Workstation).
Go to the “Virtual Machines” service in Azure and create a new one.
Create a new resource group within the project details?—?I’ll name mine “RG-AD-Lab.”
Within the instance details, give the VM a name like “DC01” to indicate it's the Domain Controller. Then make sure the Image is set to Windows Server 2019 Datacenter.
We’ll need a decent amount of processing power to run Active Directory.
So let’s choose a VM size that has at least 2 vCPUs. This will make performance a bit faster. Continue by giving the Administrator account a username and password.
Disk type also affects VM performance.
For this lab, we don’t need a high-cost option like a Premium SSD. That would be overkill. In a real setup for an organization, a Premium SSD would make sense since it can handle many operations per second.
But here, to save money, we’ll use a Standard HDD.
For our Domain Controller and Windows Workstation to talk to each other, they must be on the same virtual network.
This allows our resources to connect under the same domain later. So let’s create a new virtual network for our Domain Controller (and our future Windows Workstation).
Review and create the Windows Server 2019 Datacenter
Next we’ll create a Workstation using Windows 10 Pro. This Virtual Machine will be added to our domain and connected to our Domain Controller. The process is mostly the same as our Domain Controller deployment, with a few small changes.
Put the Windows Workstation in the same resource group and region as the Domain Controller, but give it a unique name.
We’ll also want to make sure the Windows 10 Pro image is selected.
We can use the same VM size as our Domain Controller.
Give the administrator account a username and password.
Feel free to choose the Standard HDD disk if you want to save money.
Then we’ll make sure to put the Windows Workstation in the same virtual network as the Domain Controller.
Review and create the Windows Workstation.
Now we’ve got both VMs up and running.
It’s time to promote our Windows Server 2019 Datacenter to a Domain Controller so Active Directory gets installed on it.
To do this, we need to install Active Directory Domain Services onto our Datacenter Server. This gives us the features needed to run Active Directory and lets us promote the server to a Domain Controller. So let’s log into our DC01 VM using RDP. Then once we’re inside, open up the Server Manager.
Go to “Manage” and select “Add Roles and Features.”
Follow the instructions for the first couple sections and keep the default settings.
When we get to “Server Selection,” select the only server available?—?our Domain Controller.
Once we get to “Server Roles,” be sure to click Active Directory Domain Services.
This adds all the features needed to use Active Directory on our server.
We’ll install it once we get to the Confirmation section.
Once that’s complete, we’ll promote our server to a Domain Controller.
Click the hypertext in the Results section.
Now we’ll add a new forest and create a root domain.
Before we do that, it’s important to understand a few key IT concepts?—?domains, trees, and forests. Let’s start with the first one listed.
A domain is a group of computers, users, and devices that share the same rules (like password policies or file access). And when we create a root domain in Active Directory, we’re setting up a unique namespace for our organization. Think of it like a neighborhood with HOA. Each house in the neighborhood represents a computer or device, and the HOA rules represent the policies and permissions that users must follow.
We can combine domains to create a “tree.”
A tree is where multiple domains trust each other and share the same naming convention.
It’s like a community of different neighborhoods that share resources. A forest is a collection of trees, or groups of domains, which may or may not trust each other but exist under the same management. A forest is like a city made up of various communities. The forest is the top-level container in Active Directory, forming the foundational ecosystem that must exist before we can establish a neighborhood (or domain) within it.
Once we establish a forest, creating the root domain forms the initial “neighborhood” from which other domains or trees can emerge.
So let’s add a new forest and name the root domain ADlab.com?.
Next we’ll add the DSRM (Directory Services Restore Mode) password.
This is crucial for Active Directory management and recovery. We’d need it to start the server in Directory Services Restore Mode for maintenance or recovery. It’s also required to uninstall Active Directory from the server.
Set a DSRM password.
We’ll skip DNS settings for now and handle that later.
Let’s keep the files on the C: Drive. In a production environment, using a separate disk for redundancy would be smart.
But here, in a lab setting, it’s unnecessary.
Now let’s install Active Directory Domain Services and promote the server to a Domain Controller.
The server will restart once the installation is finished.
Now that we’ve promoted our server to a Domain Controller, we need to make key configuration changes in Azure.
We’ll start by setting the private IP address of our Domain Controller to “static.” By default, it’s set to dynamic, which means the IP can change and potentially disconnect from the domain.
Imagine our virtual network is like a company with multiple branch offices. A static IP is like assigning each office a permanent address, ensuring easy and reliable communication. If the address kept changing?—?like with dynamic IPs?—?then communication breaks down between the offices.
A static IP keeps the Domain Controller accessible at the same IP address. To make this change, we’ll need to access the Network Interface Card (NIC) for DC01 in Azure.
The NIC is responsible for the VM’s network connectivity, so this is where we’ll adjust the IP settings.
Under IP configurations, set the private IP address to “static.”
Save it.
Keep in mind, we won’t be able to connect the Windows Workstation and Domain Controller unless both have static private IP addresses.
So let’s go ahead and repeat the process for our Windows Workstation.
Next we’ll ensure all our network resources can find Active Directory on the network.
We’ll do this by adding the Domain Controller’s private IP address to our virtual network as a custom DNS. Let’s return to our branch office analogy.
Think of DNS (Domain Name System) as the company’s internal directory. It translates branch office names into their addresses, making it easy to locate and communicate with them. This is especially helpful if they’re using permanent addresses. Similarly, DNS translates domains like ADlab(.)com into IP addresses that computers use to locate each other. Setting up our virtual network to use the Domain Controller's DNS ensures all our devices can find Active Directory.
So in other words, when the Windows Workstation looks for Active Directory, the DNS will direct it to the Domain Controller’s private IP address.
Let’s take note of DC01’s private IP address.
Now let’s go to our virtual network in Azure.
We’ll want to add a custom DNS server and add the Domain Controller’s private IP address:
From now on, when computers need to find each other or log into Active Directory, they’ll ask the Domain Controller’s DNS. It contains all the information about our Active Directory setup.
We’re almost done with our lab setup.
The next step is to connect our Windows Workstation to our Domain Controller. This requires manual configuration inside the Windows Workstation VM. Start by using RDP to access the Workstation.
Navigate to “Settings”, select “Access work or school,” and click “Connect.”
A few options will appear.
Select the one that allows us to join this device to a local Active Directory Domain.
Enter our domain name and the credentials for the Domain Controller Administrator account.
Click OK. And when prompted, set the user account to administrator.
Once we restart the workstation, it’ll officially be part of our domain.
We can verify this by logging into our Domain Controller and opening up our Active Directory Users and Computers service.
We’ll see our workstation underneath “Computers.”
Everything’s set up and ready for us to go.
Active Directory 101: Understanding the Backbone of On-Premise Identity and Access Management
Before we walk through common helpdesk tasks every IT professional should know, let’s break down the basics of Active Directory.
Active Directory has two main purposes:
To fully grasp how Active Directory achieves these purposes, we need to break down the key components that enable its functionality.
There are five components that make up the backbone of Active Directory: Objects, Groups, Containers, Organizational Units (OUs), and Group Policies.
Objects are the building blocks of the network. They represent users, computers, groups, printers, shared files, and service accounts. Active Directory uses these network resources to manage access and permissions. We can also put related users, computers and other objects into the same group. This allows us to manage permissions and settings for multiple objects simultaneously. These objects and groups need to be organized into logical structures?—?much like folders?—?so we can apply special settings and rules to them. These special settings and rules are called Group Policies.
When we open our newly installed Active Directory on the Domain Controller, we’ll notice the logical structures already in place.
There are default Containers and an Organizational unit created for us.
Containers and Organizational Units (OUs) act like folders that hold, organize, and separate objects in Active Directory.
However, Containers don’t offer much control or flexibility. This is why we use Organizational Units. We can create new OUs and apply Group Policies to them?—?rules that dictate what users and computers can and can’t do. So when objects are placed in an OU, we can manage how they function.
Now the default Domain Controller OU is an exception (see image above).
It doesn’t give us much control or flexibility, much like the default Containers.
For this reason, we’ll want to create an OU structure that gives us more control over our Active Directory objects and apply Group Policies to them. We can define Organizational Units arbitrarily. But it’s common to see OUs mirror the structure of an organization, like dividing them into departments such as Marketing or Product Development. This helps us apply baseline Group Policies to entire departments. But for our purposes, we’ll keep things simple and create a basic OU structure so we can get our hands dirty with common Active Directory tasks.
Let’s begin by creating an OU that matches the name of our domain. This is standard in many on-premise Active Directory environments.
Right-click on ADlab(.)com and select a new Organizational Unit to create it.
I’ll type in the name “ADlab” and press OK.
Next we’ll create two additional OUs nested within our new “ADlab” OU?—?Domain Users and Domain Computers.
It’ll look like this when complete.
Now we can place User and Computer objects within our new OU structure.
Let’s move our Windows Workstation VM out of the default “Computers” Container and into our newly created “Domain Computers” OU. This way, we can apply group policies to our Workstation for future tasks.
Just drag-and-drop the computer object to accomplish this.
Side note: After restarting the server, the new OU structure will shift to chronological order (see image above).
Now that we’ve established the basics of Active Directory, it’s time to walk through a series of common helpdesk tasks?—?skills that every IT professional needs in their toolkit.
These tasks focus on authentication, authorization, and group policy management:
Let’s get started.
Active Directory Task #1: Create, Disable, and Delete User?Accounts
Let’s walk through how to create, disable, and delete user accounts.
Creating user accounts is essential for granting individuals access to the network and its resources. Each account authenticates a user’s identity and grants permissions based on their role in the organization. Disabling and deleting accounts are just as important, as it ensures that former employees or ex-users no longer have access to sensitive information and systems.
Let’s create one first.
Right-click on our Domain Users OU, hover over “New,” and click “User.”
A new user object box will pop up.
Provide a first name, last name, and username.
Click “next,” then go ahead and assign a password for the user account.
Keep the default settings.
Once we’re finished, you’ll see the user added to the Domain Users Organizational Unit (OU).
New users are also added to the Domain Users security group automatically. This will matter later.
Most companies have policies for deleting user accounts.
Take, for example, when an employee is terminated from their job. It’s common to block their access to the network right away. But we might want to keep their account in Active Directory for 30 days. Why? Maybe for compliance, auditing, or just in case we need to restore their access. That’s why it’s best practice to disable the account instead of immediately deleting it.
Let’s execute this company policy with our John Doe user.
We’ll create a new OU called “Disabled Users.”
Next, disable the John Doe user account.
All we need to do is right-click the user object and select “Disable Account.”
Now that it’s disabled, we can drag the User object into the Disabled Users OU.
A warning will pop up asking for confirmation. Rest assured, nothing bad will happen here, so click “Yes” to move the object.
We’ve disabled the dummy user account and moved it to the Disabled Users OU.
Fast forward 30 days. John Doe’s been gone long enough, and company policy tells us it’s time to delete the account. So let’s remove all traces of access.
Just right-click on the user account and select “Delete.”
A warning will pop up asking if we actually want to delete the User. Click “Yes.”
We’ve successfully walked through the steps to create, disable, and delete a user account.
Active Directory Task #2: Reset Passwords for User?Accounts
One of the most frequent IT helpdesk tasks is resetting passwords.
A password reset lets users regain access if they forget their password or need to update it for security reasons. It’s key for user productivity and security.
To demonstrate this, I’ll create a new user account with my name.
Before we can reset the password, there are a few essential tasks we need to complete.
First, the Colton Hicks account must be granted permission to remotely access the Windows Workstation. By default, Domain Users don't get that kind of access. It’s usually reserved for admins or anyone we’ve explicitly given permission through a group policy.
If we tried to access the system right now, we’d get a message denying our access.
To fix this, we’ll create a group policy that gives the user access.
Remember, group policies are settings and rules we apply to computers or users. And Group Policy Objects (GPOs) are the specific containers where these policies are stored and managed.
We can view our policies in the Group Policy Management app on our Domain Controller.
Once we open it, we’ll see our Organizational Unit structure and the group policies linked to these OUs.
We haven’t created any GPOs yet, so we’ll only see the default ones.
In the image above, we can see two default policies underneath the Group Policy Objects folder.
This means these policies exist, but aren’t necessarily linked to any specific computers or users. Look closer, though. See how the “Default Domain Policy” is listed directly under ADlab(.)com? That means the policy is linked to the entire domain, covering every user and computer. Also, “Default Domain Controllers Policy” is linked only to the Domain Controllers OU, so it only affects the computer objects within that unit.
This setup is standard.
That being said, we want to create a new group policy that’ll give our Colton Hicks user account permission to remotely access the Windows Workstation.
So let’s create a new group policy and name it “RDP Policy.”
Now we need to define policy setting rules to give Domain Users permission for remote access.
In the previous section, I mentioned how every new user in Active Directory is automatically put in the Domain Users group. This group gives users basic access to domain resources. But this group doesn’t have RDP privileges by default. So in our RDP Policy GPO, we need to specify that Domain Users have this privilege.
Right-click the new group policy and select “Edit.”
This will open up the Group Policy Management Editor.
Let’s define the first policy setting rule. Navigate to the following location in the editor:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment
Double-click the policy named “Allow log on through Remote Desktop Services.”
This opens the policy settings.
We’ll define the settings, then click “Add User or Group.” When prompted, browse around for user and group names. Start typing “Domain Users” then click “Check Names.” Once it’s underlined?—?boom?—?you’re in! Hit OK.
Then press OK again. Click Apply, then OK to confirm the changes.
We’ve set the policy rule. All users in the Domain Users group can now log on through Remote Desktop Services.
We’ve set the rule that Domain Users can access the Windows Workstation remotely, but they still need the key to get in.
Remote Desktop Users is a built-in group that lets users log in remotely. And we need Colton Hicks to inherit those privileges, effectively giving it the keys for remote access.
We can accomplish this by adding a Restricted Group. Instead of manually adding each user to the Remote Desktop Users group, we’ll make the entire Domain Users group a member of Remote Desktop Users. This links them and allows Domain Users to inherit RDP privileges. And there’s another advantage?—?Restricted Groups ensure that only Domain Users remain in the Remote Desktop Users group.
If someone tries to alter the setup, Restricted Groups will fix it automatically. Go to the following location in the Group Policy Management Editor:
Computer Configuration\Policies\Windows Settings\Security Settings\Restricted Groups
Right-click the screen and add a group.
We’re going to want to select “Remote Desktop Users” as the group name. Then we’ll make “Domain Users” a member of this group.
It’ll look like this when we’re done:
Here’s what we just accomplished in simple terms.
These two group policy settings control who can log in remotely using RDP. Imagine we’re organizing a private party at a venue.
The Domain Users group is like the guest list?—?these are all the people who’re invited and allowed to enter the front door. However, just because someone is on the guest list, that doesn’t mean they have access to the VIP lounge (remote access). The Remote Desktop Users group is like the key to enter the VIP area. That being said, let’s say I fully trust everyone on the guest list and want to give them permission to enter the VIP lounge. I don’t want to manually give each guest a VIP key. That’ll take too long. Instead we can use a simple rule (Restricted Groups): “Everyone on the guest list (Domain Users) will be given a VIP key (Remote Desktop Users) when they enter the front door.”
The Restricted Groups setting gives every Domain User the same privileges as the Remote Desktop Users. Now our Colton.Hicks user can access the Windows Workstation remotely.
We can exit the Group Policy Management Editor.
Finally, we need to apply the RDP Policy to our Windows Workstation.
Since our RDP Policy uses computer configurations, we’ll drag it into the Domain Computers OU. This links the RDP Policy GPO to our Windows Workstation.
Press OK to link the GPO.
We’ve applied the Group Policy Object to our Windows Workstation.
But policies can take hours to kick in. To update it now, go to cmd and use the following command:
gpupdate /force
We’ll also need to force the update in our Windows Workstation.
So log into it using the admin account and run the same command. Once that’s done, my user account should have permission to remotely access the workstation.
As the image below shows, I’ve logged into my Windows Workstation with the correct user account.
Now that we’ve given the user account access to the workstation, let’s walk through resetting a user’s password.
In a real-world scenario, someone will ask for a password reset?—?maybe through a ticketing system, a call, or an email. Once we have their first and last name, we’ll use the “find” button in Active Directory Users and Computers.
This helps us locate the user account quickly.
Type in the full name and select “Find Now.”
Once we find the account, right-click on it and choose “Properties.”
Go to the “Account” tab and ask for their logon name (plus any other information required by company policy).
Then confirm their username and details match what’s on the screen.
This is good security. We need to be sure we’re resetting the right account.
Once confirmed, right-click the account again and select “Reset Password.”
From here, type in a temporary password that’s easy to share with the user.
By checking the box to change the password at the next logon, the user must set a new password that only they know.
Press OK.
Now, when we attempt to log in with the temporary password, here’s how it looks from the user’s perspective.
Notice the username shows as ADlab\Colton.Hicks. This means we're logging into the ADlab(.)com domain under the Colton Hicks user account.
We’ll get a message telling us to change the password.
At this point, we’ll enter the temporary password, along with the new password we want to switch it to.
We’ll see a final message saying our password has been changed.
The system will then log us into the Windows Workstation VM.
We’ve successfully reset a password for a user account.
Active Directory Task #3: Create Desktop Backgrounds for Every Domain?User
Our next task is setting a desktop background for every user on the domain.
This means that whenever users log in, everyone will see the same background image. It’s useful for consistency or branding?—?like a company logo or a security reminder. This way, it’s clear they’re on a computer computer and have a unified experience across all devices.
Everyone will be on the same page.
Here’s what we’ll do:
On the Domain Controller, I downloaded a basic desktop background and put it on the C: Drive.
First, I’ll create a file share so any authenticated user can access it.
A file share is like a communal folder where multiple people on a network can access the same files. This makes the background image available to all domain users. It’s also required for the Group Policy Object we’ll create, as this enables the GPO to distribute this background to every user.
In the C: Drive, right-click and select “New,” then “Folder.”
Name it “Desktop Backgrounds.”
Drag the desktop background file into the folder.
We need to share this folder so users on the network can access it.
Here’s the easiest way: Right-click the folder, choose “Properties, go to the “Sharing” tab, and select “Advanced Sharing.”
Now we can check the box for “Share this folder.”
To keep things secure, we’ll go ahead and click “Permissions” so we can add authenticated users.
Remove the default “Everyone” group and add “Authenticated Users.”
Click Apply and OK until we see the network path for the Desktop Backgrounds folder.
This is also called the UNC (Universal Naming Convention) path. It tells us exactly where the folder is located on the network.
Take note of that network path, as we’ll need it for future steps: \\DC01\Desktop Backgrounds.
We can run a quick test to see if our file share works.
If we log into our Windows Workstation, we can use the UNC path to view the desktop background image.
It works. The next step is to create a Desktop Background GPO and link it to all domain users.
Let’s go back to our Domain Controller and open Group Policy Management. We’ll link the GPO to every user in the domain by putting it under the root domain ADlab(.)com. This way, every user sees the same background, no matter the computer.
Right-click the domain and select “Create a GPO in this domain, and Link it here…”
We’ll name the GPO “Desktop Background.” Press OK.
Now let’s edit the new GPO.
Go to the following location within the Group Policy Management Editor:
User Configurations\Policies\Administrative Templates\Desktop\Desktop
Double-click the Desktop Wallpaper setting.
We’ll enable the setting.
Then we’ll specify the wallpaper name, which is the network location of the desktop background image. Use the full UNC path: \\DC01\Desktop Backgrounds\Active Directory Lab Desktop Wallpaper.png.
The "\\DC01\Desktop Backgrounds" section specifies the shared folder, while "\Active Directory Lab Desktop Wallpaper.png" specifies the file share (including its file name extension).
Apply changes and press OK.
Now run the "gpupdate /force" command on both the Domain Controller and Windows Workstation. This forces the GPO to apply right away. After that, sign out and log back in to see the updated background.
I’ll display my hostname and username to prove it worked on the Windows VM.
If we log into the Domain Controller, we’ll see that the same background is there too, giving our network a sense of unity.
Active Directory Task #4: Interactive Logon?Banner
Our next task is setting up an interactive logon banner.
This is a message that appears when a user tries to logon, usually a legal notice or a security reminder. It tells users about policies or terms before they access the system. Start by going to Group Policy Management on the Domain Controller. Like before, create a new GPO under the root domain so it applies to all computers (our Domain Controller and Windows Workstation).
Let’s name it “Interactive Logon.”
Now edit it.
Go to the following location in the Group Policy Management Editor:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options
We’re looking for the Interactive Logon settings. Specifically, we want to change the message title and text.
Let’s define the policy setting for the message title first.
This message will be displayed at the top of the interactive logon page. I’ll use the message:
“Welcome to my Active Directory Lab!”
Let’s follow the same process for the message text, which will go below the title.
I’ll use the message:
“This computer is for lab use only. Any unauthorized users are solemnly swearing that they’re up to no good.”
Close the editor.
Then run the "gpupdate /force" command for the Domain Controller and Windows Workstation.
Now, when we remotely log in to the Domain Controller or Workstation, we’ll see the logon banner.
Once we press OK, we’ll be logged into our VM as usual.
Active Directory Task #5: Deploying Software to Domain Computers
Our next task is deploying Google Chrome Enterprise to all the computers on our network using a Group Policy.
This method can be applied to any software deployment across the domain. It eliminates the need for manual installations on individual machines and ensures that each system is running the same software version. Centralized software management is efficient, minimizes errors, and guarantees consistency.
The first step is to download the MSI file for Google Chrome Enterprise.
This is a Windows Installer Package file and is required for the GPO. We can simply use the search term “Google Chrome Enterprise MSI download” and it’ll pop up in our search results.
I’ll do that now inside my Domain Controller.
Next we’ll create a new shared folder with this MSI file inside.
I’ll name it “Software”, then move the Chrome Enterprise MSI file into it.
Now we need to share this folder across the network.
Follow the same steps we took with the Desktop Backgrounds folder: Right-click the folder, select “Properties,” and navigate to the “Sharing” tab. There, select “Advanced Sharing” and check the box for “Share this folder.”
Go ahead and click “Permissions” so we can add authenticated users.
Remove the default “Everyone” group and add “Authenticated Users.”
Click Apply and OK until we see the network path for the Software folder.
Take note of the network UNC path: \\DC01\Software.
Next we’ll create a Group Policy Object that installs Chrome Enterprise onto every computer on our domain.
Head over to Group Policy Management on the Domain Controller. Right-click the root domain and select “Create a GPO in this domain, and Link it here…”
We’ll name it “Software_Deployment_Google Chrome_Enterprise.”
Let’s edit the Group Policy Object.
We can choose between a computer or user configuration. If we go with a computer configuration, the software installs after a machine reboots. If we pick user, the software installs whenever a user logs into any computer.
领英推荐
I’ll use a computer configuration for the lab.
In the Group Policy Management Editor, go to:
Computer Configuration\Policies\Software Settings\Software Installation
Right-click “Software Installation” and select a new package.
We’ll be prompted to select the software package we want to deploy.
It’s important to use the UNC path (not the local path).
Select the “Assigned” option and press OK.
Now we’ll see our software listed in the Group Policy Management Editor.
We’re ready to test our software policy.
As usual, run the "gpupdate /force" command on the Domain Controller and Windows Workstation. We’ll see a message like this:
This just means we need to reboot before the software can install.
Let’s do that.
After logging back on, we’ll see Google Chrome installed.
We’ve successfully deployed Google Chrome Enterprise to all the computers on our network using a Group Policy.
Active Directory Task #6: Configuring Roaming Profiles for User?Accounts
Our next task is to configure a Roaming Profile for our user account.
Imagine if every time we used a different computer on the domain, we had to start fresh?—?all our files and settings were gone, and it felt like a brand-new computer. That would be frustrating. Using a Roaming Profile in Active Directory solves this problem. It allows us to take our user files and settings with us to different computers on the network.
The secret to making this work is by using a shared folder.
We can store our entire user profile?—?with its files and settings?—?in this shared folder.
It acts as a central storage location. When we log into a computer, the computer checks the shared folder on the network and copies over all our stuff. Without this shared folder, the computer wouldn’t know where to find our files and settings (and our user profile wouldn’t be able to “roam” with us).
So let’s start by creating a shared folder in our Domain Controller.
We’ve done this in the File Explorer for previous tasks, so let’s use a different method this time: Through the Server Manager.
Start by clicking the “File and Storage Services.”
Then select “Shares.”
Right-click under the existing shares and select “New Share…”
We’ll choose the “SMB Share?—?Quick” option for the file share.
This option is a fast way to set up a shared folder using the SMB (Server Message Block) protocol, which lets devices and computers in the network share files. SMB is broadly supported and offers the functionality we need to store and access Roaming Profiles across the domain. The “Quick” option simplifies the process, offering default settings suitable for common scenarios like Roaming Profiles.
Click “Next.”
We’re going to choose the only server available: DC01.
We can just keep it on the C: Drive.
Click “Next.”
Now we’ll specify the share name.
I’ll call it Profiles$. The $ makes the folder hidden so it's not easily viewable by people who are browsing this network share path.
Click “Next.”
Within “Other Settings,” we want to enable access-based enumeration and encrypt data access.
Enabling access-based enumeration prevents users from seeing files and folders they don’t have permission to access. Only users with proper permissions can access files and folders in the Profiles$ share. Encrypting data access adds a layer of security by encrypting data as it moves across the network. It helps protect against unauthorized access.
Click “Next.”
At this stage, we’ll specify who can access the file share.
We’ll accomplish this by removing and adding principals. Principals are any objects?—?like users, security groups, or system accounts?—?that can be given access or permissions.
Click “Customize Permissions” to make the necessary changes. Notice how the Authenticated Users and Users (ADLAB\Users) principal are added by default. In a production environment, these groups include nearly everyone, casting too wide a net for access and permissions. We’ll want to remove these two default groups. But removing them requires us to disable something called inheritance.
Inheritance is like passing down family traits?—?in this case, permissions flow from the parent folder to every child folder nested within it. By disabling inheritance, we step out of the parent folder’s shadow, creating unique permissions tailored to the Profiles$ folder.
We shape the boundaries of access.
Once we click “Disable inheritance,” a pop-up will ask what to do with the current inherited permissions.
Here, we’ll choose to “convert inherited permissions into explicit permissions on this object.” This allows us to break away from the broader permissions granted by the parent folder and tailor them to this folder.
Now, we can remove those two principals, leaving only the SYSTEM and Administrators.
Side note: The SYSTEM account represents the operating system itself. By granting it full control, we ensure Windows can manage the folder and its contents?—?such as handling updates or running backups?—?without limitations. This helps the folder maintain its integrity no matter what permissions we assign to other users.
Next we’ll want to add the CREATOR OWNER group as a principal.
This group lets users control their own content. When a user creates a folder or file within Profiles$, they’ll become its "owner"—they can delete, modify, or even set permissions on it. But we don't want these users changing the main folder itself. This would compromise the security and integrity of the Profiles$ share structure.
For that reason, we’ll grant full control to CREATOR OWNERS, but only for subfolders and files.
Next we need to give basic permissions to an important group: Roaming Profile Users.
These permissions let users access the shared folder in the first place. For this group, specific permissions?—?like listing folder contents and creating folders?—?are critical. Without them, users can’t access Profiles$, rendering their roaming profiles useless.
This Roaming Profile Users group doesn’t exist yet.
So in Active Directory, we’ll make a new OU called “Domain Groups.” Then, add a Security Group named “Roaming Profile Users” with the default settings for global scope and security type.
Now add the Colton Hicks user account as a member of the group.
We’ve created the Roaming Profile Users group and added my user as a member.
Return to the Advanced Security Settings for our Profiles$ shared folder. Let's add the new group as a permission entry. By doing this, we're giving the Colton Hicks user account—and any future members of Roaming Profile Users—access to the shared folder with ease.
Click “Add” to create a new permission entry.
Then “select a principal” to add our newly created Roaming Profile Users group.
Now open up the advanced permissions. We’ll add:
Make sure these permissions apply to this folder only.
Now we’ll edit the Administrators principal for our final permission configuration.
The goal here is to ensure that Administrators only have permissions for the main shared folder. They can manage the folder itself, adjusting permissions and settings as needed. But they won’t be able to access other users’ content unless given explicit permissions.
With this final touch, all permissions needed for Roaming Profiles are in place. Make sure to apply all the permission changes and press OK.
Using the image above, here’s how all the permissions work together.
Imagine the Profiles$ folder as a large office building. Every subfolder or file is like a room in that building. And within this building, principals or groups have different roles, with access levels to match it.
We need to make sure users are productive without compromising security.
So let’s start with the SYSTEM account.
They’re like the building’s maintenance team. They have a master key that gives them full access to manage everything. They’re responsible for fixing what’s broken, and keeping the building functional.
The SYSTEM account keeps the entire Profiles$ folder—including subfolders and files—operational and running smoothly.
Next we have the Administrators.
They’re the building managers. They control who enters the front door, sets policies, and manages the building as a whole. However, they don’t have automatic control over each tenant’s office space. This would be an invasion of privacy unless the tenants gave them permission.
Administrators control the main Profiles$ folder but don’t have automatic permissions for subfolders or files made by others.
Now we have the Roaming Profiles Users.
They’re visitors who are interested in renting out an office space. In order to look around and decide if they want to rent, they need basic access to the building. But they obviously don’t have permission to enter and modify any office spaces yet. They need to sign the lease first.
Roaming Profile Users have basic access to the Profiles$ shared folder, but can't change subfolders or files by themselves.
And that leads us to the final group: CREATOR OWNERS.
They’re the visitors who decide to rent out an office space. Once they sign the lease, they’re tenants with full control over their own rooms. They can add, remove, or adjust their space to their liking. However, they don’t have admin privileges to manage the entire building, nor can they mess with other tenants’ rooms.
CREATOR OWNERS have full control over their subfolder and files only.
Together, these permissions balance user productivity and security. Let’s make our way to the confirmation section and create the new share.
We’ve successfully created the Profiles$ share folder.
Our last configuration is to set the profile path for the Roaming Profile User.
This path tells the system where to store and retrieve the user’s profile information. Instead of using a local path, which only works on one computer, we’ll use the Profiles$ UNC path so it can be accessed from anywhere on the network. In Active Directory, double-click the user and view its properties. We can change the profile path inside the "Profile" tab.
We’ll put "\\ADlab\Profiles$\%username%" as the profile path.
Once we press “Apply,” the %username% wildcard will automatically insert the actual username of the user we're configuring.
Now let’s make sure our Roaming Profile User works.
We’ll start by logging into the Domain Controller with the Colton Hicks user account. Then, I’ll place a file on the Domain Controller's desktop as a test. Finally we'll log into the Windows Workstation to confirm the file has traveled with our user to a different computer on the network.
Keep in mind that my user account needs to be part of the “Domain Admins” group to access the Domain Controller.
Domain Users need heightened privileges to access Domain Controllers. I’ll do that now.
Once that’s done, sign out of the admin account and log into the Domain Controller with the Roaming Profile User.
Create a test file.
We’re done here.
Make sure to sign out, then log into the Windows Workstation.
We should see the same file we just created.
We can also confirm the roaming profile status by taking a quick trip into the Control Panel.
Select “System and Security,” then “System.”
This will open up the Device and Windows specifications in our Settings.
Scroll to the bottom and select “Advanced System Settings.”
Our System Properties will pop up.
Head to the “Advanced” tab and take a peek at the User Profiles settings.
Here, we’ll see the details that confirm we’re using a Roaming Profile.
We’ve successfully configured roaming profiles for our user account.
Active Directory Task #7: Create Project Drives and Automatically Map?Them
Our next task is setting up project drives for different user groups and mapping them automatically.
A project drive is a shared network location where team members can save and access files. By creating a separate drive for each group?—?like Marketing or Product Development?—?we make it easy for teams to find shared resources. Then mapping a drive means assigning a drive letter to it. This helps users find project drives as easily as their C: drive.
And since privacy matters, we’ll ensure Group A can’t see Group B’s project files (and vice versa).
Let’s start by setting up user groups and adding user accounts to them.
Open Active Directory on the Domain Controller.
We’re going to create two new groups in the “Domain Groups” OU:
Next we’ll put two different users in these groups.
Since I only have one user on the domain, I’ll create a new one named Jane Doe.
Now I’ll add the Colton Hicks user account to Group A and Jane Doe to Group B.
Once we’ve added members to each group, we’ll create a shared folder for Group A and B.
We’ll do this in the Server Manager.
Just like we did for the Roaming Profiles, let’s create a new SMB share.
Select the file share profile named “SMB Share?—?Quick.”
Make sure the C: Drive is selected for the DC01 server.
Name this share “Group A.”
We can leave the “Other Settings” as they are.
Next we’ll customize permissions. I’ll disable inheritance, then remove all the principals until Administrators and SYSTEM are left.
I’ll add the CREATOR OWNER principal and give it full control over subfolders and files only.
I’ll also add Group A as a principal.
We’ll make sure it has the following permissions:
These are all the permissions needed for Group A’s project drive.
Apply the changes and hit OK.
Create the share once we’re on the confirmation page.
We’ll repeat the exact same steps for Group B. The only change? Use “Group B” for the share name and permission entry.
The end result will look like this:
At this point, we’ll map these shares as network drives using Active Directory and Group Policies.
Our first step is to create objects in Active Directory that act as digital placeholders for the file shares. Think of these objects as signposts?—?they tell the system exactly where each project drive lives on the network and ensures users can easily locate them. This is achieved by linking these objects to the UNC path of each project drive.
Right-click on the “ADlab” OU and select a new shared folder.
Name it “Group A” and provide the UNC path.
Repeat those steps for Group B.
Our project drives are now mapped in Active Directory, so the system knows where they live on the network.
This will be useful when we set up a Group Policy for how our project drives are assigned to users. That being said, let’s open up Group Policy Management. We’ll link a new GPO under the root domain.
Name it “Group A Mapped Drive.”
Edit the GPO and go to the following location:
User Configurations\Preferences\Windows Settings\Drive Maps?
This is where we start assigning network drives to users. Specifically, configuring this GPO will make the project drive appear when a user logs onto a domain computer.
Right-click on “Drive Maps” and select a new mapped drive.
Browse the location of the drive and select the Group A shared folder seen at the bottom.
This is the digital placeholder we created in Active Directory a few steps earlier. It points to the UNC path of the project drive for Group A.
Make sure to check the “Reconnect” box.
This option keeps the network drive mapped at each login?—?no need for users to re-map it every time they access a domain computer. This makes things more convenient and removes confusion.
Pick the first available drive letter.
Apply and press OK.
To prevent cross-access between Group A and Group B project drives, we’ll fine-tune the security filtering settings.
Security filtering acts as a GPOs’ gatekeeper. It’ll determine exactly who the GPO affects. In the Group A Mapped Drive GPO, navigate to “Security Filter.” Then remove “Authenticated Users” and replace it with “Group A.”
This ensures that only members of Group A have access to the Group A project drive.
Now we’ll repeat all these steps with a new GPO named Group B Mapped Drive?—?creating a new mapped drive, and updating the security filtering.
After finishing the Group B Mapped Drive GPO, there’s one last step?—?giving Authenticated Users read-only permissions.
Think of security filtering as the GPOs’ gatekeeper that decides who passes through. Read-only permissions act like the user manual. Once past the gate, users need to follow the GPOs “manual” instructions to see the mapped drives.
Both work hand-in-hand.
We’ll do it for the Group A Mapped Drive first.
Go to Delegation and add Authenticated Users. Any user who is authenticated within the domain can read the GPO if they are added to the delegation list.
After pressing OK, keep it at read-only permissions when prompted.
Repeat the same steps for the Group B Mapped Drive GPO.
We’re done configuring everything. So let’s run the "gpupdate /force" command on the Domain Controller and Windows Workstation to update the GPOs. Once that's done, let's see if our project drives are working properly. I'll log into the Windows Workstation with the Colton Hicks user account.
As shown in the image, the Group A project drive is visible without entering the UNC path.
Next, let’s perform the same test with Jane Doe, who only has access to the Group B project drive.
As you can see below, this user account can easily view the Group B project drive without the UNC path.
Remember, Jane Doe doesn’t have admin privileges and can only access the Group B project drive.
If she attempts to access the Group A drive, she’ll be denied.
We’ve successfully created project drives for different user groups and mapped them automatically.
Active Directory Task #8: Password Policies and Unlocking User?Accounts
Our last task is setting up password policies for every computer on the domain.
These policies are important for any security-conscious organization. At the core, we’re trying to prevent user credentials from being compromised. We don’t want malicious actors accessing our systems and wreaking havoc.
So let’s start by going to Group Policy Management on the Domain Controller.
We could create a new GPO for these password policies, but the Default Domain Policy already has some password settings configured.
So instead of starting from scratch, we’ll tweak the Default Domain Policy and call it a day.
Let’s edit that GPO. Open up the Group Policy Management editor and go to the following location:
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy
Let’s break down each policy and the changes we’ll make:
Here are all the changes we made:
Now let’s go to the Account Lockout Policy right underneath it.
Let’s break down each policy and the changes we’ll make:
Here are the changes we made:
Exit the Group Policy Management Editor, and run the "gpupdate /force" command on the Domain Controller and Windows Workstation.
Now let’s test our lockout policy.
I’ll make 5+ failed logon attempts on the Windows Workstation for my Colton Hicks user account.
The lockout policy works.
However, let’s say a user remembers their password after 5+ failed tries. Their account is locked out, but they don’t need a password reset. How can we help them? Luckily, there’s an Active Directory feature that allows us to unlock accounts without messing with the password.
Just go to Active Directory on our Domain Controller and find the user account.
Right-click it and select “properties.” Underneath the “Account” tab we’ll see a box that says “Unlock Account.” Check it.
Apply and press OK.
Now we’re able to log back into our user account without any issues.
Entra ID 101: Understanding the Backbone of Cloud Identity and Access Management in?Azure
Before we get our hands dirty with managing identity and access in Azure, let’s cover the basics of Microsoft Entra ID.
Entra ID has two main purposes:
To fully grasp how Entra ID achieves these purposes, it’s essential to break down the key components that enable its functionality.
There are five components that make up the backbone of Entra ID?—?Tenants, Management Groups, Subscriptions, Resource Groups, and Resources.
Entra ID’s hierarchical structure offers flexibility.
It enables us to apply roles and permissions in various ways to effectively manage our cloud resources. Now, for the remainder of the lab, we’ll walk through three different Identity and Access Management use cases in Azure.
We will:
Let’s jump in and get to work.
Entra ID Task #1: Create a User and Assign it Tenant-Level Global Reader Permissions
A tenant is the organizational heart of Azure.
It’s where everything lives?—?users, subscriptions, and cloud resources. Roles and permissions help manage this ecosystem. And they vary. For instance, the Tenant-Level Global Reader role can only view user identities, roles, and permissions within Entra ID. An Identity and Access Management (IAM) Auditor might use this role to review and ensure compliance with security policies
But they wouldn’t be able to update anything.
Let’s demonstrate this by creating a user, assigning it the Tenant-Level Global Reader role, and observing its permissions.
Go to the Microsoft Entra ID service in Azure and click “Users.”
Here’s where we can add a new user account.
Select “Create a new user” at the top.
I’ll give it a user principal name called “GlobalReaderPeter.”
Use the same for the display name. To stay organized, copy the user principal name and temporary password into a notepad.
Review and create the new user account.
Once the user has been created, we’ll want to assign the Global Reader role to it.
This will give it tenant-level global reader permissions. Go back to “All users” and select the GlobalReaderPeter user account.
Now go down to the “Assigned roles” section of the user account.
Click “Add assignments.” Search for Global Reader, then add it to the GlobalReaderPeter user account.
We’ve now created our user account and assigned it permissions.
Next let’s log in with the new user account and observe its permissions. Go to the Azure Logon portal in an incognito window.
We’ll be prompted to update our temporary password.
Enter a new one.
At this point, we’ll see a prompt to download and set up the Microsoft Authenticator app.
It’s part of a larger security protocol designed to keep accounts secure. The system gives us 14 days to complete this step, so for now, we can simply click “Ask later.”
Now we’re able to log in with the GlobalReaderPeter account.
Our access is limited to user identities, roles, and permissions within Entra ID. So if we check our subscriptions, we’ll see nothing in this tenant.
The same thing will happen if we try viewing the resource groups. Nothing’s there.
But we have permissions to access Entra ID, so we’ll go there to view it.
We’ll be able to see basic information in the “Overview” section.
We can also view all users in this tenant account.
But our “reader” permissions limit what we can do. We can’t create, delete, or modify user accounts. For example, if we tried to create a new user account, Azure would prevent us from doing it.
Notice how that option is greyed out below.
The Tenant-Level Global Reader role acts as a safeguard, offering just enough access to allow users to see the big picture without stepping over any lines.
Entra ID Task #2: Create a User with Subscription-Level Reader Permissions
Subscriptions keep track of resources and the costs associated with them.
Companies often create separate subscriptions under one tenant to organize departments?—?like Marketing or Product Development. We can also assign roles to check or manage these subscriptions. For instance, the Subscription-Level Reader role can view resource deployment, usage, and performance within a subscription. A Project Manager might use this role to monitor project progress and check resource availability.
But they wouldn’t have permission to change any subscription settings or configurations.
Let’s demonstrate this by creating a user, assigning it the Subscription-Level Reader role, and observing permissions.
Just like before, we’ll go to the Microsoft Entra ID service in Azure and create a new user.
This time we’ll name it “SubReaderThea.”
Next we’ll navigate to the “Subscription” service in Azure to give the user permissions at the subscription-level.
Go down to “Access control (IAM).” Then select “Add role assignment.”
From here, we’ll want to select the “Reader” role and click next.
Now we’ll select the member we want to give this role to?—?SubReaderThea.
We’ve set up a new user with the Subscription-Level Reader role. Let’s log in and observe its permissions.
We’ll start by viewing our Subscriptions.
We can view everything within Azure subscription 1. However, if I had multiple subscriptions within this Azure tenant, I wouldn’t be able to see them.
Next we’ll look at our Resource Groups.
We’ll be able to view every resource group?—?and its accompanying resources?—?within Azure subscription 1.
But since we only have “reader” permissions, we won’t be able to create a new resource group.
We also won’t be able to create, delete, or modify resources themselves.
For example, if I try to delete a VM within the subscription, Azure won’t let me do it.
The Subscription-Level Reader role provides visibility into resources and their usage without the ability to make changes.
Entra ID Task #3: Create a User with Resource Group-Level Contributor Permissions
Resource groups are like containers where we can manage Azure resources as a single entity.
They simplify management?—?we can apply uniform settings, monitor performance, and delete everything in one swoop. We can also assign roles and permissions to manage a specific resource group. For instance, a Resource Group-Level Contributor role lets users create, delete, or modify resources. A System Administrator might use this role to build out the IT infrastructure for a project.
But they’d be limited to the boundaries of their assigned resource groups.
Let’s demonstrate this by creating a user, assigning it the Resource Group-Level Contributor role, and observing permissions.
Just like before, we’ll go to the Microsoft Entra ID service in Azure and create a new user.
This time we’ll name it “RGContributorVictor.”
We’ll want to create a test resource group. This allows us to grant permissions in a low-risk environment, as we don’t want to accidentally delete or modify important resources.
I’ll name it “Permissions-Tester.”
Within the “Permissions-Tester” resource group, head over to “Access control (IAM).”
Select “Add role assignment.”
Let's select the “Contributor” role assignment.
We’ll need to be under the “Privileged administrator roles” to find it.
Then we’ll want to select RGContributorVictor as the member who’ll receive contributor-level permissions for this resource group.
Review and assign.
Now let’s log into the Azure portal with our new RGContributorVictor user account.
The first thing we’ll do is view our subscriptions. We can access the page, but we won’t be able to see billing information or other sensitive data.
Next let’s view our resource groups.
We’ve only been given access to the “Permissions-Tester” resource group, so that’s the only one we’ll see.
That being said, we have free reign over this entire resource group.
We can create, delete, or modify the resources inside it. To illustrate this, I’ll create an Azure Storage Account inside this resource group.
In the image above, notice how we can only select the “Permissions-Tester” resource group within the project details.
We can also delete entire resource groups. So let’s delete the entire resource group that RGContributorVictor has access to.
As you can see below, the deletion process works for contributor-level permissions.
The Resource Group-Level Contributor role provides full control over resources within a specified resource group.
That concludes our Entra ID lab and we’re done with the three dummy user accounts. To clean up our environment, we can delete these users by going to the Entra ID service within our main admin account.
Select all the users and delete them.
Congrats on making it to the end!
Next Steps:
Now we’ve got the tools, knowledge, and practical skills to preserve the confidentiality of our network resources.
Just as a gardener’s watchful eye keeps their oasis thriving, IT professionals use Active Directory and Microsoft Entra ID to safeguard their networks. Gatekeeping isn’t new. But it takes on a new form in the digital age. From verifying identities to defining permissions, these systems offer a reliable way to manage who gets through the gates. And essential group policies must be enforced for everything to work together seamlessly.
Successful Identity and Access Management (IAM) isn’t just about technology?—?it requires strategy, vigilance, and thoughtful oversight.
This project took 50+ hours to implement and document.
If you enjoyed the content, you might also like my in-depth project breakdown where I used Nessus Vulnerability scanner to discover and remediate system weaknesses. Every IT asset we bring into our environment?—?whether a new system, network, or application?—?pushes the boundaries of what we can accomplish.
But each one also expands our attack surface and introduces security vulnerabilities.
And Vulnerability Management is a key cybersecurity skill to fix system weaknesses before they’re exploited.
In the article, I share:
The project took 20+ hours to implement and document.
Disclaimer: This project was conducted in a secure, isolated virtual environment. It is highly recommended that you use proper virtualization or sandboxing techniques to prevent any potential harm to your local systems. I am not responsible for any damage, data loss, or security issues that may arise if proper security measures are not followed. Always ensure your projects are contained and isolated to protect the integrity and safety of your machine.
This article was originally published on Medium. You can view it HERE .