Overview

For this challenge, we’ll be resolving tickets as they come into our ticketing dashboard, osTicket. The majority of these tickets will be focused on network issues and file shares.

Scenario

We’ll start by logging into the osTicket interface to view available tickets.

Ignoring the “I NEED COFFEE” ticket, there are only a couple of real tickets in the queue. The ticket from Rob is marked as an Emergency Priority, so we’ll start our work there.

Q1

Reset Robs Password

We’re in a Windows environment, so we’ll use the Domain Controller to reset Rob’s password.

Once logged into the Domain Controller, open the Server Manager’s “Active Directory Users and Computers” tool.

From within the new window, navigate to the Users folder, under daswebs.com, and locate the Rob user.

Double-clicking Rob will open a window where we can configure various settings for his account.

Navigate to the Account pane, turn off the “Password never expires” option, and enable “User must change password at next logon.”

Apply the settings and close the window.

Now we just need to change Rob’s password so that he can regain access.

To do this, right-click Rob in the menu and select “Reset Password…”

Give the new password a value of your choice, and select OK.

Now you can respond to Rob’s ticket in osTicket and mark it as resolved.

Q2

Network Troubleshooting on Backup

In the time it took to reset Rob’s password, we got a few more tickets. Two of which are labeled Emergency.

We’ll address Thanh’s emergency ticket first.

Thanh’s ticket suggests that they experienced connectivity issues while attempting to install a package.

Let’s log into the Backup server and check its network configuration.

We can use the ip command to view interface configurations and compare our findings to the network map.

We should also check that the DNS servers are properly set on the device.

Our findings here show a few important details.

• The static IP address is properly set.

• Our ping to google.com resolved the IP address, as shown in the parenthesis, but the host was unreachable.

• Our /etc/resolv.conf file contained two valid DNS servers.

One other thing to check would be the default gateway.

We can do so with the ip route show command.

Checking our network diagram, we can see that the gateway for this subnet is 172[.]16[.]30[.]2 but the default gateway configured on the host is 172[.]16[.]30[.]1.

We can set the default route with the command sudo ip route add default via <IP ADDRESS>, but we’ll need to delete the existing route first.

Now we can reply and mark the ticket as resolved.

Q3

Network Troubleshooting on Mail

It doesn’t seem like we’ve gotten any new tickets, so let’s jump right into our remaining Emergency ticket.

We can run through the same checks we performed on the Backup server to see if we can identify the problem.

Checking the /etc/resolv.conf file, we can see that the only nameserver configured is the localhost.

Let’s see if adding the Domain Controller’s address will remedy the situation.

We can see that after adding the DC to resolv.conf, Google’s address was properly translated to its IP address.

However, it is important to note that this fix is only temporary.

As noted in the /etc/resolv.conf file, we need to change the /etc/sysconfig/network/config file for a more permanent solution.

To do this, find the line NETCONFIG_DNS_STATIC_SERVERS in /etc/sysconfig/network/config and replace the IP with the Domain Contoller’s IP.

We can now reply and mark this ticket as resolved.

Q4

Mapping employee_share to Network Drive

Our final two tickets are both normal priority, so we’ll respond to the oldest one first.

The ticket asks us to map the employee_share folder to the W: drive on Workstation-Desk.

If we take a look at the Fileshare, we’re unable to view the employee_share folder.

Let’s take a look at the Fileshare host and check the permissions.

We can see that the accessible shares are assigned to the group of DASWEBS\domain admins and have their permissions set to 775.

We can use the chgrp and chmod commands to assign the same permissions to employee_info.

We can also check the samba config file on the share located at /etc/samba/smb.conf.

Within the smb.conf file, we can see the Share Definitions section lists folders found in /share.

We can see that each section contains a variable called “path”. Let’s grep for this to get an easy view of which folders are configured for shares.

We can see that the shares configured in smb.conf match the shares we found in Windows File Explorer.

Let’s add an entry for the employee_info to make it visible on the network share.

After adding the employee_info section to smb.conf, restart the Samba service with sudo systemctl restart smb

Now that we can see the share, we can map it to a drive letter within Windows.

To do this, navigate to “This PC” on the workstation, select “Computer” from the top bar, and “Map network drive”

With the drive mapped, we can reply and mark the ticket as resolved.

Q5

Mapping archives to Backup

We only have one ticket left to resolve, so let’s get started.

Similar to our previous task, we’ll need to map a drive to the Backup server.

The difference this time is that Backup is a Linux machine.

We can start by making archives accessible via SMB.

We’ll use the same methods we used in the previous section.

With the permissions set, we just need to set the mount to the Backup host.

We’ll need to create the requested directory to mount to with the mkdir command.

To make the archives directory in /run/mount/, run the command sudo mkdir /run/mount/archives.

With the directory created, we’ll use the mount command to map the share to the directory.

Because this is a Samba share, we’ll need to pass the filesystem type as cifs with the -t parameter. We’ll also need to provide our username, password, and version number with the -o parameter.

Note: This mount is only temporary. To make this a permanent mount we’ll need to edit the /etc/fstab configuration file.

To make the mount permanent, add the following to /etc/fstab.

This method exposes user credentials and should be avoided. Instead of placing the credentials directly in fstab, you could read them from a secured file instead.