The NETID AD has multiple domain controllers to provide the NETID domain. The operating system of these domain controllers is kept within one major revision of the latest released operating system. LDAP configuration settings are generally set to the Active Directory defaults.
A noteworthy configuration of our AD is that most users can not read all user, group, and contact objects unlike the default configuration of Active Directory. Our configuration is more secure, and helps us provide groups with a private membership. You’ll find more information about this in this guide.
| On This Page |
Directory Structure
The above diagram shows the NETID domain structure or directory information tree (DIT), leaving out all the built-in containers which are largely unused.
We don’t make any promises about where a given NETID user 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. We do 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 the NETID domain are under the top-level Groups OU. Groups based on data synchronized from the Groups Service (GS) are within OU=GDS. These 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 the NETID domain 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.
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 NETID 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 NETID domain structure where campus Windows administrators are granted a non-default level of permissions.
Schema
The NETID domain schema is open to changes, and includes both vendor and UW custom schema elements. See the NETID Schema for details.
NETID User Attributes
The full set of all possible NETID user attributes is documented here. Not all possible NETID user attributes are in use. The subset of all NETID user attributes in use and centrally managed are documented here.
NETID 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
homeDrive
homeDirectory
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
profilePath
pwdLastSet
scriptPath
uSNChanged
uSNCreated
uwNetID
uwRegID
uwTest
whenChanged
whenCreated
Other unmanaged attributes may also not be visible, but there are too many of those to document.
NETID User Self Write Permissions
It is possible to write to some of your own user NETID 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 NETID User Support mechanism. The set of NETID user attributes that you can write to is the default set enabled by Microsoft out of the box.
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. However, in several cases, delegated OUs or user accounts themselves can set a SPN vale. More about self-service SPN assignment is documented.
SPN conflicts will be mediated by MI admins in consultation with the MI service manager and affected customers. We may act quickly if critical University business is threatened.
If you need help setting a SPN, you should send requests to the UW-IT 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 MI Policy, Kerberos Delegation for MI 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.