We used BIG IP APM 11.6.1 HF2 and we configure APM with RDG to centralize rdp access.
It's work good with a lot of differents versions of Windows (7, 8, 8.1, 10 "1607") but not with the last version of Windows 10 (1703) named creators update.
Apparently, Microsoft decide to change authentification in rdp client (mstsc.exe or activex rdp).
Now, rdp client force to used Kerberos authentification but RDG doesn't support it.
I don't find any solution to force rdp client to modify default authentification and enable NTLM auth.
But apparently, with RDP client and when I try to connect to the Remote Desktop Gateway, it's not the process mstsc it's connect to RDG but it's LSASS with try to Kerberos authentification.
Like it's explain in this article :
For example, this is a connexion from Windows 8.1 :
Authorization: NTLM xxxxxxxxxxxxxxxxxxxxxxxxxxx==
This is a connexion from Windows 10 creators update (1703) :
First connect to KDC Proxy :
And after to RDG but with auth scheme Negotiate and not NTLM :
Authorization: Negotiate xxxxxxxxxxxxxxxxxxxxxxxxxxx==
Anybody have an idea to do something with configuration of APM or irule to try to accept Kerberos authentification receive by rdp client ?
It's need to used the workaround in my computer to correct this problem.
For now the workaround is to replace one dll and one exe with the older version like explained in another thread:
You can replace the mstsc.exe and mstscax.dll library located in %windir%\SysWOW64\ with the "backup" file in "Windows.old\WINDOWS\SysWOW64" and in %windir%\System32\ with the "backup" file in "Windows.old\WINDOWS\System32".
You will need to take ownership of the file and give Administrators Full control access to be able to replace it. Please backup the file you are replacing
It seems that ver. 13 solves the problem. At least it did in our case.
I installed version 13, still same issue. Any one has have more details?
I agree with you, v13 doesn't solved anything for this with HF2 or not.
In my opinion, this is a new behavior implemented by Microsoft and they did not communicate on it.
I think F5 does not necessarily inform about this change.
If you want to follow the exchanges with the forum partner Microsoft, here is the post:
Windows 10 1703 - unable to connect via Remote Desktop Gateway - Force to use Kerberos for authentication
It's need to open a case in F5, but we have no time to this for the moment, so I used workaround.
Is this still an issue?
We are looking to do this since Citrix doesn't want to support 1703 for VDA so we were going to move to the F5.
no luck yet, might have to setup manually vs iApp.
We got it working again after upgrading to v13 by using the new feature native RDP.
Could you please clarify what do you mean by "new feature native RDP".
We are trying to configure this with 12.1.1 HF1 / 12.1.2 HF1 and 13.0.0 HF2 but nothings works.
The first request is as follows:
POST /KdcProxy HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache User-Agent: kerberos/1.0 Content-Length: 255 Host: our.domain.tld
from the release notes: https://support.f5.com/kb/en-us/products/big-ip_apm/releasenotes/product/relnote-apm-13-0-0.html
it might be this
Launch native RDP client from APM webtop without F5 client component code
RDP resources can now be configured to launch native RDP clients on Windows or Mac OS X. Previously, F5 client component code (ActiveX control or Java applet) was required on the user's desktop. This feature addresses recent changes in some browsers such as Firefox and Chrome or Microsoft Edge to drop support for Java and Active-X plug-ins.
dont have version 13 around to have a look.
Any news on this?
Does somebody know of any information better than this? https://partnersupport.microsoft.com/en-us/par_clientsol/forum/par_win/windows-10-1703-unable-to-connect-via-remote/1e9cec01-38d2-44ab-95ab-b1128964ccf4?tm=1492175212211&auth=1&rtAction=1492467708123.
several people report v13 with native client working for them, have you tried that?
so I'm assuming most people better at searching than me have found this, but I stumbled upon this article from JANUARY!!!
Has the uber simple fix, plainly listed.
Hopefully this can help someone more attentive than me.
I found this about 10 minutes after I took the time to finally write a simple script to replace the files for me, here again if anyone wants...
takeown /f C:\Windows\system32\mstsc.exe
takeown /f C:\Windows\syswow64\mstsc.exe
takeown /f C:\Windows\system32\mstscax.dll
takeown /f C:\Windows\syswow64\mstscax.dll
icacls C:\Windows\system32\mstsc.exe /grant users:f
icacls C:\Windows\syswow64\mstsc.exe /grant users:f
icacls C:\Windows\system32\mstscax.dll /grant users:f
icacls C:\Windows\syswow64\mstscax.dll /grant users:f
ren c:\Windows\system32\mstsc.exe mstsc.%date:~4,2%%date:~7,2%%date:~10,4%.exe
ren c:\Windows\system32\mstscax.dll mstscax.%date:~4,2%%date:~7,2%%date:~10,4%.dll
ren c:\Windows\syswow64\mstsc.exe mstsc.%date:~4,2%%date:~7,2%%date:~10,4%.exe
ren c:\Windows\syswow64\mstscax.dll mstscax.%date:~4,2%%date:~7,2%%date:~10,4%.dll
copy mstsc*.* C:\windows\system32
copy mstsc*.* C:\windows\syswow64