Implementing Protocom's SecureConsole in a Large Network
Articles and Tips: article
Directory Security Engineer
Independent Consultant
jclayton1@wideopenwest.com
11 Jan 2002
This AppNote provides insight into the design and deployment of Protocom's SecureConsole product in a large-scale network environment, including various tips and tricks for a successful deployment strategy.
|
Topics |
network security, console security, third-party add-ons |
|
Products |
Protocom SecureConsole |
|
Audience |
network administrators, engineers, designers |
|
Level |
intermediate |
|
Prerequisite Skills |
familiarity with server console and object-linking concepts |
|
Operating System |
NetWare 5.x, 6.x |
|
Tools |
ConsoleOne 1.3.3 |
|
Sample Code |
no |
Introduction
Protocom Development Systems' SecureConsole is a Novell-endorsed third-party console security application that adds the highest level of control and accountability to NetWare servers. One of the biggest reasons for implementing SecureConsole in most environments is its ability to greatly limit access to NetWare's internal command functionality once console access has been granted.
Although there have been several successful deployments of SecureConsole around the world, none thus far seems to have addressed the issues and concerns around doing so in a large network environment with thousands of users. The purpose of this AppNote is to explore the various issues you might encounter when implementing SecureConsole in such an environment. In doing so, I'll use a fictitious "intergalactic" network to demonstrate a sample design and deployment strategy used in a real-life implementation.
Large-Scale Design Issues
When it comes to enterprise-wide product deployment, most organizations follow the standard strategy of: "open box, insert CD, click Install." Unfortunately, this method will only suffice for organizations with fewer than 50 users. As you move up the scale to several thousands of users, this deployment method quickly becomes impractical.
To provide a framework for discussing the design issues involved in a large-scale product deployment, travel with me to a networked galaxy far, far away in which a large but scattered group of rebels has banded together to fight for freedom and justice against the evil empire (with apologies to George Lucas). They enlisted my services to assist them in implementing a highly secure, remote console access solution.
It wasn't long before we ran into several unexpected obstacles, the biggest of which were:
A serious lack of network administrative control
A geographically-sparse tree design
A locked-down, automated procedure for third-party application deployment
The following sections present our combined thinking regarding these deployment hurdles.
Centralized vs. Decentralized Administration
One of the hardest obstacles to overcome in the deployment of an enterprise-wide application lies deep in the structural heart of management distribution. In a perfect world, all IT administration is handled from a centralized location. Granted, you may have a few remote field technicians running around doing server repairs and the like, but as far as administrative duties (user additions, deletions, modifications, and so on) are concerned, you're better off if they are performed entirely by one core group of people.
Unfortunately, more and more organizations today seem to be drifting away from this basic principle, embracing instead the lost art of decentralization. Our rebel friends are no exception to this line of thinking, for they have chosen to spread their administrative duties from one end of the galaxy to the other. Figure 1 presents a bird's-eye view of how their network administration is handled.
Administrative control layout of the sample tree.
As you can see, every entity (planet) has staked its claim in a mass effort to maintain localized control over the independent regions. Here is how the rebels have set up the administrative rights in the JEDI tree:
The galactic administrator (GALAXYADMIN.JEDI) has full supervisory object and property rights from JEDI downward.
The planetary administrators have full supervisory object and property rights from their respective containers downward.
Unfortunately, this control is limited in regards to the actual functions which can or cannot be performed, even within each planet's own territory. For example, the roving Endorian field staff has full NDS and file system rights to every server on Endor, and some staff members even have rights to create or insert new servers into the global JEDI tree. However, they have no rights on any other planet, nor do they have the ability to perform simple administrative tasks such as user creation and modification. These procedures are reserved soley for the folks at the rebel base.
After some discussion, we decided to employ a multi-profile design using SecureConsole. Doing so will provide a more granular security approach, as opposed to housing all data inside one central object. This design is summarized as follows:
Galactic Security Control. Console access to every server in the JEDI tree is granted via group membership to the SC-SECURITY.JEDI object. Aside from any exceptions, only the GALAXYADMIN.JEDI group will be a member of this profile.
Planetary Security Control. Console access to every server on each planet is granted via membership to the regional SC-SECURITY.<planet>.JEDI object. Currently only the planetary admin groups will be members of this profile.
Once we crossed this first hurdle, our next task was to research the best possible method for deploying the application itself.
Application Rollout
Our solution to this hurdle was to have the remote field staff-from Dagobah to Tatooine-not install software straight from the factory-supplied media. Instead, custom developed in-house CDs would be distributed among all regions. These CDs will contain all approved third-party applications, which will be installed via scripts written by the in-house integration staff.
Design Recommendations
Here is some additional information about the design recommendations we arrived at.
Advantages of Profiling
The ability to control everything from console access to NLM execution can be granted via multiple avenues. Given the excellent security and scalability of Novell's eDirectory, it makes perfect sense to harness the full power of this directory service. Protocom grants this capability by providing the ability to create profile objects. Two types are supported: Security objects and Configuration objects.
The sole responsibility of the various SC-SECURITY objects is to control all remote access to the console. It is here that both users and groups can be granted specific rights to the console prompt, such as what screens can be accessed, what NLMs can be loaded, and even how many users can access the console remotely at any given time.
The responsibility of the SC-CONFIG object is to provide all server-centric configuration information to every server running the SecureConsole agent (SECURCON.NLM). Through this object, every feature-from auditing to login caching, even the type of NetWare console screensaver-can be configured in one central place.
Although both of these functions may be combined into a single object, they should remain separate for deployment in a large environment. When you have multiple profile objects, it is strongly recommended to employ just one master configuration object. This will aid not only in centralizing the front-end administration, but also in maintaining the back-end configuration file as well.
During both the initial and subsequent rollouts, the installation can be scripted to automatically point each new server at the root configuration profile. Figure 2 illustrates this particular strategy.
SecureConsole Profile object layout.
Placing the SC-SECURITY object at each regional (or in our case, "planetary") location accomplishes two key tasks:
It allows for more granular control of console access rights, as opposed to just having one object directly off [Root].
It creates a more administrative-friendly environment for rights management.
Once these objects are put into place and properly configured, it's time to assign rights for all affected users.
Group Security
Most astute network administrators take advantage of groups to make 99% of all rights assignments, both at the file and directory levels. Fortunately for me, the rebellion leaders readily endorsed this approach. Although we will be creating some additional groups down the line to accommodate administrators with special needs, we only use the existing security groups for now. Below is a table highlighting the current rights assignments:
|
Admin Type
|
Group Name
|
Assigned Rights
|
SC Rights
|
|
Galactic Admin |
GALAXYADMIN |
Full S to object and property |
SC Admin quivalent |
|
Planetary Admin |
DAGOZONE |
Full S to object and property to Dagobah down |
Non-SC Admin |
|
ENDOZONE |
Full S to object and property to Endor down |
Non-SC Admin |
|
|
HOTHZONE |
Full S to object and property to Hoth down |
Non-SC Admin |
|
|
TATOZONE |
Full S to object and property to Tatooine down |
Non-SC Admin |
Sample Deployment Strategy
This section describes the deployment strategy used in our example scenario.
Use of .IPS Files
Protocom supports an assortment of methods for installing SecureConsole into your environment, the more common of which is the use of Novell's ConsoleOne. Although this is the preferred method, that does not necessarily imply it is designed for implementation in a large environment. In fact, entirely the opposite is true.
Granted, using ConsoleOne to deploy the initial code provides a nice GUI playground to do so. However, this makes several assumptions, one of which is that the deployer has already installed the proper snap-ins to his/her workstation. By utilizing the power of a simple .IPS script file instead, the installation can be entirely automated on the back end. A sample .IPS file is shown below.
@Version 3.4.4SyntaxVersion 1.03 'CoPyRiGhT=(c) Protocom Development Systems Ltd. All Rights Reserved.' VeRsIoN=3.4.4 Secure Console Novell IPS Install Script for INSTALL.NLM********************************************************************** Language file set declaration**********************************************************************Filesetlass: OPTIONALescription: 'SecureConsole For NetWare'elp: '!! IMPORTANT !! This option copies and sets up the SecureConsole program files. If you are upgrading from a previous version please ensure you have taken backups of your SECURCON.CFG, SECURDWN.HLP and SECURCON.HLP files as these will be overwritten during the upgrade. If an existing database is found, you will be asked to confirm whether it should be overwritten. If you have any difficulty installing SecureConsole, please contact 24 hour technical support on US800\\581\\3502 or support@serversystems.com'ame: SCNLMSytes: 1800000opyToServer 'SYSTEM\\SECURCON', 'NLM\\*.*', '', 'Secure Console Installation Diskette'roductRecord SECURCON, 1, '(CompanyName) - Secure Console for NetWare'roductRecord SECURCON, 0, 'V3.4.4'roductRecord SECURCON, 4, 'SYS:SYSTEM\\SECURCON\\SCREMOVE'ommand 'ICMD'ONSOLE 'SYS:\\SYSTEM\\SECURCON\\SCDEPLOY.NCF', 3ONSOLE 'DEL SYS:\\SYSTEM\\SECURCON\\SCDEPLOY.NCF', 1EndFilesetFilesetlass: OPTIONALescription: 'Protocom SLP Serverelp: 'This module install Protocom's SLP server.'ame: SLNWSLPytes: 11000opyToServer 'SYSTEM', 'SLP\\*.*', '', 'Protocom SLP Diskette'roductRecord SLNWSLP, 1, 'Protocom SLP Module'roductRecord SLNWSLP, 0, '1.80d'EndFileSet
A few key items need to be pointed out in this example file:
Vendor-specific SLP. This is not a replacement for Novell's SLP service; rather, it is an enhanced SLP Server-service used by Protocom to register services specific to the SecureRemote portion of the product. In addition, this product is listed as "Optional," as it is only required if you decide to deploy the SecureRemote client.
SCDEPLOY.NCF. The original script provided by Protocom calls SCINSTAL.NLM. The problem is that no switches can be passed using Novell's standard EXEC statement. By using the CONSOLE command, you can embed all necessary switches into an .NCF file, subsequently calling this from with the primary .IPS file.
Auto-Scripting
Now that we've generated our .IPS file, it's time to address the final issue: location-specific object calls. As previously stated, every planet has its own security object in the tree, and therein lies the problem. We can't just create a master file distribution area and set all servers to launch a particular executable. Doing so would configure every SC-server object to point at one global security profile, create a massive tear in the universe. This would not be a good thing.
A much more acceptable workaround is in the implementation of a planetary-specific .NCF file, as shown below. (This example is specific for Dagobah.)
LOAD SYS:\SYSTEM\SECURCON\SCINSTAL.NLM /q /m /c /1 /2 /5 /6 /r /4 /E<emergency user> /O<emergency password> /x.SC-CONFIG.JEDI /y.SC-SECURITY.DAGOBAH.JEDI
Here is a quick explanation of the pertinent options in the above command line:
/q = Launch SCINSTAL in quiet mode
/E = Defines emergency username
/O = Defines emergency user password
/x = Configures location for Configuration Profile object
/y = Configures location for Security Profile object
There are several advantages to implementing the above script. The most obvious is that it's user proof. The less intervention that is required by the end user (implementer), the less chance there will be of a mistyped password or improperly configured profile object.
Conclusion
This AppNote has explored some of the major design issues involved in a large-scale implementation of Protocom's SecureConsole solution. It has also provided a sample deployment strategy based on a real-life installation.
For more information about SecureConsole, visit Protocom's Web site at: http://www.protocom.cc/SecureConsole.htm.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.