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