Passwords and Access Control

Passwords were a huge part of my Security+ preparation but this lab let me work with the actual settings in Windows. Virtual Lab 7-1 focused on local accounts. These accounts belong to the computer rather than an Active Directory domain.

The lab started with creating different users and testing passwords. the password abc was too short at first. The next example, abcdefgh was longer but did not meet the complexity requirement. These examples showed why Windows might just reject a password even when it has enough characters.

The next part covered changing the password policy through Local Security Policy. The required minimum length was 12 characters. Password history was set to remember 10 passwords. The lab also required a minimum password age of one day and a maximum of 60 days age.

Account Lockout

The account lockout section covered repeated failed sign-ins. The lab required that it would lock after three incorrect attempts. The ;lockout duration was 45 minutes. The failed attempt counter was also set to reset after those 45 minutes were up.

A lockout limits repeated password guesses against a account. There is a tradeoff though which is that a real user could mistype a password and get locked out too. Someone could also just trigger a lockout. That helped me see why administrators need to consider how a setting can actually affect the people using the system.

Sign-in Settings

The lab also covered hiding the name of the last person who signed in. This helps by keeping the username from appearing on the sign-in screen.

Another task involved was adding a warning title and message. The message identified the server as company property. A warning does not stop an attack by itself but it tells the users who system they are accessing. It is more of a deterrent control to try and push the attackers away by not actually stopping them.

Password and Account Policy Summary

I created this table for my portfolio using the requirements from Virtual Lab 7-1

Lab setting	Required value	Purpose
Password history	10 passwords	Prevents reuse of the remembered passwords.
Maximum password age	60 days	Sets when a password must be changed.
Minimum password age	1 day	Limits how soon a user can change a password again.
Minimum password length	12 characters	Rejects passwords shorter than the required length.
Password complexity	Enabled	Requires passwords to meet Windows complexity rules.
Account lockout threshold	3 failed attempts	Locks an account after repeated incorrect sign-ins.
Account lockout duration	45 minutes	Sets how long the account remains locked unless an administrator unlocks it.
Reset lockout counter	45 minutes	Sets when the failed-attempt count resets if no further failures occur.
Display last signed-in username	Disabled	Hides the previous user’s name on the sign-in screen.
Logon warning	Warning!	Displays the title above the company ownership message.

What I Took Away

This lab gave me a more closer look at the settings that are actually behind a password policy. Knowing that a password was rejected was only part of it. I also needed to understand which requirement caused the actual rejection.

The lab used several controls together. Password requirements affected what users could choose. Lockout settings limited the amount of repeated guesses. The sign-in options changed what information had appeared before someone logged in.

These were the settings assigned for the exercise. I would not assume the same values fit every workplace as it actually does not fit the workplace I currently work at. I would need to follow the organizations requirements and understand the effect of each change.

Related Lab

Virtual Lab 7-1, Guided: Configure Password Management in Windows

Network Security and Monitoring

For this topic I used Virtual Lab 8-2: Examine Network Communications by Using Wireshark. The lab covered capturing traffic and finding the specific information within it. It also showed how much information can actually be exposed when a connection is not encrypted.

I had studied different protocols and ports for Security+. This lab connected those terms to traffic generated by a browser and a FTP connection. Instead of only remembering a port number I was able to examine where it appeared in the communication.

Capturing and Filtering Traffic

The lab started with checking the computer’s IPv4 address using ipconfig. The next steps involved installing Wireshark and starting a capture on the Ethernet interface. Visiting a website that generated traffic to examine.

The HTTP display filter narrowed the results to HTTP traffic. The DNS filter showed name lookup traffic. Filters using source or destination addresses helped focus on the computer involved in the exercise.

The lab also covered the difference between display filters and capture filters. A display filter changes which captured packets are shown. A capture filter limits what Wireshark collects in the first place. That difference matters because traffic excluded during capture cannot be brought back by clearing a display filter.

Following a Conversation

Another part of the lab covered following TCP and HTTP streams. These features bring related traffic together so it is easier to read a conversation between a client and server.

The exercise included finding a browser request and the server’s HTTP 200 OK response. That response means the request succeeded. Looking at both sides gives more context than examining a single packet alone.

Why Encryption Matters

The FTP section provided an example of the risks of unencrypted communication. The tasks involved finding the USER and PASS commands in captured traffic. With plain FTP, someone who can capture the connection may be able to read the username and password.

A failed sign-in does not mean the password was protected during transmission. The credentials still had to travel to the server for it to check them. This shows why choosing an encrypted service matters even when an account has a strong password.

Wireshark Filter Examples

I created this table for my portfolio using examples from Virtual Lab 8-2. It explains the filters rather than showing saved capture results.

Filter	What it shows	Example use
http	Captured HTTP traffic	Finding browser requests and server responses.
dns	Captured DNS traffic	Reviewing requests to look up a domain name.
ip.dst == HOST_IP	IPv4 traffic sent to the chosen address	Focusing on traffic received by the lab computer.
tcp.flags.syn == 1	TCP packets with the SYN flag set	Examining connection setup.
tcp contains “USER”	TCP packets containing USER	Finding a plaintext FTP username command.
tcp contains “PASS”	TCP packets containing PASS	Finding a plaintext FTP password command.

HOST_IP is a placeholder for the computer’s actual IPv4 address.

What I Took Away

Wireshark gives me a way to investigate what is happening during a connection. If a website does not load, I can look for a DNS request or check whether a connection was attempted. The capture provides information to help narrow down the problem.

The FTP exercise also connects network monitoring with password security. Password requirements help protect an account, but they do not encrypt the connection. Both need attention.

I still need practice reading captures and choosing filters. This lab gave me a starting point. I can focus on one protocol or address instead of trying to understand every packet at once.

Related Lab

Virtual Lab 8-2, Guided: Examine Network Communications by Using Wireshark

Encryption and Data Protection

Virtual Lab 3-2 covered file encryption and recovering access when a user loses their encryption key. It also included BitLocker and transferring a file through SSH. These tasks covered protecting data stored on a computer and data moving between computers.

I had studied encryption for Security+, but this lab gave me examples of how it is used in Windows. It also showed why recovery needs to be planned before someone loses access.

Encrypting Files with EFS

Encrypting File System, or EFS, protects individual files and folders. The lab used three text files named SalesQ1, SalesQ2, and SalesQ3. The tasks covered encrypting files through File Explorer and using the cipher command.

Running cipher without additional options displays the encryption status of files in the current folder. An E means the file is encrypted. A U means it is unencrypted. The exercise also covered decrypting one file so its status could be compared with the others.

The access test involved signing in with a different account and trying to open the files. Having administrator rights did not automatically provide the key needed to read the encrypted contents. EFS protects the contents, but the file’s name and existence can still be visible.

Recovering Encrypted Files

Before the encryption tasks, the lab covered setting up a Data Recovery Agent. This provides a recovery option if the original user loses access to their EFS key.

One part of the exercise involved deleting and recreating the user account. Creating another account with the same name did not restore the original encryption key. The lab then covered importing the recovery agent’s private key and using it to decrypt the files.

This was an important part of the topic for me. Encrypting a file protects it, but losing the key can also keep the owner from reading it. The recovery certificate and private key need to be protected too. Someone with the correct recovery key could use it to decrypt the files.

BitLocker

The BitLocker section covered a different level of protection. EFS works with individual files and folders. BitLocker encrypts a drive volume.

The lab called for creating a small data volume and turning on BitLocker. It also included saving a recovery key before starting encryption. The final task was turning BitLocker off to decrypt the volume.

A practical use would be protecting data on a drive that is lost or stolen. The recovery key provides another way to unlock the drive if the normal unlock method is unavailable. It needs to be stored somewhere secure.

Secure File Transfers

The last section covered transferring a file between two Windows machines. The tasks included starting the OpenSSH server and allowing its connection through the firewall. The file was then transferred using scp.

This connects with the Wireshark lab. Plain FTP can expose credentials in captured traffic. Using scp over SSH protects the transfer with encryption.

Encryption Methods Used in the Lab

I created this comparison for my portfolio using the tasks from Virtual Lab 3-2.

Method	What it protects	Recovery or access requirement
EFS	Individual file and folder contents	The user’s EFS private key or an authorized recovery agent’s private key.
BitLocker	Data stored on a drive volume	An approved unlock method or the recovery key.
SCP over SSH	A file while it is transferred between computers	Authentication to the SSH server. This does not automatically encrypt the saved file on the destination drive.

What I Took Away

This lab helped me separate file encryption from drive encryption. It also connected encryption with account management. Recreating a username does not mean the new account has the old account’s keys.

The recovery tasks were just as important as the encryption tasks. Before using encryption, I need to know how access would be recovered. Otherwise, a security measure could leave someone unable to open their own work.

I would also check whether I am protecting stored data or a network transfer. They need different controls. An encrypted transfer does not automatically mean the file stays encrypted after it is saved.

Related Lab

Virtual Lab 3-2, Guided: Implement File Encryption