In-Depth

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
• 12/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.

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.

The Challenge

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 increased.

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.

The Solution

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 and rollout.

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 instead.

The Results

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.

In Retrospect...

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.