I was at a a customer recently where they were experiencing a problem with DirectAccess; roaming users, home or travelling, would suddenly lose their DirectAccess connection. Investigation revealed that these were IP-HTTPS users that were working out of office and their connections would mysteriously drop. These were normally Teredo clients but there are documented scenarios of Teredo quirks that cause a fail back to IP-HTTPS. The users in question had been travelling and logging on on other corporate LANs so fallback to IP-HTTPS was plausible (the ins and outs of Teredo behaviour can be found in the following blog entry):
On the IP-HTTPS side, we were noticing that the tunnel negotiation and setup was failing. Logs from the user(s) experiencing the problem were captured via the DirectAccess Connectivity Assistant. The details in the IP-HTTPS portion of the log were revealing:
https://access.mydomain.com:443/IPHTTPS Last Error Code : 0x80092013 Interface Status : failed to connect to the IPHTTPS server.
The Certificate Distribution Point (CDP) of the online Issuing Certification Authority could not be reached (error code 0x80092013).
The Certificate Distribution Point (CDP) offline message turned out to be misleading. The CA CDP was online and reachable, but investigation revealed a key omission in our configuration. The CDP of the Issuing CA URL was not in the Direct Access tunnel exemptions list. This meant that every X hours or so the CRL cache on the local Windows 7 clients was expiring. When the client did need to obtain a fresh CRL from the CA, it failed because of a race condition where the client was unable to setup the infrastructure tunnel because the server authentication certificate issued to the IP-HTTPS listener (running under IIS) could not be validated as the CA CDP was unreachable and the CRL not downloadable because the tunnel hadn’t been established (loop to infinity)…..
Lessons learned:
Nice!! 
Regards,
Mylo
I was looking for a way to temporarily disable DirectAccess on the Windows 7 client recently when testing UAG with AD FS 2.0 and needed a quick and relatively pain-free manner of making sure that DA wasn’t interfering… Giving the IP Helper service a kick on servers in the past has often given the right result with IPv6 and ISATAP, so it seemed logical that stopping the IP Helper service on the client might also have the desired effect
NET STOP IPHLPSVC
This did the trick.. no more DirectAccess.. nothing has blown up and restarting the Helper service using NET START IPHLPSVC brought DA back up 
Somewhere along the line, upgrading from UAG SP1 RC to SP1 I’d managed to hose my laptop; the infrastructure tunnel was never coming up and IKE Main Mode negotiation was failing. Connecting the client to the LAN and refreshing Group Policy I ran into an error concerning TCP/IP. Looking at the GPRESULT output:
| Group Policy Infrastructure | Success | 2/20/2011 4:22:04 PM | ||
| Registry | Success | 2/17/2011 9:40:53 AM | ||
| Security | Success | 2/17/2011 9:40:54 AM | ||
| TCPIP | Failed (no data) | 2/20/2011 4:22:04 PM | ||
There was nothing in the Application Event Log. The System log, however, had an Event ID 1085 listed. The Details tab gave a clue: EventData SupportInfo1 1 |
||||
It turns out the IP Helper service had been set to Disabled . Setting the service back to Automatic and rebooting the system, updating Group Policy and everything is back to normal.
Weird! 
Mylo
If you’ve had the good fortune of setting up AD FS 2.0 in the last few months, then no doubt you’re seeing the various capabilities and nuances of such a solution. As a new product though, while “free”, working with such technology can be frustrating. Not having the pleasure of seeing someone else going through that pain barrier that you are, nor being able to learn from someone else’s mistakes rather than yours, can make for difficult times … Nonetheless, I’ve been running various sandpits and configurations now since Q4 2009 (with admittedly varying degress of success) and I really had been meaning to make note of some of this earlier.. it was the recent release of UAG 2010 SP1 RC that provided the necessary motivation.
In this post I’m describing Web SSO scenarios, using a single corporate Active Directory for internal and external access. I look at a few possible approaches:
I’m using split-DNS in my test sandpit.. mydomain.com registered (A) records point to the AD FS proxy and the TMG in Scenario 1 for AD FS and Sharepoint respectively. In Scenario 3, the UAG portal trunk is the destination for both AD FS and Sharepoint. Scenario 2 has the A record for the AD FS STS pointing to the internal AD FS farm and the internal Sharepoint web farm(s).
Scenario 1 – Internet Access
Prerequisites
sts.mydomain.com – pointing to the Internet registered (A) record for the AD FS Proxy
teams.mydomain.com – pointing to a RP (e.g. Sharepoint 2010)…
I used TMG in the sandpit to protect my relying party (Sharepoint)…. It’s worth noting that TMG is acting as a simple Reverse Proxy here. There’s no pre-authentication on the web listeners, no FBA, no Windows Auth. The user is logging on via the AD FS proxy, before they can gain access to the Relying Party (via TMG). If that’s not clear enough… let me put it another way .. TMG is not involved in the logon process at all … i.e. AD FS based logon thru TMG is not a supported configuration (not to mention I can’t get it working either). There are, however, still potential advantages to be had, in using the TMG as the reverse proxy; namely in protecting the relying party (Network Inspection System and Enhance Malware Protection spring to mind).
As a footnote, I ended up using a wildcard certificate for testing in this scenario ; a single web listener on TMG will suffice with multiple web publishing rules per relying party (in this case per web application in Sharepoint 2010). Note that it is possible to put the AD FS proxy itself behind TMG and this works (although this adds another SSL hop to the access equation) and again, there’s no authentication configured on the listener.
Scenario 2 – Intranet/Internal Users: Integrated Authentication : IWA and AD FS
Prerequisites
In an Intranet scenario, we can leverage the SSO capability that AD and WIF can offer through integrated authentication. The client is using local DNS and is pointing directly to the AD FS farm rather than the proxy. In this example, I’ve added the STS needs to the local Intranet zone. If you’re using Mozilla in your tests here, you’ll need to go into about:config in the browser and add the STS to both the network.negotiate-auth.delegation-uris and network.negotiatea-auth.trusted.uris for Kerberos to work.
Scenario 3 : Internet Access (with UAG)
Prerequisites
– All the above plus UAG 2010 SP1 RC
When I saw that UAG SP1 (RC) now supports AD FS 2.0, I danced a little jig (albeit in my mind… I am at best, sadly, a poor dancer… my right leg is a PC, my left is a Mac…..that’s how well they get on)…. Anyway, with UAG 2010 supporting AD FS 2.0, this little offering enhances the use case at the edge.
As the name suggests with UAG, this is unified access… so all access in this scenario is thru said gateway. In this capacity, UAG (portal.mydomain.com) is a Relying Party. As the SP1 RC documentation, recommends, I created a trunk and configured AD FS as an authentication provider in UAG.
There are two access scenarios with UAG here. The first is accessing the portal trunk itself with the application available on the UAG portal, the second is calling the application directly (RP-initiated logon)
Portal-based Logon
Logging in thru portal.mydomain.com, I’m entering the UAG URL directly rather than the application (teams.mydomain.com).
First time I logon, I elect to trust the site for this session… (all the UAG ActiveX controls were installed earlier)…. because my AD FS test rig is configured with two test claims providers, Employees and Partners, we need to go thru Home Realm Discovery.. I’m logging into Employees.. (Partners is another IdP)
Login with user ID and password at the AD FS Proxy
Now we’re in the UAG portal screen
I select the “Teamsites” application and off we go and we’re in Sharepoint
RP-Initiated Logon
This process incorporates less steps and is a more likely usage scenario particularly with users bookmarking the relying party in the browser.. duly noted… here I access a Teamsites favourite that I’ve created in my browser of choice; taking me to https://teamsites.mydomain.com.
Again, I go thru Home Realm Discovery (HRD) and select Employees
Forms-based Logon at the AD FS Proxy using my trusty user ID.
This time there’s no Portal rendition, and it’s straight into the application.
UAG Configuration Notes
Here’s some barebones configuration notes.. this is not a step-by-step, rather a summary of the salient points (as I recall them)…
Create a new portal trunk and under this trunk (e.g. portal.mydomain.com) create our authentication server using the new AD FS 2.0 Server Type.
Retrieve the federation metadata and select a leading claim value (I’ve used Name). This will automatically create a new AD FS 2.0 application and Application Type .. make a note of the UAG Relying Party endpoint.. this is required when configuring the Relying Party in AD FS….. syntax is along the lines of..
You can test availability of the metadata via the browser.. note that this must resolve to the external trunk address rather than any internal address of the UAG server (this is mentioned in the documentation).
After it’s created we can pop in and look at the application properties… I didn’t have to change any settings within.
At this point it was time to create an application in UAG for our test Teamsites application… as can be seen from the subsequent shot.. we elected to use the AD FS authentication server here..
Incidentally, I elected to check the Portal and toolbar link checkbox as I wanted to test accessing the Sharepoint application thru the portal itself (as described earlier).
A couple of final notes…
Make sure the UAG portal URL, the AD FS STS and the RP are in the same browser zone otherwise spurious errors such as the one below will appear. Again, the help file does mention this, but ….
I used Local Intranet Zone as I have an Intranet access scenario (2) which uses Kerberos-based logon..
I’ve also tried this configuration from the Internet using a Windows 7 domain joined client using DirectAccess and everything works smoothly with integrated auth … great stuff..
The UAG RC documentation states that you can configure AD FS to use forms-based authentication, however, UAG does not support this configuration by default. Now I initially read this as meaning that the FBA is not supported, however, that didn’t make much sense to me so I assumed that I’d misinterpreted the meaning of the RC documentation and chose to ignore it 
…
Next test stop is either going to be KCD testing with Shadow accounts (which looks pretty interesting ) or adding the CRM 2011 Beta IFD to UAG…
Hope this helps somebody/somewhere..
Mylo
The Access Onion 