energy to education, and from
manufacturing to retail.
The reason for the high costs?
Simply put, it’s expensive to
perform the same action, again
and again, across systems that
are not sharing the same basic
identity infrastructure. Managing
identities and access for multiple
UNIX systems is complex and
inefficient because each system
is unconnected and each is a
disjointed island unto itself. Let’s
examine the specific issues with
each of the four A’s for UNIX.
Authentication in UNIX
No native single sign-on
burdens users with multiple
accounts and passwords
Not all AD bridge
solutions are
created equal. Be
sure to choose
one that gives
you all the
authentication
convenience you
require—without
adding complexity
for authorization,
administration,
and audit.
3
For organizations with multiple
UNIX systems, authentication is
a box-by- box process. Each user
must have an account on each
system he or she needs to access.
There is no easy way to ensure
that the accounts are the same.
Due to the errors that creep in
over time, inconsistency of the
timing of deployment, and the
fact that practices and support
staff change over time, a single
physical user may be represented
by dozens (or even hundreds or
thousands) of separate accounts
that bear no connection with
each other. The user names
may be different, the user IDs
(UIDs) may be different, and the
passwords will most certainly be
different, expiring at different
times and possibly requiring
different security policy.
In other words, natively UNIX
does not provide any sort of
single sign- on environment for
users. Users who must access
multiple UNIX systems are
required to remember many
passwords and must spend large
amounts of time simply logging
in and out of each system. Early
efforts to consolidate logins
and identities in UNIX (such
as NIS), unfortunately, do not
live up to modern security and
compliance standards. For
example, NIS sends passwords
over the wire in clear text, an
obvious violation of virtually every
compliance regulation.
Administrators have to
provision each account
separately
UNIX accounts present issues
for administrators as well as end
users. Natively, it is not possible
to provision all UNIX accounts for
a user in one action. The account
must be set up individually (even
if it represents the same person)
on each box. That’s not much of
a problem with one, two, or even
10 UNIX boxes and a handful of
users. But what about when the
UNIX install stretches into the
hundreds or thousands and the
number of users grows as well?
Active Directory bridge
solutions extend
authentication and
administration to UNIX
Since the early part of the 21st
century, technologies have
existed that overcome the
shortcomings of both native UNIX
authentication and NIS. Active
Directory (AD) bridge solutions
extend the authentication security,
manageability, and single sign-on
capabilities of Microsoft Active
Directory—and specifically its
enterprise-class implementation
of the Kerberos and LDAP
protocols—to UNIX, Linux, and
Mac OS X systems. With an AD
bridge solution, a single logon to
AD can authenticate and grant
access to the entire range of
UNIX systems that have “joined”
the AD trusted realm. And a
single account in AD is all that
must be provisioned, managed,
and terminated.
Be sure to choose your AD
bridge solution carefully, so as
not to complicate other A’s
However not all AD bridge
solutions are created equal. If
authentication were the only
concern, any solution would do.
But the implications of joining
a UNIX system to AD extend
beyond simply authentication
to authorization, administration,
and audit. The right AD bridge
solution for your environment
would be the one that gives you
all the authentication convenience
you require, without adding
complexity for authorization,
administration, and audit. In other
words, the more transparent
your AD bridge is, the better off
you are.
Authentication Services is the
most mature, and most robust
AD bridge on the market. It
pioneered the AD bridge market
and has been providing unified
authentication for UNIX-based
systems since 2004. Multiple
deployments of Authentication
Services exceed 100,000 users
and tens of thousands of servers.
In fact, the top 10 largest Active
Directory bridge deployments all
use Authentication Services (with
one deployment nearing 100,000
4
servers). For a discussion of the
important issues to consider when
selecting an AD bridge solution
see the One Identity white
paper “Choosing the Right Active
Directory Bridge Solution.”
Authorization for UNIX
Similar to authentication, each
UNIX system requires its own
authorization. The challenges of
box-by-box authorization can be
overcome by using an AD bridge.
Basing authorization rights on AD
group membership overcomes
the administrative, security,
and compliance challenges of
natively building and enforcing
authorization individually on each
UNIX-based server.
It’s important to choose an AD
bridge solution that enables
AD-based authorization
without introducing additional
complexities and more layers of
management or infrastructure.
Authentication Services provides
the most seamless integration
between AD and UNIX and
leverages familiar and established
AD administrative practices
and interfaces.
Identity administration
for UNIX
Provisioning is timeconsuming for administrators
Neither authentication nor
authorization for UNIX systems
can adequately occur if identity
administration is not under
control. Again, the challenge with
UNIX is the fact that identity must
exist on every box. Therefore,
provisioning user accounts for
a new employee could involve
manually setting up accounts
on dozens, hundreds, or even
thousands of UNIX servers. It
is nearly impossible to maintain
consistency of username and
UID. And the negative impact
on productivity can be crippling,
as all the provisioning work on
UNIX systems typically must be
performed by administrators
whose primary jobs are not
user support.
Manual de-provisioning
processes entail
significant risks
As troublesome as provisioning
is, de- provisioning is downright
dangerous. Delays in terminating
access to UNIX systems present
compliance violations, at best,
and an open door to malicious
activity, at worst. The highly
publicized breach at Fannie
Mae was a direct result of
delays in terminating access to
UNIX systems. With the high
number of servers involved, the
manual nature of UNIX identity
administration, and the lack of
centralized oversight available
natively in UNIX, it’s a miracle
that we haven’t had more
Fannie Mae’s.
Password management
is a drain on users and
administrators alike
Finally, there’s the issue of
passwords. Every box requires an
account, which means every box
requires a password. Again, the
administrative tasks associated
with managing those passwords—
enforcing complexity rules,
requiring periodic changes, and
resetting forgotten passwords—
are an incredible drain on
operatio
Please complete the form to gain access to this content
