skip to main content

Directory Services

White Pages Directory

Overview of Directory Services

Directory services is a shared information infrastructure that provides a comprehensive picture of an individual's relationship with the university by merging identification and role information from all systems of record on campus. This infrastructure is the foundation of campus identity management, authentication, and authorization.

White Pages Directory

The White Pages Directory is used by the campus community to look up public information for campus personnel.

Access to the White Pages Directory

The White Pages Directory supports anonymous binds from within the campus firewall.

White Pages Directory People Branch

The White Pages People branch supports queries for public information about people associated with the university.

Summary of Attributes

Below is a list of all attributes populated in the People branch with a link to particulars for each attribute. An summary of attribute population as a function of a person's affiliation is provided in the Attribute Population Matrix (pdf).

  1. General person attributes
  2. Student-related attributes
  3. Employment-related attributes
  4. Entry management attributes

Entry Structure

The People branch contains all entries for users with a direct, active affiliation to Texas A&M University.

The ldap entry for an individual is composed of standard LDAP objectclasses and of custom objectclasses specific to Texas A&M University.

Texas A&M University People Branch Object Class Hierarchy

Every entry in the People branch is assigned the following object classes:

  • top
  • person
  • organizationalPerson
  • inetOrgPerson
  • tamuEduDirectoryPerson

Conditional object classes that may be assigned to an entry in the People branch are:

  • eduPerson The individual is a published author with an ORCID identifier.

White Pages Directory Roles Branch

The White Pages Roles branch supports queries for public information about roles and organizations associated with the university.

Summary of Attributes

  1. General role/organization attributes
    • General attributes: Identifiers, access-related attributes, general information
      • Unique Identifier (uid)

    • General attributes: Names
    • General attributes: Electronic Mail
      • Primary/Published Email Address (mail)

    • General attributes: General
  2. Entry management attributes (attributes for identity, reconciliation, selection, and directory build)

Entry Structure

The Roles branch contains all entries for Texas A&M University roles and organizations.

The ldap entry for an individual role or organization is composed of standard LDAP objectclasses and of custom objectclasses specific to Texas A&M University.

Texas A&M University Roles Branch Object Class Hierarchy

Every entry in the Roles branch is assigned the following object classes:

  • top
  • organizationalRole
  • tamuRoleOrOrg

Attribute details term definitions

This table formats the attribute description information
Definition: An explanation of the exact meaning of the attribute. For attributes that are not unique to the Texas A&M LDAP directory, the definition is an explanation of the meaning of the attribute in the Texas A&M directory.
Attribute Name: Name of the attribute. More that one name can be associated with an attribute.
OID: Object identifier for the attribute. The object identifier is composed of a string of dotted numbers that uniquely identifies the attribute worldwide. The Internet Assigned Numbers Authority (IANA) governs the assignment of OIDs.
URN: Uniform resource name for the attribute. The uniform resource name has the syntax urn:NID:NSS where NID is the namespace identifier, and NSS is the namespace specific string. The namespace identifier determines the syntactic interpretation of the namespace specific string.
Multiple Values: Denotes whether or not the attribute is allowed to store more than one value.
Format: The encoding rules used for storing and transmitting values of the attribute type. The number enclosed by the curly braces specifies the minimum recommended maximum length of the attribute's value that a server should support.
Search Syntax: The grammatical rules and structural patterns governing searches on attribute values.
Controlled Vocabulary: A listing of allowed values. For attributes that have a controlled vocabulary, the definitions of the values will be provided as well.
Source: Rules governing population of the attribute.

Directory-specific details term definitions

This table defines attribute properties that are dependent on directory branch or object class configuration
Directory URL: Directory server URL.
Object Class: The object class that the attribute is associated with. It is possible for an attribute to belong to multiple object classes.
Required: Denotes whether or not an attribute must be present in an entry. In this case, "present" means "possesses at least one value".
It is the object classes that specify whether or not attributes are required or optional. For attributes associated with multiple object classes, they may be optional for one and required by another.
Indexing: Attributes may be indexed to optimize searches, similar to the indexes used by a relational database management system. LDAP supports four types of indexes. However, not all attributes support all four index types. Each index type corresponds to one of the matching rules defined in the directory schema.
approx (approximate)
Indexes the information for an approximate, or phonetic, match of an attribute value.
eq (equality)
Indexes the information necessary to perform an exact match of an attribute value. The match may be case-sensitive or whitespace-sensitive, depending on the matching rules defined in the attribute syntax.
pres (presence)
Indexes the information necessary to determine if an attribute has any value at all. If an attribute does not possess a value, then the attribute is not present in the directory entry.
sub (substring)
Indexes the information necessary to perform a simple substring match on attribute values.
Access: Denotes who has access to what.

Access control List (ACL) terminology for these parameters:

Who
* Matches any connected user, including anonymous connection
self The DN of the currently connected user, assuming he has been successfully authenticated by a previous bind request.
anonymous Nonauthenticated user connections
users Authenticated user connections
regular expression matches a DN or SASL identity

Access levels
(Higher levels possess all the capabilities of the lower levels.)
write Access to update attribute values (e.g., Change this telephoneNumber to 555-2345).
read Access to read search results (e.g., Show me all the entries with a telephoneNumber of 555*).
search Access to apply search filters (e.g., Are there any entries with a telephoneNumber of 555*).
compare Access to compare attributes (e.g., Is your telephoneNumber 555-1234?)
auth Access to bind (authenticate).
none No access.

What
The What defines the entry and attributes to which the ACL should apply. It is composed of three basic parts, all of which are optional. If none of these components are present, a single asterisk is used as a placeholder to include everything.
  • A regular expression defining the DN of the proposed target of the ACL. The actual syntax is dn.targetstyle=regex, in which targetstyle is one of base, subtree, one, or children, and regex is a regular expression representing a DN. The targetstyle, which defaults to subtree, is used to broaden or narrow the scope of the ACL. If, for example, the targetstyle is set to one the ACL applies only to children immediately below the defined DN. Very rarely does this setting need to be changed from its default. The regex follows normal regular expression rules, with the addition that the DN must be in normalized form.
  • An LDAP search filter that conforms to RFC 2254. The syntax for specifying a filter is filter=ldapFilter.
  • A comma-separated list of attribute names taking the form attrs=attributeList. If this item is not present, the ACL applies to all attributes held by the entry that matches the DN regular expression pattern.
Usage: Example(s) of known uses of the attribute values.
Example(s): Example(s) of values for the attribute. To make the example more helpful, the values are representative of a full-time staff person taking a class.