SOAP and NTLM Authentication between Debian an IIS Server

Question

I have a problem with a SOAP authentication in PHP. I have check everywhere for an answer without success.

I hope someone 'll be able to help me here !

So, here is the deal.

My PHP application server is a Debian 6 with Apache2 and the web service is based on a IIS Server.

Both servers are inside our company network.

For the connection and authentication I use a class find on the web :

http://tcsoftware.net/blog/2011/08/php-soapclient-authentication/

Here is my code using this class :

<?php 
define('CURLOPT_CERTINFO',1);
ini_set("max_execution_time",120);
ini_set('default_socket_timeout', 120);
ini_set("soap.wsdl_cache_enabled", "0");
ini_set('soap.wsdl_cache_ttl',0);

include('./SoapClientAuth.php');

//WSDL
$soapURL = "http://myApplicationAdress/ws/WEB100T/patient_identite_chargerparid.wsdl";
$soapParameters = Array(
                    'login'          => 'anADLogin',
                    'password'       => 'theADPassword',
                    'exceptions'     => 1,
                    'trace'          => 1,
                    'user_agent'     => '',
                    'keep_alive'     => 1
            ) ;
$soapClient = new SoapClientAuth($soapURL, $soapParameters);

try{
    $soapResult = $soapClient->PatientIdentiteChargerParID(array('PatID' =>'152'));
}
catch(SoapFault $fault)
{
    var_dump($fault);
}

NB : "define('CURLOPT_CERTINFO',1);" is added because this constant is not defined in our php version. If i dont define it, we have an error which is :

[03-Sep-2013 15:10:50 UTC] PHP Notice:  Use of undefined constant CURLOPT_CERTINFO - assumed 'CURLOPT_CERTINFO' in /var/www/vm-test/SoapClientAuth.php on line 97
[03-Sep-2013 15:10:50 UTC] PHP Warning:  curl_setopt() expects parameter 2 to be long, string given in /var/www/vm-test/SoapClientAuth.php on line 97

The result of the connection from a client to the debian server is an 401 Error, cf below :

* About to connect() to web100t-qualif port 80 (#0)
*   Trying 172.16.101.93... * connected
* Connected to web100t-qualif (172.16.101.93) port 80 (#0)
> POST /mwsiissrv.dll/mws/ws/_mws_soap HTTP/1.1
Host: web100t-qualif
Accept: */*
User-Agent: PHP-SOAP
Content-Type: text/xml; charset=utf-8
SOAPAction: "/patient/identite/chargerparid"
Content-Length: 309
Expect: 100-continue
Connection: Keep-Alive

< HTTP/1.1 401 Unauthorized
< Content-Type: text/html
< Server: Microsoft-IIS/7.5
< WWW-Authenticate: NTLM

In a second time, if I comment the line number 97 in SoapClientAuth.php where the constant CURLOPT_CERTINFO is used :

curl_setopt($ch, CURLOPT_CERTINFO, TRUE); 

Then the reponse change as below :

< HTTP/1.1 401 Unauthorized
< Content-Type: text/html
< Server: Microsoft-IIS/7.5
< WWW-Authenticate: NTLM
* gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_33' not found< WWW-Authenticate: Negotiate
< Date: Tue, 03 Sep 2013 12:37:00 GMT
< Content-Length: 1384
<
* Connection #0 to host web100t-qualif left intact
* Closing connection #0
* About to connect() to web100t-qualif port 80 (#0)
*   Trying 172.16.101.93... * connected
* Connected to web100t-qualif (172.16.101.93) port 80 (#0)
> POST /mwsiissrv.dll/mws/ws/_mws_soap HTTP/1.1

I dont know why kerberos is mentionned here ... but may be a clue.

Last but not least,
this code works on my local machine, which is a windows one. Moreover, the CURLOPT_CERTINFO seams to be configured because i dont need to redefined it on my windows environnement.

Well, this is all I know for the moment. I can't figure where the problem come from. It's surely due to a problem of authentication between Debian and IIS but ... I dont understand more.

Do not hesitate if you need any other informations. Thank you for your help.

Answer 1

For those who need to authenticate anyway this link has helped me a lot!

Answer 2

For information we finally found a workaround to resolve the problem.

The problem was due to the fact the IIS Server needed an AD Login / Password to let our PHP application connect to the Web Service.

What we did was using an other url to reach the Web Service, an URL needing an "anonymous" account. It means the account is defined by the application itself and not the AD.

Consequently we don't need to use NTLM authentication, where the problem was coming from.