UW Windows Infrastructure Schema
The current UW Windows Infrastructure (UWWI) schema is documented below.
UWWI will entertain any schema modification requests. All schema modifications must
follow schema best practices. Vendors tend to follow these best practices. Custom
schema modifications are also possible. Schema best practice is documented below.
Schema modifications that are deemed to follow best practices are likely to be added.
NOTE: At this time, UWWI does not permit any directory information to be written
by user accounts, except to your own user account, and then only to the "personal"
attributes that you have write permission to by default.
Current Schema
|
Description |
Schema Vendor |
Date Added |
Notes |
|
Windows Server 2003 R2 |
Microsoft Corporation |
June 29, 2006 |
Base Schema |
|
Exchange Server 2003 |
Microsoft Corporation |
June 29, 2006 |
|
UW Enterprise Directory Services /
Group Directory Services |
University of Washington |
July 20, 2006 |
Modified for Active Directory |
|
eduPerson |
Internet2/EDUCAUSE |
July 20, 2006 |
|
|
Catalyst Labs - Macintosh Support |
University of Washington |
July 20, 2006 |
Used by the EPLT labs for
Mac authentication |
|
Dell Remote Access Controller |
Dell |
August 7, 2006 |
Allows central management of Dell DRAC-enabled devices |
|
Vista Bitlocker TPM Extensions |
Microsoft Corporation |
February 1, 2007 |
|
|
Exchange Server 2007 |
Microsoft Corporation |
June 1, 2007 |
|
|
Office Communications Server 2007 |
Microsoft Corporation |
November 1, 2007 |
|
|
Exchange Server 2007 SP1 |
Microsoft Corporation |
December 12, 2007 |
|
Custom Schema Best Practices
- Unique OIDs are used for every objectclass and attribute. These OIDs belong to the
vendor or organization employing the schema modification OR the OIDs are tied to
standards-based schema definitions. The UW has an OID space. Contact the NOC to
request an OID arc for custom schema definition.
- Objectclass and attribute names that are not likely to create a future collision. Prepending
the vendor or organization's name to the attribute or objectclass name is recommended
to avoid possible collisions. For example, "year" is a poor attribute name choice.
"uwYear" is a well-chosen attribute name.
- Objectclass hierarchy doesn't break existing functionality. For example, inserting
a superior objectclass above the user objectclass or a structural objectclass on
top of the user objectclass may introduce changes that break existing functionality.
- Thoughtful use of attribute indexing. Indexing can introduce a great deal of overhead.
Only attributes that are widely used should be indexed.
- Thoughtful use of when an attribute should be included in the global catalog partition
set. Only attributes that are widely used and needed during login should be included
in the global catalog.
- Existing schema objects are not modified. (As the Active Directory vendor, Microsoft
has in the past modified existing schema objects, and this is acceptable as an exception.)
- Appropriate attribute syntax is used for the data to be stored. Poor choice of syntax
can result in unnecessary directory overhead.
- displayName=cn
- Use auxiliary classes to enhance existing objectclasses.
- Populate the description attribute with meaningful information.
- Schema modifications are in LDIF format.
In addition, some thought should be given to the following questions:
- How volatile is the data that will employ this schema modification?
- How will objects using this schema be managed and manipulated?
- What security settings are required to grant applications/users access to read/modify
the data?
- Who are the users of the data?
- Are there data privacy issues that should be considered?
- What is the total data size expected to be added to the directory from this schema
modification?