When you set up a new computer or Windows server, Systems Administrators have been notoriously guilty of using the same password, with a local administrator account, and never changing it.

Face it. We are all guilty of it. Password reuse is human nature. There have even been studies about it.

Even seasoned Information Security professionals have the same password on multiple websites. I know I probably do. However, I have improved my password usage once I invested in a password manager (LastPass) and my passwords are mostly randomly generated. However, there may be a few lingering accounts out there with old and reused passwords.

So what could go wrong if I use the same local administrator password across all of my computers and servers?

If one of your domain servers or workstations becomes compromised, an attacker could easily use those local administrator credentials to migrate across each system in your environment. An attacker does not even need to know the exact password but could use the password hash to authenticate to other systems and computers in your environment.

Former attorney, current IT & Information Security Consultant, and a very informative Twitter account I follow, "Brian in Pittsburgh" recently tweeted three reasons why attackers gaining local administrator access is bad.

Solution

Microsoft introduced the Local Admin Password Solution (LAPS) in 2015 as a free tool to Domain Administrators to combat the use of local administrator passwords being left on domain-joined servers and computers.

LAPS will set a different and random password for the local administrator account to every computer in your domain and can rotate those passwords based on your domain's password policy. These passwords are then saved in Active Directory and only authorized administrators can retrieve these passwords when required.

How does LAPS work?

In the LAPS download documentation, you will find a section that discusses how it works in your environment. However, this documentation can be a little difficult to comprehend. Here is (hopefully) an easier breakdown of how LAPS works.

1. A small application installed on your computers and servers (client-side extension (CSE)), is deployed by a small script (Group Policy Object) from your Domain Controller.

2. This small application (CSE) checks whether the password of the local Administrator account has expired (based on your Domain's password policy). If the password is deemed to have expired or is close to expiring, the CSE generates a new password.

3. The new password is then validated against the Domain Password Policy to make sure it meets password length and complexity requirements or isn't on a list of passwords you can't use.

4. The CSE reports the password and the next expiration time to Active Directory, and it is stored in a confidential attribute associated with the computer account in Active Directory.

5. The CSE changes the password of the local administrator account on the computer.

6. The password then can be read from Active Directory by users (administrators) who are allowed to do so.

How to configure LAPS?

LAPS can be downloaded directly from Microsoft.

We should first check the System Requirements.

LAPS is only supported on the following operating systems:

• Windows Server 2022
• Windows Server 2019
• Windows Server 2008
• Windows Server 2016
• Windows 10
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 (EOL January 2020)
• Windows Server 2003 (EOL July 2015)
• Windows 8.1
• Windows 8
• Windows 7 (EOL January 2020)
• Windows Vista (EOL April 2017)

In my test environment, I will use a Windows Server 2019 virtual machine for my Domain Controller, and two client virtual machines running Windows 10 and Windows 11. I am thankful that I do have a development server, running VMware ESXi, to host the virtual machines.

In the Details section of the Download page, you will see a lengthy description of why LAPS was created, how LAPS works, and its features. I highly recommend reading through this section carefully.

When you are ready to download the files, you are given several file options.

For my test environment installation, I downloaded the following files:

• LAPS_OperationsGuide.docx
• LAPS.x64.msi
• LAPS_Datasheet.docx
• LAPS_TechnicalSpecification.docx

Installing LAPS on the Management Computer

The first step was to install LAPS.x64.msi on my Domain Controller. Following the instructions from the guides, I will deselect the AdmPwdGPO Extension and ensure all of the Management Tools are selected.

Here is a brief description of what each component of LAPS.x64.msi does:

• AdmPwd GPO Extension — this is a LAPS agent that need to be installed on all computers
• Fat Client UI — GUI tool for viewing the local administrator password
• PowerShell Module — allows you to manage LAPS using PowerShell
• GPO Editor templates — admx/adml GPO templates for configuring LAPS

After the LAPS UI finishes installing, you will see the LAPS UI icon on your desktop. Opening up the LAPS UI will look as such:

Extend the Active Directory Schema for LAPS

We next need to run some PowerShell commands in order to extend the Active Directory Schema so that LAPS can store the data in attributes in Active Directory. LAPS will be storing data in the following attributes:

• ms-Mcs-AdmPwd - stores the password
• ms-Mcs-AdmPwdExpirationTime - stores the password expiration time

While logged in to my Administrator account on the Domain Controller, I will need to run the following PowerShell commands to extend the Active Directory Schema:

1) Import the PowerShell LAPS module:

Import-module AdmPwd.PS

2) Extend the Active Directory schema:

Update-AdmPwdADSchema

You should see the following results:

Change Computer Object Permissions

Now, I need to apply LAPS policies to my "Domain Computers" OU within Active Directory. As you can see, I have two workstations, WINDOWS10 and WINDOWS11, in my "Domain Computers" OU. I want to apply the LAPS policies to that group of computers.

I now need to allow the workstations to have the proper permissions to write values to the ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime attributes in the Active Directory Schema (via the CSE that will be installed on each computer in "Domain Computers").

To this, I will run the following PowerShell command:

Set-AdmPwdComputerSelfPermission -OrgUnit 'Domain Computers'

Assign Permissions to Administrators

I will then assign the proper permissions to allow administrators to view the passwords stored in Active Directory. First, I need to view the permissions that are currently set.

To this, I will run the following PowerShell command:

Find-AdmPwdExtendedRights -Identity "Domain Computers"

In my demo environment, I'm satisfied with only allowing administrators in the "Domain Admins" security group with access to the LAPS passwords. If you want to delegate permissions to an additional local administrators group (for example an "ITAdmins" group), you would need to run the following PowerShell command:

Set-AdmPwdReadPasswordPermission -Identity "Domain Computers" -AllowedPrincipals "ITAdmins"

Install the CSE on Workstations

There are several ways to install the CSE (LAPS.x64.msi) across your workstations. Manually installing it across every workstation may take some time, too. The easiest, and most convenient, way to deploy the CSE is using a Group Policy Object (GPO).

Microsoft already provides us with a .msi file. The "msi" file extension stands for Microsoft Software Installer. It is a Windows Installer format that uses Microsoft's Windows Installer service to configure installer packages, such as Windows applications or update packages. (ref. MSI File - What is, how to open and edit it?)

So knowing that I have a msi file that I can use to install software, I will create a GPO to deploy the application.

1) In your Domain Controller, launch GPMC (Group Policy Management Console) in Server Manager or search for gpmc.msc in the Windows start menu.

2) Create a new Group Policy under the Domain Computers OU.

3) Then right-click on the group policy and click on Edit

4) Then navigate to Computer Configuration | Policies | Software Settings | Software Installations

5) Right-click on it and select New | Package

6) A File Explorer window will open. Then browse to a network share that has LAPS.x64.msi file. In this demo, I am using path \\dc\LAPS\LAPS.x64.msi and this share has read permissions for everyone.

7) Then in the next window select the deployment method as “Assigned”

This will deploy the LAPS agent to all the computers in the "Domain Computers" OU. The installation will require a reboot on the client's computer to complete the installation.

GPO for LAPS Password Settings

I now need to create a password policy for the computers using LAPS. You can use the same policy for the LAPS deployment, or you can create a new GPO.

1) With the GPMC (Group Policy Management Console) open, create a new Group Policy under the Domain Computers OU.

2) Then right-click on the group policy and click on Edit

3) Then navigate to Computer Configuration | Policies | Administrative Templates | LAPS

4) I will then go through all the listed polices and set them to Enable. The policies are described more in detail below:

• Enable local admin password management: Enabled; This enables management of the local administrator account.

• Do not allow password expiration time longer than required by policy: Enabled; If an administrator password is expired, it will be changed immediately.

• Name of administrator account to manage: Use this policy if you use an administrator account other than the built-in Administrator; Sometimes you may use a different named account (ie. "admin" or "xadministrator")

• Password Settings: Enabled, configure the complexity, length, and frequency of changing the password here. I have mine set below.

Testing and Verifying LAPS is Working

Now that the LAPS policies have been set, we need to make sure the client computers are generating new passwords. Since we set the CSE to deploy using a Group Policy Object, we will need to wait for the workstations to update their Group Policy. According to the Microsoft documentation, Group Policy is automatically refreshed when you restart the domain member computer, or when a user logs on to a domain member computer. In addition, Group Policy is periodically refreshed. By default, this periodic refresh is performed every 90 minutes with a randomized offset of up to 30 minutes.

I then restarted the WINDOWS10 and WINDOWS11 computers and logged in with a domain account. Once the workstations were restarted, I can now check the LAPS UI on the Domain Controller.

It looks like it's working as expected. I can also set a new password expiration time in the last box in the LAPS UI. By default, it will enter the current date and time. If I select "Set" that will set that date and time to the expiration time.

And we are done!

Conclusion

Hopefully, this guide will be able to help you set up LAPS in your Domain environment. The instructions in the LAPS documentation may be a bit intimidating, but thankfully there are additional step-by-step guides out there that were able to help me. Please see the following two guides for additional information:

Blog cover photo by Hal Gatewood on Unsplash

In this blog, I will attempt to break down this federal act as best as possible to give you an insight into what may or may not be required by federal law for your organization The views and opinions expressed in this blog post are of my own professional opinion and not of my employer or organizations with which I am affiliated. I will be referencing analyses from other individuals and organizations which may provide further information on the passed legislation. Readers of this blog should contact their organization’s attorney to obtain appropriate legal advice.

I am not a lawyer, and this is not legal advice.

What is CIRCIA?

In general, the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) amends Title XXII of the Homeland Security Act of 2002 and requires covered private-sector entities to submit reports to the Cybersecurity and Infrastructure Security Agency (CISA) when they suffer a “covered cybersecurity incident or make a ransomware payment” within 72 hours after the incident has occurred. (H.R. 2471 § 2242(a)(1), H.R. 2471 § 2242(a)(2))

A covered private-sector entity would also be required to submit a supplemental report to CISA if “substantial new or different information becomes available or if the covered entity notifies the Agency (CISA) that the covered cyber incident at issue has concluded and has been fully mitigated and resolved. (H.R. 2471 § 2242(a)(3))

A covered private-sector entity, subject to the requirements, would also be required to preserve data relevant to the covered cyber incident or ransom payment in accordance with the procedures established in the final guidelines issued by CISA. (H.R. 2471 § 2242(a)(4))

There are some exceptions to the requirements (H.R. 2471 § 2242(a)(5)), Section 2242 outlines the required reporting of covered cyber incidents, ransomware payments, supplemental information, the preservation of information, and any exceptions.

What is a Covered Private-Sector Entity?

Section 2240 (Definitions) of Title XXII of the Homeland Security Act of 2002 defines a covered entity as, “an entity in a critical infrastructure sector, as defined in Presidential Policy Directive 21, that satisfies the definition established by the Director (of the Cybersecurity and Infrastructure Security Agency) in the final rule issued pursuant to section 2242(b).”

Presidential Policy Directive 21 (PPD-21) identified the following 16 critical infrastructure sectors:

• Chemical
• Commercial Facilities
• Communications
• Critical Manufacturing
• Dams
• Defense Industrial Base
• Emergency Services
• Energy
• Financial Services
• Food and Agriculture
• Government Facilities
• Healthcare and Public Health
• Information Technology
• Nuclear Reactors, Materials, and Waste
• Transportation Systems
• Water and Wastewater Systems

The reference to “...the definition established by the Director in the final rule issued pursuant to section 2242(b).” would come from the final ruling and from CISA on which private-sector entities would also be required to report.

If your organization falls within any of the critical infrastructure sectors, as defined in PPD-21, or designated by CISA after final rules have been published, you will potentially be required to report these incidents. It may be some time before CISA publishes these final guidelines, and CISA will be required to conduct an outreach and education campaign to let covered entities know about the reporting requirements (H.R. 2471 § 2242(e) - Outreach to Covered Entities).

What is a Covered Cybersecurity Incident?

Section 2240 defines a covered cyber incident as a “substantial cyber incident experienced by a covered entity that satisfies the definition and criteria established by the Director in the final rule issued pursuant to section 2242(b).” This essentially means whatever criteria CISA defines as a substantial cyber incident when final guidelines are published.

Section 2242(c)(2)(A) does state, at a minimum, what would constitute a covered cyber incident. This includes the following:

• A cyber incident that leads to substantial loss of confidentiality, integrity, or availability of such information system or network, or a serious impact on the safety and resiliency of operational systems and processes;
• A disruption of business or industrial operations, including due to a denial of service attack, ransomware attack, or exploitation of a zero-day vulnerability, against an information system or network, or an operational technology system or process;
• Unauthorized access or disruption of business or industrial operations due to loss of service facilitated through, or caused by, a compromise of a cloud service provider, managed service provider, or other third-party data hosting provider or by a supply chain compromise

Again, CISA will produce final guidelines on what is considered to be a covered cyber incident and what will need to be reported.

How does CIRCIA define Ransom Payment and Ransomware Attack?

Section 2240 defines ransom payment as “the transmission of any money or other property or asset, including virtual currency, or any portion thereof, which has at any time been delivered as ransom in connection with a ransomware attack.”

Section 2240 also defines ransomware attack as “an incident that includes the use or threat of use of unauthorized or malicious code on an information system, or the use or threat of use of another digital mechanism such as a denial of service attack, to interrupt or disrupt the operations of an information system or compromise the confidentiality, availability, or integrity of electronic data stored on, processed by, or transiting an information system to extort a demand for a ransom payment.”

This does not include any event where the demand for payment is “not genuine” or is “made in good faith by an entity in response to a specific request by the owner or operator of the information system”.

Overall, if a malicious actor has infected your organization’s systems through the use of a ransomware attack and has demanded a ransom payment, you will be required to report the incident to CISA.

What Information Would you Need to Report?

As we wait for clarification and guidelines from CISA, Section 2242(c)(4) does provide us with an outline of what information will need to be given when reporting a covered cyber incident. This information will include a description of the covered cyber incident that includes:

• Identification and a description of the function of the affected information systems, networks, or devices that were, or are reasonably believed to have been, affected by such cyber incident;
• A description of the unauthorized access with substantial loss of confidentiality, integrity, or availability of the affected information system or network or disruption of business or industrial operations;
• The estimated date range of such incident; and
• The impact on the operations of the covered entity (your organization).

Other details of reporting would include the following (where applicable):

• A description of the vulnerabilities exploited and the security defenses that were in place, as well as the tactics, techniques, and procedures used to perpetrate the covered cyber incident.
• Any identifying or contact information related to each actor reasonably believed to be responsible for such cyber incident. -Identification of the category or categories of information that was, or are reasonably believed to have been, accessed or acquired by an unauthorized person.

Section 2242(c)(5) outlines what information will need to be given when reporting a ransomware payment. This will include the following if applicable and available:

• A description of the ransomware attack, including the estimated date range of the attack.
• A description of the vulnerabilities, tactics, techniques, and procedures used to perpetrate the ransomware attack.
• Any identifying or contact information related to the actor or actors reasonably believed to be responsible for the ransomware attack.
• The name and other information that clearly identifies the covered entity that made the ransom payment or on whose behalf the payment was made.
• Contact information, such as telephone number or electronic mail address, that the CISA may use to contact the covered entity that made the ransom payment or an authorized agent of such covered entity, or, where applicable, the service provider of such covered entity acting with the express permission of, and at the direction of, that covered entity to assist with compliance with the requirements.
• The date of the ransom payment.
• The ransom payment demand, including the type of virtual currency or other commodity requested. -The ransom payment instructions, including information regarding where to send the payment, such as the virtual currency address or physical address the funds were requested to be sent to.
• The amount of the ransom payment.

Again, CISA will be providing final guidelines and educational material to help your organization meet the requirements of reporting. You will likely see these questions already provided to you in an online form during reporting.

What could happen if your organization does not report?

Section 2244 outlines noncompliance with required reporting. If your organization fails to comply, the CISA may issue a subpoena in a district court of the United States “to gather information sufficient to determine whether a covered cyber incident or ransom payment has occurred.” Section 2242(c)(2)(C) states, “A court may punish a failure to comply with a subpoena issued under this subsection as contempt of court.”

What should your organization do?

Even though this law is not in full effect, it is strongly recommended that you should already be reporting critical cybersecurity incidents or ransomware attacks to law enforcement or to a government organization that can properly assist you in dealing with these matters.

In the United States, these organizations include the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation’s (FBI) Internet Crime Complaint Center (IC3). You can also contact your local U.S. Secret Service Cyber Fraud Task Force Network Intrusion Team. These organizations will be able to initiate criminal investigations and offer their assistance to the best of their abilities.

As an organization, you should also look to implement technologies and procedures to help prepare for the upcoming requirements.

One good technology system to implement would be a SIEM (pronounced "sim"). A Security Information Event Management (SIEM) is a system designed to college system log (Syslog) messages from all your security appliances, networking devices, servers, and workstations into a single unified environment. A SIEM can offer real-time monitoring and analysis of events as well as tracking and logging of security data for compliance or auditing purposes. (ref. What is SIEM? - IBM)

There are various providers of SIEM applications that are out there on the market such as:

• Splunk Enterprise SIEM
• IBM QRadar
• SolarWinds SIEM Security and Monitoring
• Datadog
• AlienVault USM
• Rapid7 Insight IDR

There are also Free and Open-Source SIEM tools which are usually limited in their capabilities compared to their paid/enterprise versions.. This list includes:

• AlienVault OSSIM
• SIEM Monster Community Edition
• Wazuh
• Snort
• OSSEC
• Sagan
• Logit.io
• Prelude
• Splunk Free
• Security Onion
• Suricata
• Greylog

Analysis of the free and open-source products listed above can be found in this blog post of the THE TOP 14 FREE AND OPEN SOURCE SIEM TOOLS FOR 2022.

A good procedure to implement would be an Incident Response Plan. An Incident Response Plan is a set of tools and procedures that your security team can use to identify, eliminate, and recover from cybersecurity threats. It is designed to help your team respond quickly and uniformly against any type of external threat.

Being prepared to respond to an incident and having documented steps on how to respond and recover from an incident can save your organization critical time and money. Part of the Incident Response plan includes properly documenting and reporting the incident.

For more information on building your own Incident Response Plan, please visit the following resources:

Conclusion

The above information was just a high-level overview of the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) and its impending requirements for covered privately-owned companies operating in critical infrastructure sectors. It is likely that CISA will produce final guidelines within the next 18-24 months. However, you should immediately begin preparing your organization to meet these requirements when they are finally implemented.

For further information on this newly signed law, I will include some legal analyses which I found to be helpful.

I thank you for your time in reading this blog post and I hope that you found it informative and helpful. Please feel free to comment below or share with your network. Thank you!

(Blog image photographed by Harold Mendoza on Unsplash)

However, each server in the fleet has been assigned its own public IP address. If I have 10 web servers, it means that I must provision 10 public IP addresses. That could be a significant chunk of my public IP addresses that I theoretically rent from my Internet Service Provider (ISP). If my ISP gives me a /27 or /28 address block, then that could be a problem for other services I need to provide a public IP address to (30 useable IP addresses for a /27 and 14 useable IP addresses for a /28).

Provisioning all those public IP addresses also increases my company’s digital footprint. For 10 webservers, that could give hackers 10 different attack vectors.

Ouch! I do love my job, but I’m not trying to lose sleep overnight over it. So how can I fix this?

This is where a Reverse Proxy Server would be useful.

What is a Reverse Proxy Server?

According to NGINX (pronounced “Engine X”, one of the most commonly used open-sourced web servers used for web serving, reverse proxying, caching, load balancing, media streaming, and more), a reverse proxy server is a type of proxy server which directs client requests to the appropriate backend server. It provides an additional level of abstraction and control to ensure the smooth flow of network traffic between clients and servers.

In layman’s terms, it’s a server that sits in front of your other web servers and acts as a “traffic cop,” directing requests to the appropriate server.

Other benefits of having a Reverse Proxy Server include the following:

• Improved Security: A reverse proxy server intercepts requests headed for your backend servers. This protects the identities of your backend servers against common web attacks. By placing your pool of web servers behind a reverse proxy, you only expose one server to the public internet, further protecting all your backend servers.

• Load Balancing: If your web application is hosted across multiple servers, the Reverse Proxy Server can distribute web requests across your pool of servers preventing any single server from being overloaded.

• Improved Performance: A reverse proxy server can compress both inbound and outbound data, cache content, and conduct SSL encryption, resulting in faster performance.

How does a Reverse Proxy Work?

If you look at the above diagram may make you a bit confused about how a reverse proxy would work. Let me try to simplify this process in a step-by-step manner:

1. A public user will first request to access your web server via the public internet.
2. The corporate firewall receives the request on the publicly facing interface, inspects the request, and forwards it to the Reverse Proxy in the private corporate network.
3. The Reverse Proxy receives the incoming request and inspects the destination address.
4. The Reverse Proxy then checks the reverse proxy configuration file to determine the appropriate private IP address to send the request to.
5. The incoming request is then sent to the appropriate backend web server.
6. The backend web server then sends the response data back to the public user.

Demonstration Setup

To demonstrate this concept of a reverse proxy, I set up a lab environment on VMware Workstation Pro using an NGINX virtual machine and four different pre-made web-application virtual machines from Bitnami.

Deploying Virtual Machines

Bitnami by VMware provides pre-packaged images for the automated setup of popular server software on Windows, Mac OS X, and Linux platforms. Bitnami also provides pre-packaged virtual machines. Using the Bitnami Virtual Machine (VM) image requires hypervisor software such as VMware Player or VirtualBox. Both of these hypervisors are available free of charge.

In this lab, I chose the following Bitnami Virtual Machines:

• LAMP
• Node.JS
• MediaWiki
• Wordpress

This gave me a decent sample of various web applications. I also installed NGINX on a virtual machine running Ubuntu Server 20.04 LTS.

Once I had the VMs running, logged in to each VM and assigned a static IP address. I kept it simple and assigned static private addresses in sequential order. I didn’t start with a .1 address because that would be the gateway address to the virtual subnet (VLAN).

• NGINX – 192.168.80.2
• LAMP – 192.168.80.3
• Node.JS – 192.168.80.4
• MediaWiki – 192.168.80.5
• WordPress – 192.168.80.6

The images above show my 5 virtual machines running in VMware Workstation Pro all with the appropriately assigned addresses, and running as expected in their default states.

NGINX Configuration Files

Once I had the static IP addresses configured, I had to edit the reverse proxy configuration file on the NGINX virtual machine. First I need to look at the default NGINX configuration file.

NGINX uses text-based configuration files written in a particular format. The default configuration file is named nginx.confand is commonly located in the /etc/nginx directory. The location of the nginx.conf depends on the package system used to install NGINX and the operating system. It is may be found in /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx. An example of the NGINX configuration file can be found here.

Here is what my default nginx.conf looks like:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}


#mail {
#       # See sample authentication script at:
#       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#       # auth_http localhost/auth.php;
#       # pop3_capabilities "TOP" "USER";
#       # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#       server {
#               listen     localhost:110;
#               protocol   pop3;
#               proxy      on;
#       }
#
#       server {
#               listen     localhost:143;
#               protocol   imap;
#               proxy      on;
#       }
#}

Now, this may seem like a lot of information, but most of the configuration is commented out. The NGINX Beginner's Guide explains this structure in an easier manner:

I can see that in the http{ top-level directive, referred to as a context, there is a section for Virtual Host Configs that includes the following:

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;

This means that any configuration files I place in /etc/nginx/conf.d/ and /etc/nginx/sites-enabled/ will be included into the default NGINX configuration. I don't exactly want to place my reverse proxy configuration straight into the default nginx.conf because that could make things a little unorganized.

If I look into the /etc/nginx directory, I can see that there is also a /sites-available directory available.

What's the difference between sites-available and sites-enabled?

The sites-available folder will hold all of your virtual host configuration files, whether you use them or not.

The sites-enabled folder will contain symbolic links to files in the sites-available folder. This will allow you to disable your virtual host just by removing the symbolic link.

I will now create my reverse-proxy.conf and place it in the /etc/nginx/sites-available/ directory.

cd etc/nginx/sites-available/

sudo vi reverse-proxy.conf

I will then paste the following strings into the file:

server {
    listen 80;
    server_name lamp.bitnami.local;
    location / {
        proxy_pass http://192.168.80.3;
        }
}

server {
    listen 80;
    server_name nodejs.bitnami.local;
    location / {
        proxy_pass http://192.168.80.4;
    }
}

server {
    listen 80;
    server_name media.bitnami.local;
    location / {
        proxy_pass http://192.168.80.5;
    }
}

server {
    listen 80;
    server_name wp.bitnami.local;
    location / {
        proxy_pass http://192.168.80.6;
    }
}

In the reverse-proxy.conf I have included several server blocks that are all listening on port 80 (http). Each sever``` block will have aserver_name``` directive. When a request comes in, NGINX will test only the request’s header field “Host” to determine which server the request should be routed to. If its value does not match any server name, or the request does not contain this header field at all, then NGINX will route the request to the default server for this port. In the configuration above, the default server is the first one — which is NGINX’s standard default behavior.

You can also explicitly set which server should be default, with the default_server parameter in the listen directive. If I wanted to set my LAMP application to be the default, I would have placed the following into the configuration:

server {
    listen 80 default_server;
    server_name lamp.bitnami.local;
    location / {
        proxy_pass http://192.168.80.3;
        }
}

However, if requests without the "Host" header field (requests without a pre-defined URL) should not be allowed, I could insert the following server block that just drops the request:

server {
    listen      80;
    server_name "";
    return      444;
}

Here, the server_name is set to an empty string that will match requests without the “Host” header field, and a special NGINX’s non-standard code 444 is returned that closes the connection. I will add this block to my reverse-proxy.conf.

Configuring My Local DNS

Since these web applications are not available to the public internet, I now have to edit my hosts file on my local machine to assume the role of a Domain Name Service (DNS).

On a Windows 10 computer, you will have to search for Notepad in the Windows Search menu and choose to Run as administrator. Once you’ve done so, open up the following file using the File -> Open feature. The hosts file is located in the C:\Windows\System32\drivers\etc folder.

Feel free to check out the tutorial in the link below if you're having trouble with this.

I will then edit the hosts inserting entries into the file by placing the IP address of the NGINX proxy next to the server_name entries of the web applications. All the server_name entries will have the same IP address so that the web requests can go through the NGINX reverse proxy. Save the file when this is complete.

Testing the Reverse Proxy

Now we will test the reverse proxy. By default, most browsers will assume that you are trying to connect to a website that has a SSL/TLS certificate installed and will insert https:// into your request. Therefore, I will have to type out the entire address.

http://lamp.bitnami.local

http://nodejs.bitnami.local

http://media.bitnami.local

http://wp.bitnami.local

Everything looks good! I can now look at the NGINX access.log to see the requests. This file is located at /var/log/nginx/access.log

This was just a simple demonstration of how a reverse proxy works and how it can be easily configured. There are many options you can include in the reverse-proxy.conf such as passing request headers and choosing an outgoing IP address. Check out the NGINX documentation for more information.

For a complete tutorial on NGINX, please feel free to look at The NGINX Handbook from FreeCodeCamp below.

Thank you for your time and please leave some comments below.

UPDATE:5/5/2022 Found this awesome webinar from NGINX if you're interested in getting a hands-on demonstration:

Hashnode Blog Photo by Jaffer Nizami on Unsplash

What is OpenStack?

OpenStack is an open-source cloud computing platform that can be used to manage distributed computing, network, and storage resources. You can use OpenStack to build private and public clouds. Resources can be managed through a dashboard, giving administrators control while empowering users to provision resources through a web interface.

OpenStack is also fully open-source meaning there are no licensing costs. It is available under the Apache License which means that it can be used free of charge. Even if deployed within one of the available distributions, vendors must not add any additional licensing costs (ref OpenStack vs VMware: Bringing costs down). However, OpenStack is also not just a simple technology that you install and use. It has a certain degree of complexity and takes time to fully understand and maximize utilization. Organizations, like Canonical and Red Hat, provide professional services and support to help manage your OpenStack environment.

How to use OpenStack?

Today I will be demonstrating how to deploy and configure an OpenStack cloud. However, I will be utilizing MicroStack. MicroStack is a micro cloud platform based on OpenStack, designed for the edge and small-scale data center deployments, that can be installed and maintained with minimal effort. Canonical provides easy-to-understand tutorials to learn more about OpenStack. (For this demonstration, I used these installation instructions versus the one in the tutorials. But they are the same instructions.

Create the VM

The first requirements are to have a physical machine to work on. The tutorial's requirements are as follows:

• The latest Ubuntu LTS installed.

• Multi-core CPU

• 8 GB of RAM

• 100 GB of storage

In fact, I'm just going to create a virtual machine in VMware Workstation Pro. Something like this should be perfect for this demonstration:

MicroStack Deployment

If you follow along in the tutorial, the commands are pretty simple.

First, execute the following command to install the MicroStack snap:

sudo snap install microstack --devmode --beta

When the installation process has finished, I will view information on the installed snap by entering the command: :

snap list microstack

Looking good so far!

Initialization

I will then initialize MicroStack. According to the documentation, this will "automatically deploy, configures, and starts OpenStack services. In particular, it will create the database, networks, an image, several flavors, and ICMP/SSH security groups." The command I will use is:

sudo microstack init --auto --control

Apparently, this can take quite a bit of time depending on your system.

Verification

Once the initialization is finished, you can run a few commands to check functionality. The standard OpenStack client comes pre-installed and is invoked like so:

microstack.openstack <command>

To list the default image, run:

microstack.openstack image list

To get the default list of flavors:

microstack.openstack flavor list

Now we are getting somewhere!

Create an Instance

I will now create an instance (virtual machine) named 'test' based on the 'cirros' image. CirrOS is a minimal Linux distribution that was designed for use as a test image on clouds such as OpenStack Compute. You can download a CirrOS image in various formats from the CirrOS download page I will use the command:

microstack launch cirros -name test

Now I will connect to the instance via ssh using the generated ssh keys that were shown in the output. (I just copied the command from the resulting output from creating the instance.)

I then typed in ip a to get a quick status of the networking.

Access the Cloud Dashboard

Now for the fun stuff!

To access the OpenStack (MicroStack) Cloud Dashboard, I need to open a browser with the IP address of the virtual machine running MicroStack. So let me browse over to the IP address.

Now I need a username and password. The tutorial states that the username is admin, but I also need to generate a password from the terminal console. The password is obtained by entering the command:

sudo snap get microstack config.credentials.keystone-password

Now I need to enter the username admin and generated password into the console.

And I can now look at my entire OpenStack environment on a Cloud Dashboard.

If I select Instances I should be able to see the test instance that we created in the terminal.

Where to go from here?

Now that you have your MicroStack environment deployed, you can get started with the basics of OpenStack by going through the OpenStack Tutorials by Canonical.

Create your own micro cloud environment and have some fun!

There is even an OpenStack Cheat Sheet should you need it. I'm pretty sure you will if you're new to OpenStack.

Thank you for your time during this tutorial/demonstration. Please feel free to leave any comments below!

Well, my day job as an Information Systems & Security Manager got a bit hectic in late October and November. But then there were also the holidays and spending time with my (now) fiancée. Yea! I'm also surprised that she said yes!

In late October, I completed both the VMware Install, Configure, Manage (ICM) vSphere and Optimize and Scale (O&S) vSphere courses through the IT Academy at Cleveland Community College. These virtual courses are $180 tuition plus $16 for a digital textbook for each course; definitely more affordable than a corporate training program. These courses count as the required courses to take the VMware Certified Professional - Data Center Virtualization certification exam.

If you take both ICM and O&$ courses, you will get 70% off both the VCTA and VCP-DCV Exams!

In early November, I went and passed the VMware Certified Technical Associate - Data Center Virtualization certification exam. This certification is the entry-level VMware vShpere certification that validates a basic understanding of virtualization and vSphere concepts. I probably should have prepared more, but I barely passed.

In late November, I started to study for the AWS Certig also studied and passed the AWS Certified Solutions Architect - Professional certification in mid-January.

It was a pretty challenging exam, but I credit my success to the following sources:

• The Cloud Architect Career Development program at Go Cloud Architects

This program helped me understand the technologies and architectures behind public and private infrastructures more so than just learning the AWS services. I credit Mike Gibbs for giving me the confidence and knowledge to help me succeed. Mike and his team also put out a free comprehensive AWS Certified Solutions Architect - Professional study guide.

• AWS Certified Solutions Architect Professional course from Digital Cloud

Neil Davis' AWS Certified Solutions Architect Professional course really helped me understand all the AWS services and how they work together. This was easy to understand and came with some fun hands-on labs. I enjoyed his course.

• AWS Certified Solutions Architect Professional Practice Exams 2022 from Tutorials Dojo

I believe that these practice exams were probably more difficult than the actual exam. But the explanations that came with these questions were amazing and thorough. Overall, I thank Jon Bonso and his team for preparing me for this tough exam.

In late January, our company was in Las Vegas, NV hosting our winter conference at Caesars Palace. Part of my role includes setup and teardown of the conference, so I was out there for about 6 long days. I'm finally recovering from that trip.

During that conference, I also was able to present to a group of foodservice distributor executives on Ransomware. Although the topic can get super in-depth, I tried to keep it to a high-level and easy-to-understand conversation on what these executives should be asking from their IT support. Some of these companies outsource their IT Support to MSPs. I hope that my presentation made complete sense to them. If not, I'll go into our studio at work and record a better presentation.

Now, I am currently studying for the Certified Information Systems Security Professional exam which I intend on taking around the end of March. I do plan on building more cloud projects and documenting/blogging more about my adventures, though!

I love infrastructure and I love security, so I need to get all together and start producing quality projects.

Thanks again for your patience!

-Brandon

Today, we are going to finish off the LAMP stack by adding the scripting layer. This layer is where the code of your web application will run. In this demonstration, PHP will be used in this layer. However, a developer may want to use other scripting languages, such as Python or Perl.

I currently have my Ubuntu Server (operating system layer) configured with Apache2 (web server layer) and MySQL (database layer). Let me check for updates and make sure that I have the latest packages. I will enter the following command:

sudu apt update & sudo apt upgrade -y

Followed by entering my password (if needed).

This will get me an updated list of Ubuntu Server packages and install any available upgrades of all packages currently installed on the system.

Now if it has been a while since I last updated, it may take a minute or two.

My next step will be to bring up the Ubuntu Server documentation on PHP. This will give me a step-by-step guide to installing the PHP service.

Since I already have the Apache2 Web Server and MySQL Database installed, I can refer to just the Apache2 and MySQL sections in the documentation.

To install PHP and the Apache PHP module I will enter the following command:

sudo apt install php libapache2-mod-php

I will then enter Y to continue with the installation.

Once the installation is complete, I will then refer to the documentation to locate the command to use MySQL with PHP. To use MySQL with PHP you should install the php-mysql package with the following command:

sudo apt install php-mysql

Again, you will enter Y to continue with the installation.

When the MySQL PHP package is installed, you should restart the Apache2 Web Server to run PHP scripts. You will run the following command:

sudo systemctl restart apache2.service

You will then need to check to see if the PHP service is configured correctly. What I prefer to do is to create a phpinfo.php file in the DocumentRoot directory of the Apache2 web server. In Apache2, this directory is located at /var/www/html.

In the phpinfo.php file, I will place the following code into the file using VIM:

<?php
  phpinfo();
?>

The following image shows me changing to the /var/www/html directory. Listing the contents of the directory with ls. And then creating a file using the command sudo vim phpinfo.php.

Once in VIM, I will insert and save the snippet of code. Press the letter I to switch into insert mode so that you can start editing the file.

Once you're done, press the escape key Esc to get out of insert mode and back to command mode. Type :wq to save and exit your file.

I will then enter the command ls to make sure the phpinfo.php file is in my /var/www/html directory.

I will then restart the Apache2 service with the following command:

sudo systemctl restart apache2

I will then call up my phpinfo.php file from my web browser. This will verify that both the Apache2 web server and the PHP service are running correctly. Point your browser to http://hostname/phpinfo.php. This will display the values of various PHP configuration parameters.

Prior to pubically deploying your application, you should remove the phpinfo.php file completely. Leaving this page on your webserver directory will give potential hackers more information on the services you are running, which may cause them to exploit known vulnerabilities. Therefore, you (as the administrator) or your developer needs to remove the file as soon as possible.

This concludes my tutorial on installing and configuring PHP on your LAMP stack. Please feel free to leave comments below!

Thanks again!

According to the documentation, MySQL is the most popular Open Source SQL database management system and is developed, distributed, and supported by Oracle Corporation. The MySQL Database Server is very fast, reliable, scalable, and easy to use and can work in client/server or embedded systems.

Apparently, the official way to pronounce “MySQL” is “My Ess Que Ell” (not “my see-quel”). But they do not mind if you pronounce it as “my see-quel” or in some other localized way. MySQL is also named after co-founder Monty Widenius's daughter, My.

However, you can use other database alternatives in your LAMP stack such as PostgreSQL, MariaDB, or MongoDB (for a NoSQL database).

Developers, such as the one that I work with, love using MySQL and find many uses for it. In a LAMP stack, the MySQL database is used for storing application data.

So how do we install and configure MySQL for use? In this short tutorial, I will configure a MySQL database for use on an Ubuntu Server VM.

Canonical (the software company that provides commercial support and related services for the Ubuntu distribution) provides an easy-to-understand Ubuntu server documentation guide.

Another source of documentation that I will reference is the MySQL 8.0 Reference Manual. This documentation is more MySQL-specific but is very useful.

Even if I have configured the service hundreds of times, I like to have the documentation ready on a screen with me. Most times I will be doing this type of project at work and will end up with 20 different distractions before I get this completed and ready for my developer to use.

Let's first pull up the Ubuntu Server documentation on MySQL.

The first command looks easy enough....

sudo apt install mysql-server

Do I want to continue? Press Y for Yes.

Now the MySQL packages are installing.

Depending on your connection, the installation takes a minute or two. You will see the progress bar down at the bottom.

Once you receive your terminal prompt again, type in the following command to check the status of the service via systemd:

sudo service mysql status

Then you can check the network status of the MySQL service by sunning the ss command:

sudo ss -tap | grep mysql

Once I confirmed that the MySQL service is running correctly, I will run the mysql_secure_installation command. This MySQL Installation-related program is a guided setup to improve the security of your MySQL installation. As stated in the MySQL documentation, this program enables you to improve the security of your MySQL installation in the following ways:

• You can set a password for root accounts.

• You can remove root accounts that are accessible from outside the local host.

• You can remove anonymous-user accounts.

• You can remove the test database (which by default can be accessed by all users, even anonymous users), and privileges that permit anyone to access databases with names that start with test_.

When executed, mysql_secure_installation prompts you to determine which actions to perform.

Let us see it in action....

The command is sudo mysql_secure_installation

First question I get is...

Would you like to setup VALIDATE PASSWORD component?

In the paragraph above the question, it states that the VALIDATE PASSWORD component checks for the strength of a password. As a Systems Administrator with security in mind, this seems like a good feature. Let me press Y for yes.

The next question I receive is to select which level of password validation policy I would like to implement. My choices are as follows:

LOW: At least 8 characters in length.

MEDIUM: At least 8 characters in length, numeric, mixed case, and special characters

STRONG: At least 8 characters in length, numeric, mixed case, and special characters, and no dictionary words.

That's going to be STRONG for me. I want at least 8 characters, mixed case, numbers, special characters, and no dictionary words.

Now time to set up a password for the root account. As you can see in the image below, my password had an estimated score of 100. Since I am happy with my password, I will then select Y to continue.

Now I am asked if I want to remove Anonymous Users. If this was a test database with no data of any value, I wouldn't care about this. But since this is database will be used in production, let's go ahead and remove Anonymous Users.

I am now asked if I should only allow the root user to connect from the 'localhost'. This means that the root user can only log in to the MySQL service from the local virtual machine. If a user connects to the virtual machine via SSH and then to the root account on MySQL service, that will still be allowed. I am going to select Y for this.

Then I am asked if I want to remove the test database. I will leave it for now and select N.

The next question asks me to Reload the privilege tables. This will ensure that all changes made so far will go into effect.

Looks like I am all done with the mysql_secure_installation program!

Now time to log in to the MySQL service and see what users are listed. The command I will use is sudo mysql -u root -p. I will then be prompted to enter my password.

Let me try that again! Then follow it up with this SQL command to get the list of users: SELECT DISTINCT User from mysql.user;

I will not create my user account and request a randomly generated password. This will be the user account that I give to my developer, assuming his name is also Brandon (Which would be strange!):

CREATE USER brandon@localhost IDENTIFIED BY RANDOM PASSWORD;

Then I will grant my user account all privileges, which will make it an Administrator account. I will then need to flush the privileges so they go into effect:

GRANT ALL PRIVILEGES ON *.* TO brandon@localhost;

Followed by:

FLUSH PRIVILEGES;

Now I will try to log in to that user account I just created.

sudo myspl -u brandon -p

From there I can list the tables:

```SHOW DATABASES;"

Looks like our MySQL service is ready for use. I will then share the user credentials with my web developer for his use.

Thank you for taking to time to go through this tutorial with me! Please feel free to leave any comments below.

Low and behold there was an error right on my phone screen....

Now that I think about it, I may have heard about it from one of our member's Managed Service Provider in an email not too long ago after I told the member that their SPF record was incorrect and their emails were not being delivered successfully. That is another story...

So what really was the issue?

As you can see in the picture above, the warning I received was that the certificate did not match the URL.

So let's take a look at the certificate in more detail...

The certificate was issued to "www.frostyacres.com".

But that looks correct, right?

In a sense, it does. However, the first image was making a request to "frostyacres.com" and not "www.frostyacres.com". The browser is looking for the certificate for "frostyacres.com".

So how do you fix it?

To fix this issue, you must go back and have a cert reissued for "frostyacres.com" with "www.frostyacres.com" as a Certificate Subject Alternative Name.

I should have known this because this is how my SSL certificate is configured on my personal website brandonscloud.com.

The certificate for my personal website is issued to brandonscloud.com and has www.brandonscloud.com as an Alternative Name

Since we used a free SSL certificate from LetsEncrpty and our web server is running on a common Linux distribution, I had to run several terminal commands to get Certbot to reissue the certificate. Certbot is a free, open-source software tool for automatically using Let’s Encrypt certificates on manually-administrated websites to enable HTTPS.

Several commands later, I had a valid certificate.

However, I did manage to break a few things but had my web developer next to me and we quickly got the website back online within a few minutes.

The new certificate looks good and we shouldn't see any issues.

I hope you enjoyed the read. Please feel free to leave any comments.

The biggest thing I took away from Day #1 was to take the time to just write. Practice makes perfect.

Why do I write?

That is an interesting question.... I started off by wanting to build a portfolio of cloud infrastructure projects that I was working on, and I wanted to have a place where I can document all my projects for not just myself, but for other technology professionals getting into various infrastructure projects. It turns out potential employers like to see these write-ups as well, too. It's basically a win-win for everyone!

My girlfriend is also a published author and she really thought it would be a good idea for me to write short technical pieces. She is also currently working on her Master of Arts in Professional Writing (Applied Writing) and recently accepted a position that would allow her to create more technical content. Super proud of her!!!!

How did I get to Hashnode?

I tried looking into other platforms, but a fellow student of mine from Western Governers University introduced me to Hashnode a couple of months ago. I started to give it a shot and turns out that it works really well for what I am trying to accomplish.

So between what my goals were and my amazing girlfriend, it really motivated me to write technical content pieces. If you have read some of my previous blogs, then you know that I am not a developer but more of a systems and infrastructure professional. I feel that I need to continue to write more so that I can communicate better with everyone, not just professionally but also in my personal relationships.

Where will I go from here?

Who really knows? My biggest struggle is just taking the time to write. I need to do better, and I will do better.

Thank you, Hashnode, for providing an amazing platform. I hope that you will continue to become a better community for content creators for years to come.

Today we're going to quickly cover the letter "A" in LAMP; Apache.

As a Systems Manager or Infrastructure Architect, you don't need to know how to create a complete web application from top to bottom. But you should be familiar with how these services work together and how to quickly deploy the backend infrastructure when needed.

In a previous post, I went over how to deploy the "L" portion of the stack by quickly deploying an Ubuntu Server 20.04 LTS VM on an ESXi host.

I've just logged in to my Virtual Machine using the Putty SSH Client application. I find this easier than working on a console from the ESXi host because I can easily copy and paste commands into the terminal through Putty. As you can see, the Server is pretty up to date.

Next, I will bring up the Ubuntu Server documentation on installing Apache.

You can use the above documentation or even use the tutorial lesson provided by Ubuntu.

I will then type in the following command to install the Apache webserver:

sudo apt install apache2

The console will then ask me if I want to continue. Of course, I do!

There shouldn't be any errors and you will then be brought back to your command prompt.

We can now test out your Apache2 installation by typing the IP address for the webserver into a browser page. Be sure to have port 80 and port 443 allowed through your UFW.

It works!

That's all you need to do. You can now pass this on to your web developer for use.

Nice and easy. Part 3 is the "M" portion; MySQL. Coming soon!

Thanks again for reading!

Now I could just have a blank template server and then adjust my virtual machine settings as needed, but that wouldn’t be as much fun as doing it from scratch. However, Ubuntu does provide a method of automating server installs via a configuration file. This process is different from the cloud automation YAML files or playbooks (ie. Chef, Ansible, Puppet, Terraform, etc.) that you hear about today. This automates the installation of the Operating System by answering all the configuration questions ahead of time.

Since I am somewhat of a Linux newb and I am currently studying for the CompTIA Linux+ certification, getting some practice with Linux commands is always good. As a good method of habit to have the Ubuntu Server Guide open while I work. The documentation is pretty thorough, and I can quickly search for terms and find the correct documentation to help me.

Register the Virtual Machine

In my work vSphere environment, we utilize the vCenter Server advanced server management software. This virtual appliance provides us with a centralized platform to control our entire vSphere environment on one single console. I am a big fan of using the vCenter Server as it gives me insight across all my ESXi hosts.

In this demonstration, I will be installing the Ubuntu Server VM on an ESXi server provided by Mike Gibbs and his team at Go Cloud Architect. This server access is made available to students of the Cloud Architect Career Development course. Students share access to their ESXi servers to build their virtual machines and cloud infrastructure.

First, we need to allocate the computing resources for the Virtual Machine. I first will click on Create /Register VM.

Then I will need to specify a unique name and OS for the virtual machine. If you mess up the name, you can always change it later. I will also select Linux as the Guest OS Family and Ubuntu Linux (64-Bit) as the Guest OS Version.

Next, I will need to select where I will store the virtual machine’s files and its’ virtual disks. Since this server has only one storage location, I will select datastore1.

Side note.... Storage locations for ESXi servers do not have to be physically on the server. You can configure a connection to a SAN (Storage Area Network) to store your virtual machines. Quoting the documentation, using ESXi with a SAN improves flexibility, efficiency, and reliability. Using ESXi with a SAN also supports centralized management, failover, and load balancing technologies.

I will then customize the Virtual Hardware and edit the VM options. According to the Ubuntu Server documentation, the recommended system requirements are: • CPU: 1 gigahertz or better • RAM: 1 gigabyte or more • Disk: a minimum of 2.5 gigabytes

Depending on the usage of the server, I will not overload my VM with unnecessary computing resources. If the application calls for 1 vCPUs, 4GB of RAM, and 10GB of storage, I’ll usually allocate 2vCPUS, 8GB of RAM, and at least 20GB of storage. I don’t want the application to use all of the VM’s allocated resources, so I will double what is required in case of resource spikes caused by the operating system.

Since I am only using this server as a demonstration and this is a server provided by Go Cloud Architect, I will keep the resources down to a minimum. I can add things such as additional virtual Hard Disks, Network Adapters, and even CD/DVD drives. For the CD/DVD Media, you will need to change the selection to Datastore ISO File, then select the .ISO file which corresponds to the Operating System which you are trying to install.

In the VM Options menu, you can configure different types of Boot Options and advanced settings. Typically, I do not use these options, but they are there if you need them.

You will then review your selection and then select Finish to deploy the Virtual Machine on the ESXi host.

Once your VM is registered in the list on your ESXi host, you will select your Virtual Machine then select Power On. You will see your machine power on in the provided window. To get a better view, select Console to open a console window.

You can even click on the provided preview window and a small console window will open.

Installing and Configuring the Operating System

Now it’s time to go through the options to configure the OS. Almost there, my friends! After selecting the appropriate language option, you will then be taken into the Network Options.

In the Network Connections menu, you can configure your virtual network interface. As a good rule of thumb, servers will almost always have a static private IP address. If you keep your server on DHCP and it is assigned a different IP address, some other services trying to connect to it will likely be unable to find the server on your network. You can assign your static private IP address here or wait to do it after the installation of the Operating System. In this scenario, I will leave it as is.

In the section labeled Guided Storage Configuration you will see several options. If you do not know what to select, the Ubuntu Server documentation for this section will help. The documentation states the following:

A couple of things to note… LVM stands for Logical Volume Management. It is a system of managing logical volumes or filesystems, that is much more advanced and flexible than the traditional method of partitioning a disk into one or more segments and formatting that partition with a filesystem.

LUKS stands for Linux Unified Key Setup-on-disk-format and is used for full-disk encryption. This is similar to the Windows Bitlocker Drive encryption service and will require the user to enter in a passphrase each time the system boots. This could be problematic if your server reboots automatically for updates.

I usually keep the default settings and move on to Storage Configuration where I will review the options and select Done when I am satisfied with the partitions.

You will then select Continue on the Confirm Destructive Action screen.

The next window allows you to set up a profile for the administrator account and select a hostname, then chose a complex password. For this exercise, I will keep things simple.

Then I will enable the Install OpenSSH Server setup option for remote access to the server. Since this virtual machine is in my private network, and not exposed to the public internet, there is minimal risk of attacks.

After the OpenSSH menu, you can select from a list of Featured Server Snaps. This feature could help should you have the need for some of these services (ie Docker, AWS CLI, etc). But for now, I will leave it blank and select Done to begin the installation of the operating system.

Once the installation is complete, you will select Reboot Now to reboot the Virtual Machine.

If you do not see a login prompt after reboot, press Enter on your keyboard, and the login prompt will appear.

You will then log in to your Ubuntu Server with the credentials that you provided during the setup process.

Since I installed the OpenSSH server during the OS configuration, I can now use an SSH client, such as Putty, to connect to the Ubuntu Server. This will make it easier for me to copy and paste Linux commands into the terminal session.

Once I am logged in to my Ubuntu Server, the first thing I typically like to do is to update and upgrade the Operating System packages using the following commands:

sudo apt update && sudo apt upgrade -y

From there, I will enable the default host-based firewall tool for Ubuntu named the Uncomplicated Firewall (UFW). Typically I will know what services should be allowed to the server. For instance, if I know that this server will be used as a web server, I will allow access to ports 22 (SSH), 80 (HTTP), and 443 (HTTPS) using the following commands:

sudu ufw enable

sudo ufw allow ssh

sudo ufw allow http

sudo ufw allow https

sudu ufw status

Always check the documentation to see if there are commands you could use to allow other services to your server.

My next step would be to create authorized user accounts. For example, my Web Developer needs access to the server, I would create an appropriate level account for him. In this scenario, I would give him root/administrator level permissions. I would use the following commands:

sudo adduser webdev

sudo adduser webdev sudo

From there, it is up to the Web Developer what applications or services he wants to install on the server. I have met the requirement to produce a functioning Ubuntu Server Virtual Machine.

Thank you for your time in reading this! I hope you enjoyed this post.

A common question I get is “How do I connect to the VPN while I am traveling, and only have registered my laptop to the airplane Wi-Fi? Paying for a second device (mobile phone) to access the in-flight Wi-Fi would be costly.”

That is a good question! Unlike me, some people do like to get work done during a long flight. And we all know how not secure in-flight Wi-Fi is. In-Flight Wi-Fi connections are essentially the same public Wi-Fi hotspots that are used on the ground. Even paying for access does not mean your device is safe.

As a rule of thumb, using a VPN connection is always recommended while conducting work activities on your laptop, especially from public Wi-Fi networks and hotspots. Just because you’re in the air, doesn’t mean that your data can’t be stolen.

Also, the reliability of these connections is also not guaranteed. In-flight Wi-Fi from 30,000 feet still must travel through multiple routers and connections before it gets to its destination. To see how In-Flight Wi-Fi works, check out this article from Reader’s Digest.

So what can we do?

Even with your phone in Airplane mode, you can still authenticate with the Duo Mobile app using a Mobile Passcode. This works anywhere, even in places where you don't have an internet connection or can't get cell service.

I then remember that Two-Factor Authentication for Meraki Client VPN supports push, phone call, or passcode authentication for desktop and mobile client connections. Perfect! I may have a solution!

How do we fix it?

On the Duo Mobile App, the user will need to tap the down indicator on the Duo-Protected Account to get a one-time passcode for login.

Then when the user logs in to their VPN connection, the user will append (add to the end of) their password a comma followed by the six-digit passcode generated in their Duo Mobile app. For example:

username: bob

password: hunter2,123456

These passcodes are for one-time use only. If a user cannot connect using the current mobile passcode on the Duo Mobile App, they will have to press the blue circular arrows and regenerate a mobile passcode. Then the user will enter that new passcode after the comma that is appended to their password.

Although I have not tested this out on a flight, I did simulate by putting my phone on "airplane" mode and connecting to my corporate VPN using the passcode that was generated in the Duo Mobile app.

I was able to get the instructions out to my users today. So fingers crossed that it works for them!

Thanks for reading!

SIDE NOTE.... Duo Security just rolled out their new online learning platform. It's free to Duo customers and has a few certification paths. I have gone through most of the material and I have been learning a lot about the various options there are. As a Duo Administrator, I thought it was awesome. Needless to say, I am a big fan of Duo Security.

Duo (owned by Cisco) is a user-centric access security platform that provides two-factor authentication, endpoint security, remote access solutions and more to protect sensitive data at scale for all users, all devices and all applications. They offer multiple products to help secure your organization from Multi-Factor Authentication, Device Trust, Remote Access, and Single-Sign-On.

Our company has been using Duo Security for Multi-Factor Authentication for several years now to protect some of our more critical assets, such as Remote Server access and Office 365 accounts. Outside of work purposes, I personally use the Duo Mobile app for a number of commercial services that allow for 2FA (ie. Amazon accounts, LinkedIn, banking, etc.)

When we ran a legacy Windows ADFS server, to federate our domain and allow a Single Sign-On for Office 365, we implemented Duo Authentication for Microsoft AD FS as our Multi-Factor Authentication (MFA) provider. It worked well with the AD FS 2.0 integration.

It worked fairly well and was pretty reliable. In January 2020, Microsoft officially ended support for Windows Server 2008 and it came time to update those ADFS servers.

Configuring a Windows ADFS server (and a web application proxy) isn't too challenging, and I was able to find enough articles online to get it working and installed within a few days. In a small business environment, it's hard to get any scheduled maintenance times during the week. Therefore I had to wait to get it done over the weekend; which isn't much of a problem.

Then it came to configuring the Duo Authentication for Microsoft AD FS. According to the Duo Security documentation, "the Duo AD FS module supports relying parties that use Microsoft's WS-Federation protocol, like Office 365, as well as SAML 2.0 federated logons for cloud apps like Google G Suite and salesforce.com." Duo Security provides step-by-step instructions which are pretty easy to understand. If you get stuck, then their Support personnel are quick to respond and easy to work with. I have had to call them a few times...

PROBLEM: After configuring the Duo AD FS module and testing, we were pretty confident that we had a good solution. Several days later, we had users reporting that they could not get email on their native mail apps on their mobile devices (iOS mail, Samsung Mail, etc.). One of those users was our CEO, who wanted to just use his iOS mail app. We tried to convince our users to move to the Outlook mobile app, but that was not successful. After some deep research, it turns out that these native mobile mail clients (at the time) ran on legacy Basic Authentication protocols. In a nutshell, Modern Authentication is more secure than Basic Authentication.

According to the Duo Security documentation, "this is a Microsoft -- not Duo -- limitation." But there is a solution! In the meantime, I had to disable the Duo AD FS module which did not provide secure our Office 365 accounts with MFA. Scary.... I know!

SOLUTION: After some research, I proposed implementing a Duo Access Gateway to completely replace our Microsoft AD FS.

"Duo Access Gateway is an on-premises solution that secures access to cloud applications with your users’ existing directory credentials (like Microsoft Active Directory or Google G Suite accounts) using the Security Assertion Markup Language (SAML) 2.0 authentication standard. SAML delegates authentication from a service provider to an identity provider, and is used for single sign-on (SSO) solutions."

In terms of solving my problem, "Duo protection for Microsoft 365 via DAG includes a Basic Auth option that allows users accessing Office 365 from clients that do not support Modern Auth to still log in using only their AD username and password." Bingo! This could work!

(Duo has recently updated their DUO AD FS plugin that may now support Basic Auth clients, but I wanted the chance to deploy a fancy app on a single Linux server.)

Deploy a DMZ Server

So my first objective was to get a Linux server up and running. The minimum server requirements are as follows:

1. Form Factor: Physical or virtual machine
2. Processor: Two processors of 2 GHz or faster
3. Memory: 4 GB RAM or greater
4. Disk Storage: 20 GB or greater
5. Operating System: See the Install Docker section of this document for supported Linux flavors and versions

I decided on running the Duo Access Gateway on Ubuntu Server LTS (Focal Fossa). Why Ubuntu Server? For one, it's free to use. Secondly, it is lightweight and doesn't require much maintaining unlike routinely checking on a Windows server.

Following the Ubuntu Server documentation, we can easily install Ubuntu Server. One major difference between Ubuntu Server and Ubuntu Desktop is that the graphical environment used for the Desktop Edition is not installed for the Server. After the Operating System is installed, I went ahead and completed some basic hardening of the server and allowed the following ports to be open on the server's host-based firewall called the UFW (which literally means Uncomplicated Firewall):

1. Open ports 80 and 443 in the perimeter firewall for HTTP and HTTPS external traffic to and from the server (HTTP automatically redirects to HTTPS).

2. Port 8443 will be used for administrative purposes. Restrict traffic to this port to only authorized networks.

3. Open a port for LDAP (default 389) or LDAPS (default 636) traffic from the server to your internal Active Directory Domain Controller(s) or OpenLDAP directory server if you are using an on-premises directory.

I will open up port 22 for SSH for server administration purposes, but would restrict that to the local network.

DISCLAIMER: I'm not going to go through the entire Ubuntu Server installation and hardening here, but I'll have that in another blog soon. I also am going to demonstrate this deployment on a local VM that is set up on VMware Workstation Pro, instead of pulling the VM on our corporate infrastructure.

After deploying the server, we can now follow the Duo Access Gateway for Linux documentation. The guide is not too technical and provides you step-by-step instructions on how to deploy the DAG.

Install Docker

In a nutshell, the DAG is deployed on a Docker container. So the first requirement is to install docker. The documentation even tells you that "Docker is a tool that allows Duo Access Gateway to run inside its own self-contained environment, called a “container”, on top of your host operating system." I then would select the "Ubuntu" tab to get the directions.

You will know that you installed Docker correctly when you get the following output after running the command "docker ps"

Install Docker Compose

From there you will install Docker Compose. According to the Docker documentation, Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Since DAG is deployed using a YAML file, you will need Docker Compose. You can verify that Docker Compose is working by typing docker-compose --version. You will see text similar to what is on the bottom of the following screenshot:

Install Duo Access Gateway

You then will download and install the Duo Access Gateway YAML file. You will be able to verify that the Duo Access Gateway container is running by typing docker ps and will see the output showing the container with a status of "up" similar to the following screenshot:

I can also verify that the installation was successful by navigating to https://URL-OF-ACCESS-GATEWAY:8443 from an internal network to log into the Duo Access Gateway admin console.

Yea! It's working!!!

Configure Duo Access Gateway

After choosing an Admin Console password, you will then configure your DAG with an appropriate hostname and uploading your SSL certificate and Private Key files. It's okay if you don't have one right now, you can continue through to the next screen.

The next step would be to configure your authentication source. Duo Access Gateway supports the following authentication sources:

• Active Directory
• OpenLDAP
• SAML IdP
• Google (OpenID Connect)
• Microsoft Azure (OpenID Connect)

For our situation, we opted to use our Active Directory as our source that end-users will use for primary authentication. Configuring this portion took a little time for me, as I had to also consult the Duo Protection for Microsoft 365 with Duo Access Gateway documentation. The documentation stated that I must use Active Directory as my authentication source as well as include specific AD attributes in the "Attributes" field.

Here is what it will look like when you're configuring Active Directory as your authentication source:

In the last portion of configuring your Duo Access Gateway, you can look at the Settings page and configure your "Fail Mode" (what happens when your DAG isn't available), Session Management (enhanced security for Admin console sessions), and other general settings (hostname, verbose logging, certificate change, and Admin password).

Before creating an application on the Duo Admin Panel, you need to download the certificate to obtain the token signing certificate (the downloaded file is named "dag.crt"). This is located on the Applications page in the Metadata section. A few of these variables will be used when you enable AD Federation to Microsoft 365 using your DAG.

That's it for deploying and configuring your Duo Access Gateway. But then you need to create and deploy the Microsoft 365 Application in Duo.

Create the Microsoft 365 Application in Duo

Following the documentation to create the Microsoft 365 application in Duo you will end up creating the application and then check the box next to Enable Basic Auth to allow legacy mail clients that do not support Modern Auth to still log in using only their AD username and password. When this option is configured users logging in with legacy mail clients will bypass Duo 2FA. That doesn't sound safe, right?

However, we deploy email profiles to mobile devices using Office 365 Device Security Polices. When the user enrolls their device using the Microsoft Company Portal application, they will still get the Duo 2FA when they sign in. Once the device is registered and checked for compliance, then the email profile is deployed and the user is only required to enter in their password. You still get the 2FA, but when enrolling the device.

Now back to creating the Microsoft 365 application in Duo.... Once your settings are set, you click on Save Configuration to generate a downloadable JSON configuration file which you will upload into your Duo Access Gateway.

Add the Microsoft 365 Application to Duo Access Gateway

Return to the Applications page of the DAG admin console session.

Click the Choose File button in the "Add Application" section of the page and locate the Microsoft 365 SAML application JSON file you downloaded from the Duo Admin Panel earlier. Click the Upload button after selecting the JSON configuration file.

The Microsoft 365 SAML application is added.

Since our organization had previously configured directory synchronization between your on-premises AD domain and Microsoft 365, we could skp the steps to enable directory sychronization in Microsoft 365.

Enable AD Federation to Microsoft 365 using DAG

Our next task was to enable AD federation to Microsoft/Office 365 using DAG. This step required me to basically take down our AD FS. Any users that were not already authenticated, would not be able to access Office 365 resources temporarily. I ended up doing this on a Sunday afternoon, outside of normal business hours.

The first step in this process was to connect to launch the Windows Azure Active Directory Module for Windows PowerShell and enter the Connect-MsolService command. I then had to enter your Microsoft 365 administrator credentials for the domain.

I then had to transition our Microsoft 365 tenant from managed to federated. Following the steps in the documentation made it basically a copy and paste into my PowerShell console. The documentation states that "the transition of your Microsoft 365 tenant from managed to federated can take two hours or more." However, ours maybe took 10 minutes. To convert it from Federated to Managed you enter the following command.

Set-MsolDomainAuthentication –DomainName your365domain.com -Authentication Managed

Once you verify that your Microsoft 365 domain shows as Managed and not Federated, you need to gather the federation parameter information. The URLs needed for some of the variables are found in your DAG certification (dag.crt) file.

Then you need to set the federation parameters as PowerShell variables (shown in the documentation). This step took me a bit to figure out, as I had to locate all the correct pieces of information for the variables. You have to ensure that these variables are set correctly. I had to put in a support ticket on this, and the technical support engineer was able to help me see that I was missing an "h" in one of the Uri's. It was a bit of a pain since I was past the "point of no return" and couldn't go back to my AD FS Federation.

Verify SSO

Once my federation settings were verified, I could then verify my SSO.

Thankfully I was successful and it has been working well since deployment. I also verified that mobile devices were able to use their native mail applications. I do intend to use our DAG to secure other applications in the future. But for now, it is just adding additional security on our Office 365 accounts.

Thank you so much for your time in reading this post. I know it was a lengthy one, but I hope someone will use this for their deployments. Please feel free to leave some comments!

As someone who certainly believes in "investing in yourself," I was intrigued and decided to give it a shot. I am currently on Week 5 and am enjoying the learning experience as well as the weekly coaching calls. The content is amazing, the labs are fun, and improving my soft skills is always important.

I'll show off some of the projects that Mike has us working on here in the next posts.

Now on to bigger and better cloud things!

I guess that wasn't enough for the DS419+. Rumor has it that those Diskstations run on an older processor and have been known to just stop working. So Saturday morning comes around, and our CFO accidentally sets off the alarm at the office. We go to check the cameras and find that it's not working. No worries though! I was going in later on to take my AZ-104 exam, so I went in a little earlier than planned and saw that the DS419+ wasn't working. I attempted to power-cycle the device, which didn't fix anything.

I notified my boss (Director of IT) and recommended that we just replace the Diskstation with a newer one. The fastest option was to purchase a DS920+ ($550) on Amazon and it would arrive on Monday. I even purchased an additional 4GB of DDR4 memory ($90) for the device. (Note to other IT Pros: Most companies have a policy that anything under $1000 is just an "Operating Expense". Over $1000 is a "Capital Expenditure". So if you can fix something under $1000, then you're doing pretty good.)

The DS920+ came in Monday right at lunchtime, so I had plenty of time to swap them out. The first thing I did was find some reference material to help me out. I'm not a big fan of reading and I found a Synology video on YouTube "How to Migrate to Another Synology NAS by Swapping Drives" Perfect!

Watched the quick 5-minute video and felt pretty confident. Let's get started!

Unboxing wasn't so bad. First thing though was to add the additional memory. I didn't bust out the manual and started looking around. Found these two slots on the bottom though for M.2. drives. Looks like you can have an SSD cache. Interesting, but not really needed for our scenario.

Still hunting for the DIMM slot, I decided to pull the drive cases out. I was going to need to do that anyways. As soon as I pulled them out, I found what I was looking for.

I then seated the 4GB DDR4 DIMM into the expansion slot.

Now time to swap the drives from the DS419+ to the DS920+. They come out of the holders pretty easily. No tools are required. There isn't a specific order in which you're supposed to insert the drives, but I just kept it the same order from the DS419+ to the DS920+.

After that, it was time to put the DS920+ back into the data center and connect the power supply and the network cable. We keep ours on a small shelf in the racks. Nothing too fancy here.

Thankfully Synology has a "find tool" that works perfectly when trying to locate your new Diskstation on your network. The web assistant can be accessed by going to "find.synology.com" in your browser. Once it is found, you can just follow the instructions. The Diskstation will see that you're migrating from one device to another.

Then you wait about 10 minutes for the migration to finish.

The only issue I had was finding the IP address of the device once it restarted. So I had to go to my Meraki dashboard to find it. After I logged back into the device, I made sure everything was set correctly and my boss confirmed that he could access the cameras via the mobile app.

Overall, this probably took me about an hour to get everything back online. I actually enjoy doing small projects like this. Hopefully, this helps someone out. I don't always do just SysAdmin work. Sometimes I've got to get my hands dirty.

I thank you for your time and I hope you enjoyed this!

-Brandon

PROBLEM: The current Meraki Client VPN OS configuration allows users to save their login credentials to their devices. This can be very problematic, from a security standpoint, because a compromised device could have direct access to your corporate environment using those saved credentials.

SOLUTION: Duo integrates with your Meraki Client VPN to add two-factor authentication to any VPN login. In a nutshell, it forces users to use a secondary form of authentication (Duo), via the Duo Authentication Proxy, when connecting to your Meraki Client VPN. This provides you that added layer of security.

How does it work?

Here is how it works:

1. Primary authentication initiated to Meraki Client VPN
2. Meraki MX sends the authentication request to the Duo Authentication Proxy
3. Primary authentication using Active Directory or RADIUS
4. Duo Authentication Proxy connection established to Duo Security over TCP port 443
5. Secondary authentication via Duo Security’s service
6. Duo authentication proxy receives the authentication response
7. Meraki Client VPN access granted

Install the Duo Authentication Proxy

For this to work, the organization must configure the Duo Authentication Proxy on one of the following systems:

• Windows Server 2012 or later (Server 2016 or 2019 recommended)
• CentOS 7 or later
• Red Hat Enterprise Linux 7 or later
• Ubuntu 16.04 or later
• Debian 7 or later

Regardless of the OS that you chose, Duo recommends a system with at least 1 CPU, 200 MB disk space, and 4 GB RAM (although 1 GB RAM is usually sufficient).

In my corporate situation, I have our Duo Authentication Proxy installed on a “miscellaneous” Windows server that runs a few different services. The proxy doesn’t utilize a significant amount of computing resources. Therefore, I didn’t think that we should deploy the Duo Authentication Proxy on its own server. It was also the first Duo application I deployed, so I was slightly hesitant to do it on a Linux server.

But before installing and configuring the Duo Authentication Proxy, I needed to contact Meraki Support to have the Client VPN RADIUS Timeout value increased to 60 seconds. This is important because it gives the user plenty of time to receive and respond to the Duo Push notification.

Configuring the Proxy

Now this took me a little bit of time to configure. The configuration file is formatted as a simple INI file. Following the Duo documentation made things a little easier though. I ended up using Active Directory/LDAP as our primary authenticator, utilizing a Read-Only Service Account to read the Active Directory service on my Domain Controller. The rest of the configuration was step-by-step.

Start the Proxy

Once you configure the INI file, the commands to start the proxy service actually check your configuration file for any errors as well as checks for connectivity to Duo. If you ever modify your configuration file, you must stop and restart the DuoAuthProxy service as well as restart the Authentication Proxy.

Configure Your Meraki VPN

You will then add the server, containing your configured Duo Authentication Proxy, to your list of RADIUS servers on the Client VPN section of your Meraki Cloud console. Following the Duo documentation makes this process relatively simple.

Testing Your Setup

I ended up testing my setup from home because I wouldn’t be able to connect to our Meraki VPN from inside the network. Technically I could have done it at the office using mobile hotspots but doing it from the comfort of my house made more sense.

Thankfully it worked out well and now I have enabled 2FA on our corporate VPN.

I am currently working on the AWS version of the Cloud Resume Challenge. I am currently six steps in and working on Step #7 (Javascript).

Thanks for following and I hope this is a fun and successful journey!