Bug 322827 - Connect to Win7/2008 fails in 4.10.5
Summary: Connect to Win7/2008 fails in 4.10.5
Status: RESOLVED WORKSFORME
Alias: None
Product: krdc
Classification: Applications
Component: RDP (other bugs)
Version First Reported In: 4.10.5
Platform: Fedora RPMs Linux
: NOR major
Target Milestone: ---
Assignee: Urs Wolfer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-25 20:21 UTC by Kyle Kinkaid
Modified: 2013-08-11 14:02 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle Kinkaid 2013-07-25 20:21:48 UTC
After an upgrade to the latest KRDC version available from Fedora KDE Spin, 4.10.5, I can no longer connect to systems which are Windows 7 or Windows 2008.  I upgraded from Fedora 18 to Fedora 19, which moved KRDC from 4.10.4 to 4.10.5.  Now I can connect to Windows XP and Windows 2003 systems without issue, but all connections to Windows 7 or Windows 2008 fail.

Reproducible: Always

Steps to Reproduce:
1.Open KRDC and input a hostname/IP for a Windows 7 system
2.Click Connect
3.Watch it not connect.
Actual Results:  
After prompting for details (screen resolution etc), it will sit there as if the system is offline, while the system is known to be online.  Connections from a Windows client succeed normally.  

Expected Results:  
The connection should complete as it did prior to the upgrade to 4.10.5.



I ran debugging information using kdebugdialog and found the following output which might narrow down the problem.  

krdc(4858)/krdc (RDP backend) RdpView::receivedStandardOutput: receivedStandardOutput: "loading plugd
loading plugin rdpdr
connected to 130.118.17.182:3389
SSL_read: Failure in SSL library (protocol error?)
Authentication failure, check credentials.
If credentials are valid, the NTLMSSP implementation may be to blame.
"

In response to this, I looked for ways of stopping NTLM autonegotiation (thinking that might be the problem).  The only similar option I found was "Automatically recognize LDAP-logins and share passwords".  Unchecking that had no effect.
Comment 1 Urs Wolfer 2013-07-28 09:21:04 UTC
Please try to connect to the same server with rdesktop from a terminal. KRDC RDP support is based on rdesktop.

Starting from KDE SC 4.11, RDP support is based on freerdp. You might want to test that as well.

If you cannot connect with these tools, please report issues against them. I cannot fix in KRDC such issues.
Comment 2 Kyle Kinkaid 2013-07-29 21:05:38 UTC
Thanks for the suggestions.

I've done some investigating and both rdesktop and xfreerdp work fine when I tried with just the destination hostname and username.

To test further, I enabled debugging again tried to connect.  When I did so, I noticed two things of interest, first, that KRDC reported using xfreerpd already,  and, second, there were many flags and command line options being applied.  Here's the debugging output:

krdc(35436)/krdc (RDP backend) RdpView::start: Starting xfreerdp with arguments: ("-g", "1280x1024", "-k", "en-us", "-u", "domain\username", "-D", "-X", "115343912", "-a", "24", "--plugin", "rdpsnd", "--plugin", "rdpdr", "--data", "disk:media:/media", "--", "-x", "l", "--rfx", "--ignore-certificate", "130.118.17.155:3389")

To test further, I ran xfreerdp with all those arguments.  It originally gives the error I described above:

SSL_read: Failure in SSL library (protocol error?)
Authentication failure, check credentials.
If credentials are valid, the NTLMSSP implementation may be to blame.

and I got around that by removing the "domain" (Microsoft Active Directory Domain) from the username field, so it was just my username with no backslash or domain (escaping the backslash didn't help).  The next message I got was this:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  7 (X_ReparentWindow)
  Resource id in failed request:  0x6e00228
  Serial number of failed request:  35
  Current serial number in output stream:  37

which was from the -X argument (0x6e00228 hex = 115343912 decimal). So I removed that and it worked fine.

I had saved the various connections I made with the domain as part of the username but it appears that in xfreerdp this is not necessary as I can log in perfectly fine without it.  I will go about removing that where I had it.

I'm not sure what the -X flag does but it seems to be causing trouble for KRDC/xfreerdp.  I would suggest removing it.

Let me know if you need any more information.
Comment 3 Urs Wolfer 2013-07-31 18:33:44 UTC
If your KRDC is using xfreerdp, you are using KRDC from KDE SC 4.11.

-X is used to embed FreeRDP into KRDC. If you are using FreeRDP from a terminal, you need to leave it away.

So you are saying, that if you remove the domain from your username, it works well? Can't you just leave the domain away in KRDC as well? I think you have entered the domain in KRDC by youself, don't you?
Comment 4 Kyle Kinkaid 2013-08-06 16:55:07 UTC
I tested removing the domain previously but didn't have any success.  Your question spurred me to perform further testing and I found a method that works.  I have to recreate the connections since the username is stored in KWallet.  But in short, it works.

When KRDC used rdesktop I needed to specify the domain because otherwise it would try to login locally and not to the domain (which would fail).  But with xfreerdp it doesn't try local login and always tries the (default) domain on the system which makes adding in the domain to the username both redundant and breaks things.

Thank you for your help.  I will mark this RESOLVED.

Feature request: Can we add a field to specify the domain?  This would be helpful for increasing login options.
Comment 5 Christoph Feck 2013-08-11 14:02:04 UTC
Kyle, please report the feature request separately.