Ask Us About... Security, July 2000

by Joel Scambray

July 2000

The AUAS mailbox was humming this month. I'll do my best to answer as many question as possible in this column. Apologies to those I can't get to – I need to sleep sometime! For those that I address this time around, I hope you can recognize your original queries – I try to edit them for brevity and clarity so that the questions don't take up more room than the answers. I have not printed names to protect the privacy of those who write in to the mailbox.

On This Page

Setting up Exchange on the Internet

Setting up Exchange on the Internet

Q: We are planning a co-located Internet site housing an Exchange 5.5

server (which has IIS installed on it). How do I protect Exchange from the Internet?

A: I have a two part answer for you. One, don't install your mail server on a web server. Minimalism is one of the primary tenets of security – the more complex the system, the more likely that someone will find a hole. With the growing number of Web applications that are being broken into lately, you don't need the added risk of the mail server becoming compromised as well, or vice-versa the IIS server.

Two, protecting a mail server on the Internet has traditionally involved setting up appropriate network access controls using an external firewall, or with built-in operating system features. I recommend using both for defense in-depth.

For SMTP (server-to-server sending and receiving) and POP3 (client-side mail download), this is fairly straightforward: allow only TCP ports 25 (SMTP) for, and 110 (POP3) inbound to the server. SMTP will also have to be permitted outbound.

If you are using Exchange mail and collaboration features, things get a little trickier. You must first enable access to TCP port 135 (the Remote Procedure Call locator service) on the Exchange Server. By default, the locator service allocates two random ports for communication with the Exchange Directory and the Information Store (DS and IS, respectively). This can make it difficult to create an appropriate access control rule for the dynamic DS and IS ports. However, you can configure Exchange to use fixed port numbers. The appropriate Registry keys to adjust are:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDS\Parameters \TCP/IP Port

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\Parameters \TCP/IP Port

Knowledge Base Article 155831 https://support.microsoft.com/default.aspx?kbid=155831 details these steps. Now an appropriate access control rule can be created around the two manually defined ports.

See Knowledge Base Article 176466 https://support.microsoft.com/default.aspx?kbid=176466 for alternative configurations, including access to IMAP, LDAP, NNTP, X.400, and SSL-ized protocols. Thanks to my colleague Eric Schultze at Foundstone for pointing these resources out to me.

More IIS Authentication Blues

Q: What user authentication options do I have when configuring Internet Information Server 5?

A: IIS 5 introduces a new authentication mechanism, Digest Authentication (per RFC RFC2069 https://www.ietf.org/rfc/rfc2069.txt?number=2069). This amplifies the four other mechanisms already in place. The following table from the Windows 2000 Resource Kit summarizes the available options:

Web Authentication Schemes in IIS 5.0

Anonymous, Basic, and Integrated Windows (formerly NTLM) authentication can all be configured via the Internet Information Services MMC snap-in by selecting the object that requires authentication (e.g. the Default Web Site), Properties, Directory Security, Anonymous Access and Authentication Control Edit… button.

Digest authentication is configured in the same place, but three requirements must be met (per the Windows 2000 Resource kit):

• The Windows 2000 Server must be in a domain.

• A file called IISUBA.DLL must be installed on the domain controller. This is copied automatically during Windows 2000 Server setup.

• All user accounts must be configured to have the Save password as encrypted clear text option enabled, as shown in the first figure below. This is an option on each user object in the Active Directory. Setting this option requires the password to be reset or re-entered.

Using certificate authentication requires you to map a certificate from a trusted certificate authority (CA) to a Windows user account. This can be done in one of two ways:

1. Using Microsoft Active Directory Users and Computers

2. Native IIS 5.0 mapping

Time and space prevent a more detailed explanation of each of these here, but consult the Resource kit for step-by step configuration info.

Q: In most security documentation I see from Microsoft, it is recommended that normal

users not be allowed to interactively log onto domain controllers, web servers, and other security-critical machines. However, IIS users authenticated via NTLM must have local logon rights, as far as I know. How does this fit into the "normal security recommendations" model and what are the security ramifications of such a configuration?

A: According to all of the official documentation I've read, an account with "Log on locally" is required for any access to IIS. The implications of this are what you'd expect: a user with Log on locally rights could access the server if they were physically at the console, or they could conceivably execute code with those privileges (this would be impersonated by IIS). You can still work within the bounds of the security recommendations by physically protecting the server, though. If normal users can't access the keyboard, they can't log in, even if they have "log on locally" permissions.

Q: Is there a way to configure an ISAPI application (i.e. ASP pages) to require a user to authenticate each session when logging on to a application? Our concern is that some of our systems are setup for multiple users to use. We would prefer a serve-side solution so that we don't have to trust unreliable client configurations.

A: I have two suggestions. First, to gain some more control over your users' desktops, look into the Internet Explorer Administration Kit (IEAK) https://www.microsoft.com/technet/prodtechnol/ie/ieak/default.mspx. You can use this to automatically maintain IE configurations simply by pointing everyone's browser at a centrally maintained configuration file.

To address the server side, you could set up authentication to IIS as discussed above. This will force uses to authenticate upon the first access to any file under the root. I also recommend checking out KB 196074 https://support.microsoft.com/default.aspx?kbid=196074 which illustrates a sample ASP include script file that can trap the current authenticated session in a variable called LOGON_USER. The script checks this variable and returns an HTTP 401 (Access Denied) error message if it is empty. The 401 message signals the client to resubmit the request using authentication. Thus any request for a page that calls the 401LogonUser.inc script will prompt the user for authentication.

This article also shows how to code your individual ASP pages to force authentication at specified junctures by abandoning sessions manually, or when a specified timeout is reached. This would seem to address the situation where you want to prevent multiple users of the same computer from hijacking each other's sessions.

Two caveats: it is recommended that you use a secure Web authentication protocol with this setup. Secondly, you should note, that this solution does not purge the client-side cache, it only forces them to re-authenticate whenever the browser is re-launched (i.e. a new session is started, per your requirements). The user is still not prompted for a user name and password for each individual HTTP request, however. Rather, this will happen only when the cached credentials do not have sufficient permissions to access a specific page or file. So, you should still admonish users to close all browser sessions before abandoning the machine!!!

You should also configure Audit settings appropriately so that failed login attempts can be harvested for later analysis.

NTFS versus Share-level file system permissions

Q: Does Microsoft recommend share-level security over NTFS permissions in a multi-domain environment? Which is more secure and easy to administer?

A: I've seen experienced Windows administrators make this semantic error (including myself) so often, I had to pull this one from the mailbag and answer it. You really can't pick one or the other – file system permissions in Windows NT or 2000 result from the intersection of both share-level and NTFS access control lists (ACLs). In other words, the most restrictive effective rights are distilled from the combination of both the share and NTFS settings. Typically what this means is that one is set to the most liberal access possible, and then the other is used to determine actual permissions on a given file or directory.

Microsoft (and I, coincidentally) recommend using NTFS permissions wherever possible. It offers more granularity in assigning permissions, and it also works from the perspective of the local user as well as over the network. Thus, whether a user is logged in at the local console or browsing a directory over the network, security is enforced.

To set up NTFS share permissions in a multi-domain environment, simply share out the drive or folder you want, and then configure the NTFS permissions. By default, both share-level access and NTFS permissions are set to Everyone:Full Control, so all you have to do is change the NTFS permissions and you're done. Need I advise anyone to set it to something other then Everyone:Full Control?

Phew! It's the simple questions that challenge you to think the most. Keep 'em pouring in, and I'll do my best to get to them next time we take a spin around security.

Joel Scambray is a Principal of Foundstone https://www.foundstone.com/. He is co-author of Hacking Exposed: Network Security Secrets & Solutionshttps://www.hackingexposed.com/, from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox TechNet_AskUs_Security@css.one.microsoft.com. If your question is selected, you will see your answer in a forthcoming column.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.