In the continuing saga of the “No Usable Certificate(s) 0x103” error, which has been discussed in two previous blog posts:

http://blogs.technet.com/b/tomshinder/archive/2010/03/30/troubleshooting-the-no-usable-certificate-s-ip-https-client-error.aspx

and

http://blogs.technet.com/b/tomshinder/archive/2011/02/21/another-cause-of-the-no-usable-certificates-s-0x103-error.aspx#3415408

we’ll expand on the explanation for the reason why the computer certificate isn’t included in the NTAUTH store on the UAG DirectAccess server. In the second link noted above, we discovered that we’ll see the “No Usable Certificate(s) 0x103 error when there is no CA certificate contained in the NTAUTH store of the UAG DirectAccess server.

What we didn’t discuss was “why wasn’t there a CA certificate in the NTAUTH store of the UAG DirectAccess computer?

If you look in the comments section over at http://blogs.technet.com/b/tomshinder/archive/2011/02/21/another-cause-of-the-no-usable-certificates-s-0x103-error.aspx#3415408 you’ll see that a UAG DirectAccess server admin is having this problem – there is no CA certificate in the NTAUTH store on the UAG DirectAccess server. What he discovered is that while the client machines had this certificate installed, the UAG DirectAccess server didn’t and he thought reason for this is that only the client systems were receiving certificates through autoenrollment; the UAG DirectAccess server was not obtaining a computer certificate through autoenrollment.

I thought this was interesting and did a little research on the subject.

At http://msmvps.com/blogs/bradley/archive/2009/02.aspx?PageIndex=3 you can find the following information:

“…A Windows client's Enterprise NTAuth store is a local cache of certificates
published in the NTAuthCertificates store in Active Directory. These
certificates are propagated from Active Directory to Windows clients via
Group Policy. Since the workstation is not members of a domain, the local
NTAuth cache is not being updated and so is empty…

Resolution:
---------------------------
The local NTAuth store can be manually populated using certutil.exe.
Certutil -enteprise -addstore NTAuth CaCertificate.cer
The physical location for the NTAuth store is:
HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates
When the issuing CA certificate is added to the NTAuth store…”

The distribution of the enterprise CA certificate is separate from the distribution of the computer certificates through autoenrollment. Distribution of the CA certificate is automatic and distributed through Group Policy mechanisms and is done when the machine joins the domain. In contrast, distribution of the computer certificate through autoenrollment is something that you need to configure manually and target the machines that you want the certificates assigned to, and then requests are sent to the CA for certificate distribution to the requesting client.

Our UAG DirectAccess server admin discovered the answer at support.microsoft.com/.../295663. Check this out:

“The contents of the NTAuth store are cached in the following registry location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates

This registry key should be automatically updated to reflect the certificates that are published to the NTAuth store in the Active Directory configuration container. This behavior occurs when Group Policy settings are updated and when the client-side extension that is responsible for autoenrollment executes. In certain scenarios, such as Active Directory replication latency or when the Do not enroll certificates automatically policy setting is enabled, the registry is not updated. In such scenarios, you can run the following command manually to insert the certificate into the registry location:

certutil -enterprise -addstore NTAuth CA_CertFilename.cer”

Our hats are off to you, anonymous UAG DirectAccess admin!

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

From what I hear, this year is going to be the year where we see the wave of enterprise Windows 7 rollouts take place. While I’m not sure how these assessments are made, it makes sense from where I sit. Windows 7 Service Pack 1 has been released and end users, admins and the media have all been complimentary of Windows 7. Let’s face it – Windows 7 just plain rocks!

For this reason, I expect that we’re going to see a lot of new DirectAccess deployments being planned and executed. What’s one of the biggest goodies you get with Windows 7? I’d argue that DirectAccess is on the top five list.

If you’ve already deployed DirectAccess, you’ve seen your users and management love what it’s done for their productivity and overall computing experience. I’ve seen the same here at Microsoft. If someone who has been on DirectAccess for a few weeks somehow can’t get it to work, they show all the physical symptoms of withdrawal. Sweating, anxiety, fear, sadness, depression, and cravings all appear to those deprived of DirectAccess (OK, probably not everyone in the company has those symptoms when DirectAccess isn’t working, but that’s what happens to me).

Of course, it’s always nice to see external commentators say something nice about DirectAccess. And that happened a couple of weeks ago on The Register. The Registers motto is “Biting the Hand that feeds IT” – which is consistent with their hard hitting approach to reporting on technology issues. So you know if they say something nice, they mean it.

So when I read this quote at http://www.theregister.co.uk/2011/03/18/windows7_move/ I cried tears of joy:

“…there are real improvements in Windows 7…Direct Access, which requires Windows 7 and at least one instance of Server 2008 R2, lets users connect to file shares across the internet and without VPN. This is lighter weight and less risky than VPN, which gives all or nothing remote access…”

Sure, it’s not glowing or gushy but that’s not how The Register rolls.

What it does say to me is that they think DirectAccess is a good thing and one of the important reasons to strongly consider integrating DirectAccess early in your Windows 7 deployment plans.

Thanks!

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

We’ve received a number of questions recently about UAG DirectAccess support for the IPv6 Internet. When thinking about the IPv6 Internet, you need to think about when the DirectAccess client is on an IPv6 Internet (or on an IPv6 only intranet) and when the UAG DirectAccess server has its external interface connected to an IPv6 Internet connection.

Part of this confusion seems to stem from a TechNet article over at:

http://technet.microsoft.com/en-us/library/ee809074.aspx

Let’s look at some of the sections that might be ambiguous or otherwise difficult to understand and try to clarify a few things.

“The DirectAccess client computer connects to the Forefront UAG DirectAccess server using IPv6 and IPsec. If a native IPv6 network isn’t available (which is most probable when the user is connected to the Internet), the client establishes an IPv6-over-IPv4 tunnel using 6to4 or Teredo. The user does not need to be logged in to complete this step…”

There are two issues that need to be clarified here:

• First, the DirectAccess client always connects to the UAG DirectAccess server using IPv6 and IPsec. The IPv6 packets are protected by IPsec (with the exception of ICMPv6, which is not protected by IPsec by default). However, the IPsec protected IPv6 packets are always going to be encapsulated by an IPv4 header, using Teredo, 6to4 or IP-HTTPS (which was left out of the statement above)
• Second, if an IPv6 network is unavailable… If an IPv6 network is unavailable, then the DirectAccess client will try to use an IPv6 transition technology to connect to the UAG DirectAccess server. If an IPv6 network is available, then the machine will not be able to connect to the UAG DirectAccess server. And if somehow it does, this is not a supported scenario (I’m not saying that it can or it can’t – but I am saying that this is not a supported scenario).

That’s it – not too complicated but an important thing to know – that we don’t support scenarios where the UAG DirectAccess server’s external interface is connected an IPv6 Internet (that is to say, that the UAG DirectAccess server has an IPv6 address assigned to its external interface) and when the DirectAccess client is connected to an IPv6 only network (which prevents the client from being able to set up an IPv6 transition technology based connection to the UAG DirectAccess server.

Several people  have asked why we decided to use this approach, and the primary reason is that there are very few scenarios where the UAG DirectAccess server is connected to an IPv6 only Internet connection and where the UAG DirectAccess client is connected to an IPv6 only network. Since these scenarios can be interpreted as “corner cases” at this time, the decision was to not design toward these scenarios and focus on what we see on networks today.

That said, Microsoft is firmly committed to IPv6 and our DirectAccess design and implementation will grow with the increasing availability of native IPv6 Internet and intranet connectivity.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

I’ve been pretty quiet for most of this month (in fact, this is the first post on the Edge Man blog for March). I was in Redmond for the world wide MVP conference for a week and then spent a week to meet with members of my team on how we’ll approach documentation for the next version of Windows. It was a great visit but pretty tiring. I spent all of last week trying to get caught up and also preparing for a presentation of our content plan. I hope they like it, and even more important, I hope that YOU all like what we have planned for you!

One of the things that we hope to provide you in the future is an increasingly robust collection of Test Lab Guides. If you don’t know about Test Lab Guides and what they’re all about, then check out my post at

 http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx

We also have a great Test Lab Guide blog where you can get the latest information about Test Lab Guides and ask questions about Test Lab Guides. The Test Lab Guide blog is over at

http://blogs.technet.com/b/tlgs/

Finally, if you want to find a comprehensive list of Test Lab Guides, head on over to the TechNet wiki

http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx?wa=wsignin1.0

Now that you know all about Test Lab Guides, I want to take this opportunity to tell you about a new Test Lab Guide!

The new Test Lab Guide walks you through the setup and initial configuration of System Center Service Manager and you can find this Test Lab Guide over at:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=b276879e-380f-4b40-809e-1574f4059277

Its exciting to see the System Center folks releasing Test Lab Guides! As you know, System Center products are broad and deep, and its hard to figure out how things work from end-to-end without getting your hands-on in a Test Lab . Test Lab Guides are the ideal way to get that hands on experience and I’m looking forward to more great TLGs coming from our friends in System Center.

Thanks!

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Got a long drive between home and work?

Tired of listening to 80s hits on the radio?

Then how about a change of pace and connect with The Edge Man Tom Shinder and Security guru Yuri Diogenes for a couple hours of TechNet Talk Radio?

Yuri talks about TMG and how TMG can be used in a number of new scenarios, such as how the TMG firewall can be used to provide superior security for public cloud access and how the TMG firewall’s integrated web anti-malware and URL filtering make help make sure that your clients and on-premises datacenters remain secure in a world of private and public clouds.

You can download an MP3 of Yuri’s TechNet Talk radio broadcast over at:

http://blogs.technet.com/b/talktechnet/archive/2011/03/10/talk-technet-episode-10-yuri-diogenes-on-forefront-tmg.aspx

Also, if you like what you hear, check out Yuri’s blog where he talks about a number of security related topics:

http://blogs.technet.com/b/yuridiogenes/

After you listen to Yuri’s blog on the way to work, you can listen to me on the way home! In my TechNet Talk Radio show session, I took a number of questions from the audience, and some of them got really close to the goal of “stump the chump”! I had a great time and we talked about a number of subjects related to DirectAccess and also the weather in Texas and Seattle

You can download the MP3 of my TechNet Talk radio broadcast over at:

http://blogs.technet.com/b/talktechnet/archive/2011/03/18/talk-technet-episode-12-dr-tom-shinder-on-directaccess.aspx

Hope you enjoy these TechNet Talk Radio broadcasts. To see a list of upcoming broadcasts where you can call in and ask questions in real time, check out:

http://technet.microsoft.com/en-us/gg558001

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder