DsWriteAccountSpn

Question

DsWriteAccountSpn

Jim P.

SSCrazy Eights

Points: 8725
More actions
March 10, 2005 at 2:52 pm

#88282
This is just to see how others are getting around this...
We don't use Kerberos security. The userid we are using to run SQL Server is not a domain admin account.
So we end up with the warning in the Event Viewer
Source: MSSQLServer EventID: 19011 Description: SuperSocket info: (SpnRegister) : Error 8344
On support.microsoft.com at SQL Server Service Principle Name creation. That refers to the DsWriteAccountSpn article which states
```
To protect against security attacks where an
application or service fraudulently registers an
SPN that identifies some other service, the
default DACL on user and computer accounts allows
only domain administrators to register SPNs in
most cases. 

One exception to this rule is that a service
running under the LocalSystem account can call
DsWriteAccountSpn to register a simple SPN of the
form "ServiceClass/Host: Port" if the host
specified in the SPN is the DNS or NetBIOS name of
the computer on which the service is running.
```
But the advice from Microsoft says not to use LocalSystem or Domain Admin account to run SQL Server.
Catch-22. Anybody have a solution?

----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply

gbn SSCertifiable Points: 6429 More actions · Answer 1

If the SQL Service account is not LOCALSYSTEM or a domain admin (or similar) then this error will happen and the SQL acount can't register an SPN.

SPNs (Service Principal Names) aren't used by SQL unless you want to pass-through NT authentication to linked servers rather than explicit mappings to username/passwords.

Our SQL Servers use a standard domain account and they all generate this error. Nothing to worry about.

Jim P. SSCrazy Eights Points: 8725 More actions · Answer 2

I know it technically is a non-issue.

I just hit the event viewer one day after having to do multiple starts and stops on a server - filter out all information and then I hit those warnings.

It's just an irritant when you are looking for real errors.

----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.

Nicholas Cain SSC-Dedicated Points: 33009 More actions · Answer 3

You can prevent these errors by using the setspn utility from MS. This is available from http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/setspn-o.asp

Usage:

setspn MSSQLSvc/servername:1433 accountname

setspn MSSQLSvc/servername.domain:1433 accountname

where servername is the server, domain is the domain and accountname is the service account

Run this on the sql server.

Shamless self promotion - read my blog http://sirsql.net

gbn SSCertifiable Points: 6429 More actions · Answer 4

Without being too blunt, setspn doesn't stop the error.

All our servers have SPNs registered (and delegation etc) as we use lots of linked servers and pass-through authentication and we still get the error.

setspn does set SPNs in AD up, but at service startup SQL doesn't know this so attempts to register one anyway. The SPN is used later only when passing through the NT login token to another server.

Nicholas Cain SSC-Dedicated Points: 33009 More actions · Answer 5

I used to get the error, used setspn and the errors went away. I use windows/sql auth and linkedservers.

Shamless self promotion - read my blog http://sirsql.net

Jim P. SSCrazy Eights Points: 8725 More actions · Answer 6

I did try the setspn and it didn't go away.

Like I said...this is just an irritant, not a show stopper.

----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.