[isapros] Re: SSL Client Certificate Authentication with non-web clients
- From: "Gerald G. Young" <g.young@xxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Thu, 23 Aug 2007 16:46:22 -0400
Can you connect from a client that doesn't have a client cert installed?
For the "Require SLL Certificate" checkbox being grayed out, can you have both
a SLL Cert for the server AND require a client cert? Isn't that a
one-or-the-other kind of thing?
Yeah, I'm sorry I'm not able to help more. :(
Are you on your client as an AD user from the domain in which the ISA server
exists?
Have you taken a network trace to see what kind of communication is occurring
between the ISA server and the client?
I'm grasping here but... :)
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:39 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: SSL Client Certificate Authentication with non-web
clients
I agree completely- "require authentication" seems like, in addition to the
client cert, that the client must be authenticated via "one of the selected
methods," in this case AD (the only radial button selected- and it is grayed
out).
What is curious the that the "Require SSL Certificate" is grayed out and
unchecked. But why would that option be there in the first place if I've
explicitly said I'm requiring a client cert? The help is useless in this
regard, and I'm not finding much other info on it...
But thanks for your input ;)
t
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> Sent: Thursday, August 23, 2007 1:34 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> No other thoughts than I always assumed a 401 error was for failure of
> user authentication, not client cert authentication. I would have
> assumed that by configuring a listener to use client certs, a browser
> wouldn't even be able to connect without one (don't remember selecting
> a cert to present). I thought requiring a client cert and requiring
> authentication were two different things. If the issue really is
> something simple and not a... ahem... bug, my money would be on the
> understanding of the difference of those two settings.
>
> 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: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.
>
>
>
> =================================
>
> 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.
=================================
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:
