UW Windows Infrastructure Architecture Guide

This document is for Windows computing professionals who wish to learn about how the UW Windows Infrastructure is designed and implemented.

Directory Configuration

The UW Windows Infrastructure is built upon Microsoft Active Directory across multiple domain controllers. The operating system of these domain controllers is kept within one major rev of the latest released operating system.

LDAP configuration settings are generally set to the Active Directory defaults (MaxValRange is 1500--that's mistakenly omitted in the Microsoft document that is linked).

Schema

The UW Windows Infrastructure schema is open to changes, and includes both vendor and UW custom schema elements. See the UWWI Schema for details.

Object Creation

There are some directory objects which Windows administrators can not create regardless of the permissions they have been delegated. These include: users, contacts, and groups. This is because these objects have the potential to cause a namespace collision with institutionally provisioned objects.

All user accounts are created via the UW NetID account system. Where appropriate, you should use application NetIDs for non-person entities that have a need to authenticate; service accounts, scheduled tasks, and the like should use an application NetID.

All groups are created via the Groups Web Service which is an interface to the Groups Directory Service which are then subsequently synchronized to UWWI. If, for some reason, the namespace enforced by GDS isn't compatible with your needs, e.g. a vendor product that is hard-coded for a specific group name, then feel free to escalate this issue.

Passwords

Users do not reset their NETID account passwords directly; instead passwords are changed with the UW NetID system using the Manage Your UW NetID site.

Directory Structure

The above diagram shows the UWWI directory structure or directory information tree (DIT), leaving out all the built-in containers which are largely unused by UWWI.

All groups within UWWI are under the top-level Groups OU. Groups based on data synchronized from the Groups Directory Service (GDS) are within OU=GDS. These GDS groups are separated into OUs by affiliation groups, course groups, privacy groups, and basic or standard groups. Affiliation groups have large numbers of members in them. Course and privacy groups have private membership. There are a very large number of course groups. Groups which have no institutional value as re-usable outside UWWI are within OU=UWWI. In other words, this is the location for groups whose source directory is UWWI. Groups used for AD administration are an example of groups which reside here. If you had a vendor-required group which didn't meet the GDS naming policy, it might go here.

All personal and shared UW NetIDs are under the top-level UWNetID OU. There are greater than 300000 Windows user accounts within this OU.

All non-personal and non-shared UW NetIDs are under the top-level Other NetIDs OU. These other UW NetIDs are separated into OUs by NetID type: admin NetIDs, application NetIDs, and resource NetIDs. See ### for more info on NetID types.

All computers and other directory objects specific to UWWI clients are under the top-level Delegated OU. This is where departments, schools, and other UW organizations will be able to get a delegated OU at some point in the future. For the time being, only UW Technology has an OU in this area. When delegated OUs are ready, this is the only part of the UWWI directory structure that campus Windows administrators will be granted a non-default level of permissions.

Provisioning and Synchronization Integration with UW Infrastructure

There are four connectors integrating UWWI provisioning with the larger campus computing infrastructure. There is an account and password provisioning component, called Kiwi. The UWWI kiwi agent is called fuzzy_kiwi. There is a person directory synchronization component, called ILM. There is a service provisioning component, called SubMan or Subscriptions Manager. And there is a groups directory synchronization component, called Slurpee. Together these components automatically provision accounts, groups, passwords, personal directory information, and help computing services to work with UWWI.

This set of connectors is responsible for all user creations, and almost all group creations. This set of connectors is also responsible for almost all modifications to users or groups. Direct creation or modification of users and groups is not kosher without very good reason, because these components assume responsibility and authority for these functions, and in some cases will overwrite direct changes made, possibly resulting in disastrous consequences.

For more detailed information about these key architectural components, please follow the links to each component above. You may also want to investigate documents nested within the links above, notably:

• The full details on how ILM maps data from PDS to UWWI are here.
• The full details of how Slurpee maps GDS data to UWWI are here.

User Attributes

The full set of all UWWI possible user attributes is documented here. Not all possible UWWI user attributes are in use. The subset of all UWWI user attributes in use and centrally managed are documented here.

User Attribute Visibility

The following user attributes are not visible, beyond your own user account, without special permissions:

instanceType
whenCreated
whenChanged
uSNCreated
memberOf
uSNChanged
userAccountControl
badPwdCount
badPasswordTime
lastLogon
pwdLastSet
accountExpires
logonCount
dSCorePropagationData
lastLogonTimestamp
uwRegID
eduPersonAffiliation

It is possible to request additional read permissions to users, but this requires both Registrar and UW Technology approval for a valid business requirement.

SPNs

Service Principal Names (SPNs) are the Kerberos principal identity for services which make use of a Ticket Granting Service (TGS). SPNs are very similar to the User Principal Name (UPN) that all Windows users accounts have. Every computer in a given Windows domain has two default SPNs, and additional SPN values for non-default Windows services must be added. Some Windows services run under the context of a user account, instead of the System account (which maps to the computer account object). For these services, an SPN is needed that represents the Windows service(s).

By default, only domain admins can set SPNs because assigning SPNs is a security sensitive operation.

For the purposes of computer accounts, the ability to set SPNs has been delegated to the OU admins for any given computer. SPN conflicts will be mediated by UWWI Enterprise Admins in consultation with the UWWI governance body and affected clients. UWWI Enterprise Admins may act quickly if critical University business is threatened.

For the purposes of user accounts, at this time, you should send requests to the UW Technology help desk.

Delegation and Impersonation

Kerberos delegation allows a service account (i.e. an application NetID) to be permitted to act on behalf of any account which passes that service account its login token on other computers. This is different than Windows impersonation, which allows a service account to act on behalf of any account on the same computer where a login token was passed. Kerberos delegation requires Domain Administrator privileges to enable. Open delegation permits login token reuse to any computer (even computers in other domains or that aren't Windows based). Constrained delegation limits where login token reuse can occur to specific computers paired with specific network services and network ports.

See UWWI Policy, Kerberos Delegation for UWWI policy with regards to use of this technology.

Note that all non-personal UW NetIDs are marked as sensitive, which means that they can not be used with delegation. In other words, only personal NetIDs (not shared NetIDs, not admin NetIDs, not application NetIDs, etc) can be used with delegation, and have their login tokens re-used by accounts that have been granted this permission.