Microsoft Out of Band Update Resolves Kerberos Issue

Published: 2021-11-15
Last Updated: 2021-11-15 16:05:24 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)

Since Patch Tuesday, we've been tracking a Kerboros issue in November's patch bundle that affected authentication in several deployment scenarios:

  • Azure Active Directory (AAD) Application Proxy Integrated Windows Authentication (IWA) using Kerberos Constrained Delegation (KCD)
  • Web Application Proxy (WAP) Integrated Windows Authentication (IWA) Single Sign On (SSO)
  • Active Directory Federated Services (ADFS)
  • Microsoft SQL Server
  • Internet Information Services (IIS) using Integrated Windows Authentication (IWA)
  • Intermediate devices including Load Balancers performing delegated authentication

This was fixed out of band yesterday (November 14, 2021).  If you have applied November's update and are affected, you'll want to apply the "November-take-two" update on any affected servers.

The full issue report is located here: https://docs.microsoft.com/en-us/windows/release-health/status-windows-10-1809-and-windows-server-2019

The note on yesterday's fix being released is here: https://support.microsoft.com/en-us/topic/november-14-2021-kb5008601-os-build-14393-4771-out-of-band-c8cd33ce-3d40-4853-bee4-a7cc943582b9

If you haven't applied November's updates yet, you may have dodged a bullet this month, but you likely want to revisit your update cadence - in most other months you would be more vulnerable than safe at this point (the Monday after Patch Tuesday).

 

===============
Rob VandenBrink
rob <at> coherentsecurity.com

Keywords:
0 comment(s)
ISC Stormcast For Monday, November 15th, 2021 https://isc.sans.edu/podcastdetail.html?id=7756

Changing your AD Password Using the Clipboard - Not as Easy as You'd Think!

Published: 2021-11-15
Last Updated: 2021-11-15 01:06:24 UTC
by Rob VandenBrink (Version: 1)
4 comment(s)

Let me know if this scenario is familiar?

  • You are working in a customer's AD domain
  • You only have access to a member workstation
  • Your account doesn't have Domain Admin rights
  • Your account does not have Local Admin rights on the workstation you are connected to.
  • You want to use a long, complex password
  • ... aaand Microsoft won't allow you to paste a password into their GUI "password change".  Apparantly Microsoft wants us to continue to use passwords like "Passw0rd1!" and "Winter2021!" forever, until all AD domains are "passwordless"

If you are in this boat, you might think - great, I can't paste into the GUI, but how about "net user"?  Sadly, you need local or domain admin to change passwords using this command (see the list above).  If you try to change your own password using "net user", you'll end up with an "access denied" error.

OK, we still have PowerShell though, I can use the AD module there!  Except, sadly, you don't have local Admin rights so you can't install a new Powershell module.

What to do?  Happily you can still use PowerShell to get the job done, but we'll use ADSI to rescue the situation.  This script will do the job:

$oldpw = "existingoldpassword"
$newpw = "somenewpassword"
$user = $env:username
$domain = $env:userdomain
$user = [adsi]"WinNT://$domain/$user"
$user.ChangePassword($oldpw, $newpw)

If you use this approach, for goodness sake please don't save this script with your old and passwords in it!  

This second script will at least ask you for the passwords - and you can paste them into the input fields.  This still isn't great as the passwords are still in clear text as variables, but at least when you exit PowerShell they'll cease to be easily retrievable (unless someone collects a memory image of your workstation that is).  As a nice bonus, I cleared the clipboard in this one (from my diary last year https://isc.sans.edu/forums/diary/Whats+in+Your+Clipboard+Pillaging+and+Protecting+the+Clipboard/26556/ )

happl
$oldpw = read-host -prompt "Enter your existing password"
$newpw = read-host -prompt "Enter your new password"
$user = $env:username
$domain = $env:userdomain
$user = [adsi]"WinNT://$domain/$user"
$user.ChangePassword($oldpw, $newpw)

# Overwrite the password variables (I know that this doesn't really over-write)
# also clear the clipboard
$oldpw = "*" * 50
$newpw = "*" * 50

Set-Clipboard $null

This script has done the job for me so far - I can use a long, complex (AKA un-type-able) password, paste into the input fields, and still have my password change intervals match my clients' policies.  If you have a more elegant solution by all means post to our comment section below, this is a common enough situation that improving this would be a welcome thing for lots of us!

Or if you are reading this Microsoft (whichever manager that thought "disabling paste will make this waaay more secure"), letting us paste into the password change fields would make this detour unneccessary, and it would improve account security for lots (and lots) of us!  I use Windows Hello (using my fingerprint) to login to my laptop, but sadly, even though AD has started the "passwordless" journey, realistically AD passwords aren't going anywhere anytime soon - even "passwordless" shops are going to need some passwords for some situations for years to come.

===============
Rob VandenBrink
rob <at> coherentsecurity.com

Looking to use Linux in support of Network Services?  Check out my book (released just last week, the ink is still wet)
https://www.amazon.com/Linux-Networking-Professionals-configure-enterprise/dp/1800202393

4 comment(s)

Comments


Diary Archives