What do SPNs actually do - NAV 2009

Three terms keep coming up when setting up NAV 2009 when NAV-server (middle tier) runs on a different machine than SQL Server:
  - Delegation / Impersonation
  - Kerberos
  - SPN

Delegation / Impersonation is what it says it is. Kerberos is handled more or less automatically by Windows. But what do SPNs actually do....

(un)fortunately SPN can't be explained without first explaining Delegation and Kerberos.

Delegation / Impersonation:
The end-user (RTC) logs on to the NAV-Server which then logs on to the SQL Server - using the end-user's credentials (impersonating the end-

user). All logins here are Windows logins. Impersonation would also be a nice way for a hacker to gain access, so therefore Windows requires

that a domain administrator specifically allows the NAV-server to impersonate users on the SQL Server.

This is only when the NAV-Server and SQL Server runs on two different machines. When they run on the same machine, then Windows has already

authenticated the end-user when they connected to the NAV-Server. So when the NAV-Server logs on to the SQL Server (on the same machine),

Windows has already knows the end-user. So in this case there is no need to set up delegation, and hence no need to worry about Kerberos and

SPNs.

But with two machines, delegation is needed. Delegation requires Kerberos.

Kerberos:
Connections between two users happen all the time. What Kerberos adds to such a connection is a certificate (ticket) which ensures that each

of the two users can trust the identity of the other user. This is actually a kind of countermeasure against a user (hacker) impersonating

another user. Windows requires that before it allows delegation, that the connection being delegated is a Kerberos connection. In this way,

Windows has assurance that the user credentials being forwarded are valid. So when RTC connects to the NAV-server, it has to do this with a

Kerberos connection.

A Kerberos connection is between two Windows user accounts. A user doesn't know (shoulnd't know) what user account the NAV-server runs under.

This is where SPNs come in. So, finally we get to the SPNs:

SPN:
SPN (Service Principal Name) is a simple table that maps a service to a user account. Think of it as a table with two fields: Service-name,

and Windows User name. When the NAV client wants to start a Kerberos connection to the NAV-server, it will connect to for example

DynamicsNAV\Nav-Server:7046. Kerberos requiring a user name will then look this up in the SPN table and find the user name there. So, only if

an SPN has been created for the account that runs the NAV-service, will Windows be able to then start a Kerberos connection. And the user will

never need to know which that account the NAV-server is running under.

When setting up SPNs, make sure that:
  1) The account that runs the NAV-service has an SPN that contains what the NAV client will connect to (Server name in the right format),and
  2) Quite a common probem: Make sure that there are no duplicate SPNs. If you change the NAV-service to run under a different account you must set up SPNs for the new account. Then make sure to also remove the SPNs for the old account.

So in short: Delegation / Impersonation requires Kerberos. Kerberos connection to a service running an unknown account, requires SPN. And,

visa versa, if SPNs have not been set up correctly, then Kerberos won't work so then Delegation wont work either.

These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use. 

Best regards

Lars Lohndorf-Larsen

Microsoft Dynamics UK

Microsoft Customer Service and Support (CSS) EMEA