Network-level authentication - asset or liability?

[TimG]

Hi, folks.

We currently enforce NLA on our domain controllers but it's proving something of a mixed blessing.

Our admins use Tier 0 admin accounts for work on these servers that require it, but for some that isn't very frequent so from time to time they get locked out when the account password expires as CredSSP doesn't support password change on login.So far as we're aware NLA offers two main advantages:

1. decoupling authentication from the RDP service so that where we haven't patched against CVE-2019-0708 we aren't vulnerable to a BlueKeep-style attack

2. not launching a full RDP session until after authentication so unauthenticated RDP sessions can't be used as a medium for DoS attacks through resource exhaustion

Well - we're patched and as we don't expose RDP we're talking about a bad actor who'se already on our network and therefore may well have other fish to fry.

Sadly, we're unlikely to be introducing stronger authentication methods such as biometrics or keys any time in the very near future, so for on-prem access we still rely on the strength of the username/password pair. Unsure of the future of NLA in the modern world, too. Lengthening password lifetimes will just kick the can down the road and make it less likely that the thwarted admin will remember what s/he did last time

So - we're considering ditching NLA. I'd be interested to learn whether anyone thinks it's a lousy idea (and why)

[CraginS]

---

@TimG wrote:

...

Sadly, we're unlikely to be introducing stronger authentication methods such as biometrics or keys any time in the very near future, so for on-prem access we still rely on the strength of the username/password pair. Unsure of the future of NLA in the modern world, too. Lengthening password lifetimes will just kick the can down the road and make it less likely that the thwarted admin will remember what s/he did last time

So - we're considering ditching NLA. I'd be interested to learn whether anyone thinks it's a lousy idea (and why)

---

Tin,

First, thank you  for an extremely well formed and described question. Your description of the overall situation really helps focus on the core issue.

Next, I cannot address the question of whether to abandon NLA, but I do have two suggestions on handling your password management.

1. Adopt the revised password policies of the current NIST SP 800-63B. That is, allow long passphrases that include allowing for spaces, and do not require character complexity. Also, do not enforce periodic password changes.  Rather, require password changes on defined events, or when requested by the authorized users. 
2. Stop pretending any users, including your admins, are able to memorize all of their access credentials. Instead, supply each admin user with a password management tool and policy for use. Depending on the physical and IT environment, the tool may be properly encrypting software on a laptop, or it may be a small stand alone encrypted pocket data device, or it may even be a well protected notebook stored in a safe and checked out for each use.

Good luck!

Craig

[TimG]

Thanks, Craig.

The debate goes on here about password construction, and I for one am strongly in favour of a decently long phrase in preference to a shorter string of unmemorable gobbledegook (nice side-benefit is it'll never get stored as a LM hash, either). Likewise no time-expiry, though there are extra controls I'd want in its place. The hard bit is convincing the others who we need on board. In the UK, the NCSC has long been an advocate of password adequacy and of reminding us that time-expiry likely introduces more risks than it mitigates.

We do run a centrally-managed (and partitioned!) password management service but there are some things that aren't kept in there as users' access is defined by their AD accounts. There's little sense in having a separate password for an admin's Tier 0 account if knowing the password for the day-to-day account is enough to find it out.

Meanwhile, we don't have "pure" T0 workstations, so there's nowhere for the owner of an expired password to log in and reset it as part of the login process before attempting to RDP to the domain controller. Ho hum.

Best

Tim