“Some customers implement ISA Server 2006 Enterprise Edition with NLB and use a virtual name mapped to the virtual IP as proxy server on Internet Explorer. They notice that if they do that the HTTP request that the request sent to the ISA Server 2006 is authenticated using NTLM protocol. This post will explain why this is an expected behavior and how to allow Kerberos authentication while maintaining the NLB configuration.”

Check out the details of this article written by Yuri Diogenes and Jim Harrison and reviewed by Doron Juster at:

https://blogs.technet.com/isablog/archive/2008/06/...b.aspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Join us to learn everything you need to know about remote access and how the Microsoft Intelligent Application Gateway (IAG) provides a highly customizable and easy-to-use solution for secure remote access for all users. We go through key customer scenarios, IAG features and functionality, and the future road map. The IAG product stands out in the single sockets layer (SSL) virtual private network (VPN) market for its focus on strong policy management, end point security, and application optimization.

Presenter: Pradeep Bethi, Technical Solution Professional; Microsoft Corporation

Register and view the recorded Webcast at:

http://msevents.microsoft.com/CUI/WebCastEventDeta...ode=US

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

All ISA Firewall admins will run into problems with their ISA firewalls sooner or later. There are even times when the most experienced of ISA firewall admin just can’t seem to pin down the problem with a particular implementation. In cases like that, you’re going to need to call PSS. While most of us see it as a badge of honor to not have to call PSS, there are times when PSS knows things about the ISA firewall’s internals that outsiders just don’t have access to.

But when calling PSS about your ISA firewall issues, you need to make sure that you’re talking to someone who knows about the ISA firewall. If you don’t, you could end up in more trouble than you started out having in the first place.

Before calling PSS, you should run the ISA firewall Best Practices Analyzer on the ISA firewall. If you have installed the ISA firewall Supportability Update (http://www.microsoft.com/downloads/details.aspx?Fa...ang=en), you’ll see a link in the Troubleshooting node for Use the ISA Server Best Practice Analyzer. Click that link and download an install the BPA, or better, don’t ever click any links on the ISA firewall and download it to a management machine, scan it, and then copy it to the ISA firewall. Download the Best Practices Analyzer at http://www.microsoft.com/downloads/details.aspx?Fa...ang=en 

After installing the BPA, run a general purpose scan of your ISA Firewall. Then run some of the other scans available. Many times just running the ISA Firewall BPA will be enough for you to solve the problem yourself.

However, if you don’t have success in solving your problem using the ISA firewall BPA, then the next step is to run the ISA Server Data Packager tool, which is the IsaDataPackager.exe application in the C:\Program Files\Microsoft IsaBPA folder.

The Data Packager allows you to collect static information and package that, and it also allows you to collect information for common scenarios, such as VPN, firewall policy, Web Publishing and others. The Data Packager will collect configuration information and then do a packet trace as you try to reproduce the problem. After you reproduce the problem you can stop the Data Packager and it will then create a .cab file that you can send to PSS.

When you call PSS, explain the problem and then tell them that you have repro’d the problem and have the .cab file to send to them. If the PSS engineer doesn’t know about the .cab file, ask him to connect you to someone who knows about the ISA firewall, because all PSS staff trained in the ISA firewall are also trained in basic and advanced configuration and interpretation of the information in the Data Packager .cab file. You don’t want to waste hours on the phone or worse, be told to remove the ISA firewall and “see what happens”.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

It’s important that you start with the basics before you begin your work with the ISA firewall. By understanding the basics, you’ll be able to troubleshoot problems that would otherwise be impossible for you to figure out.

Web Publishing Rules are often a point of confusion because the ISA firewall admin doesn’t understand the basics of HTTP and how the ISA firewall manages HTTP connections for Web Publishing Rules. The good news is that Pesach Shelnitz has put together a nice two part article series on how the ISA firewall handles HTTP connections for Web Publishing Rules.

Check out this two part article at:

Another Look at Web Publishing. Part I: Host Headers without SSL

Another Look at Web Publishing. Part II: Host Headers with SSL and Certificates

Great job, Pesach!

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Jason Jones did some excellent sleuthing in figuring out a problem with slow authentication in ISA Firewall Web Publishing Rules. You’ll see this when connecting to a secure Web site and when trying to change your passwords through the FBA.

Check this out at:

http://forums.isaserver.org/m_2002068821/mpage_1/k...069141

and

http://forums.isaserver.org/m_2002027432/mpage_2/k...069093

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

I’ve gone over the differences in Server and Web Publishing Rules and how they behave depending on whether there is a ROUTE or NAT Network Rule connecting the source and destination ISA Firewall Networks. However, when something is worth communicating, its worth communicating over and over and by different authors. This helps get the word out and keeps the issue alive so that we don’t forget how things work and don’t make mistakes in the future.

Philipp Sand, an ISA Firewall support specialist for Microsoft did a great job describing how publishing rules work in ROUTE and NAT relationships. He also provides some nice tips on how to use the command line tool fwengmon to troubleshoot ISA Firewall configuration issues.

Check out Philipp’s article at:

https://blogs.technet.com/isablog/archive/2008/06/...s.aspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

I was recently helping out a client with setting up a new ISA firewall into a Windows Server 2008 domain. Things were going smoothly except for WPAD. We had configured a wpad entry on this client’s DNS server and configured the Web Proxy clients to autodetect their configuration settings. The problem was that the clients were not getting their settings from the ISA firewall.

My first thought was that perhaps there was something wrong with the clients and they weren’t getting the wpad information from the ISA firewall. So we set up a DHCP server with a WPAD entry and tested the clients with that. It worked. So apparently there was nothing wrong with the clients. I then used NetMon 3 to check if the wpad DNS queries were going to the DNS server (I should have done this first instead of messing around with DHCP servers.). The packet trace showed that the DNS queries were going to the DNS server, but the DNS server indicated that it had no records for that wpad.domain.com

We knew that there was a record for WPAD in the DNS server because we created it and saw it there. We even restarted the DNS service. Then bam! It occurred to me — this is a Windows Server 2008 DNS server. Windows Server 2008 DNS servers have a default block list that prevents them from responding to queries for ISATAP and WPAD. You have to configure the Windows Server 2008 DNS server to answer these queries using the dnscmd command line tool.

We got this fixed and the DNS queries for WPAD started working again.

Just another day in the life of an ISA firewall consultant who isn’t used to all the new features in Windows Server 2008

For more information on this, check out:

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

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

There are some things in life that no matter how hard you try to figure out, you can never make sense of them. I ran into one of these issues last weekend when trying to figure out why some people seem to think that a unihomed IAG wouldn’t be as popular as a unihomed ISA Firewall.

I was thinking of conversations I’ve had with the IAG marketing and technical folks and on multiple occasions I’ve asked about support for a unihomed configuration in future versions of the IAG product. I’ve been told that this is an interesting idea, but that there didn’t seem to be much interest in the unihomed configuration and thus they weren’t sure if it was worthwhile to officially support a unihomed IAG. However, this isn’t to say that such support wouldn’t be included, but that no hard and fast decisions have been made in this area.

As you can imagine, I found this to be a jaw-dropping response given my experience with trying to get people to not deploy unihomed ISA firewalls. No interest in the unihomed configuration? How could that be? We’ve been trying to over 8 years to go people to drop the unihomed configuration for the various versions of the ISA Firewall, but I’m sad to say that I suspect that close to, or over, 50% of ISA firewall deployments use the unihomed configuration. This in spite of the fact that we have pushed extraordinarily hard for people to use the full firewall configuration of the ISA firewall for over the years.

What does a unihomed ISA firewall do? Not much. It does forward and reverse Web proxy. Sure, it does add some security to inbound connections, and some to outbound connections if you can prevent users from bypassing the unihomed ISA Firewall since you can’t force it to be in the path (a single NIC prevents you from forcing the unihomed ISA Firewall from being in the path between source and destination). The unihomed ISA firewall does some caching too, as well as SSL termination and initiation.

So, given how popular the unihomed ISA Firewall is, what does the IAG do that the ISA firewall doesn’t do that prevents it from being as popular in a unihomed configuration? As an SSL VPN gateway, the vast majority of the work performed by the IAG is reverse Web proxy. While no caching is done, there is advanced URL inspection as well as advanced authentication support. But for the most part, the IAG is an advanced reverse Web Proxy device, similar to the unihomed ISA Firewall.

Given that multihoming the ISA firewall is often a deployment blocker, why isn’t multihoming the IAG a deployment blocker? Or maybe the IAG people aren’t really attuned to this issue as the ISA firewall people have been over the years, but instead are leveraging the experience of the Whale people, who had the Air Gap or eGap appliances. 

If they had been paying attention to the unihomed ISA firewall experiences over almost the last decade, they would realize that requiring the IAG to be multihomed could represent a deployment blocker in many environments. At the very least, you significantly increase the customer base by enabling the application administrator the ability to introduce a unihomed IAG because the application administrator doesn’t have to deal with the “network guys”, who are often just outsourced Cisco teams who manage the edge router or firewall, and the internal network routers and switches.

It’s our firm opinion here at ISAserver.org that enabling unihomed support for the IAG and its successors will significantly increase the number of people who will deploy the IAG and its successors, and that whatever development and testing efforts that go into unihomed support will more than pay for themselves over the sales lifetime of IAG and future related products.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

In a perfect world where we could deploy least privilege to all communications moving through the Forefront TMG firewall, the TMG firewall would not be a member of the domain, yet we would have all the security features and capabilities that we have with a domain joined TMG firewall. However, that’s not the case now, nor do I believe it will it be the case in the near future, including the RTM release of the Forefront TMG.

So, when deciding about what the more secure solution is, you have to take in account the entire security picture, and then choose the option that affords you the most overall security. You can’t just look at one issue, deem that issue “unsecure” and then ignore the loss of security when you don’t consider the entire list of security features and capabilities when you dismiss a single configuration option as unsecure.

For example, some consider the domain member Forefront TMG firewall to be unsecure. However, that’s because they’re looking at only a single factor. If the “expert” who made this offhand assessment were to assess the entire security configuration, he might decide that domain membership is actually an overall more secure configuration.

Consider the following information in the Forefront TMG Help File that can be found at http://technet.microsoft.com/en-us/library/cc44166...).aspx  :

• When access rules require internal clients to authenticate for outbound access, Forefront TMG can authenticate domain user accounts against an Active Directory directory service domain controller. Web proxy requests in a workgroup environment can be authenticated against a RADIUS server.
• Firewall client requests automatically include user credentials. To authenticate these requests, Forefront TMG should belong to a domain. In a workgroup environment, you can authenticate requests with user accounts that are mirrored to accounts stored in the local Security Accounts Manager (SAM) on the Forefront TMG server, but this requires some administrative overhead for secure management.
• To authenticate inbound requests to internal Web servers using domain account credentials or certificate authentication, Forefront TMG must belong to a domain. In a workgroup environment, a RADIUS or SecurID server can be used for authentication.
• To authenticate virtual private network (VPN) requests using domain account credentials or certificates, Forefront TMG must belong to a domain. In a workgroup environment, a RADIUS server can be used for authentication.
• You can configure VPN client user mapping to map users of operating systems other than Microsoft Windows to domain user accounts. User mapping is only supported when Forefront TMG is installed in a domain.
• In a domain, you can lock down the Forefront TMG server using Group Policy, rather than by configuring only a local policy.
• In a domain environment, if Active Directory is compromised, for example by an internal attack, the firewall can also be compromised, because a user with Domain Administrator rights can administer every domain member, including the server running Forefront TMG. Similarly if the firewall is compromised, the domain in which Forefront TMG is located is also at risk. By default, the Domain Admins group is in the Administrators group on the Forefront TMG server.

Regarding the last issue, I would consider the fact that the firewall might be compromised by a compromised domain or enterprise admin account to be the least of my problems should such an event occur. But then again, I have to remain true to least privilege and admit that this does add to the problems of a compromised domain admit account.

However, when looking over the list from the Help file, you can see that domain membership confers a significant amount of security that would be lost, or more difficult to maintain, if the TMG firewall were not a domain member.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Jim Harrison pointed out today that your ISA or Forefront TMG firewall performs only as well as the operating system that it runs on. To that end, Jim Harrison points out that Microsoft provides a valuable tool that you can use to determine a variety of performance issues in Windows.

Check it out at:

https://www.microsoft.com/downloads/details.aspx?F...ang=en

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)