We are implementing UAG DirectAccess. The instructions indicate that a "dedicated CA" is required for this. We currently have a two-tier structure with a Root CA and an Issuing CA. We will eventually be moving to a third tier but not at this moment. Does anyone have any information about the type of configuration the UAG is requesting? Do I need to create a totally separate CA for just UAG or can we implement it as part of our current structure?

You should never have to deploy a separate PKI for an application. My guess is that the documentation is very incorrect. Brian

On Thu, 18 Aug 2011 14:15:11 +0000, mduffey12 wrote: We are implementing UAG DirectAccess. The instructions indicate that a "dedicated CA" is required for this. Do you happen to have a link for this requirement? Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Real time: Here and now, as opposed to fake time, which only occurs there and then.

When using OTP authentication, it is necessary to implement a dedicated issuing CA, as you cannot use the same CA that is used to secure the actual IPSec connections used by UAG DirectAccess. More here: http://technet.microsoft.com/en-us/library/gg502571.aspx#BKMK_Limit and here: http://technet.microsoft.com/en-us/library/gg315324.aspx Cheers JJ Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

On Tue, 20 Sep 2011 13:11:06 +0000, Jason Jones [Silversands] [MVP] wrote: When using OTP authentication, it is necessary to implement a dedicated issuing CA, as you cannot use the same CA that is used to secure the actual IPSec connections used by UAG DirectAccess. More here: http://technet.microsoft.com/en-us/library/gg502571.aspx#BKMK_Limit?and here:http://technet.microsoft.com/en-us/library/gg315324.aspx That article makes no sense at all. In the first place, an OTP solution using RSA devices by definition does not use certificates, secondly, when using a preshared key as described in the cited article, again, no certificates are in use. Finally, when using a smart card there's no technical, nor security related reason that the same CA can't be used to issue both the smart card certs and the certs for the UAG box. Whomever wrote this article apparently doesn't understand either PKI not OTP with RSA devices. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca GIGO: A movie industry acronym referring to the numerous "Gidget Goes..." movies, i.e. GIGO Hawaii, GIGO surfing, etc.

Hi Paul, The way the solution is architected, certificates are used as short-term proof of two-factor authentication (a bit like how system health certs are used to indicate that a machine is NAP compliant). Once the user has successfully authenticated using RADIUS or SecurID, a certificate is issued from the OTP CA and this certificate is used an additional authentication requirement on the IPSec tunnel that allow DA clients to reach the intranet. No OTP = no certificate = no intranet tunnel = no access to intranet servers. OTP from a UAG DA perspective is talking about using non-smart card solutions like RADIUS and RSA SecurID. I am not sure if you are aware, but UAG DirectAccess uses computer certificates in addition to computer and user authentication in order to provide the IPSec tunnles that connect to the DirectAccess gateway running on UAG. These are completely separate to the certs being dicussed when using OTP with UAG DA. The reason for a dedicated OTP is a technical limitation in the current Windows IPSec implementation. IPSec cannot differentiate between different certificates issued from the same CA and the client already has a certificate for the regular authentication process (as discssued above). Since the OTP implementation requires something that the client doesn’t have (which then will be issued after the user can authenticate with the OTP), you have to specify a dedicated issuing CA for OTP. It is probably a little hard to understand the documentation without the associated UAG DA understanding; I guess this is why it looks a little odd at first... I agree it could be better explained in the documentation or by creating a dedicated KB about it. Cheers JJJason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

P.S. The dedicated CA is only a requirement if you want UAG DirectAccess with OTP. You do not need to follow this approach if you are using smart card authentication with UAG DirectAccess. Smart card is my preferred option and a better user experience anyhow, but not all folks have this option or have existing investiments in OTP solutions...Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

wow, it really hurts the head when people who do not understand PKI decide to implement pKI in solutions. ARRRRGGHHH

Hi Brian, One would assume that the UAG product group validates these design decisions with the Windows or Directory product group...but maybe not :( It does seem a bit of an odd (and complicated) architecture and one of the reasons I try to get people to look at smart card integration for UAG DA... However, is is really that bad to use a dedicated CA for a specific certificate usage scenario; I thought that used to be recommended? For completeness, it would be useful for you to provide some specific comments on why you feel the design is so bad? Cheers JJ P.S. Don't shoot the messenger, I'm just trying to explain how they designed it and try to explain their reasoning for the dedicated CA ;) Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

1) The reasons that PKI fail is that there are over deployments of PKI. The worst examples are applications that state that they need their own dedicated CA - The old KMS with Exchange 5.x - all Cisco VPN 3000 devices - now UAG they obviously did not talk with the PKI group at MS. Here is a good example of an app that changed after talking to the PG. When you originally deployed NAP you were stuck setting up a separate CA (at least not a separate CA hierarchy, like what you describe), to issue health certificates. After getting involved with the PG, the ability to not include certificates in the CA database was added and now you do not need a separate CA for the issuance of certificates. The bottom line, is that PKI should be a single point of trust for an enterprise. A single application should not require its own dedicated CA. Sorry to vent on the messenger <G> Brian

Thanks Brian, just wanted to check we were on the same page here; I understand your point, however in this case it is not something I guess they can do much about if it is a limitation of the Windows 7 Firewall/IPsec client. Maybe a better approach would have been fixing the problem at source in Windows 7, as opposed to forcing the CA infrastructure requirement. From the outside, it looks like they tried to use the same type of approach as with NAP health certs in order to provide an extra "check" before allowing the IPSec intranet tunnel to establish, but this kinda backfired and they were forced to make the "dedicated CA" call. I am still confused why they seem to recommend an intermediate CA though, surely it would make more sense (if they had no other choice due to IPSec client limitations) to just use a dedicated issuing CA...I know you would still hate it though ;) Cheers JJ Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

The reasons that PKI fail is that there are over deployments of PKI. This comment intrigued me :) Although I am a FF MVP, I spend a fair of time working with AD CS too... Your use of the phrase "over deployment" made me think about modern day thinking when designing AD CS, so excuse the tangent. Do you think people now deploy PKI with too many tiers and too many issuing CAs then, as opposed to cosolidating more? Do you think think Issuing CAs should be multipurpose to reduce the number of dedicated issuing CAs deployed? Surely there must be cases where dedicated issuing CAs still have a legitimate place? I have read a lot of your written work over the years, so would respectfully appreciate your thoughts... Cheers JJ Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

Yes, I think some people deploy way to complex CAs. I believe that a CA: - Can issue certificates of multiple assurance levels (as long as the CA is managed to the highest assurance level and clearly asserts assurance level through the inclusion of defined OIDs in the certificatePolicies extension - Can issue certificates for users/computers/devices from the same CA - can in 90% of cases be deployed as two tiers: Root and combination policy/issuing - only need to be three tiers if there are explicit policy differences between sectors/divisions that call for totally separate certificate policies HTH, Brian

Thanks Brian. Apologies to mduffey12 for a bit of thread stealing, but I hope my additional information on UAG DA mechanics was useful to the thread in return! Cheers JJJason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk