LDAP, Server Schema at UIUC
This page contains information about the Urbana-Champaign campus LDAP server schema.
Download the latest schema file
The Campus LDAP schema (in Excel format) was last updated on August 1, 2017.
Levels of availability
There are two different levels of availability for the information in these fields. These levels include:
Public: This information is available to all users who query the ldap.illinois.edu server from an on-campus IP or from off-campus through the campus VPN.
Restricted: This information is only available to individuals who have a specific business need for it and who have been granted access by the Technology Services Identity and Access Management team.
Individuals in need of restricted information should contact techservices-iamu@illinois.edu to explain their business need and to be granted access.
How various fields are populated
The following are notes on how various LDAP attributes are populated.
- Affiliation based on type: The eduPersonAffiliation (and the related eduPersonPrimaryAffiliation attribute) has a controlled vocabulary defined by the eduPerson (external link) specification: student, staff, member, affiliate, employee. The uiucEduType values are mapped into these affiliation values as follows:
uiucEduType value eduPersonAffiliation values staff, emeriti staff, employee, member student, extramural student, member retired, unihigh, special, olli member allied, iei affiliate extrahelp employee degree alum The eduPersonPrimaryAffiliation attribute is intended to represent the primary role of the individual. The first value in the following list that occurs in the eduPersonAffiliation attribute is chosen as the primary affiliation: staff, student, member, employee, affiliate.
- The nickname attribute: The eduPersonNickname attribute is populated based on the eduPersonNickname attribute. These same values are also used to generate alternate givenName and cn values (see "Value generation for name-related attributes" below).
Note that the following rules are currently in place for generating values for eduPersonNickname from the nickname field in the Electronic Directory Editor:- nickname is converted into pure ascii and broken into 'tokens' (by whitespace and other separators). If the token is longer than nine characters, has anything other than alphanumeric characters, or is a common word (e.g., 'and', 'are'), it is discarded.
- If the token is the same as a previous nickname or firstname(s) of the person, it is discarded.
- Only up to the first four valid nicknames (based on the preceding rules) are used.
In addition, if the user has a two-word or longer firstname, each individual part of that will end up as additional values for eduPersonNickname. - Value generation for name-related attributes: A
variety of representations of a person's name are generated as values
for several of the attributes in order to make this LDAP directory as
useful as possible from an address book perspective. Common email
clients, such as Outlook or Thunderbird, do address book lookups against
an LDAP directory by constructing queries involving the standard
name-related LDAP attributes (e.g., cn, givenName, and sn)
unless the user does an advanced search or modifies the client's
preferences. And, these clients have different defaults in how they
specify 'wildcards' in the query. Thus, generating multiple values of
these standard name attributes helps increase the likelihood of finding
someone.
In order to improve the appearance of the name fields in displays, there are 'capitalization heuristics' that attempt to do the best job of guessing which letters should be capitalized. For those relatively few entries for which Technology Services does not have 'name component attributes' (e.g., last_name, first_name) specified, there are heuristics that guess the first and last names from the displayName attribute. Any Latin1 characters are 'folded' into the ascii equivalent.
In order to provide applications an easy way to determine the 'most official' form of the name, there are several name attibutes that have a single value. The displayName attribute contains your full name, your official University name from Banner. And, the attributes uiucEduFirstName, uiucEduMiddleName, uiucEduLastName, and generationQualifier (name_suffix) contain the name components.
The givenName attribute contains the first name and any nicknames generated according to the rules above. If the first name consists of multiple words, each is an additional value for givenName. The sn attribute contains the last name and, if the last name contains multiple words, an additional value for each. The cn attribute contains the full name and most of the various combinations of givenName and sn attribute values, in both "first last" and "last, first" order. - Value generation for address-related attributes: The
various official institutional address fields in Banner all have a
corresponding attribute in the directory, with the standard LDAP
attribute postal Address is populated with the campus address for staff
and faculty and the permanent address for students. As for the name
values above, heuristics are used to capitalize these addresses and, in a
few cases, attempt to 'normalize' them. This includes folding Latin1
characters into ascii.
Each of these addresses is stored according to the formatting rules for a postalAddress attribute (i.e., a dollar sign $ character is used to separate the lines of the address). Any $ character actually occurring in an address is appropriately escaped (\24) (i.e., the '6.27. Postal Address' syntax rules from RFC2252 are observed.) - Value generation for phone-related attributes: The various official institutional phone fields in Banner all have a corresponding attribute in the directory, The standard LDAP attribute telephoneNumber is populated with the campus phone for staff and faculty and the permanent phone for students. All the official phone values are reformatted into the international form as described in E.123 and recommended by RFC2252 and eduPerson. This generally has the form "+1 ddd ddd dddd".