After deeper inspection of exchanged packets from mstsc.exe (Windows 7 to
Windows Server 2008 R2), I think there won't be any easy "fix". The current
implementation follows the samba3 source + MS-NLMP. It does not use all
security features possible in NTLMv2 authentication, and it also sends both
LM and NTLM responses. Since it was reported that the rdesktop-nla patch
suffers from the same problem, I think it simply means that I need to spend
time implementing the extra security features which aren't a piece of cake.
If I could manage to get it working by looking at the spec and samba, I had
a lot of trouble figuring out what the algorithms really were since the
documentation is really vague, inconsistent and simply plain buggy. As a
matter of fact, I have identified another bug which I'll submit to
Microsoft.
On Sat, Feb 12, 2011 at 6:46 PM, Marc-André Moreau <
marcandre.mor...@gmail.com> wrote:
> I have taken wireshark captures from Windows 7 Ultimate to Windows Server
> 2008 R2, and I noticed two weird things:
>
> 1) the "mstshash=" cookie is truncated to 8 characters. When using a domain
> logon, mstsc.exe uses the first 8 characters of the domain name, not the
> username.
> 2) With both local and domain logon, mstsc.exe performs full
> authentication, disconnects, and re-authenticates. I never understood why
> exactly, since there appears to be no difference between the two
> authentications.
>
>
> On Sat, Feb 12, 2011 at 5:27 PM, Marc-André Moreau <
> marcandre.mor...@gmail.com> wrote:
>
>> I'm looking into the issue, I am wondering if the problem is not related
>> to this: http://support.microsoft.com/?id=942564
>>
>> <http://support.microsoft.com/?id=942564>One problem listed is samba
>> incompatibility. Since I had to look into samba3 source code during my work,
>> I guess that might explain why. Not all security features are used in the
>> current implementation, maybe those were enforced after some recent upgrade
>> on both Windows Server 2008 and Windows 7 Ultimate.
>>
>>
>> On Sat, Feb 12, 2011 at 1:57 AM, Vic Lee <ll...@163.com> wrote:
>>
>>> Hi Marc,
>>>
>>> OK, I have tested again have the following scenario:
>>>
>>> 1. Win7 Ultimate: Provide only username/password, no domain. I am in
>>> successfully. The user is actually a domain user, however it seems that the
>>> server knows to use a default domain if I omit it.
>>>
>>> 2. Win7 Ultimate: Provide username/password/domain. I got similar error
>>> as Jay. You can refer to Jay's logs.
>>>
>>> 3. Win2003: negotiation broken. I can connect only if I specify --no-tls.
>>> Previously freerdp will reconnect when getting "Error:
>>> SSL_NOT_ALLOWED_BY_SERVER", now it seems the reconnection also fails.
>>>
>>> Error: SSL_NOT_ALLOWED_BY_SERVER
>>> ui_error: ERROR: Connection closed
>>> ui_error: ERROR: send: Broken pipe
>>> ui_error: ERROR: Connection closed
>>> Protocol security negotiation failure, disconnecting
>>>
>>> run_xfreerdp: inst->rdp_connect failed
>>> main thread, all threads did exit
>>>
>>> Vic
>>>
>>>
>>> On 02/12/2011 01:52 PM, Marc-André Moreau wrote:
>>>
>>>> Hi Vic,
>>>>
>>>> On Sat, Feb 12, 2011 at 12:46 AM, Vic Lee <ll...@163.com
>>>> <mailto:ll...@163.com>> wrote:
>>>>
>>>> Hi Marc,
>>>>
>>>> This is the log. The computer I am testing is under domain, however
>>>> I not passing any domain or user to xfreerdp and I am supposed to
>>>> get the login screen.
>>>>
>>>>
>>>> Actually, no. With NLA, there should be no login screen. This older
>>>> behavior was vulnerable to denial of service attacks since a full login
>>>> screen (requires quite some resources) could be obtained without any
>>>> valid credentials. mstsc.exe can ask credentials "live" during the
>>>> connection attempt. However, xfreerdp being in X11, we do not really
>>>> have a nice graphical way of inputting the credentials. Maybe those
>>>> could be inputted live from the command line.
>>>>
>>>
>>>
>>>
>>
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
