Category Archives: Windows Server

Windows Server 2022, IIS Certificate Authentication not working. (Connection Reset)

I was working with a colleague of mine the other day on this issue. If you are using WIndows Server 2022 with IIS to setup a website that will use client certificate authentication and notice that you are not prompted for a certificate….. the issue is probably TLS 1.3.

Windows Server 2022 IIS by default uses TLS 1.3. If you check the box to disable TLS 1.3 which will fall back to TLS 1.2 everything works.

Still not sure at this moment who is to blame, Microsoft, or the web browsers.

EDIT: Update from the Microsoft Article

https://docs.microsoft.com/en-us/answers/questions/654803/err-connection-reset-if-asking-client-certificate.html

Yes, I got answer: Microsoft implemented TLS 1.3 in most secure way by RFC. IIS wants to perform post-handshake authentication. Unfortunately common browsers do not support it in default configuration. You can enable it only with Firefox (when I last checked, maybe samething changed in near past). So, de facto IIS default configuration for two-way SSL with common browsers do not work with IIS when TLS 1.3 only is enabled.

You can enable IIS and TLS 1.3 only configuration by enabling in-handshake method for IIS instead on post-handshake method.

Forcing ADFS 3.0 to run TLS 1.2

If you haven’t already forced ADFS to run on TLS 1.2 you are behind the curve. Activating TLS 1.2 on ADFS and turning off all other vulnerable services is relatively easy.

Step 1: Disable SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, RC4 & Enable Strong Auth for .NET

The first step that always goes unsaid is to snapshot your Virtual Machines or get a solid backup state before making any changes to a running production environment. The next unsaid step is to perform these activities on a test/dev environment before taking down Production!

SSL 2.0 and SSL 3.0 should already be disabled, if they are not disable them immediately! The following link from Microsoft provides the registry keys and powershell needed to disable all of these services. Make sure these changes are being made on all Web Application Proxies (WAPs) and ADFS servers.

  • Disable SSL 2.0
  • Disable SSL 3.0
  • Disable TLS 1.0
  • Disable TLS 1.1
  • Disable RC4
  • Enable Strong Authentication for .NET Applications

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs

Step 2: Reboot all Virtual Machines / Servers

This step is pretty self explanatory.

Step 3: ADFS is Br0ken, Oh Noes!!

Disabling TLS 1.0 will break ADFS 3.0, more specifically it breaks the connection between the WAPs and the ADFS servers. This is easy to fix though.

Following this article on re-establishing the trust: https://blog.rmilne.ca/2021/11/16/ad-fs-web-application-proxy-re-establish-proxy-trust/

Quick Recap: Change this registry value on the primary Web Application Proxy:

HKLM\Software\Microsoft\ADFS\ProxyConfigurationStatus –> 1

This value normally has a value of 2 (which means configured), change it back to 1, and this change does not even require a reboot.

Open up Server Manager and launch “Remote Access Manager”, select “Web Application Proxy” and put in the required information to re-establish the trust.

You may need to reboot the WAPs one more time, I had to.

Step 4: Verify SSL Services are Correct

Once all services come back up, it would be a good time to verify that all the services you think you turned off are actually off. A SSL Server Test tool would be great for that, like the one by SSL Labs: https://www.ssllabs.com/ssltest/

Step 5: You may need to correct internal .NET Applications pointing to ADFS

Internal .NET Applications may start failing. If you start to receive error messages like “Authentication failed because the remote party has closed the transport stream”, it just means you are not specifying TLS 1.2.

There is a great article on Microsoft Docs here that explains the situation and the fix: https://docs.microsoft.com/en-us/answers/questions/400152/authentication-failed-because-the-remote-party-has.html

The developers will just need to specify the SecurityProtocol in their application.

Windows Server 2022 Core – Failed to release DHCP lease

There appears to be a bug in Server Core 2022 in regards to changing the network settings through “sconfig”.

I’m deploying a new server from template in vCenter and by default it drops onto a private network with DHCP. The first thing I will do is go edit the settings of the VM and drop it on the proper network. After the VM is properly configured I will then go through “sconfig” to reset the IP to a static IP.

In “sconfig” you punch in number “8” for “Network Settings” and select “1” for the only NIC in the machine and you will be at the following prompt:

Here you will select “1” for 1) set network adapter address.

Then select “S” for (S)tatic IP Address.

Follow the on-screen prompts to enter IP, Subnet Mask, and Default Gateway. It is here you may be prompted with the error.

Setting NIC to static IP…

Failed to release DHCP lease.

Result code: 83

Method name: ReleaseDHCPLease

If you run into this issue you can enter “15” on sconfig and drop to Powershell. You can then run the following commands:

Get-NetAdapter

This will provide the NICs and more importantly the “Name” field which will be needed below

Remove-NetIPAddress -InterfaceAlias Ethernet0 -confirm:$False

Even after getting this far you may still not be able to assign the IP through “sconfig” in which case you can do it with Powershell.

New-NetIPAddress -InterfaceAlias Ethernet0 -IPAddress 172.16.1.2 -PrefixLength 24 -DefaultGateway 172.16.1.1

You can now launch “sconfig” go back to “8” Network Settings and configure your DNS servers.

Monitoring Domain Controller Windows Firewall Logs (Part of Active Directory Hardening Series)

The first step before you can monitor the local DC firewall logs is to make sure you have properly setup your domain controllers to log firewall activity. If you have not already turned on firewall logging and increased the log size to the maximum you can configure that by looking at my prior post: https://paularquette.com/lock-down-your-active-directory-domain-controllers-internet-access-part-of-my-active-directory-hardening-series/

I have shared a new script on GitHub to do some basic monitoring of dropped traffic on your Domain Controllers. https://github.com/paularquette/Active-Directory/blob/main/AD_Monitor_DC_Firewall_Logs.ps1

I currently run this script every hour and I get plenty of overlap for logs. The logs roll relatively quick but not that quick. I’m also logging all allows and I may change that in the future to only log drops.

In order to see dropped traffic outbound you would have to have outgoing firewall rules in place. By default traffic is not blocked going out. You can reference my previous post linked above.

In the example below you can see I’m limiting all TCP/UDP outbound traffic on Non HTTP ports to a certain subset of IP ranges:

If this Domain Controller tries to send any NON-HTTP(s) traffic outside of the organization it will show up in the DC firewall logs.

Example of HTML Report:

If your IT Security group has the hardware firewalls super locked down you may not see much if any traffic being dropped on the local DCs, but it still isn’t a bad idea to have another layer of security around such a high profile service!

PrintNightmare – [0Day] Windows Critical Vulnerability

I had been watching Twitter all day yesterday and amongst all the #infosecbikini photos filling up InfoSec Twitter there was mention of this critical Windows vulnerability. At first it sounded like the June patches would protect you, then Twitter seemed to lose faith that was the case.

The US Cybersecurity & Infrastructure Security Agency (CISA) released the following notice the evening of June 30, 2021. (https://us-cert.cisa.gov/ncas/current-activity/2021/06/30/printnightmare-critical-windows-print-spooler-vulnerability)

It has been recommended to disable the Windows Print spooler service on Domain Controllers and any systems that do not print.

EDIT: As of writing this entry the best workaround I have been able to find if you need to keep print services running is here: https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675-exploit-to-keep-your-print-servers-running-while-a-patch-is-not-available/

EDIT 2: Microsoft has finally responded: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527

EDIT 3: CISA put out emergency directive: https://cyber.dhs.gov/ed/21-04/

For your meme viewing pleasure:

Extending Volumes in Windows Server Core

If you add space to a Windows Server Core hard disk in a virtual platform like VMware and need to extend the disk in the Operating System you will have to complete it all via command line.

Step 1

Add the space to the hard drive in your virtualization platform

Step 2

Login to the server and launch diskpart. You can then issue the command “list disk” to see which disks are on the system and which ones have free space.

Step 3

Type in “Select Disk <number>” in order to choose the disk you want to modify. You can then issue the command “List Volume” to provide the volumes on that disk in order to find the volume you want to expand.

Step 4

As you can see from the image in “Step 2”, we have 100GB that is listed as “Free”. We want to add that free space to the currently large volume, which you can see from “Step 3” is listed as “Volume 2”.

Type in “select volume <number>” and then type in “extend” in order to extend the volume for the full length that we can.

Running another “list volume” should show that the volume size is now increased to 199GB.

Server 2012R2 in place upgrade to Server 2019 on VMware

I’m personally not a fan of in place Microsoft Server upgrades but I suppose they have their time and place.

Since many of our 2012R2 servers are from the 5.1 and 5.5 days of VMware many of them are still running Virtual Hardware v9. This hardware version needs to be upgraded to perform the OS upgrade.

I was able to successfully re-create the issue with an upgrade of a clean 2012R2 install on v9 hardware. After the first reboot you will get stuck at the black screen with blue window, with no circle running underneath. I let this run for two full days (48 hours) before cancelling it.

After cancelling it and resetting the VM, you will be given the following error message:

We couldn’t install Windows Server 2019

We’ve set your PC back to the way it was right before you started installing Windows Server 2019.

0xC1900101 – 0x20017

The installation failed in the SAFE_OS phase with an error during BOOT operation

VMware generally states that you shouldn’t upgrade the VM hardware version unless there is a need. In this case there is a need.

My recommendations would be to do the following:

  1. Shut down the VM you want to perform an in place upgrade on
  2. Take a snapshot with the VM off
  3. Upgrade the Virtual Machine hardware version (We went to v15)
  4. Power on the VM, mount the ISO, run the upgrade

This process seems to be working for us, and although this may be a no-brainer, I’m putting it out there for the search engines to index in case it does help someone.