Unable to verify web service from another machine

anieanie Member Posts: 14
edited 2009-09-30 in NAV Three Tier
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/CR ... ./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.

Regards

Comments

  • apankoapanko Member Posts: 70
    anie wrote:
    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.
  • anieanie Member Posts: 14
    Thanks for such a quick response.
    I have tried the machine name as well as IP, still unable to verify the services.
  • apankoapanko Member Posts: 70
    Can you ping computer with web-services from the second machine?

    Also try to disable firewall.
  • anieanie Member Posts: 14
    Firewall is disabled.
    Still it is not working.
    Do I need to change any other configuration?
  • freddy.dkfreddy.dk Member, Microsoft Employee Posts: 360
    What page do you get?
    Is the two machines in the same domain?
    Is there anything in the event log?
    Freddy Kristiansen
    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.
  • tedcjohnstontedcjohnston Member Posts: 41
    Having what I think is the same problem:

    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.
  • anieanie Member Posts: 14
    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
  • tedcjohnstontedcjohnston Member Posts: 41
    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.
  • Scott_FrappierScott_Frappier Member Posts: 90
    Anie:

    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

    Symbiant Technologies, Inc.
    http://www.symbiantsolutions.com
Sign In or Register to comment.