Freerdp: xfreerdp: can't connect to latest Windows10: ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED

[hendwolt]

I'm using the latest master version (c27600528). When I try to connect to the latest Windows10 Insider Preview (17101), I get:
[08:44:28:330] [7640:7641] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F]
[08:44:28:330] [7640:7641] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

It does not matter if I use the hostname or the IP address.

cmdline:
xfreerdp /u: /f /v:windows10hw

I did a statically linked debug build for this:
xfreerdp /buildconfig
This is FreeRDP version 2.0.0-dev2 (c27600528)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=OFF WITH_DEBUG_ALL=ON WITH_DEBUG_CAPABILITIES=ON WITH_DEBUG_CERTIFICATE=ON WITH_DEBUG_CHANNELS=ON WITH_DEBUG_CLIPRDR=ON WITH_DEBUG_DVC=ON WITH_DEBUG_KBD=ON WITH_DEBUG_LICENSE=ON WITH_DEBUG_MUTEX=ON WITH_DEBUG_NEGO=ON WITH_DEBUG_NLA=ON WITH_DEBUG_NTLM=ON WITH_DEBUG_RAIL=ON WITH_DEBUG_RDP=ON WITH_DEBUG_RDPDR=ON WITH_DEBUG_RDPEI=ON WITH_DEBUG_REDIR=ON WITH_DEBUG_RFX=ON WITH_DEBUG_RINGBUFFER=ON WITH_DEBUG_SCARD=ON WITH_DEBUG_SND=ON WITH_DEBUG_SVC=ON WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=ON WITH_DEBUG_TIMEZONE=ON WITH_DEBUG_TRANSPORT=ON WITH_DEBUG_TSG=ON WITH_DEBUG_TSMF=ON WITH_DEBUG_WND=ON WITH_DEBUG_X11=ON WITH_DEBUG_X11_CLIPRDR=ON WITH_DEBUG_X11_LOCAL_MOVESIZE=ON WITH_DEBUG_XV=ON WITH_DIRECTFB=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FFMPEG=ON WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_0_10=OFF WITH_GSTREAMER_1_0=ON WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PCSC=OFF WITH_PROFILER=OFF WITH_PULSE=OFF WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_LEAK=OFF WITH_SANITIZE_LEAK_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SSE2=ON WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_WAYLAND=OFF WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XV=ON WITH_ZLIB=ON
Build type: Debug
CFLAGS: -march=i686 -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g
Compiler: GNU, 7.3.0
Target architecture: x86

The whole output:
[08:44:21:537] [7640:7641] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[08:44:21:540] [7640:7641] [INFO][com.freerdp.client.x11] - Property 505 does not exist
Password:
[08:44:28:310] [7640:7641] [INFO][com.winpr.sspi.NTLM] - VERSION ={
[08:44:28:310] [7640:7641] [INFO][com.winpr.sspi.NTLM] - ProductMajorVersion: 6
[08:44:28:310] [7640:7641] [INFO][com.winpr.sspi.NTLM] - ProductMinorVersion: 1
[08:44:28:310] [7640:7641] [INFO][com.winpr.sspi.NTLM] - ProductBuild: 7601
[08:44:28:310] [7640:7641] [INFO][com.winpr.sspi.NTLM] - Reserved: 0x000000
[08:44:28:310] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMRevisionCurrent: 0x0F
[08:44:28:316] [7640:7641] [INFO][com.winpr.sspi.NTLM] - negotiateFlags "0xE28A8235"
[08:44:28:316] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_56 (0),
[08:44:28:316] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_KEY_EXCH (1),
[08:44:28:317] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_128 (2),
[08:44:28:317] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_VERSION (6),
[08:44:28:317] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_TARGET_INFO (8),
[08:44:28:317] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_EXTENDED_SESSION_SECURITY (12),
[08:44:28:317] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_TARGET_TYPE_SERVER (14),
[08:44:28:318] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_ALWAYS_SIGN (16),
[08:44:28:318] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_NTLM (22),
[08:44:28:318] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_SEAL (26),
[08:44:28:318] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_SIGN (27),
[08:44:28:318] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_REQUEST_TARGET (29),
[08:44:28:319] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_UNICODE (31),
[08:44:28:319] [7640:7641] [INFO][com.winpr.sspi.NTLM] - VERSION ={
[08:44:28:319] [7640:7641] [INFO][com.winpr.sspi.NTLM] - ProductMajorVersion: 10
[08:44:28:319] [7640:7641] [INFO][com.winpr.sspi.NTLM] - ProductMinorVersion: 0
[08:44:28:319] [7640:7641] [INFO][com.winpr.sspi.NTLM] - ProductBuild: 17101
[08:44:28:319] [7640:7641] [INFO][com.winpr.sspi.NTLM] - Reserved: 0x000000
[08:44:28:319] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMRevisionCurrent: 0x0F
[08:44:28:319] [7640:7641] [INFO][com.winpr.sspi.NTLM] - AV_PAIRs =
[08:44:28:319] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvNbDomainName AvId: 2 AvLen: 22
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 57 00 49 00 4e 00 44 00 4f 00 57 00 53 00 31 00 W.I.N.D.O.W.S.1.
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0010 30 00 48 00 57 00 0.H.W.
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvNbComputerName AvId: 1 AvLen: 22
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 57 00 49 00 4e 00 44 00 4f 00 57 00 53 00 31 00 W.I.N.D.O.W.S.1.
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0010 30 00 48 00 57 00 0.H.W.
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvDnsDomainName AvId: 4 AvLen: 22
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 77 00 69 00 6e 00 64 00 6f 00 77 00 73 00 31 00 w.i.n.d.o.w.s.1.
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0010 30 00 68 00 77 00 0.h.w.
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvDnsComputerName AvId: 3 AvLen: 22
[08:44:28:320] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 77 00 69 00 6e 00 64 00 6f 00 77 00 73 00 31 00 w.i.n.d.o.w.s.1.
[08:44:28:321] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0010 30 00 68 00 77 00 0.h.w.
[08:44:28:321] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvTimestamp AvId: 7 AvLen: 8
[08:44:28:321] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 db 2a 40 4e 8c a8 d3 01 .@N....
[08:44:28:322] [7640:7641] [INFO][com.winpr.sspi.NTLM] - negotiateFlags "0xE288A235"
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_56 (0),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_KEY_EXCH (1),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_128 (2),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_VERSION (6),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_TARGET_INFO (8),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_EXTENDED_SESSION_SECURITY (12),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_ALWAYS_SIGN (16),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_WORKSTATION_SUPPLIED (18),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_NTLM (22),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_SEAL (26),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_SIGN (27),
[08:44:28:323] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_REQUEST_TARGET (29),
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMSSP_NEGOTIATE_UNICODE (31),
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - VERSION ={
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - ProductMajorVersion: 6
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - ProductMinorVersion: 1
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - ProductBuild: 7601
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - Reserved: 0x000000
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - NTLMRevisionCurrent: 0x0F
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - AV_PAIRs =
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvNbDomainName AvId: 2 AvLen: 22
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 57 00 49 00 4e 00 44 00 4f 00 57 00 53 00 31 00 W.I.N.D.O.W.S.1.
[08:44:28:324] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0010 30 00 48 00 57 00 0.H.W.
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvNbComputerName AvId: 1 AvLen: 22
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 57 00 49 00 4e 00 44 00 4f 00 57 00 53 00 31 00 W.I.N.D.O.W.S.1.
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0010 30 00 48 00 57 00 0.H.W.
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvDnsDomainName AvId: 4 AvLen: 22
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 77 00 69 00 6e 00 64 00 6f 00 77 00 73 00 31 00 w.i.n.d.o.w.s.1.
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0010 30 00 68 00 77 00 0.h.w.
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvDnsComputerName AvId: 3 AvLen: 22
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 77 00 69 00 6e 00 64 00 6f 00 77 00 73 00 31 00 w.i.n.d.o.w.s.1.
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0010 30 00 68 00 77 00 0.h.w.
[08:44:28:325] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvTimestamp AvId: 7 AvLen: 8
[08:44:28:326] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 db 2a 40 4e 8c a8 d3 01 .@N....
[08:44:28:326] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvFlags AvId: 6 AvLen: 4
[08:44:28:326] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 02 00 00 00 ....
[08:44:28:326] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvChannelBindings AvId: 10 AvLen: 16
[08:44:28:326] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[08:44:28:326] [7640:7641] [INFO][com.winpr.sspi.NTLM] - MsvAvTargetName AvId: 9 AvLen: 38
[08:44:28:326] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0000 54 00 45 00 52 00 4d 00 53 00 52 00 56 00 2f 00 T.E.R.M.S.R.V./.
[08:44:28:326] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0010 77 00 69 00 6e 00 64 00 6f 00 77 00 73 00 31 00 w.i.n.d.o.w.s.1.
[08:44:28:326] [7640:7641] [INFO][com.winpr.sspi.NTLM] - 0020 30 00 68 00 77 00 0.h.w.
[08:44:28:330] [7640:7641] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F]
[08:44:28:330] [7640:7641] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

Any ideas, what to do or how to investigate this further?
ATM I'm not sure, if I should blame freerdp or Microsoft.

[SemperFu]

I am getting the same issue, it used to work last week. I am on the insider build and I recently upgraded to 17101. It was working in 17093. Not sure if they changed anything though.

I can rdp to a windows server and then rdp to my windows 10 machine for a work around. But I get the following message regardless if the password works or not.

[02:38:27:117] [4414:4429] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F]
[02:38:27:117] [4414:4429] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

[akallabeth]

So this issue is related to insider preview only? As in you can connect with the same client to a 'normal' windows 10 but not the insider preview?

[akallabeth]

@hendwolt The OpenSSL version you link to would also be interesting for this case, as the error is set in an SSL error handler.

[hendwolt]

I have no 'normal' Windows10 for tests available, sorry.
openssl versions:
on Tumbleweed : 1.1.0g
on Leap 42.3 : 1.0.2j
On both clients I get this error. Both can successfully connect to Windows7 and Windows Server 2008R2.

[akallabeth]

@hendwolt Great, only have the normal windows 10 to test here (client running on debian stretch) and it works here, concluding that this is a new feature in the insider builds.
(the temporary deactivation of everything except /gfx was another one.)
Note: I'm using local user accounts here, are you in a domain?

[hendwolt]

@akallabeth I'm not in a domain, but I use a Microsoft account. In the network settings my Windows10 insider installation is in the workgroup "WORKGROUP".

[akallabeth]

@hendwolt Ok, so does it work with a local user account?
It smells like it has to do with some security settings, so this may give a lead.

[hendwolt]

@akallabeth No. With a local account I get the same error.

[SemperFu]

It doesn't matter what I use. You can use an incorrect username and password and you get the same error. So it is erroring out before authentication.

[akallabeth]

Did get access to a insider build of windows 10.
The issue can easily be reproduced, but the only thing I can tell for sure is that the error code mapping is broken.
The source of the issue is somewhere down in the SSL handshake which aborts for an unknown reason.

[akallabeth]

Created #4455 to change the error to a more generic one (as we lack information on what actually happened).

[lemonmojo]

I'm running into the same issue with Insider Build 17101.
Disabling the NLA requirement server-side, then connecting with TLS instead of NLA or RDP security works.

[hendwolt]

While testing #4455, I forced transport.c to tell me more details:

[13:54:33:966] [30270:30271] [ERROR][com.freerdp.core.transport] - SSL alert: [0x00004004, x00000250] type fatal [F] internal error [IE] in state SSL negotiation finished successfully [SSLOK ], rstate read header [RH]
[13:54:33:966] [30270:30271] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[13:54:33:966] [30270:30271] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
[13:54:33:967] [30270:30271] [ERROR][com.freerdp.core.transport] - SSL alert: [0x00004008, x00000100] type warning [W] close notify [CN] in state SSL negotiation finished successfully [SSLOK ], rstate read header [RH]

Maybe it helps ...

[brhahlen]

I encountered the same error in #4444

[brhahlen]

The work-around provided by @lemonmojo works for me as well.

[perkerk]

@brhahlen Export the contents of "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" of the registry on that system and post them here. It might be something a lot more complicated like incompatible cipher suites but the supported TLS and SSL protocols are a start

[hendwolt]

In my Windows10 (build 17115):
`Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001

`

[ZaneCEO]

I came here to report this same issue exactly. I'm on my Linux PC right now so I can post the exact Win10 build, but I'm on the latest from Insider Slow

[brhahlen]

I exported the keys with both NLA enabled and disabled, this is what I get for both:

NLA Enabled:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001

NLA Disabled:
```Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
```

[perkerk]

@brhahlen Those SCHANNEL settings describe what versions of TLS and SSL are enabled/disabled on the system. Your settings are pretty typical. I have a Windows 10 system I tested connecting to with wfreerdp using NLA, and verified that it worked. When I upgraded the RDP host to the latest Insider Fast build (17115) and tried again, wfreerdp failed with the same alert you're seeing. So it's reproducible with connecting from Windows as well

Also, I have a different client that uses entirely different NTLM code, and it was able to connect with NLA to both the old Windows 10 and the 17115, so it sounds like there's something in the fields or NTLM flags of the NTLM packets from FreeRDP that either OpenSSL or the RDP host doesn't like.

I don't have more time this week to spend on this, but if you're already building the client it shouldn't be too much more trouble to build OpenSSL as well and just step into where that error is being set, that would either be a big clue or outright explain what's happening.

@akallabeth There's a CVE for CredSSP coming down the pipe, maybe it's already in the Insider releases and causing the problem? If you email [email protected] they can probably tell you about it. They're very supportive of the whole RDP ecosystem

[perkerk]

https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886
Doc change:
https://msdn.microsoft.com/en-us/library/mt752485.aspx
For additional assistance as it relates to your implementation, e-mail DocHelp

[lemonmojo]

Unfortunately this has already been released by Microsoft in today's patches and customer complaints about being unable to connect already start pouring in.

@akallabeth Any news about the source of the problem or a potential fix?

[kovrom]

Looks like update KB4088776 is the one to blame. By changing it to the Absent state (uninstalling the update) the system is reachable again.
Connecting from Linux box.
xfreerdp /version output: This is FreeRDP version 2.0.0-dev2 (n/a)
Linux Kernel: 4.15.7
OpenSSL version: OpenSSL 1.1.0g-fips 2 Nov 2017
Connecting to Windows 10 Pro x64. Version: 1709. Build: 16299.248
More about the KB4088776: https://support.microsoft.com/en-us/help/4088776/windows-10-update-kb4088776

[laigor]

Connection is established if you change the security to TLS

[lemonmojo]

FYI: I've now updated my test environment and can confirm that the issue is present on the following Windows versions (when updated with the March 13, 2018 patches):

• Windows 10 (KB4088776)
• Windows Server 2016 (KB4088787)
• Windows 8.1 (KB4088876)
• Windows Server 2012 R2 (KB4088876)
• Windows 7 SP1 (KB4088875)
• Windows Server 2008 R2 SP1 (KB4088875)

[AndyTapster]

Contradicting Iaigor's comment from a while ago, using TLS does NOT work for me. Only possible to connect using NLA

Ubuntu 17.10 as host, Windows 10 Pro as remote (updated yesterday).

[lemonmojo]

@AndyTapster You need to disable the NLA requirement on the server. Here's how to:

• Connect to the remote host using Microsoft Remote Desktop
• Run "SystemPropertiesRemote.exe" (or manually open "System Properties – Remote")
• Disable "Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)"

[giox069]

None of TLS or NLA works for me:

giovanni@giovanni:~/remmina_devel/FreeRDP$ xfreerdp /v:xxxx:21077 /u:giovanni /d:yy /sec:tls
[11:46:15:146] [5760:5761] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[11:46:15:755] [5760:5761] [WARN][com.freerdp.core.nego] - Error: HYBRID_REQUIRED_BY_SERVER
[11:46:15:755] [5760:5761] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[11:46:15:755] [5760:5761] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]
[11:46:15:755] [5760:5761] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

giovanni@giovanni:~/remmina_devel/FreeRDP$ xfreerdp /v:xxxxx:21077 /u:giovanni /d:yyy /sec:nla
[11:46:38:674] [5929:5930] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
Password: 
[11:46:42:022] [5929:5930] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F]
[11:46:42:022] [5929:5930] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

[lemonmojo]

@giox069 Did you disable the NLA requirement server-side like mentioned in my previous post?

[AndyTapster]

@lemonmojo As per my post, NLA works for me. And I've just checked the NLA setting, and it is the default (On)

[giox069]

@lemonmojo thanks for the hint. Your post appeared just after I sent my one. Yes, if I disable "force NLA" at the server side and then connect with /sec:tls, it works. But, as many other Remmina users, I have hundreds of server profiles placed in 6-7 domains to manage, and it's quite unfeasible and insecure to remove NLA from all of them. The only thing we can do is to delay the updates or switch to another RDP client while waiting for the fix.

[lemonmojo]

@giox069 Totally agree! A proper fix is needed ASAP. I'm only a consumer of the FreeRDP project as well and my customers are severely impacted by this.

Hope the core FreeRDP team soon finds the source of the problem and can provide a fix.

[giox069]

Does anyone know if this problem also affects older versions of freerdp (i.e: 1.1 of stock Ubuntu 16.04, debian 7/8)? Hi have dozens of xfreerdp 1.1.0 thinclients with that version installed which connects to 2008R2 and 2012(R2) servers.

[giox069]

Update on older versions: it seems that older xfreerdp 1.X versions are not affected by the problem. I tested Ubuntu 14.0 (xfreerdp 1.0.2) and Ubuntu 17.10 (xfreerdp 1.1.0~git20140921) and I can connect to my updated Windows 10.

[Enverex]

Thought it may be worth adding this: We have roughly 40 machines (all identical clones) connecting with this. Oddly enough ~5 of them still worked, the others all needed xfreerdp set to use /sec:tls and the force NLM option disabling on the VM itself. Can't see anything special about those 5 that allowed them continue to work.

[bmiklautz]

We've identified the problem. A PR with a fix will be available in a moment.

[bmiklautz]

PR #4487. The fix is available on my branch https://github.com/bmiklautz/FreeRDP/tree/KB4088776 if anyone could also verify that this fixes the issue.

[der-eismann]

Can confirm it's working on Solus, I will push it to the repo as soon as the PR is merged. Thanks @bmiklautz!

[lemonmojo]

@bmiklautz I can confirm this is working too! Awesome work! Thx a lot!

[argonym]

Fixed connections to Server2008R2 ~and Server2016~ (tbc) that have KB4088776 installed for me as well.

[AndyTapster]

Confirmed working on Fedora 27 x64 against an affected Win10 Pro.

[weberhofer]

Thanks a lot for that patch! Have tested it and will back-port it for openSUSE today.

[scaronni]

Added to updates testing in Fedora.

[bmiklautz]

@weberhofer @scaronni thanks.
We also managed to get the fix do Debian (and Ubuntu hopefully) where freerdp2 is available.

[agibson2]

Still broken on hubbitus/remmina-next RPM repo for CentOS 7.

https://copr-be.cloud.fedoraproject.org/results/hubbitus/remmina-next/epel-7-x86_64/

Anyone know how to contact the maintainer of that? I patched the SRC rpm in that repo myself and recompiled so I am up and running but I assume others are using it too.

EDIT: I sent an email to the maintainer with the patch and the change to the src RPM spec that I used to fix it. Hopefully he still has time to maintain the repo.

[michaelblyons]

https://copr.fedorainfracloud.org/coprs/hubbitus/remmina-next/ Bottom right corner?
https://github.com/Hubbitus

[adambirds]

@agibson2 any chance you can post the steps you used to fix it on CentOS?

[norru]

Also broken on Ubuntu 17.10 since the last Win10 corporate-wide mandatory updates. Found out this morning.

EDIT: getting latest from the official Remmina PPA fixed the issue for my installation, as documented here:

https://github.com/FreeRDP/Remmina/wiki

[akallabeth]

Please do not post in which distro it is broken here, but at the issue trackers of those distributions.
We only can help with nightly packages (and to some extent debian)

[meoso]

+1
Debian 9 + Stretch-backports (Linux 4.14.0-0.bpo.3-amd64 #1 SMP Debian 4.14.13-1~bpo9+1 (2018-01-14) x86_64 GNU/Linux)
Windows 10 Pro + KB4088782
Can't remove Require NLA due to Domain.

Posted update-request to [email protected]

[norru]

@akallabeth It makes sense for people having the problem to know how common this is, and how to work this around if possible. This ticket comes up as one of the top Google answers when searching for the error message.

[akallabeth]

@norru No issue with that, just thought it might be better to link to the people responsible to get that resolved for the specific distro/OS.
So, a post with a link to distro specific issue might actually help instead of just saying it does not work ;)

[Enverex]

It'll be broken for any (and all) distros that haven't updated their packages yet. It's in their hands now, nothing upstream can do about it.

[mfvescovi]

FYI, https://tracker.debian.org/news/941834/accepted-freerdp2-200git2017072511648debdfsg1-7bpo91-source-into-stretch-backports/

[meoso]

is the fix in master, or another branch? not sure what i'm missing, i compiled master and still get the error.

./client/X11/xfreerdp /u:USER /d:DOM /v:SERVER
Password: 
[08:22:54:555] [20406:20407] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F]
[08:22:54:555] [20406:20407] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

[mdunc]

@meoso, it seems to be broken again in current master. Check out f8baeb7 instead.

[mitkof6]

Thanks. I was able to connect from Arch Linux to Windows 10.

I have disabled (on Windows): "Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)"

and used TLS security protocol.

[akallabeth]

For anyone still posting in this issue, we moved discussion to #4502 (as a regression) and the fix for that is in #4510

[RaysonChacko]

Hi Github team,
We have a terminal server and thinclients which uses ubuntu 14.0 connect to this terminal server using xfreerdp version 1.0.2 but after credssp latest update we are unable to get rdp sessions. our client is not feel secure to uncheck NLA authentication. is there any method to get rdp with current settings? i'm not a linux expert please guide me with detailed steps.

[ZaneCEO]

@RaysonChacko : just update to the latest version of xfreerdp. It's fixed now.

[rhwssi]

I just cloned from Git and I'm encountering this problem still.

[MakoWish]

I have been posting to #4801 until I just found this. I will now be monitoring this thread for updates, but also chiming in with a "me too".

How is this issue closed when it is still a problem?

[MagicFab]

@MakoWish,

For anyone still posting in this issue, we moved discussion to #4502 (as a regression) and the fix for that is in #4510

[internetidal]

I ran into the same issue. Tried disable NLA and enable sec:rdp with no luck. Problem was with the registry key. Resolved by doing the below on win 10 target m/c
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
change REG_DWORD SecurityLayer from 2 to 1

xfreerdp /cert-ignore +clipboard /bpp:15 /compression /sec:rdp /f /d:DOMAIN /v:HOSTNAME /u:testuser /p:**