[Copyright Information] [Table of Contents] [Que Home Page]
[Prev Chapter] [Next Chapter]

07 - Maintaining an Information Repository with FTP

In the last chapter, you saw how to implement your server, bringing up support for the different services that are part of the IIS product. In this chapter, you're going to start setting up an FTP site-one that is both manageable and usable, both protected and accessible. These seem like divergent goals, but they will need to work in parallel in your implementation.

When you bring up an FTP site, you're offering some pretty hard-core access to your server. You're also allowing people to upload and download files to and from your system. These are important capabilities, but they also bring with them some significant responsibilities and concerns about how you keep track of what's happening.

Before you start, be sure you have a profile of your different types of users. Users of your FTP site will probably fall into one or more of the following categories:


You'll find more specific information about implementing each of these different levels of security, along with any special precautions that may apply, in the later sections that follow in this chapter.

You'll want to have a good idea in your mind's eye of the different types of access you'd like to provide to these users. You won't have to know specifics for the examples in this chapter, but you will want to be able to apply the information as you go to your unique implementation.

How Does FTP Work?

File Transfer Protocol, or FTP, provides a way to transfer binary files over the network. In a situation such as an Intranet, this may seem a bit like a moot issue, as you can simply share a network drive and then allow people to attach to it and get copies of their files in that manner.

While it's true that you can use the network sharing approach, there may be cases where you need to have a server providing only Intranet capabilities, not the ability to share directly to it. This may be the case when you want to provide concurrent access to the information over the Internet and your internal network, or when you need to have someone administer a site who is not a network administrator.

At first glance, you'll probably wonder why you'd implement an FTP server on an internal network situation. This is a great question, and there are several different reasons you may want to bring up this type of server.

There are certainly cases where, depending on how you implement links between objects on your site, you'll probably have both network shares and FTP virtual directories. Also, perhaps the biggest benefit is the one offered earlier, that of remote access to the information on your server. If you have an Internet/Intranet shared server, you can provide secure access to information to people who may be on the road or on a remote WAN connection.

In the coming sections, you'll see exactly how to set up these types of connections and what considerations you'll need to keep in mind as you do. You'll see several examples of how to implement scenarios that may be similar to the types of things you're trying to do with your site. Keep in mind that these are examples only, and that you'll likely begin taking pieces from each sample implementation to build the solution to your specific requirements.

Setting Up an FTP Site

As you've probably determined by now, installing the FTP service and getting it running is only the first step in making responsible FTP services available on your network. The term "responsible" may seem strange here, but it's important to understand that providing general read/write file access on your server is not the best solution for your users. If a system is too open, it lends itself to tampering, and once an altered file makes its way into your archives, you run the risk of users losing confidence in your site. Lost confidence means lost users, and if people aren't accessing your site, why have it in the first place? The responsibility that you have as site administrator is to take every reasonable precaution to provide reliable access to information for your users.

Enable Logging

The first step in maintaining informational control over your site is to enable the logging options within the FTP service. As shown in Figure 7.1, you have two options: logging to a text file or logging to an ODBC data source.

Fig. 7.1 - You should always enable logging for your FTP site. It's the most basic of measures for troubleshooting both security and system problems.

When you log to a text file, the file contains a number of useful elements that will help you determine what information is being retrieved, what information is being uploaded to your server, and what (if any) problems are being encountered. FTP logging is a bit different compared to Web browser logging. Since FTP sessions are held open until the user logs off, you can follow a session and see exactly what was done from start to finish while the user was logged on, even if the user logged on anonymously.

When you enable logging, you'll be able to see the following information for each access to your server:

Any item that could not be determined or is not applicable will have a dash in the place of values for that column.

For example, by connecting to the //HOLODECK3 site and reviewing several files on line, the log entries in table 7.1 were created, showing the access and details surrounding it.

Table 7.1 - Example user log for an FTP session
Client IP Client Name Date Time Service Svr Name IP Proc time Rec Sent St NT Operation Parameters/ Target
198.68.42.72 anonymous 4/8/96 0:07:25 MSFTPSVC HOLODECK3 - 0 16 0 0 0 [1] USER anonymous
198.68.42.72 WWWuser@ 4/8/96 0:07:26 MSFTPSVC HOLODECK3 - 731 15 0 0 0 [1] PASS WWWuser@
198.68.42.72 WWWuser@ 4/8/96 0:07:26 MSFTPSVC HOLODECK3 - 10 22 0 0 2 [1] sent /
198.68.42.72 WWWuser@ 4/8/96 0:07:28 MSFTPSVC HOLODECK3 - 10 42 0 0 2 [1] sent /Private
198.68.42.72 WWWuser@ 4/8/96 0:07:29 MSFTPSVC HOLODECK3 - 10 58 0 0 2 [1] sent /Private/iexplore
198.68.42.72 WWWuser@ 4/8/96 0:07:31 MSFTPSVC HOLODECK3 - 10 72 0 0 2 [1] sent /Private/iexplore/docs
Client IP Client Name Date Time Service Svr Name IP Proc time Rec Sent St NT Operation Parameters/ Target
198.68.42.72 WWWuser@ 4/8/96 0:07:32 MSFTPSVC HOLODECK3 - 60 90 2443 0 0 [1] sent /Private/iexplore/docs/backgrnd.gif
198.68.42.72 WWWuser@ 4/8/96 0:07:35 MSFTPSVC HOLODECK3 - 311 54 4086 0 0 [1] sent /Private/iexplore/docs/client.gif
198.68.42.72 WWWuser@ 4/8/96 0:07:38 MSFTPSVC HOLODECK3 - 151 53 826 0 0 [1] sent /Private/iexplore/docs/space.gif
198.68.42.72 WWWuser@ 4/8/96 0:07:41 MSFTPSVC HOLODECK3 - 50 52 1820 0 0 [1] sent /Private/iexplore/docs/home.htm
198.68.42.72 WWWuser@ 4/8/96 0:07:41 MSFTPSVC HOLODECK3 - 10 56 2443 0 0 [1] sent /Private/iexplore/docs/backgrnd.gif
198.68.42.72 WWWuser@ 4/8/96 0:07:43 MSFTPSVC HOLODECK3 - 1442 18 0 0 64 [1] closed -
Client IP Client Name Date Time Service Svr Name IP Proc time Rec Sent St NT Operation Parameters/ Target
198.68.42.72 joeuser 4/8/96 0:08:36 MSFTPSVC HOLODECK3 - 0 14 0 0 0 [2] USER joeuser
198.68.42.72 - 4/8/96 0:08:36 MSFTPSVC HOLODECK3 - 0 15 0 0 1326 [2] PASS -
198.68.42.72 anonymous 4/8/96 0:08:55 MSFTPSVC HOLODECK3 - 0 16 0 0 0 [3] USER anonymous
198.68.42.72 swynk@pobox.com 4/8/96 0:08:55 MSFTPSVC HOLODECK3 - 30 22 0 0 0 [3] PASS swynk@pobox.com
198.68.42.72 swynk@pobox.com 4/8/96 0:09:04 MSFTPSVC HOLODECK3 - 50 234 2443 0 0 [3] sent /Private/iexplore/docs/backgrnd.gif
198.68.42.72 swynk@pobox.com 4/8/96 0:09:07 MSFTPSVC HOLODECK3 - 191 41 4086 0 0 [3] sent /Private/iexplore/docs/client.gif
Client IP Client Name Date Time Service Svr Name IP Proc time Rec Sent St NT Operation Parameters/ Target
198.68.42.72 swynk@pobox.com 4/8/96 0:09:11 MSFTPSVC HOLODECK3 - 210 41 826 0 0 [3] sent /Private/iexplore/docs/space.gif
198.68.42.72 swynk@pobox.com 4/8/96 0:09:13 MSFTPSVC HOLODECK3 - 0 6 0 0 0 [3] QUIT -

By reviewing this table, and recognizing the layout of it, you can quickly determine that this user accessed several files:

You can also see that the BACKGRND.GIF image was accessed twice in the session for some reason. If the client was using a Web browser, and if this image is truly a background image, as its name suggests, several scenarios are possible. Perhaps the user accessed more than one page that used the image, or maybe the image was loaded independently of an HTML page, or perhaps the page was called for more than once in your HTML page.

Typical FTP convention calls for a user to use his or her e-mail address in the password field if he is accessing your site via anonymous FTP. This email address is included in the log. You'll notice on the first two entries when the new session was established that the two tokens, USER and PASS, were shown, indicating that information about the user.

Note that session 3 indicates that the user was obtaining access by using a "real" FTP client. This means that he was not using a Web browser. You can tell this because the user has logged in anonymous, but still specified a password, in this case "swynk@pobox.com." Also, in the log for session 2, you can see that the NT security subsystem has failed the user's logon attempt. A status of 1326 and a lack of any further activity on the session is an indicator of this.

One trick to reading the log files is to use Microsoft Excel to view them. As you can see in Figure 7.2, this is a great way to quickly review your log files.

Fig. 7.2 - Excel provides a good viewer for your server's log files.

Follow these steps to take a quick look at the files:

  1. Stop all services on your Intranet server.

  2. In Excel, select File, Open, indicate that you want to see files of type "*.*", and choose the log file name that you want to open. Note that this defaults to "INYYMMDD.LOG" where Year, Month and Day are provided for YY, MM and DD. The "IN" and "LOG" are automatically provided by IIS..

  3. You'll be prompted to select the Original Data Type. Select Delimited, and then select Next.

  4. In the Step 2 of 3 dialog box, in the Delimiters frame, select only the Comma check box, and then select Finish.

Once your log file is imported into Excel, you're ready to reformat it as needed to get the information you seek. A good tip is to click the corner square on the worksheet grid, and then double click a column border to automatically re-size columns to see all information within them.

Protecting Your FTP Site

There are several different ways in which you can incorporate security for your FTP materials. The major components include the following:

A cross-section of these can pertain to any given user or directory. In the next sections, you'll see how you can mix and match these options to provide the access control you'll need.

Controlling Anonymous-Only Access

When you set up the FTP services, must indicate the type of access that will be used to validate the users who want to access to your site. This includes indicating the account that will be used when the user selects the special anonymous account when signing on to your site. As you can see in Figure 7.3, you also have two options that indicate how secured access will be gained to your site. The Allow Anonymous Connections and Allow Only Anonymous Connections options control more than may first be apparent.

Fig. 7.3 - If you want to secure your FTP materials, be sure to carefully consider how you'll indicate default user information in the FTP service property sheets.

These options, while seemingly very similar, offer quite different results. The first, Allow Anonymous Connections, indicates whether a user will be able to sign on to your FTP service without first indicating a user name and password. Without this option, the name and password entered must be valid to Windows NT on the server that the user is attempting to sign in to. This means that if JohnSmith, with a password of BLAHBLAH, attempts to access your site, he must first have a valid account at the site. If not, he will not be able to access any content at the site. You'll notice that, if you disable either of these options, you'll receive a dialog box indicating that you're selecting options that may be less secure. Figure 7.4 shows an example of this dialog box.

Fig. 7.4 - If you turn off anonymous login, you're forcing the user to log in to the server. Since FTP does not encrypt log on information, it is sent in a form that is decipherable by prying eyes. IIS warns you of this fact if you disable either of the options.

When you disable either or both of these options, you'll be requiring that the user be validated to the NT security system. This is true because there are no FTP clients that will encode or encrypt your user ID and password when signing on to the site. Since this is true, the user ID and password must be sent without these precautions, leaving open the possibility that someone could be monitoring the lines on which your network runs.


When you installed IIS, the user created to handle the FTP logins had the security options for it set automatically. One of the key items that is set up is the Account Right to "Log on locally" to the system. If you disable the Allow Only Anonymous Connections option, you must set this Account Right for every account you expect to be logging on to the system. If you do not, They'll be denied access when they try to access the system.

Here are the steps to create this type of Account Rights installation:

  1. Create the new user account in User Manager for Domains.

  2. Select the User account you want to work with. Note that this operation can be completed for groups of people as well. You can select multiple items by first clicking on the first user account you want to work with, and then Ctrl-clicking all other accounts from the list for which you want to work with rights.

  3. Select Policies, User Rights. The dialog box you'll see should be similar to the one shown in Figure 7.5.

    Fig. 7.5 - Log on locally is a required right for all accesses against the server by outside users.

  4. From the Right: drop down list box, select the Log on locally privilege.

  5. Verify that the user you're concerned with is listed in the Grant to: list box. If not, select Add... and then either select the Group you want to grant access to, or select Show Users and find the specific user you want to have this right.

  6. Select Add to give the right to the user.

  7. Click OK. The user is added to the Grant to: list box on the User Rights Policy dialog box.

Once you've completed these steps, the user will be able to use his user ID and password to gain access to your system. Standard security checking is still done at the NT domain level, and the user is logged into the different log files whenever he accesses the system.

By turning on the requirement for valid user names, you may be causing problems for some users who are accessing your FTP site with their Web browsers. It may be that their browser of choice does not support accessing a secured FTP site. This is an important consideration if you'll be supporting many different user environments.

If at all possible, you should recommend to your user base that they use a "true" FTP client. Figure 7.6 shows what one of the more comprehensive and easy-to-use clients looks like today. Things are constantly changing, so you can expect to see the user interface get more and more simple, allowing more secure access.

Fig. 7.6 - WS_FTP32, a shareware FTP client, provides a solid interface that allows you to log on to a site using a user name and password.

With this type of FTP utility, you can easily indicate the name and password you want to use to access the FTP site. If you turn off the ability to accept anonymous logon, you'll want to consider providing your users with a utility such as this.

Service-Level Read and Write Permissions

Another important consideration is the permissions associated with a given directory tree. Remember, the rights associated with a given login are a combination of rights first established at the service level and then modified at the operating system level. This means that, if your account has write privileges for a directory but the NT security system does not support the rights for your account, the rights will not be granted. Conversely, if you have NT-level rights to a directory that allow you to write to it, and the directory within IIS shows as read-only, the rights will be read-only.

You should think of rights that pertain to these users as applying the Most Restrictive case to their user rights. Figure 7.7 shows the Directory Properties dialog box that enables you to set these options.

Fig. 7.7 - Keep in mind that people using an FTP client application will be able to upload information to your site if you allow it. To prevent this, be sure you deselect the Write privileges associated with a virtual directory.

Remember, FTP is the most open protocol that allows access to your server. At its most permissive settings, you are basically granting the right to browse directories, upload and download files, create new directories, and more. FTP, and the rights you assign at the service and account levels, is worth the time to think about. Be sure you have the precautions in place that you need. In the next releases of browsers, users will even able to upload files via their Web browser software. You can count on accessibility getting easier and easier for your user base.

Disabling Directory Browsing

While the Directory Browsing option is not implemented in the FTP service, it brings an FTP-like service to the Web browser, so it's important to mention it here. If you have either deselected the default document option (see Figure 7.8), or if the default document does not exist in the directory you indicate, one of three things can happen for the user.

Fig. 7.8 - It's generally a good idea to make sure the Directory Browsing Allowed check box is deselected.

First, if the Directory Browsing option is enabled, the user will see a listing of the directory, from which he can select the file he wishes to view. This can be risky in nearly any setting. About the only time you'll want to have this option enabled is in those cases where a user is an administrator.

The danger of allowing general browsing of your files comes from the fact that HTML files will be visible, as well as subdirectories and supporting files like graphics and such. If the Directory Browsing option is enabled, the user will receive a file listing like that shown in Figure 7.9. This listing allows a user to see all files on your system.

Fig. 7.9 - Not having the default document defined, or not having it available, causes the Explorer to become a directory and file browser.

The second thing that may happen is that the user will be presented with an Access Denied message if you have both browsing and the default document turned off. The message will say only that they are not authorized to access the requested document. The users must specify a valid page or object to load before they will be granted access to the site.


With some servers, including Microsoft's IIS, you may be required to include a trailing forward-slash after the site name if you're not indicating the object to load in the URL. In other words, if you're loading the default page, the safest way to indicate the URL is: 

http://www.intellicenter.com/
The trailing forward-slash simply indicates to the server that the default document should be loaded.

The final option occurs if the user does indicate the proper address of a valid object on the site. In this case, the object is loaded into the browser and worked with accordingly.

Protecting Uploads

One of the real benefits you can offer to your users is the ability to upload files to your site, but to have the files remain hidden to all users on your site until you release them to public or to other protected areas on your site. Giving yourself time to review the items uploaded lets you check for obvious problems, including viruses, and lets you put the item in the correct location on your system rather than relying on the uploading user to do this for you.

The best protection for uploads is to allow access to send files, but disallow access to read from the directory where they are sent. You may recall from Chapter 3 that you can set the permissions flags for script files to Execute and safely deselect Read rights. This allows you to set up a directory for your script files, for example, from which the extensions can be executed but which cannot be reviewed.

From the Edit Properties option of the Directories dialog box, the FTP service allows you to set these privileges if you want to enforce them at the Service level. You can see these settings in Figure 7.10.

Fig. 7.10 - One of the places you can set options to control upload rights to the site is on the FTP service's Directories tab.


If you decide to control these options using NTFS on a user-by-user or account-by-account basis, be sure you select both the Read and Write options for the directories. If you don't, the only thing you'll be able to control with the NTFS permissions will be those rights that pass this initial test. In other words, if the user isn't allowed Read privilege in this services definition, a user will not have access, regardless of NTFS permissions.

The other way to control these rights is through the use of the NT-based security system. You can select the permissions from NT and control the access to the directories just the same as you can here. If you're not using NTFS, you can still control access. You simply have different options for doing so.

Figure 7.11 shows the different options you have and their effects on your system.

Fig. 7.11 - There are several different alternatives available to help control access to your system's virtual directories.


One of the most frequently asked questions regarding setting up a protected site is how to allow certain access rights to FTP or Web users. As you can see in Figure 7.11, the different combinations of rights to provide a certain privilege can be an interesting challenge.

Take a few minutes as your site comes up and familiarize yourself with exactly what it is that happens as each of these rights is imposed on an FTP session. You'll want to set up a sample account and then try logging on with that account to determine the impact on of each setting on the rights. Once you can understand how these apply, you'll be all set and can move on to mixing private and public information on your system.

Controlling Access Via IP Addresses

A brute-force control method for your network, one that provides essentially bullet-proof access control, is to limit access by IP address. When you set up your site, you can determine which IP addresses, or series of addresses, are allowed on your site. As you can see in Figure 7.12, you control IP access on an exception basis.

Fig. 7.12 - Controlling access by IP address can be tedious, but it's a sure way to manage the people who can access your information.

The first thing you do is select the default access allowance- will you generally allow all users to gain access, or will you generally not allow users on the system except in those cases where you've specifically granted access? Select the general rule you want, either Granted Access or Denied Access.

Whichever you select, you can then indicate which IP addresses, or IP address ranges, fall outside the rule you've indicated. In other words, if you say that most computers are Granted Access, the IP addresses you list will be denied access. If you indicate that the default is to provide Denied Access, the IP addresses you indicate will be provided access to the system.

By selecting the Add or Edit buttons, you can specify or update the IP addresses that are allowed on your system. Figure 7.13 shows the dialog box that is used to provide this information.

Fig. 7.13 - When you indicate the IP address, if you're providing only a single address, you can select the ellipses button and provide a computer name to be looked up in DNS, saving you the trouble of knowing the different IP addresses for the computers on your network.


Remember, you can specify a "wildcard" IP address range. For example, as you can see in Figure 7.13, only the first portion of the IP address, "204.166," is indicated. IIS will add in the final portion of the address, but this address is combined with the Subnet Mask and all computers that fall within that range are impacted by the setting.

This is especially helpful if you're running your Intranet over the Internet. If you're concerned about someone else coming into your system, and have an assigned range of values for your company's IP addresses, you can disable access by default and then grant access specifically to only those computers with IP addresses that are known to your system ahead of time.

You'll notice in Figure 7.12, the IP address is listed with trailing zeros, indicating that all values in those portions of the address are acceptable.

Revisiting the Types of Users You'll Encounter

At the beginning of the chapter, I told you that there were four types of users:

For the "General..." users, you should create overall FTP rights groups. Typically, you'll want to create a group, "Public FTP," of which all FTP users are members. This group has general access to all of the different general access areas, including the root directory trees for the virtual directory structure. From there, you can grant specific access addenda that provide for access to closed, or private, areas.

General private users should first belong to the public groups, as this provides the overall access to the site. Next, you should create groups that all users of the specific category will fall into. Perhaps you're supporting a product on your site and you need to provide registered users of your product with updates to the software. Create a group, such as "MySoftware RegBase," that all of these users will be members of. Grant the rights to that group, allowing them access to the private areas only. Since they are also members of the Public FTP group, they'll have overall access to the site as well, along with the added access to the software updates they need.

The distinction between a unique private group and general public users/groups is that private groups will likely have more obscure rights assigned to them, perhaps an upload capability and access to additional directories. These are not actually implemented any differently than "normal" groups, but it may be easier to try to think of them as more exclusive, less public groups. For example, you could create a private group for use with Beta testers of your software. Private groups are often temporary and used to provide rights to a small subset of accounts for a short term. Again, don't be confused by the name. You don't do anything different setting these up, as the naming is only for clarification in this context.

Of course there are always exceptions. Unique users are just that, an exception. Let's say that JoeUser is a system administrator who absolutely must have access to the root directory of your system. Surely this should be a very limited resource, and you may want to grant the right to JoeUser specifically.

Much of the task of assigning rights is brainwork and planning. Start by making lists and figuring out the types of access you'll have to accommodate. From there, you will see the groups fall out and almost create themselves. Taking the time now will save you from a splintered installation later that requires a significant amount of upkeep.

Accessing Your FTP Site from Web Pages

As you'll recall from Chapter 3, it's also possible to access an FTP site using a browser. There are several ways you can get to the location. Of course you can always just specify the address in the "command line" or URL Open: text box. To do so, you'll use the format:

ftp://<site>.[<subdir>...].<file>
For example:

ftp://ftp.intellicenter.com/classes/samples/iis.zip
would indicate that you need to connect to the IntelliCenter FTP site and you want the IIS.ZIP file. It's located in the /classes/samples virtual directory. What happens when you indicate the file in this manner varies a bit from browser to browser. In most cases, the file is downloaded and you have the option of opening it or just saving it to disk.

The actual reaction will vary, however, because browsers are becoming more intelligent in how they work with files that are downloaded. For example, if you point your browser to a .DOC file, and you have the Word Viewer installed, the document will automatically be opened for you in the Word Viewer. If you select a graphic with Internet Explorer, the graphic will be displayed in the browser if it's a compatible, known graphic format.

Building a Customer Support Site

In this section, you'll see how you can apply the different permissions and setup techniques to your Web site. You'll see different techniques for user profiles, permissions groups, and directory structures, along with the specific steps to implement these techniques.

The goals for this site are:

These are pretty typical goals for an Intranet or Internet presence for a customer support site. You need to provide your customers with access to the information they need to use your products. You also need to provide a mechanism for feedback, which is why the requirement to allow uploads is included.

In these example sites, except where it's not possible or feasible to do so, you'll be building the site for use with the Internet Explorer, as it provides a solid and easy interface. The user won't have to know how to use an FTP client unless he or she is going to be uploading of files to a site.

In this site, you'll likely encounter many, if not all, of the different types of users mentioned earlier. In the next few sections, you'll see how you can apply these groups and users to the FTP capabilities at your site.

Provide Overview Information and Product Support Materials

Providing information on products that are offered by your company is a perfect application of a Web site. You can provide access to the information 24 hours a day, seven days a week, without additional staffing. Of all the things the Web can offer, leverage is one of the most powerful benefits that it brings. You gain leverage to publish information, when and where it's needed by your customer base, while at the same time taking a significant load from your support staff. They can provide support, focusing on solving the urgent issues first instead of based on who is on the phone at the moment.

In this scenario, consider the directory tree shown below.

FTPRoot
     Product_Info
          Widgets
          ShoeShine_Kits
          CeilingFan_Cleaners
          Tire_Polish
          MySoftware
     Support_Info
          MySoftware
               Network
               StandAlone
          ThirdParty
You create the home FTP directory and point it at FTPROOT in the directory structure. You'll likely allow users to browse the directory structure, or you can create the HTML pages that will point the user to the correct directory to see its contents. Figure 7.14 shows how this might look to the user.

Fig. 7.14 - When your users visit the site, they need not necessarily know that you're providing links to an FTP site. You can provide the interface to the underlying FTP system with the use of FTP URLs that indicate the files that you want to provide.

In this case, where you're providing general access, only the standard FTP setup is required. You'll notice that the links can be both HTTP addresses and FTP addresses. The first item on the list is an FTP address. If the user clicks on the link, the document will be loaded and the file will be displayed.

Since this file, a .DOC file, is known to your Web browser, the file is loaded and displayed automatically. This is shown in Figure 7.15. To the users, they simply opened a document and are now able to browse it, save it to their local hard disk, print a copy of it, etc.

Fig. 7.15 - Depending on the version of browser you have, the document may be loaded into the browser and displayed in place using either Word or the Word viewer if you have installed it.

The listing shown in listing 7.1 is the HTML that is behind the document that provides these links and the access to the FTP document. Notice that the URL indicating the FTP link is different only in that it indicates the FTP protocol. The server and browser work together to make sure the display of the information is as seamless as possible.

Listing 4.1 Sample links to an FTP site from a Web page (SUPPORT.HTM)

<HTML>
<HEAD>
<Title>Sample Product Support Links</title>
</HEAD>
<BODY>
<BODY BACKGROUND="../white.jpg" BGProperties=fixed
 LEFTMARGIN=50>
<center><h1>Product Support Sample 
Page</h1></center>
<body text=black>
<center><a href="http://www.microsoft.com"><img
 src="../bestwith.gif" ALT="Best Viewed with Internet 
Explorer" WIDTH=100 HEIGHT=42 border="0"></center></a>
<p>
<B><i><center>
<MARQUEE BGCOLOR=White width=80%  Loop=-1 
BEHAVIOR=Scroll>You may find the following links 
useful in your use of the product we're 
supporting...</MARQUEE></i></center>
</b>
<p>
<hr>
If you have links you'd like to add, please email 
me at: <A href="mailto:swynk@pobox.com"> 
swynk@pobox.com</A>
</b><p>
<p>
<ul>
<li><a 
href="ftp://holodeck3/Product_Info/overview.doc"
>Product overview </a> for the products we support.
<li><a 
href="http://www.cyberhighway.net/~clarkr/">This Old 
Cyber-House</a> is a fun romp through a ton of 
information and fun links. 
<li><a 
href= 
"http://www.netmind.com/URL-minder/URL-minder.html">
 URL-minder</a> is an excellent utility that will 
automagically 
 watch web pages you're interested in.  This free 
service will 
 notify you, via email, whenever a web page 
changes once you've 
 registered an interest with the engine.  It 
works quite well!
<li><a href="http://www.synet.net/hwg/">The HTML 
Writer's Guild</a>
	is a great resource for information 
about writing and designing web pages.
...

...
<li><a href=
"http://www.cs.colostate.edu/~dreiling/
smartform.html">
 Savvy Search</a>, <a 
href="http://www.infoseek.com">Infoseek</a>, 
 <a href="http://www.yahoo.com">Yahoo!</a>, and 
<A
 HREF="http://www.stpt.com/"> Starting Point</
A> are good search 
 engines, and  <a href="http://www.mcp.com/
 130672791559792/nrp/wwwyp/">the Internet Yellow 
Pages</a> 
 provides a good resource for finding sites as well. 
</ul>
</BODY>
</HTML>
Since this information is public and probably general marketing and sales information, access to it should not be restricted. Be sure that you set up two groups for access to the Web and FTP portions of this site as follows:

Make sure your anonymous users for the FTP and Web services are members of these groups. By doing so, you're creating the lowest common denominator type of approach to your site. In effect, you're saying that, at the very least, all users will have access to the information granted to these two groups.


When you apply rights to a directory or share, you have the option of applying the rights to all subdirectories within the target with NTFS. Chances are good that you should say Yes to the question of applying the rights. But keep in mind that you're granting all the rights listed to all files and subdirectories within the current directory structure. This means that, if you've previously created a private subdirectory below one that you later declare public and apply rights against, your private subdirectory will suddenly be very public.

When you create a directory structure for which you're concerned about security for certain endpoints, create it from the top down, especially as it pertains to security levels. Apply the public security first, and then select the private directory, remove the public rights, apply the more stringent rights. This will ensure that you have complete control over how the rights are applied.

Probably the best and most hassle-free approach to handling this situation is to set up different directory structures for the secure and non-secure directories. You can create virtual directories that will point to these other locations from within your FTP service, and at the same time you won't have the worry of overwriting the directories as you work with permissions.

Provide Access to Sample Files and Demos

As you could see with the earlier example, providing FTP access to the sample files and demonstrations you have on your system is straightforward. If you have a dynamic source of files, or if you simply have a large number of files, you can indicate in the URL that you simply want to provide a directory listing of the subdirectory containing the files. To do so, just leave off the portion of the URL that indicates the file to retrieve. So, using our example above, if you want to provide a file listing of everything in the PRODUCT_INFO subdirectory, the HTML line would read as follows:

<li><a href="ftp://holodeck3/Product_Info/">
Product overviews </a> for the products
 we support.
The result, shown in Figure 7.16, is a listing of the available product information starting with the directory you indicate in the URL. The user can browse the directories at will and take a look at any items that look interesting.

Fig. 7.16 - Listing a directory's contents can be good way to provide up-to-date access to a dynamically changing source directory.


Security is applied to the items viewed only if you've implemented your security with NTFS. Share-level security does not apply to browsing the FTP directories. Of course, the FTP rights of Read/Write do still apply. If you need to protect an item, you need to physically move it, or be sure you implement NTFS and use the security offered by it.

Provide Access to Program Updates

Once you've applied security to a directory or file and the user requests it, he is prompted to enter his password if the user defined as the anonymous user is not allowed access to the object. Figure 7.17 shows the dialog that prompts the user for the user name to use for access to the resource.

Fig. 7.17 - The user name and password provided by the user are used to log in to NT to authenticate the account and its rights.

Once signed in, the user is treated as an authenticated user for further accesses. This allows the user to access the directories and objects that prompted the initial request for user name and password.

To allow access to program files, first create the directory that you need to place the files into. Map a virtual directory to that location, making them available to the service. Set the rights appropriately in the service, most likely to Read privileges. Then remove the rights that are assigned to the directory when it's created. Be especially careful to remove the group EVERYONE and the user Guest if these are shown in the list of allowed accesses.

Add the group as having access to the directory, and apply the security to the directory and its subdirectories and existing files. This locks down the content and provides it only to the people and groups indicated in the permissions list.

When users log into the system, depending on the capabilities of the browsers they use, they'll either be prompted by the Web browser for the login information or they'll be informed that they need to use a more typical FTP client package that allows access to restricted sites.


If you find the people are having difficulties accessing your protected information, have them try logging in with a dedicated FTP client. There are several Web browsers that may not be compatible with the security validation tests provided by NT.

If you have several products (or several versions of the product) on which to make files available, you'll want to create a group specific to each version. This allows you to control very specifically who has access and who doesn't. Remember, a user can belong to more than one group at a time, so if you have the requirement to provide access to multiple areas, simply apply the rights based on the Group, and then make the appropriate users part of those groups.

Downloading or accessing the updates or releases for retail software is likely to fall into the user-grouping that I spoke of earlier ("Member of Unique Private Group" and "Unique Private Individual"), as you'll be granting rather exclusive rights to these users.

One further caution-with these accounts, you'll do yourself a favor if you implement a password change schedule or password expiration schedule for these accounts. This will mean that you'll have to modify the password assigned to the accounts on a regular basis. This keeps users from sharing passwords with friends, and it keeps access rights to the accounts more private and more elusive to any problematic users you may encounter. You set these rights from the User Manager for Domains. Double-click on the account and set the different properties using the buttons along the bottom of the display.

Allow File Uploads

File uploads are a very interesting capability that you can offer. Whenever you have a serious, inexplicable user problem that you're trying to solve, it can really help to have the program, sample, or data uploaded to your site for review by your staff. This capability to upload files needs to be tempered a bit to the point that other users cannot see the files uploaded and cannot download them from the upload directory.

The reason for this is really twofold. First you don't want to compromise any information provided to you from a customer, should it get into the hands of another customer. If you're supporting a software product used to track job costing, for example, and a client just uploaded a sample, you don't want other clients getting that information.

The second reason is, once again, if you have people accessing your site with a malicious intent, they can upload a file containing harmful information, a virus, or some bad bit of code. If other users see this, you run the chance of being liable if they have problems with their systems. It was your system, after all, that provided the faulty item to them.

You'll want to make the FTP upload directory Write permissible and Read non-permissible at the FTP service level. From the FTP service, select the Directories tab and then select the directory you want to use for uploads. Select Edit Properties and then set the privileges appropriately.

When users upload files, they won't be able to see the uploaded files on your system, so you may want to warn the users of this before they upload.

Reality Check

At the IntelliCenter Reality Check site, there are a number of things implemented using the techniques here. There are three levels of employees, somewhat akin to the employees in the Customer Support sections earlier in this chapter. There are also unknown prospects, known prospects, and clients.

Prospects have been set up, basically as anonymous users, to have only public rights. The following items are published for these users, all from a Web page interface:

If customers are interested in finding out more, they're directed to call IntelliCenter to gain access to more detailed information. This allows the company to garner more information about the contacts and make sure they get the information they need from the site. During the call, the potential customer receives a user ID and is assigned to the appropriate group that gives him additional access to the following types of information at your site:

Finally, when a client has started a curriculum with the company, his account receives access to the protected student areas. The student areas include the following items:

By providing different levels of access, it's possible to first spark some interest without giving away any unnecessary information. From there, if the client is interested in class information, he can find it out online just by registering. By registering, IntelliCenter gets a new client contact and can track the contact to see how they can best help him.

One of the challenges faced was with the user access. Initially the NT Challenge/Response passwording was selected for Web access. Since this is incompatible with non-Microsoft browsers, this posed a limitation to the intent of the site. After disabling this option and allowing clear text authentication, it was possible to prompt for and receive the information required to authenticate the account.

The next issue was one of typical network browsers not allowing, at least easily, for the entry of user name and password when accessing the FTP site. In many cases, the client needs to use a true FTP client, as we mentioned earlier in the chapter, to access the protected information. By putting a mention of this fact on the web page, we were able to help people gain access as needed.

From Here...

This chapter has been a series of practical applications and how-to's for your FTP site. From here, the best thing you can do is experiment with the permissions and different access methods. You'll need to choose your weapon of choice for accessing your site, even in cases where it means there will be exceptions, as is the case with protected FTP information and Web browsers.

You're safe in standardizing on Web browsers as the utility used to access your site, and you can assume that these browsers will only become more robust in the very near future.

Here are some additional resources that you may find helpful:

Copyright © 1996, Que Corporation
Technical support for our books and software is available by email from support@mcp.com

Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290.

Notice: This material is from BackOffice Intranet Kit, ISBN: 0-7897-0848-5. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.

[Copyright Information] [Table of Contents] [Que Home Page]
[Prev Chapter] [Next Chapter]