Just a clarification on how protocol security negotiation works:
The client sends a packet advertising supported protocol security. This can
be Standard RDP, TLS, or TLS + NLA.
If the server is old and doesn't know about TLS, or TLS + NLA, and the
client advertised support for one of those, it will disconnect the client
immediately. In this case, both mstsc.exe and FreeRDP will reconnect
advertising support for Standard RDP only, which should result in successful
protocol security negotiation. This is the behavior I have observed in
wireshark with mstsc.exe, and I have implemented the negotiation to work the
same in FreeRDP.
FreeRDP supports both Standard RDP and TLS, but does not support NLA. It
will advertise support for both Standard RDP + TLS on first connection
attempt. If the server requires NLA, then it will be disconnected. FreeRDP
would then try again advertising Standard RDP support only, but that may
fail as well if NLA is configured to be mandatory on the server.
On Thu, Dec 2, 2010 at 8:29 PM, Mads Kiilerich <m...@kiilerich.com> wrote:
> Olivier Dumon wrote, On 12/03/2010 12:45 AM:
>
> Hello,
>>
>> I agree with you, it doesn't work with me. I didn't say anything else !
>> I can connect directly to any of the farm servers with freerdp (-0 option)
>> and with mstsc (/admin option)
>>
>
> Can you connect to any of the machines with freerdp? If it never works, not
> even in a farm with only one machine, then we know that it isn't an issue
> with the farm/redirect functionality but ... something else.
>
> I got a private mail (!?) with a hint that the problem is in licensing
> model per-device versus per-user. Can you investigate that? Console/admin
> connections avoids licensing issues.
>
>
> Again, i have no problem to connect to the farm with a windows mstsc
>> client.
>> In attachment, you can find a connection of a mstsc client to the Windows
>> 2008 R2 servers farm.
>>
>> The client IP is 10.100.30.224
>> The first remote desktop server IP is 10.100.30.228
>> The second one is 10.100.30.226
>>
>
> Thanks. The trace shows that the servers offers/requests CredSSP security
> protocol (
> http://msdn.microsoft.com/en-us/library/cc240806%28v=PROT.10%29.aspx)
> which I don't think FreeRDP support. (A recent rdesktop patch might however
> inspire us to how it can be implemented.)
>
> Connecting with FreeRDP should however fall back to another supported
> protocol.
>
> I don't know how CredSSP influences the communication, but it surprises me
> that in both cases the first connection is closed by the client after
> several package exchanges, and then it reconnects - this time successfully.
> The actual communication is encrypted, so I don't know how the conversation
> goes.
>
>
> Can we get the output from a connection attempt with xfreerdp compiled with
> --with-debug ? (--no-tls as before is fine for a starter.) A wireshark trace
> of the same connection attempt might be handy too and answer unexpected
> questions.
>
>
> Is it possible to configure mstsc to use the "old" RDP security protocol
> and neither TLS nor CredSSP? That would be more similar to what xfreerdp
> does, so a trace of that might reveal something interesting.
>
>
> I and others have tested that connecting and redirecting works with 2008 R2
> farm. There are probably lots of bugs left that we will fix when they are
> found, but it is probably also possible to work around the issues.
>
>
> /Mads
>
>
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
