Network Computingwww.networkcomputing.com

Managing a remote-access solution is difficult and time-consuming. If you plan on rolling out a large remote-access solution, you'll probably need to have a dedicated administrator to take care of the system. Remote access can quickly become a critical business process that you don't want left to already overworked administrators because there are many disparate parts that must be kept interoperating.

Managing a remote-access system requires substantial knowledge of asynchronous communications, modem hardware, and asynchronous protocols. Communications problems are typically difficult to identify and fix, especially if you're trying to support a user in another office. The source of an error can be anywhere along the path between the user and the network the user is trying to reach, but your remote-access manager can only effectively work directly with the connections from the telco demarcation point to the servers he/she manages.

If you have a distributed administration system, pushing remote access out to them may be wiser than trying to centrally manage it. This has the benefit of locally managed network devices with people onsite that can get to the devices and work on them quickly. Additionally, local administrators can fine-tune their remote access system to more tightly integrate with the goals of the business units they support. On the other hand, this will increase the work load on the current managers or will require the hiring and training of new personnel.

Centrally managed remote-access solutions have the benefit of a single point of contact for all remote-access concerns. This allows better management and utilization of resources because usage statistics and reports can be gathered and reviewed by a single group of people that will, over time, build up knowledge of how the remote-access solution behaves. Many of the larger remote-access vendors offer management stations that extend the functionality of network management systems such as Novell's NetWare Management System, and HP OpenView. The down side to the centrally managed approach is that unless you have all your modem racks and remote access servers under one roof, troubleshooting can become highly ineffective. Many problems are more easily solved if you can observe the racks directly rather than waiting for a SNMP trap to be set or for some other indication on a remote console.

In either distributed or centrally managed remote access, there are some common features that you'll want to look for.

• Management Are the modems/remote-access servers centrally managed? Preferably yes, and by a nonproprietary method. Using a standardized management protocol such as SNMP lets you use existing tools on your network to manage these devices. Beware that vendors employ different levels of SNMP functionality. In some cases, you manage the devices from a proprietary interface, but you can also receive traps via SNMP. Most large-scale servers can also be managed via a command-line interface via telnet, dial in to a dedicated management port, or through a serial port on the server itself in the event SNMP is unavailable or temporarily unavailable.

• Updates Updates to the modem/system hardware/firmware are essential to keep a smooth-running remote-access solution going. The update process should be as simple and nonintrusive as possible and should take place within the management console.

• Alarms and Events You'll want to configure your own alarms and events. While most vendors send defaults already activated, you'll find that your installation has its own quirks. Being able to create your own events lets you customize the management station to your needs.

• Automated Processing Hand in hand with alarms is automated processing. Sometimes when an alarm occurs, you'll want to run some task automatically. For example, after each call, you may want to reset the modem. Conditions can be numerous and extend beyond the modem chassis, but the idea is that a task is run in response to a certain event.

• Robust Reporting You can't effectively manage a remote-access system if you can't gather information that you find important and relevant. Gathering historical data provides you with overall trends and allows you to analyze how effective your remote-access solution is and will indicate when changes need to be made as the organization evolves over time. Current reporting, or snapshots provide views of your remote-access system at any point in time.

If your proposed solution lacks any of these features, you will have to find other ways of getting the information or functionality. Further issues revolve around controlling access into your network, controlling functionality and billing usage.

• Many computer savvy users have found putting a modem on their desktop is a simpler form of access because they can bypass controls that are placed by administrators. With a remote-control package on their desktop, they can access network resources without your knowledge. Since most computer security problems are internal to the organization, this poses quite a risk. Prohibiting desktop modems may be wise administrative move to protect against potential problems.

• As interest in the Internet grows among the public, more people, including your employees, are trying to find ways to get online content. If users have access to the Internet from your dial-ups, they may be tempted to use it instead of finding a ISP. Limiting remote user's access to specific internal network services may also be in keeping with established security policies. You certainly don't want next year's budget or strategic plan being transmitted across the wires by unwitting employees. By evaluating what users need to do remotely, you can use the advanced features of TACACS+ or RADIUS authentication servers to establish online user profiles for limiting times online, services that can be used, and networks that can be reached.

• Billing users back to their respective accounts to match organization accounting models will entail the creation of new processes to get data from one format to another and to match calls from your telephone provider against your internal calling log.

Updated January 17, 1997

Print This Page

E-mail this URL