You can use NETID user accounts for login on either computers in domains trusting NETID or with standalone computers connecting to computers in domains trusting NETID. The use scenarios listed below are common scenarios that we expect clients will employ in taking advantage of the NETID domain across a trust.
Domain with Computers
General description: You manage a local (departmental) Windows domain which contains computers (machine objects) to which you wish to control access via interactive logon. You would request a (one-way) trust of the central domain. Your users would be able to logon using their UW NetID and “central” password. Once logged in, they can use appropriately shared resources within your domain.
To make this scenario work, after getting a trust there are a couple key steps you’d need to make:
- Configure the “logon locally” and “access this computer from the network” user rights to allow the appropriate NETID user accounts access.
- Reconfigure any group policy within your domain that might apply to users. This might include both “User configuration” settings (see loopback processing mode above), as well as specific group policy settings that grant or restrict permissions to users or groups.
For the more specific case of this scenario where you manage a computing lab, you may want to either restrict logon access using the uw_students@netid.washington.edu affiliation group or employ selective authentication.
For an example of the group policy changes you might employ to enable this scenario, check out this example group policy. Keep in mind that some of these group policy settings should be applied domain-wide (lmcomptability), while the rest can be applied to just portions of your domain, i.e. to just specific OUs. The logon script specified in this sample GPO, might include things like a command to map the user’s home directory, e.g. “net use h: \\yourServer\%username%”
You may want to review the FAQs:
How do I configure my workstation so I can login interactively with my NETID user account?
This scenario might co-exist with the Domain with Resources scenario, so check it out too.
Domain with Resources
General description: You manage a local (departmental) Windows domain which contains resources (file systems, print servers) to which you wish to permit access. You would request a (one-way) trust of the central domain. Your users would be able to perform a network logon to the resource(s) using their UW NetID and “central” password. The workstations your users have would NOT need to be members of your (or, indeed, any) domain.
To make this scenario work, after getting a trust there are a couple key steps you’d need to make:
- Configure the “access this computer from the network” user rights to allow the appropriate NETID user accounts access.
- Reconfigure any group policy within your domain that might apply to users. This would include specific group policy settings that grant or restrict permissions to users or groups.
- ACL any shared resources to allow the appropriate NETID user accounts access.
You may want to review the FAQs:
How do I make use of NETID groups across a trust?,
How do I configure my workstation so I can login interactively with my NETID user account?,
How do I limit access to a share or folder to students in a particular course?,
How do I limit access to a Web page to just faculty and staff?
This scenario might co-exist with the Stand-alone Windows Workstation scenario, so check it out too.
Stand-alone Windows Workstation
General description: You have NO local domain, but manage one (or more) “stand-alone” Windows work station(s). You would be able to use resources made available by others (see cases #2 and 3 above) but would not be able to use the central domain directly since you are not “sharing” any resource.
To make this scenario work:
- The user needs to know to provide their NETID credentials when they try to access a domain resource that is ACL’d accordingly.
Stand-alone server
General description: You have NO local domain, but do have a stand-alone Windows (or equivalent) server providing shared file systems or other resources. For the first phase of this project you would not be able to share resources using the central domain. To share resources during the first phase they must be contained within SOME domain. You might be interested in using Managed Workstation services. In the future, it might be possible to organize such services under an “organizational unit” (OU) within NETID.
Contact help@u.washington.edu if you are interested in either joining a computer to NETID via Managed Workstation services.
Group Policy Settings
Several group policy settings are of general interest in using NETID, and are referred to in the Common Use Scenarios section.
- If you would like to apply user-based policy across forests (either via domain or forest trust), then you must enable this setting:
computer configuration/administrative templates/system/group policy/allow cross-forest user policy and roaming user profiles
- If you would like to apply user-based policy based on the group policy associated with the computer that any users logs in with, then you should enable this setting:
computer configuration/administrative templates/system/group policy/user group policy loopback processing mode
A value of “replace” indicates that the user settings defined in the computer’s group policy objects replace the user settings normally applied to the user.
A value of “merge” indicates that the user settings defined in both the computer and user’s group policy objects are applied. The computer’s group policy objects win in cases of conflict.
- To avoid problems with NETID’s LMCompatibility settings, you should set:
computer configuration/security settings/local policies/security option/network security: LAN Manager authentication level = Send NTLMv2 response only\refuse LM & NTLM
There are implications to making this change. There are other values that are compatible with UWWI. See KB823659 item 10 for Microsoft detailed information about this setting.
For additional information on the LmCompatibilityLevel setting, and a walk through, see the FAQs:
How does the authentication mechanism get chosen? What’s the LmCompatibilityLevel setting?
What should my LmCompatibilityLevel settings be?Failure to have the correct LmCompatibilityLevel can result in these problems:
I can login on some computers but not others. Why is this happening?
I can login with my NETID user account, but I can’t access resources on a server even though I’ve granted that account access. What’s wrong?