Detections
Analytics

SQLI-22-003800 - SQL Server must be configured to use the most-secure authentication method available.

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Enterprise environments make account management for applications and databases challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Managing accounts for the same person in multiple places is inefficient and prone to problems with consistency and synchronization.

A comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed.

Examples include, but are not limited to, using automation to act on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in noncentralized account stores, such as multiple servers. Account management functions can also include assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephone notification to report atypical system account usage.

SQL Server must be configured to automatically use organization-level account management functions, and these functions must immediately enforce the organization's current account policy.

Automation may comprise differing technologies that when placed together contain an overall mechanism supporting an organization's automated account management requirements.

SQL Server supports several authentication methods to allow operation in various environments, Kerberos, NTLM, and SQL Server. An instance of SQL Server must be configured to use the most secure method available. Service accounts used by SQL Server should be unique to a given instance.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

Ensure Service Principal Names (SPNs) are properly registered for the SQL Server instance.

Use the Microsoft Kerberos Configuration Manager to review Kerberos configuration issues for a given SQL Server instance.

https://www.microsoft.com/en-us/download/details.aspx?id=39046

Alternatively, SPNs for SQL Server can be manually registered.

For other connections that support Kerberos the SPN is registered in the format MSSQLSvc/<FQDN>/<instancename> for a named instance. The format for registering the default instance is MSSQLSvc/<FQDN>.

Using an account with permissions to register SPNs, issue the following commands from a command-prompt:

setspn -S MSSQLSvc/<Fully Qualified Domain Name> <Service Account>
setspn -S MSSQLSvc/<Fully Qualified Domain Name>:<TCP Port> <Service Account>
For a named instance, use:
setspn -S MSSQLSvc/<FQDN>:<instancename> <Service Account>
setspn -S MSSQLSvc/<FQDN>:<TCP Port> <Service Account>

Restart the SQL Server instance.

More information regarding this process is available at https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections#Manual.

See Also

https://dl.dod.cyber.mil/wp-content/uploads/U_MS_SQL_Server_2022_Y25M06_STIG.zip

Item Details

References: CAT|I, CCI|CCI-000015, Rule-ID|SV-271264r1111061_rule, STIG-ID|SQLI-22-003800, Vuln-ID|V-271264

Plugin: MS_SQLDB

Control ID: afcd22f6c302895cfbfe1536e4292d8156c9da8dc771bcdb7810a4a5bffe007f