0

Problem

After enabling KrbtgtFullPacSignature (value 3) according to KB5020805 the entire domain becomes unreachable, at the login screen the following message is shown: “Insufficient system resources exist to complete the requested service“ and we had to rollback the domain controllers through backup.

Prerequisites

  • Set KrbtgtFullPacSignature to value 2
  • Checked msDS-SupportedEncryptionTypes, values are Null or 0 on all accounts
  • UserAccountControl is set to normal values
  • Checked EventID 4769 on all ADDCs and only 0x12 is used
  • Checked EventID 42, 43 and 44, none is present
  • Checked EventID 14, no entries are present

Troubleshooting

After the backup rollback we checked our SIEM for relevant events during the time the KrbtgtFullPacSignature was set to value 3, no relevant information and/or IDs where found. Later in an isolated environment we tried to recreate the problem and confirmed that as soon as we changed the value to 3, the same error message appears and as soon as we changed back to value 2 it disappeared and authentication went back to normal.

Updates

All the ADDCs in the domain are Windows Server 2019 and the following updates are installed (list not including normal .NET patches, definitions, etc), the updates include the cumulative November and December update aswell as the OOB patch from november:

  • KB5021655
  • KB5019966
  • KB5018419
  • KB5017855
  • KB5012170
  • KB5017379
  • KB4589208
  • KB4535680
  • KB5017315

Question

When looking around the internet this doesn't seem to be the normal error for this change. I can also add that we have 4 domains (in different forests) and the other 3 domains worked out fine with the same methodology, only the 4th domain got this error. Any ideas what can cause this and how to resolve it?

Salve
  • 85
  • 1
  • 6
  • `Later in an isolated environment we tried to recreate the problem and confirmed that as soon as we changed the value to 3, the same error message appears`. *Later*? Seriously, testing only works if it is done *before* deployment. – Greg Askew Dec 16 '22 at 11:58
  • @GregAskew I don't understand your concern, we cloned the faulting machines (before the change to force strong kerberos was done) and did the change in an isolated invorenment. When you say "before deployment", I don't understand what you mean in this specific case? – Salve Dec 16 '22 at 12:16
  • Same issue here. Seems to be hit or miss between different environments. At least 20% with the issue. Anyone able to confirm what's causing the issue? – truwarrior22 Apr 13 '23 at 14:22

0 Answers0