The
task of granting remote users access to your central network and subsequently
managing those users can be quite daunting. It is especially difficult to
ensure that you’ve covered all the bases because each user's needs
vary in some way, and there isn't a common checklist that you can follow
for every situation.
This chapter will
help you address as many of these variables as possible. It will aid you
in formulating your own strategies in advance, and perhaps point out some
pitfalls and/or solutions that may be new to you. After you have read
this article, you may not have all the answers, but at least you’ll
know the questions to ask.
If you are looking
for a guide to help you decide which aspects of managing remote users
should be of importance to you, you’ve come to the right place. We’ll
cover as many scenarios as possible, restricting ourselves to general
concepts and methods rather than focusing on specific products or bit-level
explanations of protocols. But if you're just getting your feet wet with
supporting remote users, especially dial-up ones, we suggest reviewing
the following Network Computing Design Manual chapters:
The challenges of
remote support and implementation can be frustrating as you strive for
a reliable, secure and speedy connections for your off-site users. The
processes involved can be costly, time-consuming and morale-defeating,
and that's when it works right. At its worst, you’ll end up quitting
your profession in the IT arts, and becoming a simple woodsman.
Differentiating Between
Remote User Types: Individuals vs. Networks
For the most part, remote-support clients can be separated into two distinct
camps: remote users and remote networks. There are some overlapping areas
of concern, but each has distinct support needs. One obvious difference
is that a remote user is most likely going to be mobile, or need connections
that are not static or renewable (for instance, a dial-up user may be
connecting you via the Internet from an ISP that doesn’t provide
static IP addressing). A remote network or branch office, however, will
most likely use the same network mapping terms. However, there are some
notable exceptions, such as a remote office using an analog or digital
(ISDN) dial-on-demand router to connect to the enterprise.
Managing Individual
Remote Users
As with any new technology
or strategy deployed on your network, managing your remote users requires
several stages of preparation.
1. Identify the
goals of the project.
2. Assess the various
tools you have at your disposal (and research ones you don’t have).
3. Develop a solution.
4. Test it. I can't
stress this step enough.
Identifying your
users’ needs and goals is the most important part of your planning
regimen. These needs and goals must be clearly and concisely defined.
You must accurately identify the specifics of what they want to do now
and in the near future. Failure to do so may send you back to the drawing
board several weeks or months later. Not only will you have wasted your
time and resources, you will have created an antagonistic atmosphere towards
remote access.
Following are some
key details to work out that will help you to identify, develop and test
an applicable solution (or combination of solutions). They fall under
several categories, including transport issues (bandwidth, equipment and
so on), security, reliability and convenience.
Mobilizing the Troops
Transport issues are extremely important to network support representatives
as they manage remote users. How will remote users get to your network?
What equipment will they need? How reliable will it to be? Should they
use direct-dial or an alternative connection technique, such as TCP/IP
over a public network? These are all valid questions, but they are only
the tip of the iceberg. These days, when remote access is the topic of
conversation, people tend to think more in terms of using the Internet
as the primary medium, leaving direct dial as an alternative connectivity
method. We'll examine both methods, but with the exploding use of public
networks and their increased acceptance in the corporate world, you'll
find more solutions that bypass direct connections altogether.
Is the user going
to be on the move, or is he or she going to be stationary (a telecommuter
working from home)? The level of mobility will determine which security
and access methods will be appropriate. A lack of a static IP address
(having the same IP address assigned each time if the user dials into
an ISP), for example, will prevent you from taking some basic security
steps, such as placing an ACL (access-control list) on a router at the
central network. Being able to recognize your user by only his or her
login ID can restrict your overall security scheme. This will undoubtedly
force you to make exceptions to your security policies, unless you use
a VPN technology. We’ll elaborate on this in a later section.
To effectively manage
a mobile user plan for all possible contingencies. Security issues aside,
stability will be the hardest thing for you to provide or support. A truly
mobile user is one of the most difficult to support and manage, make no
mistake about it. "Mobile" equals analog connectivity subject to the whims
of whatever telco or facility sits between you and your users. You can
leave your fancy T1, DSL and fiber-delivered services behind you, because
it’s back to the 1960s in terms of reliable connectivity. Except
back then, they didn't design the analog infrastructure to accommodate
a 56-Kbps connection through a hotel's switchboard.
Provide your users
with as many alternate paths as you can into your network (without completely
sacrificing security, of course). Make those choices clear and easy to
understand. If the access isn’t simple and robust, your users will
not want to use it, making your job harder in the long run.
Additionally, you’re
not going to be able to hide all the sundry transport mechanisms, making
the connectivity experience less than elegant. Generally speaking, it
will be difficult to find a nonhostile environment for your users to dial
in from. Specifically, they're going to be facing unfamiliar variables
such as dial-tone access (for example will they have to dial a "9"
to get an outside line or need to enter in an access PIN specific to an
LD carrier?). They’ll have to cope with noisy switchboards causing
static on the line and, of course, the inherent background noise found
in most long-distance switched analog connections.
Don’t expect
anything less, or you’re going to get burned. Even if your users
are lucky enough to stay in hotels that have Ethernet connectivity, you’ll
still need to jump through with whatever hoops the hotel setup requires.
These hoops may include being a DHCP client or configuring for a proxy
gateway. This might not sound like a big deal to you, but remember, we’re
talking about your end users, not you. To them, it looks like more voodoo
than they’d care to deal with. This isn't their job, after all; it’s
yours! You will have users who would prefer to dial in using a modem rather
than change any configuration settings.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
2009 IT Salary Survey: Meager Raises, Solid Prospects
Though raises are notably smaller than a year ago, and job securitys shrinking, IT careers are looking safer than many others in this economic downturn. Get all the findings in InformationWeek's 2009 IT Salary Survey. Available FREE for a limited time.
REPORTS
ANALYTICS
Follow 
