KU Enterprise Directory Specification (200408)
Copyright © 2004 by The
University of Kansas,
Internet2, and/or the respective authors
Comments to: aims@ku.edu
Table of Contents
The kuOrganizationalRole object class
The (200408) version of the KU object classes (kuAuthAccount, kuObject, kuPerson, kuAccount, and kuOrganizationalRole), and (200312) version of the eduPerson object class specification are described in this document. This version is currently in use in KU’s enterprise directory service environment.
EduPerson is an auxiliary object class for campus directories designed to facilitate communication among higher education institutions. It consists of a set of data elements or attributes about individuals within higher education, along with recommendations on the syntax and semantics of the data that may be assigned to those attributes.
The KU object classes extend eduPerson for use at the University of Kansas. The eduPerson attributes are found in the next section, with the KU attributes following. All these attribute names are prefaced with eduPerson. The eduPerson auxiliary object class contains all of them as “MAY” attributes:
Much of the descriptive text relating to eduPerson and the standard LDAP object classes is taken from the eduPerson 200312 specification produced by the Internet2/MACE Directory Working Group, dated December 2003.
Attributes listed in the standard object classes but not intended to be populated at KU will not be listed.
In general, these object classes apply to three branches of the KU enterprise directory. The main branch is ou=people, dc=ku, dc=edu, the authentication branch is ou=authaccounts, dc=ku, dc=edu, and the alias forwarding branch is ou=aliases, dc=ku, dc=edu.
We also have an ou=groups, dc=ku, dc=edu branch, but it is very standard in its format. There is an ou=automatic branch within it that contains automatically generated groups, but they are standard in form as well.
The ou=people, dc=ku, dc=edu branch contains a sub-object for each person, list, or departmental account. However, only departmental accounts with web login privileges (KU Online IDs) are included. Each of these sub-objects will contain the following classes:
Where these objects have a KU Online ID, there will be an owner attribute pointing to a corresponding object in the ou=authaccounts branch.
The distinguished name (or dn) for a sub-object of ou=people is of the form:
kuEntryId=entryID, ou=people, dc=ku, dc=edu
Each person object MAY contain one or more sub-objects indicating staff appointments. These are primarily intended for white pages lookups and provide a way to group department, title, address, and phone for the various positions. Only the primary appointment will be listed in the person object. These sub-objects will contain the classes top, organizationalRole, and kuOrganizationalRole.
The distinguished name (or dn) for a role object is of the form:
kuRoleIndex=index, kuEntryId=entryID, ou=people, dc=ku, dc=edu
The ou=authaccounts, dc=ku, dc=edu branch contains a sub-object for every KU Online ID. These sub-objects will contain the top and kuAuthAccount object classes, and are the objects that users must bind against. There will always be an owner attribute pointing to the corresponding object in the ou=people branch.
The distinguished name (or dn) for a sub-object of ou=authaccounts is of the form:
uid=onlineID, ou=authaccounts, dc=ku, dc=edu
The ou=aliases, dc=ku, dc=edu branch contains a sub-object for every domain that the KU MTAs translate and forward. Currently we forward ku.edu, kletc.org, kualumni.org, and kansan.com. Each of these branches contains a sub-object for every alias. These sub-objects will contain the top, kuObject, and kuAccount object classes, with a uid attribute equal to the incoming mail address (e.g. myalias@ku.edu) and a mail attribute equal to the destination address (e.g. myusername@mail.ku.edu).
The distinguished name (or dn) for a sub-object of ou=people is of the form:
uid=alias@domain, ou=domain, ou=aliases, dc=ku, dc=edu
The ou=people branch consists of the main white pages and authorization information for people, departmental accounts, and lists. This not a complete list of attributes, but in any case where the Core Middleware group considered that some comment was needed to clarify the meaning or utility of an attribute, it can be found here. For details on the syntax and other aspects of these attributes, see the appropriate standards documents.
Application utility class: extended; # of values: multi
Defines the building name for the person’s primary address.
directory of directories, white pages
buildingName: Strong Hall
Syntax: directoryString
Application utility class: extended; # of values: multi
country name According to RFC 2256, "This attribute contains a two-letter ISO 3166 country code (countryName).
set of ISO 3166 country codes
directory of directories, white pages
c: ca
Syntax: directoryString
Application utility class: core; # of values: multi
Common name.
According to RFC 2256, "This is the X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it is typically the person's full name.
Required. One of the two required attributes in the person object class from which eduPerson derives (the other is sn). As such it is one of eduPerson's three "core application utility" attributes. The third is eduPersonOrgDN.
With eduPersonOrgDN and cn, the client knows the person's name and the distinguished name of the organization with which he/she is assoicated. The latter could help them find a directory entry for the person's organization.
all
cn: Mary Francis Xavier
Syntax: directoryString; Indexing: pres,eq,sub,approx
Application utility class: standard; # of values: multi
Specifies the department numbers to which the person has staff appointments.
These are taken from the job table information in the Lawrence/Edwards HR and the KUMC HR extracts. It is possible that deptno values at the two campuses may collide, though they do not at present.
controlling access to resources
departmentNumber: 2151000
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the title(s) for the person. This is taken from either the Lawrence/Edwards HR extract or from the KUMC HR extract.
Can be anything. According to RFC 2256, "This attribute contains a human-readable description of the object." We are populating this attribute with the the titles for the person, allowing multiple values.
directory of directories, white pages
description: Chancellor/Professor
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single
The name(s) that should appear in white-pages-like applications for this person
From RFC 2798 description: "preferred name of a person to be used when displaying entries."
Cn (common name) is multi-valued and overloaded to meet the needs of multiple applications. displayName is a better candidate for use in Dod, white pages and configurable email clients.
directory of directories, white pages, email client
displayName: Jack Dougherty
Syntax: directoryString; Indexing: pres,eq,sub
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.1
NAME 'eduPersonAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Application utility class: standard; # of values: multi
Specifies the person's relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary)
faculty, student, staff, alum, member, affiliate, employee
If there is a value in eduPersonPrimaryAffiliation, that value should be stored here as well.
The list of allowed values in the current version 1.0 of the object class is CERTAINLY incomplete. We felt that any additional values should come out of discussions with the stakeholder communities. Any agreed-upon additional values will be included as part of the later versions of eduPerson.
We also deliberately avoided including a value such as "other" or "misc" because it would be semantically equivalent to "none of the above." To indicate "none of the above," for a specific person, leave the attribute empty.
The "member" value is intended to include faculty, staff, student, and other persons with a basic set of privileges that go with membership in the university community (e.g., library privileges). It could be glossed as "member in good standing of the university community."
"affiliate" is intended to apply to people with whom the university has dealings, but to whom no general set of "community membership" privileges are extended.
Each institution decides the criteria for membership in each affiliation classification.
A reasonable person should find the listed relationships commonsensical.
directory of directories, white pages, controlling access to resources
eduPersonAffiliation: faculty
Syntax: directoryString; Indexing: pres,eq,sub
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.7
NAME 'eduPersonEntitlement'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Application utility class: extended; # of values: multi
URI (either URN or URL) that indicates a set of rights to specific resources.
A simple example would be a URL for a contract with a licensed resource provider. When a principal's home institutional directory is allowed to assert such entitlements, the business rules that evaluate a person's attributes to determine eligibility are evaluated there. The target resource provider does not learn characteristics of the person beyond their entitlement. The trust between the two parties must be established out of band. One check would be for the target resource provider to maintain a list of subscribing institutions. Assertions of entitlement from institutions not on this list would not be honored. See the first example below.
URN values would correspond to a set of rights to resources based on an agreement across the relevant community. MACE (Middleware Architecture Committee for Education) affiliates may opt to register with MACE as a naming authority, enabling them to create their own URN values. See the second example below.
The driving force behind the definition of this attribute has been the MACE Shibboleth project. Shibboleth defines an architecture for inter-institutional sharing of web resources subject to access controls. For further details, see the project's web pages at http://shibboleth.internet2.edu/.
controlling access to resources
eduPersonEntitlement: http://xstor.com/contracts/HEd123
eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope
Syntax: directoryString
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.2
NAME 'eduPersonNickname'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Application utility class: standard; # of values: multi
Person's nickname, or the informal name by which they are accustomed to be hailed
Most often a single name as opposed to displayName which often consists of a full name. Useful for user-friendly search by name. As distinct from the cn (common name) attribute, the eduPersonNickname attribute is intended primarily to carry the person's preferred nickname(s). E.g., Jack for John, Woody for Durwood, JR for Joseph Robert.
Carrying this in a separate attribute makes it relatively easy to make this a self-maintained attribute (editorial oversight is advisable!). If it were merely one of the multiple values of the cn attribute, this would be harder to do.
Application developers can use this attribute to make directory search functions more "user friendly."
directory of directories, white pages
eduPersonNickname: Spike
Syntax: directoryString; Indexing: pres,eq,sub
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.3
NAME 'eduPersonOrgDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY distinguishedNameMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE )
The distinguished name (DN) of the of the directory entry representing the institution with which the person is associated.
With a distinguished name, the client can do an efficient lookup in the institution's directory.to find out more about the organization with which the person is associated.
Cn (common name), sn (surname, family name) and this attribute, eduPersonOrgDN, are the three attributes satisfying the "core" application utility class of eduPerson.
The directory entry pointed to by this dn should be represented in the X.521(1993) "organization" object class The attribute set for organization is defined as follows:
o (Organization Name, required}
Optional attributes include:
description
localeAttributeSet
postalAttributeSet
telecommunicationsAttributeSet
businessCategory
seeAlso
searchGuide
userPassword
Note that labeledURI is not included in the above list. We recommend adding the labeledURIObject auxilliary object class to the organization object pointed to by this dn, which endows it with a labeledURI attribute. Some directory servers implement this object class by default. For others, the schema may need to be extended using this definition (using the syntax specified by RFC2252):
( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' SUP top AUXILIARY MAY labeledURI )
directory of directories, white pages
eduPersonOrgDN: o=Hogwarts, dc=hsww, dc=wiz
Syntax: distinguishedName
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.4
NAME 'eduPersonOrgUnitDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY distinguishedNameMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' )
Application utility class: standard; # of values: multi
The distinguished name(s) (DN) of the directory entries representing the person's Organizational Unit(s). May be multivalued, as for example, in the case of a faculty member with appointments in multiple departments or a person who is a student in one department and an employee in another.
With a distinguished name, the client can do an efficient lookup in the institution's directory for information about the person's organizational unit(s).
The directory entry pointed to by this dn should be represented in the X.521(1993) "organizational unit" object class. In addition to organizationalUnitName, this object class has the same optional attribute set as the organization object class:
ou (Organization Unit Name, required}
Optional attributes include:
description
localeAttributeSet
postalAttributeSet
telecommunicationsAttributeSet
businessCategory
seeAlso
searchGuide
userPassword
Note that labeledURI is not included in the above list. We recommend adding the labeledURIObject auxilliary object class to the organization object pointed to by this dn, which endows it with a labeledURI attribute. Some directory servers implement this object class by default. For others, the schema may need to be extended using this definition (using the syntax specified by RFC2252):
( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' SUP top AUXILIARY MAY labeledURI )
directory of directories, white pages
eduPersonOrgUnitDN: ou=Potions, o=Hogwarts, dc=hsww, dc=wiz
Syntax: distinguishedName; Indexing: eq
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.5
NAME 'eduPersonPrimaryAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
Application utility class: standard; # of values: single
Specifies the person's PRIMARY relationship to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary)
faculty, student, staff, alum, member, affiliate, employee
Appropriate if the person carries at least one of the defined eduPersonAffiliations. The choices of values are the same as for that attribute.
Think of this as the affiliation one might put on the name tag if this person were to attend a general institutional social gathering. Note that the single-valued eduPersonPrimaryAffiliation attribute assigns each person in the directory into one and only one category of affiliation. There are application scenarios where this would be useful.
The list of allowed values in the current version 1.0 of the object class is CERTAINLY incomplete. We felt that any additional values should come out of discussions with the stakeholder communities. Any agreed-upon additional values will be included as part of post-1.0 versions of eduPerson.
We also deliberately avoided including a value such as "other" or "misc" because it is semantically equivalent to "none of the above." To indicate "none of the above," for a specific person, leave the attribute unpopulated.
"member" is intended to include faculty, staff, student, and other persons granted a basic set of privileges that go with membership in the university community (e.g., library privileges). It could be glossed as "member in good standing of the university community."
"affiliate" is intended to apply to people with whom the university has dealings, but to whom no general set of "community membership" privileges are extended.
Each institution decides the criteria for membership in each affiliation classification.
A reasonable person should find the listed relationships commonsensical.
directory of directories, controlling access to resources
eduPersonPrimaryAffiliation: student
Syntax: directoryString; Indexing: pres,eq,sub
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.8
NAME 'eduPersonPrimaryOrgUnitDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY distinguishedNameMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' )
Application utility class: standard; # of values: multi
The distinguished name (DN) of the directory entries representing the person's primary Organizational Unit(s).
Appropriate if the person carries at least one of the defined eduPersonOrgUnitDN. The choices of values are the same as for that attribute.
Each institution populating this attribute decides the criteria for determining which organization unit entry is the primary one for a given individual.
directory of directories, white pages
eduPersonPrimaryOrgUnitDN: ou=Potions, o=Hogwarts, dc=hsww, dc=wiz
Syntax: distinguishedName; Indexing: eq
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.6
NAME 'eduPersonPrincipalName'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
Application utility class: standard; # of values: single
The "NetID" of the person for the purposes of inter-institutional authentication. Should be stored in the form of user@univ.edu, where univ.edu is the name of the local security domain.
If populated, the user should be able to authenticate with this identifier, using locally operated services. Local authentication systems should be able to adequately affirm (to both local and remote applications) that the authenticated principal is the person to whom this identifier was issued.
The initial intent is to use this attribute within the Shibboleth project, http://middleware.internet2.edu/shibboleth. However, it has quickly become clear that a number of other applications could also make good use of this attribute (e.g. H.323 video, chat software, etc). eduPersonPrincipalName (EPPN) would be used as follows: A resource owner, A, would look at B's directory entry to discover B's EPPN. A would then tell the local authorization system that B's EPPN is allowed to use the resource. When B tries to access the resource, the application (or access control infrastructure) would validate B's identity, check with the local authorization system to ensure that B has been granted the appropriate access privileges, and then either grant or deny access.
EPPN looks like a Kerberos identifier (principal@realm). A site might choose to locally implement EPPN as Kerberos principals. However, this is not a requirement. A site can choose to do authentication in any way that is locally acceptable. Over time, many sites are expected to be using PKI for authentication; however, they may still be specifying identity in EPPN format.
Likewise, EPPN should NOT be confused with the user's published email address, although the two values may be the same. Some sites have chosen to make the user portion of email addresses and security principals the same character string; other sites have chosen not to do this. Even when they appear to be the same, they are used in different subsystems and for different purposes, and there is no requirement that they have to remain the same.
The uid attribute of the user's object within the local white pages directory may also contain a login id, a security principal; some systems (eg NDS) may put a login id in the cn attribute. These attributes are defined within objectclasses that are universal. Unfortunately, their use is not prescribed in a sufficiently precise and consistent manner for use with cross domain authorization. A variety of systems already make conflicting use of these attributes; consequently, we have defined this new attribute.
An assumption is that EPPNs are managed on an enterprise basis by the univ of univ.edu. A particular EPPN is assigned solely to the associated user; it is not a security principal identifier shared by more than one person. Lastly, each EPPN is unique within the local security domain.
How long, if ever, before a formerly assigned EPPN is reassigned to a differrent individual is an institutional decision. Some institutions will choose never to reassign EPPNs. Others may opt for a relatively short hiatus before reassignment. While this complicates the work of the relying parties, it is unavoidable given institutional autonomy. See MACE best practice documents on identifiers for further discussion of these issues.
This attribute should prove useful in creating some applications that are based on currently deployed technologies and on code that does not currently use LDAP or require a PKI. This attribute should help to create a framework to foster interesting inter-institutional collaborations between sites that use different technologies. In short, this attribute provides a foundation for yet another abstraction layer.
It is expected that this attribute may become deprecated in some future version of eduPerson. This would occur as LDAP enabled infrastructures and applications become more mature. One metric of this maturity will be the convergence on best practices and their widespread adoption.
controlling access to resources
eduPersonPrincipalName: hputter@hsww.wiz
Syntax: directoryString; Indexing: pres,eq,sub
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.9
NAME 'eduPersonScopedAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Application utility class: standard; # of values: multi
Specifies the person's affiliation within a particular security domain in broad categories such as student, faculty, staff, alum, etc. The values consist of a left and right component separated by an "@" sign. The left component is one of the values from the eduPersonAffiliation controlled vocabulary. The right component identifies the security domain in the form of a dotted string value on the model of DNS domain names. This right-hand side syntax of eduPersonScopedAffiliation intentionally matches that used for the right-hand side values for eduPersonPrincipalName since both identify a security domain.
See controlled vocabulary for eduPersonAffiliation. Only these values are allowed to the left of the "@" sign. The values to the right of the "@" sign should be a dotted string.
Consumers of eduPersonScopedAffiliation will have to decide whether or not they trust values of this attribute. In the general case, the directory carrying the eduPersonScopedAffiliation is not the ultimate authoritative speaker for the truth of the assertion. Trust must be established out of band with respect to exchanges of this attribute value.
An eduPersonScopedAffiliation value of "x@y" is to be interpreted as an assertion that the person in whose entry this value occurs holds an affiliation of type "x" within the security domain "y."
directory of directories, white pages,
controlling access to resources
eduPersonScopedAffiliation: faculty@cs.berkeley.edu
Syntax: directoryString
Application utility class: extended; # of values: multi
A fax number for the directory entry. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567"."
A fax number for the directory entry.
directory of directories, white pages
facsimileTelephoneNumber: +44 71 123 4567
Syntax: telephoneNumber; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
From RFC 2256 description:" The givenName attribute is used to hold the part of a person's name which is not their surname nor middle name."
givenName: Stephen
Syntax: directoryString; Indexing: pres,eq,sub,approx
Application utility class: extended; # of values: multi
From RFC 1274 description: "The [homePhone] attribute type specifies a home telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567".
In RFC 1274, this was originally called homeTelephoneNumber
directory of directories, white pages
homePhone: +1 608 555 1212
Syntax: telephoneNumber; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
From RFC 1274 description: "The Home postal address attribute type specifies a home postal address for an object. This should be limited to up to 6 lines of 30 characters each."
Home address. The organizationalPerson class has a postalAddress that complements this attribute
directory of directories, white pages
homePostalAddress: 1212 Como Ave.$Midton, SD 45621
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single
The fully qualified host name for the system on which the account exists.
This will not be set for departmental aliases that have no local account.
white pages, account management
host: raven.cc.ku.edu
or
host: home.ku.edu
Syntax: directoryString
Application utility class: extended; # of values: multi
From RFC 2256 description: "The initials attribute contains the initials of some or all of an individuals names, but not the surname(s)."
initials: f x
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single
Specifies any comments to account administrators about this account. Usually the stated purpose for the account.
In general, this value is only used by Systems Access and is only visible to anyone during the annual account renewal cycle.
white pages?, account administration
kuComment: Get email about graduate admissions
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the campus mail address (usually) of the person who requested the account.
white pages, account administration
kuAccountContactAddress: 208 COMP $ CAMPUS 66045
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the name of the person who requested the account.
white pages, account administration
kuAccountContactName: Parnassus Q Vanderfeller III
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the telephone number of the person who requested the account.
white pages, account administration
kuAccountContactPhone: +1 785 864 1234
Syntax: telephoneNumber
Application utility class: standard; # of values: single
Specifies the sub-department that owns this account. This is a number used by Academic Computing to manage account ownership within a department.
All departments contain at least one sub-department, which is used to own accounts that aren’t owned by any specific sub-department.
white pages, account administration
kuAccountSubDepartment: 1540006
Syntax: directoryString
Application utility class: standard; # of values: single
Follow inetOrgPerson definition of RFC 1274: "The [uid] attribute type specifies a computer system login name."
The username for this object if it has one. This is used to represent the username for all accounts, not just those that can authenticate.
This is distinct from the uid attribute in that the uid attribute can be used for authentication, but this is only for information and management.
white pages, account management
kuAccountUid: gmettes
Syntax: directoryString; Indexing: pres,eq
Application utility class: standard; # of values: multi
Specifies the non-hidden Lawrence/Edwards email- and web-forwarding aliases that the object owns as well as their respective destination email addresses.
These are simply the alias names without any “@ku.edu” or “@ukans.edu” appended, followed by one or more spaces, followed by the destination email address, optionally followed by one or more spaces, followed by a descriptive label. An object may have up to three aliases and they may be hidden from the address book (see kuAliasHidden, below).
white pages, controlling access to resources
kuAlias: hpotter hpotter@mail.hsww.wiz e-mail
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the hidden Lawrence/Edwards email- and web-forwarding aliases that the object owns, as well as their respective destination addresses.
These are simply the alias names without any “@ku.edu” or “@ukans.edu” appended, followed by one or more spaces, followed by the destination email address, optionally followed by one or more spaces, followed by a descriptive label. An object may have up to three aliases and they may be hidden from the address book (see kuAlias, above).
controlling access to resources
kuAliasHidden: harryp hpotter@mail.hsww.wiz hidden e-mail
Syntax: directoryString
Application utility class: standard; # of values: single, required
Specifies the object’s ID in the AIMS database. For any directory references via the relational database, this attribute is called entry_id instead of kuEntryId.
The entry ID is an integer sequence number and is intended to be unique for each person or departmental account. It is not guaranteed to be unchanging. Sometimes, a person will be entered twice, once as a student and once as staff with no common IDs that can be used to merge the two entries into one. Such a person will have two objects, each with its own entry ID. If at some point a common ID is entered, the two entries will be merged into one, and one of the entry IDs, usually the more recent of the two, will be discarded.
The entry ID is an integer sequence number. It carries no information other than to link objects in the directory to objects in the AIMS database. It can grow up to 12 digits in size and began at 1. It is not zero padded.
controlling access to resources, linking back to the AIMS database for updates
kuEntryId: 154265
Syntax: directoryString; Indexing: pres,eq
Application utility class: standard; # of values: single, required
Specifies the type of object represented.
person, list, organization, account.
This indicates whether the object represents information for a person, a mailing list, an organizational alias, or a departmental account.
white pages, access to resources
kuObjectType: person
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the person’s relationship(s) to the institution in fine-grained categaries, such as UnclassifiedProfessionalStaff, KumcStaff, PreEnrolledStudent, etc. (See controlled vocabulary)
AdjunctFaculty, AffiliatedCorporation, Classified, CourtesyFaculty, Emeritus, Faculty, GraduateResearchAssistant, GraduateTeachingAssistant, KumcStaff, OtherStaff, ReligiousAdvisors, Retiree, StudentStaff, UnclassifiedAcademicStaff, UnclassifiedProfessionalStaff, UnknownStaff, VisitingScholars, AdmittedStudent, EnrollingStudent, KuceStudent, OrientationStudent, PreEnrolledStudent, Student, OldAdjunctFaculty, OldAffiliatedCorporation, OldClassified, OldCourtesyFaculty, OldEmeritus, OldFaculty, OldGraduateResearchAssistant, OldGraduateTeachingAssistant, OldKumcStaff, OldOtherStaff, OldReligiousAdvisors, OldRetiree, OldStudentStaff, OldUnclassifiedAcademicStaff, OldUnclassifiedProfessionalStaff, OldUnknownStaff, OldVisitingScholars, OldKuceStudent, OldStudent
If there is a value in kuPersonPrimaryAffiliation, that value should be stored here as well.
The staff positions are taken from translations of the HRSA empl_class codes and only apply to Lawrence/Edwards people. We are not receiving this field from KUMC. “UnknownStaff” indicates that the empl_class field is not a known value. “KumcStaff” indicates that they are active in KUMC’s HR system. They may be faculty at KUMC, but we won’t know.
Student staff positions have been separated into “StudentStaff,” “GraduateResearchAssistant,” and “GraduateTeachingAssistant.” It is possible for a person to have “StudentStaff,” but not “Student,” if they are coded as a “student” employee, but are not actually enrolled. This happens occasionally when a department hires a student from another institution as a part-time hourly employee.
“Student” indicates that the person is enrolled in a current semester, defined as the current semester except during June and July, when the fall semester is also considered current. A student will only have one of the following values if they do not also have “Student”. “KuceStudent” indicates that the student is enrolled in a course through KU Continuing Education. “EnrollingStudent” indicates that the student has a permit to enroll for the coming semester, but has not yet enrolled. “PreEnrolledStudent” indicates that the student has pre-enrolled for a future semester. “OrientationStudent” indicates that the student is signed up for New Student Orientation, but has not yet enrolled.
The values beginning with the word “Old” are only included if the person has no current affiliation, in which case all their old affiliations still in the source database (AIMS) will be included. The only reason a person in this category is included in the directory is that they have a valid uid, and thus could potentially access some online services, e.g. grades or fee payment.
We have avoided including values such as “other” or “misc”, because it would be semantically equivalent to “none of the above.” To indicate “none of the above” for a specific person, leave the attribute empty.
The values are a set of names culled from the empl_class values in Peoplesoft HR, from different student categories, and from our other two data sources (KUMC HR, and Continuing Education (KUCE)).
controlling access to resources
kuPersonAffiliation: GraduateTeachingAssistant
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the person’s birthdate.
Values are currently of the form MMDDYY.
The main reason this information is included is for controlling access to the page for initially getting a uid. It’s quite possible that that page will be accessing the data from a more direct source than LDAP and this attribute may not be needed.
However, there is a mailing list (NONTRAD_DL) which selects its members based partly on whether their age is out of line with their student level. It is thus conceivable that some organization at KU might want to use this value for authorization purposes.
Controlling access to resources
kuPersonBirthdate: 073186
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the building codes for the Lawrence/Edwards positions to which the person has staff appointments.
These are taken from the position data from Peoplesoft HR. If these were maintained in KUMC HR we would incorporate their buildings as well.
controlling access to resources
kuPersonBuildingCode: ST
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the person’s preferred name in a standard, easily parsed form.
We use the preferred name from HR if present. Otherwise, we use whatever name is available.
The format of the name is similar to the HR Peoplesoft format but not identical. The suffix, if present, is moved to the end of the name with a comma separating it from the rest of the name.
white pages, web page greetings
kuPersonCanonicalName: Vanderfeller,Parnassus Q,III
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single
Specifies the person’s 16-digit Lawrence/Edwards KU Card ISO number. This number may change if a card is replaced for any reason.
We don’t store numbers for inactive cards. We assume that a person only has one card. For those rare cases where a person has more than one card, one of the values will be discarded. Which one is not specified in this document.
controlling access to resources
kuPersonCardIsoNumber: 1234567890123456
Syntax: directoryString; Indexing: pres,eq
Application utility class: standard; # of values: multi
Specifies the jobcode values for the positions to which the person has staff appointments.
These are taken from the job table information in the Lawrence/Edwards HR and the KUMC HR extracts.
controlling access to resources
kuPersonJobcode: 010600
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the person’s postal address from the Continuing Education data extract.
This data is provided as a way for a web-based Continuing Education application to send mail to the address given to Continuing Education by the student.
This attribute is pretty much as is from the Continuing Education database.
restricted Continuing Ed white pages, Continuing Ed mailings or data updates
kuPersonKuceAddress: 1234 Shady Lane $ Lawrence, KS 66044
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the client ID from the KU Continuing Education database.
This is the primary key in the Continuing Ed database.
This may be an historical value, that is to say, the person may have been enrolled in Continuing Ed at one time, but no longer. We will still remember their client ID. Perhaps we shouldn’t for the LDAP directory?
This field is composed of the first four letters of the person’s last name followed by a sequence number of some sort. We choose not to interpret this attribute, but to use it as a unit.
controlling access to resources
kuPersonKuceId: ANTM23073
Syntax: directoryString; Indexing: pres,eq
Application utility class: standard; # of values: single
Specifies the person’s telephone number from the Continuing Education data extract. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567".
This data is provided as a way for a web-based Continuing Education application to call a person at the phone number given to Continuing Education by the student.
This attribute is pretty much as is from the Continuing Education database, but massaged into an international form.
restricted Continuing Ed white pages, Continuing Ed contacts or data updates
kuPersonKucePhone: +1 785 843 1234
Syntax: telephoneNumber
Application utility class: standard; # of values: single
Specifies the person’s Lawrence/Edwards employee ID in Peoplesoft HR.
This may be an historical value, that is to say, the person may have been employed at one time, but no longer. We will still remember their employee ID. Perhaps we shouldn’t for the LDAP directory?
controlling access to resources
kuPersonLHrId: 1234567
Syntax: directoryString; Indexing: pres,eq
Application utility class: standard; # of values: single
Specifies the person’s email address on the Lawrence/Edwards campus. Follow inetOrgPerson definition of RFC 1274: "The [mail] attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822. Note that this attribute should not be used for greybook or other non-Internet order mailboxes."
Preferred address for the "to:" field of email to be sent to this person on the Lawrence/Edwards campus. Nowadays usually of the form localid@ku.edu.
Preferred address for the "to:" field of email to be sent to this person on the Lawrence/Edwards campus. Usually a copy of the “mail” attribute.
directory of directories, white pages, email client
kuPersonLMail: jrandom@ku.edu
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Specifies the sub-object dn values of object class kuOrganizationalRole for the person’s appointments on the Lawrence/Edwards campuses.
With a distinguished name, the client can do an efficient lookup in the institution's directory for information about the person's staff appointments on the Lawrence, Edwards, and KUMC campuses.
The kuOrganizationalRole object class is defined below. The DN is of the form:
kuRoleIndex= roleIndex, kuEntryId=entryID, ou=People, dc=ku, dc=edu
The sub-object groups together related attributes associated with the position, such as title, department, jobcode, address, and telephone number. The role index provides a way to sort a person’s roles in order of importance. It is a simple integer, starting with zero.
Refers to a sub-object of object class kuOrganizationalRole.
white pages, controlling access to resources
kuPersonLRole: kuRoleIndex=0, kuEntryId=154265, ou=People, dc=ku, dc=edu
Syntax: distinguishedName
Application utility class: standard; # of values: single
Specifies the state employee ID from the KUMC HR extract.
This may be an historical value, that is to say, the person may have been employed at one time, but no longer. We will still remember their employee ID. Perhaps we shouldn’t for the LDAP directory?
controlling access to resources
kuPersonMHrId: J0000000001
Syntax: directoryString; Indexing: pres,eq
Application utility class: standard; # of values: single
Specifies the person’s email address on the KUMC campus. Follow inetOrgPerson definition of RFC 1274: "The [mail] attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822. Note that this attribute should not be used for greybook or other non-Internet order mailboxes."
Preferred address for the "to:" field of email to be sent to this person on the KUMC campus. Nowadays usually of the form localid@kumc.edu.
Preferred address for the "to:" field of email to be sent to this person on the KUMC campus if different from the “mail” attribute.
directory of directories, white pages, email client
kuPersonMMail: jrandom@kumc.edu
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Specifies the sub-object dn values of object class kuOrganizationalRole for the person’s appointments on the KUMC campus.
With a distinguished name, the client can do an efficient lookup in the institution's directory for information about the person's staff appointments on the KUMC campus.
The kuOrganizationalRole object class is defined below. The DN is of the form:
kuRoleIndex= roleIndex, kuEntryId=entryID, ou=People, dc=ku, dc=edu
The sub-object groups together related attributes associated with the position, such as title, department, jobcode, address, and telephone number. The role index provides a way to sort a person’s roles in order of importance. It is a simple integer, starting with zero.
Refers to a sub-object of object class kuOrganizationalRole.
white pages, controlling access to resources
kuPersonMRole: kuRoleIndex=0, kuEntryId=154265, ou=People, dc=ku, dc=edu
Syntax: distinguishedName
Application utility class: standard; # of values: multi
Specifies the position number values for the positions to which the person has staff appointments.
These are taken from the job table information in the Lawrence/Edwards HR extract. We are not currently receiving this information from KUMC.
controlling access to resources
kuPersonPositionNumber: 00000320
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the person’s PRIMARY relationship to the institution in fine-grained categaries, such as UnclassifiedProfessionalStaff, KumcStaff, PreEnrolledStudent, etc. (See controlled vocabulary)
Same as kuPersonAffiliation.
Appropriate if the person carries at least one of the defined kuPersonAffiliations. The choices of values are the same as for that attribute.
Think of this as the affiliation one might put on the name tag if this person were to attend a general institutional social gathering. Note that the single-valued kuPersonPrimaryAffiliation attribute assigns each person in the directory into one and only one category of affiliation. There are application scenarios where this would be useful.
See the description of kuPersonAffiliation for more details about the interpretations of the field values.
The values are a set of names culled from the empl_class values in Peoplesoft HR, from different student categories, and from our other two data sources (KUMC HR, and Continuing Education (KUCE)).
white pages, controlling access to resources
kuPersonPrimaryAffiliation: GraduateTeachingAssistant
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the primary department name to which the person has a staff appointment. The ou field contains all the department names to which the person has staff appointments.
This is taken from the translated department names from the Lawrence/Edwards HR and the KUMC HR extracts.
white pages, controlling access to resources
kuPersonPrimaryDepartment: Physics and Astronomy
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the person’s PRIMARY home postal address.
This data is provided as a way for a web-based application to send mail to the person’s home address.
If the student has a type 1 address (SRIS terminology) then that is used, otherwise, we look for a Continuing Ed address. We could use staff home addresses, but those are not available in the Lawrence/Edwards HR or KUMC HR extracts.
home mailings or data updates
kuPersonPrimaryHomeAddress: 1234 Shady Lane $ Lawrence, KS 66044
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the person’s PRIMARY home telephone number. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567".
This data is provided as a way for a web-based application to display a person’s home phone.
This attribute is pretty much as is from SRIS or from Continuing Education database, but massaged into an international form.
restricted lookups for contacts or data updates
kuPersonPrimaryHomePhone: +1 785 843 1234
Syntax: telephoneNumber
Application utility class: standard; # of values: single
Specifies the sub-object dn values of object class kuOrganizationalRole for the person’s primary appointment on the Lawrence/Edwards campuses.
With a distinguished name, the client can do an efficient lookup in the institution's directory for information about the person's staff appointments on the Lawrence and Edwards campuses.
The kuOrganizationalRole object class is defined below. The DN is of the form:
kuRoleIndex= roleIndex, kuEntryId=entryID, ou=People, dc=ku, dc=edu
The sub-object groups together related attributes associated with the position, such as title, department, jobcode, address, and telephone number. The role index provides a way to sort a person’s roles in order of importance. It is a simple integer, starting with zero.
Refers to a sub-object of object class kuOrganizationalRole.
white pages, controlling access to resources
kuPersonPrimaryLRole: kuRoleIndex=0, kuEntryId=154265, ou=People, dc=ku, dc=edu
Syntax: distinguishedName
Application utility class: standard; # of values: single
Specifies the sub-object dn values of object class kuOrganizationalRole for the person’s primary appointment on the KUMC campus.
With a distinguished name, the client can do an efficient lookup in the institution's directory for information about the person's staff appointments on the KUMC campus.
The kuOrganizationalRole object class is defined below. The DN is of the form:
kuRoleIndex= roleIndex, kuEntryId=entryID, ou=People, dc=ku, dc=edu
The sub-object groups together related attributes associated with the position, such as title, department, jobcode, address, and telephone number. The role index provides a way to sort a person’s roles in order of importance. It is a simple integer, starting with zero.
Refers to a sub-object of object class kuOrganizationalRole.
white pages, controlling access to resources
kuPersonPrimaryMRole: kuRoleIndex=0, kuEntryId=154265, ou=People, dc=ku, dc=edu
Syntax: distinguishedName
Application utility class: standard; # of values: single
Specifies the person’s PRIMARY office postal address.
This data is provided as a way for a web-based application to send mail to the person’s office address.
Unfortunately, the Lawrence/Edwards HR database does not populate the room number, so we don’t in fact have a full address. It would be nice to have this information.
This is currently created from the Lawrence/Edwards HR extract cross-referencing the building code with a list of postal addresses obtained from Printing Services. For KUMC addresses, the main KUMC address is given. Ditto for Wichita addresses.
white pages
kuPersonPrimaryOfficeAddress: Strong Hall, room 230 $ 1450 Jayhawk Blvd $ Lawrence, KS 66045-7535
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the person’s PRIMARY office telephone number. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567".
This data is provided as a way for a web-based application to display a person’s office phone.
This attribute is pretty much as is from the Lawrence/Edwards HR extract, but massaged into an international form.
white pages
kuPersonPrimaryOfficePhone: +1 785 864 1234
Syntax: telephoneNumber
Application utility class: standard; # of values: multi
Specifies the student’s academic groups, if any.
AHLTH, ARCH, BUS, CLAS, EDUC, ENGR, FINEA, GRAD, JOUR, LAW, MED, NURS, OURU, PHARM, SOCW
This address is taken from the major codes in the STD11 SRIS segment and modified into Peoplesoft format.
The values are the possible Peoplesoft academic groups.
controlling access to resources, special mailing selections
kuPersonStuAcademicGroup: CLAS
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the home postal address for a student.
This address is taken from the type 1 (SRIS terminology) address for a student.
home mailings or data updates
kuPersonStuCampusAddress: 1234 Shady Lane $ Lawrence, KS 66044
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the person’s old-style student ID from the student extract, or from the Lawrence/Edwards HR extract if present.
This may be an historical value, that is to say, the person may have been enrolled at one time, but no longer. We will still remember their student ID. Perhaps we shouldn’t for the LDAP directory?
controlling access to resources
kuPersonStuCampusId: 123456
Syntax: directoryString; Indexing: pres,eq
Application utility class: standard; # of values: single
Specifies the person’s home telephone number from the student extract. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567".
This data is provided as a way for a web-based application to display a student’s home phone.
This attribute is pretty much as is from SRIS type 1.
restricted lookups for contacts or data updates
kuPersonStuCampusPhone: +1 785 843 1234
Syntax: telephoneNumber
Application utility class: standard; # of values: multi
Specifies the student’s academic career, if any.
GRDK, GRDL, LAW, MED, SOCW, UGDK, UGDL
This address is taken from the STD11 SRIS segment and modified into Peoplesoft format.
The values are the possible Peoplesoft academic careers.
controlling access to resources, special mailing selections
kuPersonStuCareer: UGDL
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the status of the student’s application for a degree.
AG, AP, AW, DN, IR, PN
This address is taken from the STD11 SRIS segment and massaged into Peoplesoft format. The only value that will actually appear is AG.
If the value is “AG” then the student has applied for a degree. If the value is null then the student has not applied for a degree. Any other value is ignored at this time. Once the data is coming from Peoplesoft, there will be the additional values “AP”, meaning that the application was approved, “AW”, meaning that the application was awarded, “DN”, meaning that the application was denied, “IR”, meaning that the program is in review, and “PN”, meaning that the student needs to finish pending work.
controlling access to resources, special mailing selections
kuPersonStuDegreeCheckoutStatus: AG
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the course sections that the student is enrolled in.
This is formatted like a distinguished name, but there is no associated object. The main purpose for this is to enable the client to efficiently look up the person's courses.
The data in this field is of the form:
courseNumber=courseNumber, catalogNumber=catalogNumber, subject=subject, term=term
This field provides a way to group the course information for the courses that students are enrolled in. It contains such things as (using SRIS terminology) year term, line number, sub department, and course number, or (using the new Peoplesoft SA terminology) term, course number, subject, and course catalog number. There will be one value for each section of each course the person is enrolled in, generally including the previous semester, the current semester, and any semesters for which the person has pre-enrolled.
Looks like a DN, but is not. It probably should be a DN.
controlling access to resources
kuPersonStuEnrolled: courseNumber=45907, catalogNumber=111, subject=PHSX, term=4022
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the campuses at which the student is enrolled in courses.
Lawrence, KUMC
This address is taken from the STD310 SRIS segment. We use the line number ranges to determine the type of course. For Peoplesoft SA we will use other means to determine the campus.
What we’re really after here isn’t so much the campus, though that is probably useful, but whether a student is enrolled only in KUMC courses or whether they are enrolled in Lawrence/Edwards courses. We are currently using this information to determine eligibility for Exchange mailboxes and other online services. Quite likely we should be using other means, but if a student is enrolled in Lawrence/Edwards courses they may need an Exchange account to see a course public folder even though they are primarily a KUMC student.
controlling access to resources, special mailing selections
kuPersonStuEnrolledCampus: Lawrence
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the course sections that the student was enrolled in but has dropped or withdrawn.
This is formatted like a distinguished name, but there is no associated object. The main purpose for this is to enable the client to efficiently look up the person's dropped courses.
The data in this field is of the form:
courseNumber=courseNumber, catalogNumber=catalogNumber, subject=subject, term=term
This field provides a way to group the course information for the courses that students are enrolled in. It contains such things as (using SRIS terminology) year term, line number, sub department, and course number, or (using the new Peoplesoft SA terminology) term, course number, subject, and course catalog number. There will be one value for each section of each course the person is enrolled in, generally including the previous semester, the current semester, and any semesters for which the person has pre-enrolled.
Currently, we use this in the course roster program. If Peoplesoft SA provides good functionality for this, we may obsolete this attribute, although given the looseness of course structures at KU, we may still need it for web-based authorization.
Looks like a DN, but is not. It probably should be a DN.
controlling access to resources
kuPersonStuEnrolledInactive: courseNumber=45907, catalogNumber=111, subject=PHSX, term=4022
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies whether the person’s FERPA-related attributes are to be hidden from non-administrative queries.
Y
This attribute is used to indicate that a student has opted out of having their directory information listed. It does not actually cause the attributes to be hidden; they must be specified as values in kuPrivateAttribute. If a person is permanent staff as well as a student, their staff-related attributes are not hidden. This attribute is provided to indicate to an application why some attributes are hidden.
Any value means that the FERPA-related attributes are hidden.
white pages, controlling access to resources
kuPersonStuHideFERPA: Y
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the home postal address for a student.
This address is taken from the type 1 (SRIS terminology) address for a student.
home mailings or data updates
kuPersonStuHomeAddress: 1234 Shady Lane $ Lawrence, KS 66044
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the person’s home telephone number from the student extract. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567".
This data is provided as a way for a web-based application to display a student’s home phone.
This attribute is pretty much as is from SRIS type 1.
restricted lookups for contacts or data updates
kuPersonStuHomePhone: +1 785 843 1234
Syntax: telephoneNumber
Application utility class: standard; # of values: single
Specifies the person’s new-style student ID from the student extract.
This may be an historical value, that is to say, the person may have been enrolled at one time, but no longer. We will still remember their student ID. Perhaps we shouldn’t for the LDAP directory?
controlling access to resources
kuPersonStuId: 12345678
Syntax: directoryString; Indexing: pres,eq
Application utility class: standard; # of values: single
Specifies the level for the student.
10, 20, 30, 40, 40, 10, GR, 00, P1, MD, 20, 30, 40, 45, GR, P2, P3, 40, 40, 30, 45, P1
This data is taken from the STD11 SRIS segment and massaged into Peoplesoft format.
The values are the possible student levels.
controlling access to resources, special mailing selections
kuPersonStuLevel: 30
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies whether the student is married.
C, D, E, H, M, S, U, W
This address is taken from the STD11 SRIS segment and is self-reported.
The values are the values for the SRIS marital status field and is massaged into Peoplesoft format. The only use for this field currently is the NONTRAD_DL mailing list, which uses age and marital status to select students who may be non-traditional. It’s quite possible that the selection should be done externally to the directory, in which case we don’t need this field.
controlling access to resources, special mailing selections
kuPersonStuMaritalStatus: S
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the student’s academic plan, if any.
Too many to list, but of the form: ENGLA-BA, ENGLA-BGS, ENGLGA-MA, ENGLGA-MAT, ENGLGA-MP, ENGLGA-PHD
This address is taken from the STD11 SRIS segment and modified into Peoplesoft format.
The values are the possible Peoplesoft academic plans.
controlling access to resources, special mailing selections
kuPersonStuPlan: MUSGF-PHD
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the student’s primary academic group, if any.
AHLTH, ARCH, BUS, CLAS, EDUC, ENGR, FINEA, GRAD, JOUR, LAW, MED, NURS, OURU, PHARM, SOCW
This address is taken from the STD11 SRIS segment and modified into Peoplesoft format.
The values are the possible Peoplesoft academic groups.
controlling access to resources, special mailing selections
kuPersonStuPrimaryAcademicGroup: CLAS
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the student’s primary academic career, if any.
GRDK, GRDL, LAW, MED, SOCW, UGDK, UGDL
This address is taken from the STD11 SRIS segment and modified into Peoplesoft format.
The values are the possible Peoplesoft academic careers.
controlling access to resources, special mailing selections
kuPersonStuPrimaryCareer: UGDL
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the student’s primary academic plan, if any.
Too many to list, but of the form: ENGLA-BA, ENGLA-BGS, ENGLGA-MA, ENGLGA-MAT, ENGLGA-MP, ENGLGA-PHD
This address is taken from the STD11 SRIS segment and modified into Peoplesoft format.
The values are the possible Peoplesoft academic plans.
controlling access to resources, special mailing selections
kuPersonStuPrimaryPlan: MUSGF-PHD
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the student’s primary academic program, if any.
AHLTG, AHLTU, ARCHG, ARCHU, ARENG, ARENU, BUSG, BUSU, CLASG, CLASU, EDUCG, EDUCU, ENGRG, ENGRU, FINEG, FINEU, JOURG, JOURU, LAWP, MEDG, MEDP, MEDU, NADMG, NURSG, NURSU, OURU, PHARG, PHARP, PHARU, SOCWG, SOCWH, SOCWU, TRANG, TRANL, TRANM, TRANS, TRANU
This address is taken from the STD11 SRIS segment and modified into Peoplesoft format.
The values are the possible Peoplesoft academic programs.
controlling access to resources, special mailing selections
kuPersonStuPrimaryProgram: CLASU
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the student’s primary academic subplan, if any.
Too many to list, but of the form: CELL BIOL, ORGAN BIOL, SYST&ECOL, GENETICS, MUSIC ED, PHYSICAL E, PHYS EDC, SCHOOL ADM, SCHL PSYCH, SPEC EDC, VISUAL ART
This address is taken from the STD11 SRIS segment and modified into Peoplesoft format. In general, most people won’t have a value here. Most plans don’t have subplans.
The values are the possible Peoplesoft academic subplans.
controlling access to resources, special mailing selections
kuPersonStuPrimarySubPlan: MUSIC ED
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the student’s academic program, if any.
AHLTG, AHLTU, ARCHG, ARCHU, ARENG, ARENU, BUSG, BUSU, CLASG, CLASU, EDUCG, EDUCU, ENGRG, ENGRU, FINEG, FINEU, JOURG, JOURU, LAWP, MEDG, MEDP, MEDU, NADMG, NURSG, NURSU, OURU, PHARG, PHARP, PHARU, SOCWG, SOCWH, SOCWU, TRANG, TRANL, TRANM, TRANS, TRANU
This address is taken from the STD11 SRIS segment and modified into Peoplesoft format.
The values are the possible Peoplesoft academic programs.
controlling access to resources, special mailing selections
kuPersonStuProgram: CLASU
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the student’s academic subplan, if any.
Too many to list, but of the form: CELL BIOL, ORGAN BIOL, SYST&ECOL, GENETICS, MUSIC ED, PHYSICAL E, PHYS EDC, SCHOOL ADM, SCHL PSYCH, SPEC EDC, VISUAL ART
This address is taken from the STD11 SRIS segment and modified into Peoplesoft format. In general, most people won’t have a value here. Most plans don’t have subplans.
The values are the possible Peoplesoft academic subplans.
controlling access to resources, special mailing selections
kuPersonStuSubPlan: MUSIC ED
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the semesters/terms in which the student is enrolled in courses.
This address is taken from the STD310 SRIS segment. We massage the year term into a Peoplesoft SA format.
This value is a four digit number of which the first digit is a century value (3 = 1900, 4 = 2000), the next two are the last two digits of the year, and the final digit is a semester designator (2 = spring, 6 = summer, 9 = fall).
controlling access to resources, special mailing selections
kuPersonStuTerm: 4029
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the course sections that the instructor is teaching.
This is formatted like a distinguished name, but there is no associated object. The main purpose for this is to enable the client to efficiently look up the person's courses.
The data in this field is of the form:
courseNumber=courseNumber, catalogNumber=catalogNumber, subject=subject, term=term
This field provides a way to group the course information for the courses that students are enrolled in. It contains such things as (using SRIS terminology) year term, line number, sub department, and course number, or (using the new Peoplesoft SA terminology) term, course number, subject, and course catalog number. There will be one value for each section of each course the person is enrolled in, generally including the previous semester, the current semester, and any semesters for which the person has pre-enrolled.
Looks like a DN, but is not. It probably should be a DN.
controlling access to resources
kuPersonTeaches: courseNumber=45907, catalogNumber=111, subject=PHSX, term=4022
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies attribute names that are to be hidden from non-administrative queries.
Any attribute value except kuPrivateAttribute. It only applies to attributes that are normally visible to the public, making them private.
This is used by the ACLs to control access to various attributes belonging to an object.
white pages, making only certain fields accessible to web-based applications
kuPrivateAttribute: homeAddress
kuPrivateAttribute: homePhone
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the password to be passed to the Smartforce web page login. This is part of the kuSmartforce object class definition.
These are generated randomly for each user. They are obsoleted if a uid changes owners before a new extract is sent to Smartforce.
controlling access to Smartforce resources
kuSmartforcePassword: tetaNJECRE2323Ejoq
Syntax: directoryString
Application utility class: extended; # of values: multi
locality name.
According to RFC 2256, "This attribute contains the name of a locality, such as a city, county or other geographic region (localityName".
X.520(2000) reads: "The Locality Name attribute type specifies a locality. When used as a component of a directory name, it identifies a geographical area or locality in which the named object is physically located or with which it is associated in some other important way.
directory of directories, white pages
l: Hudson Valley
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
Follow inetOrgPerson definition of RFC 2079: "Uniform Resource Identifier with optional label."
Commonly a URL for a web site associated with this person. Good candidate for a self-maintained attribute. Note, however, that the vocabulary for the label portion of the value is not standardized.
Note from RFC 2079: "The labeledURI attribute type has the caseExactString syntax (since URIs are case-sensitive) and it is multivalued. Values placed in the attribute should consist of a URI (at the present time, a URL) optionally followed by one or more space characters and a label. Since space characters are not allowed to appear un-encoded in URIs, there is no ambiguity about where the label begins. At the present time, the URI portion must comply with the URL specification.
Multiple labeledURI values will generally indicate different resources that are all related to the X.500 object, but may indicate different locations for the same resource.
The label is used to describe the resource to which the URI points, and is intended as a friendly name fit for human consumption. This
document does not propose any specific syntax for the label part. In some cases it may be helpful to include in the label some indication
of the kind and/or size of the resource referenced by the URI.
Note that the label may include any characters allowed by the caseExactString syntax, but that the use of non-IA5 (non-ASCII) characters is discouraged as not all directory clients may handle them in the same manner. If non-IA5 characters are included, they should be represented using the X.500 conventions, not the HTML conventions (e.g., the character that is an "a" with a ring above it should be encoded using the T.61 sequence 0xCA followed by an "a" character; do not use the HTML escape sequence "å").
Examples of labeledURI Attribute Values
An example of a labeledURI attribute value that does not include a label:
ftp://ds.internic.net/rfc/rfc822.txt
An example of a labeledURI attribute value that contains a tilde character in the URL (special characters in a URL must be encoded as specified by the URL document [1]). The label is "LDAP Home Page":
http://www.umich.edu/%7Ersug/ldap/ LDAP Home Page
Another example. This one includes a hint in the label to help the user realize that the URL points to a photo image.
http://champagne.inria.fr/Unites/rennes.gif Rennes [photo]"
Most commonly a URL for a web site associated with this person
directory of directories, white pages
labeledURI: http://www.hsww.wiz/%7Eputter Harry's home page
Syntax: caseExactString; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Follow inetOrgPerson definition of RFC 1274: "The [mail] attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822. Note that this attribute should not be used for greybook or other non-Internet order mailboxes."
Preferred address for the "to:" field of email to be sent to this person. nowadays usually of the form localid@univ.edu. Likely only one value.
Some mail cllents will not display entries unless the mail attribute is populated. See the LDAP Recipe for further guidance on email addresses, routing, etc. http://www.georgetown.edu/giia/internet2/ldap-recipe/
Note: RFC 1274 uses the longer name 'rfc822Mailbox' and syntax OID of 0.9.2342.19200300.100.3.5. All recent LDAP documents and most deployed LDAP implementations refer to this attribute as 'mail' and define the IA5 String (ASCII string) syntax using using the OID 1.3.6.1.4.1.1466.115.121.1.26, as is done here.
Preferred address for the "to:" field of email to be sent to this person
directory of directories, white pages, email client
mail: dumbledore@hsww.wiz
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: no recommendation; # of values: multi
Follow inetOrgPerson definition which refers to RFC 1274: "The manager attribute type specifies the manager of an object represented by an entry." The value is a DN.
This attribute carries the DN of the manager of the person represented in this entry.
directory of directories, white pages
manager: uid=twilliams, ou=people, dc=hobart dc=edu
Syntax: distinguishedName; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
Follow inetOrgPerson definition of RFC 1274: "The [mobile] attribute type specifies a mobile telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567"."
cellular or mobile phone number
RFC 1274 uses the longer name 'mobileTelephoneNumber'.
cellular or mobile phone number
directory of directories, white pages
mobile: +47 22 44 66 88
Syntax: telephoneNumber; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Standard name of the top-level organization (institution) with which this person is associated.
Likely only one value.
Meant to carry the TOP-LEVEL organization name. Do not use this attribute to carry school college names.
directory of directories, white pages
o: St. Cloud State
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Specifies the department names to which the person has staff appointments.
These are taken from the translated department names from Lawrence/Edwards HR and from KUMC HR.
directory of directories, white pages, controlling access to resources
ou: Physics and Astronomy
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single
Identifies the distinguished name of the ou=authaccount object corresponding to this entry.
controlling access to resources
owner: uid=hputter, ou=authaccounts, dc=ku, dc=edu
Syntax: distinguishedName
Application utility class: extended; # of values: multi
Follow inetOrgPerson definition of RFC 1274: "The [pager] attribute type specifies a pager telephone number for an object. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567"."
RFC 1274 uses the longer name 'pagerTelephoneNumber'.
pager number
directory of directories, white pages
pager: +1 202 555 4321
Syntax: telephoneNumber; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
Campus or office address. inetOrgPerson has a homePostalAddress that complements this attribute. X.520(2000) reads: "The Postal Address attribute type specifies the address information required for the physical postal delivery to an object."
Campus or office address. inetOrgPerson has a homePostalAddress that complements this attribute
Campus or office address. X.520(2000) reads: "The Postal Address attribute type specifies the address information required for the physical postal delivery to an object."
directory of directories, white pages
postalAddress: P.O. Box 333$Whoville, WH 99999
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
Follow X.500(2000): "The postal code attribute type specifies the postal code of the named object. If this attribute value is present, it will be part of the object's postal address." Zip code in USA, postal code for other countries.
ZIP code in USA, postal code for other countries.
Zip code in USA, postal code for other countries.
directory of directories, white pages
postalCode: 54321
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
Follow X.500(2000): "The Post Office Box attribute type specifies the Postal Office Box by which the object will receive physical postal delivery. If present, the attribute value is part of the object's postal address."
Follow X.500(2000): "The Post Office Box attribute type specifies the Postal Office Box by which the object will receive physical postal delivery. If present, the attribute value is part of the object's postal address."
directory of directories, white pages
postOfficeBox: 109260
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: single
Follow inetOrgPerson definition of RFC 2798: "preferred written or spoken language for a person'"
See RFC2068 and ISO 639 for allowable values in this field. Esperanto, for example is EO in ISO 639, and
RFC2068 would allow a value of en-US for US English.
directory of directories, white pages
preferredLanguage: EO
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
Specifies the room number of a person’s primary address.
directory of directories, white pages
roomNumber: 230
Syntax: directoryString
Application utility class: no recommendation; # of values: multi
Follow inetOrgPerson definition which refers to RFC 1274: "The secretary attribute type specifies the secretary for an object represented by an entry." The value is a DN.
This attribute carries the DN of the secretary for the person represented in this entry.
directory of directories, white pages
secretary: uid=smcgill, ou=people, dc=hobart dc=edu
Syntax: distinguishedName
Application utility class: standard; # of values: multi
Follow person object class definition: Identifies (by DN) another directory server entry that may contain information related to this entry.
According to X.520(2000), "The See Also attribute type specifies names of other Directory objects which may be other aspects (in some sense) of the same real world object."
The distinguished name of another directory entry
directory of directories, white pages
seeAlso: cn=Department Chair, ou=physics, o=University of Technology, dc=utech, dc=ac, dc=uk
Syntax: distinguishedName; Indexing: pres,eq,sub
Application utility class: core; # of values: multi
Surname or family name. According to RFC 2256, "This is the X.500 surname attribute, which contains the family name of a person."
Required. One of the two required attributes in the person object class from which eduPerson derives (the other is cn). As such it is one of eduPerson's three "core application utility" attributes. The third is eduPersonOrgDN.
If the person has a multi-part surname (whether hyphenated or not), store each component as a separate value in this multi-valued attribute. That yields the best results for the broadest range of clients doing name searches.
all
sn: Carson
Syntax: directoryString; Indexing: pres,eq,sub,approx
Application utility class: extended; # of values: multi
Abbreviation for state name
Format: Standard U.S. postal service two-letter code.
According to RFC 2256, "This attribute contains the full name of a state or province (stateOrProvinceName)."
For states in the United States, U.S. Postal Service set of two-letter state name abbreviations
State or province name. While RFC 2256 specifies use of the "full name," it is customary to use the U.S. Postal Service set of two-letter state name abbreviations for states in the U.S. and, as noted in the definition, other nationally coordinated official abbreviations are preferred for province names.
Standard two-letter abbreviations for U.S. state names, other standards based abbreviations for provinces where available.
directory of directories, white pages
st: IL
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
According to RFC 2256, "This attribute contains the physical address of the object to which the entry corresponds, such as an address for package delivery (streetAddress)."
directory of directories, white pages
street: 303 Mulberry St.
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Office/campus phone number. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567"."
directory of directories, white pages
telephoneNumber: +1 212 555 1234
Syntax: telephoneNumber; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Specifies the PRIMARY title for the person. This is taken from either the Lawrence/Edwards HR extract or from the KUMC HR extract.
Although this standard LDAP attribute is defined as multi-valued, we are only putting the person’s primary title into it.
directory of directories, white pages
title: Chancellor/Professor
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Follow inetOrgPerson definition of RFC 1274: "The [uid] attribute type specifies a computer system login name."
Likely only one value. See the extensive discussion in the "LDAP Recipe" (http://middleware.internet2.edu/dir/rpr-nmi-edit-mace_dirldap_recipe.2.0.html)
A number of off-the-shelf directory-enabled applications make use of this inetOrgPerson attribute, not always consistently.
RFC 1274 uses the longer name 'userid'.
controlling access to resources
uid: gmettes
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
A user's X.509 certificate
RFC 2256 states that this attribute is to be stored and requested in the binary form, as 'userCertificate;binary'.
Note that userSMIMECertificate is in binary syntax (1.3.6.1.4.1.1466.115.121.1.5) whereas the userCertificate attribute is in certificate syntax (1.3.6.1.4.1.1466.115.121.1.8).
email clients, controlling access to resources
Syntax: binary
Application utility class: extended; # of values: multi
This attribute identifies the entry’s password and encryption method in the following format:
{encryption method}encrypted password.
The user pw is hidden, and is used in the bind operation in LDAP. The bind operation must be done over SSL to avoid sending clear text passwords over the wire or through the air.
controlling access to resources
userPassword: {ssha}9LsFG7RT+dFnPErwSfxDlaQTn6dbIFGklMNFRr==
Syntax: binary
Application utility class: extended; # of values: multi
An X.509 certificate specifically for use in S/MIME applications (see RFCs 2632, 2633 and 2634)..
An X.509 certificate specifically for use in S/MIME applications. According to RFC 2798, "If available, this attribute is preferred over the userCertificate attribute for S/MIME applications."
RFC 2256 states that this attribute is to be stored and requested in the binary form, as 'userCertificate;binary'.
Following userSMIMECertificate in RFC 2798, "A PKCS#7 [RFC2315] SignedData"
email clients
Syntax: binary
Objects in the kuOrganizationalRole class currently correspond to staff positions on the KU campuses. There is one object for each position in the HR systems for the Lawrence/Edwards and KUMC campuses. It extends the organizationalRole class. Any object containing kuOrganizationalRole will also contain organizationalRole.
The main function of this class is to group related attributes, such as department, title, address, and telephone number for white pages display. You would need this for authorization if you need to correlate a person’s jobcode, for instance, with a particular deptno, for instance, it’s not good enough that they be both a GTA and have a position in the English department, but they must be a GTA in the English department.
The entry ID is the kuEntryId value corresponding to the person holding the position. The role index is an integer value designating the “rank” of this position among the person’s positions. It begins at zero and higher numbers are lower rank, thus position 0 is the person’s primary position, 1 is their next position, etc.
As can be seen from the format of the distinguished name for these objects, they are nested under the kuPerson object for the role occupant.
Application utility class: extended; # of values: multi
Defines the building name for the position’s postal address.
directory of directories, white pages
buildingName: Strong Hall
Syntax: directoryString
Application utility class: extended; # of values: multi
country name According to RFC 2256, "This attribute contains a two-letter ISO 3166 country code (countryName).
set of ISO 3166 country codes
directory of directories, white pages
c: ca
Syntax: directoryString
Application utility class: core; # of values: single, required
Common name.
According to RFC 2256, "This is the X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it is typically the person's full name.
Contains the title for this position. If a work title is present in Peoplesoft HR, that is what is used. Otherwise, use the position description. If by some strange chance the position description is not present, use the translated jobcode.
all
cn: Chancellor/Professor
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single, required
Specifies the department number for this position. See the departmentNumber description in kuPerson for more information.
white pages, controlling access to resources
departmentNumber: 2151000
Syntax: directoryString
Application utility class: standard; # of values: single, required
Specifies the title for this position. If a work title is present in Peoplesoft HR, that is what is used. Otherwise, use the position description. If by some strange chance the position description is not present, use the translated jobcode.
white pages, controlling access to resources
description: Chancellor/Professor
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Specifies the person’s relationship(s) to the institution in fine-grained categaries, such as UnclassifiedProfessionalStaff, KumcStaff, PreEnrolledStudent, etc. (See controlled vocabulary)
Same as kuPersonAffiliation defined in kuPerson class (above).
Although this is a multi-valued attribute, only one value will be stored here.
See the kuPersonAffiliation description in kuPerson for more information.
The values are a set of names culled from the empl_class values in Peoplesoft HR.
controlling access to resources
kuPersonAffiliation: GraduateTeachingAssistant
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies the building code for this position’s office. See the kuPersonBuildingCode description in kuPerson for more information.
white pages, controlling access to resources
kuPersonBuildingCode: ST
Syntax: directoryString
Application utility class: standard; # of values: single, required
Specifies the jobcode for this position. See the kuPersonJobcode description in kuPerson for more information.
white pages, controlling access to resources
kuPersonJobcode: 010600
Syntax: directoryString
Application utility class: standard; # of values: single, required
Specifies the position number for this position. See the kuPersonPositionNumber description in kuPerson for more information.
controlling access to resources
kuPersonPositionNumber: 00007820
Syntax: directoryString
Application utility class: standard; # of values: single
Specifies whether this role is visible. If the field is present and “Y”, the role is not visible.
Y
white pages
kuPrivateRole: Y
Syntax: directoryString
Application utility class: standard; # of values: single
The role index consist of an integer value designating the “rank” of this position among the person’s positions. The integer begins at zero and higher numbers are lower rank, thus position 0 is the person’s primary position, 1 is their next position, etc.
white pages, controlling access to resources
kuRoleIndex: 0
Syntax: directoryString
Application utility class: standard; # of values: single, required
Specifies the empl_status for this position. This is translated from the single letter value from Peoplesoft HR empl_status. The values are below and correspond, respectively, to the empl_status values A, D, L, P, R, S, and T.
Active, Deceased, LeaveOfAbsence, LeaveWithPay, Retired, Suspended, Terminated.
controlling access to resources
kuRoleStatus: A
Syntax: directoryString
Application utility class: extended; # of values: multi
locality name.
According to RFC 2256, "This attribute contains the name of a locality, such as a city, county or other geographic region (localityName".
X.520(2000) reads: "The Locality Name attribute type specifies a locality. When used as a component of a directory name, it identifies a geographical area or locality in which the named object is physically located or with which it is associated in some other important way.
directory of directories, white pages
l: Hudson Valley
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Specifies the name of the department for this position. See the ou description in kuPerson for more information.
These are taken from the translated department names from Lawrence/Edwards HR and from KUMC HR.
directory of directories, white pages, controlling access to resources
ou: Physics and Astronomy
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single
Specifies the postal address for this position. See the kuPersonPrimaryLHrAddress description in kuPerson for more information.
white pages
postalAddress: Strong Hall , room 230 $ 1450 Jayhawk Blvd $ Lawrence, KS 66045-7535
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
Follow X.500(2000): "The postal code attribute type specifies the postal code of the named object. If this attribute value is present, it will be part of the object's postal address." Zip code in USA, postal code for other countries.
ZIP code in USA, postal code for other countries.
Zip code in USA, postal code for other countries.
directory of directories, white pages
postalCode: 54321
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
Follow X.500(2000): "The Post Office Box attribute type specifies the Postal Office Box by which the object will receive physical postal delivery. If present, the attribute value is part of the object's postal address."
Follow X.500(2000): "The Post Office Box attribute type specifies the Postal Office Box by which the object will receive physical postal delivery. If present, the attribute value is part of the object's postal address."
directory of directories, white pages
postOfficeBox: 109260
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single, required
Specifies the DN for the person who holds this position.
This DN refers to the object containing this object.
controlling access to resources
roleOccupant: kuEntryId=154265, ou=People, dc=ku, dc=edu
Syntax: directoryString
Application utility class: extended; # of values: multi
Specifies the room number of a position’s postal address.
directory of directories, white pages
roomNumber: 230
Syntax: directoryString
Application utility class: extended; # of values: multi
Abbreviation for state name
Format: Standard U.S. postal service two-letter code.
According to RFC 2256, "This attribute contains the full name of a state or province (stateOrProvinceName)."
U.S. Postal Service set of two-letter state name abbreviations
State or province name. While RFC 2256 specifies use of the "full name," it is customary to use the U.S. Postal Service set of two-letter state name abbreviations for states in the U.S.
Standard two-letter abbreviations for U.S. state names
directory of directories, white pages
st: IL
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
According to RFC 2256, "This attribute contains the physical address of the object to which the entry corresponds, such as an address for package delivery (streetAddress)."
directory of directories, white pages
street: 303 Mulberry St.
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single
Specifies the telephone number for this position. See the kuPersonPrimaryPhone description in kuPerson for more information.
Unfortunately, no current staff telephone numbers are maintained in the KUMC Peoplesoft HR database, so this field will likely not be populated for KUMC positions.
white pages, controlling access to resources
telephoneNumber: +1 785 864 1234
Syntax: telephoneNumber; Indexing: pres,eq,sub
The ou=authaccounts branch contains a sub-object for every KU Online ID. These sub-objects will contain the top and kuAuthAccount object classes, and are the objects to which users must bind in order to authenticate. There will always be an owner attribute pointing to the corresponding object in the ou=people branch.
The distinguished name (or dn) for a sub-object of ou=authaccounts is of the form:
uid=onlineID, ou=authaccounts, dc=ku, dc=edu
The onlineID is the uid value corresponding to the person’s KU Online ID. This class will also have a userPassword value, corresponding to a hashed value for the user’s password.
RFC 2252 definition
( 1.3.6.1.4.1.5923.1.1.1.6
NAME 'eduPersonPrincipalName'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
Application utility class: standard; # of values: single
The "NetID" of the person for the purposes of inter-institutional authentication. Should be stored in the form of user@univ.edu, where univ.edu is the name of the local security domain.
See the definition in the ou=people branch (above).
controlling access to resources
eduPersonPrincipalName: hputter@hsww.wiz
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single
Identifies the distinguished name of the ou=people object corresponding to this entry.
controlling access to resources
owner: kuEntryId=1234567, ou=people, dc=ku, dc=edu
Syntax: distinguishedName; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
Follow inetOrgPerson definition of RFC 1274: "The [uid] attribute type specifies a computer system login name."
Likely only one value. See the extensive discussion in the "LDAP Recipe" (http://middleware.internet2.edu/dir/rpr-nmi-edit-mace_dirldap_recipe.2.0.html)
A number of off-the-shelf directory-enabled applications make use of this inetOrgPerson attribute, not always consistently.
RFC 1274 uses the longer name 'userid'.
controlling access to resources
uid: gmettes
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: extended; # of values: multi
This attribute identifies the entry’s password and encryption method in the following format:
{encryption method}encrypted password.
The user pw is hidden, and is used in the bind operation in LDAP. The bind operation must be done over SSL to avoid sending clear text passwords over the wire or through the air.
controlling access to resources
userPassword: {ssha}9LsFG7RT+dFnPErwSfxDlaQTn6dbIFGklMNFRr==
Syntax: binary
The ou=aliases, dc=ku, dc=edu branch contains a sub-object for every domain that the KU MTAs translate and forward. Currently we forward ku.edu, kletc.org, kualumni.org, and kansan.com. Each of these branches contains a sub-object for every alias in that domain. These sub-objects will contain the top, kuObject, and kuAccount object classes, with a uid attribute equal to the incoming mail address (e.g. myalias@ku.edu) and a mail attribute equal to the destination address (e.g. myusername@mail.ku.edu).
The distinguished name (or dn) for a sub-object of ou=people is of the form:
uid=alias@domain, ou=domain, ou=aliases, dc=ku, dc=edu
Application utility class: standard; # of values: multi
Contains the label for the alias in the ku.edu alias table. If the alias is not in the ku.edu domain, the attribute is null.
We are populating this attribute with the the label for the alias.
directory of directories, white pages
description: Registered email address
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single, required
For aliases in the ku.edu domain, specifies the object’s ID in the AIMS database. For aliases in other domains, contains some unique value.
linking back to the AIMS database for updates
kuEntryId: 154265
Syntax: directoryString; Indexing: pres,eq
Application utility class: standard; # of values: single, required
Specifies that the object is an alias.
alias.
white pages, access to resources
kuObjectType: alias
Syntax: directoryString
Application utility class: standard; # of values: multi
Specifies the delivery email address for the alias.
local mail transfer agents
mail: myemail@mail.ku.edu
Syntax: directoryString; Indexing: pres,eq,sub
Application utility class: standard; # of values: single
For an alias in the ku.edu domain, identifies the distinguished name of the ou=authaccounts object corresponding to this entry. For aliases in other domains, the attribute will be null.
linking back to AIMS.
owner: uid=gmettes, ou=authaccounts, dc=ku, dc=edu
Syntax: distinguishedName; Indexing: pres,eq,sub
Application utility class: standard; # of values: multi
The alias email address.
This is of the form alias@domain, e.g. myalias@ku.edu. Mail sent to this address will be delivered to the address in the mail attribute.
controlling access to resources
uid: gmettes@ku.edu
Syntax: directoryString; Indexing: pres,eq,sub
The kuObject class defines ku-specific attributes for an object, whether a person or a departmental account. It is used in the ou=people,dc=ku,dc=edu tree. It extends eduPerson and kuAccount independently. This class is always included when defining any kuPerson or kuAccount objects.
The kuPerson class defines ku-specific attributes for a person. It extends kuObject and eduPerson, which in turn extend the standard LDAP inetOrgPerson, organizationalPerson, and person classes. It is used in the ou=people,dc=ku,dc=edu tree.
Any object containing the kuPerson object class will also contain the object classes kuObject, eduPerson, inetOrgPerson, organizationalPerson, and person, and also will likely contain kuSmartforce.
Below, we first define the new kuPerson attributes, then the kuSmartforce attributes, then the eduPerson attributes, followed by those attributes from the standard LDAP classes inetOrgPerson, organizationalPerson, and person. Within each group the attributes are presented in alphabetical order rather than in any logical order.
The kuAccount class defines ku-specific attributes for a departmental account. It extends the kuObject class, indicating which department owns the account and specifying more directory information for the account. It is based on the standard account class, but is independent of it. It is used in the ou=people,dc=ku,dc=edu tree.
The kuOrganizationalRole class provides a way of grouping attributes for people with multiple positions or roles. Such a person would have multiple kuOrganizationalRole objects as sub-objects, each one grouping the person’s title, department, empl_class, address, and telephone information. It extends the organizationalRole class. It is used in the ou=people,dc=ku,dc=edu tree, and is always a sub-object of a kuPerson object.
The kuSmartforce class is used by the Smartforce login process to provide a password to the Smartforce web site. Each person will have kuSmartforce attributes as well as kuObject, kuPerson, eduPerson, inetOrgPerson, organizationalPerson, and person attributes. Since we may have other applications that need special handling it is probably better to create new object classes containing application-specific data rather than cluttering kuPerson with this information. This is especially important given that we may switch vendors on occasion, necessitating an adjustment to our LDAP schema. It is easier and more reliable to drop an entire object class and possibly replace it with another than to change the existing object classes, though we may at some point need to do that, too.
The eduPerson class is an auxiliary object class for campus directories designed to facilitate communication among higher education institutions. It consists of a set of data elements or attributes about individuals within higher education, along with recommendations on the syntax and semantics of the data that may be assigned to those attributes.
RFC definition
( 1.3.6.1.4.1.5923.1.1.2
NAME 'eduPerson'
AUXILIARY
MAY ( eduPersonAffiliation $ eduPersonNickname $
eduPersonOrgDN $ eduPersonOrgUnitDN $
eduPersonPrimaryAffiliation $ eduPersonPrincipalName $
eduPersonEntitlement $ eduPersonPrimaryOrgUnitDN $
eduPersonScopedAffiliation)
Attributes
buildingName................................. 3, 61
c. 4, 61
cn....................................................... 4, 61
departmentNumber...................... 5, 62
description................................. 5, 62, 71
displayName......................................... 5
eduPersonAffiliation........................... 6
eduPersonEntitlement........................ 7
eduPersonNickname........................... 8
eduPersonOrgDN................................ 9
eduPersonOrgUnitDN...................... 10
eduPersonPrimaryAffiliation.......... 11
eduPersonPrimaryOrgUnitDN........ 12
eduPersonPrincipalName........... 13, 69
eduPersonScopedAffiliation............ 15
entry_id................................................ 21
facsimileTelephoneNumber............. 16
fax......................................................... 16
givenName.......................................... 16
homePhone......................................... 16
homePostalAddress........................... 17
host....................................................... 17
initials................................................... 18
kuAccountComment......................... 18
kuAccountContactAddress.............. 18
kuAccountContactName.................. 19
kuAccountContactPhone.................. 19
kuAccountSubDepartment.............. 19
kuAccountUid.................................... 20
kuAlias........................................... 20, 21
kuAliasHidden............................. 20, 21
kuEntryId................................ 21, 61, 72
kuObjectType................................ 22, 72
kuOrganizationalRole................. 28, 33
kuPerson.............................................. 63
kuPersonAffiliation............... 22, 31, 63
kuPersonBirthdate............................. 24
kuPersonBuildingCode............... 24, 63
kuPersonCampusId........................... 36
kuPersonCanonicalName................. 25
kuPersonCardIsoNumber................. 25
kuPersonJobcode.......................... 25, 63
kuPersonKuceAddress...................... 26
kuPersonKuceId................................. 26
kuPersonKucePhone......................... 27
kuPersonLHrId................................... 27
kuPersonLMail................................... 28
kuPersonLRole.................................... 28
kuPersonMHrId................................. 29
kuPersonMMail.................................. 29
kuPersonMRole.................................. 30
kuPersonPositionNumber.......... 30, 64
kuPersonPrimaryAffiliation....... 23, 31
kuPersonPrimaryDepartment.......... 31
kuPersonPrimaryHomeAddress..... 32
kuPersonPrimaryHomePhone......... 32
kuPersonPrimaryLRole..................... 33
kuPersonPrimaryMRole.................... 33
kuPersonPrimaryOfficeAddress...... 34
kuPersonPrimaryOfficePhone......... 34
kuPersonStuAcademicGroup.......... 35
kuPersonStuCampusAddress.......... 35
kuPersonStuCampusPhone.............. 36
kuPersonStuCareer............................ 36
kuPersonStuDegreeCheckoutStatus 37
kuPersonStuEnrolled......................... 37
kuPersonStuEnrolledCampus.......... 38
kuPersonStuEnrolledInactive.......... 39
kuPersonStuHideFERPA.................. 40
kuPersonStuHomeAddress.............. 40
kuPersonStuHomePhone................. 41
kuPersonStuId.................................... 41
kuPersonStuLevel.............................. 41
kuPersonStuMaritalStatus................ 42
kuPersonStuPlan................................ 42
kuPersonStuPrimaryAcademicGroup 43
kuPersonStuPrimaryCareer............. 43
kuPersonStuPrimaryPlan................. 44
kuPersonStuPrimaryProgram.......... 44
kuPersonStuPrimarySubPlan........... 45
kuPersonStuProgram........................ 45
kuPersonStuSubPlan......................... 46
kuPersonStuTerm.............................. 46
kuPersonTeaches................................ 47
kuPrivateAttribute............................. 47
kuPrivateRole..................................... 64
kuRoleIndex.......... 28, 30, 33, 34, 61, 64
kuRoleStatus....................................... 65
kuSmartforcePassword..................... 48
l.. 48, 65
labeledURI........................................... 49
mail........................................... 28, 50, 72
manager............................................... 51
mobile.................................................. 51
o. 52
organizationName............................. 52
ou.............................................. 31, 52, 66
owner....................................... 53, 70, 73
pager..................................................... 53
postalAddress............................... 53, 66
postalCode..................................... 54, 66
postOfficeBox................................ 54, 67
preferredLanguage............................ 55
roleOccupant...................................... 67
roomNumber................................ 55, 67
secretary............................................... 55
seeAlso................................................. 56
sn........................................................... 56
st 57, 68
street............................................... 57, 68
telephoneNumber........................ 58, 68
title........................................................ 58
uid....................................... 58, 69, 70, 73
userCertificate.................................... 59
userSMIMECertificate....................... 60
Branches
ou=aliases........................................ 3, 71
ou=authaccounts............................ 3, 69
ou=groups............................................. 2
ou=people.................................... 2, 3, 70
Object classes
account................................................. 74
eduPerson 6, 7, 8, 9, 10, 11, 12, 13, 15, 73, 74
inetOrgPerson 5, 16, 17, 18, 28, 29, 49, 50, 51, 52, 53, 55, 58, 59, 60, 72, 73, 74
kuAccount 3, 4, 5, 16, 17, 18, 19, 20, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 71, 72, 73, 74
kuAuthAccount...................... 69, 70, 71
kuObject........... 20, 21, 22, 47, 72, 73, 74
kuOrganizationalRole 28, 30, 33, 60, 61, 62, 63, 64, 65, 67, 74
kuPerson 3, 4, 5, 22, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 55, 61, 62, 63, 64, 66, 69, 73, 74
kuSmartforce................................ 48, 74
organizationalPerson 16, 17, 48, 52, 53, 54, 57, 58, 74
organizationalRole 60, 61, 62, 65, 66, 67, 68, 74
person............................... 4, 5, 56, 58, 74