I agree. That's why you can create a Web Publishing Rule to publish the TSG and require a user certificate. However, that will require that the client application understands how to use user certificates. For example, the Outlook client does not. I don't know if the TS client does. For non-TSG connections, inbound connections will still come over 3389 (or whatever port you want to use to accept RDP connections). TLS/SSL isn't a transport in this situation. Thomas W Shinder, M.D. Site: www.isaserver.org Blog: http://blogs.isaserver.org/shinder Book: http://tinyurl.com/3xqb7 MVP -- ISA Firewalls > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thor > (Hammer of God) > Sent: Friday, July 13, 2007 11:44 AM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: OT: Requiring client-side certs for RDP > > It is: TSD is RDP via HTTPS. > > The advantage is there, and in scenarios where one controls > servers and workstations, it is a good thing. However, given > the nature of RDP, there needs to be server-level enforcement > mechanisms in place to obviate anonymous attacks. > > There are ways to increase security, but server enforced > client certificates would be ideal. > > t > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros- > > bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder > > Sent: Friday, July 13, 2007 10:39 AM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: OT: Requiring client-side certs for RDP > > > > 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. > > > > > > > > >