Microsoft really did a number on us with the release of their November 2022 patches, didn't they!

One of the accounts that I am working on has, let's say, some 'technical debt', and needless to say when we still have legacy Windows Server 2003 boxes and SQL Server 2008 in the mixing pot, you have to expect some issues.

Needless to say, when Microsoft released their monthly updates in November 2022, we came across an issue related to the CVE that they are trying to fix in relation to Kerberos identical to what can be seen here.

After much trial and error, we managed to workaround it by deleting the SPN record(s) between Application and SQL server, which essentially causes Kerberos authentication to fail, and forces NTLM authentication, e.g.:

setspn -D MSSQLSvc/sqlservername.fqdn DOMAINNAME\SqlServiceAccount
setspn -D MSSQLSvc/sqlservername.fqdn:1433 DOMAINNAME\SqlServiceAccount

Once that had been done, we restarted the SQL server services, restarted the Application services and restarted IIS.

Risk v reward, being this seems to work, but is obviously then using a less secure authentication protocol.

Further info:

When the SQL Server driver forms an invalid SPN, authentication still works because the SSPI interface tries to look up the SPN in the Active Directory service. If the SSPI interface doesn't find the SPN, Kerberos authentication isn't performed. At that point, the SSPI layer switches to NTLM authentication mode, and the logon uses NTLM authentication and typically succeeds – (see https://learn.microsoft.com/en-us/troubleshoot/sql/connect/cannot-generate-sspi-context-error).

#tech #microsoft

Steve @[email protected]