Services and the NETID Domain

Last updated: October 3, 2024
Audience: IT Staff / Technical

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.

Can Sharepoint be run in the NETID domain? Or run cross-forest with the NETID domain?

Microsoft SharePoint Server can be installed on a MI domain-joined computer but the SharePoint User Profile Synchronization Service cannot be enabled.

The User Profile Synchronization Service (UPSS) keeps SharePoint user profile information synchronized with the corresponding NETID Active Directory user attributes. UPSS is Microsoft Identity Manager (MIM) under the covers and requires an elevated privilege in AD, the “Replicating Directory Changes” permission. This setting circumvents the ACLs that have been put in place to implement FERPA protections of sensitive student data. SharePoint will leak this FERPA-protected data. See Course Group Privacy Configuration for more information. There are also hundreds of thousands of user accounts in the NETID AD. You certainly don’t want to synchronize all of those accounts to your SP server.

The best option is to not install SharePoint Server yourself. UW-IT offers SharePoint Online for campus customers. Please refer to the Service Catalog entry.

If you do opt to install your own instance of SharePoint Server on a NETID domain-joined server, then please follow these instructions for turning the UPSS off.

  1. After SharePoint is installed, go to Central Admin and chose Manage Services on Server.
  2. Now stop the User Profile Synchonization Service. Do not stop the User Profile Service!

There are alternative ways that you can populate user profile data. When a user logs into SharePoint they can click their name in the upper right-hand of the SP window and choose “Edit Profile.” This will create a profile if it didn’t already exist. The user can then fill in the fields that they wish to share with their colleagues.

In addition, you can use PowerShell to create profiles. If you had, say, a spreadsheet of your potential SP population, you could export it as XML or CSV and use that as input to the PowerShell script to create profiles. Here is a TechNet article on doing this PowerShell scripting.

You can use a combination of these two methods: pre-populate and/or update profiles using PowerShell, and have new users self-provision their profile.

Note: the Sync Service may not start at all if its service account doesn’t have the “Replicating Directory Changes” permission. Consequently you are likely to see SP errors related to this. However, the User Profile Service (UPA) will run and do what it is intended to do. Do not turn on off the User Profile Service.

Should I use Entra ID, Shibboleth, 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.

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. If you can’t use Entra ID 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.

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

Reference the following guide when choosing your identity provider:

Web applications can be integrated with UW NetIDs and the UW Groups service via a variety of methods, including Entra ID and UW Shibboleth. UW Shibboleth and Entra ID are both generally recommended.

Guide to which UW Identity Provider your web application should prefer:

Web app … UW Entra ID UW Shibboleth
requires use of SAML or OIDC

X

X
requires use of WS-Federation or WS-Trust protocols

X
requires the OAuth protocol

X
requires integration with Office 365 or other Entra ID apps

X
requires user provisioning via the SCIM protocol

X
has an Entra ID application gallery template

X
requires support team access to app sign in logs

X
requires custom terms of use

X
requires Research and Scholarship category support

X
requires custom IdP metadata

X
requires multilateral SAML federation

X
requires support for social identities such as Facebook

X
requires broadest possible set of identity providers

X
requires better user experience via sign in only when required

X
requires group claims for member-private groups

X
requires claims involving confidential data

X
requires simple conditional access controls such as:

-group membership
-IP address

X

X
requires advanced conditional access controls including:

-location (IP, GeoRegion, or GPS)

-device platform

-client application

-client device state

-sign in risk

-application specific restrictions

X
requires stronger fraud protections such as:

-behavior analytics to flag risky signs in such as: atypical travel, unknown/suspect locations, patterns matching known compromised account signatures

-detection of publicly leaked credentials

-high volume of daily security signals

X

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. SQL Server licensing includes software assurance, but does not include extended security updates for products beyond Microsoft’s support lifecycle.
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