Service Principal Name not registered on older OS if NetworkServic
tcsosi
my service starts. If my service's log on is LocalSystem then the SPN is
registered correctly. If the service's log on is NetworkServices then this
fails. This only occurs on older OS's like XP (32 or 64bit) and Windows
Server 2003. On new OS's like Vista, Window 7 and Windows Server 2008 this
isn't a problem.
The documentation for DsServerRegisterSpn states the service does require a
log on as LocalSystem, but I observed that SQL server doesn't seem to have
this issue on the older OS's and successfully registers the following:
MSSQLSvc/tim.osisoft.int:1433 even if the SQL server's log on is
NetworkServices.
My SPN call looks like the following:
DsServerRegisterSpn(
DS_SPN_WRITE_OP.DS_SPN_ADD_SPN_OP, name, null);
where name is the SPN string. The error returned is 1212 which equates to:
"The format of the specified domain name is invalid."
Can you tell me why SQL can register, but my code cannot and a work around
to make it work.
Thanks in advance.
--
UI Developer
Gerry Hickman
> I'm attempting to add a service principal name using DsServerRegisterSpn when
> my service starts. If my service's log on is LocalSystem then the SPN is
> registered correctly. If the service's log on is NetworkServices then this
> fails. This only occurs on older OS's like XP (32 or 64bit) and Windows
> Server 2003. On new OS's like Vista, Window 7 and Windows Server 2008 this
> isn't a problem.
> The documentation for DsServerRegisterSpn states the service does require a
> log on as LocalSystem, but I observed that SQL server doesn't seem to have
> this issue on the older OS's and successfully registers the following:
> MSSQLSvc/tim.osisoft.int:1433 even if the SQL server's log on is
> NetworkServices.
> My SPN call looks like the following:
Can you be more clear about where you expect this SPN to be registered?
My understanding, is that it can either be on an AD computer object, or
on an AD user object (e.g. service account). I'm assuming you are
running the service installer on a domain joined workstation and expect
the SPN to magically appear in AD?
With SQL server, if you use pre-staged domain user accounts to run the
services (which you should), they often can NOT register their SPNs. If
you get SQL server to create the accounts at install time, they probably
CAN register because they mess with the security. It depends on what
access level (to AD) the installer process has. I run many SQL server
instances where all services run as domain users, and the DBAs don't
have Admin rights - I always have to create the SPNs manually.
> DsServerRegisterSpn(
>
> DS_SPN_WRITE_OP.DS_SPN_ADD_SPN_OP, name, null);
>
> where name is the SPN string. The error returned is 1212 which equates to:
> "The format of the specified domain name is invalid."
>
> Can you tell me why SQL can register, but my code cannot and a work around
> to make it work.
> Thanks in advance.
>
--
Gerry Hickman (London UK)
Gerry Hickman
news:0D63A7AB-84BE-4960...@microsoft.com...
> We are attempting to register a computer account.
You mean you're trying to add an SPN entry to the servicePrincipalName
attribute of a coputer account in AD? We assume this to be the same computer
upon which you are installing the service?
> We observed that SQL was able to register correctly using the Log On of
> NetworkServices so we wondered why ours was not.
I assume you mean SQL server is able to add an SPN entry to the
servicePrincipalName attribute of a coputer account in AD? The computer upon
which SQL server is running? This part I'm not sure of. All the information
I can find about SQL server is related to adding an SPN entry to the
servicePrincipalName of a USER account in AD - the account that's running
the SQL service.
Strangely, it claims that if SQL server is running as LOCAL SYSTEM, it can
"automatically" register the SPN. This seems odd to me, because I thought
LOCAL SYSTEM could only access "local" resources - changing an AD user
account is not a local operation. In theory, it could work as NETWORK
SERVICE, provided the target account allows write access by NETWORK SERVICE.
I looked at all our SQL 2005 servers, they do NOT have any SPN on their
computer accounts, but they do have SPNs on the user accounts that run the
services (because I put them there manually).
In this article:
http://msdn.microsoft.com/en-us/library/ms189585(SQL.90).aspx
It says:
"If the SQL Server service is running under the LocalSystem account, you do
not have to manually configure an SPN for SQL Server. The SPN is created
automatically when the SQL Server service starts. If the SQL Server service
runs under a domain user account, you must manually configure an SPN. To do
so, follow these steps."
Then in this article, it has info about self registration:
http://support.microsoft.com/kb/319723
It says:
"To configure the SQL Server service to create SPNs dynamically when the SQL
Server service starts, follow these steps:"
It's using the SELF security principal to allow read/write of SPNs, but in
my view, this should only work for user accounts when the user running the
process is the same as the user account being changed - I don't see how it
could work with computer accounts...
--
Gerry Hickman
London (UK)
> "Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message
> news:usclFJ9Y...@TK2MSFTNGP06.phx.gbl...