Any daemon that uses Kerberos to authenticate its clients should have a service principal name (SPN) in the directory. Configuring an SPN is straightforward; in fact, there's a tool that ships with the server version of Windows called setspn.exe that can be used to add these mappings. If you're running Windows 2000, you can find this tool in the Windows 2000 Resource Kit. Or you can write some code yourself to call the Win32 function DsWriteAccountSpn, which is really all that setspn.exe does anyway.

The structure of an SPN looks like this: class/host:port/name, where class represents the type of service (for example, "MSSQLSvc," "ldap," or "www") and host is the machine name (either a DNS or NETBIOS name). The port and instance fields are optional; port isn't necessary if the daemon is listening on its default port, but it can be useful if several instances of the daemon are running on the same machine, listening on different ports. The name field is used by replicated services such as Active Directory, but most services won't make use of this feature and can omit it.

Here's an example: Say you have a Windows service called weathersvc that runs on a machine called jupiter and listens on the service's default port. On that machine, you've decided to run the service under a domain account named WeatherDaemon. In this case, you add an SPN to the WeatherDaemon account (actually I'm adding two SPNs here; you'll see why shortly).

 setspn -A weathersvc/jupiter.acme.com MyDomain\WeatherDaemon
 setspn -A weathersvc/JUPITER MyDomain\WeatherDaemon

Let's say you're also running this same service on a machine called titus, but there it runs as Network Service. Because it's running with the machine's credentials, you need to add an SPN to the machine account titus.

 setspn -A weathersvc/titus.acme.com MyDomain\titus
 setspn -A weathersvc/TITUS MyDomain\titus

For each example, I registered two SPNs: one using the DNS name and one using the NETBIOS name of the host. This is convenient because it allows the client to specify either name, but bear in mind that NETBIOS names might not be unique across the directory and, if a duplicate SPN is found in the directory, authentication will fail. If you're worried about this, use only DNS names when registering SPNs, and make sure your clients always use the fully qualified DNS name when making authenticated connections to a server using Kerberos.

SQL Server 2000 uses this mechanism. If you decide to run an instance of it under a domain account, you'll need to add an SPN (the service class in this case is MSSQLSvc). It's useful to consider how the client-side libraries for SQL Server 2000 pick apart a connection string and form an SPN when they authenticate with a server. It's really quite simple once you understand how SPNs work.

1. Pull the server name out of the connection string.
2. Form the SPN as follows: string.Format("MSSQLSvc/{0}:1433", hostName).
3. Use this SPN when authenticating with the database.

If you build your own Kerberized system, you should incorporate the use of SPNs to ensure that you're getting mutual authentication. This means building client-side code that forms the SPN based on the names of your service class and the host (and perhaps the port) to which the client is connecting. It also means registering an SPN for each instance of your server in Active Directory. I provide an example of this in How to add CIA to a socket based app.

Remember that this works only if you run your server under a domain account or one of the built-in logon sessions (Network Service or SYSTEM) on a machine that is part of a domain. SPNs aren't used with local accounts because Kerberos isn't used with local accounts!

Also, if you're using named pipes, DCOM, or HTTP, you shouldn't need to add any SPNs because the system maps these services onto a well-known SPN with a service class of HOST. These SPNs are automatically added whenever a machine joins the domain.

PortedBy VineetGupta