Kerberos client authentication times out with SQL error 87

Apologies for the length of this but I'm app developer, not a SQL DBA nor network Admin, so I'm out of my area and just wanted to be sure I documented everything as well as I could. This is a problem about authenticating from a client app using Kerberos authentication and a Windows Domain Identity, to a SQL 2022 instance on a host that hosts both SQL 2019 and now SQL 2022. I’ve inherited a problem that was abandoned more than a year ago and got it simply because it involves SQL client connections from an application, or that I’m the old man in group which really doesn’t mean I have more experience, at least not like it used to, but they think it does, so I let them believe it. I’ve solved a number problems that were missed, but I’m still short of making it work because I’m having trouble getting the SPN’s and network protocols correct for Kerberos client connections. Each instances of SQL Server has a unique instance name, the 1st has the instance name “Sql2019”, the 2nd instance “Sql2022” and it’s the 2nd instance that needs Kerberos authentication. One of the things missed by the original group were the client libraries used for OLE DB connections; they were still using SQL Native Client. I have since installed the newer MSOLEDBSQL libraries into the client machines and made the code changes to use Ole DB SQL Connections and other client side components for Kerberos client connections, following MS Documentation on this topic. And not knowing if I was going at this the right way, I installed these client libraries on the machine hosting SQL 2019 and SQL 2022. I believe I have all of the correct elements set up on the client side, I’m not sure about the server side, because I can make an OLE DB connection from the client app and access the application databases, but when a connection is made that requires access to the restricted elements of SQL 2022, such as the Master DB or SSIS when installing and configuring DTS Packages, client authentication fails. The error message I’m getting right now is a SQL Connection timeout SQL Error 87. If I understand MS Docs correctly, the reason for this is because the original SPN setup is no longer valid and or, when an OLE DB client connection initially fails Kerberos authentication, it falls back to NTLM. But SQL 2022 can’t authenticate the NTLM connection because something is incomplete or missing with the SPN’s or something is incorrectly configured with regards to the network protocols used, Named Pipes vs TCP/IP. I’m stuck in this latter area and re-reading the MS Docs is not giving me any insights on where to go next. Here is where things stand as of this post: 1. The SQL Server name is “**SqlServer**” 2. The instance names are “**Sql2019**” and “**Sql2022**”. 3. The host is joined to the domain. 4. The TCP/IP ports for both instances use the default port numbers. 5. The Named Pipes protocol use the default SQL Names assigned at installation. 6. The account that both SQL instances runs under was changed before I was given this task, from NT Service to a domain account named (**SysCred**) and it’s used exclusively for services. That account is a member of the domain wide *Administrators Group*, and I have confirmed that on SQL Server, it is also a member of the *local Administrators Group*. I’m not sure if this is relevant or not, but I have left it as it is. 7. The same can be said for the application that they want accessing SQL 2022 with Kerberos authentication, it too runs under a domain account (**CoreSrvcs**), and at present, that domain account is a member of the *local SQL Server’s Administrators Group*, so I have left it as it is. 8. On SQL Server 2022 I found the following: 9. A SQL Login for the domain account (**SysCred**), who is a member of (*sysadmin, serverdmin*) 10. A SQL 2022 Login for the domain account (**CoreSrvcs**), who is a member of (*sysadmin, serverdmin*) 11. This login is mapped to the application databases, the *Master DB*, and to the *SSIS database*. 12. The SQL Host has AD LDS service installed to synch with the domain controller, and that services appears to be working correctly, I see no error messages in the event logs for it. 13. I queried for SPN’s on the SQL Server and found the following: 14. For the domain service account (**SysCred**) that SQL instances run under 15. *MSSQLSvc/SqlServer.domainame:50895* 16. *MSSQLSvc/SqlServer.domainame:SQL2022* 17. *MSSQLSvc/SqlServer.domainame:1433* 18. *MSSQLSvc/SqlServer.domainame:SQL2019* 19. For the domain account (**CoreSrvcs**) that applications run under: 20. *MSSQLSvc/SqlServer.domainame:50895* 21. *MSSQLSvc/SqlServer.domainame:SQL2022* 22. *MSSQLSvc/SqlServer.domainame:1433* 23. *MSSQLSvc/SqlServer.domainame:SQL2019* 24. In the application components that need to query the *Master DB* or the *SSISSDB*, I changed the code from using the elements in the *System.Data.SqlClient* namespace or the *Microsoft.Data.SqlClient* namespace, to use elements from *System.Data.Ole* as per Microsoft Docs, and as long as I only query the application database, everything works. 25. But when the application attempts to access the *Master DB*, or install and configure DTS packages against the *SSISDB* database, the client connection times out and I see this SQL server error 87. 26. NOTE one of the last changes made per MS Docs was to use a SPN in place of the SQL Server Instance name when setting up an Ole DB Connection, on my last few tries I was using one of the SPN’s listed above, but all produced the same error. My last thought before asking for help was to change the protocol order of SQL Server Configuration Manager, from having TCP/IP first to Named Pipes 1st, not sure this would make a difference, and while I wait for a reply I’ll checkout some trouble shooting tips and tools from https://github.com/microsoft/CSS_SQL_Networking_Tools/wiki