FreeRDP
FreeRDP copied to clipboard
FreeRDP
[Protected Users] Group Membership Support
Is your feature request related to a problem? Please describe. In an Active Directory domain, if an account is added to the "Protected Users" group, I am not able to connect to the machine (ERRCONNECT_ACCOUNT_RESTRICTION [0x00020017]).
Describe the solution you'd like I'd like to be able to use an account that is a member of the "Protected Users" group.
Describe alternatives you've considered I have not tried any alternatives, other than using a Windows VM
Additional context Additional information about the "Protected Users" group can be found here. Primarily, when an account is a member of this group, it cannot:
- Authenticate with NTLM authentication.
- Use DES or RC4 encryption types in Kerberos pre-authentication.
Example Output [12:05:25:027] [51640:07b4a000] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx [12:05:25:027] [51640:07b4a000] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr [12:05:25:029] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE [12:05:25:029] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE [12:05:25:029] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE [12:05:25:029] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE [12:05:25:029] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE [12:05:25:029] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE [12:05:25:029] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA [12:05:25:029] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - Attempting NLA security [12:05:26:034] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3 [12:05:26:038] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - RDP_NEG_RSP [12:05:26:038] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - selected_protocol: 2 [12:05:26:038] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL [12:05:26:039] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - Negotiated NLA security [12:05:26:039] [51640:07b4a000] [DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_NLA [12:05:35:026] [51640:07b4a000] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA [12:05:35:027] [51640:07b4a000] [DEBUG][com.freerdp.core.nla] - nla_client_init 348 : packageName=Negotiate ; cbMaxToken=12256 [12:05:35:027] [51640:07b4a000] [DEBUG][com.freerdp.core.nla] - Sending Authentication Token ... ... [12:05:35:028] [51640:07b4a000] [DEBUG][com.freerdp.core.nla] - CredSSP protocol support 6, peer supports 6 [12:05:35:029] [51640:07b4a000] [DEBUG][com.freerdp.core.nla] - Sending Authentication Token ... ... [12:05:36:035] [51640:07b4a000] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_ACCOUNT_RESTRICTION [0x00020017] [12:05:36:035] [51640:07b4a000] [ERROR][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_NLA - nla_recv_pdu() fail [12:05:36:035] [51640:07b4a000] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1 [12:05:36:035] [51640:07b4a000] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1
Breaks down to better kerberos implementation. Might require the machine to be a domain member too, so that might actually work with current kerberos support but no environment for testing atm
Hi there, any progress in the matter, it would be good if this feature is integrated soon.
Anybody who has interest in debugging and fixing kerberos is welcome to try, it is not top of my list though.
A customer of mine has made new accounts for those with admin rights. The new accounts are all members of the "Protected Users" group. I was unable to RDP from Fedora with freerdp-2.0.0-53.20190820git6015229.fc30.x86_64, but was able to connect using a Windows 10 client, that was not joined and not part of my customer's domain.
[15:13:24:472] [20347:20348] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr [15:13:24:472] [20347:20348] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd [15:13:24:472] [20347:20348] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr [15:13:24:659] [20347:20348] [WARN][com.freerdp.crypto] - Certificate verification failure 'unable to get local issuer certificate (20)' at stack position 0 [15:13:24:659] [20347:20348] [WARN][com.freerdp.crypto] - CN = SERVER.DOMAIN.EXAMPLE.COM Password: [15:13:31:096] [20347:20348] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_ACCOUNT_RESTRICTION [0x00020017] [15:13:31:096] [20347:20348] [ERROR][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_NLA - nla_recv_pdu() fail [15:13:31:096] [20347:20348] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
confirming this, too. The only way to connect to a server using an account in the "Protected Users" group currently seems to be using a Windows box/VM. This box doesn't have to be in any domain, it just has to be "any" Windows.
Would be very helpful to see this added to FreeRDP, otherwise it is not usable in a typical enterprise enviroment for high privileges access.
confirming this, too. The only way to connect to a server using an account in the "Protected Users" group currently seems to be using a Windows box/VM. This box doesn't have to be in any domain, it just has to be "any" Windows.
good workaround news @daudo, the Microsoft remote desktop app adds support for this in version 10.6.0!
@altrhombus @daudo how do you connect using the windows client?
Tried it with a setup and got the exact same error message from mstsc
@akallabeth In my case, it "just works" from the windows client, it keeps working even after the user is added to the "Protected Users" group. But I heard from a colleague that even from windows it caused some problems when people are using the IP to connect, but it works when using the correct dns name or fqdn.
But from Linux I'm blocked because of this issue. My current workaround is to login to a TSE server using a "normal" user, and then using the official client to connect the the required server using my "protected" user.
@Elektordi that is fine for you, but does not help in recreating a setup where I can test what is going on ;)
@akallabeth a wild guess; perhaps your user can't get an AES ticket and fails on windows due to use of rc4 enctype in kerberos, klist or wireshark would show it (often this gets resolved by resetting the user's password).
On the other hand, I can't reproduce the original issue as it works for me on linux as well, so it may be just due to usual kerberos failure such as bad config etc, see log:
$ client/X11/xfreerdp /u:admin /p:pwd /v:adc.acme.com /cert:ignore /log-level:debug
[02:11:22:134] [216841:216841] [DEBUG][com.freerdp.client.common] - This is 3.0.0-dev Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=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_STRNDUP=1 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_CAIRO=OFF WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=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=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=ON WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=ON WITH_FAAD2=ON WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_FUSE=OFF WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=ON WITH_GSSAPI=ON WITH_GSSAPI_MIT=ON WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=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_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PCSC=OFF WITH_PROFILER=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VAAPI=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_WAYLAND=OFF WITH_WINPR_TOOLS=ON 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: Release
CFLAGS: -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -fno-omit-frame-pointer -DWINPR_DLL
Compiler: GNU, 10.2.1
Target architecture: x64
[02:11:22:134] [216841:216842] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
[02:11:22:134] [216841:216842] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[02:11:22:134] [216841:216842] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[02:11:22:134] [216841:216842] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[02:11:22:134] [216841:216842] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[02:11:22:135] [216841:216842] [INFO][com.freerdp.client.x11] - Property 248 does not exist
[02:11:22:137] [216841:216842] [DEBUG][com.freerdp.primitives] - primitives benchmark result:
[02:11:22:291] [216841:216842] [DEBUG][com.freerdp.primitives] - * generic= 52
[02:11:22:443] [216841:216842] [DEBUG][com.freerdp.primitives] - * optimized= 105
[02:11:22:443] [216841:216842] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized
[02:11:22:445] [216841:216842] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[02:11:22:445] [216841:216842] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[02:11:22:445] [216841:216842] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[02:11:22:445] [216841:216842] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[02:11:22:445] [216841:216842] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[02:11:22:445] [216841:216842] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[02:11:22:445] [216841:216842] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[02:11:22:445] [216841:216842] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[02:11:22:445] [216841:216842] [INFO][com.freerdp.core] - freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state
[02:11:22:445] [216841:216842] [INFO][com.freerdp.core] - freerdp_tcp_default_connect:freerdp_set_last_error_ex resetting error state
[02:11:22:445] [216841:216842] [DEBUG][com.freerdp.core] - connecting to peer 192.168.122.200
[02:11:22:446] [216841:216842] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3
[02:11:22:451] [216841:216842] [DEBUG][com.freerdp.core.nego] - RDP_NEG_RSP
[02:11:22:451] [216841:216842] [DEBUG][com.freerdp.core.nego] - selected_protocol: 2
[02:11:22:451] [216841:216842] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL
[02:11:22:451] [216841:216842] [DEBUG][com.freerdp.core.nego] - Negotiated NLA security
[02:11:22:451] [216841:216842] [DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_HYBRID
[02:11:22:456] [216841:216842] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[02:11:22:456] [216841:216842] [DEBUG][com.freerdp.core.nla] - nla_client_init 416 : packageName=Kerberos ; cbMaxToken=48000
[02:11:22:456] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_import_name: SEC_E_OK (0x00000000)
[02:11:22:461] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_init_sec_context: STATUS_WAIT_1 (0x00000001)
[02:11:22:461] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_release_buffer: SEC_E_OK (0x00000000)
[02:11:22:461] [216841:216842] [DEBUG][com.freerdp.core.nla] - Client: Sending Authentication Token
[02:11:22:461] [216841:216842] [DEBUG][com.freerdp.core.nla] - NLA.negoToken (length = 1255):
[02:11:22:562] [216841:216842] [DEBUG][com.freerdp.core.nla] - CredSSP protocol support 6, peer supports 6
[02:11:22:562] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_init_sec_context: SEC_E_OK (0x00000000)
[02:11:22:562] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_acquire_cred: SEC_E_OK (0x00000000)
[02:11:22:562] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_release_buffer: SEC_E_OK (0x00000000)
[02:11:22:562] [216841:216842] [DEBUG][com.freerdp.core.nla] - Client: Sending Authentication Token
[02:11:22:563] [216841:216842] [DEBUG][com.freerdp.core.nla] - NLA.pubKeyAuth (length = 92):
[02:11:22:663] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_unwrap: SEC_E_OK (0x00000000)
[02:11:22:663] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_release_buffer: SEC_E_OK (0x00000000)
[02:11:22:663] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_acquire_cred: SEC_E_OK (0x00000000)
[02:11:22:663] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_release_buffer: SEC_E_OK (0x00000000)
[02:11:22:663] [216841:216842] [DEBUG][com.freerdp.core.nla] - Client: Sending PubKeyAuth Token
[02:11:22:663] [216841:216842] [DEBUG][com.freerdp.core.nla] - NLA.authInfo (length = 113):
[02:11:22:663] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_release_name: SEC_E_OK (0x00000000)
[02:11:22:663] [216841:216842] [DEBUG][com.winpr.sspi.gss] - gss_delete_sec_context: SEC_E_OK (0x00000000)
[02:11:22:764] [216841:216842] [DEBUG][com.freerdp.core.gcc] - Server rdp encryption method: NONE
[02:11:23:465] [216841:216842] [DEBUG][com.freerdp.core.info] - Client Info Packet Flags = INFO_MOUSE|INFO_DISABLECTRLALTDEL|INFO_UNICODE|INFO_MAXIMIZESHELL|INFO_LOGONNOTIFY|INFO_COMPRESSION|INFO_ENABLEWINDOWSKEY|INFO_FORCE_ENCRYPTED_CS_PDU|INFO_LOGONERRORS|INFO_MOUSE_HAS_WHEEL|INFO_NOAUDIOPLAYBACK
[02:11:23:466] [216841:216842] [DEBUG][com.winpr.timezone] - tz: Bias=-120 sn='Jerusalem Standard Time' dln='Jerusalem Daylight Time'
[02:11:23:666] [216841:216842] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x1f size=37 channelId=1008)
[02:11:23:666] [216841:216842] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x14 size=41 channelId=1008)
[02:11:23:666] [216841:216842] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x14 size=41 channelId=1008)
[02:11:23:666] [216841:216842] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x2b size=57 channelId=1008)
[02:11:23:666] [216841:216842] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x27 size=41 channelId=1008)
[02:11:23:666] [216841:216842] [DEBUG][com.freerdp.core.rdp] - recv Monitor Layout Data PDU (0x37), length: 42
[02:11:23:766] [216841:216842] [DEBUG][com.freerdp.core.rdp] - recv Synchronize Data PDU (0x1F), length: 22
[02:11:23:766] [216841:216842] [DEBUG][com.freerdp.core.rdp] - recv Control Data PDU (0x14), length: 26
[02:11:23:766] [216841:216842] [DEBUG][com.freerdp.core.rdp] - recv Control Data PDU (0x14), length: 26
[02:11:23:766] [216841:216842] [DEBUG][com.freerdp.core.rdp] - recv Font Map Data PDU (0x28), length: 26
[02:11:23:766] [216841:216842] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32
[02:11:23:766] [216841:216842] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_RGB16
[02:11:23:787] [216841:216842] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem
[02:11:23:787] [216841:216842] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd
[02:11:23:788] [216841:216842] [DEBUG][com.freerdp.core.heartbeat] - received Heartbeat PDU -> period=1, count1=8, count2=8
[02:11:24:264] [216841:216842] [DEBUG][com.freerdp.core.rdp] - recv Set Error Info Data PDU (0x2F), length: 22
[02:11:24:264] [216841:216842] [INFO][com.freerdp.core] - rdp_set_error_info:freerdp_set_last_error_ex resetting error state
[02:11:24:854] [216841:216842] [DEBUG][com.freerdp.core.rdp] - recv Save Session Info Data PDU (0x26), length: 620
[02:11:24:854] [216841:216842] [DEBUG][com.freerdp.core.info] - LogonInfoV2: SessionId: 0x00000003 UserName: [admin] Domain: [ACME]
[02:11:24:854] [216841:216842] [DEBUG][com.freerdp.core.heartbeat] - received Heartbeat PDU -> period=1, count1=8, count2=8
[02:11:25:058] [216841:216862] [DEBUG][com.freerdp.channels.cliprdr.client] - ServerCapabilities
[02:11:25:058] [216841:216862] [DEBUG][com.freerdp.channels.cliprdr.client] - MonitorReady
[02:11:25:058] [216841:216862] [DEBUG][com.freerdp.channels.cliprdr.client] - ClientCapabilities
[02:11:25:058] [216841:216862] [DEBUG][com.freerdp.channels.cliprdr.client] - ClientFormatList: numFormats: 12
[02:11:25:082] [216841:216862] [DEBUG][com.freerdp.channels.cliprdr.client] - ServerFormatListResponse
[02:11:25:817] [216841:216842] [INFO][com.freerdp.client.x11] - Closed from X11
[admin@localhost FreeRDP]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]
Valid starting Expires Service principal
05/13/2021 02:03:13 05/13/2021 06:03:13 krbtgt/[email protected]
renew until 05/13/2021 06:03:13, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
05/13/2021 02:03:13 05/13/2021 06:03:13 TERMSRV/adc.acme.com@
renew until 05/13/2021 06:03:13, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Ticket server: TERMSRV/[email protected]
So I tried with mstsc, it looks like if the workstation isn't joined to the domain, then it'll use NTLM and fail due to protected-users, but a joined machine would use kerberos indeed, however I noticed it uses U2U rather then regular gss-krb5 like the freerdp client does, although the latter works for me with protected-users too, as mentioned.
You can take a look at my captures, alongside my wip MR for wireshark to better dissect the gss-krb5 blobs in credssp, at: https://gitlab.com/wireshark/wireshark/-/merge_requests/3020
@iboukris mstsc also uses SPNEGO tokens and not a raw kerberos ticket as we do. Looking at wireshark's code the actual version + your patch will not be enough to decode U2U tokens.
More about mstsc behaviour:
- if it figures that will not be able to any kerberos with the host, then it goes with a raw NTLM token (starting with
NTLMSSP\x00bytes); - otherwise it sends a
SPNEGOtoken and the optimisticmechTokenwill contain some U2U byte (the TGT request), and further token exchanges will implement the U2U negotiation with MIC exchange and such.
At the end only freerdp and rdesktop uses raw Kerberos tickets, so when you do some server-side NLA, if the peer comes with a kerberos token instead of SPNEGO, then for sure the client software is one of these two.
Hi David,
Looking at wireshark's code the actual version + your patch will not be enough to decode U2U tokens.
Yeah, it only decodes the spnego layer so it shows the U2U OID as below, but I guess that's something to fix in the gssapi dissector, it does otherwise decode the ap-req and decrypts it when a keytab is provided.
GSS-API Generic Security Service Application Program Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
Simple Protected Negotiation
negTokenInit
mechTypes: 4 items
mechToken: 603e060a2a864886f712010202030400302ea003020105a103020110a2223020a0030201…
krb5_blob: 603e060a2a864886f712010202030400
KRB5 OID: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User)
krb5_tok_id: Unknown (0x0004)
I still wonder why U2U, my vague understanding is that sometimes the terminal service won't have access to the long term key, and only gets access to a tgt on behalf on the host on which it runs, in such case a regular ap-req won't do since the service can't decrypt tickets (encrypted with the long term key), so the client ask the tgt from the service, then asks the kdc for a ticket encrypted with that tgt's session key, and then it passes it to the service and authenticate. If that is the explanation, it may explain why in some scenarios regular kerberos (freerdp) won't work, while windows clients would work using U2U.
I also wonder what is the U2U support in SPNEGO in the gssapi libraries, if any (and where the doc is). IIRC MIT's kvno tool does a U2U request from the kdc, but that's about it, i'll take a closer look.
Well decoded first token would give something like that:
## GSSAPI Kerberos Token: (RAW DATA)
TokId: 0x400 (or 0x0004) ?
Token:
## Kerberos TGT Request: (ASN.1 Type: KERB-TGT-REQUEST)
pvno: 0x5
msg-type: 0x10
server-name:
name-type: 0x2
name-string: TERMSRV/<your server name>
AFAICT there's no U2U support in any of the open kerberos lib I know (mit, samba or heimdal).
You're probably right, U2U is used because it's convenient for servers that can't join the KDC.
Also found this on the matter: https://specifications486.rssing.com/chan-58023329/all_p2.html
Quote:
Deliberate Kerberos U2U from client: CredSSP in Remote Desktop Session
For Kerberos under CredSSP, the client chooses to do U2U on its own without
a prior error about U2U being required. The client initiates U2U because CredSSP
calls InitializeSecurityContext with the ISC_REQ_USE_SESSION_KEY flag.
That flag requires a new session key, which Kerberos honors by doing U2U.
...
CredSSP resorts to U2U mechanism because U2U service tickets are not cacheable.
When CredSSP uses U2U, it gets a unique session key to encrypt credentials and this
remains private to the process instance. Had that connection used Kerberos without U2U,
then the session key used to protect the credentials would have been available to any
process running as the user that shares the user’s ticket cache.
Arch and Debian (Bulleye) stock packages are build without GSSAPI support (WITH_GSSAPI=OFF ) . So even with proper Kerberos config and ticket I get the same kind of error with stock packages.
Trying to rebuild with GSSAPI=ON .
I'm on mac and I have the same problem with the RoyalTSX application. RoyalTSX uses a FreeRDP plugin to connect to RDP servers. The error does not occur with the "Microsoft Remote Desktop" application.
With the closure of #5746, should this issue be closed as well? Is support for Protected Users now available?
On release 2.10.0, the error is still present.
xfreerdp /u:[email protected] /p:xxxxxxxxxx /v:srv.domain.local
[10:04:01:842] [1353:0d958000] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0
[10:04:01:842] [1353:0d958000] [WARN][com.freerdp.crypto] - CN = srv.domain.local
[10:04:01:843] [1353:0d958000] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:16000069:STORE routines::unregistered scheme
[10:04:01:843] [1353:0d958000] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:80000002:system library::No such file or directory
[10:04:01:843] [1353:0d958000] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:16000069:STORE routines::unregistered scheme
[10:04:01:843] [1353:0d958000] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:80000002:system library::No such file or directory
[10:04:01:843] [1353:0d958000] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[10:04:01:334] [1353:0d958000] [WARN][com.freerdp.core.nla] - SPNEGO received NTSTATUS: STATUS_ACCOUNT_RESTRICTION [0xC000006E] from server
[10:04:01:334] [1353:0d958000] [ERROR][com.freerdp.core] - nla_recv_pdu:freerdp_set_last_error_ex ERRCONNECT_ACCOUNT_RESTRICTION [0x00020017]
[10:04:01:334] [1353:0d958000] [ERROR][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_NLA - nla_recv_pdu() fail
[10:04:01:334] [1353:0d958000] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
[10:04:01:334] [1353:0d958000] [ERROR][com.freerdp.core] - freerdp_post_connect failed
But if user is not a "Protected Users" member, no problem:
xfreerdp /u:[email protected] /p:xxxxxxxxxxxx /v:srv.domain.local
[10:04:50:365] [1363:06fce000] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0
[10:04:50:365] [1363:06fce000] [WARN][com.freerdp.crypto] - CN = srv.domain.local
[10:04:50:366] [1363:06fce000] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:16000069:STORE routines::unregistered scheme
[10:04:50:366] [1363:06fce000] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:80000002:system library::No such file or directory
[10:04:50:366] [1363:06fce000] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:16000069:STORE routines::unregistered scheme
[10:04:50:366] [1363:06fce000] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:80000002:system library::No such file or directory
[10:04:50:366] [1363:06fce000] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[10:04:52:491] [1363:06fce000] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32
[10:04:52:491] [1363:06fce000] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[10:04:52:518] [1363:06fce000] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd
[10:04:52:518] [1363:06fce000] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
Able to confirm this is working now, I don't know of any distro that builds with kerberos set on, i built my own version and tried to setup a repo of it for other people to test but I am not smart enough.
can see my built version "WITH_GSSAPI=ON" is key here
Here we can see my user is part of the group
I connected just fine, I suspect the user stating it is not working is simply not using a freerdp build with it turned on. This works flawlessly, the only part that does not is for machines that are not domain joined, windows can do this, by sending the credentials via CredSSP and then using kerberos on the server. But my understanding is that would be the U2U and there is no support in libraries for it.
Anyway this should be marked as closed now as it is fixed based on my own testing.
@BryannaM you might want to give our current development branch a shot, there have been lots enhancements regarding kerberos support there, specifically for systems that can not reach the KDC
Will take a look, I know the mode i am thinking of i guess it is not even kerberos from the client, it just sends the password via CredSSP to the server for a machine that is not domain joined on windows, I have had trouble finding documentation even about how that functions, i was going to try and do a wireshark capture showing the behavior but having some trouble figuring out how to use it and decrypt the traffic. I will try the new building and look for any other kerberos issues that are open that I can test if they are fixed now.