UW Windows Infrastructure Policy - DRAFT

This policy applies to users and administrators of the UW Windows Infrastructure (UWWI).

Creation of Windows Domains

No additional domains are allowed within UWWI. netid.washington.edu is the only domain in the forest.

Domain Trusts

UW campus domains may request a 1-way incoming external or forest trust to netid.washington.edu. The netid.washington.edu domain will not trust other domains for any reason. To acquire the incoming trust they must:

• Have an owner
• Have a specified group of administrators
•  Have a support contact
•  Notify UWWI of any domain-level breach or suspected breach
•  Notify UWWI of any breach or suspected breach that may have exposed UWWI user credentials
•  Assist in the investigation and remediation of any suspected breach that involves their domain
• Comply with the Microsoft licensing policy and any other applicable software licensing terms.

NT4 domains are not eligible for a domain trust with UWWI.

The UWWI governance team reserves the right to remove a trust on the following grounds:

• Failure to comply with UWWI policy
• A breach or suspect breach puts other members of the UWWI community at high risk.

Schema

With the exception of service impacting schema issues, schema changes will first be implemented in the UWWI pre-production forest. UW administrators will be notified and given two weeks to test these changes.

The UWWI 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
• can only login on a small number of trusted computers in managed domains
• where possible, additional authentication factors are required
• 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 Windows 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

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 requires notification to UW administrators.

Personal Data and Visibility

Individuals granted access to personal data in the UWWI Active Directory 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 UWWI Active Directory, 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 propogated into the UWWI Active Directory. Direct data entry will be overwritten by automated processes.

Computer Account Creation

Windows administrators must 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 UWWI. 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 UWWI Active Directory.
• Resource NetIDs should be used for accounts which have no need to authenticate, but must have a Windows user object.
• Supplemental NetIDs should be used as little as possible.

Group Creation

Windows administrators must not manually create groups in UWWI. All groups are created via the Groups Web Service (GWS).

Groups may be manually created when:

• Your need is incompatible with naming restrictions enforced by GWS

• Your need requires features not supported by GWS

Authentication

UWWI Active Directory only permits NTLMv1, NTLMv2, or Kerberos authentication. Services within UWWI may employ other authentication mechanisms, but those authentication mechanisms should meet the UW Minimum Security Computing standard.

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 account passwords directly; instead passwords should be changed with the UW NetID system using the Manage Your UW NetID site.

Kerberos Delegation

With UWWI 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 will be entertained by the UWWI governance body, 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, UWWI marks 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
• Supplemental NetIDs
• Resource NetIDs

Exceptions can 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 his or her administrative privileges.

All actions taken by all accounts are subject to monitoring and audit.

Software License Compliance

Prior to using the UW Windows Infrastructure you must ensure that your system adheres to Microsoft software licensing policy.

Every computer (whether it runs Windows or not) that connects to UWWI should have a Windows Server 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 UWWI. Since non-compliance can conceivably effect any service provider that makes use of UWWI, it is in the UW’s best interest to ensure proper licensing. UW Technology does not provide Microsoft server licenses or client access licenses. UW does not have a campus site license for Microsoft Software, however, the campus does have an attractive pricing structure via a volume licensing agreement.

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 and the domain controller group policy settings.

These security settings do limit the use and services you can provide when using UWWI, and you may need to refer to KB823659 to fully understand the implications of these settings.