This document includes explanations relevant to delegated OU scenarios in the NETID domain. We welcome suggestions as to additional questions that should be added to this document.
NOTE: The Services and the NETID domain document has content about services you may wish to run in your delegated OU.
- What can I do with a delegated OU? Why should I use it? What are the benefits?
- What groups don’t I want to use anymore?
- What things should I be aware of if my existing departmental domain has trusts to another domain?
- My existing departmental domain has a password policy. How can I use the NETID domain without that?
- How do I recover local admin privs on a computer in a delegated OU?
- Can OU Admins create arbitrary users in their delegated OU? Don’t UW NetIDs cost money?
- Can UW NetIDs for people not formally affiliated with the UW, like visitors, be created?
- Aren’t UW NetIDs limited to 8 characters? Doesn’t that mean NETID users are limited?
- When do the NETID user accounts for students go away? How do I deprovision access to our computers?
- Can a user have more than one support org? Can IT staff be assigned to more than one support org? Can students choose support orgs?
- How do I create Group Policy Objects for users? Can I edit GPOs? Are there any GPO restrictions?
- How can I keep my Windows Firewall rules current or be aware of changes to UW campus IP ranges?
- What if we need help with a delegated OU outside business hours?
- Can we still get audit data? Can we find out who added a user? How about notification of user compromise?
- How do we find out when an employee leaves the university or changes departments and incorporate it into our OU?
- We need a temporary extension on these automated affiliation processes. How do we go about that?
- If we want to write our own scripts to modify user settings, is this supported?
- What group namespace do we use?
- As domain administrators, can you agree to not give yourself access to files without notifying the legally authorized users?
- Can NETID users and groups be used as SQL server logins?
- Will you support Read Only Domain Controllers?
- I don’t seem to be able to create a GPO in our delegated OU. I right-click on the OU and go to properties, Group Policy, and get an error: Access denied. Is this not the way to create GPOs in our delegated OU?
- How do I get mycomputer.netid.washington.edu registered in DNS?
- How do I get my computer’s DNS name correctly configured in the NETID domain?
- How do I use group policy to set primary DNS suffix?
- After trying to fix my DNS suffix value, upon boot some of my computers report the following error: “The security database on the server does not have a computer account for this workstation trust relationship.” What should I do?
- Why can’t I use my Admin UW NetID with the Groups Service? How do I administrate groups that need a higher level of security?
- What is recommended for a service account for an application running in NETID Active Directory?
- What is the order of group policy processing?
What can I do with a delegated OU? Why should I use it? What are the benefits?
The primary benefits to using a delegated OU are:
- Your department doesn’t need to run separate domain controllers and buy additional MS external connector licenses for those DCs
- Your department doesn’t need domain controller management expertise
- Your department doesn’t need to manage Windows user accounts and passwords
- Your department can collaborate on Windows services with the entire UW NetID population
- Your users will have fewer login prompts
- Your Windows administrators can more easily collaborate with other UW Windows administrators
- Provides a Windows domain environment which is securely run
Put succinctly, delegated OUs allows the UW to remove Windows domain silos, share and reduce costs, and more easily share successes.
What groups don’t I want to use anymore?
Windows supports a number of groups with membership functionality that is dynamic in nature. Microsoft sometimes calls these groups “Well-known SID” groups. Some of these group’s dynamic functionality is tied to the users and computers in your domain, based on the assumption that everyone in your domain is “trusted”. In moving from a departmental domain with computers and users numbering less than 10,000 to a university-wide domain with computer and user numbers on a much larger scale, the meaning of some of these groups changes to the point that you do not want to use them anymore to secure departmental resources. They’d still be fine to secure resources for all the UW, but not for departmental resources.
In specific the following groups may be problematic for departmental resources:
- Domain Users
- Domain Computers
- Authenticated Users
In the NETID domain context, Domain Users and Authenticated Users are almost synonymous. Authenticated Users possibly includes additional users, such as computer local or federated users. You should replace references to Domain Users with a group representing your department. In particular, you should pay attention to who has membership in your computer’s local Users group.
MI has provided a OU scoped workaround solution for Domain Computers. See Delegated OU Computer Groups.
What things should I be aware of if my existing departmental domain has trusts to another domain?
If your existing departmental domain has trusts to another Windows domain, you should carefully plan how you will transition collaboration with that other Windows domain after moving into a delegated OU.
Trusted domains
The NETID domain does not trust other domains, so any domain you currently trust will not be available as an authentication (and authorization) choice. However, any user in that other domain should either have an existing user account in the NETID domain based on their UW NetID, or have the ability to get a UW NetID and therefore a NETID user account. The trick is identifying those accounts and transitioning them to NETID users. You can make that transition prior to moving any computers into the NETID domain.
Trusting domains
You’ll need to work closely with the administrators of Windows domains that trust your departmental domain to transition authorization to any other their resources from your existing departmental domain user accounts (and groups) to NETID user accounts. And if that other Windows domain doesn’t currently have a NETID trust, you’ll need to first convince them to get a trust.
My existing departmental domain has a password policy. How can I use the NETID domain without that?
Password policies are designed to decrease the likelihood that someone else can compromise your user account by guessing your password. But by themselves, password policies do not make a Windows domain secure, so they are not a magic bullet to becoming secure. In fact, the traditional idea of a forced password policy has in recent years increasingly been considered an ineffective security measure, and even the US federal government appears poised to remove that practice from its guidelines.
The NETID domain depends on the UW NetID service for its user accounts and passwords, so within the NETID domain there’s not really a choice to implement a password policy. The NETID domain can’t provide the benefit of being the Windows domain with UW NetID accounts and passwords while separately managing those user accounts and passwords–that’s a contradiction. So a password policy is really an issue for the upstream UW NetID service.
Existing UW NetID password policy does not require forced password changes for any UW NetID population. However, some share a desire to see UW NetID password policy change in the future. Because of the widespread impact on end users, changing something like UW NetID password policy will require careful consideration. If you’d like to see UW NetID password policy change, you can share this desire with UW-IT.
How do I recover local admin privs on a computer in a delegated OU?
The simplest and most direct method is to leverage group policy. Create a new OU and move the computer you are locked out of into this new OU. Create a group policy object, and set the following setting on it:
Computer Configuration/Policies/Windows Settings/Security Settings/Restricted Groups/Administrators=NETID\u_msinf_delou_<delegatedOU>_ouadmins
Then either wait for the group policy to refresh or reboot the computer. You should then be able to login to the computer.
Alternatively, you can download a copy of the P. Nordahl boot disk (or one of many variants) and use it to reset the local administrator password. With a known local administrator password you can login. This method takes a bit more skill, and can be more dicey since these tools aren’t guaranteed to work, and could result in a non-working system.
One scenario where these approaches will not work is if you’ve added your computer to the NETID domain without following the proscribed method. In those cases, members of NETID\u_msinf_delou_<ou-name>_computerjoiners should be able to extract the computer from the Dagobah swamp the computer finds itself in.
Can OU Admins create arbitrary users in their delegated OU? Don’t UW NetIDs cost money?
The NETID domain leverages the UW NetID system–you want a NETID user account, you get a UW NetID. The UW NetID system is funded via the technology recharge fee, with no additional cost for a sponsored UW NetID.
A lot of the basics around the UW NetID system are covered at http://www.washington.edu/itconnect/accounts/, including a link to http://www.washington.edu/itconnect/accounts/sponsored.html which covers how to sponsor a personal UW NetID for someone, as well as a link to Shared UW NetIDs.
By leveraging the UW NetID system, we aren’t duplicating effort, we’re enabling re-use of the same identity in multiple services. The NETID user creation happens milliseconds after the initial UW NetID password is set, so there’s no latency downside to leveraging the UW NetID system.
Can UW NetIDs for people not formally affiliated with the UW, like visitors, be created?
Yes, you can do this. At http://www.washington.edu/itconnect/accounts/, you’ll find a section entitled “UW NetIDs for Visitors” which should address any needs you have.
Aren’t UW NetIDs limited to 8 characters? Doesn’t that mean NETID users are limited?
Yes and no. The constraints are by type of UW NetID. So a personal UW NetID is restricted to 8 characters. Most shared UW NetIDs also have an 8 character restriction (but there are several kinds of Shared UW NetIDs which do not have that constraint). Admin UW NetIDs are restricted to 13 characters. In general, UW NetIDs can’t be more than 128 characters, and a couple of the UW NetID types do allow that length. See https://wiki.cac.washington.edu/display/infra/UW+NetID+Namespace for gory details.
When do the NETID user accounts for students go away? How do I deprovision access to our computers?
Personal UW NetIDs are issued for life (and beyond). Currently, only a few UW NetIDs like Admin UW NetIDs, prospective students (didn’t enroll), and clinicians are automatically deprovisioned.
So a student retains their UW NetID indefinitely, as does anyone else who has gotten a UW NetID. Because the NETID domain leverages the UW NetID system, that generally means a student’s NETID user account remains indefinitely. However, the NETID domain also has user lifecycle management based on inactivity. To get more details, read about NETID User Inactivity.
There are also cases where any particular UW NetID might be abandoned and deleted, but these aren’t typically because of a change in affiliation. And in cases of known or suspected password compromise, we do disable access until identity re-vetting can occur. Identity management is different than access management, i.e. authentication isn’t authorization. This is why you’ll see encouragements not to use netid\domain users or netid\authenticated users for access control within a delegated OU. In terms of access control within your OU, you’ll want to closely examine the Groups Service features. Features that may be of high relevance are course groups, “automatic” employee groups derived from department appointment data, student major groups, student curriculum groups, and using the dependency group function to automatically have members removed when they are no longer in an affiliation group.
Can a user have more than one support org? Can IT staff be assigned to more than one support org? Can students choose support orgs?
The workflow here is:
- you get a support org
- you invite your users to choose your support org
- your users choose your support org
- for those users which choose your support org (and for which you are a designated IT staff), you can view their UW NetID settings and manage some subset of those settings
Any UW NetID can be invited to choose your support org, regardless of the person’s affiliation or the type of UW NetID.
A UW NetID can choose more than one support org. Only the user can remove a support org they have chosen/added.
IT staff can be assigned to as many support orgs as needed.
Over time and with greater adoption, the UW NetID Support Tool will gain capabilities.
How do I create GPOs for users? Can I edit GPOs? Are there any GPO restrictions?
Loopback processing is needed if you want to apply user settings via group policy. Computer settings don’t require loopback. You can freely create group policy objects, provided you follow the naming rules. You do need to remember to delegate management of GPOs you create to your gpadmins group. You must only edit GPOs via the latest group policy management tool. You shouldn’t assign another OU’s GPO to your OUs.
More on creating Group Policy objects in the NETID domain
How can I keep my Windows Firewall rules current or be aware of changes to UW campus IP ranges?
There exists a text file \\netid.washington.edu\SYSVOL\netid.washington.edu\scripts\CampusIpRanges.txt that can be referenced. This includes the current UW campus IP subnet definitions. There is also sample PowerShell code in the text file to help you edit an existing GPOs to define Windows Firewall rules using these IP ranges.
More on creating Group Policy objects in the NETID domain
What if we need help with a delegated OU outside business hours?
Breakfix types of issues for critical business processes such as NETID user account provisioning and password changes result in an engineer being paged 24/7/365.
As you might imagine, the level of support provided depends on how critical the needed support is. So things that are basic services that lots of people rely on get immediate attention, and will result in the right personnel getting called/paged to address the problem. And where possible, we’ve made critical components redundant, e.g. there are 4+ NETID domain controllers. Things that are one-time planned events like requesting a new OU or setting up a domain trust are not 365/24/7 support events–i.e. they are typically not break-fix work, and the email generated by those forms clearly specifies that expectation.
If you have planned work outside business hours which requires UW-IT involvement, let us know, and we’ll can talk about coordinating our availability.
If things break or don’t work as you expect, so sometimes you need to escalate an issue to someone with more privileges, and you need a response as soon as possible. When that happens after business hours, the right thing to do is to call UW-IT operations (206-221-5000). They have the ability to contact engineers and/or escalate to the UW-IT duty manager.
If there are specific situations you are worried about, missing permissions you think we could additionally delegate, or features that could alleviate concern here, we’d love to talk more about that.
Can we still get audit data? Can we find out who added a user? How about notification of user compromise?
On a computer in a delegated OU, you have access to the security audit logs on your computers just as you do today in another Windows domain. This allows you to audit all access to your computers or created a computer local user.
UW-IT is responsible for AD level auditing. So we can tell who created a NETID user (which should always be the UW NetID agent) or deleted a group (which should always be the Groups agent). If you’d like to audit AD activity, like tracking who is creating/deleting OUs, then that’s something we’ll need to talk about. In terms of eDiscovery kinds of requests that require NETID user account logon info, we’d handle reporting on when that user logged in and from where (if location info is available).
UW-IT Security Operations handles UW NetID compromise events, so if you discover a compromise, you should notify them. Standard practice for a UW NetID compromise event within UW-IT is to disable access to services and change the password until UW-IT can re-vet the user’s identity and then re-establish a password and access to their services.
How do we find out when an employee leaves the university or changes departments and incorporate it into our OU?
This is a deep and complicated topic, so understand that this response is really just a simplified overview.
There are two pieces of data of interest in this question: departmental appointment and affiliation i.e. does this person have officially recognized relationships with the University? The NETID domain publishes affiliation via affiliation groups and the eduPersonAffiliation values on NETID user objects. For example, my NETID user account has:
eduPersonAffiliation (4): employee; staff; member; alum;
memberOf(x): uw_employee; uw_staff; uw_member; uw_alum;
meaning I’m an employee, which also makes me a staff and a member, and I also happen to be alum. The affiliation groups are very useful for access control dependent on specific affiliation values.
If I lost my job or left, the employee, staff, and member values would all be removed. Employee affiliation is lost at the 2nd pay period after termination date. For students, to simplify what happens, student affiliation is removed within 90 days after the relationship is terminated.
In addition these two examples, affiliation flows to many other UW-IT managed systems and governs what services are provided. To expand on this:
- having a UW NetID doesn’t necessarily mean you get any computing services with it,
- having an active affiliation does tend to automatically permit you for some services,
- there are better ways to integrate an application/service with affiliation status
Departmental appointment data doesn’t yet have as rich of a story behind it here at the UW. This is partly because a lot of the HR data around departmental affiliation isn’t very accurate. However, some options are available and likely more in the future. As an example, the Groups Service partnered with the Enterprise Data Warehouse to create a “My People” report which allows departments to craft reports using appointing financial information and other data. These “My People” reports can then be turned into groups with automated membership. Several departments have used this approach, and this has provided a positive feedback loop that has resulted in HR data improvements.
We need a temporary extension on these automated affiliation processes. How do we go about that?
That depends on what mechanism you are using to grant access. If, for example, you leverage uw_employee to control access to a resource, then if you need the ability to grant exceptions based on some local business logic, then you can nest uw_employee in some group you control, and add your exceptions to that group, maintaining the exceptions either manually or automatically via the Group web service API. If you have some other mechanism in mind, please let us know and we can discuss it in more detail.
If we want to write our own scripts to modify user settings, is this supported?
Yes and no. It really depends on what you mean by user settings. Here’s a rough outline.
By user settings I think you mean configuration settings that stay with a user on the same computer. And you can definitely apply user settings via group policy objects leveraging loopback processing. That’s encouraged. And the one nice thing here is that you know that those user settings are only being applied on the computers you manage–not any other computer that user might logon to.
I wouldn’t typically think you meant AD user attribute values here, but maybe you did. In general, currently you can’t really use scripts/programs to modify AD user attribute values. There are some exceptions you might get at if you were clever, but most of those exceptions aren’t really that interesting. So currently in general, this isn’t encouraged. However, we do provide support for AD user attribute values for those AD user attributes which we maintain.
We definitely see bulk changes to AD user attributes as a gap in our offering, and we plan to address that. In terms of support, we don’t plan to offer any support to OUs on group policy troubleshooting of user settings. We will spend a nominal amount of time if asked for help–if nothing else providing ideas for troubleshooting. And if a group policy problem appears to be with the domain or a domain controller, then we’ll definitely take ownership of that.
What group namespace do we use?
Don’t get the group namespace confused with your NETID domain computer namespace–it isn’t the same thing, although it might share a substring in common.
Where you put your groups is up to you, and is a function of the Groups service. You might want to follow the “Learn more about groups” link from the home page of the groups service. In particular, the Groups Service Basics page and from there the UW Groups Naming Plan page are relevant to this.
As domain administrators, can you agree to not give yourself access to files without notifying the legally authorized users?
The MI policy statement addresses this. From /tools-services-support/it-systems-infrastructure/msinf/design/policy/:
“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
•logins SHOULD be limited to a small number of trusted computers
•where possible, additional authentication factors SHOULD be used
•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 Microsoft 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, EXCEPT for documented exceptions or by agreement of the MI service manager
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 SHOULD result in a notification to UW administrators.”
If this isn’t sufficient, we can discuss further what is needed.
Can NETID users and groups be used as SQL server logins?
Yes.
Will you support Read Only Domain Controllers?
Maybe. There are a lot of variables involved in this question, including cost recovery, operational support, bandwidth considerations, developing an AD site architecture, etc. This would definitely need to be something discussed in a lot more detail. We aren’t opposed to this, but we also don’t have an already developed solution, nor do we yet know whether we’d get prioritization approval to develop one. If enough folks wanted something like this, then the resulting priority should result in an offering.
I don’t seem to be able to create a GPO in our delegated OU. I right-click on the OU and go to properties, Group Policy, and get an error: Access denied. Is this not the way to create GPOs in our delegated OU?
It sounds like you are trying to use an old, unsupported method to create and modify group policy. Using Active Directory Users and Computers to create/modify group policy is no longer supported. Please use the Group Policy Management Console from Windows 7 or Windows Server 2008 R2 (or whatever the latest OS and GP management tool is). Not using the latest group policy editor will cause corruption and/or inconsistently applied group policy settings. Really–we’ve seen it many times. This is covered in the OU Practices document.
How do I get mycomputer.netid.washington.edu registered in DNS?
You don’t. You can’t use a DNS suffix of netid.washington.edu with your computers; we reserve that for MI provided services.
Instead you should continue to use whatever DNS zone you currently use, unless it’s a workstation and you want to use the DDNS service we provide. See /tools-services-support/it-systems-infrastructure/msinf/ous/add-computer/#compNameGuidelines for a good summary of all the computer naming guidelines.
See the next question for tips on how to get your computer’s DNS name correctly configured.
To find a list of all your computers which have are incorrectly using a DNS suffix of netid.washington.edu, you can search the root of your delegated OU with a LDAP search suffix of (dnshostname=*.netid.washington.edu).
How do I get my computer’s DNS name correctly configured in the NETID domain?
See the prior question about how you can’t have a DNS suffix of netid.washington.edu on your computers. /tools-services-support/it-systems-infrastructure/msinf/ous/add-computer/#compNameGuidelines has a good summary of all the computer naming guidelines.
For all the guidance in this FAQ, use an account that has local admin privs & full permissions on the AD computer object. This will be an account that is a member of u_msinf_delou_<yourOUhere>_ouadmins or u_msinf_delou_<yourOUhere>_computerjoiners.
The manual way to get your computer’s DNS name correctly configured is to make sure that it is correctly configured prior to joining it to the domain, and to ensure that the ‘Change primary DNS suffix when domain membership changes’ setting is not enabled.
NOTE: If you do not uncheck ‘Change primary DNS suffix when domain membership changes’ you will not end up with a correctly configured computer.
So four step process if you aren’t yet joined to the domain:
- Uncheck ‘Change primary DNS suffix when domain membership changes’
- Change primary DNS suffix to a value that is NOT netid.washington.edu (e.g. clients.uw.edu)
- Reboot
- Join domain (please follow the domain join guidelines)
See the pictures below if you are unfamiliar with any of these steps. This zip file has a PowerShell script called doNotChangeDnsSuffixWhenDomainMembershipChanges.ps1 to automate #1.
NOTE: If you skip the reboot after changing your DNS suffix, and you are running Windows 7, then a bug will cause your computer to be misconfigured and in need of repair after the domain join. You’ll then need to repeat this process again.
If you have already joined the computer to the domain, and it’s in a misconfigured state, then you’ll need to fix that. The below snapshot takes you through the UI steps on a Windows 7 computer–other Windows OSes will be similar but slightly different.
The steps are:
- Go to the System control panel
- Click the ‘Change settings’ button
- On the ‘Computer name’ tab, click the ‘Change’ button
- This will open the ‘Computer Name/Domain Changes’ dialog
- If you are joining the computer to the domain, click the ‘Domain’ radio button and fill in ‘netid.washington.edu’ in the text box
- Click the ‘More’ button
- Set your primary DNS suffix
- Uncheck the ‘Change primary DNS suffix when domain membership changes’ setting
How do I use group policy to set primary DNS suffix?
Your OU’s group policy administrator can set the following setting:
Computer Configuration
|__Administrative Templates
|__Network
|__DNS Client
Dynamic Update: Enabled
Register PTR Records: Disabled
Register DNS records with connection-specific DNS suffix: Enabled
Connections Specific DNS Suffix: clients.uw.edu
Primary DNS suffix: clients.uw.edu
That configuration will work if you choose clients.uw.edu as your DNS zone. If you have another DNS zone you’d like to use, then you may need to remove some of the above settings if your DNS zone is not DDNS.
After trying to fix my DNS suffix value, upon boot some of my computers report the following error: “The security database on the server does not have a computer account for this workstation trust relationship.” What should I do?
This problem is known to happen with Windows 7 when you change the DNS suffix at the same time as you join the domain. The problem can also be a side-effect of having SQL Server on the computer. There seems to be some other cause that we haven’t been able to isolate yet.
If you find computers with this error, the cause is that the computer is unable to use Kerberos to authenticate itself. Kerberos fails because the fully qualified domain name (FQDN), i.e. netbiosname + DNS suffix, doesn’t match a servicePrincipalName value on the computer account. At some point, there was a failure of the computer to update its AD computer object dnsHostname and servicePrincipalName values. For example, pot-broken thinks it’s FQDN is pot-broken.clients.uw.edu. But its AD object looks like this:
Dn: CN=pot-broken,OU=pot,OU=Delegated,DC=netid,DC=washington,DC=edu
dNSHostName: pot-broken.netid.washington.edu;
servicePrincipalName (6): TERMSRV/pot-broken.netid.washington.edu; RestrictedKrbHost/pot-broken.netid.washington.edu; HOST/pot-broken.netid.washington.edu; TERMSRV/POT-BROKEN; RestrictedKrbHost/POT-BROKEN; HOST/POT-BROKEN;
The fix is to manually update the dnsHostname and servicePrincipalName values. Any member of your OU’s ouadmins or computerjoiners group is authorized to implement such a fix. If SQL Server is running on the affected computer, be sure to stop it before trying this fix.
For your convenience, we’ve written a PowerShell script to make this easier.
import-module activedirectory
$compsToFix = Get-Content c:\bin\compsToFix.txt
foreach ($comp in $compsToFix) {
$dnsHostname = “$comp.clients.uw.edu”
$oldDnsHostname = “$comp.netid.washington.edu”
set-adcomputer -identity $comp -ServicePrincipalNames @{Remove=”HOST/$oldDnsHostname”}
set-adcomputer -identity $comp -DNSHostName $dnsHostname
set-adcomputer -identity $comp -ServicePrincipalNames @{Add=”HOST/$dnsHostname”}write-host $dnsHostname
}
This script does the minimum required to remove the error, it doesn’t fix all the broken servicePrincipalName values. You may want to revise this script to address those, or may want to manually fix those values.
To use this script, create a text file at c:\bin\compsToFix.txt. Include a list of all computers with the error, separated by a carriage return/line feed (i.e. one computer on each line). Run the script from any domain joined computer in a local Administrator elevated PowerShell window using an account in ouadmins or computerjoiners.
Why can’t I use my Admin UW NetID with the Groups Service? How do I administrate groups that need a higher level of security?
The NETID domain isn’t the Groups Service, but we get this question a lot because we leverage the Groups Service and Admin UW NetIDs.
Admin UW NetIDs are provided to enable separation of risk in environments where there isn’t any other way to provide separation except via a separate identity. The Windows environment is a good example of that. Web applications aren’t a good example of that. With a web application, you can provide separation of risk via additional access controls, e.g. by requiring a 2-factor step-up challenge.
So it’s always been the intention to enable stronger access control in the Groups Service via personal UW NetIDs and 2 factor, not by enabling everyone to have a 2nd identity in the Groups Service. This feature is in the Groups Service backlog (jira.cac.washington.edu) as something folks could vote on (thus indicating that it should have an increased priority).
It isn’t yet clear when this capability will be added, but there is a recently developed prototype of this capability around (and working). There are lots of questions about how to implement this the right way (many details), so it may or may not be available in the near future, but it does have some recent attention.
What is recommended for a service account for an application running in NETID Active Directory?
Within the NETID domain there are a diversity of options for a service account. There are the options provided by the UW NetID service, which include Shared UW NetIDs and Application UW NetIDs. There is also the NETID domain only option of a group managed service account (gMSA).
We recommend gMSAs when the OS and application permit. This is because among those options, it clearly has the best security profile and provides the best management capabilities. Obviously, since it is NETID domain only, it isn’t portable outside the NETID domain environment, but because you really shouldn’t re-use a service account for multiple uses, we don’t see this as relevant. You can read more about how you can self-provision a gMSA and other details at our Group Managed Service Accounts Info page
Should a gMSA not fit your scenario, we’d recommend an application UW NetID next. However, that option isn’t fully supported by the UW NetID service, so is only available in limited cases. Application UW NetIDs have some expected practices and policy associated with them that make them more suitable than a Shared UW NetID. Should neither of the other options work out, a Shared UW NetID is a fine solution. You can find out more about those at the Shared UW NetID page