IT Connect
Your connection to information technology at the UW

Services and the NETID Domain

This document answers questions about running services in the NETID domain. We welcome suggestions as to additional questions that should be added to this document.

Should I use Azure AD, Shibboleth, Pubcookie, or NETID domain-based Integrated Windows Authentication with my Windows web application?

This is a complex question and requires a lengthy explanation to fully explain it. We’ll try to be brief, but please contact UW-IT if you would like to discuss this further.

First, Pubcookie is in containment by the Authentication service that provides it. Don’t deploy anything new using it. It also lacks authorization integration with Windows, so it was never an ideal choice.

Second, the Microsoft Infrastructure considers NETID domain-based Integrated Windows Authentication as being in containment. This is because browser support for Integrated Windows Authentication (IWA) is extremely poor (Internet Explorer). If you can’t use Azure AD or Shibboleth, you are better off using Basic authentication against the NETID domain with HTTPS to protect the password in transit. So IWA is your choice of last resort. Basic over HTTPS is one step above IWA.

The Authentication service lists Shibboleth as its preferred web authentication solution, however, from a Windows server platform, it is not as nice as Azure AD. Both use federated authentication, with the server itself not handling the authentication process or credentials (e.g. a password). This is highly desired from a security perspective because it means that if your web application was compromised, they couldn’t get those credentials.

Shibboleth does not integrate with the Windows security model, which means you’ll need to design your own authorization mechanism. In contrast, Azure AD can integrate with the Windows security model which means you can use NTFS, groups, and other native Windows features.

If you do choose to develop a custom authorization mechanism, note that it may be a risky undertaking to use the NETID domain’s groups as your source of authorization information because of the privacy limitations.

Go to top of page

Where can I find NETID user accounts or groups? Will it always be in that location?

NETID doesn’t make any promises about where a given NETID 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.

That said, we do follow some practices which are apparent when examining the directory structure. But again, you shouldn’t assume these practices will always be followed.

Go to top of page

How do I get a Windows Server cluster setup in the NETID domain? I keep getting errors …

There are multiple paths to setting up a Windows Server cluster in NETID, and several key details you’ll want to make sure you’ve got correct. The cluster node object (CNO) is the master computer object for the cluster and typically is considered the “service account” within Microsoft tooling. Virtual computer objects (VCOs) are created for each server node in the cluster. These VCOs can be pre-created manually or automatically by Microsoft tooling–this is the key decision point in terms of the paths you can take.

A few key details to get right are:

  • ensure that you’ve got correct FQDN in the dnsHostName and servicePrincipalName attributes on the CNO and VCOs (that FQDN should not include netid.washington.edu and should resolve to the appropriate server(s)).
  • run cluster setup using an OU admin account that has local admin privileges on each of the server nodes
    • Provide fully qualified DNS names to all questions in the cluster setup (giving just the netbios name *WILL* result in failure)

The steps to follow are:

  1. OU admin creates CNO in their OU (this can be a special subOU or really anywhere in your OU)
  2. OU admin disables the CNO to allow the Cluster wizard to work correctly
  3. OU admin already has full control permissions on CNO (no action, despite Microsoft instructions)
  4. Decision point: Cluster wizard creates VCOs or pre-create VCOs.
    1. If you choose wizard creation, you’ll need to get UW-IT to add your CNO to your _computerjoiners role group.
      1. Send an email to help@uw.edu with “Please add my CNO to _computerjoiners role” along with the CNO’s name and the fact you are setting up a Windows cluster.
      2. After that change has been made, OU admin uses the Cluster wizard to create the VCOs. The Cluster wizard uses a hybrid of the OU admin and the CNO’s permissions to get things done.
    2. If you choose pre-create, you’ll need to add the right permissions to each VCO so the CNO can manage the VCOs. As a OU admin, you already have the ability to do this operation.
      1. Grant to the CNO the following 3 permissions: Reset Password, Validated Write to DNS Host Name, Validated Write to Service Principal Name. Consult Troubleshoot Cluster service account – Windows Server | Microsoft Docs if you need a step-by-step on how to do that.
      2. OU admin can use the Cluster wizard to create the clustered role with a client access point that matches the prestaged VCO name, and bring the resource online.

These steps are outlined at Prestage cluster computer objects in Active Directory Domain Services | Microsoft Docs, but of course, some of the details don’t represent the delegated OU permissions and a few of the details documented aren’t quite accurate (e.g. that doc claims step 4b1 should be full control, but Troubleshoot Cluster service account – Windows Server | Microsoft Docs contradicts it).

If you are trying to setup a HyperV failover cluster, there may be more involved. In some cases, UW-IT has had to manually add SPNs to get a HyperV cluster working correctly. Ask us for help if needed.

Go to top of page

How do I get a SQL Cluster setup in the NETID domain? I know you’ve got a general cluster FAQ, but what about allowing the cluster services to manage the cluster node object (CNO)? Can you just grant me the ability to modify permissions?

SQL clusters generally can follow the same approach as noted above for Windows Server clusters. However, in the past we’ve run into scenarios where the SQL cluster tooling uses the permissions of a service account, not the CNO to determine what it can do. We don’t generally grant the ‘Modify Permissions’ permissions to user accounts, which are what those scenarios required. Granting that permission in AD allows almost anything to happen. We can make permission changes given a good business reason, so feel free to ask us for help if you run into this rare case.

If you have this need, please send help@uw.edu a request with the subject line “MI permissions needed for SQL cluster” along with your specific CNO, VCOs, and service account.

Go to top of page

Why do we have an expired cert for EFS, Encrypting File Services?

Any Customer is welcome to use EFS, but MI has created a filesafe to make sure that EFS is set up correctly for your OU. To use EFS, you absolutely need to create a Data Recover Agent (DRA), in the event you lose access to the files. MI is not providing that service. By leaving an expired cert in place, every customer that tries to enable EFS gets an error, which will keep them from enabling it without first deploying a Data Recovery Agent:

http://technet.microsoft.com/en-us/library/cc512680.aspx

You will need to create a group policy with a setting just like MI to deploy an EFS DRA & cert that covers *your* delegated OU (and *only* yours). Then you’ll be able to enable EFS anywhere* on computers under your OU. You are responsible for the file recovery, not MI.

Go to top of page

Who is licensed to use Microsoft SQL Server?

All UW licensing is restricted to computers owned by the UW. Microsoft SQL Server licensing is available to employees and students, via a substantially discounted enrollment in the Microsoft campus agreement through May 30, 2026. Beyond that date, the UW expects the costs to increase significantly beyond the ability for this product to be centrally funded. Customers using Microsoft SQL Server will likely have to pay for their use at that point. Customers are encouraged to explore migrations to Azure SQL before that time.
Go to top of page

How can we use RDS (Remote Desktop Services) in the NETID domain?

RDS is the new acronym for Window Terminal Services, i.e., running Terminal Servers for your OU customers. If you would like to do this as an OU admin, build your RDS server and place it in the NETID domain. Next, apply for ‘Elevated Directory Access’ via the below form:

Elevated Directory Access Form

Based on that info, your server will be put in the built-in *group* for Terminal Server Licensed Servers, managed by Group Services.

NOTE: If your RDS server is managed by the Standard Managed Server service, then that service team will take care of getting your RDS server this access–no need for you to request this access.

Go to top of page

Who can use RDS or Windows Virtual Desktop?

RDS with Windows Server:

The Windows Server license provides 2 administrators to connect via Remote Desktop. The user must be administrators to leverage this special 2 RDS connection capability.

For normal users to make use of Remote Desktop Services to Windows Server, you must install the RDS role, and have one RDS CAL available for each user. RDS CALs are assigned via a RDS licensing server associated to the Windows Server running RDS. There is a 30 day grace period for RDS CALs per user, after which they are unable to connect.

Students are not covered for RDS CALs under the UW campus agreement–only UW employees are. Obtaining RDS CALs for students would require a purchase and some mechanism to get the purchased licenses allocated to the RDS licensing server–which involves entering an agreement code specific to your purchase.

To get RDS CALs for employees or others, you can contact UW-IT Software Licensing via help@uw.edu.

RDS with Windows workstations:

Note: A personally owned Windows workstation is outside the scope of this.

In general, the primary user of a Windows workstation is entitled to use RDS to connect to that Windows workstation as part of the Windows workstation license.

If the user who is using RDS to connect to a Windows workstation is not the primary user, e.g. because the computer is a shared computer in a computer lab, then a Windows Virtual Desktop Access (VDA) license is required. The UW has VDA licenses included in UW Microsoft Student and UW Microsoft Advanced service levels, generally provided for employees and students on UW-owned computers.

RDS to a virtually hosted Windows workstation:

A virtually hosted Windows workstation uses similar technology but requires a different level of licensing: the Windows Virtual Desktop Access (VDA) license. The UW has VDA licenses included in UW Microsoft Student and UW Microsoft Advanced service levels, generally provided for employees and students on UW-owned computers.

Azure Virtual Desktop is a Microsoft cloud-hosted solution in this category and you can read more about it

Go to top of page

How can we use DFS (Distributed File System) in the NETID domain?

Please see our DFS service offering page

Go to top of page

Last reviewed April 1, 2022