NETID user accounts have limitations which IT Administrators may need to be familiar with. This document explores those limitations.
Limitations Imposed by Policy
There are several limitations imposed by MI Policy. These include:
- Creation via UW NetID system only
- Passwords follow UW NetID standards
- Appropriate use for the type of UW NetID
- Some account details are restricted due to regulatory concerns. You can find which by reading the list of managed attributes on NETID users
- NETID user account details are overwritten by automated processes from systems of record
- Kerberos delegation can be used with personal UW NetIDs only
- When the delegation account is a NETID user account, approval is needed
Limitations Imposed by Architecture
There are limitations imposed by architecture which may change over time. These include:
- Name attributes follow a complex logic which leaves only employees and students with flexibility
- Whitepages publish flag controls some visibility
- Whitepages data flow to NETID users has a 15 minute latency
- Applying user group policy requires loopback group policy, because all NETID users are in a single OU
- Managing Windows-centric user attributes requires adding these attributes to the UW NetID Support Dashboard functionality, see NETID User Support
Limitations Imposed by Lack of Solutions or Interest
- There are likely user attributes for which there is existing institutional data which NETID is not currently provisioning. And we aren’t provisioning that data, because you haven’t expressed interest in it so we can prioritize it. So please contact us and ask.
Further Discussion
You might wonder why we don’t simply just put users into department-based OUs. The answer to that question comes from the fact that there isn’t good institutional data around department affiliation, there isn’t even a registry for “official” UW departments, and then there’s the pesky problem of users which have multiple departmental affiliations. It’s very rare for a university of any size to have a central AD with users split into multiple OUs because these problems are pretty common.
Several departments have crafted workaround solutions which address the needs behind some some common user attributes. These workaround solutions have been documented and are generally useful.
However, we have also provided some management functionalities for user attributes. The approach we’ve taken leverages the user’s consent that your department provides their IT support. See NETID User Support for more details. Currently, only a handful of NETID user attributes are manageable via this functionality, but more NETID user attributes can be added upon request.