[isapros] Re: SSL Client Certificate Authentication with non-web clients

  • From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
  • To: <isapros@xxxxxxxxxxxxx>
  • Date: Thu, 23 Aug 2007 14:54:08 -0700

You can combine FBA & client cert, but only if you select client cert from the 
FBA configuration.
You cannot combine "primary" user cert auth (selected from the listener auth 
schemes UI) and any other auth method.

-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thor (Hammer of God)
Sent: Thursday, August 23, 2007 2:12 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: SSL Client Certificate Authentication with non-web 
clients

If I leave "require client cert" but remove "require authentication" then any 
client can connect from anywhere without regard to certificates. 

I absolutely agree that the expected behavior would be that without a client 
cert, that you could not connect.  But you can.

 

In fact, from a client with or without a client cert, when "require 
authentication" is removed, the listener does not even ask for a client 
certificate-- it just goes right to the web site.

 

It is "poo poo"

 

t

 

From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Gerald G. Young
Sent: Thursday, August 23, 2007 2:07 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: SSL Client Certificate Authentication with non-web 
clients

 

No, I meant what if you leave " require client cert", remove "require 
authentication", and then...

Test 1
From a client without a client cert installed try to connect.  Can you?  
Expected result is no, you can't.

Test 2
From a client with a client cert installed try to connect.  Can you?  Expected 
result is yes, you can.

Cordially yours,
Jerry G. Young II  ++ Sent from BlackBerry ++
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 <isapros-bounce@xxxxxxxxxxxxx>
To: isapros@xxxxxxxxxxxxx <isapros@xxxxxxxxxxxxx>
Sent: Thu Aug 23 16:52:46 2007
Subject: [isapros] Re: SSL Client Certificate Authentication with non-web 
clients

If I select "require authentication," but don't have a client cert, I cannot 
present the cert (have an empty "select cert" window) and can't access the site.
If I load the cert properly, it is available to present, but after I present 
it, I get the 401 authentication error.
If I tell ISA to use a *different* CA (one that I don't have), but present my 
domain cert, it comes back and tells me to select a different certificate.

The client I'm testing from is not on the domain, and I'm not logged on as a 
domain user for ISA-- but I shouldn't be.  I'm testing what would be a 
"standard"' internet user accessing an SSL site that is configured to require a 
client-side cert for access. 

The goal is to limit who can connect up to the site in the first place via user 
cert, just like what you can do in IIS directly with client cert mapping.  I'm 
hoping that I don't also have to go to the IIS site and configure some sort of 
client cert mapping voodoo-- if you have to do that, there is no use in having 
the listener require a client cert.

Still macking at it ;)

t

> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> Sent: Thursday, August 23, 2007 1:46 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> 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.



=================================

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.

 


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


Other related posts: