I thought TSG was RDP/HTTP Also, the advantage of using RDP/TLS is that a TLS session is established before credentials are sent. The author of the winsecurity.org article is well known for such gaffs. -----Original Message----- From: "Jim Harrison"<Jim@xxxxxxxxxxxx> Sent: 7/13/07 11:27:27 AM To: "isapros@xxxxxxxxxxxxx"<isapros@xxxxxxxxxxxxx> Subject: [isapros] Re: OT: Requiring client-side certs for RDP I just love it when "tribal knowledge" becomes "documented fact". It's clear from the "article" that the author never tested any of the configuration or application statements he makes. Even the dialog for his "attempt authentication" screenshot clearly states "Authentication will confirm the identity of the remote computer to which you connect" - NOT "Authentication will confirm the identity of the user/machine **from which you connect**". In theory you *could* require user cert auth, but I don't know if the TSG client will respond appropriately. Since TSG is "just" RPC/HTTP, it's rpcrt4.dll that handles the translation between RPC and HTTP and AFAIK, it only handles Basic and NTLM. Because TSG is RPC/HTTP, you can configure the /RPC vroot to require user certs and thus impose this requirement on your connecting clients to test this theory. Of course, if you also share this vroot with Exchange RPC/HTTP you'll break OL connections, since they can't handle cert auth. -----Original Message----- From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God) Sent: Friday, July 13, 2007 9:29 AM To: isapros@xxxxxxxxxxxxx Subject: [isapros] OT: Requiring client-side certs for RDP Greets: Windows Server 2003 SP1 allows one to configure server-authentication via certificate for RDP over TLS/SSL. The MSFT articles say things like "the client must trust the certificate" etc in their client-configuration notes, and other articles specify that you can control access to RDP by issuing self signed certs and controlling distribution. This presents the illusion that one can limit connections to RDP on a Win2k3 server via this method. See: http://support.microsoft.com/kb/895433 http://technet2.microsoft.com/windowsserver/en/Library/a92d8eb9-f53d-4e8 6-ac9b-29fd6146977b1033.mspx http://www.windowsecurity.com/articles/Secure-remote-desktop-connections -TLS-SSL-based-authentication.html Win2k3 Terminal Services allows one to require security levels, but only provides "server" authentication - it does not allow you to require a particular certification to be requested of the client (as IIS does). Snips from the windowsecurity article compound this perception: <snip> The threat becomes even bigger, when the server running Microsoft Windows Terminal Services is accessible from the Internet through an RDP connection on port 3389, even though you have an advanced firewall such as ISA Server in front of it. A scenario that is common especially for Microsoft Small Business Server users. The good news however, is that you can prevent these attacks. The solution is certificate based computer authentication. If the computer cannot authenticate itself by presenting a valid certificate to the terminal server it is trying to connect to, then the RDP connection will be dropped before the user has a chance to attempt to log on. </snip> This is simply untrue. The client does not "present a valid certificate" at all. It either trusts the server or not, and it is up to the client to make that decision. While RDP clients 6 and below only allow "No auth, attempt, or require" which do provide the expected behavior, updated or alternate clients (like Vista) allow you to connect anyway. This being said, does anyone know if the current longhorn/ts gateway features will actually allow enforcement of client certificates such a requiring client certs that are signed by particular authorities? Sorry for all the detail, but I wanted to avoid people saying "Sure, just require TLS for RDP". t All mail to and from this domain is GFI-scanned.