How the three-tier architecture works in NAV 2009

The Role Tailored architecture is a three-tiered architecture which contains the following levels:

• Presentation level (Role Tailored client)
  
• Business logic and communication level (Microsoft Dynamics NAV Server)
  
• Data level (SQL Server database)
  

The different tiers can be installed on different computers. You can have multiple instances of any of the components (though usually not on the same computer): multiple clients, multiple servers, and multiple database servers.

Three terms keep coming up when setting up Client, NAV Server and SQL Server on different machines.

• Delegation / Impersonation
  
• Kerberos
  
• SPN
  

Delegation / Impersonation:

When the Role Tailored client, Microsoft Dynamics NAV Server, and SQL Server are all installed on separate computers, the client interacts with the database through an intermediate computer, which is running Microsoft Dynamics NAV Server. The server is performing actions on the client's behalf. This process is known as impersonation.

Delegation is when a front-end service forwards a client request to a back-end service so that the back-end service can also impersonate the client. Impersonation is typically used to check whether a client is authorized to perform a particular action, while delegation is a way of flowing impersonation capabilities, along with the client's identity, to a back-end service.

All logins here are Windows logins. Impersonation would be a nice way for hackers to gain access, so therefore Windows requires 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. In this case there is no need to set up delegation, and hence no need to worry about Kerberos and SPNs.

But with multiple 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 (shouldn'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)
   
2. Quite a common problem: 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 require 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 won't work either.

Creating Service Principal Names

The first step in setting up delegation is to create any necessary service principal names (SPNs). To make delegation more secure, Active Directory uses Kerberos to authenticate services. An SPN is the name by which a client uniquely identifies an instance of a service, using the account under which the service runs. To make delegation work, you must explicitly create an SPN when either the Microsoft Dynamics NAV Server service or the SQL Server service is running under a dedicated domain user account. We recommend using this configuration for the highest security. If both services are running under dedicated domain user accounts or under the same dedicated domain user account, you must create two SPNs: one for each service.

Note: You have the setspn command-line tool installed on your server. In Windows Server 2008, the setspn tool is included if you have installed the Active Directory Domain Services server role. In Windows Server 2003, you must download the Windows Server 2003 Service Pack 2 32-bit Support Tools to get the setspn tool.

To create a service principal name

1. Open an elevated command prompt. Click Start, and in the search window, type Command Prompt.
   
2. Right-click Command Prompt, and then click Run as administrator.
   
3. At the command prompt, create the SPN. The syntax is:
   

   setspn –A InstanceName/FullyQualifiedDomainNameOfServer:Port Domain \User
   

Delegating Access to the SQL Server Service

Configuring delegation means explicitly configuring the Microsoft Dynamics NAV Server service to delegate its access to the database server on behalf of the RoleTailored client. To make the access more secure, you specify delegation to a specific service on a specific server.

To delegate access to the SQL Server service

1. On any server computer in the domain, click Start, and then click Run.
   
2. In the Open field, type dsa.msc.
   

   This opens the Active Directory Users and Computers utility.
   

3. For you to configure delegation, the functional level for the domain must be Windows Server 2003 or higher. To verify the domain functional level, right-click the node for the domain where you have installed Microsoft Dynamics NAV, and then click Raise Domain Functional Level. If the level is not at least Windows Server 2003, raise it to that level.
   
4. Right-click the node for the domain where you have installed Microsoft Dynamics NAV, and then click Find.
   
5. In the Find Users, Contacts, and Group dialog box, type the name of the domain user in the Name field, and then press ENTER.
   
6. In the Search results area, right-click the domain user, and then click Properties.
   
7. On the Delegation tab, click Trust this user for delegation to specified services only, and then click Use Kerberos only.
   
8. Click Add to open the Add Services dialog box.
   
9. In the Add Services window, click Users or Computers, and then type the name of the domain user.
   
10. In the list of services for the domain user, click MSSQLSvc, which is the name of the SQL Server service.
    
11. Click OK to exit the Add Services dialog box.
    

Click OK to close all open dialog boxes.