New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xfreerdp: can't connect to latest Windows10: ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED #4449

Closed
hendwolt opened this Issue Feb 18, 2018 · 62 comments

Comments

Projects
None yet
@hendwolt
Contributor

hendwolt commented Feb 18, 2018

I'm using the latest master version (c276005). 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 (c276005)
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

This comment has been minimized.

SemperFu commented Feb 19, 2018

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

This comment has been minimized.

Member

akallabeth commented Feb 19, 2018

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

This comment has been minimized.

Member

akallabeth commented Feb 19, 2018

@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

This comment has been minimized.

Contributor

hendwolt commented Feb 19, 2018

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

This comment has been minimized.

Member

akallabeth commented Feb 20, 2018

@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

This comment has been minimized.

Contributor

hendwolt commented Feb 20, 2018

@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

This comment has been minimized.

Member

akallabeth commented Feb 20, 2018

@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

This comment has been minimized.

Contributor

hendwolt commented Feb 20, 2018

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

@SemperFu

This comment has been minimized.

SemperFu commented Feb 21, 2018

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

This comment has been minimized.

Member

akallabeth commented Feb 22, 2018

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

This comment has been minimized.

Member

akallabeth commented Feb 22, 2018

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

@lemonmojo

This comment has been minimized.

lemonmojo commented Feb 22, 2018

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

This comment has been minimized.

Contributor

hendwolt commented Feb 24, 2018

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

This comment has been minimized.

brhahlen commented Feb 26, 2018

I encountered the same error in #4444

@brhahlen

This comment has been minimized.

brhahlen commented Feb 26, 2018

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

@perkerk

This comment has been minimized.

Contributor

perkerk commented Mar 9, 2018

@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

This comment has been minimized.

Contributor

hendwolt commented Mar 10, 2018

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

This comment has been minimized.

ZaneCEO commented Mar 13, 2018

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

This comment has been minimized.

brhahlen commented Mar 13, 2018

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:

[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

This comment has been minimized.

Contributor

perkerk commented Mar 13, 2018

@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 dochelp@microsoft.com they can probably tell you about it. They're very supportive of the whole RDP ecosystem

@perkerk

This comment has been minimized.

@lemonmojo

This comment has been minimized.

lemonmojo commented Mar 13, 2018

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

This comment has been minimized.

kovrom commented Mar 13, 2018

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

This comment has been minimized.

laigor commented Mar 14, 2018

Connection is established if you change the security to TLS

@bmiklautz bmiklautz added the blocker label Mar 14, 2018

@lemonmojo

This comment has been minimized.

lemonmojo commented Mar 14, 2018

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):

@AndyTapster

This comment has been minimized.

AndyTapster commented Mar 14, 2018

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

This comment has been minimized.

lemonmojo commented Mar 14, 2018

@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

This comment has been minimized.

Contributor

giox069 commented Mar 14, 2018

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

@weberhofer

This comment has been minimized.

Contributor

weberhofer commented Mar 15, 2018

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

@scaronni

This comment has been minimized.

scaronni commented Mar 15, 2018

Added to updates testing in Fedora.

@bmiklautz

This comment has been minimized.

Member

bmiklautz commented Mar 15, 2018

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

akallabeth added a commit to akallabeth/FreeRDP that referenced this issue Mar 16, 2018

fix nla: don't use server version
FreeRDP currently only supports CredSSP protocol version 3. However the
current implementation always sent back the version received by the
server indicating that this version was supported.
With recent windows updates applied the protocol changed and this approach
doesn't work anymore (see
https://msdn.microsoft.com/en-us/library/mt752485.aspx for protocol changes).

With this fix FreeRDP always sends version 3 as supported version.

Credit goes to @mfleisz.

Fixes FreeRDP#4449
@agibson2

This comment has been minimized.

agibson2 commented Mar 16, 2018

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

This comment has been minimized.

@adambirds

This comment has been minimized.

adambirds commented Mar 19, 2018

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

@norru

This comment has been minimized.

norru commented Mar 20, 2018

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

This comment has been minimized.

Member

akallabeth commented Mar 20, 2018

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

This comment has been minimized.

meoso commented Mar 20, 2018

+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 debian-backports@lists.debian.org

@norru

This comment has been minimized.

norru commented Mar 21, 2018

@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

This comment has been minimized.

Member

akallabeth commented Mar 21, 2018

@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

This comment has been minimized.

Enverex commented Mar 21, 2018

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.

@meoso

This comment has been minimized.

meoso commented Mar 21, 2018

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

This comment has been minimized.

mdunc commented Mar 22, 2018

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

@mitkof6

This comment has been minimized.

mitkof6 commented Mar 23, 2018

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

This comment has been minimized.

Member

akallabeth commented Mar 23, 2018

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

@RaysonChacko

This comment has been minimized.

RaysonChacko commented May 28, 2018

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

This comment has been minimized.

ZaneCEO commented May 28, 2018

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

seojangho added a commit to seojangho/setup that referenced this issue May 29, 2018

@rhwssi

This comment has been minimized.

rhwssi commented Jul 7, 2018

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

@MakoWish

This comment has been minimized.

MakoWish commented Sep 28, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment