Introduction to directories
With any computing environment, organizations must be able to manage basic information about their users and computers so that users can verify or “authenticate” their identities, and can find and interact with the organization’s technology resources in an authorized manner. A directory system provides these services.
At the core of a directory system is a database that holds the information necessary to manage the user and computer accounts that are associated with a specific “domain”. A domain can be a single standalone computer or any number of related computers that share a common directory. The latter domain structure is stored on one or more central servers dedicated to this purpose called “domain controllers”.
By default, when a computer comes “out of the box”, it only has its own local domain, and when you define that first administrator account, information about that account is stored in the computer’s local directory. But computers can also join a larger domain whose directory information is shared by all of the domain’s member computers.
For the purpose of this discussion, the term “domain” will refer to this larger domain concept, since a local domain only uses a tiny subset of the larger domain’s robust functionality.
Any organization can set up one or more domains to manage its user accounts and computers, and most configure more than one domain. Here at UHCL, we have a production domain for faculty and staff accounts and systems, and another for students. Having multiple production domains enables the UCT support staff to easily customize policies to meet the needs of each constituency. We also have other domains that are used to manage the user accounts and systems associated with our testing environment.
LDAP – a protocol, not a directory system
LDAP is an acronym that stands for the Lightweight Directory Access Protocol – keyword “protocol”. As for any protocol, LDAP describes the methods that users and applications use to interact with target systems, in this case, the directory systems. Most directory systems, including our own instance of Microsoft’s Active Directory, use LDAP to communicate, as do the directory systems provided by Apple, IBM, Novell, Oracle, OpenLDAP, and other vendors. While it is fairly common for any of the aforementioned directory systems to be called "LDAP", LDAP and the directory system are not synonymous. So, rather than saying "that application authenticates against LDAP", it would be more appropriate to say "that application authenticates against Active Directory (via LDAP)".
Active Directory (“AD”) – Basic concepts
At UHCL, we use Microsoft’s Active Directory (“AD”) as our primary directory system. Active Directory holds a vast amount of information about the organization’s computers and the individuals who use them. Because the core of AD is a database with an updateable "schema" (basically the definition of the database's tables, data elements, etc.), it can be extended to include additional, custom information about the domain’s users and computers that the organization may want to track.
Organizations that manage multiple domains usually keep the information for all of its domains in a single, unified environment known as a “forest”. Having all domains in the same forest enables the support staff to efficiently manage policies and privileges across all of the domains or a specific subset.
To facilitate the management of the information in the directory database, AD provides an extensive set of functions for administrator use. Aside from creating, maintaining and deleting directory records, one of the most basic functions is to assign users and computers into user groups and computer groups, respectively. User groups can help administrators manage the access privileges for all of the members of a group by granting those privileges to the group itself. To give a new person access to the group’s resources, all an administrator needs to do is to add the new user’s identity to the group. When a user’s job functions change or the person leaves the organization, the administrator can remove that person’s ability to access the resources used by the group by just removing the user’s entry from the group.
Groups should not to be confused with organizational units (“OUs”). An organizational unit (“OU”) is a “container”, similar in concept to a file folder. By default, “objects” (e.g., users, computers) that are defined to the system are automatically assigned to either the “User” or the “Computer” OU. From the AD administrator’s interface, the user OU and the computer OU would each be displayed as a folder within the directory “tree”. All user records are displayed as objects under the user OU. All computer records are displayed as objects under the computer OU. Custom OUs can be added to the directory tree so that each object placed in that OU folder can be managed in a similar way. For example, the University may have a “UCT” OU under which all user records for UCT personnel and all computer records for UCT devices are stored.
Unlike groups, OUs cannot be used to assign access privileges to groups of users. Rather, OUs are used to assist in the administration of the OU's user records and computer records. Like a file folder, each OU can be set up with access privileges to allow specific users and user groups to access the OU container and its records, or to deny such access. In this manner, directory maintenance can be distributed to different administrative teams on a per OU basis.
Like a file folder, OUs typically inherits the policies of its “parent” folder, but these policies can be enhanced or replaced for selected OUs by authorized administrators using “group policy” functionality. It should be noted that the "group" in group policy does not refer to user groups and computer groups. Rather, the term "group policy" should be thought of as just a “group of policies”. The policies that can be managed through group policies are extensive, even including the ability to install software on an OU’s computers.
Identity management is a term used to describe the processes and systems through which user records in a directory system authorized, created, maintained, disabled, deleted and de-authorized. An identity management (“IDM”) system is software that facilitates the execution of identity management functions through automation. Usually, IDM systems link to Enterprise Resource Planning (“ERP”) systems like PeopleSoft, so for example, when a new employee is added to the ERP system, the IDM could add a new user record to the directory and assign it to the appropriate groups based upon certain information about the new person (e.g., department, job function, level). When a person changes his or her department, job function, etc., the IDM can automatically make any necessary adjustments in the directory, often without any manual intervention. When a person is no longer a part of the organization, his or her associated records in the directory system can be automatically disabled or deleted.
In addition to the IDM system's automated record management capabilities, these systems include functionality to allow administrators to perform manual updates to directory data, to run standard, custom and ad-hoc reports, to extract data into spreadsheets, to alert specific individuals when certain defined conditions occur, to import and export records and to back up the database.