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, any employee will be able to sit at home and access resources at workóas if they were sitting in their officeó"commuting" over phone lines. They will be able to take calls from customers, access corporate databases, email, and productivity applications without doing much of anything different on their PC. While you may be skeptical of how seamless this would beóand rightly soótrue telecommuting is a lot 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, 2400, and even 9600 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 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 pop-up 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 then current 9,600 bps modems were painfully slow.
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 provide 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.
As indicated above, 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 type 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, which get converted to direct device calls which 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 they scroll a window, but instead, the Graphical Device Interface (GDI) commands are sent to the remote PC, where the screen responds accordingly. There are also some mechanisms which 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.
As mentioned above, 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 multi-tasking 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 in, he/she 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 upon resources on the host PC, you could accommodate several users at once, each remote controlling their 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 becomes to troubleshoot and manage a number of multi-tasking servers running numerous virtual remote control sessions over analog modems. Since remote control does not pass network protocols, but 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 directly in a remote control environment, you cannot easily copy files between network resources and your machine. Generally, the remote control application requires you to pop-up another file transfer application, that 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, then have the host disconnect the call and dial-back the user at a pre-determined phone number. This guarantees that the user is calling from a known location. Unfortunately, it does nothing to protect against someone using a remote users' PC without his or her knowledge at the given location.
In general, unless you are building a very small remote access solution (less than 10ñ20 nodes), you should consider saving your remote control money and putting it into a remote node solution (discussed in the following "Remote Node" section).
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 for your users, 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 one of versions of remote control that uses the multi-tasking virtual machine method, make sure you error 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 box(es), besides 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 a remote user act as if they were local to their home LAN. To further the analogy, if a user normally sits in his or her office, and connects to the corporate network via Ethernet, then remote node allows a user dialing in via modem, or ISDN adapter, to act as if they 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 stack on their PC, 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.
Since remote node allows a remote PC to act as a real node on the network, extended through phone lines, it allows a user to do things in generally the same way as they would at their office desks. That is, a user would login as they normally do, access network drives and printers as always, and run applications remotely like electronic mail, terminal emulation, host access, and, with some caveats, access word processing, spreadsheet or other productivity applications' data.
Unlike 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 they try and launch a 6 Megabyte application on a 14.4 or 28.8 modem. As more telecommuters and move to ISDN, the effect of this will lessen, but there are definitely ways to optimize a remote node solution
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 Network Operating System security to provide additional protection. Finally, since 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.
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 above, certain kinds of operations should not be attempted across a remote node connection unless you have lots of bandwidth (e.g. 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 all the same overhead as you would locally. This includes protocols that require an acknowledgment for each packet sent out on the wire. This 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. Since 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.
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 following "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 upon 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 care 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. These are described below, 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:
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 his/her normal network password, and he/she is in. Or, you can implement more involved security schemes, where the user has to authenticate to the public network when they initially dial, then authenticate with your remote node host, then finally 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.
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 (e.g. 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.
When configuring remote node clients, it's much more important to think about where applications are executed.
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
***
This includes applications like Word or Excel, as well as, for example, on a Novell client, 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 over a remote node connection, especially an analog one, will literally take minutes and frustrate the user. While this may seem like an added burden maintaining multiple copies of an application, it 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.
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 acquiring special services from a 3rd 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 wish to accommodate at once. However, if you plan on using an analog solution, you have a number of configuration options.
Since 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 dial-in number each time a call rings busy. As far as the remote node server is concerned, it thinks it has 8,16 or however many number of modems your multi-port serial card supports.
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 8 to 16 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 AccessBuilder. 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 through to a server on the network that handles their remote user tasks. One solution available allows the remote user to come into the network via communications server using a remote node connection, then passes that 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 running a special remote control client with support for remote node connections.
On the client side, your options are fairly straight-forward. Whether you need a PCMCIA-based 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 deep convictions about which modem vendor they like, if you stick with the big names, like US Robotics and Hayes, you can't go too far wrong. It can not be stressed enough that if you skimp on modems, you'll ending chasing weird connection problems for most of your days.
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 support 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. It's 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 interface card, like those from Eicon Technologies that interface with your X.25 connection. Then, your remote node software like NT RAS or Netware Connect, has drivers that work with the card to identify and control the virtual channels available across the network. Make sure you check with to X.25 card vendor to ensure they provide drivers for your remote node software. Also, most hardware-based routers support X.25 connections.
In either caseó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, they can dial a local phone number to gain access into the X.25 cloud, where they are then routed to your remote node host an onto your network. This is diagrammed in figure 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 (64kbps) 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 would get a circuit, terminated at your server/router location, that provides PRI service. You would then need an interface card on your server or router that supports PRI connections.
Once this is in place, your ISDN remote users would dial a local POP for the network provider's ISDN network, and the call would be 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 had 11 users doing this at once, your PRI would be 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 64kbps of throughput. If 128kbps 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 their network from analog to ISDN. You may need to build a separate leased-line service for your analog users alone.
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 T-1ó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, where you need to have as many channels available as you want users dialing in simultaneously.
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 outside users presents several security challenges. The biggest challenge 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.
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 would still have to authenticate to the Network Operating System (e.g. Novell Netware or Windows NT). Of course, you need to then maintain two sets of passwords, which can be administratively taxing and add to the user's frustration. It also may not very secure if the password 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 in, they enter their username. Then, the server disconnects them and dials back to their pre-defined number. This option may not work if the remote user is mobile, and requires administration if the remote user's number changes, but provides an acceptable mechanism for basic security.
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 their normal NOS password to access network resources. PAP passwords are passed as clear text and so 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 it's 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 they are 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 they are 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 wish to encrypt data sent back and forth. And to do this you will need more processing power on the server and client doing the encryption. Below is a screen shot of some of the authentication and encryption options provided by Windows NT's RAS server (see fig. 27.4).
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 and 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 either available now, or in the near future.
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 Appletalk 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 in-bound and out. 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, they 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 support in-bound 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 in-bound 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 an X.25.
The Remote Access Service that comes with Windows NT was designed to provide both client and server remote node functionality only. The RAS server service that comes with NT workstation only supports one in-bound connection. The RAS server service that comes with NT server supports 256 simultaneous in-bound 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 supports 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 login 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 login to the RAS server.
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, since 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.
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 today. There is a service available on the Internet today called Winserve (http://www.winserve.com) that provides Windows clients with a roving LAN resource. Winserve offers NT server file storage, 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 was 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 your 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 user's 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.
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 their laptop, plug into a desk that has an ISDN connection, and access their corporate network. In addition to just a desk and a plug, they also have 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 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.
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 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 becomes the key to getting 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 around when the good assignments are handed out, when the praises are heaped or to represent themselves when something goes wrong for which they are responsible.
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 accomodate 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 in-bound and out-bound IP, IPX and Macintosh connections, to Windows NT's RAS server with support for 256 simultaneous sessions of in-bound 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 to the more feature-rich CHAP, to 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 telecommuting to your employees will only expand, adding new players like cable companies, and new challenges for your organization, as you deal with employees spend less time in the office and more time on the road or at home, access your network resources.