November Update - 2021-11 KB5007247 - Kerberos errors

[Koldov]

Last night I remoted in and bravely (?) did the November updates for our servers...

 

I was expecting some sort of carnage this morning due to previous print nightmare updates (and a thread on here about SQL).

 

After a reboot of the servers sure enough I couldn't print, but found that somehow it had set the Print Spooler service to 'Disabled'.

 

Setting it back to automatic and restarting it brought all the printers back on-line... strange but at least it is working for now.

 

Anyway, after checking through the event logs, I started seeing Kerberos Ticket errors:

 

The Key Distribution Center (KDC) encountered a ticket-granting-ticket (TGT) from another KDC (SERVER-2) that did not contain a PAC attributes field. See https://go.microsoft.com/fwlink/?linkid=2173051 to learn more.

 

and

 

The Key Distribution Center (KDC) encountered a ticket that did not contain information about the account that requested the ticket while processing a request for another ticket. This prevented security checks from running and could open security vulnerabilities. See https://go.microsoft.com/fwlink/?linkid=2173051 to learn more.

 

Ticket PAC constructed by: SERVER-2

Client: DOMAIN.COM\\SERVER-1$

Ticket for: krbtgt

 

I left it overnight thinking it would sort itself out and settle down, but the error are still being produced this morning.

 

Looking through the link I can't really see what the issue is as both DCs have had the November update... I haven't added the reg key suggested.

 

Anyone else seeing this.

[Michael]

I know Microsoft have released out-of-band updates for Server 2016 and Server 2019 (on November 14th) but nothing for Server 2012 or R2. Still only the November 9th update.

 

Are domain users unable to authenticate, or is it just event logs filling up?

 

It's more an issue for DCs rather than servers hosting other roles (as far as I can tell)!

[Koldov]

Yes, exactly that (event logs), it does appear to be a DC to DC thing.

 

Everything else (that I know of so far) is absolutely fine.

 

EDIT: Just a little concerned about what it may be breaking between DCs (replication etc.)

[Michael]

Separately, there are no November print related updates - security or not, again as far as I can tell looking at release notes.

[Michael]

If you scroll down here, it describes the error on Server 2016.

[Koldov]

Luckily the server side of things (updates) no longer seem to affect printing, it's only client updates that mess it up.

 

I was on another forum (shhhhhh)..... and noticed that some had said the recent out-of-band updates for Windows 10 clients (tested on 21H2) seem to have even fixed their printing issues. Even though the release notes don't mention anything about printing!

 

Nothing for lower version yet though...

[Michael]

In regards to these errors:

 

0x000006e4 (RPC_S_CANNOT_SUPPORT)

 

0x0000007c (ERROR_INVALID_LEVEL)

 

0x00000709 (ERROR_INVALID_PRINTER_NAME)

 

Either disable the Windows Firewall on the LAN, but enabled off the LAN (how I generally do things via GPO) or enable these TCP ports -

 

Default start port: 49152

Default end port: 65535

Port Range: 16384 ports

 

I'm currently in the process of manually updating a few Server 2016 DCs to 14393.4771, which should bypass 14393.4770 altogether.

 

The registry tweak is entirely optional, but I'd suggest leaving as default for now (do nothing).

[Koldov]

The registry tweak is entirely optional, but I'd suggest leaving as default for now (do nothing).

 

Yup, confusing as hell (as ever) from Microsoft... but 'do nothing' seems to be the general consensus...

 

https://community.spiceworks.com/topic/2338789-event-id-35-and-37-kerberos-on-server-2019

 

https://docs.microsoft.com/en-us/answers/questions/630388/server-2012-r2-std-generates-event-id-37-microsoft.html

 

Maybe it's just the wording of the error that seems to imply that when the enforcement phase kicks in, 'DC 2' is going to be blocked as it doesn't contain the PAC attributes field 'DC 1' is looking for... and I've no idea why not or how to fix it!

 

Not helped by the search for Event ID 37 brings up "Event ID 37 is logged when the hardware platform determines that the OS can't use some frequency range that the processor supports. This Warning event notifies the user that the processor or CPU core can't support running at full speed."

 

Only subsequent results in the search show the Kerberos issues linked.

[Michael]

To be honest, this is why I generally hold off for 30 days using WUfB, (all controlled via GPOs) so if Microsoft bodge a monthly update, everything else continues working.

 

I can then perform isolated tests and allows more time for decision making also.

[Koldov]

As for the printer errors I'm ashamed to say I've left my clients on the September CU...

 

Nothing in your link obviously relates to 2012R2 (as it's for 1607/2016) and clicking on the "Known issues in this update - Clip or tap to view the known issues" reveals a further clickable link under Workaround - "Windows release health."

 

However, I'm sure I've mentioned in one of the other many printing threads that I can't understand the workarounds...

 

"Print clients must have installed a Windows update released on or after January 2021 before the print server has installed"

 

None of my clients are that far behind on updates...

 

"Ensure that network security and VPN solutions allow print clients to establish RPC over TCP connections to print server over the following port range:

Default start port: 49152

Default end port: 65535

Port Range: 16384 ports"

 

Not sure where this is (as it doesn't explicitly state what service/program to enable these ports for - I can't find RPC over TCP), but on my print server the Firewall is off and if it wasn't the following rule is in the 'Firewall with Advanced Security':

 

File and Printer Sharing (Spooler Service - RPC)

Inbound rule for File and Printer Sharing to allow the Print Spooler Service to communicate via TCP/RPC.

Program - %SystemRoot%\system32\spoolsv.exe

Protocols and Ports TCP - RPC Dynamic Ports - All Ports

 

That's a default for printer/file sharing, so doesn't that cover it?

 

"You also benefit from using client side rendering for print jobs. The 'Render print jobs on client computers' option is available from the printer's device Properties, and it is recommended that its checkbox is selected on the print server. Note this step will not help if clients have overwrites which prevent the server setting from taking effect."

 

This is the default for all our printers anyway...

 

I just can't face the potential hoards of teachers knocking on my door crying that they can't print a new ream of paper for their class to colour on and stick in their workbooks...

[Oaktech]

Is it related to this:

 

https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041

[Koldov]

 

The Key Distribution Center (KDC) encountered a ticket-granting-ticket (TGT) from another KDC (SERVER-2) that did not contain a PAC attributes field. See http://https://go.microsoft.com/fwlink/?linkid=2173051 to learn more.

.

 

Is it related to this:

 

https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041

 

Yes, it absolutely is! The link in my first post from the error in the event viewer log forwards to that link.

 

What I am not understanding actually is what the errors really mean... or maybe I'm reading it incorrectly.

 

I'm just trying to decipher it and failing, because to me it looks like DC1 (KDC) is unhappy with what DC2 is sending (the errors are part of the Deployment/Audit phase I think), but when the Enforcement phase kicks in (July 2022), does that mean it will block communication?

 

And why doesn't DC2 have what DC1 needs (the correct Kerberos PAC)?

[Koldov]

So, interestingly SERVER 1 has just decided to randomly stop complaining and isn't filling up its event logs with those Kerberos errors about Server 2 anymore....

 

There doesn't seem to be much info about it, but at least I found something to corroborate the fact that I'm was not going mad or that it's just my set-up...

 

https://community.spiceworks.com/topic/2338789-event-id-35-and-37-kerberos-on-server-2019

 

The Key Distribution Center (KDC) encountered a ticket that did not contain information about the account that requested the ticket while processing a request for another ticket. This prevented security checks from running and could open security vulnerabilities. See https://go.microsoft.com/fwlink/?linkid=2173051 to learn more.

 

Ticket PAC constructed by: SERVER 2

Client: DOMAIN.COM\\SERVER 1$

Ticket for: krbtgt

 

 

Nothing has changed with either server, no updates, no reboots... Maybe SERVER 2 just needed a bit of time to think about what it had done wrong and got itself together...

 

Previously it logged this error pretty much every hour and then Wednesday at 18:00 it seems to have just stopped... no entries for this error after that!

[Boredguy]

It can take up to a week from the patch being applied to all DC's before it stops complaining from what I read

[Koldov]

Ah, sounds about right then!