You have probably noticed in the papers recently a lot of talk about the newest catalyst for change in employee work habits. Remote access or more popularly telecommuting has been heralded as the future of employee interaction with the workplace. As the word indicates, in tomorrow's world, employees will be able to sit at home and access resources at work--as if they were sitting in their offices--"commuting" over phone lines. They will be able to take calls from customers, access corporate databases, e-mail, and productivity applications without doing much of anything different on their PCs. While you may be skeptical of how seamless this would be--and rightly so--true telecommuting is closer than you think. Many companies either offer some kind of telecommuting services or are seriously looking at it right now.
Thanks to improvements in modem technology, growing acceptance of ISDN, and better application software in support of remote access, we now have the tools to provide quicker, easier access to all kinds of corporate data from almost anywhere. Of course, along with this ability comes a whole set of challenges for making such a system robust, fault-tolerant, secure, and flexible. You need to be able to provide it in such a way that it's supportable, manageable, and scaleable because you can be sure that once in place, more people than you expected will want to utilize remote access services.
In this chapter, we'll review some of the communications media available for remote access. We'll discuss the differences between the old way, remote control, and the new way, remote node, and where each has its place. Then we'll look at how to implement a telecommuting solution, including perhaps the biggest challenge--security. We'll also look at the various product-based software and hardware solutions to provide remote access as well as services that may be available from your local telephone company. Finally, we'll take a brief look at the organizational issues to be aware of when implementing a telecommuting solution. By the end of this chapter, you will be versed in the key concepts behind telecommuting and how best to implement it in your organization.
Nowadays, there are many different media that we use to communicate. When we use that media, whether it be by making a voice phone call, sending a file across an Ethernet LAN, or dialing up a modem on our PC to access an internet provider, we enter a network using one topology, traverse either a public or private system of maybe a differing topology, and end up on some remote network of perhaps a third topology. The understanding of the different types of media, and their inherent characteristics, is key to developing an understanding of the issues around implementing remote access. This is due to the fact that as you develop a plan to implement a telecommuting solution in your environment, you may be forced to choose between one technology or the other based on cost, performance, or even availability, and it's imperative to know what each technology's advantages and disadvantages are.
While ISDN may be the next big technology for telecommuting solutions, the history of remote access has been defined by relatively slow-speed analog modems. As a result, this slow technology has very much affected the course of software development designed to facilitate telecommuting. In the days of DOS, 2,400, and even 9,600 bps analog modems, remote access had to be as efficient as possible, providing maximum functionality using limited bandwidth. This need prompted the development of so-called remote control applications.
Remote control software uses a simple concept to allow remote users access to corporate network resources. A host PC, connected to your corporate network, runs a piece of remote control software. It may then have a modem connected, or it may be connected only through the network. A remote user running the client piece of the remote control application dials up the host and takes over the host's screen and keyboard. That is, the remote user sees what a user sitting at the host PC would see. The application that the remote user launches is actually running on the host PC, not the remote one. This means that the speed of response for the remote user is dependent upon not only the modem speeds but also the horsepower of the host computer executing the application. When the remote user uses the keyboard or mouse, these commands are sent to the host as if the user were pressing keys or mouse buttons right at the host PC.
Software packages like PCAnywhere and Carbon Copy were some of the first using this remote control approach. As a result, only keystroke and mouse commands are sent across the wire, as are screen updates. Since this is a fairly low bandwidth type of transfer under an operating system like DOS, you could get fairly decent performance and had access, at least visually, to all the applications you normally would if you were sitting on the corporate network. If you want to actually transfer files to your remote PC from your network, you usually have to open an application under the remote control software that performs an asynchronous file transfer similar to your standard communications software using, for example, the Xmodem protocol.
When Windows hit the scene, remote control applications required some fine-tuning. Even sending only screen, mouse, and keyboard updates of a GUI-based environment like Windows required more bandwidth and, indeed, the first Windows-based remote control applications, used with the then current 9,600 bps modems, were painfully slow.
Uses of Remote Control. Because remote control applications pass only screen, keyboard, and mouse updates, they were useful for providing access to applications that would be too slow for users connected directly to the network via modem. This included applications like PC-based database systems or system administration tasks using GUI-based front-ends. Some LAN protocols didn't have the ability to provide dialup network attached connections. Interestingly, Novell's popular IPX network protocol was chief among those protocols that did not have available dialup software for quite a while. As a result, the only remote access solution was remote control.
Advantages. As indicated previously, remote control provided a means of providing remote access to your corporate network applications using relatively little bandwidth. Indeed, while remote control is quickly being replaced by remote node access today, there are still many advantages to using remote control in the LAN and WAN environments. Today's remote control applications have been optimized for GUI-based environments like Windows 95 and NT. Instead of passing screen and keyboard updates directly, today's programs allow the remote user to issue keyboard and mouse commands that get converted to direct device calls and are then sent to the host and delivered programmatically. In this case, for example, each pixel doesn't have to be sent to the remote user each time she scrolls a window; rather the Graphical Device Interface (GDI) commands are sent to the remote PC, where the screen responds accordingly. There are also some mechanisms that ensure that the screens on both ends are synchronized.
Remote control still has an important role to play as a troubleshooting and training tool in a LAN/WAN environment. For example, a system administrator might get a call from a user two states away who can't figure out how to access a macro in a word processing application. The administrator could take over the user's PC and guide the user through the process while the user watches and talks to the administrator on the phone. This kind of application relies on a higher-speed network infrastructure than analog modems but represents a good way to leverage existing remote control applications for use by LAN administrators and trainers.
Disadvantages. As mentioned earlier, remote control has played an important part in providing remote access to corporate network resources in the era of slow analog modems. But as we move into faster technology on both the analog and digital side, remote control has a number of costly disadvantages that make deploying it as a supportable remote access solution difficult to justify. Principally, remote control relies on the concept that for each remote user dialing in, a host has to be dedicated for that user to take over. This requires placing a dedicated PC resource on your network for each user who wishes to dial in. Not only is this costly, but it does not represent a very supportable solution.
There have been products that attempted to address this issue by providing turnkey platforms that utilize a single network-connected PC, running a multitasking operating system like OS/2, with specialized remote control host software. This PC would also contain some multi-port asynchronous serial card, supporting some number of modems (usually in 8-port increments). The product, called WinView from Citrix, was a good example of this. When a user logged on, he connected to the host and started a virtual Windows session under OS/2 (see fig. 27.1).
Figure 27.1
An example of a remote access configuration using a multitasking remote control server.
Depending on the resources of the host PC, you could accommodate several users at once, each remote controlling her own virtual Windows machine. This remote control approach, once stable, was a good solution for smaller remote access needs, but it simply didn't scale well. With anything more than 20 or 30 remote users at the most, imagine how difficult it would become to troubleshoot and manage a number of multitasking servers running numerous virtual remote control sessions over analog modems. Since remote control does not pass network protocols but does pass screen, keyboard, and mouse commands, it makes it very difficult to troubleshoot network problems. Any remote control solution, by definition, will require more host PC resources--either real or virtual--as you accommodate more users. This quickly becomes costly to implement and manage.
Since you are not actually connected to the network in a remote control environment, you cannot easily copy files between network resources and your machine. Generally, the remote control application requires you to start another file transfer application, which allows you to transfer files between your PC and remote resources, using some asynchronous transfer protocol like Xmodem. This is hardly easy to explain to a new user trying to do simple tasks remotely. While some remote control programs do provide some level of scripting to automate some of these tasks, it still represents a far more complex solution than simply being able to use a DOS copy command or the Windows 95 Explorer.
Finally, if you are still convinced that remote control is for you, consider that security should be one of your biggest requirements when providing access to your network. Given that, most remote control packages provide little serious security. Most come with a simple password scheme that may or may not synchronize with the network security you may already have in place. Many support callback, which means you can have a user dial up the host and then have the host disconnect the call and dial back the user at a predetermined phone number. This guarantees that the user is calling from a known location. Unfortunately, it does nothing to protect against someone using a remote user's PC without his or her knowledge at the given location.
NOTE: In general, unless you are building a very small remote access solution (fewer than 10-20 nodes), you should consider saving your remote control money and putting it into a remote node solution (discussed in the later "Remote Node" section).
Issues of Implementing Remote Control. Though we have discussed how remote control works in general, there are a number of points to consider if you decide to implement a telecommuting solution using remote control. First, make sure that you test modem compatibility end-to-end. Keep the list of accepted modems small, otherwise you will end up troubleshooting weird modem problems and learning more about the Hayes AT command set than you ever wanted. If you decide to use a version of remote control that uses the multitasking virtual machine method, make sure you err on the side of caution when specifying how much RAM and hard disk space you need. In this case, more is definitely better. Also, make sure the vendor provides a good way to manage the computer other than sitting at the console to check its condition. A good solution will provide some kind of remote management of the Remote Control Host, ideally using a standard management protocol like SNMP.
Since the advent of faster modems, the appearance of ISDN, and advances in software development, the remote node approach to telecommuting has become the preferred method to connect and manage remote users. Unlike remote control, where analog modems are used to pass only screen, keyboard, and mouse updates, remote node actually lets remote users act as if they are local to their home LAN. If a user normally sits in her office and connects to the corporate network via Ethernet, then remote node allows that user dialing in via modem or ISDN adapter to act as if she had extended that Ethernet across the phone lines to the remote computer.
Unlike remote control, which requires a specialized piece of client software running on the remote user's PC, remote node users actually run their network protocol stacks on their PCs, with a special driver to support either dialup analog modems or digital switched services like ISDN. That is, if you are accessing a Novell network remotely, you would run the IPX stack on your PC, and, instead of using a conventional Ethernet or token-ring MLID driver, you would have one that interfaced with your modem. Similarly, in the IP environment, your IP stack would interface with a Point-to-Point Protocol (PPP) or Serial Line Internet Protocol (SLIP) to access your modem.
Uses of Remote Node. Since remote node allows a remote PC to act as a real node on the network, extended through phone lines, it allows users to do things in generally the same way as they would at their office desks. That is, users log on as they normally do; access network drives and printers as always; run applications remotely like electronic mail, terminal emulation, host access; and, with some caveats, access word processing, spreadsheet, or other productivity applications' data.
Unlike with remote control, where applications run only on the host PC, all applications run over a remote node connection actually execute on the remote PC, just as normal network-connected clients do. As a result, it's important to recognize what effect launching an application may have across even a 28,800 bps modem line. This may be the single biggest limitation of remote node and requires user education to prevent undue angst on the telecommuter's part as he tries to launch a 6M application on a 14.4 or 28.8 modem. As more telecommuters move to ISDN, the effect of this will lessen, but there are definitely ways to optimize a remote node solution.
Advantages. The advantages of remote node are numerous, including better scalability, security, and manageability. For these reasons, most medium to large telecommuting solutions use a remote node type of access. This technology is more scaleable because it does not require any dedicated PC resources on the host side, as does remote control. Basically, any number of users may dial into the host, using either an asynchronous modem pool or leased lines utilizing any number of data services. Of course, the more users you have, the more modems you need to support. As an alternative, you can set up a leased line service at your host site, connected to a third-party network provider to provide higher bandwidth access to your users (more on this leased line method later). Remote node is also a more secure solution. Since your users are nodes on the network, they can utilize existing network password schemes to access resources, or with the help of third-party security tools, you can augment existing NOS security to provide additional protection. Finally, because remote node workstations run network protocol stacks just like normal LAN users, you can use the same network management infrastructure to manage remote user resources. This is very valuable when you need to control elements of remote access like user ID maintenance, resource access, capacity planning, and auditing of remote use.
Disadvantages. While remote node provides many features that make it the preferred telecommuting solution, it bears reminding that there are some limitations with the technology today. As alluded to earlier, certain kinds of operations should not be attempted across a remote node connection unless you have lots of bandwidth (for example, 2 `B' channel ISDN). Even then, the practice of launching Word for Windows across a remote node connection should only be performed in desperate circumstances! Remember that since you are passing network protocols to and from a server, for example, you have the same overhead that you do locally. This includes protocols that require an acknowledgment for each packet sent out on the wire and requires education on the part of the end user since you may not be able to explicitly prevent a user from accidentally loading an application remotely. Because you are loading a network protocol stack on the end user workstation, there is some additional complexity required to support such a scheme, which varies depending upon which network protocol you're running. For example, if you're using TCP/IP, you need to decide if you want to give each remote user a fixed IP address or assign one at dial-in time. Despite these limitations, however, remote node represents the best option for remote access in today's high bandwidth network environments.
General Concepts When Configuring Remote Nodes. To set up a remote node system, you must first answer some questions about your configuration:
Once you answer some of these questions, you are ready to begin implementing a remote node solution. Depending upon your needs, there are a number of hardware- and software-based tools for configuring support for remote nodes. Some of these are discussed in the later "Product Solution" section, but in general, there are a number of issues common to all remote node platforms.
First, you will need to allocate at least one server, communications server, or router, depending on your implementation for use as a remote node host. You may want to have a redundant host available, either up and running for high demand periods or as a hot spare in case your primary hardware fails. This device will be attached to your network on one side and to some phone network on the other. Next, you will need to provide the hardware to connect to whatever access solution you decide upon. This is described later, but in general, if you are using an asynchronous modem solution, you will need some kind of support for multiple modem ports. This may be a multi-port serial card for a Novell or NT server, or it could be a dedicated communications router that supports multiple modem ports on one side and standard network connections on the other.
After the host is in place, you will need either asynchronous or synchronous connections to the phone network. This may mean pulling a number of modem lines to your host or installing a leased line with DSU. If you decide to go with leased lines, make sure your particular remote node solution supports this kind of connection. Many low-end remote node solutions only support asynchronous connections. Next, you will need to configure your remote clients with a dialup protocol stack. Regardless of whether you're using Novell's IPX or TCP/IP, there are a number of access methods for each. For example, you can get a special MLID driver from some remote node solutions that runs just like a standard Novell IPXODI driver. A workstation with a driver such as this might load its network protocols as follows: LSL
DIALER
IPXODI VLM (or NETX) In this case, the DIALER driver has an associated configuration that uses the modem installed in the PC as if it were a network interface card, specifying the number of your remote node host to call. Other IPX client stacks, such as those that come with Novell's Netware Connect product, Windows 95's dialup adapter, and Windows NT's RAS client, implement IPX (and TCP/IP) over standard PPP or SLIP interfaces, utilizing these standards-based protocols for dialup access. Regardless of the protocol, there always has to be some driver that interfaces between the protocol stack and the modem or terminal adapter.
Once the remote client's protocol stack is configured, you will need to set up security on the host side. Depending upon your solution, you may not have to do much. Regardless of whether you're using a server-based host, dedicated communications server or router, you have the option of setting up the host to provide pass-through authentication directly to your network. In that case, the user authenticates once using her normal network password. Or you can implement more involved security schemes, where the user has to authenticate to the public network when she initially dials, then authenticate with your remote node host, and then authenticate with your network operating system services. This latter combination provides maximum security but may also induce an undue and unwelcome burden on your users.
PPP versus SLIP. When you're looking at configuring the client's protocol stack using, for example, either IPX or IP, you'll probably need to decide whether to use PPP or SLIP as the underlying network protocol. SLIP was originally intended for IP dialup connections and provides no functionality beyond the framing of an IP datagram for serial communications. It does not provide any dynamic addressing functionality, as does PPP, nor does it have any authentication or reliability services. PPP, on the other hand, was designed to be a multi-protocol interface between the network protocol (for example, IP or IPX), and physical medium. It provides for dynamic host address (in the case of IP), authentication (PAP and CHAP), and reliability mechanisms. PPP is the preferred method for most dialup remote node solutions. Make sure any client stack and host software or hardware supports PPP, as opposed to some proprietary scheme for transporting network protocols.
Client Configuration Issues. When configuring remote node clients, it's much more important to think about where applications are executed. This includes applications like Word or Excel, as well as LOGIN.EXE or any other utilities that you normally access on a local LAN. This is because the time it takes to load and execute these applications over a remote node connection, especially an analog one, will literally take minutes and frustrate the user. While it may seem like an added burden maintaining multiple copies of an application, this will allow your remote node solution to do what it's best designed to do: allow easy transfer of data between host and client as if they were directly connected to their network. Indeed, remote node is ideally suited to true client/server applications. In this case, the front-end sits on the remote client, and the back-end does much of the processing and returns only the results to the client front-end application.
TIP: In general, a good rule is to keep all executables that you plan on running loaded on the remote machine's hard drive. Do not run them from the server across the remote node connection.
Using Dialup Analog Lines. Analog modems, both on the remote and host side are probably the simplest to set up. They don't require any specialized knowledge, as do leased-line solutions, and they don't require special services from a third-party network provider--you can access your host from the public telephone network. However, modems by nature are more difficult to manage remotely, and you need to add one modem for each additional remote user you want to accommodate at once. However, if you plan on using an analog solution, you have a number of configuration options.
Because you will need to accommodate multiple users, on the host side you need to set up a modem pool. A modem pool is a way of connecting multiple modems to your host, such that each one accesses your network independently when a user dials in. In the case of an asynchronous modem pool, you can set up a remote node server with a multi-port serial card, like the Digiboard, place modems on it as you need capacity, and provide remote node access to your network. If you have a PBX at your site that supports hunt groups, you can set up a group of these modems to accept calls to a single phone number so your users don't need to change their dialup number each time a call rings busy. As far as the remote node server is concerned, it thinks it has eight, sixteen, or however many modems your multi-port serial card supports.
TIP: If you choose to use a multi-port serial card, make sure your remote node server software explicitly supports it, with current drivers for your OS. Most problems with these solutions arise when you have unsupported hardware or out-of-date drivers.
Another option for analog modem support is to use a communication server to provide the access to your network. This is a hardware device that usually has eight to sixteen serial ports on one side and a network connection--like Ethernet or token ring--on the other. You can connect regular asynchronous modems to the communications ports, and configure it to provide authentication to the user just like a remote node server. Common examples of these types of boxes include Cisco's 500-CS or 3Com's Access- Builder. These boxes provide an easy means of setting up remote node services without the cost of server software and hardware. However, they are usually less feature-rich than a software-based solution. In fact, some vendors have used communications servers to provide the authentication mechanism and then pass the traffic to a server on the network that handles their remote user tasks. One solution allows the remote user to come into the network via communications server using a remote node connection that then passes the user to a remote control host. This hybrid solution has the effect of reducing the traffic the remote user has to pass across the phone line because they are only passing screen, mouse, and keyboard updates across their remote node connection. Of course, this requires them to run a special remote control client with support for remote node connections.
On the client side, your options are fairly straightforward. Whether you need a PCMCIA modem or an external one, make sure that you test whichever you specify with those on your host or server side. Just because a vendor says that a modem is Hayes-AT compatible doesn't mean that it will handshake correctly with its partner or maintain a connection at high speeds. While some people have strong convictions about which modem vendor they like, if you stick with the big names, like US Robotics and Hayes, you can't go wrong. It cannot be stressed enough that if you skimp on modems, you'll chase weird connection problems for most of your days.
Using Leased Lines and ISDN. If you are planning to accommodate more than 15-30 users at any one time, you should seriously look at a leased-line solution on your remote node server/host side. There are many technologies available to accommodate almost every level of need. For example, most good remote node server software, like Novell's NetWare Connect or Microsoft's Windows NT RAS server, supports X.25 connections right into the server. X.25, as you may know, is a packet-switching technology that has been around for quite some time. Its advantages are that it is available everywhere and allows you to multiplex multiple inbound calls into virtual ports on the server. To get X.25 access from a server-based remote node solution, you can buy an adapter card, like those from Eicon Technologies, that interfaces with your X.25 connection. Then your remote node software has drivers that work with the card to identify and control the virtual channels available across the network. Make sure you check with the X.25 card vendor to ensure that they provide drivers for your remote node software. Also, most hardware-based routers support X.25 connections.
In either the hardware router or software-based solution, once you decide you want to use X.25 (or any other transport mechanism for that matter), you will need to find a network provider that has an X.25 network you can use. There are many vendors who do, including most of the major long-distance phone companies and some of the large bulletin-board services like CompuServe. These vendors have Points-of-Presence (POPs) all over the country into their networks. This means that no matter where your remote user is, she can dial a local phone number to gain access into the X.25 cloud, where she is then routed to your remote node host and onto your network (see fig. 27.2).
Figure 27.2
Example of a remote node configuration using X.25 to an NT or Novell server.
In addition to X.25, you have many other options for providing connections to your remote users using leased lines. For example, if you have ISDN users to accomodate, you might install a PRI at your host location. As you might remember from our earlier discussion of ISDN, a PRI gives you 23 `B' channel (64 Kbps) connections. To implement such a solution, you will need to find a third-party network provider that has built an ISDN network infrastructure. Many of the RBOCs and long-distance carriers have such an infrastructure. From them, you get a circuit, terminated at your server/router location, that provides PRI service. You then need an interface card on your server or router that supports PRI connections.
Once this is in place, your ISDN remote users dial a local POP for the network provider's ISDN network, and the call is switched to your host site and presented to your network. Remember, when planning for capacity, each ISDN remote user may have the capability of sending two `B' channels worth of data. If you have 11 users doing this at once, your PRI is almost fully utilized. In some cases, this may not be a concern. Indeed, many ISDN network vendors don't yet support bonded `B' channels, so even if the remote user tries to send two channels-worth of data, one of those will be dropped when it gets to the provider's POP. There are also limitations on the remote client side. Certain terminal adapter vendors don't yet support bonding of the `B' channels, so the user will only ever get 64 Kbps of throughput. If 128 Kbps of throughput is required by your end-users, make sure you find out about this feature from both your TA vendor and network provider ahead of time. Remember, also, that installing a PRI is for ISDN end-users only. You generally won't be able to use it for your remote analog users unless your network provider can do some conversion within its network from analog to ISDN. You may need to build a separate leased-line service for your analog users.
If you find that you want to provide access to your ISDN users, but ISDN is not supported at the location where your remote node host or router is located, you may still be in luck. Many network vendors support ISDN into their network from your remote user, and then convert it to another switched digital service--like Switched 56 or Switched T1--outbound. In this solution, your ISDN users dial into the ISDN POP as always, but on your host side, you have a switched service that provides connection to your network. The same capacity rules apply.
Now that we have looked at the underpinning of remote access, you need to consider some implementation issues. Chief among these is security. While security is somewhat dependent upon whether you implement a remote node or remote control solution, there are some preferred ways of securing your network.
As you can imagine, the idea of opening up your sensitive corporate network to out- side users presents several security challenges. The biggest of these is to protect your company's assets without making it difficult for the remote user to access your network. With this in mind, there are number of authentication and verification schemes you should consider.
Using Passwords and Callback. Most remote node and remote control server software supports simple passwording. That is, you can set up the software to prompt the remote user for a password just to get into the remote access server, and then the user still has to authenticate with the network operating system (for example, Novell NetWare or Windows NT). Of course, you then need to maintain two sets of passwords, which can be administratively taxing and add to the user's frustration. It also may not be very secure if the passwords are sent in the clear, meaning they are not encrypted at all. Anyone sniffing the wire can then get your password and hack into your network.
In addition to simple passwording, most software-based solutions like RAS or NetWare Connect provide a callback mechanism. This allows the system administrator to set up a list of users who are eligible to dial into the server and a fixed phone number where they are dialing from. When the remote user dials up, he enters his username. Then the server disconnects him and dials back to his predefined number. This option may not work if the remote user is mobile and requires administration if the remote user's number changes, but it provides an acceptable mechanism for basic security.
Using Authentication Services. Another security option is to require your users to authenticate to your remote access network protocol, prior to being granted access to the remote network services. Most PPP stacks supports one of two authentication options. These are Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP). PAP provides basic password authentication to your network. That is, your remote user dials your host or router, is prompted for a password before being given access to your network, and then can use her normal NOS password to access network resources. PAP passwords are passed as clear text and are vulnerable to being tapped into. CHAP, on the other hand, uses a challenge-response mechanism to authenticate the user to the network. Each remote user has a secret that is known only by the host or router running CHAP. The user uses this secret to calculate a value using some algorithm, and that value is passed to the server. The server compares the value to its secret, spun against the algorithm and if they match, the user is allowed access to the network. This process continues periodically during the life of the connection to ensure that the connection remains valid. With CHAP, no passwords are sent across the wire, so the connection is harder to spoof.
There are many variations on CHAP that you can use. One common solution is to run an authentication server, which interacts with your remote access point, be it a router or a server, and employs some authentication scheme to permit the user access to the network. These authentication servers employ a number of different encryption algorithms to provide secure access, including well-known ones like the Data Encryption Standard (DES), RSA, Kerberos, and any number of proprietary schemes. This kind of configuration is illustrated in figure 27.3.
Figure 27.3
An example of a remote access solution using an encryption server.
In this scenario, the user carries a token when she is accessing the remote network. The token, which physically looks like a thick credit-card or calculator, is synchronized with the authentication server to provide a unique password that changes on a periodic basis (called a time-synchronous authentication scheme). This password is then used, sometimes accompanied by a user PIN, to authenticate the user to the network. There are also asynchronous authentication mechanisms available. These methods, also called challenge-response, present a challenge to the user, which requires a response; then she is prompted to provide a password, perhaps based on some token scheme. In this way, the user has to know the response to the challenge, as well as have a valid token-generated password.
All of these schemes address only authentication security and don't address payload security. That is, how is the data, carried on the line, protected? You will need to get additional software if you want to encrypt data sent back and forth. To do this, you will need more processing power on the server and client doing the encryption. Figure 27.4 shows a screen shot of some of the authentication and encryption options provided by Windows NT's RAS server.
Figure 27.4
Windows NT RAS' authentication and encryption options.
There are literally hundreds of vendors providing some basic remote control or remote node software and hardware. Rather than try to describe them all, we'll touch on just the major ones that are available with Novell NetWare and Windows NT, as well as discuss some of the available router-based solutions and some other unconventional options that are available either now or in the near future.
NetWare Connect. NetWare Connect 2.0 is Novell's newest offering in the remote access arena. It's a separate package designed to provide both dial-in and dial-out capabilities on a Novell network. It runs as a series of NLMs on your Novell 3.x, 4.x, or run-time server. It supports remote IPX, IP, and ARAP (AppleTalk Remote Access Protocol) clients, and provides (new to 2.0) PPP and SLIP drivers for IP and IPX clients. Each NetWare Connect server can support up to 128 simultaneous connections inbound and outbound. It can provide authentication using NDS or other more standards-based authentication schemes. NetWare Connect comes with its own Windows-based Management Console, called ConnectView. As a modem pool for outbound calls, it supports LAN redirectors like Int14 and NASI (Novell Asynchronous Service Interface). In this case, if a user on the LAN wanted to dial out to a bulletin-board service, he could use a communication package like Procomm Plus for Networks to access the NetWare Connect-attached modems using one of the LAN redirectors. NetWare Connect also supports inbound remote control connections, where a remote control host running, for example, PC Anywhere on your corporate LAN, can attach to a NetWare Connect port and wait for a remote control client dialing in. In this case, it is acting as a sort of remote control redirector.
NetWare Connect allows you to assign certain ports for either inbound or outbound usage and provides auditing and management of port usage. It can also be managed through an SNMP management platform. NetWare Connect supports asynchronous multi-port serial boards, as well as ISDN and X.25.
NT RAS. The Remote Access Service that comes with Windows NT was designed to provide both client and server remote node functionality. The RAS server service that comes with NT workstation only supports one inbound connection. The RAS server service that comes with NT server supports 256 simultaneous inbound connections. RAS does not have support for dial-out modem pooling, though there are third-party products available to do this. Both the RAS server and client software support IP, IPX, and NetBEUI. Additionally, it supports dynamic IP addressing using either a static IP address pool or Microsoft's Dynamic Host Configuration Protocol (DHCP). IP support includes both PPP and SLIP, and authentication can be done under PPP using PAP, Microsoft's own authentication or a third-party authentication service. Additionally, you can use either the Windows 95 dialup adapter or any third-party PPP stack to dial into a RAS server, using PAP authentication or even no authentication.
The RAS client comes with a crude scripting language for automating certain logon sequences. Setup of the RAS server is GUI-based and fairly straightforward. You can log user access to NT's event viewer, and there is an admin tool that allows you to define who in NT's domain database can log on to the RAS server.
Router-Based Solutions. There are any number of router-based solutions for setting up the host side of a remote access network. Most of them are remote node solutions, because they simply perform a routing function between some remote medium like ISDN-PRI or X.25 and the internal network. Some, like the 3Com Accessbuilder-Citrix solution, work with software products to allow hybrid remote node, remote control functionality. If you are building a fairly large remote access solution, a hardware-based router, in conjunction with some secure authentication service, is probably the most reliable, easy-to-maintain solution you will find. This is because routers as remote node providers fit easily into your existing network infrastructure, providing only slightly different functionality than they normally do.
Third-Party Network Providers. If you're looking to provide remote access to your mobile users utilizing the existing Internet and telephone networks, you have some interesting and innovative options. There is a service available on the Internet called Winserve (http://www.winserve.com) that provides Windows clients with a roving LAN resource. Winserve offers NT server file storage and client name registration using NT's TCP/IP-based WINS NetBIOS name resolution service, as well as Microsoft mail post office services for your Windows for Workgroups, Windows 95, and Windows NT clients. Basically, it's as if the Internet were your own giant NT LAN.
You dial your Internet provider, connect to the Internet, and register with WINS on Winserve's site; then you can browse NT server resources as well as other NetBIOS machines that have registered. From wherever you are, you can connect to an NT server where you have stored files and access them as if you were on your corporate LAN. Of course, you still have to deal with the security issues of Internet, but for non-sensitive files or mail, it's an innovative way of providing access to users from anywhere in the world.
On the Novell side, you also have an option. NetWare Connect Services, provided by Novell in conjunction with AT&T, provides you with a global IPX-based network. You can dial into AT&T's network and access pre-registered Novell services anywhere, including your own corporate NetWare Servers. There's also a gateway service to the Internet, providing a full-range of remote access possibilities in a mixed TCP/IP and IPX environment.
Options Provided by Your Local Telco. Your local telephone company may also have some resources that you might not have considered to facilitate your telecommuting solutions. Several RBOCs are proposing and have tested neighborhood telecommuting centers, where an employee can go with his laptop, plug into a desk that has an ISDN connection, and access his corporate network. In addition to just a desk and a plug, he also has general office services like faxing, voice and video conferencing, and printing. Companies can work with their RBOCs to provide access to these centers for their employees and save money by putting special connections in employees' homes, and they allow the employee to work close to home and still have all the resources they need to do their job. Expect to see these centers springing up more and more, especially as the phone companies push the "ISDN everywhere" concept.
Future Solutions. In the not too distant future, service providers that once were regulated out of the networking market will play a key role in the telecommuting world. Television cable companies are already planning how they will provide high-speed Internet connections to every person's home using the existing coaxial cable infrastructure, which is ideally suited to high-bandwidth network traffic. As the Internet becomes a more secure place to do business, more companies will be able to provide remote access over it, and more of today's Internet providers will become remote access providers as well. The key feature here is that higher bandwidth and greater accessibility to broadband high-bandwidth networks will make transfer of voice and data traffic much easier to implement within your organization. Once again, security is the key for this to happen.
While you may not think of it right away, providing a telecommuting solution to your end-users could fundamentally affect the way your company's employees interact. If you give the user the option to work at home, without restriction, chances are that they will. This may have an obvious effect on their productivity and accountability but also on the culture of your organization. It's definitely worth spending some time with management and a human resources specialist to define a very clear policy about telecommuting--including how often an employee can do it, which tasks are telecommutable and which must be done at home, how a manager can evaluate an employee if they are gone two days a week, and how to avoid bias against telecommuting employees, who may not be present when the good assignments are handed out, when the praises are heaped, or when something goes wrong.
We have looked at the many ways you can provide remote access to your employees via either remote control or remote node. Today, increasingly high bandwidth access methods like ISDN make remote node the most cost efficient, secure, and easy-to-manage function. Additionally, leased-line technology can allow you to accommodate many users at once, and third-party network providers can provide Points of Presence for your users, wherever they may be.
There are many vendors providing remote access solutions, from Novell's NetWare Connect product providing up to 128 simultaneous inbound and outbound IP, IPX, and Macintosh connections to Windows NT's RAS server with support for 256 simultaneous sessions of inbound IP, IPX, or NetBEUI clients. Along with these software products and hardware-based routers are the various security mechanisms for accessing your network, including the basic PAP protocol for PPP, the more feature-rich CHAP, and third-party authentication services that work in conjunction with hardware and software solutions.
Finally, as we move into the high-bandwidth days, your options for providing tele- commuting to your employees will only expand, adding new players, like cable companies, and new challenges for your organization as you deal with employees who spend less time in the office and more time on the road or at home.
© Copyright, Macmillan Computer Publishing. All rights reserved.