![[Copyright Information]](graphics/copyrite.jpg)
![[Table of Contents]](graphics/toc.jpg)
![[Que Home Page]](graphics/que_home.jpg)
![[Prev Chapter]](graphics/chapprev.jpg)
![[Next Chapter]](graphics/chapnext.jpg)
People realize that Intel-based systems are powerful when used as Web servers. Many articles in trade journals and newsletters indicate that mid-range PC-based systems handle amazing loads and still offer the throughput needed to service the Internet and Intranet systems coming on-line. These were tasks traditionally left to UNIX systems.
Your Intranet is based on Microsoft NT Server and it supports some of the heaviest loads in the industry. One example of an overly taxed system is the Microsoft site, http://www.microsoft.com. This site is powered by an Intel-based system, running NT Server and the Internet Information Server. The site supports many millions of hits per month and proves IIS and NT to be a good platform for both Internet and Intranet systems alike.
In order to support the most user-friendly access to your system, there are several different things you can do. Friendly names, allowing users to refer to your server by name rather than by its TCP/IP address, are just one step you can take. In the balance of this chapter, you'll see how to set up NT Server to provide a strong and secure environment for IIS. At the same time, you'll see how important the NT Server domain model is to providing a strong Web, FTP and Gopher site.
In the coming sections, learn how the pieces of the NT Server operating system work together to bring your Intranet up and to make it as easy as possible to use.
When you set up your Intranet, there are three different ways that people point their web browsers to your server to begin working with your system. The first option, specifying the TCP/IP address, requires that you simply indicate the address of the server in the HTTP: URL specified.The syntax for these types of URLs is:
http://nnn.nnn.nn.nn[/<filename|path>][/...]
Using this, or any of the other protocols from these examples, the default document loads automatically if your URL ends at a directory level with no specified file. Unless changed, with IIS, this file is DEFAULT.HTM, while with other systems, such as those based on UNIX, the default object loaded is often INDEX.HTML.
As you can see in figure 2.1, the IP Address for the server in this demonstration is 199.255.25.25 and it loads the DEFAULT.HTM page.
Fig. 2.1 - One option to indicate the location to open is to provide the IP address for the server in the URL.
 You can specify the URL on your Intranet without indicating HTTP:// in the address. If you leave off this indication, the Internet Explorer automatically assumes this type of connection and modifies the address for you, after finding the address you indicate.  |
The second option is to use the FILE: protocol. This opens the file you indicate. You to view it and its links the same as if you indicated the URL with any other method. The syntax for the FILE protocol is:
file:///<full path and filename>
You can select a file located on any path available to your client system. By using the FILE protocol, you bypass the Web server altogether. This is a good way to test a site prior to rolling it out to a production Web site. You not only can create your pages, images and other objects that you want available to your users, but you also can enable your users to open your pages using the FILE protocol. Users browse your content and test it out without impacting the server during the test.
 Chapter 10, in the "Site Maintenance with NT, IIS, and SMS section," explains that when you create your pages, you must be sure to use relative path names. If you do, the FILE protocol works correctly. If you hardcode your links as HTTP Hyperlinks, your users will have to have full access to your Web server when following one of the HTTP links. This removes the advantage of the FILE protocol.
Further, if you indicate your file links by simple relative file links, for example ../dir/mypage.htm, the browser navigates your pages better when using any applicable protocol. |
Figure 2.2 shows how you specify the URL when using the FILE: protocol.
Fig. 2.2 - If you opening objects directly from the server or linked files, you use the FILE: protocol to access them. Note the use of the /// before the object path and name.
The final option indicates the URL by specifying its friendly name set up in the NetBIOS settings for the server. When you do this, you indicate the computer name as the URL, followed by any specific object you want to open. As with the other methods, if you specify only the server name, the server automatically opens the DEFAULT.HTM page. The syntax of this URL is:
http://<computername>
or
<computername>
If you indicate only the computername on your system as the URL, the Internet Explorer assumes you need the HTTP protocol and automatically changes the URL to show the http:// prefix. This is a real benefit to your Intranet, because you only need to tell your user base, "Just type in webserver for the location." You don't have to worry about explaining the HTTP portion of the address.
Notice that the Internet Explorer will append a / to the URL you indicate. This is just the formatting recognized by the server/browser combination and does not affect the page that loaded to satisfy your request. |
Use each of these on your Intranet system, but you cannot use the FILE: protocol on the Internet. The Internet assumes a path to the object you want to open. You can use a combination of these access methods on your systems, depending on whether you test a new installation or running against an existing production system.
This chapter discusses quite a number of TCP/IP options and protocols to consider using in your implementation. One of the protocols not specifically addressed here, (because it does not relate directly to bringing up your Intranet), is Dynamic Host Configuration Protocol or DHCP. DHCP provides you with a way to dynamically assign IP addresses to your network's workstations. In short, the system administrator establishes a pool of addresses and systems request an IP address as they sign on to the network. DHCP assigns them an address and then marks the address as assigned. Addresses provided in this manner are termed "leased" addresses., This term is used because "leased addresses" either expire when the system leaves the network, or at another predetermined time, often a fixed number of hours after completing the original assignment of the IP address.
As you'll see in the balance of the chapter, DNS and WINS provide easy to manage tools to monitor and keep up to date the tables that relate computer names and IP addresses. As you can imagine, in an environment where IP addresses are constantly changing, these services offer some great functionality for the users and system administrators of the systems in which they are used. |
In the next sections, see how you set up your system to let your users indicate the computer names as the address. Also, learn how to manage the users' of your system and begin to create the foundation upon which your Intranet server runs.
One of the key things to know about NETBIOS-based networks is that the computer name set up for your system is incompatible with larger networks. NetBIOS is not a routable protocol. With this in mind, and realizing that computer names cannot be routed over multiple LAN segments, Microsoft solved the problem, but still maintained user-friendly names.
WINS does just that. WINS maintains a database of systems on the LAN and their associated IP address. Just as the Domain Name System (DNS) does for the Internet, WINS takes the user-friendly people associated with the network systems and associates it with their individual IP address. When people indicate that they want to access machine "HOLODECK3," WINS steps in and makes sure that the users access the right physical computer.
Before setting up your server as the WINS server, you must have a fixed IP address for the server. Since you configure the client systems to refer to the WINS server to resolve the names on the network, you must specify a fixed location where the client systems can seek help.
Make sure your system has a pre-assigned, fixed IP address, not one assigned by DHCP. You can check the address by reviewing the TCP/IP protocol settings. Select the TCP/IP Protocol, then click Configure. Select the desired adapter from the Adapter list box. The Specify an IP Address options should specify an IP Address and Subnet Mask. You cannot select the Obtain an IP Address from the Server option. See figure 2.4 for an example. |
Fig. 2.3 - You cannot use the DHCP or other variable IP address options if your server will be serving as a WINS server on the Intranet.
Fig. 2.4 - Making WINS available on your network requires adding a new service to the Network options supported by your server.
When you select the Add button, you access a list of available services, much like those shown in figure 2.5. In addition, you'll be able to use a third-party disk, if you have one, to install drivers that may have been updated from the time you installed your system.
Fig. 2.5 - There are several services available to install on your system.
Select Windows Internet Name Service and select OK. When you do, you are prompted for the location of the files to update. Load your CD ROM, then select the OK button to start the copying process. Once you complete the copying process, notice that the services appear in the Protocols tab, as shown in figure 2.6.
Fig. 2.6 - Once installed, the WINS service binds to a network adapter as a new protocol on the adapter.
Install the service, and it activates on your network. It automatically starts when your system starts and it monitors the network for announcements of systems coming on line.
Later, when a system requests access to a computer system by name, e.g., HOLODECK3, that system makes an initial request of the WINS system. The request is evaluated against all named systems known to the WINS service. Once it finds a match, the system receives the requested IP address and can continue to do its work with the remote system.
Of course, to the user, this is all transparent. To you, as you use your Internet Explorer, WINS simply makes a request of the network to open a certain machine (using the protocol you indicate in the URL). Behind the scenes, lookup and remapping take place quickly to get you where you need to go.
When you type in the name of the system you seek, notice that the status bar in the Internet Explorer indicates that it is finding the address for system '<systemname>'. This indicates that the system is trying all means possible to find the system you requested, including WINS. |
If the system is not located, your client system attempts to find the system on the local LAN segment. Since LAN names are valid within a segment, your system sends out a message looking for the system you indicate. If found, the connection is made as expected. If the connection is not located, you receive an error message telling you that the remote connection could not be made. See figure 2.7 for an example error message.
Fig. 2.7 - If a system cannot be located on your network that matches the requested name, the application will eventually time out the request and let you know that it could not find the needed system.
Fig. 2.8 - A new option is installed into the menu system allowing you to administer the WINS database and its options provided to client systems.
The WINS Manager makes changes to the operating parameters, updates the database and generally administers the WINS service. Note that you do not make these changes through the control panel, but instead you make them through the WINS Manager. The Control panel installs and updates the service, but the service administration is done through the menus.
When you start the WINS Manager, you see a screen similar to the one shown in figure 2.9. The difference, of course, is that you see your own system's names and IP addresses. This display summarizes the activity on your WINS server, and it allows you to manage the different attributes controlling the operation of your system.
Fig. 2.9 - The WINS Manager main form allows full access to the different options for managing the named system database.
From the Server menu, add additional WINS servers to monitor. Since a single network shares the WINS request fulfillment process, use this capability to load-balance a busy network. At the same time, use a single WINS administrator to manage all of the different servers on your network. Select both the Add WINS Server and Delete WINS Server options to control the servers administered from the application. Each time you load the WINS administration utility, the different servers you indicate automatically reload. See specific Detailed Information by selecting the Detailed Information option from the menu. An example dialog box is shown in figure 2.10.
Fig. 2.10 - When you review the details for a WINS server, you see the number of systems it manages plus other server configuration information.
The View menu updates or clears the statistics shown on the right-hand pane. This is helpful if you believe you may have a problem. Using the View menu allows you to see only the current information about the WINS processes that are running.
It is likely that you spend the majority of your time administering the WINS processes in the Mappings menu. The Mappings menu is where you review and update the computer and TCP/IP relationship database, and it is also where you establish static mappings between systems and their addresses. When you select Mappings, Show Database., you review all known systems and see how they are represented in the system databases. Figure 2.11 shows an example of how this database represents not only computer names, but also domain and known user names.
Fig. 2.11 - By periodically reviewing the database of mappings, you insure that your systems are represented correctly by the WINS server. If you find that a system suddenly "disappears" on the network and people cannot reach it via its friendly name, review its configuration here and verify that it is assigned the correct IP address.
For each mapping your system detects, it sets up an entry in this database. This information sends back an associated IP address when a client computer requests it, based on a NetBIOS name. The columns marked "A" and "S" represent Active and Static addresses. An Active address indicates that, as of the last network query, the computer indicates it has that address. In the case of a Static address, you establish a Static address for a system, one that does not change from login to login.
Remember, the addresses assigned to DHCP, DNS and WINS servers should be static. This is because the client systems accessing the network must specify a fixed IP address in their network configuration in order to use the services of your server processes. |
If an address is marked as both Active and Static, it indicates that, as of the last polling, the computer was on the network and at the address indicated in the database. Notice that a given computer, service, or domain name may be in the database more than once, and still retain a WINS entry in the database. This allows for domains, changes in computers, and new names that begin appearing on the network, etc. As the mapping expires, the name is removed from the database. Since the name was valid at one point in time, if the computer leaves the network, and re-attaches quickly, you get to the right address, even before the system has time to re-register itself with the WINS processes.
From the Mappings menu options, select Static Mappings to start the steps to assign fixed addresses. Figure 2.12 shows an example of the dialog box used for managing these mappings.
Fig. 2.12 - Static mappings are good to use for servers already set up for fixed IP addresses. You can save the trouble of dynamically monitoring IP addresses for those types of systems by assigning a Static Mapping.
From this dialog, you can add and edit mappings, as well as import mappings from a text file, if you have prepared one with the mappings you need to indicate. The Import Mappings option is useful when setting up a network where you need to be aware of other systems that are not within the normal scope of "vision" for this server. This may be the case if you have systems that are on a WAN, and if you want to make sure users gain access to remote systems on another segment of the WAN.
Since you can map addresses regardless of their physical location, if you have a server with access to the Internet, you can just as easily map to a system on the Internet as one that is on your local network. This helps if you want to ensure that remote offices have access to your system, and vice versa. |
If you have a system that is using DHCP for its IP address assignments, do not put it in your WINS database with a static mapping. This causes WINS to provide your client systems with an incorrect IP address reference at a future date, when the system's IP address is reassigned via DHCP.
Generally speaking, it is important to know that the WINS system is self-maintaining. As new systems announce themselves on the network, WINS picks up this information and makes sure that the correct correlation between systems and their IP addresses is maintained. As assigned IP addresses expire, they are removed from the database. Also, as a system comes onto the network, if it was previously known under a different address, the old address is removed and the database is updated with the new assignment information.
Normally, the database automatically cleans up at regular intervals. If you want to initiate removing old addresses and other expired tokens from the database manually, select the Mappings, Initiate Scavenging menu option. When you do, the WINS server queues a job at the system level that cleans up the database and removes any unused entries. Notice that this manual step is not a typical requirement, because the server processes complete this at regular intervals in the course of their normal operation.
| *.LOG | These files are logs of the various transactions completed in the database. If the database must be recovered, WINS uses this information to do so. |
| SYSTEM.MDB | Configuration settings and other parameters relating to the structure and operation of the WINS system. |
| WINS.MDB | The core WINS database |
You will probably find that one of the LOG files is locked by the WINS service if you try to back it up when the system is running. To successfully backup the system, use the Backup Database option from the Mappings Menu. |
You create the backup of the system in a two-step process. The first step, shown in figure 2.13, is to indicate where you want to store the database backup. From the Mappings menu, select the Backup Database option to start the process.
Fig. 2.13 - Once you start the backup process, it automatically your system every three hours.
If you specify a nonexistent directory name, a new directory is created for you. When the backup runs, it dumps to the directory you indicate in a subdirectory named NEW under a subdirectory named WINS_BAK. There will be one or more LOG files, an MDB file and a PAT file created in that directory. These files should be backed up on a regular basis and are the source used by the Restore Local Database option if you encounter a problem either with your WINS database orif you need to reinitialize your WINS system with current values.
With Windows 95, Windows NT Server and Windows NT Workstation, set up the WINS connectivity from the Control Panel by selecting the Network application. Select Protocols, then select TCP/IP and Configure. Figure 2.14 shows the network configuration dialog boxes allowing you to indicate the WINS parameters.
Fig. 2.14 - Once the server is running, enable WINS at each workstation that will be referencing the server for name resolution.
If you are on a large network, you can improve WINS lookup performance by having more than one system servicing the WINS lookup requests. If you do this, indicate the secondary server in the configuration options, allowing your workstations to try both systems when looking up a system's address. If referencing a DNS server, these configuration dialog boxes are where you'll indicate the options for that service as well. Remember that in the context of this dialog box, you really indicate that the DNS server works on your Intranet, not, as it's typically used, for lookups on the Internet.
To establish a reference to an external DNS system, use the DNS tab indicating the addresses to use for DNS lookups. |
LMHOSTS and its associated capabilities and options are quite interesting. You might consider the LMHOSTS file as a sort of "poor-man's DNS" or WINS. On systems using TCP/IP, including all systems ranging from Windows for Workgroups using the TCP/IP-32 options through Windows '95 and Windows NT, there is a file that can be used on the system called LMHOSTS. This file contains mapping information that correlates IP addresses and their friendly NetBIOS computer names.
If this sounds familiar, it's because the file and its interaction with the TCP/IP configuration serves a function identical to the Windows WINS and DNS servers.
The catch is that you must manually maintain the file, making changes to it to reflect new systems, systems removed from the network and, probably most importantly IP address changes. If you decide to use DHCP, it makes using the LMHOSTS approach impractical, simply due to the fact that the addresses are liable to be constantly changing as they are dynamically assigned. However, in a situation where you not only have one or two fixed IP addresses, but also where only a few people need access to the systems, this may be just the trick.
LMHOSTS file works this way: you indicate the address and name of the system you want to use, along with any relevant domain information. When Windows loads TCP/IP, it knows the mapping file contains additional information. When you make a request to connect to a system and the system's name is not found by a DNS or WINS lookup, the LMHOSTS file is consulted.
# Lines that start with a "#" are generally a comment
# Unless they are providing parameters
000.000.000.000 MyServer #PRE #DOM:MyDomain
The IP address must start in the first column, followed by the NetBIOS name of the computer the address relates to. You should not assign an arbitrary name to the computer, instead, use the NetBIOS name assigned when the system was installed.
There is a fully commented sample file, LMHOSTS.SAM, automatically installed on your system when you install TCP/IP. While the file is a good explanation of what to include in the LMHOSTS file, be sure you do not use this file "as is" for your real mappings. Create a new file, listing only the associations you want to call out.
The entire file is read and parsed each time it is consulted, and if your file contains the vast array of comments found in the sample, you may find that this process has a negative impact on performance on your system. |
In most systems, you have better luck with the LMHOSTS file if you use the #PRE option. This option loads the names and IP addresses at the time TCP/IP is loaded, making them available immediately when calls are made, rather than having Windows parse the file each time you make a request.
In actual use of LMHOSTS, you'll find there is a marked increase in the successful connection to resources outlined in the file if the #PRE option is used. Also, be sure to include the monikers, e.g., INCLUDE, PRE and DOM, in all uppercase. |
The big downfall of LMHOSTS is two-fold. First, wonderful tools are available to you in the DNS and WINS services. These tools provide these identical lookups and are far more optimized to respond to the dynamics of the network environment.
Second, you must keep the LMHOSTS file(s) up to date on each and every system on which they are referenced. You can dodge this bullet a little bit by creating common include files that each system's LMHOSTS file refers to. Consider the following LMHOSTS file:
# Lines that start with a "#" are generally a comment
# Unless they are providing parameters
#INCLUDE \\netserver\profiles\lmhosts
000.000.000.000 MyServer #PRE #DOM:MyDomain
The special #INCLUDE token allows you to include the contents of another file in your LMHOSTS file. Using this approach, you can create a common LMHOSTS file that each user refers to. If the users have individual mappings to add, they do so by adding them before or after the #INCLUDE.
You can then do normal "Net USE" type of operations and connect to the remote system, just as if you were on the network local to that system. With NT Server, you're still assured of solid security, as the same security rules will apply. You'll need to be a valid, authorized user on the remote system, and your user properties will be applied against any and all access you request.
You can use the LMHOSTS file to map your system to other servers that may be on the Internet. For example, if you know an NT Server is set up and you have rights on the system, you can establish a connection to it. Use all the standard Windows tools by simply creating a mapping for it in your LMHOSTS file, restarting your system and connecting to the Internet by whatever means you use.
On Windows NT and Windows NT Server, the LMHOSTS file must reside in the SYSTEM32\DRIVERS\ETC subdirectory under your Windows tree. In Windows for Workgroups and Windows '95, LMHOSTS resides in the WINDOWS subdirectory (the point from which your main Windows system loads).
In short, use the LMHOSTS capabilities when you need specialty mappings, those IP and system name mappings not of general benefit or not provided to other users on your network. If you need to provide your user base at large with specific access to other systems, use the WINS static mapping capabilities.
Windows for Workgroups introduced peer to peer networking for Microsoft platforms. Peer-level networking means that workstations share information stored on their local hard disk with other users on the network. While this is a great way to share small-to-medium amounts of information and numbers of workstations, a serious bottleneck arises as the number of workstations and the traffic they generate grows.
The bottleneck is the result of the requirement to manage access to the information and balance performance on a given user's system vs. the access to the information over the network and more. In systems where the number of workstations and the amount of shared information becomes a burden on the network, consider implementing a more "industrial strength" solution. That's where Windows NT comes in, and with it, domains become part of the network picture.
Figure 2.15 shows a sample domain configuration with a two-server domain and a single-server domain.
Fig. 2.15 - Servers belong to only a single domain while users and systems can use more than one domain.
At first, system administrators may argue with this figure, because workstations belong in one domain or another. The point of the figure is: servers belong to one domain and one domain only. Workstations and users sign into and out of different domains, as needed, as long as they are authorized in another domain. The important thing is that once you enter, or logon to, a given domain, you must abide by the domain's accompanying rules and security parameters.
Be careful setting up user policies and rights on your network servers. When you install IIS, it will create a special user that it will attempt to use for all accesses to the network. This may seem to simplify management of the server rights, but it actually has a tendency to complicate things.
Because you only have a single user account to work with in establishing rights, you need to be very careful on what you allow the account to access. Remember that if you grant access to materials for the account in anticipation of a certain user or user group using the system, not only that user will be able to see the information, but all users logging in to the system. You can protect information and force a user to authenticate themselves on your server, but that requires that you establish user accounts for the secure materials. This is the correct way to approach managing the users; allow the broadest, most unsecure access to the default user, but disallow access to any protected information you may be concerned about.
Once you've determined the information that you want to protect from the general public user, create users and assign them appropriate rights that allow them access to the materials. This way, when IIS attempts to access the information, it will prompt the user for their user name and password, and it will only allow them to work with the protected materials if they are authorized.
FTP is a different security concern because it allows the user to sign in directly to your system, specifying a user ID and password. Typically, users sign on by indicating the user "Anonymous" and the provide their email address in the password field. However, those posing the biggest threat to your installation are seldom "typical" in their use of the system.
Chapter 9, "Security Issues--Firewalls and Data Security," as well as other upcoming sections, present system security and offer different strategies for you to use at your site. In addition, setting up these rights for users is a focus as you begin to lock down your site, protecting it against any possible intruders.
You can work with more than one user at a time. If you manage existing users and want to set up the group associations, logon times and many other attributes, first select the users from the list by shift- and control-clicking the names on the list and then selecting User, Properties.
Fig. 2.16 - Users belong to groups, and you control access to resources by either these group assignments or the individual users.
Be very wary of one particular user. Consider strongly whether to disable the account altogether. The GUEST account is as dangerous as any user that logs on to your system without a valid user name and assigned password is assigned to this account. Therefore, any privileges given that account are automatically provided to any user signing on to the system without otherwise-defined access.
The built-in Group, EVERYONE, is also in the system. Every user and group belongs to this group. In addition, this is the default privileges group provided access to all resources when they are created, unless user access is explicitly revoked or modified. This means you can assign rights to limit access to your users, but, without removing the rights for the group EVERYONE on the resource you set up, all users still have access to it. |
In almost all cases, your best option is granting groups rights to resources, rather than granting these rights to users. This is true even in those cases where you grant access to a resource only to a single user. You'll save time and effort later when the user is either replaced or gains an assistant the needs to have the same level of access. When that happens, you need only modify the members of the group. You won't need to change access privileges on resources on your system. Therefore, consider the following steps in planning to implement your system's user database:
Windows NT assigns user rights based on a "Least Restrictive" model. This means if you belong to two different profiles and one profile indicates you have no access to a resource, but the other indicates that you have access, you can gain access to the resource. This is because the least restrictive of the two profiles indicates that you are allowed access.
Put simply, any user you assign to the NOACCESS group, but that is not removed from other groups, may have more access rights than you planned. The effect of the NOACCESS group may be weakened, because the other groups allow overriding user rights, granting user rights to certain resources. In general, when you try to revoke access to an individual, be sure to review the associated account and make sure it does not belong to other groups that may also influence effective rights. |
Fig. 2.17 - By copying an existing user, you inherit the groups and privileges of the copied user, making it easier to create new users.
If you select the Must Change Password option, first-time user logs onto the system. They must change his/her password. This may seem like a good idea at first, but be wary of the user's particular type of system. In some environments, specifically Windows 3.x systems, the system may not allow them to change their password. In these cases, you effectively lock the user out of the system, because NT bars them from the system until the password has been changed.
If you have a user blocked from signing on to the system, review the account and make sure this option is not checked. Also, make sure the Account Disabled option is not selected. This also prevents access to your system. |
When you set up IIS you do not have to establish a user account for every person connecting to your server. You only need to set up accounts for the default IIS users you set up, and any specific privilege groups and/or accounts that you may need to set up. Specific privilege accounts are those accounts requiring different access rights, above and beyond those afforded the your typical user.
By default, you do not have to set up the anonymous users for your Intranet server, at least on a general access basis. Chapter 10 explains that installing IIS automatically creates the user associated with providing general access to your IIS controlled directories.
If you have Exchange installed on your server system, when you select Add to insert the new user, Exchange steps in and allows you to also set up a user's mailbox for the new user. |
The next sections briefly cover the different aspects of the user account.
Fig. 2.18 - Work with users in groups to simplify management tasks.
When you assign a user to a group, he also affords the rights and privileges associated with that group. By double-clicking groups listed in the Member Of: and Not a Member Of: listboxes, you add and remove membership in groups. After the user is assigned to the appropriate groups, select OK to save the changes and return to the new user's properties dialog box.
As you can see in figure 2.19, you specify the path to the USR or MAN file containing these settings. This way, when a user logs in to the system, these preferences are loaded and the environment looks and operates the same, whether he/she logs in from his/her desktop system or a neighbor's system. When you set up profiles, you indicate whether they are MANdatory or USeR related. If MANdatory, the file is saved with a MAN extension and the user cannot make changes to the profile. If USeR-oriented, the user is able to make changes, and the changes are saved to the profile for the next session.
Fig. 2.19 - Setting up user profiles gives the user a machine-independent look and feel, decreasing user anxiety in moving between or among systems.
Establish user profiles using the User Profile Editor available on the Administrative Tools menu from the Windows NT desktop. Figure 2.20 shows the Profile Editor and the different options it allows you to manage. The key thing to consider when you create these profiles is the level of user that you support. If there is a chance that the user will "accidentally" delete all entries from a program group, you may want to consider locking the different program groups. The Profile Editor has two distinct purposes: first, to provide the common user interface users expect when logging on to the system, and, second, to afford the user self-protection in warranted cases.
Fig. 2.20 - The Profile Editor sets up profiles that may be referenced then either setting up or modifying user accounts.
When you select any of the File, Save... options, shown in figure 2.21, you can determine the scope of your new or changed profile and its storage location. Provide this information to the User Manager in setting up users.
Fig. 2.21 - Once you create the user profile, you have several options for both saving and applying the profile from the File, Save options.
Fig. 2.22 - By specifying the allowed logon times, you control after hours exploration, or even hacking, of your system. This is especially useful when you begin to open up your server to the volumes of content provided with an Intranet server.
Fig, 2.23 - Controlling the computer logon points limits "roaming" between computer systems and departments where security is a concern.
If you then need to grant access after hours to certain materials, can create a new user accessible only after hours. Restrict this user so that he is only allowed on the server during these hours, and from specific workstations.
Another big use for controlling logon workstations is the case of Remote Access Services users. RAS users present some unique opportunities for tampering with your system. However, there are several different things you can do to limit or control their access while providing the needed information and access. Consider creating a new user, assigning specific allowable logon times and then assigning a specific logon workstation. An example might be the NetBIOS name of the user's laptop. This prevents another user from attempting access on three different levels, a significant barrier to entry into your system.
If you find yourself faced with the need to set up a very secure system, consider using multiple user accounts for different key employees. Set up accounts with specific rights during normal business hours to allow the accesses necessary to accomplish the required tasks during the day. Then set these accounts so the user cannot logon after hours.
Fig. 2.24 - Controlling the expiration date manages temporary accounts very well.
It is an excellent policy to add a new item to your employee termination and temporary employee access permissions checklists indicating when an account expires. By setting this option, you prevent a past employee from gaining unwanted access to your server.
Never leave unused accounts on your system. This is a key tenet of system security. It applies even more in those cases where you open your system up to the Internet. Set the expiration date here, and disable the account when it is no longer in use. You can opt to change the user name, adding a prefix of "XPIRE," etc. This floats the name to the bottom of the alphabetical display of users. However, if, in the future, you need to know what access was gained, this process saves completely deleting the account from the system.
Global groups relate to network security and are referenced by other network servers in the current domain. Although you may have both types of groups on your system, the global group is the most commonly established type. Global groups cannot contain local groups. This is because local groups are not visible between servers in the domain. Local groups can contain global groups, but you cannot reference a local group from another server. See figure 2.25 for a local group dialog box, and figure 2.26 for a global group dialog box.
Fig. 2.25 and 2.26 - Groups are the key to user security on your system. You create groups specific to this system, as seen in a Local group, or you create groups relevant to the entire network, as seen in a Global group.
Remember, the order of rights assignment is key. First create the user and assign their group affiliations. Next, assign rights to the groups as needed. As a reminder, try to avoid assigning rights to the user unless you have a warranted exception. |
The Windows Explorer is the key to applying security to different resources on your system. Select the directory resource you want to share and right-click it. The menu, shown in figure 2.27, has an option to establish the sharing for the resource.
Fig. 2.27 - Select Sharing from the menu to set up or maintain sharing options for the highlighted resource.
Selecting sharing not only sets up the share name and the number of users accessing the resource, but it also offers the option to set permissions on the resource by selecting the Permissions...button. Figure 2.28 shows the dialog box setting these initial options.
The information presented here on securing share-level security on your system pertains to setting up shares on the server. With IIS, security is enforced by way of NTFS and directory level privileges. If you establish rights based on a share, they are not enforced unless the share is accessed. If you use the directory related to by the share, without using the share, the rights will have no effect. If you are in need of protecting content on the site, you must use NTFS for the file system and you must set rights based on the permissions, outlined below, for the directory, not the share. More information about this is presented in Chapter 10, where you'll see how to set up directories with user-specific rights and privileges. In addition, throughout this book you'll find examples of setting up secure areas on your system.
If you select a share name of more than the DOS-standard 8.3 format, some DOS workstations may not be able to access the resource. If you do select such a name, you are warned about this fact as you apply the share information for the resource. |
Fig. 2.28 - Setting up the initial share information is pretty straightforward. By default, the maximum number of users allowed access to the resource is unlimited.
If you select OK or Apply, at this point, without setting Permissions, all users with access to the resource via a share, a parent directory, etc., have open, Full Control access to the resource. Be sure to select the Permissions button.
The underlying file system dictates how permissions change. If the NTFS, NT File System, is installed, you gain additional options. These allow you to apply specific permission subsets, rather than just generic permission categories.
When you select Add...,you have two options: First, you can select single or multiple users and groups. Second, as a set, you can assign rights applying to the set of users. When you select OK, the users are listed in the permissions text box. This verifies that the permissions are properly applied. Selecting OK once again saves and applies the changes. Now the resource is available with your declared permissions
The net result was to bar the group EVERYONE from all access to the system. You cannot remove this built-in group, but you can explicitly remove it from the access control lists for the different resources on your system. By removing the rights for the group, you establish meaningful rights for the different users on the system. This had the side effect of easier administration of the IIS installation as well. Users accessing the system from that connection, via the Intranet and Internet, now fall under the control of the security system.
The decision was also made to disable the Guest account. The positive side of this is that there are no default rights on the system, only explicitly granted rights. The negative side is that, while there may be legitimately public information on the system, users must be granted rights, even to public information, before they will be able to access it.
Security is one of the most intricate equations you face when bringing up and managing your Intranet system.
A full tutorial on Windows NT Server is far beyond the scope of this chapter and, indeed, this book. This information is provided as a starting point to provide information on implementing the core services relied upon by your Intranet.
For additional reading on these topics, consider the following sources:
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.