Introduction


Chapter eight examines the functions performed by servers on the network, breaking them out into four areas (authentication, disk sharing, printing and applications). This chapter does not attempt to dissect the inner workings of server operating systems and network-based applications. Instead, the goal is to impart an understanding of the fundamental services that servers provide such that you will be able to understand and analyze working servers and applications in the field.

  1. Authentication: validating users and requests
  2. Disk sharing
  3. Printing
  4. Client/Server applications
  5. Conclusion
  6. Self Check



[ I ] Authentication

"Halt! Who goes there - friend or foe?"

Authentication is the term we use to describe the functions users associate with logging in, logging out, passwords and user IDs. Authentication has three main functions:

  • Permitting access to authorized users
  • Denying access to unauthorized users
  • Regulating user actions

Permit/Deny

The simplest form of authentication is to require that the user possess a valid user-id. The user identifies himself by a name to the computer, the computer then checks that name against a list of names. If the user's name is on the list, the system grants him access.

The most common form of authentication is a two-part user-id and password challenge. A "password" is a word, phrase, or other collection of characters that only you and the computer know. If you're ID is good, and the password you supply matches the one on record, access is granted.

NOTE: A well designed login system will challenge the user for a password even if the user-id entered by the user is invalid. Similarly, it will not tell the user which part of the user-id/password pair was incorrect. The idea is to deny a would-be intruder any knowledge as to whether he's hit upon a valid user-id or not.

Password Storage



This security thing really is a paranoid game. 		Users' passwords are almost always stored in an encrypted format. The idea is to prevent password abuse by the system's users or administrators; if passwords were stored as "clear text" then whomever had access to the password file would be able to see everyone else's password and thus be able to sign on to the system as another user – perhaps just as a prank, perhaps to do worse.



There are a number of utilities out there to crack the password files used by many common operating systems. Some of them will reduce the average password file to a hacker's treasure-trove in a matter of minutes. Microsoft Windows NT is apparently very easy pickings; Windows 2000 is supposed to fix all this. 		The most common method for storing encrypted passwords is through a "one way DES" algorithm. DES, or the "Data Encryption Standard" is a mathematical method for taking something you want to encrypt (in this case a user's password) and combining it with a key of up to 56 bits to produce the encrypted data. In one way DES there is no way to decrypt the password once it is encrypted. Validation is performed by taking the password supplied by the user at login, encrypting it on the spot, and comparing the encrypted output with the encrypted copy on file. Logically, with one-way DES, if the two outputs match then the two inputs must match as well.

As computers become more and more powerful, the ability to "break" encryption schemes through application of raw computing power comes into more and more hands. There is currently a move away from DES (with its 56 bit keys) to stronger encryption systems which employ longer and longer keys. The longer the cipher key is, the harder it is to break. The computing time required to break 2048 bit key is astronomical. But then again, computers get faster every day.

United States export laws regulate "strong" encryption (algorithms that use keys over 40 bits long) as if they were munitions. Yes, US technology export controls treat the 128-bit encryption in MS Internet Explorer 4.0 the same way they do Tomahawk cruise missiles. There is a growing amount of industry pressure to change this so that US firms can compete in the global market for encryption products. Congress has been dragging its feet due to counter pressure from the intelligence and law-enforcement communities.

Password Do's and Don'ts


DO:
  • Require users to use a password
  • Force users to change passwords regularly
  • Keep a written copy of administrator passwords in a safe place
  • Keep a record of old administrator passwords
  • Use numbers and "shift" characters if your OS supports them


DON'T:
  • Use passwords shorter than five characters
  • Use names, birthdays, usernames, or other words easily associated with you
  • Use "password"



[ II ] Disk sharing

One of the two fundamental NOS functions is providing client systems access to the server's disk drives for file sharing, exchange, safe storage, and collaborative work. The method for accessing the server's disks is dependant on the client machine. An Intel-based PC running Windows 95/98 will use a different method to access server drives than a RISC-based UNIX workstation.



A "volume" is a logical unit of storage. It may take up part of a physical disk drive on a server, all of the disk drive, or it may span across multiple disks.

Mapped Drives

PCs running MS-DOS, Windows 3.x, Windows 95/98, Windows NT, and OS/2 use the concept of the "mapped" drive letter. On these systems physical devices like diskette drives, hard disks, and CDROMs are referred to by drive letters -- A: B: and so on. Drives A: and B: usually point to floppy disk drives; C: is the first hard disk, D: would be the second (or a CDROM drive) and so on. Each PC can reference 26 drives (A - Z) this way. We use the upper letters of the alphabet (traditionally starting with F:) to point to volumes on servers out on the network.

PC Client Server Type
PC NFS UNIX
NetWare Shell / Requestor NetWare / IntranetWare
IBM LAN Requestor OS/2

There are three types of mapped drive: "general", "false root", and "search". A general drive mapping assigns a drive letter and points it to the top of the directory structure in a volume on a server. A false root drive mapping assigns a drive letter to an arbitrary spot somewhere in the directory structure in a volume. If the volume has a directory structure like this: 


          /
          |-etc
          |-system
          |-apps
          |-users
              |-joe
              |-polly
              |-sue

The "PATH" is a series of directories that a PC's operating system will look in to find a program before returning "Bad command or file name". Commonly the C:\DOS directory is in the path, as well as entries to locate files associated with Windows and utility programs. Even Windows NT uses the PATH. To check your path type "env" from a DOS prompt. We could map drive "H:" on a user's PC to "start" at /users/polly ...All they would see by changing to their H: drive would be the files in the "polly" directory and any directories beneath that. This is very useful for setting up users' "home" drives on a network.

A search drive is a drive letter mapped to a place on a volume that has something (usually a utility program) that we want users to be able to access without knowing exactly where it is. By setting a search drive in the PATH on the user's PC (usually done automatically at login time) the user can start a program just by entering its name -- he's saved from having to know exactly where the program is, and the PC's operating system will find it for him.

Graphical Navigation

PCs running the Mac OS, Windows 95/98/NT, OS/2, and versions of UNIX with graphical interface allow users to navigate through servers, volumes, directories, and files using graphical representations of each item. This enables the user to "drill down", by clicking on icons with a mouse, from the top layer of a server or a local disk drive until he finds the file(s) he's looking for. Fans of Microsoft Windows 3.x will point out that it has a GUI file manager, but the integration of the GUI and the file system is not very tight. Compare a Windows 3.1 system with an NT 4.0 workstation and the difference will become clear pretty quickly. The graphic below shows the author's desktop using GUI file navigation.

Graphic of typical Windows 95 desktop


UNCs and URLs

Navigating through a GUI interface to locate files is not very efficient if you are in a hurry, or if you have to do it over and over again. In response to this, Microsoft developed the "UNC" or Universal Naming Convention. A UNC is a text string that identifies a server, volume (or share name), a number of directories, and (usually) a file name. EG: \\main_server\users\joe\docs\paper1.doc Not only is it faster to type a UNC than it is to get to the same location via mousing, but UNCs can be used to reference files and directories in batch files or scripts -- something that can't be done with pure GUI navigation.

URLs use the "front slash" while UNCs use the "back slash". These are hallmarks of the origins of the UNC in MS-DOS and the URL in UNIX.

A cousin of the UNC is the "URL" or "Uniform Resource Locator". URLs are used to locate information (most commonly on the Internet) through browsers. URLs are text strings like UNCs, except that the first part instructs the browser to use a specific protocol to retrieve the information. EG: http://www.coke.com/softdrinks/free_stuff.html

UNIX and NFS

So far we've looked at networked disks from the perspective of desktop PCs, mostly Windows-based Intel systems. Let us turn our attention to UNIX systems and take a look at NFS - the Network File System (also called the "Nightmare File System" by those who survived its early days). Why look at NFS? Many businesses, schools and other institutions have UNIX systems running as database servers, web servers, mail hosts, and high-end workstations. Even if you only deal with Windows PCs you will probably be faced with connecting that PC to a UNIX system at some point in your career. Before NFS will make any sense, however, we need to have a grip on the fundamentals of the UNIX file system.

PCs use the "drive letter" concept to reference different disk drives. UNIX uses an entirely different idea. On a UNIX system all of the disk drives on that system appear to be part of one big directory structure. Everything starts from the root directory - / (or "slash" directory) and extends outward from there. The disk that contains the / directory (and usually the other directories and files needed to boot the system) is called the root disk. Other disks containing their own hierarchies of directories and files are "mounted" over directories on the root disk. The root disk of a UNIX system may contain the following: 

          /
          |-etc
          |-bin
          |-home
          |-tmp
          |-usr
          |   |-lib
          |   \-sbin
          \-var
              |-spool
              \-adm

Another disk in the system (call it HD2) might have the following directories and files in its file system:

         /
         |-jane
         |-max
         |   \-files
         |-robin
         |   |-docs
         |   \-pictures
         \-toad
             \-mail

If we mount HD2's file system on top of /home on the root disk, the user will see a file system that looks like this:

          /
          |-etc
          |-bin
          |-home
          |   |-jane
          |   |-max
          |   |   \-files
          |   |-robin
          |   |   |-docs
          |   |   \-pictures
          |   \-toad
          |       \-mail
          |-tmp
          |-usr
          |   |-lib
          |   \-sbin
          \-var
              |-spool
              \-adm

The "joint" where the file system on the root disk leaves off and the file system on HD2 begins is entirely transparent to the users on the system. In this fashion very large file systems spanning many disks can be built. NFS takes this concept and extends it from one machine to another across the network.


If you hear an ad from Sun Microsystems with their "we invented network computing" slogan, this is what they're talking about.

The administrator of one UNIX system can decide to make part (or all) of the file system on his machine available for other systems to mount using NFS across the network. (Making part of your file system available for other systems to mount is called "exporting"; the file that controls what is exported, to which systems, and what privileges they have, is called /etc/exports.) Systems with NFS client software mount the exported file system from another machine just as if it were another local disk. To the users on that system it still looks like one big directory tree -- regardless of the fact that it may reside on numerous local disks and on disks attached to remote systems. The /etc/exports file controls the privileges which whole systems have on the exported file system; user and group security controls what individual users can do. The more restrictive setting wins. For example: if a user has full rights in a file system, but part of it is mounted via NFS and the exporting system only gives read permission to the mounting system, then the user will only have read permission in that part of the file system.

[ III ] Printing

Network printing is the second of the two fundamental NOS functions. Disk sharing and network printing are often lumped together in the same breath as "file and print". The core idea behind LAN-based printing is to enable multiple users to share access to a printer. This is desirable for a couple of reasons. First, the cost of a printer per user is greatly reduced if that cost is divided by twenty instead of one. Second, that per-user cost savings can give an organization the ability to buy a faster / more capable printer than they could justify for just one person.







In the UNIX world programs that run all the time in the background looking for input to act upon, such as a print spooler, are called demons.

Network Printing Mechanics

The mechanism that underlies LAN printing is fairly straight forward. It consists of the following steps:

  1. The user initiates printing from their application
  2. A temporary file containing the print information is created
  3. Software on the client station sends the temp file to a print "queue" on the server
  4. The server stores the temp file in a directory on the server that is associated with the print queue (a "spool" directory)
  5. A print server (or print "spooler") process constantly checks the queue directory for temp files waiting to be printed. The spooler sees the temp file in the queue directory and sends it to the printer

Generally print jobs are handled on a first-come first-served basis. However, most server operating systems provide utilities to cancel, hold, and/or reschedule print jobs.



HP is the dominant vendor in the network printing environment. One of their leading items, the HP JetDirect network interface, is pictured below along with a link to their printing site.


Spoolers and Print Servers

We hinted at it above; a print server is a process running on the server itself or on another system that waits for print jobs to arrive from the user and then automatically sends them out to the correct printer. One print server can handle multiple printers and multiple print queues. In high volume printing environments more than one printer may be assigned to service one queue. A printer with many differnet input/output options may have a number of print queues associated with it, each queue being set up to take advantage of a different feature of the printer.

Network printers may be directly attached to the server (through parallel or serial interfaces), or they may be connected over the LAN through a network interface in the printer. In this case the printer often runs the print server process and the file server becomes just a centralized holding place for print jobs waiting to be printed.



[ IV ] Client/Server Applications

Client-server application development is the fastest growing area in Corporate Information Systems (even with all the hype over the Internet, intranets, extranets and e-commerce). We're all familiar with one-piece applications -- things like PC word processors and spreadsheet programs. Client-server applications look much like "monolithic" one-piece applications, except that the functions in the application are broken into two or more pieces that run on different systems. Generally we refer to client-server apps as having a "front end" and a "back end".

The front-end is the part of the application that the users interact with. Its job is displaying output to the user, accepting user input, and communicating with the back-end. The back-end is the part of the application that primarily deals with handling raw data. Two every-day examples of client-server applications are: web browsers (eg: Netscape Navigator) & web servers; and email clients (eg: Eudora) & POP-mail servers. Client-server applications are used for every commercial computing need where a large number of users need to access a large amount of centralized data, such as a financial accounting system or an inventory control system.

Client and Server Communication

Communication between client and server relies on the network. The server software "listens" for requests from clients. The requests are addressed to a "port" on the server system. A port is analagous to a Post Office Box: all the mail goes to one building, but it gets delivered to the right person based on the PO Box number. For example, a PC running client software and using the TCP/IP protocol might send a request to a server application at host 132.99.45.12 port #5590. The server would receive the request on its port, take whatever the appropriate action is (looking up a customer's order history perhaps) and send the appropriate response back to the client. Each server application running on a system has a unique port address so that one computer system can support multiple client-server applications. Both TCP/IP and IPX/SPX support "ports" (sometimes referred to as "sockets" or "streams"). A listing of common TCP/IP ports is available here.

C/S Security

Client-server applications generally use some form of authentication to validate requests coming from clients. Usually this is in the form of a userid/password challenge. Many C/S systems bolster user authentication with encryption schemes to keep intruders from eavesdropping on communication between the clients and the server. Security design in the mainframe and minicomputer environment is a fairly tried-and-true practice. Security in the client-server arena is still being worked out. So, any client-server applications you specify should be evaluated carefully with an eye toward security. Remember: mainframe applications run on single systems within the confines of the "glass house" datacenter and have had decades to mature into robust and secure apps; client-server applications are a new breed. They are creatures of the network so both security and performance need to be evaluated with the entire network in mind, not just the client and server end-points.
[ V ] CONCLUSION

Chapter Eight introduced the mechanics of several critical network functions: authentication, file and print sharing, and client/server applications. At this point you should be able to name the functions of authentication, identify which type of file access a client is using to access a given server, and trace the progress of a print job from source to destination.
[ VI ] SELF CHECK

  1. What are the three functions of authentication?

  2. How should a well-designed security system handle a mis-spelled userid?

  3. In a sentence or two each, explain the reason for each passowrd "do" and "don't".

  4. Explain how each of the three types of mapped drives works.

  5. Aside from the direction of the "slash", what is the primary difference between a URL and UNC?

  6. How does the UNIX file system differ from the DOS file system?

  7. What two factors make shared network printing desirable?

  8. Explain the process of network printing in your own words.

  9. List five client server applications not mentioned in the chapter.

[ CH 7 ] [ TOC ] [ CH 9 ]
Back to top
© 1998,1999,2000 Shipman | Created 3-16-98 | Updated 2-5-00