This policy applies to users and administrators of the Microsoft Infrastructure (MI). There are several other documents which are closely related to this policy document. They are:
- Delegated OU Practices, discussed rules in practice for those using Delegated OUs
- Schema Best Practices, discusses rules in practice for adding schema
- Contact Practices, discusses rules in practice for adding contacts
- Group Policy, documents key group policy settings
Creation of Windows Domains
No additional domains are allowed within the NETID forest. netid.washington.edu is the only domain in the forest.
Domain Trusts
Domain trusts with the netid.washington.edu domain are possible with other UW domains under one of following two scenarios. A UW domain is one which is in or under a DNS zone which UW owns (e.g. washington.edu, uw.edu, uwb.edu) and for which the system owner and manager is a UW employee.
- Incoming trust: In general, the netid.washington.edu domain will grant other UW domains the right to trust it, subject to applicable policies, restrictions set forth below, and an annual review of the need.
- Outgoing trust: In general, the netid.washington.edu domain will not trust other domains. However, UW units may request that the NETID domain trust their domain on a temporary basis subject to the following:
- NT 4 and Windows 2000 domains will not be trusted.
- The request must be in support of an approved project in UW-IT’s project portfolio. That project must have:
- approved resource commitments
- a plan and timeline that minimizes the length of time the trust exists
- has a deliverable to migrate the resources of the domain into the netid.washington.edu domain
- has a deliverable to decommission the domain
- Domain management practices must include the following:
- domain password policy meets or exceeds the requirements of the UW NetID password policy
- domain controllers must be patched and install all recommended patches within 7 days
- NETID domain administrators must be granted Domain Admin privileges
- account names must match UW NetIDs for any given user
- domain controllers must be physically secured in a managed datacenter
- accounts with administrative privileges in the domain, including but not limited to Domain Admins, Enterprise Admins, Account Operators, Schema Admins, and Administrators, must:
- not be used as “personal” accounts,
- have passwords that meet or exceed the complexity requirements for Admin UW NetIDs, and
- must not be shared
- Selective Authentication MUST be employed
Additionally, either case is subject to approval by the MI Service Team.
Each requesting unit must:
- Provide the MI Service Team with a domain support contact, secondary support contact, and an escalation contact – each with specific contact methods that can be used reliably 24/7/365.
- Notify the MI Service Team and the CISO’s Office of any domain-level breach or suspected breach, or one that may have exposed netid.washington.edu credentials
- Assist the MI Service Team, and the CISO’s Office or other investigating agency, with investigating any breach or suspected breach
- Comply with all applicable software licenses
In all cases, a granted trust may be removed on the following grounds:
- Failure to comply with policy
- A breach or suspected breach
- A broken trust in combination with a failure of responsible support contact(s) to resolve the issue
Schema
Schema changes SHOULD be first implemented in the MI pre-production forest. UW administrators SHOULD be notified of changes. Service-impacting schema changes SHOULD have a 2 week notice beforehand.
The schema best practices are fully documented outside this document.
Enterprise Administrators, Domain Administrators, and Account Operators
Windows accounts with enterprise administrator, domain administrator, or account operator level privileges MUST submit to additional security restrictions to provide a reasonable level of assurance. These additional security restrictions include:
- the account MUST be an enterprise admin NetID
- logins SHOULD be limited to a small number of trusted computers
- where possible, additional authentication factors SHOULD be used
- use of privileges by these accounts is available for review by UW Security Operations
Accounts with this level of privilege MUST NOT:
- take ownership of any non-centrally managed resource in the Microsoft Infrastructure UNLESS requested to do so by someone with the appropriate authority, or in a case of emergency when failing to do so will put UW resources at risk
- manually reset passwords, manually create user accounts, or otherwise circumvent established architecture design, EXCEPT for documented exceptions or by agreement of the MI service manager
The number of individuals with enterprise administrators, domain administrators, or account operator level privileges MUST be kept to a very small number per best practices. Changes to who has these privileges SHOULD result in a notification to UW administrators.
Personal Data and Visibility
Individuals granted access to personal data in the NETID domain MUST respect the data privacy it has been given, using it only for official UW business, according to the Family Educational Rights and Privacy Act of 1974 (FERPA). Individuals MAY request access to personal data stored in the NETID domain, including course group membership, via the Registrar.
Individuals and departments SHOULD NOT directly modify any of their user account attributes. Modifications SHOULD be made to the authoritative data of record, and propagated into the NETID domain. Direct data entry on NETID user accounts CAN be overwritten by automated processes.
Computer Account Creation
Windows administrators SHOULD pre-create all new computer accounts via Active Directory Users & Computers prior to actually joining the computer to the NETID domain.
User Accounts
Windows administrators MUST NOT manually create user accounts in the NETID domain. All user accounts are created via the UW NetID account system.
The appropriate type of UW NetID SHOULD be used whenever possible. Examples of expected use within UWWI include:
- Personal NetIDs SHOULD be used for normal day to day work responsibilities.
- Application NetIDs SHOULD be used for non-person entities that have a need to authenticate, i.e. system accounts, service accounts, and scheduled tasks.
- Admin NetIDs SHOULD be used for all accounts granted administrator level privilege on servers, large sets of workstations, or which are delegated elevated permissions within the NETID domain.
- Resource NetIDs SHOULD be used for accounts which have no need to authenticate, but must have a Windows user object.
- Shared NetIDs SHOULD be used as little as possible.
Group Creation
Windows administrators MUST NOT manually create groups in the NETID domain. All groups are created via the Groups Service (GS).
Groups MAY be manually created when:
- Your need is incompatible with naming restrictions enforced by GS
- Your need requires features not supported by GS
Contacts
Delegated OU administrators MUST NOT manually create contacts in the NETID domain. All NETID domain contacts are centrally managed, i.e. there are policies and practices about their lifecycle.
Contact names in the NETID domain SHOULD conform to a c_<variable> namespace policy, and are considered part of the UW NetID namespace. There are use cases which may not be able to conform to this namespace, and those will be handled on a case by case basis.
Contacts for Exchange email forwarding and to enable Sharepoint alerts for an email address not currently represented in the NETID domain are known use cases which MI Engineering will actively create and manage. Requests for contacts for all other use cases will require further review by the MI service manager.
Authentication
The NETID domain only permits NTLMv2 or Kerberos authentication. Services within the NETID domain MAY employ other authentication mechanisms, but those authentication mechanisms SHOULD meet the UW computing standards.
Passwords
All accounts MUST have a password that meets certain basic requirements for strength, complexity and form, as spelled out in the UW NetID Passwords document. Users CAN NOT reset their NETID user account passwords directly; instead passwords SHOULD be changed with the UW NetID system using the Manage Your UW NetID site.
Kerberos Delegation
With NETID user accounts, constrained delegation is permitted, given adequate business justification. The application NetID granted constrained delegation permissions MUST be restricted to only be able to login to a known list of computers. Open delegation requests MUST obtain approval by the MI service manager, and further discussion about business justification is required. To request delegation, send a request to help@u.washington.edu.
For the purposes of protection from misuse by delegation, MI WILL mark all non-personal UW NetIDs as sensitive to delegation, meaning they CAN NOT be used with delegation. This means that the following types of NetIDs CAN NOT be used with delegation:
- Application NetIDs
- Admin NetIDs
- Shared NetIDs
- Resource NetIDs
Exceptions MAY be made given adequate business justification, and appropriate levels of security risk mitigation.
Security Review
UW Security Operations has access to all security events. All use of administrative privileges WILL be audited for review by the UW Security Operations. In addition to general security evaluations, Security Operations investigates circumstances in which a Windows administrator is suspected or is deemed to have abused their administrative privileges.
All actions taken by all accounts are subject to monitoring and audit.
Software License Compliance
Prior to using the Microsoft Infrastructure you MUST ensure that your system adheres to Microsoft software licensing policy.
Every computer (whether it runs Windows or not) that connects to the NETID domain SHOULD have a Windows Client Access License (CAL). Additional licenses MAY be required depending on additional service usage. Ongoing compliance is REQUIRED after you have started making use of the NETID domain. Since non-compliance can conceivably effect any service provider that makes use of the NETID domain, it is in the UW’s best interest to ensure proper licensing. UW-IT does provide Microsoft licenses or client access licenses via a Campus Agreement partially funded by the Technology Recharge Fee, but most software licenses are limited to UW owned computers.
Domain Security Settings
Domain-wide security settings SHOULD follow UW computing policies. Changes to these settings MUST be reported to UW administrators.
The domain security settings are documented within the domain level group policy settings.
These security settings do limit the use and services you can provide when using the NETID domain, and you may need to refer to KB823659 to fully understand the implications of these settings.