The Enterprise Directory provides a high-performance read-only interface via the LDAPv3 protocol intended for authentication, authorization, and directory queries. Three views of the directory schema are provided for these use cases:
|ED-Lite||Anonymous||Public directory or whitepages lookups|
|ED-Auth||Person||Person authentication and authorization|
|ED-ID||Service||Fine-grained access to privileged data elements|
The view of the directory is a function of the security context in which directory operations are performed. In other words, the way you bind determines what view you see. All views share a common directory schema that consists of the following object classes:
While all branches are available in all directory views, not all directory entries are available; similarly all attributes of visible entries may not be available. For example, since entitlements are only visible to principals that have defined roles on the entitlement (viewer, manager), no entitlements are visible in ED-Lite since the security context is anonymous.
Binding to ED-LDAP anonymously results in the view we refer to as ED-Lite.
ED-Lite contains public directory information that is world readable. It is the source for all the information contained in People Search:
ED-Lite is available at:
Some data can be suppressed in ED-Lite depending on a user’s affiliations and preferences. The rules are listed below.
The following affiliations roll up to the VT-ACTIVE-MEMBER affiliation, which overall suppression is based on:
The following affiliations do not roll up to the VT-ACTIVE-MEMBER affiliation:
- All Alumni affiliations
- All VCOM affiliations
The following rules for displaying information in ED-Lite should be treated individually. That is, if rule 1 is met, the information is displayed for that individual and rule checking stops. In other words, you only go to rule 2 if rule 1 doesn’t apply.
- If any of the affiliations present is VT-EMPLOYEE-STATE, then display the Employee attributes taking into account the suppressedAttribute attribute for addresses and phones.
- If at this point, any affiliation present is VT-EMPLOYEE-PREHIRE, then do not display any information about this person.
- If at this point, any affiliation present is VT-STUDENT-ENROLLED or VT-STUDENT-FUTURE and the Confidential flag is NO, then display the Student-Not Confidential attributes taking into account the suppressedAttribute attribute for addresses and phones.
- If at this point, any affiliation present is VT-STUDENT-ENROLLED or VT-STUDENT-FUTURE and the Confidential flag is YES, then do not display any information about this person.
- If at this point, any affiliation present is VT-EMPLOYEE-WAGE or VT-EMPLOYEE-NON-STATE, then display the Others attributes.
- If at this point, any affiliation present is VT-STUDENT-RECENT and the Confidential flag is NO, then display the Student-Not Confidential attributes taking into account the suppressedAttribute attribute for addresses and phones.
- If at this point, any affiliation present is VT-STUDENT-RECENT and the Confidential flag is YES, then do not display any information about this person.
- At this point, display the Others attributes.
|Attribute||Employee||Student (Not Confidential)||Others|
|Home department for an employee||OK||X||OK|
|Instant messaging Ids||*||*||*|
|Webpage(s) associated with person||*||*||*|
|Local phone (MA or DM in Banner)||OK||OK||X|
|Local postal address (MA or DM in Banner)||OK||OK||X|
|Preferred email address||OK||OK||OK|
|Mail code for employees||OK||X||OK|
|Postal Address (OF in Banner)||OK||X||OK|
|Office phone number (OF in Banner)||OK||X||OK|
* Indicates the individual users should indicate this in MY VT as to whether or not they desire to make this information available via ED-Lite
Binding to ED-LDAP with a simple bind using TLS is commonly referred to as ED-Auth.
ED-Auth is used primarily to authenticate users by PID and password. It can also be used for authorization using VT affiliations and ED group membership.
Binding to ED-Auth is typically done by searching for the PID, called uupid in ED-LDAP, and then binding with the returned DN and user supplied password.
As a bound user, applications can check affiliations or group membership for authorization.
ED-Auth is available at:
You must use TLS when using ED-Auth. Failure to do so will result in LDAP error 13, confidentiality required.
Always use TLS.
ED-Auth IP Restrictions
ED-Auth will only authenticate users for clients from specific IP addresses.
Allowed IP Addresses
TLS Client Auth
In addition to the list of allowed IP addresses, clients that perform TLS client authentication with a certificate for an active ED Service will also be allowed to authenticate Guests.
Note that this feature will not work for Virginia Tech or Sponsored people since ED-Auth restrictions went into place on January 3rd, 2018. It does work for Guests.
Clients that aren’t in the allowed IP ranges or perform TLS client auth with an active ED Service (Guests only) will see LDAP error 49, invalid credentials. If you encounter this error and the user can login to valid VT services (e.g. https://auth.vt.edu), you should check that your client IP is in the allowed range (or your ED-ID services is active and you are doing TLS client auth).
Users are able to suppress their uupid attribute in ED-Auth, which can cause issues if an application expects the attribute to always be available.
To allow the lookup of a single uupid but prevent the enumeration of them all, exact searches will always return the uupid. Wildcard searches will never return the uupid.
Suppose you are looking for pid1234. The filter:
will return the entry with the uupid attribute since it is an exact search.
If you use the filter with a wildcard:
the entry will be returned, but will not contain the uupid attribute.
Binding to the directory with a service credential, typically a certificate via the SASL EXTERNAL authentication mechanism, provides access to the ED-ID view of the directory. ED-ID is used to look up information about users that is typically not public. This information can be used by applications for:
- Making business decisions
- Showing additional data about people
- Authorizing users
Access to ED-ID requires an ED Service, which is issued an X.509 certificate by the VT Middleware CA. The service certificate is used to perform TLS client authentication to the directory, which then allows us to bind using SASL EXTERNAL.
Entries in ED-ID include:
The attributes available for view by ED services must be approved during the registration process. In this way, specialized views can be created for each ED service. Request an ED service.
The Enterprise Directory Schema consists of the following object classes:
ED Usage Requirements