[isapros] Re: OT: Requiring client-side certs for RDP
- From: "Steve Moffat" <steve@xxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 13 Jul 2007 17:04:02 -0300
Well boy...:)
It's the default on my Vista 64 box and on a spare XP box.
S
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jim Harrison
Sent: Friday, July 13, 2007 5:00 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: OT: Requiring client-side certs for RDP
That's not the default.
If you see this, then somewhere along the line it was changed.
Literally every v6 client I've used (v5 doesn't "do" SSL) provides a
cert validation warning.
No, you can't take that answer - I don't know if this will be supported,
but it's easily discovered.
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thor (Hammer of God)
Sent: Friday, July 13, 2007 12:51 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: OT: Requiring client-side certs for RDP
Nope. No acknowledgment needed at all if you just tell it "Always
connect even if authentication fails" (which it the default for the
updated RDP client). No muss, no fuss, silent connection to an
untrusted, unmatched, un-anything server.
This is why the articles are wrong and need changing. And this is why,
if you want to be able to limit the connection on the server side, the
server should have a mechanism to accept a client-side certificate.
I take it the answer is "no," Longhorn terminal services will not
address this come production...
t
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: Friday, July 13, 2007 12:36 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: OT: Requiring client-side certs for RDP
>
> It's true that the client *can* connect, but not until the user has
> acknowledged the popups that are produced whtn the cert isn't trusted,
> fails to match the connection, etc. This is my point.
> In fact, anyone programming against the TS COM will have to make sure
> they handle this event properly.
>
> Correct - TSG is not "TS Server using SSL" - that's RDP over SSL (no
> HTTP involved).
> TSG OTOH, is RPC/HTTP - you'll have to web-publish it to see the URLs
> used, but when you do, the /rpc/rpcproxy.dll?<servername>:3388 request
> will clarify this for ya.
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx]
> On Behalf Of Thor (Hammer of God)
> Sent: Friday, July 13, 2007 12:04 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: OT: Requiring client-side certs for RDP
>
> Actually, yes, it is *completely* wrong. But let's make sure we're
not
> letting you launch one of your famous misdirection threads ;)
>
> I'm not talking about TSG (Terminal Services Gateway). I'm talking
> about Win2k3 Terminal Services configured to require TLS/SSL: The
> client
> does *not* have to trust the CA at all - it does not have to trust the
> cert, the ca, or the entire chain for that matter, even though the
> articles say it must. It doesn't. The client can connect anyway...
> That's what is wrong with the articles.
>
> I'm asking if Longhorn terminal services will fix this natively.
Tom's
> point about using ISA's SSL Client Certificate Authorization for this
> is
> a great suggestion for TSG, but that is a different animal.
>
> t
>
>
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > Sent: Friday, July 13, 2007 11:31 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: OT: Requiring client-side certs for RDP
> >
> > It's not completely wrong; "..the client must trust the root
> > certificate
> > authority.." actually means "the client must trust the CA that
issues
> > the TSG server certificate", but I agree that it's less than clear.
> >
> > Whether TSG will do this natively, I don't know (and kinda doubt),
> but
> > I
> > can certainly ask.
> > As with OL, the question is more client- than server-based; IIS and
> any
> > application that operates within it can use user cert auth, but so
> far,
> > no RPC/HTTP client is capable of responding to a server that
requires
> > user cert auth.
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > bounce@xxxxxxxxxxxxx]
> > On Behalf Of Thor (Hammer of God)
> > Sent: Friday, July 13, 2007 10:41 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: OT: Requiring client-side certs for RDP
> >
> > While dude's article is clearly wrong, the MSFT KB's should be
> amended
> > as well. Saying "the client must trust the root certificate
> authority"
> > is simply incorrect and misleading.
> >
> > But, more to the core question, since the ts gateway is not the
place
> > to
> > enforce this, are there plans in place for longhorn terminal
services
> > to
> > support client certificate requirements like IIS does?
> >
> > t
> >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > Sent: Friday, July 13, 2007 10:26 AM
> > > To: 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.
> > >
> >
> >
> >
> > All mail to and from this domain is GFI-scanned.
> >
>
>
>
> All mail to and from this domain is GFI-scanned.
>
All mail to and from this domain is GFI-scanned.
Other related posts:
