The following are some troubleshooting steps if you run into problems getting inside-out management working. Inside-out management is the ability for a machine on the internal corporate network, such as a helpdesk machine, to be able to initiate communications to remote, internet-based DirectAccess clients, such as by using RDP sessions, remote registry, or mapping drives.
1. Ensure the remote DirectAccess client has registered its IPv6 address and name in DNS and that it can be resolved by the Inside-Out management machine. The IPv6 address will correlate to which ever connection mechanism the client is using, either:
a. Native IPv6 (unlikely)
b. 6to4
c. Teredo
d. IP-HTTPS
Note. A link local IPv6 address will not work.
2. Ensure the Inside-Out management machine is configured with IPv6 via ISATAP (this could also be native IPv6 but we will assume ISATAP).
If the Inside-Out management machine is not receiving an ISATAP address, check
a. All the ISATAP IP addresses are registered (see point 4 below)
b. That all the ISATAP IP addresses are all in the same subnet, and that the subnet mask allocated is correct
c. That the Intranet firewall is allowing Protocol 41 (See point 5 below)
3. Ensure the Inside-Out management machine has registered its IPv6 address and name in DNS and can be resolved successfully. This will be the machines ISATAP IPv6 address.
If the helpdesk machine does not have an ISATAP address refresh ISATAP (and other) settings from the command line using one of the following commands:
i. SC CONTROL IPHLPSVC PARAMCHANGE
Or
ii. NET STOP IPHLPSVC then NET START IPHLPSVC
4. Ensure the ISATAP router name is resolving to the internal interfaces of the DirectAccess server acting as the ISATAP router from the internal network, or other ISATAP router if you are using one.
a. In a WNLB 2-node array, this would be the 2 x servers dedicated IP addresses plus the virtual IP address, so 3 addresses in total all resolving to the ISATAP name.
5. Ensure that the Intranet Firewall is allowing Protocol 41 (IPv6 encapsulation) to UAG servers in both directions. Do not confuse Protocol 41 with Port 41. IPv6 Encapsulation is a protocol like TCP or UDP, not a Port.
6. Ensure any required client side firewall rules are in place on the remote DirectAccess clients with Edge traversal allowed
a. ICMPv4 for pinging IPv4 addresses
b. ICMPv6 for pinging IPv6 addresses
c. F&P for whichever services you require, such as SMB file share mapping
d. Remote Desktop
e. Etc. Etc.
7. Ensure all the DirectAccess Servers have a valid ISATAP configuration.
a. NETSH INT IPV6
a.1. Find the index number for ISATAP
b. NETSH INT IPV6 SH INT Index#
b.1. Ensure that Forwarding, Advertising and Advertise Default Route, are all enabled
b.2. If not
b.2.1. NETSH INT IPV6 SET INT Index# FORWARDING =EN ADVERTISE=EN ADVERTISEDEFAULTROUTE=EN
b.3. Validate changes
b.3.1. NETSH INT IPV6 SHOW INT Index#
b.4. NET STOP IPHLPSVC
b.5. NET STOP IPHLPSVC
8. Collect some trace logs:
a. NETSH TRACE START SCENARIO=DIRECTACCESS CAPTURE=YES REPORT=YES
b. NET STOP IPHLPSVC
c. NET START IPHLPSVC
d. Wait 10 seconds
e. NETSH TRACE STOP
The logs are called NETTRACE.ETL and NETTRACE.CAB files and will be located in the %TEMP%\NetTraces folder. Either analyse the logs yourself or send them to your support representative.
9. Note. If you want to be able to manage the remote DirectAccess computers even when no one is logged on to them, add the Inside-Out management machines to the management servers group on the DirectAccess servers, where you define Domain Controllers, SCCM and AV machines. Machines defined in these groups can access the client when only the infrastructure tunnel is up, i.e. before the remote user logs on and establishes the Intranet tunnel. If you have been trying to connect to a remote machine that is not logged on, this could be your problem.
Finally, if the troubleshooting steps have still not helped, just be aware of the issue in this knowledge base article, DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010, caused by custom security policies regarding the local security rights for the DirectAccess Manage-Out machine and clients (e.g. modifying the setting "Access this computer from the network").
If you are still having problems you will need to set up network traces from the inside-out management machine, the DirectAccess servers, and the remote DirectAccess client to see where things are going wrong.
HTH.
Colin Brown, Architect.
Microsoft Consulting Services.
One of the hottest topics in IT these days is identity management. Sure, IdM has been important for a long time but with the advent and the acceleration of cloud computing, it’s taken a prominent position on the IT stage. There are a lot of issues that you need to consider with the new computing paradigms that we didn’t have to deal with before. But how do you figure out what’s important and what’s not?
Typically, you’d go do a Bing search and see what’s out there. That’s what I did. The problem I ran into was that there really wasn’t a lot of good information on identity architecture. Most of the information I found was very product specific, so the assumption was that you were already an identity architect and therefore you already knew about foundational issues and essential capabilities. Too bad for me, since I was not an identity architect.
So what was the solution to the problem? Since I work at Microsoft, why not take advantage of the fact that we have some pretty smart people who work as identity architects in Microsoft Consulting Services? That’s what my colleague Gaiana Bagdasaryan and I did – talk to the these architects who have had many years of experience architecting, designing, planning, deploying an operating identity management solutions.
The result of this effort is a collection of two papers:
The Four Pillars of Identity: Identity Management in the Age of Hybrid IT
Identity Infrastructure Capabilities: Identity Management in the Age of Hybrid IT
I think we did pretty good with these papers, at least for a start. But there’s still a lot of work to be done. These are architectural papers, so we tried to keep the amount of product and technology specifics to a minimum and focused on what the problems are and what capabilities are required to solve these problems. We plan to follow up on these by providing more information on Microsoft technologies that can be used to solve many of the problems you’ll encounter when architecting an identity management solution.
Let me know what you think of these papers and please feel free to share any ideas you have on how to make them better and what kind of information you’d like to see moving forward.
HTH,
Tom
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, SCD iX Solutions Group Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Go Social with Private Cloud Architecture! Private Cloud Architecture blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Private Cloud Architecture LinkedIn Group Private Cloud TechNet forums TechNet Private Cloud Solution Hub Private Cloud on the TechNet Wiki
Windows Server 2012 is the greatest operating system Microsoft has ever unleashed on your data center. There are so many new features and capabilities that it would take several books to illuminate them all. And with all that goodness comes a number of new and improved security technologies. This is what the book Windows Server 2012 Security from End to Edge and Beyond written by me, Yuri Diogenes and Debra Littlejohn Shinder is all about.
Why did we pick the name “From End to Edge and Beyond”? The “End” is the endpoint – the client device that connects to server based applications and services and the servers themselves. The “Edge” is the edge of the network, a firewall or a remote access server. And “Beyond” is about the cloud. Windows Server 2012 Security from End to Edge and Beyond addresses all of these issues, security has it applies to the endpoint, network edge and the cloud.
What’s inside? Check this out:
And there’s an added bonus – Tim Rains from the Microsoft Trustworthy Computing Group will be writing a forward for the book! Tim Rains is the Director of Product Management in Microsoft’s Trustworthy Computing group. Tim and his team of product managers support the Microsoft Security Response Center (MSRC), the Microsoft Malware Protection Center (MMPC), and the Microsoft Security Engineering Center (MSEC) which includes the Security Development Lifecycle (SDL) and Security Science. Among other things, Tim’s team manages production of the Microsoft Security Intelligence Report (www.microsoft.com/sir). Tim has worked in several roles at Microsoft including the Senior Public Relations Manager of Security Response at Microsoft, Senior Product Manager of the Microsoft Malware Protection Center, Program Manager of the Windows Network Diagnostics team, Technical Lead on the Security Incident Response team in the Product Support Services (PSS) Security team and Technical Lead on the PSS Windows Server Networking team.
It’s quite a compliment to have Tim endorse our book. Not only will he write a forward for the book, he has made several key suggestions that enhance the overall value of the book to any security minded administrator who needs that extra leg up to secure his data center. Yuri, Debi and I truly appreciate Tim’s insights and we hope you will benefit from Tim’s input into this book.
We just about done with the writing and expect that the book will be available in December or January. Stay tuned!
Hey folks,
You might have noticed that the old Edge Man hasn’t posted for almost a year. The Edge Man blog began as part of my work with UAG DirectAccess. I think we did a lot of great work here and provided some keen value for all of you who were working with UAG DirectAccess and even for those who were using the Windows DirectAccess. For you DirectAccess fans, I can assure you that DirectAccess is alive and well and I think you’ll find some welcome improvements as we move forward to the next version of DirectAccess. If you want to know more about that, then check the TechNet library.
While those were good times, its good to expand one’s horizons and explore new technologies and ways of thinking. I’ve since moved on from the UAG DirectAccess team and now work on the Server and Cloud Information Experience Solutions Group (that’s a mouthful!) Our primary focus is private cloud and you can find the body of our work in the Private Cloud Solutions Hub on TechNet.
My perspective on private cloud is that it provides you an opportunity to start over. I don’t see many people running data centers today who feel that their current datacenter is what they would have built on purpose. There are a number of reasons for this, but due to a confluence of things under their control and not under their control, their datacenters aren’t the well architected, well-designed, smooth running machines that they’d like them to be.
This is where private cloud represents a unique opportunity to start over. The private cloud provides you the chance to start over, to rebuild your datacenter into what you want it to be. And while some say (including myself) that the “cloud” presents a new paradigm for delivering software and services, the fact is that private cloud does all the things our current datacenters do – but does it in a way that enables them to be cheaper (sometimes), faster, more reliable, and better at delivering services to our customers.
So there you have it. The Edge Man has become the Private Cloud Architecture man. Does that mean I’m going to always have my head in the clouds and stick with conceptual stuff? Not likely. I’m doing a lot of work now on the technologies included in the Windows 8 operating system that enable the cloud. I’ll take a lot about those technologies in the future – but if you want an early glimpse of what I’ve been working on, check the TechNet library HERE.
As we move forward, I’ll run fun things like contests, games, and other things that will put some lightening into the cloud! Looking forward to you all joining my on this trek. It’s going to be a wild ride!
Thanks!
Tom Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, SCD iX Solutions Group Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Yuri Diogenes and I have worked together on a number of projects over the years – last year we published three new books on TMG, UAG and Forefront Security for Exchange. You can find more information on these books on Yuri’s blog at http://blogs.technet.com/b/yuridiogenes/archive/2010/07/08/new-forefront-books-by-microsoft-press.aspx
We also worked together on the TMG Firewall Administrator’s Companion which you can find at http://blogs.msdn.com/b/microsoft_press/archive/2009/12/09/forefront-tmg-2010-administrator-s-companion-a-unique-reading-experience-is-coming.aspx
So with four books in the can, where do we go from there? Well, Yuri recently moved from CSS Security to Windows Server iX so we thought “how about we do a security talk show?” Sounded like a good idea to me, and thus Security Talk with Yuri Diogenes and Tom Shinder was born.
Unlike Talk TechNet (http://technet.microsoft.com/en-us/gg558001), Security Talk with Yuri Diogenes and Tom Shinder is like a television talk show – we plan on recording two shows a month and if the thing takes off, we’ll consider doing four shows a month so that you can enjoy the fun once a week.
While the official launch won’t be until after TechEd, we took advantage of the fact that Jim Harrison was in town from Redmond (Yuri and I live in the Dallas/Ft. Worth area in Texas) and did a “practice” session.
Head on over to the Security Talk with Yuri Diogenes and Tom Shinder blog for more information and to view the v0.5 of the program!
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management/ICG 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
Ben Ari posted an answer to the Forwarding on the 6to4 Interface cannot be enabled error that you might see when you try to activate the DirectAccess configuration on the UAG DirectAccess server.
When you activate the configuration, it will look something like this:
Check Ben’s blog post at http://blogs.technet.com/b/ben/archive/2011/01/27/forwarding-on-the-6to4-network-interface-cannot-be-enabled.aspx for the reason and a fix.
Thanks Ben!
The question on how to handle DirectAccess clients and Internet security for those clients is always a popular topic. As I’ve mentioned many times in this blog, the overall threat and management profile of the DirectAccess client should be little different than a client that is on the intranet.
However, there is one major difference between the intranet client and the DirectAccess client – and that’s an Internet gateway that protects the client from Internet threats with URL filtering and web antimalware.
With this in mind, the following question is topical and I’ll use it to drive the discussion.
====================================================================
“UAG providing direct access over HTTPS to a large set of demo computers in retail stores. They are a wireless ISP so all the computers in the offices are connected directly to the Internet, rather than a corporate network. We are using DA to manage group policy on the demo boxes to ensure they are tightly locked down. We have a need to also provide some sort of content filtering/web site blocking on these boxes. One thought is to leverage UAG to act as a filtering proxy server for these boxes. The customer is concerned about using UAG “normally” because traffic would then flow across the DA/HTTPs link which would be the slowest option and may impact the performance of these demo boxes. Thus they would like to configure their UAG box to act as a proxy server out on the Internet with some authentication for clients to connect. So my questions to the group are: Is this totally crazy? Can this be done in a supported way? Is there a better way for them to do this”
“UAG providing direct access over HTTPS to a large set of demo computers in retail stores. They are a wireless ISP so all the computers in the offices are connected directly to the Internet, rather than a corporate network. We are using DA to manage group policy on the demo boxes to ensure they are tightly locked down.
We have a need to also provide some sort of content filtering/web site blocking on these boxes. One thought is to leverage UAG to act as a filtering proxy server for these boxes. The customer is concerned about using UAG “normally” because traffic would then flow across the DA/HTTPs link which would be the slowest option and may impact the performance of these demo boxes. Thus they would like to configure their UAG box to act as a proxy server out on the Internet with some authentication for clients to connect.
So my questions to the group are:
First we have to get clear on the scenario. It sounds like these machines are configured as DirectAccess clients and are configured to use IP-HTTPS to connect to the UAG DirectAccess servers. It’s not clear why this is being used instead of 6to4 – maybe there is a device in the path between these DirectAccess clients that blocks IPv4 Protocol 41. What it appears they want to do is provide some gateway based security for these clients. The proposed idea is to use the UAG DirectAccess server as an outbound proxy for the DirectAccess clients. There are two problems with this possible solution:
Given those two facts, we need to think of some other way to enable Internet gateway security for these clients. This is what I’d propose:
The figure below shows what the request path would look like when you configure the DirectAccess clients to use a Web proxy. Note in this scenario that you can have the outbound connection use a different gateway to the Internet than the one used by the DirectAccess server itself.
The figure below shows what it looks like when you configure the DirectAccess clients to “bounce off” the UAG DirectAccess server. The difference in this case is that the web filtering gateway is most likely going to be in a DMZ. You will need to be careful here, because the DirectAccess server can only have a single default gateway, which means that the web filtering gateway is going to need to be in the DirectAccess request/response path between the DirectAccess client and server. In the figure below, you can see that the outbound connections are leaving through the same firewall that they DirectAccess tunnel connections came in through.
If you want to see how this configuration works in a test lab, then check the Force Tunneling Test Lab Guide. You can find a complete list of Test Lab guides at http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx
If you choose to deploy ISATAP to support your DirectAccess deployment, one of the things you need to do is remove the name ISATAP from the DNS block list if you’re using a Windows DNS server running Windows Server 2003 SP2 or above. By default, these DNS servers will not resolve queries for the names WPAD and ISATAP. Even if there is a resource record for WPAD or ISATAP in DNS, the DNS server will not return a response for those names if they are on the DNS query block list.
The reason for this is that it’s possible for a rogue device to dynamically register these names in DNS. If that happens, there is the possibility that client systems will auto-configure themselves to use the rogue device as their web proxy, or configure their ISATAP adapters to use the rogue device as their ISATAP gateway. Both of these scenarios are enabled by the fact that Internet Explorer uses auto-discovery by default to configure the web proxy, and the ISATAP adapter is enabled by default if the name ISATAP can be resolved and the client can contact an ISATAP router.
If you check this link you will find a document that contains the following statement:
“By default, the DNS Server service in Windows Server 2008 and later blocks name resolution for the name ISATAP through the DNS Global Query Block List. To use ISATAP on your intranet, you must remove the ISATAP name from the list for all DNS servers running Windows Server 2008 and later. For more information, see Remove ISATAP from the DNS Global Query Block List in the DirectAccess Deployment Guide..”
The question then is “if ISATAP responses from the DNS server is considered unsecure, then isn’t deploying ISATAP on the network considered unsecure?”
The answer is “no”. The reason for this is that when you deploy ISATAP on your network and enable the DNS server to answer queries for ISATAP, you will enter a static Host (A) record for ISATAP. When you configure the static DNS resource record, it will not be overwritten by dynamic registrations by potential rogue hosts. Therefore, the security implications of removing ISATAP from the DNS block list are mitigated since no one can dynamically overwrite the static ISATAP record you created.
However, if you decide that you don’t want to use ISATAP, or at least don’t want to use DNS to inform ISATAP hosts of the ISATAP router, then you should put ISATAP back into the DNS block list and remove the ISATAP resource record from your DNS server.
You can find out more about the DNS query block list HERE.
What would you be willing to pay for a really cool IPv6 and DirectAccess troubleshooting cheat sheet?
$5? $10? $100? ONE HUNDRED BILLION DOLLARS?
Since these cheat sheets are priceless we’re going to give them away. Thanks to DirectAccess guru and all around good guy Pat Telford, we’re making the .vsd file for these cheat sheets available for download.
You haven’t seen these cheat sheets? Here’s what they look like:
You can download the .vsd for these sheets HERE.
Your first decision when planning a publishing solution using Forefront TMG 2010 (TMG) or Forefront UAG 2010 (UAG) is to determine which of the two products best fits the needs of the deployment.
Both TMG and UAG can securely publish Exchange, SharePoint, Terminal Services and web-based line of business applications to the Internet. However TMG and UAG offer some features or support some scenarios that the other does not. So, the first step in choosing which product to use is deciding what features you need or think you may need.
Some deployments may actually benefit from using both TMG and UAG to satisfy specific requirements. For example, you might use UAG to provide a unified portal experience for your inbound Web-based client access, use TMG to protect Internet access for your internal users, and use Forefront TMG to provide certificate-based authentication to your mobile device-enabled workforce.
The following table compares both products at a functional level:
Feature or Capability
Forefront Threat Management Gateway 2010
Forefront Unified Access Gateway 2010
Scale Out Using Arrays
Arrays enable you to apply the same configuration setting to multiple machines participating in the same array
X
Network load balancing of the publishing array
Network Load Balancing (NLB) enables high availability and transparent failover for participants in the NLB array
Load Balancing of Back-End Servers
Integrated Web Farm load balancing enables you to load balance connections to back-end web servers, removing the need for a hardware load balancer behind the web gateway
Single network interface deployment
The web gateway can be deployed in a single NIC configuration, so that NICs do not span multiple networks
Enterprise Management (multiple nodes in one array)
Enterprise Management enables the administrator to manage multiple arrays located throughout the organization from a single management interface; in addition, configuration for all arrays is stored in a centralized location which located off any of the array members
Integrated Windows Authentication
Integrated Windows Authentication enables SPNEGO, Kerberos or NTLM authentication with the web gateway
Support two-factor authentication for web applications
Two-factor (multi-factor) authentication enables the administrator to require users to present two or more pieces of information to access resources
Certificate Authentication with ActiveSync
Certificate authentication with ActiveSync increases the overall ActiveSync security scenario by requiring the device to present a certificate before allow access to Exchange Server resources
Upgrade Path from ISA 2006
While it’s not possible to do an in-place upgrade from ISA to TMG (because ISA was 32bit only and TMG is 64bit only), there is a clear and easy to perform upgrade path.
Authorization Using Endpoint Policies
Endpoint detection determines the state of the device connecting to the gateway and enforces access policy based on the results of the endpoint detection
SharePoint rich client support (MSOFBA)
MSOFBA is a protocol that provides forms based authentication, instead of basic authentication, when you use Office client applications
Federation support with ADFS
Use integration support for ADFS to enable federated identity scenarios
Endpoint Session Cleanup
Endpoint session cleanup provides a mechanism to remove information obtained from the server during the course of the session; removal takes place on log off.
Port Scalability
Port scalability enables you to publish more resources while using fewer ports on the receiving interface of the web gateway
Password Lockout Protection (at a node level)
Password lockout protection protects the user account from being inadvertently locked out by either a friendly or malicious user; user is locked out of the gateway, but not in the Active Directory.
Granular access policies
Granular access policies enable the administrator to control access to applications and to components of applications, based on the results of user and device assessments.
Support for DirectAccess
DirectAccess is a new remote access technology that enables users to be always connected to the intranet and enables IT to always be connectivity to the users – all done transparently without user intervention
Portal functionality to publish multiple line-of-business applications
Portal functionality enables users to connect to a single URL to access a portal page that contains applications and services available to the user, based on the results of user and device assessment.
Load balancing support for HTTP-based protocol access from the Internet
Load balancing enables an array of web gateway to handle more requests more efficiently by evenly distributing connections among members of the load balanced array.
Highly Customizable
Customizable according to the support guidelines and the development policies and processes for Microsoft partners
Built-in Wizards for Exchange
Built-in wizard for publishing Exchange web services makes it simple to publish these resources using a secure default configuration
Outlook Web Access “Look and Feel”
Both UAG and TMG provide a log on page experience that is similar to the one provided by Exchange Outlook Web Access (OWA).
Publish Microsoft Office Outlook Web App and the Exchange Control Panel (ECP) using forms-based authentication
Forms based authentication enables users to enter credentials in an easy to use form to authenticate with the web gateway
Publish Outlook Anywhere using Basic or NTLM authentication
Publish Microsoft Exchange ActiveSync using Basic authentication
Support two-factor authentication for Exchange ActiveSync
Provide certificate-based authentication for Exchange ActiveSync, Outlook Web App, and ECP
Perform mail hygiene for Exchange with installation of the Edge Transport server role and Microsoft Forefront Protection 2010 for Exchange Server
Email inspection can be performed on the web gateway to protect against spam and malware
Protect and filter Internet access for internal users from malware and other Web-based threats
The web gateway can perform URL filtering to block undesirable web sites and scan and block malware delivered from the web
Provide support for scaled up Outlook Anywhere deployments by using multiple source IP addresses
UAG has a Port Scalability feature that allows UAG to use multiple source IP address on its internal interface to contact the published CAS servers, allowing it to overcome the limit of 60000 ports maximum in a single IP address.
Check a client computer accessing Outlook Web App for presence of approved antivirus software, updates, etc.
Endpoint detection can be performed to insure that the client attempting to access the OWA Exchange web service meets corporate security standards before allowing access
Built-in features for SharePoint publishing
The web gateway has wizards and other technologies that make intelligent decisions on how to best publish SharePoint resources
Thanks to Fernando Cima and Carsten Kinder for developing this table.
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
There’s a continuing debate in the IT Pro community whether or not you can host quality content on a wiki. If you don’t know what a wiki is, it’s a platform where anyone can post content and then after the content is posted, anyone can edit it.
Seems like a good idea, since IT Pros can share their collective experience and enhance the content – essentially creating a global “brain trust” that enables the possibility of creating the most comprehensive and most accurate content possible.
Of course, there are other perspectives on the intrinsic value of a wiki that let’s everyone edit documents. The following video embodies this sentiment.
Well, regardless of which end of the wiki debate you might find yourself, one thing is clear – there is a ton of great information on the TechNet wiki now, and the amount and the quality of the content continues to grow.
Proof of this comes from the recent posting of the Forefront Threat Management Gateway (TMG) 2010 Troubleshooting Survival Guide. Yuri Diogenes worked day and night, night and day, for weeks to put together this vital resource that is sure to benefit all TMG firewall administrators. You can find the TMG Troubleshooting Survival Guide over at:
http://social.technet.microsoft.com/wiki/contents/articles/forefront-threat-management-gateway-tmg-2010-troubleshooting-survival-guide.aspx
And remember – it’s on the wiki! That means you can add information, correct incorrect information, or even insert comments into the document. Share what you’ve learned about troubleshooting the TMG firewall. We want to you participate because It takes a village to troubleshoot the TMG firewall
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.
Many of your might know my friend Yuri Diogenes from the great work he’s done over the years for ISA Server and the TMG firewall. Yuri has spent the last several years working in the CSS Security Team, and most of his work was focused on Forefront products.
Last Month, Yuri moved from the support organization to the Information Experience (iX) organization (which includes technical writers and advanced technical communicators). Yuri has hit the ground running and I expect that he will have a long and successful career in the iX organization – it’s in his blood!
With that as an introduction, I’d like to let you in on a contest that Yuri is starting in the near future. In this contest you’ll need to be able to answer questions about Forefront products, such as TMG, UAG and Forefront Security for Exchange. But instead of just answering questions, you’ll need to subscribe to Yuri’s twitter feed so that you can *get* the questions! How’s that for sly?
Head on over to Yuri’s blog for more information on the contest – and good luck!
http://blogs.technet.com/b/yuridiogenes/
Yuri Diogenes – Friend of those in the trenches
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…”
“…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”
“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!
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx
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:
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.
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:
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
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.
One of the most mysterious errors you’ll see when working with DirectAccess are related to failures in IP-HTTPS connectivity. I did a blog post on this problem last year and you can find it at http://blogs.technet.com/b/tomshinder/archive/2010/03/30/troubleshooting-the-no-usable-certificate-s-ip-https-client-error.aspx
Phillip Sand clued me into another possible cause of IP-HTTPS connectivity problems. First, whenever you suspect a problem with IP-HTTPS connectivity, you should run the command:
netsh interface httpstunnel show interface
If you see the following:
Role : client URL : https://da.domain.com:443/IPHTTPS Last Error Code : 0x103 Interface Status : no usable certificate(s) found
Where da.domain.com is the FQDN used to connect to the IP-HTTPS listener on the external interface of the UAG DirectAccess server, then you know you have a problem.
In addition to the cause I mentioned in the earlier blog post is a situation related to the CA certificate not being installed in the NTAUTH store of the UAG DirectAccess server. You can find out if the CA certificate is installed by running the command:
certutil –v –store –enterprise ntauth
on the UAG DirectAccess server. If everything is OK, then you’ll see something like what appears in the figure below (this is what you’ll see if you’re using the UAG DirectAccess Test Lab Guide for your UAG DA lab):
If you don’t see any certificate listed, then that can cause the 0x103 error on the client.
You can fix the problem by running the command:
certutil –addstore –enterprise –ntauth IssuingCACert.cer
Where IssusingCACert.cert is the root CA certificate.
Hat tip to Philipp Sand for this great info!
For companies thinking about deploying DirectAccess, the question of whether or not you need to deploy ISATAP will invariably come up. The answer to this question is “no” and the reasons for why you don’t need ISATAP in a DirectAccess deployment are covered in my article over at http://blogs.technet.com/b/tomshinder/archive/2010/10/01/is-isatap-required-for-uag-directaccess.aspx
However, ISATAP does have a place in a DirectAccess deployment, as I discussed in that article. If you don’t have an existing native IPv6 network infrastructure in place, then you might want to consider enabling ISATAP to fully realize the “manage out” capabilities that are part of a comprehensive DirectAccess solution.
However, in all the coverage of ISATAP, I’ve left out some critical information that can help you decide on how you deploy ISATAP in your organization. It’s at this point I get to tell you that the ole “Edge Man’s” favorite food is crow. When I get to eat crow, it means I said something in public and then find out later I was wrong (or at least not entirely right). I like crow because when I eat it, it means that I’ve learned something new.
Now with that are an introduction, let’s get into what led to this “crow eating” session. If you read this blog on a regular basis, you might remember my article on using a HOSTS file entry to control which systems configure themselves as ISATAP hosts. If you didn’t see it you can check it out at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx
In that article, I said:
“In general, ISATAP is a good thing…”
Now that seems like a pretty benign statement, doesn’t it? I thought so. But if you look at the Intra-site Automatic Tunnel Addressing Protocol Deployment Guide at http://www.microsoft.com/downloads/en/details.aspx?familyid=0F3A8868-E337-43D1-B271-B8C8702344CD&displaylang=en you will find the following statement:
“Appropriate Uses for ISATAP on Intranets ISATAP in Windows is not designed for production networks [italics mine]. On a production network, ISATAP should be used in a limited capacity for testing while you deploy native IPv6 capabilities. Microsoft does not recommend the use of ISATAP across entire production networks. Instead, you should deploy native IPv6 routing capability…”
Ah, well, ahem, er, kaff-kaff, aaaa.., that doesn’t really align with my comment regarding “in general, ISATAP is a good thing”.
Let me explain.
To get a better appreciation for the situation, it’s a good start to think about what ISATAP actually does. For most of us, our introduction to ISATAP is with DirectAccess. In fact, for many of us, our introduction to IPv6 is with DirectAccess. When reading about DirectAccess you see that the DirectAccess server is configured as an ISATAP router, as well as a router or relay for Teredo and IP-HTTPS. This gives you the initial impression that ISATAP must be a required component of the UAG DirectAccess solution, and that perhaps it’s a standard for all IPv6 deployments. In truth, ISATAP has limited utility and is designed to support a very specific scenario.
ISATAP is an IPv6 transition technology and is designed as a temporary solution to help you transition your IPv4 network to an IPv6 network. ISATAP enables ISATAP capable hosts to automatically assign an address to an ISATAP adapter, and to communicate with an ISATAP router to get IPv6 routing table information. The purpose of ISATAP then is to provide ISATAP capable hosts with information that enables them to connect to hosts on an IPv6 only network. That connection is made through an ISATAP router.
The ISATAP router has an interface on the IPv4 only network and a second interface on an IPv6 only network. The ISATAP router will take the IPv6 packets that are encapsulated in an IPv4 header, and forward them to the IPv6 only network by removing the IPv4 header before forwarding them. When hosts on the IPv6 only network want to connect to hosts on the IPv4 network, the ISATAP router will receive the packets, put an IPv4 header on them, and forward them to the ISATAP enabled hosts on the IPv4 only network.
When ISATAP enabled hosts on an IPv4 only network communicate with each other, they will preferentially use their ISATAP adapters to communicate. They will query DNS and if they receive both A and AAAA records, they will use the AAAA record’s address and use IPv6 to communicate with the other ISATAP enabled host on the IPv4 only network. This is done because Windows hosts that are capable of using ISATAP (Vista and above, Windows 2008 and above) use IPv6 preferentially. It doesn’t matter that the IPv6 packets are encapsulated with an IPv4 header. Keep in mind that in order to reach the ISATAP adapter on the destination host, the source host also needs the address in the A record to get the IPv4 address of the destination.
In Figure 1, you can see three networks:
When a host on the IPv4 only network wants to connect to a host on the IPv6 only network, it uses routing table entries that indicate that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address ISATAP router. The ISATAP router then removes the IPv4 header to expose the IPv6 header and forwards the IPv6 packet to the host on the IPv6 network.
The UAG DirectAccess server is also configured as an ISATAP router, and it advertises IPv6 routes that ISATAP capable hosts on the IPv4 only network can use to connect to DirectAccess clients. The DirectAccess clients network (which includes network prefixes for the Teredo, 6to4 and IP-HTTPS address spaces) is an IPv6 only network. Therefore, when a host on the IPv4 only network wants to connect to a DirectAccess client, it checks its routing table and finds that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address on the internal interface of the UAG DirectAccess server. The UAG DirectAccess server (acting as an ISATAP router) removes the IPv4 header and forwards the un-encapsulated IPv6 packet to the DirectAccess client.
Figure 1
As you can see, ISATAP is used to enable connections from an IPv4 only network (meaning the routing infrastructure only supports IPv4 routing) to an IPv6 only network (meaning that the routing infrastructure supports IPv6 and the hosts on the network use only IPv6 addressing) by using an ISATAP router. The idea here is that as you transition to an IPv6 network, you will create dedicated segments devoted to IPv6 and that during this transition, you still need to enable connectivity between the “old” IPv4 only network and the “new” IPv6 only network. The transition phase isn’t meant to be indefinite and when the transition phase of the deployment is over, you’ll disable ISATAP in DNS and take down the ISATAP routers.
However, DirectAccess is a special case when it comes to ISATAP and IPv6 enablement. We want you to be able to use DirectAccess now. However, we also realize that very few networks are IPv6-only at this time and that it will take several years before the predominate network protocol is IPv6. To solve this problem, we enabled the UAG DirectAccess server as an ISATAP router. For the UAG DirectAccess server, the purpose is to enable full “manage out” capability, so that management servers on the IPv4 intranet can initiate connections with DirectAccess clients. We don’t need ISATAP to support connections initiated by DirectAccess clients to IPv4 resources on the intranet because we have the NAT64/DNS64 solution.
The “manage out” scenario where management servers on the intranet initiate connections to the DirectAccess clients is a relatively limited one in terms of scope. You won’t have that many management servers that need to be able to do this (although you might want to allow Help Desk to connect to DirectAccess clients over RDP, in which case the number of hosts that need to initiate a “manage out” connection will be larger). Since you know in advance who these machines are, you might want to consider using a HOSTS file entry on these “manage out” machines instead of enabling ISATAP for your entire network using DNS. This gets around problems you might run into if you’ve decided to disable IPv6 on the computers on your network (you can find out the details of this situation in my blog post at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx).
In conclusion, we can reconcile my statement that ISATAP is generally a good thing when we think about the special case of the DirectAccess. However, the purpose of ISATAP in a DirectAccess scenario is a bit different than it is when you’re using ISATAP to transition your intranet to IPv6. Because a limited number of hosts on the intranet need to be IPv6 capable to initiate connections (manage out) DirectAccess clients, there is a good argument for not enabling ISATAP in DNS (it is disabled by default) and only using HOSTS file entries on the machines that require “manage out” capability to DirectAccess clients.
Most of you probably know this, but before I joined Microsoft I spent most of my time with ISA Server and Threat Management Gateway (TMG). A big part of my life was ISAserver.org (www.isaserver.org). My affiliation with ISAserver.org started in mid-2000 and continued uninterrupted until I joined Microsoft in December 2009. However, even after joining Microsoft, I’ve continued to post to the web forums on ISAserver.org because the community for ISA and TMG and UAG is so active there.
The web forums were my favorite experience at ISAserver.org. From those forums I got to know many people, and became friends with a lot of them, over the years. ISAserver.org brought together people from all over world to have professional and interesting discussions about our favorite firewall: ISA Server (now TMG). I can honestly say that my life would have been a poorer experience if I hadn’t participated and met so many great people because of my involvement with the ISAserver.org web forums.
So yesterday was a big day for me – I hit my 50,000th post on the web forums!
It took 10 years to do it, which means I averaged something like 5,000 posts per year. Of course, the number of posts per day was significantly higher in the days of ISA 2000 and ISA 2004 – ISA 2000 was a complete remake of Proxy Server 2.0 and somewhat of a challenge to understand and then when ISA 2004 was released, it represented a major remake of the user interface and required a lot of new learning. It was with the introduction of ISA 2004 that ISA became a true enterprise ready network firewall.
Because something like this only happens once, I decided to do a short movie of the event. If you’d like to watch the momentous occasion, then check out the video below.
Talk TechNet enables you to get your questions about hot technologies answered in real time. In this session, Dr. Tom Shinder will be here to discuss DirectAccess and what Unified Access Gateway 2010 brings to the DirectAccess table. Tom is a Principal Writer in the Anywhere Access Group and is responsible for UAG DirectAccess content and promoting DirectAccess in the community.
Bring your hard questions about IPv6, IPv6 transition technologies, IPsec, Teredo, 6to4, IP-HTTPS, Name Resolution Policy Table (NRPT), CRL checking and more! DirectAccess is wide and deep, so here's you unique opportunity to "stump the chump!"
Presenters: Keith Combs, Senior Program Manager, Microsoft Corporation, Matt Hester, Senior IT Pro Evangelist, Microsoft Corporation, and Dr. Tom Shinder, Principal Technical Writer, Microsoft Corporation
Head on over to:
https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032477770&EventCategory=4&culture=en-US&CountryCode=US
to Register for the event.
I’ll make sure to remind everyone a couple of days before we go live.
A few people have mentioned on the web forums and in email discussions that they’d like an easy way to disable the IP-HTTPS interface on the DirectAccess client for testing purposes. They don’t want to disable it completely for all clients (which you can do through Group Policy), they just want to disable it for a specific client for a short period of time to figure out what the problem might be with something else.
If you open the network shell (netsh) and check the syntax that you should use to disable the IP-HTTPS interface, you’ll see something like the following:
Syntax set interface [[ url= ] ( url )] [[ state= ] ( enabled | disabled | default )] [[authmode= ] ( none | certificates )]
However, if you try it, you’ll see something like this:
What’s up with that?
Apparently, there is a problem with using netsh to disable the IP-HTTPS interface. Therefore, we’re going to have to consider an alternate approach to temporarily disable the IP-HTTPS interface.
To do this, open the Registry Editor and navigate to:
HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition\IPHTTPS\IPHTTPSInterface\IPHTTPS_ClientState
To disable the interface, set the value to 3.
Keep in mind that this setting is controlled through the UAG DirectAccess client Group Policy. When Group Policy is refreshed on the client, this setting will be overwritten and the IP-HTTPS interface will activate again.
An interesting question came up a few weeks ago regarding DirectAccess and expiring computer accounts. I thought it was an topical question that brought up some issues worth exploring, so I’m sharing with you some thoughts on the problem here.
First a little background. UAG DirectAccess (and Windows DirectAccess) enables the DirectAccess client to connect to the intranet through the use of two tunnels:
The infrastructure tunnel enables the DirectAccess client to reach computers on the intranet that are part of an administrator defined “management servers” group. The DirectAccess client uses this tunnel to communicate with domain controllers, update servers and other servers that you’d like the DirectAccess client to be able to connect to before the user logs on.
The intranet tunnel is opened after the user logs onto the DirectAccess client computer. This tunnel enables access to the rest of the intranet.
Both the intranet and the infrastructure tunnels require two forms of authentication to succeed before the tunnels are established.
For the infrastructure tunnel, the DirectAccess client must be able to succeed at:
For the intranet tunnel, the DirectAccess client must be able to succeed at:
Note that in order to perform Kerberos authentication, you need to have connectivity to a domain controller. The domain controller should be reachable through the infrastructure tunnel that was established before the user attempts to log on.
With that understanding in place, you can see if that a computer account had expired for some reason, the infrastructure tunnel could not be created, since it depends on computer account (NTLMv2) authentication. And if you can’t get the first tunnel opened, you can’t get the second tunnel opened (the intranet tunnel), since the Kerberos authentication required for the second tunnel depends on the first tunnel coming up.
So what would happen if a computer account password expired? Nothing. The reason for this is that the computer itself is responsible for changing its password. If the computer is offline for six months and then brought online, nothing bad will happen. The computer will change its password when it starts up. This means that if for some reason a DirectAccess client computer is offline for more than 30 days (the default value for computer account password expiration) there won’t be any problems connecting to the intranet and establishing both of the IPsec tunnels.
For more information on how computers change their computer account passwords, see http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx
However, there is one scenario that might be problematic, and if you manage a DirectAccess deployment, you might want to take this into consideration. Some firms “clean up” their computer accounts on a periodic basis. During the clean-up, they might disable the stale computer accounts, or they might delete them. In this scenario, the DirectAccess client will not be able to establish the infrastructure tunnel and therefore will not be able to establish the intranet tunnel. If the computer account is disabled, it will need to be enabled. If it was deleted, the computer will need to leave the domain and rejoin the domain; this can be done over an SSTP connection.
ISATAP is an optional configuration option you can take advantage of when working with UAG DirectAccess. What ISATAP allows you to do is automatically assign IPv6 addresses to computers on the network that already have IPv4 addresses (which is going to be all of them). The advantage conferred when using ISATAP is that you can have an entirely IPv4 infrastructure (that is to say, your routers don’t support IPv6 and you haven’t done anything to enable IPv6 on your network) is that you can initiate connections from computers on the intranet to DirectAccess clients that are located somewhere on the Internet.
ISATAP clients can do this because they tunnel IPv6 messages inside an IPv4 tunnel. When traveling over the intranet, the IPv6 messages move over the network inside the IPv4 header and when they reach the destination, the IPv4 header is removed and the IPv6 header is exposed and the packet is then received by the ISATAP tunnel adapter. When the ISATAP host connects to a DirectAccess client, it connects to an IPv6 only host (the DirectAccess client), since DirectAccess clients only communicate over IPv6 when connecting to resources on the intranet.
This works by sending the packets from the ISATAP enabled host on the intranet to the ISATAP router on the UAG DirectAccess server. When the ISATAP enabled host on the intranet tries to connect to a DirectAccess client, it sends the IPv4 encapsulated IPv6 packet to the ISATAP router on the UAG DirectAccess server. When the packet arrives at the UAG DirectAccess server, the ISATAP router removes the IPv4 header and forwards the IPv6 packet to the DirectAccess client. And when the DirectAccess client returns its response, the IPv6 packet is sent to the UAG DirectAccess server, and then the ISATAP router on the UAG DirectAccess server encapsulates that IPv6 packet with an IPv4 header and forwards it to the ISATAP host on the intranet.
In general, ISATAP is a good thing, but it can create some potential issues. First, you need to be aware that in order to configure their ISATAP adapters, the ISATAP enabled hosts need to be able to resolve the name ISATAP. Usually, you put a host (A) record for ISATAP in your DNS and all machines can then resolve this name to configure their ISATAP adapters. Since all Vista and above and Windows Server 2008 and above hosts are automatically configured as ISATAP enabled hosts, all of these machines will automatically configure their ISATAP adapters after they resolve the ISATAP name.
The problem is that not everyone wants to enable IPv6 on their networks. For a number of reasons, some firms want to disable IPv6 on the machines on their networks. The problem is that if you disable IPv6, but leave the ISATAP adapter enabled, the NAT64/DNS64 feature won’t work when the DirectAccess clients try to connect to these machines. The reason for this is that when the ISATAP adapter initializes, it registers its IPv6 ISATAP address in DNS automatically. When the DirectAccess client resolves the name of the host that has IPv6 disabled but ISATAP adapter enabled, it will get a quad A (AAAA) record and try to connect to that host using its IPv6 address. But since IPv6 is disabled on that host, the connection attempt will fail.
In practice, very few hosts on the intranet need to be able to initiate connections to the DirectAccess clients. Only management servers, and maybe computers assigned to corporate IT need this kind of access, and perhaps computers run by the Help Desk. If you’ve decided to disable IPv6 on your network, you might be better served by not putting the ISATAP address in DNS. Instead, put the ISATAP entry into the HOSTS file of the machines that need to initiate connections to the DirectAccess clients.
In this case, there is no ISATAP entry in DNS, so hosts without an ISATAP entry in their HOSTS file will not enable their ISATAP adapters. The machines that have an ISATAP entry in their HOSTS files will be able to resolve the name ISATAP and they will enable their ISATAP adapters and they will then be able to initiate connections to DirectAccess clients. With this configuration, the DirectAccess clients can use the UAG DirectAccess server’s NAT64/DNS64 to connect to the hosts that don’t have ISATAP enabled, and they will be able to use IPv6 to connect to the ISATAP enabled hosts that have the ISATAP entry in their HOSTS files.