Final Project Documentation - Bobleoble/tech-journal GitHub Wiki
Documentation Overview
A complete medium sized enterprise created from scratch over the course of three weeks. This network includes a pfSense Firewall, two Windows workstations, two Windows Server 2016 Domain Controllers, two Windows Server 2016 Distributed File System machines, two CentOS 7 DHCP machines, one Windows Server 2016 Management machine, one CentOS 7 machine for testing, one Ubuntu Docker machine, and one Ubuntu Ansible machine.
Machine Configuration
The following are all of the configurations for the machines used, however they are not listed in order of configuration. The pages below are also simply the roots of the network, like prerequisites, and not the way each machine is being used. That information can be found further below.
- pfSense Firewall - 10.0.5.2
- Windows Workstations - Dynamic IP Range between 10.0.5.100 and 10.0.5.150
- Windows Server 2016 Domain Controllers - 10.0.5.5 and 10.0.5.6
- Windows Server 2016 DFS Machines - 10.0.5.50 and 10.0.5.51
- CentOS 7 DHCP Machines - 10.0.5.15 and 10.0.5.16
- Windows Server 2016 MGMT Machine - 10.0.5.10
- CentOS 7 Util Machine - 10.0.5.21
- Ubuntu Docker Machine - 10.0.5.60
- Ubuntu Ansible Machine - 10.0.5.11
Domain Group Policies
After any of the below, run gpupdate /force to update the Group Policy on that machine. This must be done after any Group Policy is completed. After running the command, relog.
Docker
Basic Teamspeak server that allows for communication between workstation machines.
Ansible
RVTM
| Requirement/POC | Test | Expected Results | Actual Results | Pass/Fail |
|---|---|---|---|---|
| Redundant AD infrastructure using DC1 + DC2. One should be able to turn off DC1 or DC2, and still be able to manage AD and login via W1 + W2 + MGMT1. | We turned off DC1 and logged into W1 and W2, then turned DC1 back on, turned DC2 off and logged into W1 and W2, showing the redundancy of ADDS if either went down. | Login to W1, and W2, should be successful as the other domain controller should take over for the one that went down. | Login was successful on both W1 and W2 while DC1 was down and DC2 was up, and vice versa | Pass |
| DHCP1 and DHCP2 should provide DHCP services to your LAN. | To test this, we'll run ipconfig /all which shows the IP configuration, including the DHCP Server providing the IP address to the machine. | On W1, show that its DHCP Server is 10.0.5.15. On W2, show that its DHCP Server is 10.0.5.16 | W1 was using 10.0.5.15, and W2 was using 10.0.5.16. | Pass |
| Should be able to release and renew current IP configuration, and DHCP should be able to assign a new IP to the machine. | For W1, run ipconfig /release and ipconfig /renew, and then do the same for the second workstation machine. | It is expected that DHCP will renew the IP's for these machines. | All IP's were released and renewed as expected. | Pass |
| MGMT2 works as an Ansible controller and can perform commands on nodes. | On MGMT2, use Ansible to ping DHCP01 via inventory.txt. | The ping sends green text back saying that it worked. | The ping worked and sends back the expected results. | Pass |
| UTIL01 is joined to the domain. | On UTIL1, attempt to log into domain user | We are able to log into [email protected] of UTIL1. | We were able to log into [email protected]. | Pass |
| MGMT2 will be an Ansible controller system that can control your entire domain, with the exception of Windows Workstations. You should be able to run interactive commands against all these systems. | We will ping all of the connected machines using MGMT2. | It is expected that the ping returns true, showing a connection to each of the machines on the domain | Each of the machines pinged responded, showing their connection to MGMT2 on the domain. | Pass |
| UTIL will be a system that you can provision with a new application via MGMT2 and Ansible. | Show that Nmap is installed and works. | Nmap should be installed on UTIL and functional | Nmap is installed on UTIL and functional. | Pass |
| MGMT1, DC1, DC2, DFS1, DFS2 and your Workstations represent your Active Directory Infrastructure. Your domain should be your groupname.local. Join all windows systems to the domain and at least one of your Linux systems. | In Vsphere, show all of the DNS names of these machines, showing that they are joined to the unlucky.local domain | MGMT1, DC1, DC2, DFS1, and DFS2 should all display as being on the unlucky.local domain | All of their DNS names result in .unlucky.local. | Pass |
| Create an AD security group called linux-admins. Members of this group should be able to sudo to root on one of your Linux systems (this has some implied sub-requirements). | Show AD security group containing members, then prove one of those users can sudo to root on UTIL | This linux-admin user should be able to sudo to root on the UTIL machine, proving they in fact have admin privileges | Admin user can sudo to root on the UTIL machine | Pass |
| Install docker and a wiki/application of your choice on docker. (NOT WORDPRESS!) | The application of choice was a TeamSpeak server, which should be installed. | Show that the Teamspeak Server is running and can be joined on W1 and W2. | Teamspeak Server was joined on WK1 and WK2. | Pass |
| Create a Domain Group Policy that allows W1 + W2 to remote desktop between one another. | Show the group policy is in existence on MGMT1, then remote desktop from W1 to W2 or vice versa. | Remote desktop should connect between W1 and W2 flawlessly. | Remote desktop connects without an issue. | Pass |
| Create a Domain Group Policy that applies corporate wallpaper to W1 + W2 + MGMT1. | Show the group policy is in effect on MGMT1, on W1 and W2 show that the corporate wallpaper is applied | On W1, W2, and MGMT1, the wallpaper should all be the same. To prove these weren't all individually applied, open Personalize on windows desktop of one of these machines, it should not let you change the wallpaper because "some settings are managed by your organization". | The same wallpaper is present on all of the aforementioned machines, and it should not be changeable by the user. | Pass |
| Create a Domain group policy that moves W1 and W2 user profiles and home directories to a DFS share. | Show the group policy on MGMT1 and the location of W1 and W2 user profiles inside of the DFS share. | W1 and W2 user profiles should be inside the DFS share. | W1 and W2 user profiles are inside the DFS share. | Pass |
| Use Ansible to install a yum package. | Show the ansible playbook that was used to install the yum package, then show the location of the package on the system. | It is expected that the package exists on the machine and matches up with the expected installation from the ansible playbook. | Yum package matches, is properly installed | Pass |
| Use Ansible to add a new Linux local user can be an SSH user or one with a password. | Show ansible playbook that adds a new local Linux user and the existence of the user, do so by logging into this user's account | User account should exist and be accessible. | Ansible playbook doesn't work properly, so local Linux user does not exist. | Fail |
| Use Ansible to add a new Windows domain user. | Show ansible playbook that adds a new domain user, then log into that user's account on a seperate machine to show that it works | The user's account should be accessible on other domain-joined machines | Windows Domain user does not exist as ansible playbook is not configured properly. | Fail |