How I Completely Locked Myself Out of My PC

Today, I wiped and re-imaged a PC for the sake of testing… and ended up making log-on impossible. Here’s what happened.

DUO For Workstation

For those who don’t know, DUO has a workstation install that allows you to require push approval at the Windows log-on screen1. I thought it would be good practice to deploy this in my home environment.

I signed into the DUO Admin Portal, activated Microsoft RDP as a protected application, and made note of my API hostname, integration key, and secret key. Next, I installed the application locally and configured the local and portal-side authentication policies.

With everything set up, I rebooted my machine and…was immediately met with an error code.

How Can I Troubleshoot When I Can’t Sign In?

I was in a pickle. I needed to fix this problem without being able to sign in normally.

First I checked the DUO Admin Portal for logs using my phone. There was no log generated for this sign-in attempt, which tells me one of the following is the point of failure:

  • The local application is misconfigured.
  • There is a network point of failure between my workstation and DUO cloud. I have offline sign-ins disabled in my DUO policies, so a communication failure would prevent authentication.
  • There is a misconfiguration server-side.

Always Check the Logs

I knew from workplace experience that the DUO endpoint application does store clear-text logs. They should get me closer to the problem.

I booted into the Windows Recovery Environment by holding the SHIFT key and selecting POWER > RESTART. Then, from the Recovery Environment, I launched into Safe Mode2.

Once in safe mode, I navigated to C:\ProgramData\Duo Security\duo.log and read through the data to find the issue.

I could see that the API host and integration key were correct, so perhaps I had flubbed the secret key. I ran the below commands to disable DUO locally and then uninstalled the application after exiting safe mode and signing in normally.

regsvr32 /u "C:\Program Files\Duo Security\WindowsLogon\DuoCredProv.dll"
regsvr32 /u "C:\Program Files\Duo Security\WindowsLogon\DuoCredFilter.dll"

I re-installed DUO, double-checked the secret key, and restarted. Same error.

I also updated the temporary blank password that I had to a proper password. No change in symptoms.

Firewall?

I repeated the above to escape my sign-in purgatory and set my sights on ruling out a communication failure between my desktop and DUO cloud since we’ve addressed the local application.

The simplest way to test this was to allow offline authentication in the DUO Policies server-side and locally (set during installation). If communication fails, we should see Windows bypass the check altogether and authenticate normally.

We did not.

So What is Wrong In DUO Cloud?

At this point, I felt a policy was to blame. For my Windows logon, two sets of policies are passed through: Microsoft RDP application policies, and the general DUO policies.

Microsoft RDP policies were simple to rule out. I simply set the application to Bypass Mode and gave it a whirl. I got the same error code, so I set my eyes on the general DUO policies.

With Microsoft RDP in Bypass Mode, I also set the general DUO Authentication Policy to bypass mode. I still got the same error… what was I missing?

Username

From the logs, I knew DUO was recognizing my username format as NTLM3 and parsing it into username and domain. For example, DUO will see a login for PCNAME\USERNAME and parse the credentials into two variables:

  • specifiedUsernameOnly: “USERNAME”
  • specifiedDomainOnly: “PCNAME”

Because I still saw no authentication logs (pass, bypass, or fail) in the Admin Portal, I set my sights on the user configuration.

Lo and behold, I had absent-mindedly set the username in DUO as “sjenkins” which was the local user on the PC before I did a re-image. The correct username is now “scott”. That means the authentication request DUO for Workstation was sending to my DUO API instance did not match any user and thus had nowhere to send a push to.

I added “scott” as an alias to my user and gave sign-in a final try.

The push was sent straight to my phone…

What a beautiful sight!

My Home Network Diagram

I have a lot of plans for my home network, so I thought it would be useful to document the current configuration!

The Diagram

This is a very typical configuration with only a couple of changes outside of what most folks will naturally implement. Still fun, but not quite as interesting as some of the networks I see in my work environment (YET!).

Trust in Networks

From a security perspective, we do not necessarily want all devices to have communication with one another. Consider the Internet of Things1 devices I have, like my Smart TV, and guest devices. I cannot trust that these devices are secure so I don’t want them to have anything to do with my sensitive devices like my home computer.

For this reason, I have my trusted home network composed of my wired connections to my ISP modem as well as my protected wireless connection. For IoT devices, guest devices, and possibly insecure devices I’m tinkering with, I have a logically segmented wireless guest network. This way if there’s a vulnerability with my “Smart” Coffee Maker, the scope of exploit in my network is limited. A bad actor will have to go through my ISP modem’s firewall to get over to my trusted network which it should not be able to.

Static IP vs. DHCP

The only device I have configured with a static IP is SCOTT-PC. I wanted my phone and laptop to be able to always reach my PC at the same address without having to consult the modem for an updated IP if my PC were to ever fail to renew the IP assignment and receive another address by DHCP. There are some services I spin up from my PC that my phone and laptop access which is the reason for this change.

All other devices on my Trusted and Untrusted networks are assigned their IP addresses by the DHCP function on my router. The lease duration for network addresses in my networks is 1 day, so, in normal function, when devices reach the halfway marker of that lease (12 hours), they send a renewal request to the DHCP server (my router) which the router will approve and they will keep the same address.

PowerLine Adapter

PowerLine adapters use existing electrical wiring within an environment to transmit data. Because they use a different frequency band on the copper wiring than power transmissions, the existing electrical outlets in the home can supply both data and power transmission. If this is interesting to you, you may want to read this article. I implemented these because there was no Ethernet port where I set my work desk.

To physically configure a PowerLine adapter, connect a patch cable between your ISP modem/router and the PowerLine adapter. The adapter needs to be plugged into an outlet.

Then, connect your second PowerLine adapter to an outlet on the same electrical grid (ideally also the same circuit breaker). Take an Ethernet patch cable from this PowerLine adapter to your device.

PowerLine adapters may or may not work terrifically in your environment.

  • With high electrical demands, the data bandwidth the adapter can transmit will dip. So, if you’re running the microwave, your expected 1000 MB/s connection may drop significantly.
  • The quality of your copper wiring greatly impacts the bandwidth the adapter can service.
  • Signal degradation occurs over longer distances, so an ideal configuration would not have a long electrical run between the two adapters.

Upcoming Changes

MoCA

I eventually want to experiment with implementing a MoCA (multimedia over coaxial) network2. My apartment has coaxial cables laid in the walls and one is conveniently located by my work desk. I’ll need to connect a MoCA adapter directly to my router and then into a COAX wall port. Then out from an existing COAX wall port into a second MoCA adapter and my PC via an Ethernet patch cable. Compared to my PowerLine setup, the MoCA network will need more logical configuration on the router which I’ll document when I implement it eventually.

MoCA will likely provide a better connection speed for my PC than my wireless connection and my PowerLine connection. A limitation of MoCA that is worth considering is it is a non-switched connection; bandwidth is shared among all connected devices. Since I only plan to connect by PC by MoCA, I should benefit from the full bandwidth limited either by the speed provided through my router or the speed the COAX cabling in my walls can support (likely the latter based on the age of my apartment…).

Switch/Firewall

When funds permit, I’d like to get a multi-layer switching device. The firewall onboard the ISP modem does not fit all of my needs. Eventually, I’ll get a SOHO-grade multilayer switch that I can position after my ISP modem and before my devices. Some of the features I would like to play with are:

  • Configuring a VPN so I can securely tunnel into my home network from external networks.
  • Defining VLANs (network segments) that function without inter-VLAN bandwidth constraints.
  • Remote network monitoring and management.
  • Eventually, I’d like to segment and implement a network for a camera system completely isolated from the Internet.
  • General network experimentation and building out my home lab.