Lessons Learned

I ran into an interesting one today that I had not seen before. A client installed ISA 2004 on his SBS 2003 server, and we followed the best practices for doing so. After an hour or so, he called me back because he could no longer check e-mail with Outlook. I had assumed (incorrectly, of course) that when he mentioned still using POP3 to get e-mail because he hasn’t switched over to SMTP delivery yet, that he was referring to the POP3 Connector in SBS. In fact, he was still having the workstations pull down e-mail from the external server using a POP3 account in Outlook, then saving the new mail into the Exchange profile. And Outlook could not connect to the POP3 server.

We had already installed the firewall client, so I knew it wasn’t an issue with not having the client installed. I ran a monitoring scan in ISA, and saw the connections from the workstation getting denied by the SBS Internet Access rule. I checked that the Internet Users security group got created during the ISA installation, and I checked that all the users had been added to the Internet Users security group. I checked that the SBS Internet Access rule was built as it was supposed to be. All these things checked out.

I connected to the workstation and ran a manual telnet to port 110 on the POP server expecting the connection to be refused. It wasn’t. It worked as expected.

Google to the rescue again. I found this article on isaserver.org that pointed out the default configuration of the ISA firewall client in ISA 2004 is to ignore connections from outlook.exe. When this happens, ISA will treat connections from the workstation as a SecureNAT client when the connection comes from Outlook, and that is specifically denied by the SBS rules.

The workaround in the article is to change the default settings for the firewall client in the ISA Management Console so that the Firewall Client will take connections from outlook.exe and pass them through ISA as a firewall client and not a SecureNAT client, and this change allowed the workstation to pull e-mail down from the remote mail server as it had before ISA was installed.

Long term, the my client will be moving to direct SMTP delivery of e-mail. Near term, he will be configuring the POP3 connector to pull mail into Exchange instead. But it was the first time I’d worked with a setup where Outlook on the client was pulling e-mail from a remote POP mail server behind an ISA server, and it caught me by surprise. Hopefully this post will help someone else in this situation find the solution a little quicker.

There are a couple of connectivity issues related to using a Macintosh in a Windows network that are worth noting. These can impact connectivity of both Mac OS 10.4 and 10.5 in an SBS (or other Active Directory network).

First, if the Active Directory login name matches either the Full Name or shortname of a local Macintosh account, you will not be able to authenticate against active directory. What seems to be happening in this instance is that the Mac OS authentication mechanism looks first at the local user directory before looking at any remote user directories when attempting authentication. If the name entered at login matches an accoun in the local user directory, Mac OS will attempt to authenticate against that user instead of the account in the remote user directory. This means an AD account named “jane” will not authenticate against AD if there is a local account with the shortname “jane” or the long name “Jane Dough.” Even if the shortname for “Jane Dough” is “admin,” the authentication will fail.

To resolve this issue, first create another local Mac user account with a long name and short name that have no close matches to any account in Active Directory. Make that user an administrator over the local machine. Then log in with that new user and remove any local accounts with names similar to the AD login name. If the user has been using that local account for a while, you will need to take steps to move the local user profile information into another account, which is not a trivial task. Only after you delete the local account with a similar name to the AD account will you be able to authenticate against the AD account. This happens whether you join the Mac to Active Directory or not.

Second, I have seen two instances where joining a fresh Leopard (10.5) install to an SBS network have been problematic. Specifically, when you log in with AD credentials, the process can take 5 or more minutes to process the login. Unfortunately, I have not been able to troubleshoot these two instances the way I had wanted, and I have not been able to replicate the behavior on demand. I believe that there is an issue/delay with the Mac doing LDAP lookups in AD to get the account information for authentication, but I cannot be sure withouth further testing.

If anyone has seen this problem and is willing to work with me to do some more in-depth troubleshooting on the problem, please let me know. Given the number of systems that I’ve connected and that have been done following the instructions on this blog and the smallbizserver.net site, this specific behavior is very rare. But now that I’ve seen it twice, I’d like to know what’s going on and modify these instructions as needed to help prevent that problem in the future.