Hi FreeRDP developers,
I have finally managed to get network level authentication to work for
domain logon. I thought it was broken because of higher domain controller
policies, but it turns out not to be the case. I did one stupid mistake, but
maybe it was combined with some other smaller errors at the same time, who
knows. You'll notice there is code for the enhanced security features that
will only be used if the "ntlmssp->ntlm_v2" flag is set. It's not working,
but it should be close. We can probably just leave it there until Microsoft
actually enforces a higher security level on its next version of Windows
Server. If Microsoft updates MS-NLMP with precisions on those obscure new
features of the protocol, there would probably not be much to fix in order
to make the enhanced security work.
Anyway, I did some polishing work regarding NLA as well. It's all on master
now, since I have started integrating my previous branches.
Here are the new command line options:
--no-rdp: disable Standard RDP encryption
--no-tls: disable TLS encryption
--no-nla: disable network level authentication
--sec: force protocol security (rdp, tls or nla)
These can be used to force a particular security to be used, or disable
certain security features.
I would need as much testers as possible for NLA. Last time, it took a week
before someone reported a failure case that would have been catastrophic if
it would have ever made it to a stable release.
I still have other issues to investigate regarding NLA:
Many users are unaware of the fact that with NLA, you do NOT get the
graphical login prompt, especially if you do not enter all credentials at
command line. I added some checks in xfreerdp to disable NLA if not enough
information is present. What would be the best approach to avoid confusion
with users that normally use the graphical login?
Passing the password on the command line is an obvious security problem:
awake@workstation:~/git/freerdp_integration> ps aux | grep xfreerdp
awake 13005 0.7 0.0 48240 3784 pts/1 Sl+ 22:39 0:00
/home/awake/git/freerdp_integration/X11/.libs/xfreerdp -u Administrator -p *
Password123!* -d AWAKECODING 192.168.1.150
awake 13049 0.0 0.0 7668 808 pts/3 S+ 22:39 0:00 grep
xfreerdp
In systems with multiple users, a simple "ps aux" can reveal the password in
plaintext. I've heard that the original password could be overwritten, but
this still has the drawback of not hiding the password length, and to still
reveal the password in plaintext in between the time the program is
launched and the time the program overwrites the password.
We can probably implement the feature of overwriting the original password,
but maybe we should implement some mechanism to dynamically prompt the
password in a secure manner. Any suggestions?
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
