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 WS2008 failover cluster setup in the NETID domain? I keep getting errors …

The failover clustering setup formula for WS2008 in NETID is:

  • add failover clustering role to nodes
  • create cluster node computer object (CNO)
  • ensure you’ve got correct FQDN in the dnsHostName and servicePrincipalName attributes on the nodes and the CNO (that FQDN should not include netid.washington.edu)
  • run cluster setup using an OU admin account with local admin privileges to the nodes
    • Provide fully qualified DNS names to all questions in the cluster setup (giving just the netbios name *WILL* result in failure)

Alternatively you can follow the guidance at http://technet.microsoft.com/en-us/library/cc731002(WS.10).aspx which details the AD requirements for a failover cluster.

But the key is really making sure you’ve got a dnsHostName attribute on all the computer objects that is accurate–which should result in the SPNs being accurate and providing a FQDN everywhere.

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?

We don’t grant the ‘Modify Permissions’ permissions to anyone. Granting that permission in AD allows almost anything to happen. We will make permission changes given a good business reason such as the one you’ve got.

http://www.derekseaman.com/2013/09/sql-2012-failover-cluster-pt-4-cluster-creation.html has a pretty good summary of the overall process of setting up a SQL cluster, with that specific part of the series focusing on the AD permissions needed. The author of that blog post isn’t accurate in specifying what permissions are required as full control isn’t needed, just:
•Reset Password
•Validated Write to DNS Host Name
•Validated Write to Service Principal Name
as documented at http://support.microsoft.com/kb/307532.

So to enable the SQL cluster servers to manage the cluster node object, we would grant:
On sql-cluster-node:
Allow sql-server-1 & sql-server-2: Reset Password, Validated Write to DNS Host Name, Validated Write to Service Principal Name on this object

If you have this need, please send help@uw.edu a request with the subject line “MI permissions needed for cluster” along with a copy & paste of the above paragraph with sql-cluster-node and sql-server-1/2 replaced with your specific names.

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

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

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

Please see our DFS service offering page

Go to top of page