I have created a codeunit web service and published it. I can verify it from the local machine using this url:
http://localhost:7047/DynamicsNAV/WS/CRONUS_International_Ltd./services
But when I try to do the same from another machine inside the same domain, the page does not get displayed. Please suggest what I should do.
Hi,
Try to use name of the computer on which the web services run instead of localhost.
The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
Followed walkthrough on installing on three computers.
Setup the SPNs for NST and for web services (two different walk throughs).
On the machine where NST is installed, if I load IE with the address- http://localhost:7047/DynamicsNAV/WS/Services
I get the WSDL showing the single published web service and the System Service. No login prompt is displayed.
However, if I substitute the machine name or IP address for localhost, on the same machine, I get the login message. If I login as administrator, I get the WSDL. If I login as a user account in the domain admin group, I get an failure to load HTTP 500 message.
On the SQL server, in the Application Log, I get a Failure Audit message 18456- Anonymous Login failed.
It appears that I've messed up something in the delegation between the NST and SQL. Or, is there a setup on a user account needed to use it with Web Services? The user account is a super use in NAV.
"There are only two truly infinite things: the universe and stupidity. And I am unsure about the universe." - Albert Einstein
Corollary- Build and idiot proof system and nature will build a better idiot.
When I try to access the web service url from another machine in the same LAN and Domain, the page is showing "The website cannot display the page".. though it can be easily be varified from the machine where it is hosted.
](*,)
Somebody.. PLEASE HELP
Thanks guys for the way you always help and support
Regards,
Anish
Just fixed my issue (with the help of my local Solution Center!).
I had SQL running under a different user than the NST. In this case, the setspn command for MSSQLSvc needs to be for the user that SQL is running under, NOT the user that the NST is running under.
My bad. :oops:
Hope this helps!
Thanks to Scott Frappier for helping me out! \:D/
"There are only two truly infinite things: the universe and stupidity. And I am unsure about the universe." - Albert Einstein
Corollary- Build and idiot proof system and nature will build a better idiot.
As Ted stated - he was running into a very similar issue - and while I have it fresh in my mind, I wanted to offer some assistance.
Assumptions:
You MUST be running NAV 2009 SP1 or the hotfixes that address the SPN changes in NAV 2009 RTM for these settings to work. If you're using pre-SP1 with no hotfixes, there is a different syntax for the setspn which you can find in the doc/installation folder of the root of the NAV 2009 DVD - it documents how to setup 3-tiers on 3-machines and is recommended reading to start.
I'd do the following:
===Verify that your domain functional level is set to Windows 2003===
Open Domains and Trusts from the Domain Controller
Right-click on the domain in question and go to "Properties"
You should see the Domain Functional Level sitting at Windows Server 2003 - if it is not, verify that you can upgrade the domain functional level before doing it because you cannot "undo" the change.
If your Forest Functional Level is at Windows 2000, don't worry about it, it does not need to be upgraded.
===Verify that you have the SPN's setup correctly for both the SQL Server service===
SQL Server (command prompt)
setspn -L DOMAIN\SQLServerServiceAccount
You should have output that has the following:
MSSQLSvc/machinename.domain.suffix:1433
MSSQLSvc/machinename:1433
If you do not have that output, issue the following commands (does not change if you are running NAV 2009 RTM or SP1):
setspn -A MSSQLSvc/machinename:1433 DOMAIN\SQLServerServiceAccount
setspn -A MSSQLSvc/machinename.domain.suffix:1433 DOMAIN\SQLServerServiceAccount
===Verify that you have the SPN's setup correctly for NST/WS layer===
NST (command prompt)
setspn -L DOMAIN\NSTServiceAccount
You should have output that has the following (for RTC and WS):
http/machinename
http/machinename.domain.suffx
InstanceName/machinename:7046
InstanceName/machinename.domain.suffx 7046
If you do not have that output, issue the following commands:
// Web Services
setspn -A http/machinename DOMAIN\NSTServiceAccount
setspn -A http/machinename.domain.suffix DOMAIN\NSTServiceAccount
// RoleTailored Client - NST
setspn -A InstanceName/machinename:7046 DOMAIN\NSTServiceAccount
setspn -A InstanceName/machinename.domain.suffix:7046 DOMAIN\NSTServiceAccount
Remember - InstanceName is by default the "DynamicsNAV" when it is installed. If you changed this in your config file on the NST, you must reflect this in the SPN.
Also note - you can delete old SPN's by issuing statements similar to the following:
setspn -D http/machinename DOMAIN\NSTServiceAccount
setspn -D InstanceName/machinename:7046 DOMAIN\NSTServiceAccount
===Verify that the Kerberos Delegation is setup for the NST Service Account===
Open Active Directory User's and Computers on your domain controller
Navigate to the NST Service Account that you are using
Right-click and go to Properties
Go to the "Delegation" tab
Select "Allow Delegation for these specific services"
Click on "Add"
Search for "DOMAIN\SQLServerServiceAccount"
You should be presented with information that states "MSSQLSvc/machinename:1433" - highlight it and press "OK"
The account should now show delegation to the MSSQLSvc for that user account
===Verify that the NSTServiceAccount has the correct local security policy===
On the NST Server, go to the Local Security Policy (translate all of this if you know how to use the Group Policy Security).
Go to User Rights Assignment
Grant DOMAIN\NSTServiceAccount the "Act as part of the operating system" and "Impersonate a client after authentication"
This is not documented in the setup help, but is documented as part of the general Kerberos setup's for other applications that I have worked with - you may not need to do this for the setup.
===Restart all services and purge your Kerberos Ticket Cache===
Stop all services (SQL, NST, and WS)
Go to each machine, run kerbtray.exe (download it if you need to) and then select "Purge Tickets" so that the Kerberos ticket cache is cleared - tickets are held for a couple of days by default and are only purged after a time period expires, or a machine is rebooted.
Start all services
After this is all said and done, you should be able to either use the machinename or FQDN to connect to the web service (instead of just using the localhost). As for an IP address, I have not successfully been able to get a direct IP address to work with web services - we have always used either just the machinename or the FQDN to access the services.
Let me know if this helps and if you are up and running.
- Scott
Scott Frappier
Vice President, Deployment Operations
Comments
Hi,
Try to use name of the computer on which the web services run instead of localhost.
I have tried the machine name as well as IP, still unable to verify the services.
Also try to disable firewall.
Still it is not working.
Do I need to change any other configuration?
Is the two machines in the same domain?
Is there anything in the event log?
Group Program Manager, Client
Microsoft Dynamics NAV
http://blogs.msdn.com/freddyk
The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
Followed walkthrough on installing on three computers.
Setup the SPNs for NST and for web services (two different walk throughs).
On the machine where NST is installed, if I load IE with the address-
http://localhost:7047/DynamicsNAV/WS/Services
I get the WSDL showing the single published web service and the System Service. No login prompt is displayed.
However, if I substitute the machine name or IP address for localhost, on the same machine, I get the login message. If I login as administrator, I get the WSDL. If I login as a user account in the domain admin group, I get an failure to load HTTP 500 message.
On the SQL server, in the Application Log, I get a Failure Audit message 18456- Anonymous Login failed.
It appears that I've messed up something in the delegation between the NST and SQL. Or, is there a setup on a user account needed to use it with Web Services? The user account is a super use in NAV.
Corollary- Build and idiot proof system and nature will build a better idiot.
](*,)
Somebody.. PLEASE HELP
Thanks guys for the way you always help and support
Regards,
Anish
I had SQL running under a different user than the NST. In this case, the setspn command for MSSQLSvc needs to be for the user that SQL is running under, NOT the user that the NST is running under.
My bad. :oops:
Hope this helps!
Thanks to Scott Frappier for helping me out! \:D/
Corollary- Build and idiot proof system and nature will build a better idiot.
As Ted stated - he was running into a very similar issue - and while I have it fresh in my mind, I wanted to offer some assistance.
Assumptions:
You MUST be running NAV 2009 SP1 or the hotfixes that address the SPN changes in NAV 2009 RTM for these settings to work. If you're using pre-SP1 with no hotfixes, there is a different syntax for the setspn which you can find in the doc/installation folder of the root of the NAV 2009 DVD - it documents how to setup 3-tiers on 3-machines and is recommended reading to start.
I'd do the following:
===Verify that your domain functional level is set to Windows 2003===
Open Domains and Trusts from the Domain Controller
Right-click on the domain in question and go to "Properties"
You should see the Domain Functional Level sitting at Windows Server 2003 - if it is not, verify that you can upgrade the domain functional level before doing it because you cannot "undo" the change.
If your Forest Functional Level is at Windows 2000, don't worry about it, it does not need to be upgraded.
===Verify that you have the SPN's setup correctly for both the SQL Server service===
SQL Server (command prompt)
setspn -L DOMAIN\SQLServerServiceAccount
You should have output that has the following:
MSSQLSvc/machinename.domain.suffix:1433
MSSQLSvc/machinename:1433
If you do not have that output, issue the following commands (does not change if you are running NAV 2009 RTM or SP1):
setspn -A MSSQLSvc/machinename:1433 DOMAIN\SQLServerServiceAccount
setspn -A MSSQLSvc/machinename.domain.suffix:1433 DOMAIN\SQLServerServiceAccount
===Verify that you have the SPN's setup correctly for NST/WS layer===
NST (command prompt)
setspn -L DOMAIN\NSTServiceAccount
You should have output that has the following (for RTC and WS):
http/machinename
http/machinename.domain.suffx
InstanceName/machinename:7046
InstanceName/machinename.domain.suffx 7046
If you do not have that output, issue the following commands:
// Web Services
setspn -A http/machinename DOMAIN\NSTServiceAccount
setspn -A http/machinename.domain.suffix DOMAIN\NSTServiceAccount
// RoleTailored Client - NST
setspn -A InstanceName/machinename:7046 DOMAIN\NSTServiceAccount
setspn -A InstanceName/machinename.domain.suffix:7046 DOMAIN\NSTServiceAccount
Remember - InstanceName is by default the "DynamicsNAV" when it is installed. If you changed this in your config file on the NST, you must reflect this in the SPN.
Also note - you can delete old SPN's by issuing statements similar to the following:
setspn -D http/machinename DOMAIN\NSTServiceAccount
setspn -D InstanceName/machinename:7046 DOMAIN\NSTServiceAccount
===Verify that the Kerberos Delegation is setup for the NST Service Account===
Open Active Directory User's and Computers on your domain controller
Navigate to the NST Service Account that you are using
Right-click and go to Properties
Go to the "Delegation" tab
Select "Allow Delegation for these specific services"
Click on "Add"
Search for "DOMAIN\SQLServerServiceAccount"
You should be presented with information that states "MSSQLSvc/machinename:1433" - highlight it and press "OK"
The account should now show delegation to the MSSQLSvc for that user account
===Verify that the NSTServiceAccount has the correct local security policy===
On the NST Server, go to the Local Security Policy (translate all of this if you know how to use the Group Policy Security).
Go to User Rights Assignment
Grant DOMAIN\NSTServiceAccount the "Act as part of the operating system" and "Impersonate a client after authentication"
This is not documented in the setup help, but is documented as part of the general Kerberos setup's for other applications that I have worked with - you may not need to do this for the setup.
===Restart all services and purge your Kerberos Ticket Cache===
Stop all services (SQL, NST, and WS)
Go to each machine, run kerbtray.exe (download it if you need to) and then select "Purge Tickets" so that the Kerberos ticket cache is cleared - tickets are held for a couple of days by default and are only purged after a time period expires, or a machine is rebooted.
Start all services
After this is all said and done, you should be able to either use the machinename or FQDN to connect to the web service (instead of just using the localhost). As for an IP address, I have not successfully been able to get a direct IP address to work with web services - we have always used either just the machinename or the FQDN to access the services.
Let me know if this helps and if you are up and running.
- Scott
Vice President, Deployment Operations
Symbiant Technologies, Inc.
http://www.symbiantsolutions.com