[isapros] Re: SSL Client Certificate Authentication with non-web clients
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Thu, 23 Aug 2007 16:19:27 -0500
:)
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thor
> (Hammer of God)
> Sent: Thursday, August 23, 2007 3:25 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication
> with non-web clients
>
> "sense" of course (had to beat Tom to it).
> t
>
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > Sent: Thursday, August 23, 2007 1:23 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: SSL Client Certificate
> Authentication with non-
> > web clients
> >
> > I'm hitting the listener as an anonymous user, yes. But,
> I'm providing
> > the cert as authentication. If I don't "require
> authentication" in the
> > "SSL Client Certificate Authentication" properties, it
> never asks the
> > client to provide a cert. And just to ensure that the browser isn't
> > "automatically" sending anything, I've deleted the client cert and
> > removed the domain CA cert from root certs on the client box -- with
> > "require authentication" cleared, but requiring SSL Client
> Cert Auth,
> > the client, the client can still connect to the server without
> > presenting a certificate (which doesn't make any since to
> me) and there
> > is no fallback auth specified.
> >
> > Thoughts?
> >
> > t
> >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> > > Sent: Thursday, August 23, 2007 1:15 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-
> > > web clients
> > >
> > > Are you still logging on as an anonymous user? Since you're
> > > configuring the listener to use a client cert and require
> > > authentication, shouldn't you be authenticating against the ISA
> > server?
> > >
> > > Cordially yours,
> > > Jerry G. Young II
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Application Engineer
> > > Platform Engineering & 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
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > "The truth is that there is nothing noble in being superior to
> > somebody
> > > else.
> > > The only real nobility is in being superior to your former self."
> > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > >
> > >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > Sent: Thursday, August 23, 2007 4:10 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-
> > > web clients
> > >
> > > OK... Help me out with this one-- forget about RDP, etc. I'm just
> > > trying to get an SLL Listener to require an SSL Client Certificate
> > for
> > > authentication, and am having some issues- i'm sure it's something
> > > easy,
> > > but I'm missing it.
> > >
> > > Start from the basics without requiring auth on the listener:
> > > 1) Create SSL listener with proper cert
> > > 2) publish to internal site
> > > 3) got to https://www.domain.com and it works fine
> (either bridged to
> > > 443 or redirected to 80) as anonymous user.
> > > 4) at this point, everything works just fine...
> > >
> > > Now, I tell the listener to require a client-side cert for
> > > authentication- in this case, it is a cert that must be
> signed by my
> > > own
> > > domain CA. The ISA box is NOT on that domain.
> > > 1) install CA cert in trusted root certificates on ISA box. It
> > works,
> > > and is valid.
> > > 2) install User cert created by the CA on client box with path to
> > root
> > > cert. Move CA cert to trusted root certs. User cert is
> valid, cert
> > > path is valid.
> > > 3) Configure listener to use client cert, and to require
> > > authentication.
> > > If I don't require, the client does not have to present a cert. I
> > > further tell ISA to only accept certs trusted by the domain CA (it
> > > shows
> > > up in the list, of course). Note that behavior does not
> change if I
> > > select "all CA's"
> > > 4) Configure the system policy on ISA for CRL lookups
> > > 5) Verify the ISA box can get to the CRL path specified
> in the cert
> > > 6) from the client, go to https://www.domain.com and it asks for a
> > > cert.
> > > The cert is available, and i present it: but I always get:
> > >
> > > Error Code: 401 Unauthorized. The server requires authorization to
> > > fulfill the request. Access to the Web server is denied.
> Contact the
> > > server administrator. (12209)
> > >
> > > Removing the SCCA returns things to normal. I've even tried
> > publishing
> > > to different back end servers... same thing.
> > >
> > > What could be the problem?
> > > t
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > > Sent: Thursday, August 23, 2007 11:26 AM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re: SSL Client Certificate
> Authentication with
> > > non-
> > > > web clients
> > > >
> > > > The point of using a browser on not is not relevant.
> > > > It's the client application's responsibility to handle
> the return
> > > from
> > > > SCHannel that says "pick a cert of type 'X'".
> Supposedly, the v6
> > RDP
> > > > client knows how to prompt for smartcard certs, but I haven't
> > > > personally
> > > > tested this. Word on the streets is that "soft-certs"
> should also
> > > > work,
> > > > but again; I haven't personally tested this.
> > > >
> > > > -----Original Message-----
> > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > bounce@xxxxxxxxxxxxx]
> > > > On Behalf Of Thor (Hammer of God)
> > > > Sent: Thursday, August 23, 2007 7:26 AM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] SSL Client Certificate
> Authentication with non-
> > web
> > > > clients
> > > >
> > > > So, in an earlier thread, we discussed using certificates to
> > control
> > > > what clients could connect to a published RDP server.
> As we saw,
> > > this
> > > > is not possible in Vista/2003 implementations. However, we see
> > that
> > > in
> > > > TSGateway, one uses an SSL listener (with public names
> to /rpc) to
> > > > publish access to TSGateway functionality via RDP over RPC/HTTP.
> > The
> > > > TSGateway configuration allows you to specify
> smart-card logon, but
> > > in
> > > > the absence of that, the recommendation was made to use
> "SSL Client
> > > > Certificate Authentication" restrictions at the SSL listener
> > itself.
> > > >
> > > >
> > > >
> > > > However, I don't see how this will work. As I see it,
> the only way
> > > to
> > > > use SCCA on a web listener is for the client to be a browser -
> > that's
> > > > how the user is given the option of choosing which cert
> to present
> > to
> > > > the server. In the case of an RDP client (MSTSC.exe)
> connecting to
> > a
> > > > TSGateway published via an SCCA web listener, it won't work as
> > there
> > > is
> > > > no way to present a cert.
> > > >
> > > >
> > > >
> > > > So, we really can't use SCCA as it relates to RDP,
> correct? Or is
> > > > there
> > > > some secret squirrel configuration I don't know about?
> > > >
> > > >
> > > >
> > > > t
> > > >
> > > >
> > > >
> > > > -----------------------------
> > > >
> > > > vinni, viddi, vinni denuo
> > > >
> > > >
> > > >
> > > >
> > > > All mail to and from this domain is GFI-scanned.
> > > >
> > >
> > >
> > >
> > >
> > > =================================
> > >
> > > This email message is intended for the use of the person
> to whom it
> > has
> > > been sent, and may contain information that is confidential or
> > legally
> > > protected. If you are not the intended recipient or have received
> > this
> > > message in error, you are not authorized to copy, distribute, or
> > > otherwise use this message or its attachments. Please notify the
> > sender
> > > immediately by return e-mail and permanently delete this
> message and
> > > any attachments. NTT America makes no warranty that this email is
> > error
> > > or virus free. Thank you.
>
>
>
Other related posts:
