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.
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
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).
The UW Windows Infrastructure schema is open to changes, and includes
both vendor and UW custom schema elements. See the
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
- a person directory
synchronization component, called
- a service provisioning
the UW NetID Subscriptions Manager, which is part of the UW Exchange service
UWWI Group Sync Agent
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:
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:
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:
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
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
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.
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
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.
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
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
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.
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.
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
UWWI Policy, Kerberos Delegation for UWWI policy with regards to use of this
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.