[isapros] Re: OT: Requiring client-side certs for RDP

  • From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
  • To: <isapros@xxxxxxxxxxxxx>
  • Date: Fri, 13 Jul 2007 15:54:05 -0700

Not true - each server OS provides the "remote desktop users" group that allows 
RDP access without adding anyone to the local admins group.
There is *no* requirement for a user to be a local admin simply to provide TS 
access.

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Gerald G. Young
Sent: Friday, July 13, 2007 3:15 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: OT: Requiring client-side certs for RDP

You realize that you don't NEED to add a user to the local Administrators group 
to get access over RDP, yeah?  It's just that by default only the local 
Administrators group is allowed to access the server over RDP.  You can grant 
that to a regular user and then su (runas) into an administrator account.  That 
would still meet least privilege reqs, yeah?

Cordially yours,
Jerry G. Young II
Application Engineer
Platform Engineering and Architecture
NTT America, an NTT Communications Company

22451 Shaw Rd.
Sterling, VA 20166

Office: 571-434-1319
Fax: 703-333-6749
Email: g.young@xxxxxxxx

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thomas W Shinder
Sent: Friday, July 13, 2007 5:28 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: OT: Requiring client-side certs for RDP

BTW--why are you looking into RDP?

I've always thought remote access to RDP was poison, since it epitomizes
the violation of least privilege.

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 Thomas W Shinder
> Sent: Friday, July 13, 2007 3:23 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: OT: Requiring client-side certs for RDP
> 
> Doesn't hurt to ask :)
> 
> 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 3:18 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: OT: Requiring client-side certs for RDP
> > 
> > Exactly.  Which is why I'm asking for it ;)
> > t
> > 
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> > > Sent: Friday, July 13, 2007 2:16 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: OT: Requiring client-side certs for RDP
> > > 
> > > That's true -- this type of authentication is designed to 
> > protect the
> > > client from "rogue" terminal servers. It doesn't do anything to
> > protect
> > > the server, nor is that the intent.
> > > 
> > > 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 2:05 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re: OT: Requiring client-side certs for RDP
> > > >
> > > > Vista or the updated XP client.  You need to check under 
> > Advanced to
> > > > select the connection type.
> > > >
> > > > But that is not what is important... what is important is 
> > that *the
> > > > client* decides what to do in the current deployment of 
> RDP/TLS in
> > > > Win2k3 terminal services configurations.  For "true"
> > > > connection-based-on-certificate security, you must have
> > > > functionality on
> > > > the server to request and validate a certificate.
> > > >
> > > > This is why I went out of my way to describe the behavior, to
> > > > avoid all
> > > > of this ;)  So, the question was, does anyone know if 
> > this is being
> > > > addressed in Longhorn...
> > > >
> > > > t
> > > >
> > > > > -----Original Message-----
> > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > > > Sent: Friday, July 13, 2007 12:58 PM
> > > > > To: isapros@xxxxxxxxxxxxx
> > > > > Subject: [isapros] Re: OT: Requiring client-side certs for RDP
> > > > >
> > > > > Ok - what client are you using?
> > > > > I've configured my own TS (not TSG) to use SSL encraption and
> > every
> > > > > time
> > > > > I connect with any hostname other than what is 
> presented by the
> > > cert
> > > > > subject, I get a "cert validation" popup.
> > > > >
> > > > > -----Original Message-----
> > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > bounce@xxxxxxxxxxxxx]
> > > > > On Behalf Of Steve Moffat
> > > > > Sent: Friday, July 13, 2007 12:39 PM
> > > > > To: isapros@xxxxxxxxxxxxx
> > > > > Subject: [isapros] Re: OT: Requiring client-side certs for RDP
> > > > >
> > > > > No popups are presented......I helped with the testing.
> > > > Straight into
> > > > > the desktop.
> > > > >
> > > > > S
> > > > >
> > > > > -----Original Message-----
> > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > bounce@xxxxxxxxxxxxx]
> > > > > On Behalf Of Jim Harrison
> > > > > Sent: Friday, July 13, 2007 4: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.
> > > > >
> > > >
> > > >
> > > >
> > > >
> > 
> > 
> > 
> > 
> 
> 
> 


All mail to and from this domain is GFI-scanned.


Other related posts: