[isapros] Re: OT: Requiring client-side certs for RDP
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 13 Jul 2007 10:26:05 -0700
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.
Other related posts:
