Skip to main content
IT Connect

Information technology tools and resources 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.

What is a WINS server and is there a central service?

WINS stands for Windows Internet Name Service. A WINS server holds mappings from a NetBIOS name (the name of your computer in the Network Control Panel) to your computer’s IP address. If you want other people to access your computer without knowing the fully qualified DNS name across subnets, then using the same WINS server is the solution. Using a WINS server also helps improve the quality of the browse list seen in Network Neighborhood. DNS name resolution is superior, but requires the person to type in a fully qualified DNS name in order to reference your computer.

Because the client resolution order for NT4 clients first checks for NetBIOS resolution before DNS resolution, larger NT4 domains often opt to implement a WINS server to improve domain performance. Windows 2000 clients use DNS resolution before NetBIOS resolution. Windows 2000 clients version of the Network Neighborhood, My Network Places, has an improved browse list (over NT4) with a common WINS server implemented.

In the past, the UW has not supported WINS campus-wide. Some departments have informally used the UW-IT WINS servers to avoid running WINS themselves. With the advent of MI, these UW-IT WINS servers are considered part of the Microsoft Infrastructure service and supported as such. You do not need to be in a domain that trusts MI to use these services. However, UW-IT only plans to provide WINS services as long as needed to support MI. Microsoft has indicated it plans to remove all reliance on NetBIOS resolution in future versions of Windows.

WINS support is required for domain migration. Common WINS servers for all machines in the domain throughout the migration are very important to retain resolution.

The IP addresses for the centrally supported WINS servers are 140.142.1.6 & 140.142.13.229.

Go to top of page

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. This is documented here: http://www.netid.washington.edu/documentation/delegPerms.aspx.

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