LDAP Schema

Employees | Students | Other | Fields

DNs

dn: uid=NNNN,ou=people,dc=rutgers,dc=edu

eduPerson

eduPerson is a standard used by the Internet 2 community, to facilitate cross-institutional projects. I’ve started adding some of the attributes from eduPerson. In particular, I’ve started with the ones that are likely to be most useful for Shibboleth, because we’re starting to do a Shibboleth pilot.

You might want to look at the section below on eduPerson. If the information you need is available from eduPerson-defined attributes, there may be an advantage to using them. Your application is likely to be more portable. However you should beware that the exact way in which Rutgers information is mapped onto the eduPerson structure could conceivably change.

Comment on staff attributes and data flow

Data flow

Data on employees comes from the payroll system (Administrative Systems) via the IDM Registry. The LDAP employeeType attribute is set from the Registry role. Roles of FACULTY, STAFF and STUDENT WORKER represent employees of various types:

• 1 – normal employee – FACULTY or STAFF
• 3 – does not occur – shown as type 1
• 4 – part-time staff – STAFF
• 5 – student employees – STUDENT WORKER
• 6 – grad assistant – FACULTY
• 7 – part-time lecturer – FACULTY
• 8 – co-adjutants – FACULTY

The numerical type code is stored in the rutgersEduEmployeeType attribute.

Employees come into the system when a department files a PAF (Personnel Authorization Form). In all cases it includes an appointment begin date, which is the date when the role starts. In practice however employees typically do not appear in the Registry (and thus in LDAP) until several weeks after this date, because data is not entered until their first pay check.

For permanent employees (i.e. all except type 4 and 5), the PAF may also include an expiration date. This is commonly used for 10 month employees and for part-time lecturers and others contracted for a specific period. At that date, the role is expired, at which point it no longer shows in the employeeType attribute. Staff who have access to administrative applications also have those access rights terminated.

Permanent employees may also be terminated using a PDR (Personnel Data Record) with a “separation date” filled out. This results in the employee being terminated on that date. This is used whenever employees leave the University other than at an expiration date. At this date, the role no longer shows in employeeType, and access to administrative applications is removed.

As of June 1, 2004, permanent employees whose role expires will have their expiration dates extended for 90 days. This is intended to be long enough that 10 month employees will have their roles continue over the summer, and part-time lecturers will have their roles continue over the gap between semesters if they are appointed for the new semester. All other processing will continue as documented.

This extension makes sense because most staff with expiration dates are actually reappointed for the next year or semester, and we do not want them to lose all access. For cases where a department knows that a staff member will not be coming back, we encourage them to terminate the employee, using a PDR with a separation date. Separation dates will not get the 90 day extension.

The situation with type 4 and 5 employees is more complex. There is no ongoing contract with these employees. Once an employee is put into the system via a PAF, any department can employee them. So there is no way to know for sure when one has left. In February of each year, entries are purged for type 4 and 5 staff who did not have a paycheck between July and December of the previous year. When the entry is purged, the employeeType of STAFF is removed, and any administrative access is terminated.

LDAP includes data for staff with a current FACULTY, STAFF or STUDENT STAFF role.

Attributes

Currently staff attributes such as location have only one value. Some staff hold more than one position. However one is defined as primary. The attributes come from that.

employeeType is an exception. Every current role that the person has in the Registry is shown.

Note that different data is available for permanent and temporary employees. All employees, temporary and permanent, have a “paycheck location”. This is in principle the location to which their checks are sent. However for temporary employees, data based on this (both location and department) is unreliable. This data is normally entered only when the employee first joins Rutgers. If they move from area to area it is normally not updated. (For temporary employees, checks are actually sent to a location supplied as part of their biweekly vouchers, so there was no compelling need to update the data in payroll. That actual location is not captured in any database.)

Permanent employees have additional data, which should be more reliable. This includes an “organization code”, a “reporting relationship code”, and a department name. However this data does not exist for temporary employees. A list of organization codes and corresponding reporting relationship codes is available at the University Human Resources Administrative Systems information site. UHR recommends that anyone that needs to identify departments in an application should use the organization code. Reporting relationship codes change in reorganizations. It is not uncommon for departments to have their name changed. However organization codes should be stable.

Except if you need to deal with temporary employees, you are better off using rutgersEduStaffDepartment than “ou”. rutgersEduStaffDepartment is the name associated with the organization code. “ou” is the name from the department associated with the check location. However we recommend that you only use the department name when you need to produce a human-readable screen: use the organization ID for internal processing. However if you need to deal with temporary and student employees, you will need to look at the “ou”.

Comment on student attributes and data flow

Data flow

Beyond basic name and role, student data comes from the student data warehouse and from course registration. (The processes that generate this data and feed the data warehouse are not under control of the LDAP group.) The student data warehouse has major, unit of registration, etc.

Students include employee types of ADMIT COMING, STUDENT, SUMMER STUDENT, WINTER STUDENT, PRIOR STUDENT, and ALUMNI.

Student roles are driven by basic student admissions and registration processes.

In the Student Records Database (SRDB), one can tell that a student has been admitted. However that fact is not reflected in the Registry, and there is no ADMIT role. You should be aware that when talking about admissions processes, people sometimes speak of an ADMIT status, even though there is no actual Registry role with that name.

Students become ADMIT COMING when they are accepted and return a form indicating that they are coming. Most undergraduates go through an ADMIT COMING status. Most graduate students do not. This means that graduate students often will not show in our data until they appear on campus and register.

ADMIT COMING is not used for summer and winter. The ADMIT COMING role will end Oct 15 or March 15 if the student doesn’t register. If they do register, ADMIT COMING ends on the same day that STUDENT starts.

The STUDENT role starts when the student registers. Registration starts several months before the beginning of a semester, so new students will have STUDENT status during semester before they actually arrive. If a continuing student does not register, they will lose STUDENT role in mid-August or mid-January. Most student have registered for the next semester by that time. However a few do not, so there will be some continuing students who briefly lose their STUDENT role.

When students who haven’t registered lose the STUDENT or ADMIT COMING role, they may disappear from LDAP. That will happen if they don’t have another active role (e.g. many students are also staff), and if they don’t have an active account on any of the primary OIT computer systems. (Everyone with an active OIT account remains in LDAP, even if they don’t have a valid role, because we use LDAP to process logins. You can tell whether they have a valid role by checking the employeeType attribute.)

Students are shown as STUDENT, SUMMER STUDENT, WINTER STUDENT when they are actually registered for classes. Note that it is possible for a student to be “deregistered” due to problems such as not having paid a bill. In general such students are not excluded from classes or removed from the dorms. In many cases they will end up registering, and it is not in our interests to do things that would make it difficult for them to complete the semester. When a student is deregistered, the STUDENT role disappears. At that point they have no active role. There is currently no practical way for us tell whether someone without a STUDENT role has been temporarily deregistered or has dropped out. There is data in the SRDB that gives at least a reasonable approximation, but these are not yet present in the Registry.

Students are shown as PRIOR STUDENT if either

• it’s between May and October and they have an October graduation but are not taking classes for their final Fall semester, or
• it’s in January and they have a January graduation.

This allows them to access applications they might need to finalize their graduation.ALUMNI indicates a student who graduated. The Registrar initiates a process showing that the student actually graduated. This may take a month or two after actual graduation. May graduates will probably continue showing as STUDENT until they get the ALUMNI role, because STUDENT status from Spring isn’t purged until mid-August. However December graduates may lose their STUDENT role before getting their ALUMNI role, because STUDENT role is purged mid-January, and graduation information is not necessarily entered by then. See the PRIOR STUDENT role mentioned above.

Once you have ALUMNI status, it continues indefinitely.

SUMMER STUDENT and WINTER STUDENT roles have no interaction with the normal student roles. You get them as soon as you register for the summer or winter term. That may well be several months in advance. The role ends August 31 for summer and January 31 for winter.

LDAP generally contains data for students who either have a currently active student role (other than ALUMNI) as well as people who have accounts on any of our primary systems. For students, those accounts are reviewed near the middle of Spring and Fall semesters. At that time, anyone who is not currently an active student is removed, after warning them and giving them an opportunity to fix up any problems with their status.

Thus we will list students who were temporarily deregistered, until the account review, as long as they created a computer account while they were still registered. We permit alumni to continue accounts for a year after graduation. Thus LDAP will include those alumni.

Attributes

The student data warehouse has data from the following students:

• Currently registered students: their whole history
• Not currently registered, but registered previous semester: their whole history
• Admit coming next semester
• Preregistered next semester
• Graduated in the last graduation cycle: their whole history

The data we get from the SDW will commonly include multiple terms. We need to pick one set of data from which to get campus, major, etc. You’d think we would pick the most recent semester, but it’s not that easy:

• Suppose someone is currently an undergrad but admitted to grad school. We want to show their undergrad data for the current semester.
• We probably don’t want to use summer school or winterim data for regularly enrolled students.

So the actual rule is to use current, then next, then previous semesters, and then go backwards. If summer or winter is the most recent use it, but only if the student isn’t enrolled in either the previous or next semester.

For this purpose we consider the semesters to change January 1 and June 1. I.e. if you are a current undergrad and admitted to grad school we’ll move to your graduate data on June 1.

LDAP generally contains data for people who either have a currently active role or who have accounts on any of our primary systems. (Presumably you aren’t going to be providing service to anyone else.) This may sometimes include former (or even future) students who do not meet the criteria for inclusion in the student data warehouse. There may also be people in the data warehouse that don’t fit these criteria, though it will be rare.

Course registration data comes from a different source. It has historical data for quite a long period. Data is loaded starting with the previous calendar year. Contact LDAP Support if you need additional data.

Other types of entry

In addition to faculty, staff and students with active roles, the system has data for anyone with accounts on any of our primary systems. This may include

• former faculty, staff and students who do not have currently active roles, but who haven’t yet had their access removed by an account cleanup
• alumni for a year after graduation
• guests
• anyone else who can convince one of the campus divisions to create an account for them (this is rare), or who a department indicates should be regarded as faculty, staff or student but whose Registry role does not reflect it.

There is a separate role for guests. Guests have entries in the Registry. In addition to some basic name and contact information, each guest will be a member of one or more “herds”. The term “herd” is probably going to be replaced by “subrole.” Basically we are coming to view the GUEST role as an extensible role, whose semantics are defined by subroles. Here are examples of subroles:

• Each campus system has a subrole. These are used for official OIT guests, who have a formal relationship with the campus that entitles them to computer services, but who are not actually paid by the University. They may be visiting scholars, members of groups such as the University Foundation (who are generally thought of as University employees although they aren’t paid by the University) and members of institutions with which we work closely.
• Departments who use OIT account management software may have one or more subroles. Members of a departmental subrole are authorized to create accounts on the department’s computers.
• We will be using subroles to accept feeds of people from institutions with which we have joint registration agreements or other reasons why we want data for them in the PDB.

At this moment, the subrole is not being loaded into LDAP. This makes it unattractive to use the GUEST role to control who has access to a service. There are so many different types of guest that you probably don’t want all GUESTS to have access to your service.

During 2004 we will be doing further development of guest processing. As part of this, we will load subroles. The current intention is to show this as part of employeeType. Thus a member of subrole UMDNJ-STUDENT (a hypothetical example: presumably used to accept a feed of UMDNJ students who are cross-registered in Rutgers courses) will show as an employeeType of GUEST:UMDNJ-STUDENT. However at this moment such a person would simply have an employeeType of GUEST. There is some discussion of separating the GUEST role into GUEST-STUDENT and GUEST-FACSTAFF.

Specific Fields

objectclass

top, person, organizationalPerson, inetorgperson, eduPerson, rutgersEduPerson

uid

Currently each entry has one uid. Generally this is the primary username registered in the Registry for that person, known as the “NetID”. Note that there are people who have accounts on the campus systems without having their username registered in the Registry. This will be their username.

Be aware that we may end up listing all uids registered for the person in the PDB. If that is done, the primary one will be first. The dn will be based on it.

If a user is in the PDB but has no username assigned (i.e. they have not created a NetID), then we will generate a uid of the form iid.xxx, where xxx is their IID. There has to be a uid because the DN will be built from the uid. If someone who previously did not have username gets one, the fake iid.xxx uid will go away.

Applications should not make any assumption about the format of the fake uid generated for users who have no registered username. In particular, there is no guarantee that it will continue to start with “iid.”

one to many values (currently always one), directorystring, case insensitive. Indexed equality, presence, substring. Visible to anonymous access, but only within Rutgers. However anonymous users may search for uid, even from outside Rutgers.

title

This is the job title from the payroll system. It exists only for staff. For temporary staff it may be out of date: information for them is set only when they are initially employed. Location, department, title, and any other information about them is not necessarily updated.

zero or one value, directory string, case insensitive match. Visible to anonymous access. While we will have at most one value, the schema (which we don’t control, since this is a standard attribute) permits multiple values.

rutgersEduRCPID, alias rcpid, 1.3.6.1.4.1.10962.1.1.1

This is the Rutgers Community Participant ID number, a unique number assigned by Administrative Computing Services for everyone in the Registry. This number should be used only by applications that are linked to the Registry/PDB. It should never be shown to a user, nor to any application outside Rutgers (see rutgersEduExternalRCPID for external use). It may be used by any application that is linked to the Registry/PDB both in the application itself and for synchronization with the Registry/PDB.

zero or one value, INTEGER, indexed for equality only. Not visible to anonymous access.

rutgersEduIID, alias iid, 1.3.6.1.4.1.10962.1.1.2

This is the Internal Identifier, a unique string assigned by Administrative Computing Services for everyone in the Registry/PDB. This identifier was originally created to take the place of the SSN as a key in applications that did not need access to the SSN. The RCPID was later created for essentially the same purpose. Each RCPID should correspond to exactly one IID, but there are IID’s associated with people who do not have RCPIDs.

Use of the IID is not as constrained as the RCPID. No user should have to know their IID. We recommend against showing it to the user. However it is not absolutely prohibited to show it.

This identifier is currently created using the user’s initials followed by digits for uniqueness. While we do not currently change IIDs, there is some concern that because of the use of initials, some users might find this a problem if their name changes. Thus there is some thought that the RCPID will be a safer identifier in the long run. However it is not clear that the RCPID will replace everything else: some institutions have found that it’s useful to have both an internal identifier such as the RCPID, which is never shown to anyone, and an employee number that can be put on ID cards and such. For example, if someone’s ID card is stolen, and the employee identifier is used fraudulently, we might need to change it. We don’t want to be in a position of ever having to change the RCPID. Until there is a clear resolution of how many identifiers we need and what the rules are, we are likely to continue using both RCPID and IID.

zero or one value, directory string, case insensitive match, indexed for equality only. Visible to anonymous access.

rutgersEduRUID, 1.3.6.1.4.1.10962.1.1.3

This is the Rutgers University Identifier. This is a unique identifier, as assigned by OIT Administrative Computing Services. It is intended to replace the SSN as the primary identifier for many purposes. Currently it is only defined for students. However it will eventually be defined for faculty and staff as well. At the moment it will exist for everyone in the Student Records Database (SRDB). This includes past students and applicants, as well as existing students. A surprising number of faculty and staff are included.

The RUID is a unique, immutable identifier. It is intended to be defined for everyone that appears in one of the official administrative databases. It is a 9-digit number, assigned from ranges that are not used for valid SSNs. It is considered to be semi-public. Thus it may not be used for posting grades, or other applications that would identify confidential information.

zero or one value, DirectoryString, indexed for equality only. Not visible to anonymous access.

rutgersEduStudentID, 1.3.6.1.4.1.10962.2.1.1.16

This attribute is present for most students. It is normally the SSN, and in fact many records refer to this as the SSN. However some students either don’t have an SSN or have requested that we use a different number than their SSN. Thus you should not assume that this is an actual SSN. E.g. you shouldn’t use it in constructing reports to government agencies that require an SSN. However it should be valid to use this to connect an LDAP entry with other university records, because most university records use this student ID rather than an actual SSN. If you have a documented need for the actual SSN to be available in LDAP, please report it and we’ll add it.

As of the weekend of February 11, 2006, this field will no longer be maintained. Values will be “frozen.” Thus people who have values will retain their current values, but new values will not be added. The field is likely to be removed in the future. Historically this field has often been used as the SSN, although it isn’t always. Should anyone have a documented need for the actual SSN to be available in LDAP, it will be added as a separate field, with very limited access.

zero or one value, directory string, case insensitive match. Indexed for equality only. Visible only to privileged applications. Even if you have a special DN and password you won’t see this field unless you specifically ask for it.

rutgersEduEmployeeID, 1.3.6.1.4.1.10962.2.1.1.17

This attribute is present for employees. The field name in the administrative data is SSN. As far as we know it is the actual SSN. However we can’t rule out the possibility that for a few people adjustments are made as we know they are made for students. Sometimes new employees do not yet have an SSN. In this case a temporary SSN is generated for them. However as of April, 2006, that temporary SSN is not fed to the PDB. Thus we will not have ID numbers for such employees until they get their actual SSN.

This field is carried to permit you to connect LDAP data with other University records. It should not be used to construct reports to external agencies requiring an SSN without further investigation. Note that the same person may have both the old student ID and an employee ID. Typically they will be the same, because both will be the SSN. However there are certainly people for which they are different. Thus applications should be careful to use the employee ID to connect to data from payroll and other employee sources.

zero or one value, directory string, case insensitive match. Indexed for equality only. Visible only to privileged applications. Even if you have a special DN and password you won’t see this field unless you specifically ask for it.

employeeType

This attribute is present for all roles in the Registry/PDB that are currently active for this person. It is in uppercase. The possible values are

STAFF, FACULTY, GUEST, STUDENT, SUMMER STUDENT, STUDENT WORKER, ADMIT COMING, ALUMNI, RETIREE, EMERITUS

Note that the traditional Rutgers employee type code (e.g. 1 for normal permanent staff, 5 for student staff) is also available as rutgersEduEmployeeType, although that attribute is visible only to privileged applications.

The following type codes appear in employee data. Here is how they appear to map to Registry roles:

• 1 – normal employee – FACULTY or STAFF
• 3 – does not occur – shown as type 1
• 4 – part-time staff – STAFF
• 5 – student employees – STUDENT WORKER
• 6 – grad assistant – FACULTY
• 7 – part-time lecturer – FACULTY
• 8 – co-adjutants – FACULTY

zero to multiple values, directory string, case insensitive match. Visible to anonymous access. Anonymous users will only see people with STAFF or FACULTY, since other entries are hidden. However if an anonymous user can see someone, they can see all the values of this attribute. That is, if someone is just a STUDENT, anonymous users will not see the entry. If they are both STUDENT and STAFF, anonymous users will see the entry with both values of employeeType.

cn, sn, givenname

This is from the Registry where possible. If there is no Registry entry, it is constructed from the GCOS field on the system where their account exists.

The system goes through some fairly complex analysis to get the right capitalization, and to figure out which part is sn and givenname. It should be right most of the time, but no guarantees. One value currently. However applications should not assume that, because many organizations handle nicknames by letting the user add additional cn’s. That could occur here.

one value currently, directory string, case insensitive match. Visible to anonymous access. While we will only generate one value at the moment, be aware that the schema (which we do not control) permits multiple values. indexed equality, presence, substring.

postalAddress, homePostalAddress, rutgersEduResHallAddress: 1.3.6.1.4.1.10962.2.1.1.18

From the Registry. No attempt is made to build an address from the GCOS field. A sampling of them shows that users don’t set them consistently enough to be worth dealing with.

postalAddress and homePostalAddress may exist for anyone in the Registry. rutgersEduResHallAddress exists only for students, and not all of them. It’s their address in a Rutgers residence hall.

Lines of the address are separated by ‘$’, per the LDAP specification.

A combination of heuristics and known exceptions are used to capitalize.

zero or one value, directory string, case insensitive match. Office data for faculty/staff is visible to anonymous access. Home and ResHall data is available only by special request. There are separate permissions for student and faculty/staff data.

rutgersEduStudentCampusAddress: 1.3.6.1.4.1.10962.2.1.1.26

This is a U.S. Mail version of the campus post office box, e.g. 34618 RPO WAY.

zero or one value, directory string, case insensitive match. This is only available by special request. It is currently controlled by the same permission as student home data. However if we get a request from someone who needs this and not home data, we’ll check with the Registrar. It may end up being public to anyone who is allowed to see the student.

telephonenumber, facsimiletelephonenumber, homePhone, rutgersEduResHallPhone: 1.3.6.1.4.1.10962.2.1.1.19

From the Registry. Again, no attempt is made to get a value from the GCOS field.

facsimiletelephonenumber (i.e. FAX number) is currently collected only for faculty and staff, and is an office number. There is a home fax attribute, but it’s not listed because we currently don’t have data for it.

telephonenumber and homePhone may exist for any user in the Registry. rutgersEduResHallPhone exists only for students, and not all of them. It’s their phone in a Rutgers residence hall.

Numbers are validity checked and normalized. Some heuristics are used, e.g. 51234 or 4451234 are recognized. But there are some numbers that can’t be made sense of (even by hand). The number is put into the form +1 732 445 1234×567, which is the current recommended format for LDAP.

zero to multiple values, telephoneNumber, case insensitive match. Indexed equality, presence, substring. Office data for faculty/staff is visible to anonymous access. Home and ResHall data is available only by special request. There are separate permissions for student and faculty/staff data.

mail

This is the address registered in the Registry. No address is created for users not in the Registry. This address is not used for routing mail.

This value is intended for people who want to know a user’s primary email address. There may be more than one value, because we have separate addresses per role. They are currently not in any particular order.

This address can be set in two places: when an account is created via RATS, or through the appropriate online application (ADR for faculty/staff or student web application for student).

In order to understand the algorithms, you need to know that in the administrative data there is a separate email address for each role. (Role is documented under employeeType.) The email address here is chosen by a fairly complex heuristic:

• Ignore ALUMNI
• Look only at addresses associated with roles that are active, if there are any.
• If no roles are active, look only at addresses associated with the role(s) that expired most recently.
• If several roles are active or expired at the same time, use roles in the following order: STAFF, FACULTY, GUEST, STUDENT, ADMIT COMING, any role with no email address listed.
• Only look at SUMMER STUDENT if no other role exists, even an expired one.

The reason SUMMER STUDENT is given such a low priority is that there is no way for the student to change it once it’s set.

Online ADR: This application is available to anyone with role STAFF or FACULTY, even part-time or GA. It sets the email address for STAFF, FACULTY, or both if the user has both roles.

Student web application: This application is available to anyone with role STUDENT and ADMIT COMING. It sets address for those roles. Thus it should never set SUMMER STUDENT.

When a student changes status from ADMIT COMING to STUDENT and from STUDENT to ALUMNI, the email address moves to the new role. Email addresses are also moved from STUDENT to SUMMER STUDENT and STUDENT WORKER.

When a user creates an account, the account creation program requires them to choose a role. Generally the roles are FACULTY, STAFF and GUEST for the campus faculty/staff systems and STUDENT, SUMMER STUDENT (summer only), and ADMIT COMING for the campus student system. The account creation program sets the email address for the role that the user has selected.

zero to multiple values, directory string, case insensitive match. Indexed equality, presence, substring. Visible to anonymous access.

rutgersEduCampusService, 1.3.6.1.4.1.10962.2.1.1.2

This is an experimental attribute, intended for applications that need to check the type of service a user is registered for.

Here are some examples of the attribute:

rutgersEduCampusService: student:newark:enabled
rutgersEduCampusService: facstaff:nb:probsh
rutgersEduCampusService: facstaff:nocampus:enabled

This gives the status of campus-based services. Currently that’s the only class of service we provide, although eventually we expect to authorize people for individual services. For each class of service for which the person is authorized, it lists

• student or facstaff: these are the only two classes of service.
• campus: newark, camden, nb or nocampus. nocampus is someone who registered through the netid web page. They explicitly do not want any campus-based services.
• status: enabled or something else. The something else indicates the reason service was disabled, but currently only campus staff know what the valid values are. Thus one should check for = or != enabled.

Note that we will authenticate a user if they are currently enabled for any service. At first one might think that if someone is disabled anywhere we should deny them everywhere. The problem with this is that probsh is the final status for people whose accounts are in the process of closing because they have left. We don’t want to disable a staff member who used to be a student while the student account is in the process of being closed. In a few cases whether a user can login or not doesn’t agree with what you’d expect from these attributes. That can occur for users with multiple usernames and/or RCPID’s, where the data isn’t entirely consistent. Normally this is a pseudo-user, not an actual person.

zero to multiple values, directory string, case insensitive match. Indexed equality, presence, substring. Not visible to anonymous access.

rutgersEduStatus, 1.3.6.1.4.1.10962.2.1.1.6

This is the overall status of a user. It has either “active” or “inactive”. This is our best indication of whether the person is a current valid user. It will be “active” even if the account has been locked for disciplinary or other reasons. See the section above on authorization for a more detailed discussion on the role of the various authorization attributes.

The right way to check whether someone is valid is rutgersEduStatus = active or rutgersEduStatus != active. Do not check for inactive, because we may extend this attribute to have several values giving more information about inactive users.

one, directory string, case insensitive match. Not visible to anonymous access.

rutgersEduLock, 1.3.6.1.4.1.10962.2.1.1.23

rutgersEduLock indicates that a user’s account has been locked. Currently there are four locks:

• RUTGERS:1 – this is a global lock, that is intended to be set only when there is a clear reason to disable someone in all applications throughout the University. This is a new feature, and policies haven’t yet been set, but it is intended that most applications will pay attention to this lock.
• CAMPUS:1 – this indicates that one of the campus divisions believes that the user’s password is invalid. In some cases this may be an inactive user whose password has not yet been updated to the current password scheme. More commonly, it indicates a user whose password has been used by hackers. We disable it until the user can change it.
• CAMPUS:2 – this indicates that the campus divisions have locked a user’s account for disciplinary reasons, or possibly because the user is no longer at the University and they are in the process of closing the account.
• REMOTEACCESS:1 – this indicates that the user should not be able to access modems and related services.

We will develop more specific categories over time.

zero to many, directory string, case insensitive match.

rutgersEduSpecFilter, 1.3.6.1.4.1.10962.2.1.1.20

This attribute is used only for special users that represent applications. It is an LDAP filter that is used to check all users that the application authenticates. It is text, e.g. “(employeeType=student)”.

When a connection binds to a user with this attribute defined, the filter is remembered as a property of the connection. Any further attempts to bind in the same connection are checked by this filter. This allows us to specify that some applications will only accept currently registered students, others only faculty, etc.

The filter may also be associated with a connection by IP address. See the next entry for details on the algorithm.

See the section on authorization for details.

zero or one, directory string, case insensitive match. Not visible to anonymous access.

rutgersEduSpecIP, 1.3.6.1.4.1.10962.2.1.1.21

This attribute exists only for special DN’s, i.e. DN’s that represent applications that use LDAP.

If an application first authenticates with its own DN and then does any user authentication, this attribute is not necessary. When the application authenticates, the system will notice the rutgersEduSpecFilter attribute associated with the special DN, if any, and apply the filter there to any user authentications in the same session.

However some applications use a separate connection for the user authentication. I.e. they authenticate as the application, look up information, close the connection, open a new connection, and then authenticate as the user. In that case we need a way to figure out which filter to apply to the user authentication. rutgersEduSpecIP allows us to specify one or more IP addresses for a special DN. Any connection from one of those IP addresses will be interpreted as from that application. Any filter associated with that special DN will be applied to attempts to authenticate.

The default filter is specified by the rutgersEduSpecFilter property on the DN uid=default.auth,ou=Special Users,dc=rutgers,dc=edu. This DN is defined as the default because it has an attribute of rutgersEduSpecIP = *.

The order of search is (1) check for a filter associated with any DN used for this session, (2) check for a filter based on the IP address from which the connection is coming, and (3) use the default filter.

Here’s the actual processing:

E.g., a connection comes from a client at 128.6.4.4. The application attempts to BIND to a DN uid=smith,ou=people,dc=rutgers,dc=edu.

First, check to see whether a filter is already associated with this connection because a previous BIND was to DN with the rutgersEduSpecFilter property.

If not, a search is done for (rutgersEduSpecIP=128.6.4.4). If an entry is found, and it has rutgersEduSpecFilter defined, that filter is used.

If no filter has been located yet, look up (rutgersEduSpecIP=*). This should lead to a default service DN. Use the rutgersEduSpecFilter attribute of that DN.

Once a filter has been located, check uid=smith,ou=people,dc=rutgers,dc=edu against the filter. If it fails, return “insufficient access”. Otherwise go ahead and check the password. If the password fails, return “invalid credentials.” If uid=smith,ou=people,dc=rutgers,dc=edu isn’t found, return the error code from the search, most likely “no such object”. For situations that imply a configuration error, e.g. the default filter can’t be found, “operations error” will be returned. If the user is found, but doesn’t have an appropriate ruauth entry, “inappropriate authentication” is returned.

zero to many values, directory string, case insensitive match. Not visible to anonymous access.

rutgersEduAuth, alias ruauth, 1.3.6.1.4.1.10962.2.1.1.1

This attribute contains information used by the system to authenticate users. It should not be used by anyone else, and thus is intentionally not documented here. It is subject to change without notice.

zero to two values, case sensitive match. Not visible to anonymous access.

rutgersEduNt4password, alias nt4password, 1.3.6.1.4.1.10962.2.1.1.4

This attribute is used for authentication by Bluesocket and other systems that need to do Microsoft authentication. It is a secondary password, encrypted using the Windows NT algorithm.

zero or one values, case insensitive match. Not visible to anonymous access.

rutgersEduHidden, 1.3.6.1.4.1.10962.2.1.1.3

This attribute is used for users who have requested their information to be hidden. It is not present for most users. When it is present there are two possible values:

• true – entry is hidden from all non-privileged users
• external – entry is hidden from access from non-privileged users outside Rutgers [In the future, users who have authenticated will be treated as from within Rutgers, no matter where the connection is coming from.]

For students, this attribute is controlled by the web application that is part of the Rutgers Online Directory. This application lets them hide their entry completely, or control release of specific fields. We set the value “true” if they have hidden their entry completely or if they have disabled display of the email address. Note that we do not keep any of the other data controlled by that application, so we don’t look at the settings for any other fields. Students will never have the value “external”.

For faculty or staff, the value “external” is set if they have checked the box in the online ADR saying that their email address should not be shown outside Rutgers. The value is “true” if their Online Directory entry is completely hidden. This can only be set manually, by special request to Administrative Computing Services. As of July 12, 2003, this value is not set for anyone.

Note: currently anonymous users can only see faculty and staff entries, so this attribute is largely irrelevant for students. For faculty and staff, in addition to checking this attribute, the entry is only visible outside Rutgers if the email address is defined. This setting is an interim measure, which may well change. Anyone who wants to make sure that their entry is not shown outside Rutgers should set the flag in the online ADR saying that their email address should not be shown outside Rutgers.

The reason we are currently hiding entries without email addresses is that all entries show the NetID. Email addresses are often based on the NetID. So showing the entry at all would let someone guess the email address with reasonable probability. If someone hasn’t registered their email address with the Registry, there’s a reasonable chance that they don’t want it released.

zero or one values, case insensitive match.

l

This is a standard LDAP attribute. It is intended to be set to a location, which in practice is normally a city name. On this system it is set to one of CAMDEN, NEWARK or NEW BRUNSWICK.

This is derived from the People Database. It is set from rutgersEduStudentLocation or rutgersEduStaffLocation. See their definitions below. If both student and staff locations are defined, the staff location is used. In New Brunswick, rutgersEduStaffLocation is a local campus, such as Cook or Busch. For purposes of deriving “l”, all New Brunswick locations are converted to NEW BRUNSWICK.

Note that for staff this is derived from the check location. See the note at the start of this section for the limitations of this data.

zero or one values, case insensitive match.

rutgersEduStudentLocation, 1.3.6.1.4.1.10962.2.1.1.7

This is set only for students. It may be set together with rutgersEduStaffLocation, if the user is both student and faculty/staff. This field is only visible to applications that have privileges.

This will be done of CAMDEN, NEWARK or NEW BRUNSWICK. It is our best estimate of the campus where the student is enrolled. There are three different fields in the SRDB containing location information. We use all three, in priority order:

• There is a location code associated with the curriculum. This represents the campus on which the student was most recently enrolled. It is not normally set, but it used for certain fields such as Nursing, which appear on several campuses. If the location code is set, and the value is Camden, Newark, or New Brunswick, that is used for the location. (The location may also be set to an off-campus location on which Rutgers offers courses. Such locations are not used. The effect is that students enrolled in off-campus programs are shown as on the primary campus for the school in which they are enrolled.)
• There is a “unit of affilation.” Certain schools, such as Engineering and Nursing, have students affiliate with a residential college in addition to their school affiliation. If this code is set, the campus associated with the affiliation is used.
• If neither of the preceding cases is defined, then the location is derived from the “unit of registration.” This is typically a school or college. The campus where the unit is headquartered is used.

zero or one values, case insensitive match.

rutgersEduStaffLocation, 1.3.6.1.4.1.10962.2.1.1.5

This is set only for faculty or staff. It may be set together with rutgersEduStudentLocation.

This will be one of CAMDEN, NEWARK or a New Brunswich campus, such as BUSCH, COOK, DOUGLASS, COLLEGE AV, LIVINGSTON. It comes from the payroll system, and is the campus on which the user’s unit it located. It is possible that the person may actually work on a different campus. See the Campus Address for the most accurate information on the person’s physical location.

Note this is derived from the check location. See the note at the start of this section for the limitations.

zero or one values, case insensitive match.

rutgersEduCampusLocation, 1.3.6.1.4.1.10962.1.1.4

This is set only for faculty or staff.

This consists of their Room Number, Building Name, and Campus separated by ‘$’, per the LDAP specification. It is similar to what is shown on the Rutgers Online Directory for Faculty/Staff.

zero or one values, case insensitive match.

ou

This is a standard LDAP attribute, the Organizational Unit. It is normally set to the name of a department or other unit.

In this case it is defined only for faculty or staff. It is set to the primary department where the user works. The ou value is derived from what Rutgers calls the Division and Department, separated by a colon, e.g. FACULTY-ARTS&SCIENCE:COMPUTER SCIENCES. Not all units use the part after the colon, e.g. COMPUTING SERVICES:. Note that the colon will always be present.

These values are taken from a table. You should not need to worry about the same value being spelled differently or having a typo.

Note this is derived from the check location. See the note at the start of this section for the limitations. Unless you need departments for temporary staff, we recommend using rutgersEduStaffDepartment instead.

zero or one values, case insensitive match.

rutgersEduStudentUnit, 1.3.6.1.4.1.10962.2.1.1.8

This attribute gives the primary unit in which a student was enrolled during his/her last term of attendance. It is set only for students.

Note: This attribute will be set for any for whom we have the data, even if they are no longer a student. If you are looking only for students that are currently enrolled in your unit, you should verify that role (i.e. employeeType) is STUDENT, or possibly “STUDENT or ADMIT COMING”.

It is derived from the text form of the “unit of registration” and “unit of affiliation”, separated by a colon. (See below if you prefer to use the codes.) E.g. ERNEST MARIO SCHOOL OF PHARMACY (UNG):RUTGERS COLLEGE. Most schools do not use the unit of affiliation (the part after the colon). In that case the trailing colon is still present. The unit of affiliation is used by certain schools where students are both enrolled in a school and affiliated with a residential college.

These values are taken from a table. You should not need to worry about the same value being spelled differently or having a typo.

zero or one values, case insensitive match. Visible only to privileged applications.

rutgersEduStudentUnitCode, 1.3.6.1.4.1.10962.2.1.1.13

This attribute gives the primary unit in which a student was enrolled during his/her last term of attendance. It is set only for students.

Note: This attribute will be set for any for whom we have the data, even if they are no longer a student. If you are looking only for students that are currently enrolled in your unit, you should verify that role (i.e. employeeType) is STUDENT, or possibly “STUDENT or ADMIT COMING”.

It is derived from the “unit of registration code” and “unit of affiliation code”, separated by a colon. E.g. for a student with StudentUnit of “ERNEST MARIO SCHOOL OF PHARMACY (UNG):RUTGERS COLLEGE”, this would be “30:RC”. This is provided because applications may prefer to test for codes rather than text.

The official way to tell whether someone is grad or undergrad is to look at this field. The unit of reg values for grad schools are 08, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 31, 34, 38, 53, and 56. All others may be assumed to be undergrad programs. Note that 90, 93, and 96 are summer / winter schools, which are categorized as undergrad.

zero or one values, case insensitive match. Visible only to privileged applications.

rutgersEduStudentCurricCode, 1.3.6.1.4.1.10962.2.1.1.14

This attribute gives the curriculum in which the student was registered during his/her last term of attendance. Only numerical codes are listed. Most staff and students are familiar with the codes because of their use in the published schedules.

Note: This attribute will be set for any for whom we have the data, even if they are no longer a student. If you are looking only for students that are currently enrolled in your unit, you should verify that role (i.e. employeeType) is STUDENT, or possibly STUDENT or ADMIT COMING.

This is derived from the curriculum code, option code and location code, separated by colons. For most purposes you probably need only the curriculum code. The option and location are used for certain situations where a unit offers a course on other locations. If you need the option or location codes you probably need to talk to an expert in the Student Records Database. A typical computer science major would have “198::”, because normally the option and location wouldn’t be present.

The valid curriculum codes differ for campus and level (grad or undergrad). To see the current list, go to the Schedule of Classes. Specify the campus, level and term you want. The next screen will have a pull-down labelled “select a subject area.” This gives the list of curriculum codes.

Dual majors will have two values. Currently the SRDB can only keep track of 2 codes. Students with more than 2 majors are tracked manually. There are plans to extend the SRDB to keep track of up to 5 codes. When that happens they will be loaded into LDAP.

zero, one, or two values, case insensitive match. Visible only to privileged applications.

rutgersEduStudentGradYear, 1.3.6.1.4.1.10962.2.1.1.22

This attribute is the last 2 digits of the student’s graduation year. Note that this is only approximate.

This field in the Student Records Database is used for two different purposes: graduation year and a code indicating the type of graduate program. Unfortunately these uses overlap: code 10 can be either a graduation year of 2010 or a terminal masters’ program. Thus this field is cleared when it is one of the graduate codes.

Warning: Law and Pharmacy set the graduation year for their graduate programs, so you cannot assume that students with this code set are undergrads. If you need to disambiguate, check rutgersEduStudentUnitCode. Values of 23:*, 24:* and 31:* indicate the three graduate schools that set the graduation year. For anyone else, this field indicates an undergraduate graduation year.

In summary, the only values that can occur are the last two digits of a graduation year, and the following codes:

• DC – DC only – students who have received permission from the Dean of students to pursue a part-time course of study for this term
• NM – Non-matriculated

If anyone needs the graduate codes, or a field indicating whether someone is a grad student, please request it from LDAP Support. It appears that there is no specific code for grad students in the SRDB. Rather, people who care about this know which unit codes are for undergrad and graduate colleges. However if someone needs it, an appropriate attribute can be created.

zero or one values, case insensitive match.

rutgersEduStudentGradMonth, 1.3.6.1.4.1.10962.2.1.1.24

This attribute is a code indicating the student’s graduation month. The code from the Student Records Database is returned with no further analysis. Numbers that occur are 1, 5 and 10, corresponding to January, May and October graduation.

zero or one values, case insensitive match.

rutgersEduStudentHousingCode, 1.3.6.1.4.1.10962.2.1.1.25

This attribute is a code indicating whether the student is in University housing. The value is from the SRDB without additional analysis. According to the schema, it is

• 1: Lives in University Housing.
• 2: Lives in Fraternity or Sorority House.
• 3: Lives with parents/guardians or relatives.
• 4: Lives off-campus.

However values other than 1 almost never seem to occur. There are about the right number of 1’s, and 5 3’s. It is strongly recommended that you use this field only to see whether the student is in University housing, and checking rutgersEduStudentHousingCode=1.

zero or one values, case insensitive match.

Access requires special permission. It is controlled by the same permission as dorm address, although that could change depending upon who needs access to it.

rutgersEduResidentialCollege, 1.3.6.1.4.1.10962.1.1.5

This new attribute lists the Residential College for a student. This field is needed due to the merging of the various Colleges into SAS. Currently it is only set for Douglass College students. If the student is a Douglass College student, the attribute is set to “Douglass”. Otherwise, the attribute is not set.

zero or one values, case insensitive match. Visible only to privileged applications.

rutgersEduStudentCourseReg, 1.3.6.1.4.1.10962.2.1.1.15
rutgersEduStudentCourseRegWithdrawn, 1.3.6.1.4.1.10962.2.1.1.31

The CourseReg attribute shows the courses for which a student was registered for the last 2 years. The format is year:semester:unit:curriculum:course:section[:supplement]. E.g. Computer Science 323, section 1, in New Brunswick would be “2003:1:01:198:323:01”. The semester number is 1 for Spring, 9 for Fall, 0 for Winter and 7 for Summer. You can expect other codes to show as various special sessions are included in central data.

The final optional component, the supplement code, is normally not present. The supplement code appears when two different courses would otherwise have the same course number. It is typically one or two letters. An example is “2008:7:22:390:603:60:NB” where “NB” is the supplement code.

Students who have withdrawn will have the course listed as rutgersEduStudentCourseRegWithdrawn rather than rutgersEduStudentCourseReg.

Note that students who are currently not enrolled may have old course data but not unit and curriculum.

Several past semesters are included because sometimes applications may need to deal with students that are still finishing incompletes. Also, we would prefer to let users determine the point at which their application starts looking at the next semester’s data, rather than changing all of our data at some arbitrary cutoff date. However it is not the purpose of this data to show a student’s entire academic record. Thus only 2 years of data are included.

zero or more values, case insensitive match. This attribute is available only to privileged applications. Even then it is available only for applications that specifically need it. (This is not an attempt to deny access where it’s needed. Rather, because this data is sensitive under FERPA, we’re trying to avoid showing it to applications that don’t need it.)

rutgersEduStudentGpaTerm, 1.3.6.1.4.1.10962.2.1.1.27

This attribute shows the GPA for the current term. This is a decimal number with up to three digits after the decimal point. Note that the decimal point is not present if it happens to be a whole number.

WARNING: This value is currently not loaded. After looking at the data, it’s unclear if it is useful. Data for the current term is never available, since grades aren’t reported until the end. The best we could do is the most recent term, but for some students that is summer and for other spring. Others may have skipped a term. If anyone actually needs this data, we will probably have to come up with a way of showing several recent terms. But LDAP is probably not the right place to get detailed transcript data. If you need this, please contact LDAP Support and we’ll look at the right way to handle it.

zero or one values, case insensitive match. You most specifically request access to this data if you need it.

rutgersEduStudentGpaCum, 1.3.6.1.4.1.10962.2.1.1.28

This attribute shows the cumulative GPA. This is a decimal number with up to three digits after the decimal point. Note that the decimal point is not present if it happens to be a whole number.

The SRDB has a separate cumulative GPA for each term. The values reflect that and all previous terms. We take the most recent one, including summer and winter terms. Since grades for a term are submitted after the end, the cumulative GPA does not reflect work from the current term. Note that this attribute is an exception to the processes described above. Normally we use a fairly complex algorithm to determine which term’s data to use. However for this one attribute, we use the most recent term for which there is non-blank data.

zero or one values, case insensitive match. You most specifically request access to this data if you need it.

rutgersEduStudentCreditHours, 1.3.6.1.4.1.10962.2.1.1.29

This attribute shows the number of course credit hours the student is attempting for this term. This is a decimal number with one digit after the decimal point. Note that the decimal point is not present if it happens to be a whole number.

zero or one values, case insensitive match.

rutgersEduStudentFtPt, 1.3.6.1.4.1.10962.2.1.1.30

This attribute shows whether the student is full-time or part-time. It is based on credit hours, but the cutoff is different for different colleges. The field contains either “P” or “F”.

zero or one values, case insensitive match.

rutgersEduReportingRelationship, 1.3.6.1.4.1.10962.2.1.1.9

This is a string indicating the reporting hiearchy of the individual. In fact the value we’re carrying doesn’t show the whole hiearchy. It goes only to the level of the department. Thus there is a one to one mapping between these codes and organization ID’s. Because we want to encourage applications to use organization ID’s, this attribute is visible only by special arrangement.

(We want applications to use the organization ID because reporting relationship codes change as reorganizations occur. A good reason for requesting access is if you have an application that actually cares what VP area or division someone is in, rather than just their department. Think carefully whether in case of a reorganization you want to keep a specific set of departments, or the departments in a particular area, even if they change.)

directory string, zero or one values, case insensitive match; visible by special arrangement only.

rutgersEduStaffDepartment, 1.3.6.1.4.1.10962.2.1.1.10

This is the department name associated with the organization ID. As noted above, this is only defined for permanent employees. If you are willing to have data only for permanent employees, we recommend using this in preference to the “ou” attribute. We recommend that you use this attribute only when you need to present a human-readable name; use the organization ID for any internal processing. Organizations are renamed from time to time, but their IDs don’t change.

directory string, zero or one values, case insensitive match; visible to anonymous users.

rutgersEduOrganizationCode, 1.3.6.1.4.1.10962.2.1.1.11

This is a unique integer representing the department. See the UHR site for a list of the codes. This is the preferred attribute to use for programs that want to know what department a person is in. Note that it is defined only for permanent employees.

Integer, zero or one values, case insensitive match; visible to anonymous users; indexed (eq). However searches based on this attribute may only be done by privileged applications.

rutgersEduEmployeeType, 1.3.6.1.4.1.10962.2.1.1.12

This is the traditional Rutgers employee type code, i.e. 1 for normal permanent staff, 5 for student staff, etc. If you are processing department or location information you may need to check this. The reporting relationship code, organization ID and staff department are defined only for type 1 and 6 staff.

Note that types 2 and 3 do not exist. Employees previously categorized as type 3 are shown as type 1 in this data.

Integer, zero or one values, case insensitive match; visible only to privileged applications.

eduPersonAffiliation

Here’s the mapping from Rutgers roles to eduPersonAffiliation:

• FACULTY: faculty, member, employee
• STUDENT, ADMIT COMING, SUMMER STUDENT: student, member
• STAFF, STUDENT WORKER: staff, member, employee
• GUEST: affiliate
• ALUMNI: alum, affiliate

Unfortunately the mapping isn’t perfect. In many cases GUEST should be listed as “member” although it’s unclear how to tell at the moment.

eduPersonPrimaryAffiliation

The primary affiliation uses the first affiliation in the following list: faculty, staff [but not STUDENT WORKER], student, employee, affiliate, alum. Note that grad assistants will be classified as faculty. It’s not clear whether that’s a bug or not. Someone who is shown as “employee” is a student worker who is not a student. If they were a non-student worker they’d be shown as staff. If they were a student they’d be shown as a student. Guests will be shown as affiliates. At the moment we encourage you to test for the affiliation you’re interested in from eduPersonAffiliation, rather than using PrimaryAffiliation.

eduPersonPrincipalName

This is NetID@rutgers.edu. For users without netid’s, iid.NNNN@rutgers.edu is used, where NNNN is their IID.

rutgersEduEmplId, 1.3.6.1.4.1.10962.1.1.8

rutgersEduDateOfBirth, 1.3.6.1.4.1.10962.1.1.6

rutgersEduGender, 1.3.6.1.4.1.10962.1.1.7

rutgersEduResidentialCollege, 1.3.6.1.4.1.10962.1.1.5

rutgersEduExternalRcpid, 1.3.6.1.4.1.10962.1.1.9

rutgersEduRCN, 1.3.6.1.4.1.10962.1.1.10

rutgersEduLastPasswordChange, 1.3.6.1.4.1.10962.1.1.11

rutgersEduPersonalEmail, 1.3.6.1.4.1.10962.1.1.12

rutgersEduSORSource, alias rutgersEduRBHS, 1.3.6.1.4.1.10962.1.1.13

rutgersEduRBHSPIDM, 1.3.6.1.4.1.10962.1.1.14

rutgersEduRBHSId, alias rutgersEduANumber, 1.3.6.1.4.1.10962.1.1.15

rutgersEduPHI, 1.3.6.1.4.1.10962.1.1.16

rutgersEduCountryOfResidence

This will be the two letter country code (ISO 3166) computed as follows:

1. If the rutgersEduResHallAddress attribute data exists (address type 9), use that country code (if there is one). Otherwise,
2. If the homePostalAddress attribute data exists (address type 1), use that country code (if there is one).

zero or one value, country code string, case insensitive match. Available only by special request. There are separate permissions for student and faculty/staff.

eduPersonAssurance

eduPersonEntitlement

uidnumber

This is a unique number, which should be used if you need something like a Unix UID, i.e. a unique number for each individual. However be aware that it is more than 16 bits. Certain older Unix implementations require that the UID be either 15 or 16 bits. Since the directory has about 100,000 entries in it, that can’t work. Numbers higher than 100,000 are used, because numbers are never recycled as old users move out and new ones are added to the system.

Integer, visible to anonymous users, indexed EQ.