Accessing a Windows Share from the Native Windows Command Prompt

I needed to run a application installer from a share located on a server. I knew I could use “net use” to map the drive but I remembered that there was an easier way but couldn’t recall the command. After some searching I found it:

pushd \\<server>\<share>

Then after you are done accessing the share:

popd

Per the docs, pushd will start at the drive letter “Z” and work its way back until the next unused drive letter is found and use that letter for the mapping.

As a “net use” refresher to map a drive:

net use z: \\<server>\<share>

Of course there are other switches available so to get help:

net use /?

And since “net use” is part of the “net” command:

net /?

Windows Server Broken Update Fix

Updates can break on Windows Server for a number of reasons, so this is not an all encompassing fix. But over the years I have seen this occasionally. What happens is that the server does not update and when you attempt a manual update via the Windows Updates setting screen, the updates never download: the downloads are typically stuck at 0% complete. This is apparently due to a corruption of the files within the “C:\Windows\SoftwareDistribution” folder. Because the update process is hung, the update service also appears to be hung up so the process to repair the problem is slightly more involved that one would expect.

First, open the services control applet:

-Click the "Start" Button
-Type "services.msc"
-Set Windows Update to "disabled"
-Reboot the server

Once the server has re-started, verify that the Windows Update service is not running:

-Click the "Start" Button
-Type "services.msc"

Rename the SoftwareDistribution folder:

Rename C:\Windows\SoftwareDistribution to SoftwareDistribution.old

Reset the update service:

-Click the "Start" Button
-Type "services.msc"
-Set windows update to "manual"
-Start the service

Now manually run the updates and make sure they are downloaded and installed. Then perform the required server reboot.

Ubuntu Server: Google Authenticator Configuration

Before installing and configuring the Google Authenticator on a virtual server you need to check and do a few few things to avoid getting locked out of the server. I have seen this grub configuration issue on virtual Ubuntu 18.04, 20.04, and 22.04 server installs on both HyperV and vSphere infrastructures. Also, make sure that you have multiple ssh terminals open prior to restarting sshd in the event the configuration is incorrect.

In the examples below I am only targeting admin accounts with sudo privileges – normal user accounts can log in without being prompted for a Google Authenticator code. Users logging in at the terminal will not be prompted for the authentication code. This configuration only affects ssh logins.

Grub Recovery Issue:

Prior to google authenticator setup you should check to make sure that the grub bootup menu is displayed long enough for you to capture it in the event that you need to do an emergency recovery.  Doom on you if you don’t change this behavior in the grub configuration.

vim /etc/default/grub

GRUB_DEFAULT=0
#GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=20
update-grub

Reboot and verify the grub screen appears in the terminal window for a suitable amount of time.

Google Authenticator Install and Configuration – as root:

As a security suggestion – open multiple ssh sessions to avoid possible lockout during configuration.

A second suggestion – Users should not be added to the group (i.e. sudo) until after doing the user authenticator setup if they will be doing the setup using SSH. User setup of the authenticator from the local terminal will not matter since this configuration only affects ssh logins.

Check for users in certain group, in this case “sudo”:

getent group sudo

Install Gooogle Authenticator:

apt-get install libpam-google-authenticator

Edit and add to the bottom of the file (the order of these two lines matters):

vim /etc/pam.d/sshd

# Google authenticator - only for users in sudo group
auth [success=done default=ignore] pam_succeed_if.so user notingroup sudo
# Google authenticator - prompt for code
auth required pam_google_authenticator.so

Edit the sshd config file:

vim /etc/ssh/sshd_config

# For google authenticator
# Enable challenge-response passwords
ChallengeResponseAuthentication yes

Restart ssh daemon:

systemctl restart sshd

Client Setup – As normal user:

As a normal user in the terminal:

google-authenticator

Answer the following questions:

Do you want authentication tokens to be time-based (y/n) y

In the phone app, add key or use QR code. Then enter the code from the app:

Enter code from app (-1 to skip): <code>

Copy emergency one-time use codes to a safe file.

Do you want me to update your "/home/shawn/.google_authenticator" file? (y/n) y
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) n
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y

At this point you are done. Remember to add/re-add users back to the sudo group if you removed them.