Windows Authorization in XMLHttp

almarka

Hello everyone.

Here is the scenario.

Three-tier environment. Database with couple of companies.

We use 'Microsoft XML, v6.0'.ServerXMLHTTP automation to send commands from one company into another.

Everything works just fine except one small thing. When we generate the command to webservice, we specify username and password in the xmlhttp.Open method, which is not really good, as then all users will use the same account to connect.

If we do not specify username and password in the Open method then the system tries to connect to NAV with anonymous account.

Is there any way to make xmlhttp connect with the windows account automatically without putting username and password manually into the connection string?

Thanks!

ara3n

I think you can have a setup table to link the user to the pw and login and have separate login/pw for each user.

almarka

Thanks for the answer. You are right, it is possible solution, but not really workable. Two reasons:

1) Security.
2) Duplication (with AD) and synchronization of data (if, for example, user changes his password in AD it will not be automatically changed in NAV table).

I thought that there could be some kind of a boolean parameter which would say "Windows Authorization". Isn't it there?

How do you, guys, send messages from NAV towards the webservices? Do you always use the "hardcoded" combination of password and user? Or probably we are using wrong automation and there is another better way to do that?

Thanks for your replies!

ara3n

If you are doing this on RTC. have you tried to instantiate the dll on client and try it without specifying login/pw which would authenticate using windows authenication.

Condor

We are trying to do the same thing, using a different company by using the webservices. We are using ServerXmlHttp in stead of XmlHttp to skip the logindialog. Without any further modifications we get an 401 (unautorized) response from the server.

Next we configure the winhttp stack with proxycfg to bypass the server. Eg. proxycfg -d -p " " "*". And the ServerXmlHttp component uses NTLM/integrated authentication with the current windows user. This has to be done for each computer using this code however...

But it doesn't work in all cases. On a different location with a W2K8 server we get the 401 message and cannot find the solution how to get it to work. Does anyone have experience debugging this kind of scenario's?

ara3n

have you setup delegation? what is your server configuration?

Condor

On the site that does work we have setup a three thier environment including delegation.

On the site that does not work all tiers are installed on the same server! The funny thing is that we got an beautifull error message in the eventlog on this site when we used basic authentication, supplying the name and password in the request: that a SPN was probably missing. Never before we got this much information! But when we do not supply the username and password in the request we get the not autorized message.

The working setup is: client windows 7, webservice W2K8 standard SP2, database W2K3 Enterprise SP2, Dynamics version 2009 R2.
The failing setup is: server is W2K8 R2 Standard (client, webservice, database), Dynamics is version 2009 SP1.

I am just wondering what the best way is to go from here. I cannot use easy tools like Fiddler because the winhttp stack is used. Wireshark on a productionserver might introduce other problems.

ldreamsl

I hope to be help.

You can simply set the proxy in this way (in the code):

XmlHttp is 'Microsoft XML, v6.0'.ServerXMLHTTP60

IF (User <> '') THEN BEGIN
  //Use this Credentials
  XmlHttp.open('POST',URL,0,User,Password);
END ELSE BEGIN
  //Proxy for current windows user
  XmlHttp.setProxy(2,' ','*');
  XmlHttp.open('POST',URL,0);
END;

If the function is provided credentials are used ones, otherwise set the proxy to use the current windows user.

ara3n

Thanks for sharing this.

Condor

Coincidence? We found the solution last week!

The server that did not work was a 64-bit machine. Netsh sets the settings on a 64-bit machine for 64-bit applications. The NAV client is 32-bit, therefore the settings for the NAV client did not change.

We had to open a 32 bit command prompt: c:\windows\SysWOW64\cmd.exe and execute the command again: netsh winhttp set proxy proxy-server=" " bypass-list="*". Now we saw the modification in the registry and the solutions works.

Guess the setProxy does the same from code...

ajhvdb

Condor wrote:

Coincidence? We found the solution last week!

The server that did not work was a 64-bit machine. Netsh sets the settings on a 64-bit machine for 64-bit applications. The NAV client is 32-bit, therefore the settings for the NAV client did not change.

We had to open a 32 bit command prompt: c:\windows\SysWOW64\cmd.exe and execute the command again: netsh winhttp set proxy proxy-server=" " bypass-list="*". Now we saw the modification in the registry and the solutions works.

Guess the setProxy does the same from code...

Thanks for sharing, but in which situation do you set this? On the server?, client? and why? a lot of questions, sorry..

koubek

I suppose that i am too late but i have entered coincidentally into the thread...

What I know there is no way to force NTLM and use the credentials of a windows user. You should use another components or you can add you web service machine URL into the "Local Intranet" sites inside Internet Explorer. Using this "trick" NAV won`t ask you anymore for credentials. Using Fiddler you can see that authorization works correctly in the standard way using NTLM (you can see all handshakes)...

Condor

@ajhvdb: we used the command specified on a 64 bit Citrix server.

The reason we used this is because setproxycfg -d -p " " "*" did not work and netsh changed settings for 64 bit applications.

So opening a 32 bit command prompt and executing netsh again solved our problem.