1. Site Updates

By Stephen Chetcuti

After weeks of development, ISAserver.org has been relaunched together with MSExchange.org, now providing the most updated and regular articles for Microsoft ISA Server and Exchange Server. Apart from their new look, we've added a number of new features and sections including;

• New site search engine; search through hundreds of articles and FAQs for the answers you need!
• Updated software section; vote and post comments on your experiences with 3rd party software
• Printable articles; print hard copies of any of our articles!

More features in store such as 'New tutorial automatic email notifications', a weekly 'Questions of the week' newsletter from Tom and more!

Also check out our newly launched WindowSecurity.com, providing Windows security news, articles, tutorials, software listings, reviews and more for information security professionals.

2. New ISA Server Book In Progress

3. ISA Server Tips and Tricks

By Thomas W Shinder, M.D., MCSE, etc.

This month I'll share with you a few tips and tricks I've learned while walking the path ISA Server had set for me.

1. Make Norton Antivirus AutoUpdate Work
   
2. Don't Loopback Through the ISA Server!
   
3. Allowing Outbound PING (and other ICMP messages)
   

1. Make Norton Antivirus AutoUpdate Work

Something that had been bothering me for a long time were problems with getting Norton Antivirus 2002 automatic update to work with ISA Server. I tried several things to get it to work, but nothing. Whenever I can't figure something out, I attribute the problem to gremlins, and leave it alone until someone smarter than me comes up with an answer.

As always, my wish came true. We have a lot of sharp guys and gals on the ISAserver.org Web boards and mailing list. If you're not a member, be sure to sign up over at www.ISAserver.org. The answer to the Norton Antivirus problem came from Dave Merrick. Dave wrote on the mailing list an answer to the problem that was so simple, I am embarrassed that I didn't figure it out for myself!

Turns out the problem I had (as well as everyone else) is related to access controls. On my own network, I have pretty loose outbound access controls and allow the approved protocols (which don't include Morpheus and Kaaza) to all authenticated users. Norton Antivirus was configured either with a system account on the local workstation, or the local administrator's account. The account is used by the schedule service for the scheduled event used by the automatic update feature. Once I changed the account to a valid domain account (one that I created specifically for NAV), the AutoUpdate feature worked fine.

Here's how you fix the NAV problem (on an XP machine; should be similar on Win2k):

1. Click Start and point to Programs. Point to Accessories and then point to System Tools. Click on Scheduled Tasks
2. Right click on Symantec NetDetect and click Properties.
3. On the Task tab, type in DOMAINNAME\username in the Run as text box. Click the Set password button and type in the password for that user account and confirm the password. Click OK and then click OK again.

That's it! AutoUpdate will now work like it used to. Cool!

2. Don't Loopback Through the ISA Server!

Every day, and I mean every day, we get questions from ISA Server admins about problems they have connecting to their published sites. In the great majority of cases, the problem is they are trying to access sites from an internal network client by "looping back" through the external interface of the ISA Server. Jim Harrison has a great name for this: Isotropic Bounce. Although I have to admit that I'm not sure if we're dealing with Isotropy or Entropy.

What happens is that the internal network SecureNAT client sends the request to the ISA Server. The ISA Server dutifully forwards the request to the published server on the internal network. The published server receives the request that was forwarded by the ISA Server. The published server also receives the source IP address of the internal network host, which was included in the forwarded request. The published server answers the internal network SecureNAT client directly. The problem is that the SecureNAT client is expected an answer from the ISA Server, not from the published server, so the answer from the published is ignored.

Other problems crop up with Firewall clients. But I'm not going to tell you the whole story here! You'll have to attend my talk at next month's Microsoft TechEd on "Troubleshooting ISA Server Clients". I'll have a whole bunch of super secret, but super useful, stuff for you on fixing ISA Server client related problems. Hope to see you there!

Moral of the story: Always test your publishing rules from an EXTERNAL network client.

3. Allowing Outbound PING (and other ICMP messages)

OK everyone. Here's what's required to allow outbound ICMP messages (such as PING and TRACERT):

1. The client must be configured as a SecureNAT client
2. IP Routing must be enabled on the ISA Server
3. The default packet filters, created during ISA Server installation, must be in place. Actually, not all the packet filters need to be in place, just the one that allows outbound ICMP.

There are no secrets, no other "tricky" configuration issues you need to handle. If you can't ping out from an internal network client, there's something going on with your ISP, or perhaps you have some other issues going on with your connection. I know it works with dial-up analog modems, ISDN dial-up adapters, and T carrier connections. I've not had the pleasure of working with xDSL and Cable connections myself, so if anyone out there with these types of connections is having problems, let me know at tshinder@ISAserver.org

4. ISAserver.org Learning Zone articles of Interest

We have a great group of articles in the Learning Zone that will help you get a handle on your most difficult configuration issues. Here are just a few of the newer articles:

• TZO Packet Filters
  http://www.ISAserver.org/pages/articles.asp?art=348
• VPN Client Security Issues
  http://www.ISAserver.org/pages/articles.asp?art=325
• Configuring ISA Server Arrays
  http://www.ISAserver.org/pages/articles.asp?art=332
• Using the Exchange RPC Filter to Publish Microsoft Exchange
  http://www.ISAserver.org/pages/articles.asp?art=327
• Microsoft ISA Server, Part I - introduction, installation, configuration, Web caching and Internet access
  http://www.ISAserver.org/pages/articles.asp?art=360

5. Q Articles of the Month

Just copy and paste the line under the title into your browser and Go!

• How to Obtain the Latest Internet Security and Acceleration Server 2000 Service Pack
  Q313139
• FIX: Problems with Web Browser if ISA Server 2000 Is Chained to an Upstream Web Proxy Server
  Q317822
• Domain Name Is Not Logged When You Are Using Basic Authentication
  Q313462
• Web Proxy Sends TCP Reset Instead of Only Closing Session
  Q317122
• XCCC: How to Configure Exchange 2000 Conferencing Server and ISA Server to Allow Audio and Video
  Q303098
  
  

6. Mailing List Post of the Month

Shawn Quillman answers a question on ISA implementation planning. Shawn shows he really knows his stuff in this mailing list post!

You're doing essentially what we've done here. For the AD question, there's no getting around it. Array configurations are stored in AD which means if you want arrays you have to have AD. If you want to run / get used to ISA before you have your directory set up then install it in standalone mode and then migrate it to an array.

You can also do funky things with Proxy Autoconfiguration (PAC) files that simulate load balancing if you need to run ISA prior to getting your AD functioning. I wrote an ASP that generates our .pac file. It determines randomly which of our 2 ISA's gets listed first in the return list. I couldn't put them in an array because the servers are in different AD sites, but I still want them as redundant as possible. Can't have an array with servers from different sites. One of these days I'll put a load-balancer in.

Here are the steps I did to migrate from our UNIX-based Netscape proxy with a separate account database to ISA. Make sure you have the necessary permissions to do things, it'll save you tons of time. If you have multiple AD domains in your organization and you want ISA enterprise admins in the different domains they need to be part of a universal group. Domain local groups didn't cut it.

1. Get AD set up and run the enterprise initialization (extends the AD schema for ISA).
2. Set up global groups in AD for ISA permissions. These are the groups that user accounts go into for access through ISA.
3. Exported the list of user accounts from my Netscape directory and get them matched to NT user accounts. If you're smarter than we were your proxy account names match your Windows account names. When I got an acceptible list of Windows usernames that should have access I imported them into the permission groups. I wrote scripts and VB programs for this since we've got a couple thousand users at my location.
4. Install and configure ISA. Test with a pilot group of 15 or so people. If you're going to authenticate through ISA you have to use Basic (plaintext) authentication for Netscape. You can use NTLM for IE. Netscape will always prompt for authentication, IE can pull it from the desktop environment.
5. Migrate users. I'm running ISA in cache mode so we only had to reconfigure browsers (plus a couple of misc. apps on a case-by-case basis). We only support IE and Netscape. IE we reconfigured with a reg file run in the login script. Netscape we reconfigured with a Perl script that modified the prefs.js file and ran in the login script. Bummer if you don't have a standard folder path for Netscape prefs...
6. Make sure users know to use their Windows network ID :) Some of the people here failed to be informed of this... Grrr. Windows accounts will get locked out after proxy authentication failures just like any other failure. Go back into User Manager / AD Users and Computers and unlock the account.

Our migration actually went very smoothly. We've been using the same process for all of our (15 or so) locations around North America (one at a time). I had to skip the pilot phase because the MS Proxy that our other firewall location had ate itself. There's a DNS issue I found where ISA tries to resolve Internet names instead of just forwarding the request right to the firewall. There was a hotfix for that which is included with ISA SP1. That was about the only thing I think.

Good luck!

-Shawn 

7. Web Boards Post of the Month**

Having Problems with Frontpage or WebDAV? Try this tip from Giles:

Applying SP1 is not enough, you have to manually add the following registry key:

HKLM\System\CurrentControlSet\Services\W3Proxy\Parameters

Value Name: PassOPTIONSToPublishedServer
Data Type : REG_DWORD
Data : 1
Default : 0

Set this parameter to 1. The data can be any non-zero value.

This is described in Q304340 of MS Knowledge Base. Stop and restart the W3Proxy service.

Simply applying SP1 does not fix the problem. After that it works

8. ISA Server Link of the Week

ISA Server Service Pack 1 is available and its required that you install it! Microsoft does not support pre-SP1 machines, and neither do I! Check out this site for download and installation instructions. Pay special attention to the Firewall client installation instructions. You should update the Firewall client on the client machines after installing SP1.

http://www.microsoft.com/isaserver/downloads/sp1.asp

9. Ask Dr. Tom

QUESTION:
This question comes from Pete:
When internal clients are registered with the gatekeeper, external users can contact those internal users by 'dialing' the phone number which the internal user has entered under the gatekeeper settings in NetMeeting (the gatekeeper matches the phone number to the right internal client). When registering with an ILS server, the phone number option is grayed out and I presume not registered with the ILS server at all. How does it work when an external user wants to contact an internal user? I presume they still use a gateway setting and phone number? Does the phone number have to match the internal user's entry in the Active Directory database? Just to be clear, I don't want to make the internal ILS server available to external clients. Internal clients will only call genuine Internet clients by entering their Internet hostname or Internet IP address (we haven't had the requirement yet to call users on another LAN)

Answer:
Hi Pete - You are correct about the configuration of the NetMeeting client application when you use the H.323 Gatekeeper. The NetMeeting client is configured with a phone number and the address of the Gatekeeper. After making these changes, the NetMeeting client registers its address with the H.323 Gatekeeper and external network users can call the user via the phone number the client registered with the Gatekeeper. This works very well and requires little configuration expertise! Even my mother who can hardly start the computer is able to make the simple configuration changes in NetMeeting.

Thing are different when you have internal network client use an internal ILS Server. The clients do not register phone number with the ILS server. Instead of phone numbers, the clients register the user name configured in NetMeeting. One advantage of using an ILS server is that you can search the list of user names in the ILS database. The H.323 Gatekeeper does not have a facility that allows users to search the registration database; you MUST know the phone number of the person that you're calling.

You won't be able to register with both an internal ILS Server and the H.323 Gatekeeper at the same time. Your best option is to publish your ILS Server and allow external networking client to call internal network clients if you want to use the ILS Server. However, I recommend that you do not use an ILS Server, and have all clients register with the H.323 Gatekeeper. If you organization plans to fully implement H.323, you can create a H.323 phonebook in the same way that you create your telco phone book.

QUESTION:
This question comes from Randy Platt:
I'm working with a network that needs all clients to connect to a secure web site but can't. When you follow the hyperlinks to https://yadda.yadda.org:18888/ the status indicator says "Done" but no page or error is displayed. The security certificate is installed at the client. Port 18888 has been opened to the server through the DSL router and you can connect to the site at the server. What needs to be done to let the server pass everything through?

Answer:
Hi Randy - Right out of the box, ISA Server support SSL tunneling on TCP port 443 and 563. It sounds like you need to allow SSL tunneling for 18888. In order to do this, you need to implement the script included with Q283284. Remember that when you run the script that you don't break the line like they did in the Q article.

10. ISA Server Guru of the Month - Stefaan Pouseele

This month's ISA Server Guru is Stefaan Pouseele. Stephen has been a key contributor on the ISAserver.org messages boards. His insights into fitting ISA Server into complex network configuration have been top notch! Stefaan is from Gent, Belgium, thus adding to our international crew of ISA Server gurus! Stefaan's contributions to the Web boards and mailing list have been over and above the call of service, and for this reason we award him the coveted ISAserver.org Guru of the Month Award.

Copyright(c) ISAserver.org.org August 2002 - All Rights Reserved Disclaimer: We are not responsible for anything good or bad that might happen to your systems based on the advise given herein. You must test and retest the configuration options suggested in this newsletter and validate and confirm for yourself that they work as you intend.