RTC Forums

Subscription => Support => Topic started by: Andrew.W on June 14, 2017, 03:02:14 PM



Title: Using Windows Authentication with RTC clients
Post by: Andrew.W on June 14, 2017, 03:02:14 PM
Hi Daniel

Looking at the Microsoft documentation, both WinHttp and WinINet support Kerberos and NTLM authentication. Can I use this authentication with RTC? I looks like it's transparent to the calling application and should just work provided you initialise it.

What I'm trying to achieve is where access to a web resource depends on your domain credentials. The client and server will always be on the same domain. Server is IIS.

Will this work? Or do I need to influence how RTC works with these libraries.


Title: Re: Using Windows Authentication with RTC clients
Post by: D.Tkalcec (RTC) on June 14, 2017, 04:13:35 PM
The current WinInet and WinHTTP connection providers implemented in the RTC SDK (v8.11) only have built-in Proxy and SSL support. For more details, check the "rtcWInetHttpCliProv.pas" (WinInet) and "rtcWinHttpCliProv.pas" (WinHTTP) units in the "Lib" folder.

Best Regards,
Danijel Tkalcec


Title: Re: Using Windows Authentication with RTC clients
Post by: Andrew.W on June 14, 2017, 05:15:27 PM
Thanks Daniel

I found that making this change in TRtcWinHttpClientProvider.OpenConnection after the call to InternetConnect worked. After this, calls on Winhttp are authenticated using Windows.

Code:
var
.....
    myOption, theError:DWORD;
    lbResult: BOOL;
begin
----
    myOption := WINHTTP_AUTOLOGON_SECURITY_LEVEL_LOW;
    lbResult := InternetSetOption(hSession, WINHTTP_OPTION_AUTOLOGON_POLICY,
          Addr(myOption), sizeof(myOption));
    if not lbResult then
    begin
          theError := GetLastError();
          raise Exception.Create('Internal error : could not set security level: '+intToStr(theError));
    end;



Title: Re: Using Windows Authentication with RTC clients
Post by: D.Tkalcec (RTC) on June 14, 2017, 05:57:10 PM
Since the default security level for the WinHTTP API is medium, which should work for local and trusted domains, I'm curious if adding your domain to the proxy bypass list wouldn't also work, without the need to reduce the security level to LOW (default is MEDIUM).

See this topic:
http://microsoft.public.winhttp.narkive.com/btwPfktT/trusted-login-fails-in-winhttp

I could add a global variable for the security level, so you could change it to LOW for your Application (if that is what you really want), but I'm not sure that reducing the security level is the best way to solve this problem and I'm pretty sure that changing this will have unwanted effects in some other RTC-based Clients using the WinHTTP API if it became the "new default".

Best Regards,
Danijel Tkalcec


Title: Re: Using Windows Authentication with RTC clients
Post by: Andrew.W on June 14, 2017, 06:17:58 PM
I will keep looking at it. But it would not work unless set to low.

But right now I'm glad I have a working solution using RTC.


Title: Re: Using Windows Authentication with RTC clients
Post by: D.Tkalcec (RTC) on June 14, 2017, 07:15:48 PM
Ok, then ... I've released RTC SDK v8.12 now, adding "RTC_WINHTTP_AUTOLOGON_SECURITY_LEVEL" as a new global parameter/variable to the "rtcWinHttpCliProv" unit, allowing Clients using the WinHTTP API to change their Security Level to LOW (=1) or HIGH (=2) if needed. The defaul value is MEDIUM (=0), to keep this update backwards compatible with prior RTC SDK versions, where this global variable was NOT available.

Best Regards,
Danijel Tkalcec


Title: Re: Using Windows Authentication with RTC clients
Post by: Andrew.W on June 15, 2017, 11:24:55 AM
This is why we love RTC, thanks.

The issue with security levels is that WinHTTP looks at the proxy exceptions on your local internet config. If it sees your host there, it thinks the host on the Intranet (not Internet) and will authenticate if the security setting is medium.

But at the company where I am, this setting is never used. There are no bypassed servers, there is no proxy.

So at low the WinHTTP client will try to authenticate against everything. Firewall policies at this company are there to block traffic going outside the domain.