[Service Graph Connector for Microsoft SCCM] Integrated authentication failures after MID Server patchingIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } After Windows patching or security hardening on the MID Server host, a previously working Service Graph Connector for Microsoft SCCM (SG-SCCM) connection that uses Windows integrated authentication begins to fail. Testing the SCCM data source connection in ServiceNow returns an error similar to: SQLState: nulljava.sql.SQLException: com.microsoft.sqlserver.jdbc.SQLServerException: Integrated authentication failed. ClientConnectionId:<GUID> Symptoms<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Key characteristics: The SG-SCCM connection in an environment was working before the patch window.After patching the MID Server host, all SCCM data source “Test Connection” calls using integrated authentication fail with the error above.A separate SCCM connection using a SQL login (username/password) in another environment (for example, prod) still works, which confirms that SQL Server is reachable and responsive. Facts<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Important scope note: When “Use integrated authentication” is enabled on a JDBC or SCCM Service Graph data source, SQL Server authentication is performed using the Windows identity of the MID Server service account on the MID host.ServiceNow does not participate in the Kerberos / NTLM handshake. If integrated authentication from the MID host fails in native tools (for example, SSMS), the failure is outside the ServiceNow platform and must be corrected in Windows/AD/SQL. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All releases Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } This behavior occurs when Windows integrated authentication between the MID Server host and the SCCM SQL Server breaks at the Windows/AD/SQL layer. In the resolved case that prompted this article, the root cause was a combination of: AES key / encryption configuration for the service account in Active Directory, andSQL Server SPN configuration for the SCCM SQL instance. After the MID host was patched, the effective Kerberos configuration and SPN mapping for the SCCM SQL instance no longer aligned with the service account and its AES settings. As a result, Kerberos negotiation between the MID host and SQL failed, and the Microsoft JDBC driver surfaced a generic “Integrated authentication failed” error when ServiceNow tried to connect using Windows integrated authentication. Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } This will vary based on your environment and infrastructure. In the resolved case, the Windows and SQL teams corrected the AES key and SPN configuration for the relevant service account and SQL instance. Once Kerberos was healthy again, the SSMS Windows Authentication test succeeded and the Service Graph SCCM data source Test Connection in ServiceNow started working without any changes on the ServiceNow side. Validate Windows integrated authentication directly from the MID Server host, outside of ServiceNow: Sign in to the Windows server that hosts the MID Server used by the SCCM connection.Run SQL Server Management Studio (SSMS), or an equivalent SQL client, on the MID host.While logged in as, or explicitly running SSMS as, the same AD account that runs the MID service, attempt to connect to the SCCM SQL instance using Windows Authentication (no SQL username or password). If this SSMS connection fails, the issue is confirmed to be in the Windows or AD or SQL authentication path and not in ServiceNow.If this SSMS connection succeeds but the ServiceNow data source still fails with “Integrated authentication failed”, further ServiceNow platform-side review is required. If the SSMS Windows Authentication test fails, work with your Windows, AD, and SQL teams to restore integrated authentication from the MID host. Focus on the following: Confirm the MID host is joined to the correct domain and its secure channel to the domain is healthy.Confirm the MID service account is active, not locked or disabled, and has not had its password or group memberships changed in ways that would affect SQL access.Review recent changes to security policies applied to the MID host or its OU, particularly those affecting Kerberos or NTLM for outbound connections to SQL.Verify that the correct MSSQLSvc SPNs exist for the SCCM SQL instance and that they are mapped to the correct SQL Server service account.Review encryption options and AES key configuration for the service accounts involved, and ensure these settings are compatible with domain security policies and SQL Server expectations. Retest the SCCM Service Graph connection in ServiceNow.