Best Practice - Web Service Logon

Toddy_Boy

Hi All

Working with SQL Server R2 64 bit, Nav2009 Classic Client, Objects 2.6 (old school baby 8) ) we have developed an asp.net website to enable members of the outside world to interact with Navision via web services which works well, however we are having some authentication issues and I'm wondering what the bestter practice would be.

A domain user domainname\dn is used to run the Business Layer services. I would like, for consistency (and not o use another CAL) to use this user's credentials (username and password) when connecting the web service i.e.

objWSClass.Credentials = New Net.NetworkCredential("dn", "dnpassword", "domainname")

However this returns an error when trying to conect to the database when used in a web service call "Login failed when trying to connect to SQL Server", if I use my credentials (I am local SQL Admin) everything works fine.

So, have I missed something obvious setting up the domain\dn user or is the better practice to use a dedicated user to authenticate?

Steve

kine

1) CALs are not about accounts, it is about physical users working with the system. Doesn't matter if you have 100 accounts in the system when physically using it is only one person. It is one CAL. If you have one account,used with 100 users,it is 100 CALs...
2) Is the account defined in NAV and have some roles assigned?

Toddy_Boy

Hi Kine

I can logon with windows authentication as the domain\dn no problem, the user has Super rights.

Steve

kine

May be problems with Kerberos and SPNs?

Toddy_Boy

Hi Kine

Nothing was done with Kerberos for my user (the one that logs the web service on no problem), although we had to do a lot of Kerberos and SPN stuff to get the domain\dn user to function correctly when being used as the service account.

I get the feeling it's something to do with the SQL Server account or admin user account, however both myself and the domain\dn user are local admins on all machines.

Steve

kine

Than try to go through event logs on the service tier and on the SQL server to find more. Look into SQL if the authnetication request is for ANONYMOUS or for correct account. Check that the account have correct permissions on SQL to login...

Toddy_Boy

Error Log on the SQL Server shows

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors.

What does that mean :-k We resolved errors like this with the Kerberos SPN stuff when setting up domain\dn

kine

I recommend to check again the SPNs, date and time on the servers, and that the user account is not somehow disabled for Krberos and delegation (untrusted for delegation etc.)

PhilipAvis

Toddy. Did you find an answer to this problem?

Toddy_Boy

Yes with the aid of our Dynamics partner.

It was a problem with the SPNs and Kerberos. The SPNs were set up incorrectly, these needed to be amended by using the adsiedit.msc - Active Directory Security Information editor for setting SPN's via a GUI. This is part of W2003 Server support tools SP2. Here is a fuller description of what was done and used, hope it's useful.

KerbTray - Kerberos toolkit for looking at Kerberos tickets - download from Microsoft

Setting SPN's for SQL Clusters - and multiple SQL instances http://support.microsoft.com/kb/319723

The key points here are:

1. Use the instructions in the KB article to set the SPN's for SQL - these are dynamically set using these instructions.
2. Set the SPN's on the service names using adsiedit - they DO include the port numbers.
3. Once the SPN's have been setup for the services (SQL service account and Nav server account), the delegation information that needs to be added to the NAV Server account (via active directory users and computers) will be driven by the SPN's that have been set up on the SQL service.
4. Use the kerberos tool to check that the SPN's are working for the RTC connectivity to the NAV server.