Introduction

Delinea ADEdit is a command-line interface (CLI) utility that enables UNIX administrators to manage Delinea objects—such as zones, rights, and roles—in Microsoft Active Directory. This chapter introduces you to ADEdit’s main features and architecture.

How ADEdit uses Tcl

ADEdit is implemented as a Tcl application. Tcl (Tool Command Language) is a powerful but easy to learn programming language that provides full scripting ability. With Tcl, administrators can write simple management scripts that perform complex tasks with a single execution. Experienced Tcl programmers can also include ADEdit commands in their own Tcl applications to add Delinea management capabilities and GUI interfaces for ADEdit operations to those applications.

Administrators who aren’t familiar with Tcl can use ADEdit as a scripting tool on their Linux or UNIX computer to manage Delinea directly from the command line or by combining commands into scripts.

What ADEdit Provides

The purpose of ADEdit is to let an administrator with the proper Active Directory permissions fully manage Delinea objects from a UNIX console. By using ADEdit, for example, an administrator working on a Linux computer can perform common administrative tasks such as create a new user account, add a user to a new group, or assign a user to a new role. That same administrator might also query Active Directory for information about zones, groups, roles, or any other Delinea objects.

Because ADEdit is a more powerful and flexible tool, it is intended to replace some of Delinea’s previous-generation UNIX command line programs such as adupdate and adquery. Those previous-generation tools limited the operations administrators could perform to a computer’s currently joined zone and domain. With ADEdit, administrators can manage objects in any zone or domain and perform operations on many more features than were possible using its predecessors.

To give administrators additional flexibility for performing administrative tasks, ADEdit also allows for multiple modes of execution and provides its own accompanying library of predefined scripts for common tasks.

Administration Across Domains and Forests

ADEdit offers complete control of Delinea objects and properties from a Linux or UNIX console. Administrators with the proper permissions on the Active Directory domain controller can modify every aspect of operation that the Access Manager offers. For example, administrators can use ADEdit to create zones, add groups, delegate permissions, define roles, and modify user properties, group membership and role assignments.

ADEdit can operate on any domain in any forest. Its host computer does not need to be joined to a domain to work with that domain. As long as the administrator has the necessary authentication and rights to work on a domain, ADEdit can bind to the domain and work on it. ADEdit can also work simultaneously on multiple domains in multiple forests.

ADEdit enables you to manage all aspects of the access control and privilege management features of multiple Delinea software from a single CLI tool. For example, it can replace adupdate and adquery and offers the features of LDAP clients such as ldapsearch, without the limitations of those command line programs.

Options for Execution

ADEdit offers multiple modes of execution:

  • Interactive mode. In interactive mode, ADEdit executes single CLI

    commands in real time. You can enter a series of commands within a shell

    to perform simple administrative tasks. ADEdit offers command history

    that is persistent from session to session. You can use the up arrow and

    Enter keys to review and re-enter commands instead of retyping complete commands from scratch.

  • Script execution. ADEdit can accept and execute a Tcl script file that

    includes ADEdit commands. The Tcl scripting language includes full

    programming logic with variables, logical operators, branching, functions

    (called procedures in Tcl), and other useful program-flow features. As the

    script executes, ADEdit keeps the Active Directory objects that it is working

    on in internal memory. It does not require repeated queries to Active

    Directory as it works on an object.

  • Executable file. You can set up any ADEdit Tcl script as an executable file

    that can run by itself on a UNIX platform.

Scripting makes ADEdit a very flexible administration tool. You can use a single script to handle hundreds or thousands of repetitive tasks that would take a very long time to perform through the console. And you can write a set of scripts to quickly and easily check on and respond to current conditions. A script could, for example, create a new zone, read etc/passwd files on UNIX computers in that zone, and migrate all existing UNIX users it finds there into new zone user accounts. Another script could find users in specified groups and then assign a new role to all users in those groups.

With that power comes responsibility. It’s quite possible for an ADEdit script—or even a single ADEdit command—to completely erase Active Directory’s contents if used incorrectly. There are, for the most part, no warnings and there is no undo feature if this happens. Only knowledgeable users should use ADEdit, and it is important to test scripts in sample environments before deploying them to the enterprise.

Library of Predefined Procedures

ADEdit installs with an accompanying library of utility procedures called the ade_lib Tcl library. These procedures use ADEdit commands to perform standard administrative operations such as adding zone users to a zone group or creating a new Active Directory user. The procedures in the library also provide examples of how to use ADEdit commands efficiently in Tcl scripts. From these examples, administrators can learn how to use and adapt ADEdit commands in their own custom scripts.

How ADEdit Works with Other Delinea Components

ADEdit is part Delinea Server Suite and works with specific Windows and UNIX components of the Delinea architecture. As described in the Administrator’s Guide for Linux and UNIX, Delinea uses Active Directory, which runs in a Windows network, to stores Delinea-specific data such as zone information. To make computers part of an Active Directory domain, administrators deploy a platform-specific Server Suite Agent. After the agent is deployed and the computer joins an Active Directory domain, the computer is a Delinea-managed computer and ADEdit can define, retrieve, modify, and delete Active Directory and Delinea information for that computer.

Active Directory and ADEdit

Active Directory uses multi-master data storage. It replicates directory data on multiple domain controllers throughout a domain. Changes in data on one domain controller are replicated to the other domain controllers in the domain.

To perform virtually any operation, ADEdit must bind to one or more Active Directory domain controllers. ADEdit can then query Active Directory for data within bound domains, retrieve Active Directory objects, modify retrieved objects, create new objects, and delete existing objects. Those objects include all Delinea-specific objects such as zone objects, zone user objects, role objects, and more.

ADEdit is not limited in scope to Delinea-specific information. An administrator with full privileges could define, retrieve, modify, and delete information for any object or attribute in Active Directory.

Managed Computers and ADEdit

For computers to be managed by Delinea, they must have the Server Suite Agent installed and must be joined to an Active-Directory domain. The Server Suite Agent includes the following components that work directly with ADEdit:

  • adclient is a Delinea process running on a managed computer. The adclient process communicates with Active Directory to make its host computer part of the Active Directory domain. Applications that require authentication and authorization or other services then use adclient to query Active Directory for that information. In most cases, ADEdit connects directly to Active Directory without using adclient. However, there are some commands that use adclient to get information more efficiently than from Active Directory directly.

  • Delinea command line programs are commands administrators can run on managed computers to control adclient operations and work with the Delinea data stored in Active Directory. ADEdit replaces some of these commands, but occasionally works in conjunction with other commands such as adflush, especially when executing ADEdit commands that work through adclient. For more information about using command line programs, see the Administrator’s Guide for Linux and UNIX.

Other Administrative Options

ADEdit is intended to the primary tool for administrators who want to perform administrative tasks directly from a command line or in scripts on Linux, UNIX, and Mac OS X computers. However, there are two other administrative options for performing the same tasks outside of ADEdit:

  • The Access Manager console runs on a Windows computer and provides a graphical user interface that you can use for complete control of Delinea-related information and some Active Directory features.

  • The Delinea Server Suite SDK for Windows provides application programming interfaces (API) that you can use to control all of the same features provided the Access Manager console.

It’s important to realize when using any of these tools that an instance of one of these tools has no knowledge of other tool instances and acts as if it’s the only administrative tool at work. For example, if one administrator uses the Access Manager console to modify a zone object at the same time as another administrator uses ADEdit to modify the same zone object, their changes might clash. For example, if the changes are first saved by the administrative using Access Manager, those change might be overridden by changes saved by ADEdit. The last tool to save object data has the final say.

This is true as well for different instances of ADEdit. If two administrators both use different ADEdit instances simultaneously to work on the same object, the administrator who last saves the object is the only one whose work will have an effect on the object.

It’s important when using ADEdit in an environment with multiple administrators to retrieve an object, make changes, and check it back in efficiently to avoid conflicts. ADEdit object changes are not atomic.

It helps to bind all administration tools to the same domain controller within a domain to further minimize conflicts. If tools work on different domain controllers, one tool’s changes may take time to replicate to the other domain controllers, so other tools connected to other domain controllers won’t be able to see those changes immediately.

ADEdit Components

ADEdit has two components: the ADEdit application and the ade_lib Tcl library. They are both installed when the Server Suite Agent is installed on a Linux, UNIX, or Mac OS X computer to be managed.

A user can access ADEdit through a CLI in a shell or through an executing Tcl script or Tcl application. ADEdit’s Tcl interpreter executes the commands it receives from the CLI using the ADEdit commands and Tcl commands that are part of ADEdit. It may also use ade_lib Tcl library commands if specified. Tcl scripts and applications use ADEdit’s commands and ade_lib Tcl library commands directly. ADEdit binds to an Active Directory domain controller, with which it exchanges data. ADEdit may also (in a few cases) get data from Active Directory through the adclient process.

The ADEdit Application

ADEdit uses Tcl as its scripting language. Tcl is a long-established extensible scripting language that offers standard programming features and an extension named Tk that creates GUIs simply and quickly. Tcl is described in the authoritative book Tcl and the Tk Toolkit by John K. Ousterhout and Ken Jones (Addison-Wesley, 2010).

ADEdit includes a Tcl interpreter and the Tcl core commands, which allow it to execute standard Tcl scripts. ADEdit also includes a set of its own commands designed to manage Delinea and Active Directory information.

ADEdit will execute individual commands in a CLI (in interactive mode) or sets of commands as an ADEdit script.

The ade_lib Tcl Library

The ade_lib Tcl library is a collection of Tcl procedures that provide helper functions for common Delinea-related management tasks such as listing zone information for a domain or creating an Active Directory user. You can include ade_lib in other ADEdit scripts to use its commands.

To use ade_lib in a Tcl script or in an ADEdit session, begin the script or session with: package require ade_lib

ADEdit Context

When ADEdit commands work on Active Directory objects, they don’t specify a domain and the object to work on as part of each command. ADEdit instead maintains a context in memory that defines what commands work on.

ADEdit’s context has two types of components:

  • A set of one or more bindings that connect ADEdit to domains in the forest. Each binding uses an authentication to connect to an Active

    Directory domain controller. The authentication must have enough rights to

    perform ADEdit’s administrative actions on the domain controller. Each

    binding binds ADEdit to a single domain; multiple bindings bind ADEdit to

    multiple domains at one time.

  • A set of zero, one, or more selected Active Directory objects that ADEdit works on. A selected object is typically a Delinea object such as a zone, zone user, role, or NIS map, but can also be any generic Active Directory object. ADEdit stores each selected object with all of its attributes (called fields within ADEdit). ADEdit stores no more than one type of each selected object: one zone object, for example, one PAM application object, one generic Active Directory object, and so on.

An ADEdit session or script typically starts by binding to one or more domains. If ADEdit isn’t bound to a domain, none of its commands that work with Active Directory (which is most of them) have any effect. Once bound, ADEdit commands work within the scope of all currently bound domains.

An ADEdit session or script then typically selects an object to work on: it specifies an object such as a zone user object that ADEdit retrieves from Active Directory and stores in memory as part of the context. All subsequent zone user commands then work on the zone user object in memory, not the zone user object as it is stored in Active Directory.

When finished with a selected object, the session or script can simply ignore the object (if nothing has changed in it) or it can save the object back to Active Directory (if the object has been modified and modifications need to go back to Active Directory, overwriting the object there). The selected object remains stored in ADEdit’s context until the session or script selects a new object of the same type, which replaces the previous object.

By maintaining a context with selected objects, ADEdit avoids constant Active Directory queries for successive object management commands: A selection command queries Active Directory to retrieve an object. Reading or modifying object fields occurs internally and doesn’t require Active Directory queries. If the object is saved, a final Active Directory query returns the modified object to Active Directory.

Context Persistence

ADEdit’s context persists for the duration of an ADEdit interactive session. The context in an ADEdit script persists only until the end of the script’s execution.

Pushing and Popping Contexts

ADEdit can save and retrieve contexts using push and pop commands that use a stack to store successive levels of context. Pushing and popping contexts is useful within Tcl scripts when jumping to a procedure. The script can push the current context to the stack, create an entirely new context for the procedure, then pop the original context back when exiting the procedure.

Context Cautions

Working with ADEdit’s context requires some thought. Commands that affect objects don’t explicitly specify an object, so you must be careful to ensure that the correct object is specified before executing commands that affect the object. ADEdit has context reporting commands that help by showing current domain bindings and selected objects.

It’s important to realize that any modifications to a selected object have no effect until the object is saved back to Active Directory. If you forget to save an object, you lose all modifications.

If you keep an object in context a long time between selecting the object and saving the object, be aware—as noted earlier—that another administration tool may alter the object in Active Directory during that time and you won’t know about those alterations.

Logical Organization for ADEdit Commands

The commands you can execute with ADEdit fall into the following logical categories:

  • General-purpose commands that control ADEdit operation and provide

    information about ADEdit.

    For example, you use these commands to view usage help, set the LDAP

    query time-out interval, and quit ADEdit.

  • Context commands that set up and control the ADEdit domain context.

    For example, you use these commands to bind to a domain before

    subsequent object management commands, view current bindings, and

    change the context.

  • Object management commands that enable you to perform all of the

    same tasks as you can with Active Directory Users and Computers and

    Access Manager.

    For example, you use these commands to create, select, and manage

    zones, users, groups, computers, rights, roles and role Assignments.

  • Utility commands that perform useful data retrieval and data conversion

    tasks.

    For example, you use these commands to convert domain names and

    security principal names from one format to another.

  • Security descriptor commands that modify security descriptors and make

    them readable.

For example, you use these commands to convert security descriptors strings from one format to another.

For more information about the commands each category, see ADEdit commands Organized by Type.

For details about specific commands, see ADEdit Command Reference.