[isapros] Re: RDP v6.0 Client Certificate configuration
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Mon, 27 Aug 2007 15:06:58 -0700
MCIL...
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thor (Hammer of God)
Sent: Monday, August 27, 2007 2:54 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: RDP v6.0 Client Certificate configuration
CIL
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: Monday, August 27, 2007 1:27 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RDP v6.0 Client Certificate configuration
>
> Cross-forest cert auth is a Windows; not an ISA limitation.
> If it's stated so in the docs, it's not a "bug". Because ISA depends
> on AD for resolving certificates to user accounts, it's limited to what
> is available in Active Directory.
> If you want to cry "bug", go cry to the Windows team.
But ISA requiring active directory integration for "client authentication" of a
certificate *is* an ISA limitation. Don't confuse the two. No support for
commercial certificate PKI solutions is *not* a windows limitation, it's an ISA
limitation.
[Jim] I never stated otherwise, and this is a by-choice design limitation.
> I agree that the CRL rule seems heavy-handed to say the least, but
> you're being selective in your POV; if you used your GoDaddy user cert
> (assuming you could), ISA would need to validate the CRL and this would
> be "external", unless you just want to maintain your own destination
> set for various CRL locations.
Of course. But you can't use any "other" certificates in the first place
because of the AD limitation, so it doesn't matter anyway. Why have CRL
features in place when you can't use 3rd party certificates? If we're forced to
use local AD, then just make us disable the account - but don't force an "All
HTTP to all networks from my enterprise firewall" rule if we don't want to.
Fortunately, ISA seems to "cache" the CRL's so that once it hits the certsrv
you can disable the rule and it still works. Unfortunately, this prevents
common usage of a CRL in that even if you explicitly re-publish an CRL, or if
you explicitly update the CRL delta reflecting revocation, ISA doesn't seem to
see it. But I'm still working that out.
[Jim] - it's likely that ISA caches the CRL for a brief time for performance
reasons. Unfortunately, there's no way to access or clear the "CRL cache"
> "..the docs allude that it will work.." - the last row in the table at
> the bottom of
> http://www.microsoft.com/technet/isa/2006/authentication.mspx spells it
> out.
A single tabular reference at the end of one article where the words "Active
Directory (Windows)" appear under "Authentication Provider" hardly spells
anything out. Under "Client Certificate Authentication it says:
"In the client certificate scenario, a certificate is provided by the client,
and the client is authenticated by ISA Server on the basis of that certificate.
This might be a certificate that is embedded in a smart card, or a certificate
that is used by a mobile device so that it can connect to Microsoft
ActiveSync®."
It says "the client is authenticated by ISA Server on the basis of that
certificate." No, it's on the basis of validating the user account in AD, not
the cert. So why is "Accept any client certificate trusted by the ISA Server
computer" a configuration option? It simply doesn't work, period. It should
not be an option. I can give the ISA server a million valid CA certs and tell
it trust them all, but it will not accept them, even if it trusts them, even if
I tell it to, if it can't to a lookup in AD for the account. Also, where's the
little "Warning" like they have for 2 factor auth not working with ISA in a
workgroup? Won't work in a workgroup for SCCA either.
This directly from the help:
"The client certificate trust list allows you to configure what certification
authorities are accepted by Microsoft Internet and Security Acceleration (ISA)
Server 2006 for client certificates. For example, you can choose to accept only
client certificates that were issued by your corporate certification
authority." ERRRRNNNKK. Wrong.
Bottom line is that "it don't work as advertised." That being said, I'm ok
working within the limitations of the implementation, but that's what it is: a
limitation, so jump off that high horse, cowboy! :)
[Jim] - quicherbitchin, whiny-boy. You don't like the way the docs read, feel
free to post to isadocs@xxxxxxxxxxxxxx It's your direct line to the ISA doc
team. Along that same train, had you actually "read" the UI text when you
configured OL to use HTTP, you'd have seen the phrase "on fast networks,
connect using HTTP first, then connect using TCP/IP". I wonder what they meant
by that? :-p
Now, all that being said (part II) I certainly see that in standard
environments, this can totally be used successfully, and I'm happy with it.
[Jim] - kewl enuf. I still want to sort out why one environment has to "force
auth" and another doesn’t. This'll take some tracing.
t
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> Sent: Monday, August 27, 2007 7:29 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RDP v6.0 Client Certificate configuration
>
> There were multiple "causes," but the primary one is that ISA must do
> an AD lookup to validate the "client authentication" certificate. In
> my environment, the ISA server is a domain member in a different forest
> with no cross-trust, so it couldn't validate the account. To me, this
> is a shortcoming of ISA's "SSL Client Certificate Authentication"
> mechanism. In other words, you can only issue and use "user
> certificates" for the purpose of "client authentication" from forest
> Enterprise Root CA's that ISA is a domain member of, and where ISA can
> query AD. Even though the docs pair up "SCCA + AD," it seems more like
> a 'bug' to me. I mean, for SCCA to work, you must enable the system
> policy rule for "Allow all HTTP from ISA to all networks" for the
> purposes of CRL downloads. Why worry about CRL when you are forced to
> use AD? Worse yet, why force a horrible rule like "All HTTP from ISA to
> all networks" when it's really unnecessary? Further, the fact that one
> has an option to use "certs issued by all CA's ISA trusts" points to
> the implementation of SCCA to be a "work in progress" as there is no
> way it can use those other CA's given the AD requirement.
>
>
>
> The way it *should* work is the way the docs allude that it will work--
> that being the way all certs work -- where you say "if you get a cert
> for the purposes of client authentication that is signed by the
> following CA's, authenticate it" but it doesn't. My guess is that this
> is due to core ISA authentication operations where all authentication
> is tied to a user account somewhere and SCCA functionality, at the end
> of the day, requires some sort of account authentication.
>
>
>
> All other "problems" stemmed from that, and have all been sorted out
> and documented in the previous emails...
>
> t
>
>
>
>
>
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> Sent: Sunday, August 26, 2007 4:45 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RDP v6.0 Client Certificate configuration
>
>
>
> Was that the cause of the problem you and Jim were working on the last
> day or so? Or is that and the “require authentication” issue
> different? I’ve lost track of them and hadn’t ever seen a solution.
>
>
>
> Jerry
>
>
>
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> Sent: Sunday, August 26, 2007 2:41 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RDP v6.0 Client Certificate configuration
>
>
>
> P.S. To all those testing TSGateway, don't make the same mistake I did
> in temporarily redirecting to HTTP to test normal HTTPS-HTTP access for
> NetMon purposes, and then forgetting to set it back before testing RDP
> via TSGateway. TSGateway requires HTTPS of course, so redir to HTTP
> from the rule will give you odd "Logon Failed" errors. It took me a
> freaking day to figure that one out, but I'm a moron ;)
>
>
>
> t
>
>
>
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> Sent: Sunday, August 26, 2007 11:31 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RDP v6.0 Client Certificate configuration
>
>
>
> I occasionally enjoy a fine whine :)
>
>
>
> I've been in and out of this discussion becasue of Exchange horkage,
> but Jim probably said that the problem is with the client side
> software, right? There's no way to tell the client to present it's User
> Certificate for authentication, sort of like the problem with Oulook
> 2003+ RPC/HTTP -- the Outlook client doesn't know how to present the
> User Certificate for authentication, so it just chokes on it.
>
>
>
> So, I don't really see it as ISA's fault, but the RDP client's fault,
> if we need to assign blame, and I think we do because the RDP and
> Outlook guyz really need to think about security in a bit more depth
> and enable User Certificate assignment and presentation to the
> destination machine.
>
>
>
> There is a solution, but it means using additional software. The IAG
> 2007 supports User Certificate authentication to access the SSL VPN
> portal. Once you're authenticated and authorized by the IAG 2007 to use
> RDP, you can then use Integrated authentication to authenticate with
> the terminal server. It's not the best solution, because the best
> solution would be to build User Certificate support into the RDP and
> Outloook clients.
>
>
>
> Tom
>
>
>
> Thomas W Shinder, M.D.
> Site: www.isaserver.org <http://www.isaserver.org/>
> Blog: http://blogs.isaserver.org/shinder/
> Book: http://tinyurl.com/3xqb7
> MVP -- Microsoft Firewalls (ISA)
>
>
>
>
>
>
> ________________________________
>
>
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> Sent: Sunday, August 26, 2007 1:18 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RDP v6.0 Client Certificate configuration
>
> You mean a "Client Authentication Certificate" in the user's
> account's certificate store? Done that ;) You just can't tell the RDP
> client to use it. And ISA's "SSL Client Authentication Certificate"
> authentication mechanism is flawed-- it only allows the use of a cert
> generated by a CA that ISA is not only a domain member of, but also one
> where it can connect to AD and validate it. It completely horks
> "standard" certificate and trust usage in that regard. You can't even
> use something like a Verisign "Client Authentication" certificate (I
> bought one and tried it- no workie). So even if you have a full
> private key certificate you load and trust on the ISA box, if the ISA
> server can't confirm via AD, it won't work. Really poor implementation
> if you asked me.
>
>
>
> So, you gonna answer the question now? I mean, since you're the
> one who came up with the idea of publishing TSGateway via an SSL
> Listener configured to use SCCA, I figga'd you'd have some better
> answers than nomenclature whining. :-p
>
>
>
> t
>
>
>
>
>
>
>
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> Sent: Sunday, August 26, 2007 11:04 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RDP v6.0 Client Certificate configuration
>
>
>
> Try using a User Certificate and see if that helps ;)
>
>
>
> Thomas W Shinder, M.D.
> Site: www.isaserver.org <http://www.isaserver.org/>
> Blog: http://blogs.isaserver.org/shinder/
> Book: http://tinyurl.com/3xqb7
> MVP -- Microsoft Firewalls (ISA)
>
>
>
>
>
>
> ________________________________
>
>
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> Sent: Sunday, August 26, 2007 12:56 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] RDP v6.0 Client Certificate
> configuration
>
> Jim, et. al. -- any word on how to get the v6.0 RDP client
> to present a Client Authentication certificate to an ISA server
> listener using SSL Client Certificate Authentication? It no workie,
> and I can't find any data on a hack to specify a cert for the RDP
> client...
>
>
>
> t
>
>
>
> -----------------------------
>
> vinni, viddi, vinni denuo
>
>
>
>
> All mail to and from this domain is GFI-scanned.
>
All mail to and from this domain is GFI-scanned.
Other related posts:
