From the Trenches: Decentralizing Network Admin
With 50 remote administrators relying on headquarters for planning and support, Cox Communications needed to set its administrators free—without giving away the keys to the farm.
- By Clara Parkes
- December 01, 1999
Cox Communications provides broadband communication to
more than 3.8 million people. The company is headquartered
in Atlanta, with 18 branch locations around the country.
In 1996, Cox was in the process of migrating its systems
from Novell 3.1.2 to Windows NT. The company had a brand
new domain structure (with one master domain and 30 resource
domains), but the corporate LAN administrators were still
responsible for planning and supporting the 50 field administrators.
To add or remove users or change passwords, the remote
administrators had to download User Manager over the wire
from headquarters. As the company grew, so did the User
Manager database—which meant it often took longer to download
Security Accounts Manager (SAM) than it did to make the
actual system changes.
and Resource Administrator
Mission Critical Software, Inc.
An evaluation version is available for download
in return for registration information.
Mark Kobrinsky, Manager of LAN and Desktop Resources
at Cox, decided it was time to decentralize the administration
process so that administrators could manage their own
security and only turn to headquarters for support. His
plan was to create a more granular security policy so
remote administrators could manage their own users and
groups in the master domain, without having access to
any other users or groups. Besides getting support from
headquarters, the remote administrators would otherwise
be on their own.
Kobrinsky’s mission was to figure out how he could give
administrators varying degrees of security. For example,
he wanted to enable helpdesk staffers to reset passwords,
enable users, and lock users out if needed—and nothing
more. This was especially important because a good number
of first-line helpdesk staffers would be accessing the
system to make basic user changes, and these people often
didn’t have the extensive training that most account operators
had—so the potential for unintentional system damage was
The primary domain controller was at Atlanta headquarters,
with 18 remote sites and 300 servers nationwide. They
had 5,000 users, a number that has since grown to more
than 12,000. The environment consisted of Windows NT 4.0
servers, SMS 2.0, SQL Server 7.0, Oracle, Exchange 5.5,
Internet Information Server, and Site Server. Desktops
run Windows 95 (though the company is looking to migrate
to Windows 2000 Professional) and Office 97.
The only option within NT alone was to make each administrator
an account operator. But this meant giving people more
far-reaching degrees of security than necessary (or safe).
Instead, the company needed a system that would enable
administrators to have varying degrees of security depending
on their job function.
Kobrinsky knew that NT’s native security couldn’t support
such a system, so he began investigating alternative solutions.
This was in 1996, when Cox was still doing final tests
of its new NT domains to make sure they worked properly.
Once they’d determined that their domains were in order,
he began actively pursuing the next phase in 1997. Because
their domain structure was brand new and fully functional,
a major priority was to find a tool that would fit into
their infrastructure and not require a domain structure
overhaul. Moreover, they needed a solution that could
be added or removed without impacting the domain structure.
At that time there weren’t many products out there that
could do what they needed. The company brought in Mission
Critical Software, Inc.’s OnePoint Directory and Resource
Administrator and were so pleased with its flexibility
and responsiveness that they decided to go with it.
Directory and Resource Administrator enables secure,
distributed administration of user accounts, groups, and
system resources while limiting access to other functions.
Because Directory and Resource Administrator modifies
the system’s security, Kobrinsky took almost three months
to test the whole system and make sure it worked correctly.
His 24-member team included the LAN and PC support groups
as well as IntelliNet, an Atlanta-based Microsoft Certified
Solution Provider consulting firm, to help with the evaluation
Implementing Directory and Resource Administrator was
painless, helped by the fact that Cox already had a highly
standardized environment in its user naming, global group
naming, and local group naming. Because of this, they
were able to put Directory and Resource Administrator
directly into their domain without any problems.
The biggest challenge proved to be getting the field
administrators to give up User Manager and use Mission
Critical’s Directory and Resource Administrator interface
instead. Kobrinsky explains, “It’s really more of a cultural
change than anything else. We had to give it time, but
eventually the product proved itself.” The adoption was
helped by the fact that Directory and Resource Administrator
caches the SAM. Because of this, administrators no longer
had to wait several minutes to download it and make a
change—they could make changes in a matter of seconds
Since the project first began in 1996, they’ve expanded
their implementation of Directory and Resource Administrator
from the master domain to the resource domain as well.
As the number of users has grown, Kobrinsky discovered
that there were many power users in specific groups, or
certain types of administrators in other groups, who needed
to be able to look at a specific resource in a resource
domain and either modify it or view it throughout the
day—such as seeing the number of people logged on, who’s
using a specific resource, and so on. So Cox uses Directory
and Resource Administrator to manage users and resources
in the resource domain as well.
Now, each remote administrator can manage his or her
own users and groups directly. They’ve achieved their
goal of more granular security, having added several different
security levels. For example, the helpdesk has one level
of security, the PC support area has another, the LAN
administrators have yet another level of security. An
especially beneficial aspect of the system is that Cox
still has domain administrators at headquarters who can
revert back to using User Manager, whereas the field uses
Directory and Resource Administrator’s client. So if the
product stops working or if there were some sort of emergency,
they could easily revert back to using the native Microsoft
security very quickly. “In terms of disaster recovery
or contingency planning,” says Kobrinsky, “Directory and
Resource Administrator has made it very easy.”
Moving forward, Kobrinsky sees Mission Critical playing
a key role in Cox’s migration to Windows 2000. He’s investigating
adding Mission Critical’s Domain Administrator product
into their environment so they can automate the OU population
and consolidate resource domains.
What advice would Kobrinsky give to others interested
in taking on a similar endeavor? First and foremost, before
bringing in any other product, assess your domain administration
and be sure your domain is working exactly the way you
want. And finally, don’t forget to assess your goals for
security and how you want to manage it. If you have a
clear goal of what you want to do, you’ll be able to make
the product work with your environment instead of trying
to make your environment work with the product.