The next step in our journey is to set up Group Policy Objects (GPOs).
At this point, you may be wondering what is it?, why we need it, and how to implement it.
Microsoft Group Policy Objects (GPOs): is a collection of Group Policy settings that defines what a system will look like and how it will behave for a defined group of users, those policies are replicated among Domain Controllers (DCs) so every user/computer on the domain have the same policies.
In a nutshell, we can customize many aspects of the domain: security, auditing, looking, functionalities, and even deploying apps with it. It is a fundamental piece of any Windows Server Domain deployment.
Where are the Group Policy Objects (GPOs) stored?
A GPO stores its configuration information in two locations:
1. Group Policy Container (GPC)
2. Group Policy Template (GPT)
A GPC is an object that contains information like GPO’s name, ACL, version information, and enable/disable status. It is stored in the CN=Policies, CN=System container of the domain.
In our case we can find it in 2 locations:
Active Directory Users and Computers:
Click on View and ensure Advanced Features is enabled.
Navigate to the following path:
Domain > System > Policies
Using ADSI Edit:
Open ADSI Edit (run
adsiedit.msc
).Connect to the Default Naming Context.
Navigate to:
DC=YourDomain,DC=com > CN=System > CN=Policies
The Policies container holds the GPC objects (GUIDs).
A GPT is stored as files on the SYSVOL directory on every domain controller in the domain. It contains the administrative templates and scripts related to the GPO. The contents of the SYSVOL folder are replicated between all the domain controllers in the domain.
For this case, we go to the SYSVOL folder (which is stored on the S drive, Microsoft best practices recommend it to store it on a separate drive than the OS).
Configure Group Policy Objects (GPOs)
For our project, we will configure the following GPOs:
General Security:
Minimum password length: 12 characters.
Password complexity requirements enabled.
Maximum password age: 30 days.
Account lockout after 5 failed attempts.
Screenlock timeout: 5 mins.
Windows Updates:
- Configure Windows Updates to automatically download and install every Sunday at 4 am. (IMPORTANT: This is NOT the best practice as we always want to review updates before approving/installing them, for that, we will disable this GPO and set up a Windows Server Update Services WSUS in the following posts.).
Workstations Access Restrictions:
- Disable Command prompt, PowerShell, and Task Manager for the HR department.
Auditing:
Enable logon/logoff auditing.
Enable lockout verification.
Basics:
To access GPO configuration let’s go to Server Manager > Tools > Group Policy Management.
We can see all GPOs for our domain:
GPOs are usually NOT applied right away but rather it depends on the configuration itself:
For Computer Configuration GPOs:
Policies refresh every 90 minutes, with a random offset of up to 30 minutes.
Domain controllers refresh every 5 minutes.
For User Configuration GPOs:
- Policies also refresh every 90 minutes, with a random offset of up to 30 minutes.
At User Logon or Computer Startup:
- GPOs apply immediately when a user logs on or when the computer starts up.
Manual Application:
You can force an immediate GPO refresh by running the following command on the client machines via the command prompt:
gpupdate /force
For our project, we will use the Manual Application on the Domain Controller (DC) and the Workstation(s).
General Security:
For General Security GPOs we will apply them on the Default Domain Policy GPO (so ALL users and computers get those settings).
Minimum password length: 12 characters.
Find the Default Domain Policy GPO, right-click, and select Edit…
Go to: Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy, we can see it’s set up as default:
Let’s set it up per our standards:
Test:
Let’s try to create a user with a password of less than 12 characters.
We will get an error:
Now let’s try a password with more than 12 characters:
Success!:
Password complexity requirements enabled: this one is already set up.
Maximum password age: 30 days:
Account lockout after 5 failed attempts:
We also need to define values for Account lockout duration and Reset account lockout counter after, for both we will use the suggested 30 minutes.
Test:
Let’s enter Matt’s credential wrongly 5 times and have the account locked out:
To unlock it, we can wait 30 minutes or do the following:
Go to Active Directory Users and Computers and find the user then go to Account and see it’s locked:
We can check the Unlock Account option and select Apply, Ok:
Now the user should be able to log in successfully.
Screenlock timeout: 5 mins:
Go to Computer Configuration > Policies > Windows Settings > Security Settings > Security Options and find Interactive logon: Machine inactivity limit.
Windows Updates:
Configure Windows Updates to automatically download and install every Sunday at 4 am:
Navigate to: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update:
Configure automatic updating: 4 - Auto download and schedule the install.
Install during maintenance: Checked.
Scheduled install day: 1 - Every Sunday.
Scheduled install time: 04:00.
Every week: Checked.
Workstations Access Restrictions:
The following GPOs will be applied ONLY to the HR department, therefore, we will create and link GPOs to that Organizational Unit (OU).
Disable Command prompt:
Right-click on the HR OU, select: Create a GPO in this domain, and Link it here…
We will name it: Disable CMD
Right-click on Disable CMD and select Edit…
Go to User Configuration > Policies > Administrative Templates > System.
Double click and open Prevent access to the command prompt:
Selected Enabled and Disable the command prompt script processing also? Yes.
Apply and Accept:
Test:
Let’s log in with Soo (member of HR OU).
This is what happens when we try to open the command prompt:
Success!
Let’s Disable Powershell:
The same process, create the OU, and link it to HR and Edit:
Select Don’t run specified Windows applications:
In List of disallowed applications set: powershell.exe and powershell_ise.exe
Test:
As we can see we are unable to open Powershell via Start Menu or File Explorer:
It’s showing but if you try to click it, it won’t do anything:
Success!
Let’s Disable Task Manager:
The same process, create the OU, and link it to HR and Edit:
Open Remove Task Manager:
Set to Enabled, Apply, and Ok**:**
Test:
We log off and log back in with Soo (member of HR OU):
Notice when we do CRTL+ALT+DEL, the Task Manager option is not showing anymore:
Let’s try to open via the Start Menu:
We got an error:
Success!
Auditing:
Enable logon/logoff and lockout auditing:
For this one let’s Edit the Default Domain Policy:
Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff
Here we will select Audit Events: Success and Failure for both: Audit Account Lockout and Audit Logon
With this setting the events for Account logon and Account lockouts will saved ONLY on the local Workstation’s event viewer.
For the audit events to be saved on the Domain Controller’s event viewer:
Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon
Enable Success and Failure Audit Events for:
Audit Credential Validation
Audit Kerberos Authentication Service
Audit Kerberos Service Ticket Operations
Test:
Enter Matt’s wrong password.
on the local workstation: BBM-WS02 we can verify the event viewer:
Failure Code: 0×18:
We can check on Microsoft documentation:
0x18 | KDC_ERR_PREAUTH_FAILED | Pre-authentication information was invalid | The wrong password was provided. |
Now let’s test the Account lockout auditing:
Rinse and repeat 4 times more and we get:
Let’s review the event viewer events from the BBM-DC01:
Failure Code: 0×12:
We can check on Microsoft documentation:
0x12 | KDC_ERR_CLIENT_REVOKED | Client’s credentials have been revoked |
Verify Applied GPOs:
Let’s log in on BBM-WS01 with a user, open the command prompt and run:
gpresult /r
Notice on Applied Group Policy Objects we see M Drive (user is member of Marketing OU, therefore once he logs in he has the Marketing (M) drive mapped on File Explorer).
We can also see further information about filtered GPOs, and the groups the user belongs to:
And with that, we’ve set up the Group Policy Objects for our Domain.
The next steps will be setting up the Windows Server Update Services Server (WSUS), Remote Desktop Services (RDS) Server, Setting up Emails, and much more!
Stay tuned for more content.
Thanks for reading!
Link to the series 👉 https://beyondbaremetal.hashnode.dev/series/beyond-bare-metal-setup