Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

You receive a "Warning SuperSocket Info" warning information when a SQL Server service account is a domain user


View products that this article applies to.

BUG #: 232774 (SHILOH_BUGS)

↑ Back to the top


Symptoms

When SQL Server starts on a computer that is running Microsoft SQL Server 2000 or Microsoft SQL Server 2005, the SQL Server program always attempts to register the virtual server in the Active Directory. The following event may be logged in the event log: NoteError 1355 is equal to ERROR_NO_SUCH_DOMAIN. Error 8344 is equal to insufficient permissions to perform the registration operation. This is shown as a warning for the SPNRegister function and as an error for the SpnUnRegister function.

This message is not an error message. This text is only a warning that SQL Server cannot register a service principal name (SPN). This indicates that the security mechanism that will be used is Microsoft Windows NT Challenge\Response (NTLM) authentication instead of Kerberos authentication.

These messages should only be considered a problem if your SQL Server installation requires Kerberos authentication or the network security settings prevent fallback to NTLM negotiation. Otherwise, these messages can be ignored safely.

↑ Back to the top


Cause

The message usually appears because the SQL Server service account is running as a domain user who does not have requisite permissions to register SPNs. With Microsoft Windows 2000 Service Pack 3 (SP3), you can enable Kerberos authentication on server clusters. For instructions on how to do this, see the following article in the Microsoft Knowledge Base:
319723 Information about SQL Server 2000 Kerberos support, including SQL Server virtual servers on server clusters

↑ Back to the top


Resolution

You can also edit the account's Access Control Settings permissions in the Active Directory directory service to enable the Read servicePrincipalName permission and the Write servicePrincipalName permission for the SQL Service account.

Warning If you use the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP utility, or any other LDAP version 3 clients, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require that you reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems caused by incorrectly modifying Active Directory object attributes can be solved. Modify these attributes at your own risk.

↑ Back to the top


Workaround

To resolve these type messages and enable the SQL Server service to create SPNs dynamically for your SQL Server instances, ask your domain administrator to add the appropriate permissions and user rights to the SQL Server startup accounts.

To enable the SQL Server service account to establish SPNs correctly on startup, follow these steps:
  1. Click Start, click Run, type Adsiedit.msc, and then click OK.
  2. In the ADSI Edit window, expand Domain [DomainName], expand DC= RootDomainName, expand CN=Users, right-click CN=AccountName, and then click Properties.

    Notes
    • DomainName represents the name of the domain.
    • RootDomainName is a placeholder for the name of the root domain.
    • AccountName represents the account that you specify to start the SQL Server service.
    • If you have specified Local System to start the SQL Server service, AccountName represents the account that you use to log on to Microsoft Windows.
    • If you have specified a domain user account for the SQL Server service, AccountName represents the domain user account.
  3. In the CN=AccountName Properties dialog box, click the Security tab.
  4. On the Security tab, click Advanced.
  5. In the Advanced Security Settings dialog box, make sure that the SELF user is listed under Permission entries. If the SELF user is not listed, click Add, and then add the SELF user.
  6. Under Permission entries, click SELF, and then click Edit.
  7. In the Permission Entry dialog box, click the Properties tab.
  8. On the Properties tab, click This object only in the Apply onto list, and then make sure that the following permissions are selected under Permissions:
    • Read servicePrincipalName
    • Write servicePrincipalName
  9. Click OK three times, and then close the ADSI Edit window.
For help with this process, contact Active Directory product support. Refer to this Microsoft Knowledge Base article if you contact product support.

When you perform this workaround, you eliminate SPN issues for new installations or installations that have had the TCP/IP port or domain name modified.

Important We recommend that you do not grant WriteServicePrincipalName right to the SQL service account when the following conditions are true:
  • There are multiple domain controllers.
  • SQL Server is clustered.
In this scenario, the SPN for the SQL Server may be deleted because of latency in Active Directory replication. This may cause connectivity issues to the SQL Server instance.

Assume that you have the following:
  • A SQL virtual instance named Sqlcluster with two nodes: Node A and Node B.
  • Node A is authenticated by domain controller A and Node B is authenticated by domain controller B.


The following may occur:
  1. The Sqlcluster instance is active on Node A and registered the SQL SPN in domain controller A during start up..
  2. The Sqlcluster instance fails over to Node B when Node A is shutdown normally.
  3. The Sqlcluster instance deregistered its SPN from domain controller A during the shutdown process on Node A.
  4. The SPN is removed from domain controller A but the change has not yet been replicated to domain controller B.
  5. When starting up on Node B, the Sqlcluster instance tries to register the SQL SPN with domain controller B. Since, the SPN still exists Node B does not register the SPN.
  6. After some time, domain controller A replicates the deletion of the SPN (from step 3) to domain controller B as part of Active Directory replication. The end result is that no valid SPN exists for the SQL instance in the domain and hence you see connection issues to the Sqlcluster instance.

Note This issue is fixed in SQL Server 2012.

↑ Back to the top


Status

Microsoft has confirmed that this is a problem in SQL Server 2000 and SQL Server 2005.

↑ Back to the top


References

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

235529 Kerberos support on Windows 2000-based server clusters

269229 How to manually re-create the Cluster service account

↑ Back to the top


Keywords: kb, kbyukonsweep, kbappliestoyukon, kbbug, kbdsupport, kbpending

↑ Back to the top

Article Info
Article ID : 303411
Revision : 1
Created on : 1/7/2017
Published on : 4/7/2013
Exists online : False
Views : 932