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.

Additional documents are linked from this page that describe in greater detail the core architectural components that comprise UWWI.

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.

Provisioning and Synchronization Integration with UW Infrastructure

There are four connectors integrating UWWI provisioning with the larger campus computing infrastructure. They are:

• an account and password provisioning component, called Kiwi. The UWWI kiwi agent is called fuzzy_kiwi.
• a person directory synchronization component, called ILM.
• a service provisioning component, called the UW NetID Subscriptions Manager, which is part of the UW Exchange service
• the UWWI Group Sync Agent

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 allowed 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.

In the diagram above, you can see the flow of group data from the Group Web Service along the purple arrows to UWWI. You can see the flow of password data from the UW NetID system along the yellow arrows to UWWI. You can see the flow of person directory data along the red arrows to UWWI. You can see the flow of service lifecycle data (subscription data) along the white arrows to UWWI and UW Exchange. And finally, you can see the flow of directory data (users, groups, and contacts) from the NETID Active Directory to our Office 365 Windows Azure Active Directory (WAAD) along the dark blue arrows. Arrows with solid lines represent push-based data transfer from one component to the destination. Arrows with dotted lines represent pull-based data transfer, with the recipient as the initiator.

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.
• The details of the Office 365 DirSync connector are here (undocumented at this time).

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 managed user attributes are not visible, beyond your own user account, without special permissions:

accountExpires
badPwdCount
badPasswordTime
dSCorePropagationData
eduPersonAffiliation
facsimileTelephoneNumber
instanceType
lastLogoff
lastLogon
lastLogonTimestamp
logonCount
managedObjects
memberOf
msExchMobileMailboxFlags
msExchUMDtmfMap
msExchUMEnabledFlags
msExchUMPinChecksum
msExchUMRecipientDialPlanLink
msExchUMTemplateLink
msRTCSIP-ArchivingEnabled
msRTCSIP-FederationEnabled
msRTCSIP-InternetAccessEnabled
msRTCSIP-Line
msRTCSIP-OptionFlags
msRTCSIP-PrimaryHomeServer
msRTCSIP-PrimaryUserAddress
msRTCSIP-UserEnabled
priorUWNetID
pwdLastSet
uSNChanged
uSNCreated
uwNetID
uwRegID
uwTest
whenChanged
whenCreated

Other unmanaged attributes may also not be visible, but there are too many of those to document.

Additional UWWI Directory Access

It is possible to request additional read permissions to users, but this requires the following set of approvals for the full set of data in UWWI:

• Registrar approval for Student data in a UW Directory (see UW Directories - Student Data item on link)
• UWWI directory access

The Registrar approval is required for access to users because the memberOf attribute on each user may include group memberships for course groups, which is FERPA protected data, or for other membership-restricted groups. Of course, all such approvals are subject to a valid business requirement.

The UWWI directory access process in general is to request access via the above link, providing details on the business requirement necessitating an additional level of access, and the specific additional access required.

Currently, there is no established mechanism to obtain access to a smaller set of UWWI directory user attributes than all attributes for all users.

Self Write Permissions

It is possible to write to some of your own user UWWI user attributes. In general, we don't recommend this, and we don't make any promises that attributes that you can write to won't become a managed user attribute at some point in the future. However, the ability to write to some of these user attributes may enable functionality that is important to you that we don't yet provide centrally via managed user attributes or via the UWWI User Support mechanism. The set of UWWI user attributes that you can write to is the default set enabled by Microsoft out of the box.

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.

UWWI doesn't make any promises about where a given UWWI user account or group will be located. We reserve the right to move objects to meet changing service requirements. You should not make assumptions about where user or  group objects are located. UWWI does follow some practices about user and group placement, but there are circumstances where we may not follow those practices, or may change those practices without notice.

Most groups within UWWI are under the top-level Groups OU. Groups based on data synchronized from the Groups Service (GS) are within OU=GDS. These GS groups are separated into OUs by course groups, member privacy groups, and standard groups. Course and member 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. These groups are kept to a minimum and can only be created by exception. If you had a vendor-required group which didn't meet the GS naming policy, it might go here.

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

Most Admin, Resource, and Application 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 UW NetID Accounts and Passwords for more info on UW NetIDs.

Most 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 that request a delegated OU are created. This is the only part of the UWWI directory structure where campus Windows administrators are granted a non-default level of permissions.

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 Service which are then subsequently synchronized to UWWI. If, for some reason, the namespace enforced by GS 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.

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.