How to Use the UW Windows Infrastructure for Windows Authentication
The UW Windows Infrastructure (UWWI) provides automatically-provisioned Windows
user accounts (hereafter referred to as UWWI user accounts) that correspond to UW
NetIDs.
After successfully obtaining a trust and
configuring your Windows domain-based resources with the appropriate access controls,
you will be able to tell clients to login with UWWI user accounts to obtain access
to those resources.
Before making use of the UWWI, you'll need to:
- Determine what kind of trust you'd like to obtain. Please refer to the "Trust Relationships" document for the issues
surrounding the kind of trust to use.
- Understand the landscape of UWWI, which
will primarily consist of familiarizing yourself with the automatically
provisioned users accounts and groups.
- Take note of
the security, privacy and service limitations and plan for
these limitations accordingly.
- Understand the implications
of using a trust.
- Review ways you might use UWWI.
-
Implement access controls (ACLs) and security settings
needed.
- Tell your users.
NOTE: Unfortunately, at this time, the UW Windows Infrastructure (UWWI) service
does not allow management of the user directory objects. This means that neither
Windows administrators nor users themselves can set user-specific properties like
the user profile path or home directory. Some user settings can be set via group
policy settings. This issue is at the top of the list of deliverables for future
projects focused on UWWI--most other enhancements require that this problem first
be solved. Future projects have not been funded at this time, but are under consideration.
Account Provisioning
Account provisioning for UWWI is handled by custom account/password infrastructure
system called kiwi that is used by several UW Technology run systems to maintain the perceived
unity of the UW NetID. This means that all UW NetID changes are propagated to UWWI
in near real-time. Account creation, name changes, password changes, and some limited
metadata all comes via this kiwi provisioning mechanism.
Because kiwi "owns" this set of functionality, users can not directly
change their UWWI user account password. Instead, users must use the existing UW NetID
password change mechanisms in order to change their passwords.
Group Provisioning
In addition to the kiwi system, some enterprise groups contained in
the GDS directory are automatically provisioned in UWWI. There are generally
4 types of group information in GDS, they are:
Standard groups are basic groups--nothing fancy about them. There are a couple of
these in GDS that won't come straight over into UWWI as is. Those groups correspond
to ones that have computers as members. Since AD will only allow member values that
correspond to actual entries in AD, those members can't be added. There are less
than 5 groups that fall into that category, and their membership will simply be
missing those computer members. There are about 150 standard groups today, and most
of them correspond to UW Technology departments or groups used by UW Technology for access control.
These groups come from feeds from other source systems. In the future, there may
be some adhoc web form that allows people to create/maintain these groups. You can
talk to the GDS folks via the link on the webpage above about getting groups into
GDS. An example name of a standard group (as represented in UWWI) is:
gds.Departments.C&C.ITI.DS.All
Within GDS, the "gds." part of the name is not prepended. We've prepended it in
UWWI to help avoid namespace collisions later when we expect that UWWI might allow
group creation for organizations that opt to reside within UWWI.
Privacy groups aren't in UWWI today, but may be sometime in the future. They are
standard groups but with an option to keep the group membership private. There is
only one of these groups in GDS today.
Course groups correspond to courses that students enroll in. Their membership is
private. Course groups have lots of bits of info associated with them including:
displayName (the course title), uwYear (the year offered), uwQuarter (quarter offered:
SUM|SPR|WIN|AUT), uwSln (the decimal number in the catalog for this course), uwCurric
(the departmental discipline), uwCrsNo (the course level number), uwSectID (the
section), uwInstructor (the instructor(s)), and of course the members. Within UWWI,
the members include the enrolled students AND the instructor(s). Within GDS, students
and instructors are kept separate, and there is no "member". An example
name of a Course group (as represented in UWWI) is:
2005SUM-PSYCH101A
Within GDS, there is no nice name that uniquely identifies courses, so this is completely
a construction of our own. GDS uses the uwRegID as the unique name. uwRegID's are
long hex strings that are not particularly nice for consumption in ACLs. :)
Affiliation groups are groups that represent the eduPersonAffiliation values associated
with each person. There is a known number of affiliation groups that is unlikely
to increase very rapidly. The affiliation groups are:
- gds.uw-affiliate
- gds.uw-alum
- gds.uw-employee
- gds.uw-faculty
- gds.uw-member
- gds.uw-staff
- gds.uw-student
These groups have a huge number of members and have wide use across a variety of
scenarios.
Students, faculty, and staff are just what you'd think: all UW NetIDs with an active
kerberos subscription and those respective affiliations.
Member is intended to include faculty, staff, student, and other persons with a
basic set of privileges that go with membership in the university community (e.g.,
they are given institutional email and calendar accounts). It could be described
as "member in good standing of the university community."
Employee is intended to include people who are active faculty or staff.
Alumni is intended to include people who have some active relationship with the
university (i.e. at least one other affiliation) and were students in the past.
Affiliates are people with a UW NetID with an active kerberos subscription, not student,
staff, or faculty, and some relationship to the university.
All these groups (all four types) are universal groups to maximize their potential
outside the forest. Universal groups can be placed in universal groups or domain
local group in an external domain/forest or be used directly on resource ACLs on
computers in an external domain/forest.
Only course groups and privacy groups have restrictions on reading the member attribute.
Additionally, you won't be able to view the memberOf attribute on any user except
yourself.
For detailed examples of how to make use of UWWI groups, see these FAQs:
How do I make use of UWWI groups?
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?
Security Settings and Limitations
Please refer to the
UW Windows Infrastructure Policy Guide.
Implications of Using a Trust
Generally speaking, there are three categories to consider when you add a trust
to your domain or forest: security implications, issues tied to forest trusts, and
use of groups via a trust.
Security Implications of a Trust
When you create a trust between your domain and an external domain, some of the
scope of built-in groups change. This carries with it implications for who can access
resources. The implications are primarily for one built-in group: 'authenticated
users'. 'Authenticated users' is a dynamic group whose membership represents all
users in trusted domains. The use of 'Authenticated users' in Microsoft default
ACLs has waned with each major product release. However, 'authenticated users' is
included by default as a member of the local 'users' group, which gives it wide
ranging access that can include the ability to logon locally and read quite a bit
of data. You may want to remove that group membership if you don't want all UWWI
users accounts to have that level of access.
Domain controllers need to support a wider range of users and include more use of
'authenticated users' in default ACLs. We don't recommend changing the default ACLs
on domain controllers.
Another security implication to the trust is the authentication method used. The
authentication method is tied to the type of trust. Domain trusts are only capable
of NTLMv2 or NTLMv1 authentication (in general, they are capable of LM too, but
UWWI doesn't allow that). Forest trusts are capable of Kerberos authentication,
but can also use NTLMv2 and NTLMv1 (again, they can use the other methods, but UWWI doesn't
allow them). Each of those authentication methods comes with a set of security assumptions
that you may want to consider.
Forest Trust Issues
If you've chosen to use a forest trust to UWWI, then there are some user
interface adjustments that
you need to understand. Microsoft has a Knowledge Base article (KB816467)
that tersely describes these issues. In summary, the issues are:
- The domain drop-down list available at interactive login will not
necessarily have the trusted domain listed (it is if your domain is the
forest root domain), meaning that in order to authenticate to the
trusted domain users will have to fully qualify their username, e.g.
"NETID\barkills" or "barkills@netid.washington.edu"
- using the built-in Object Picker to browse and identify users/group
may not work as it does for objects in your forest, and within the
Object Picker you may need to fully qualify users/groups, e.g."NETID\barkills"
or "barkills@netid.washington.edu"
Use of Groups via a Trust
You may want to add UWWI users or groups to your domain groups.
This diagram shows the valid possibilities. Lines in blue indicate group
membership possibilities. Lines in red indicate ACL possibilities. Only the Forest
A-Domain X (AX) column shows all intra-domain possibilities, the interaction between
AX and BY shows cross-domain plus cross-forest possibilities and the interaction
between BY and BZ shows cross-domain, intraforest possibilities.
Take care to note that the ONLY group type in your domain/forest can contain groups
from another forest is a domain local group.
Common Use Scenarios
At this time, you can't join computers to UWWI, but we imagine a day when this will
be encouraged. Until that time, you can still use UWWI user accounts for login on
either computers in domains trusting UWWI or with standalone computers connecting
to computers in domains trusting UWWI. The use scenarios listed below are common
scenarios that we expect clients will employ in taking advantage of the UWWI service.
In the future, more scenarios may be added as they are imagined or as the UWWI service
expands its functionality.
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 (e.g., via "control-alt-delete"). 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 UWWI 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 gds.uw-students@netid.washington.edu
affilation group or employ
selective authentication as described in the
trust request documents.
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 UWWI 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 UWWI 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 UWWI user accounts access.
You may want to review the FAQs:
How
do I make use of a group in UWWI?,
How do I configure my workstation so I can login interactively with my UWWI 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 UWWI 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 Nebula services. In the future,
it might be possible to organize such services under an "organizational unit"
(OU) within UWWI.
Contact help@u.washington.edu if
you are interested in either joining a computer to UWWI via Nebula services.
Group Policy Settings
Several group policy settings are of general interest in using UWWI, 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 UWWI'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 UWWI user account, but I can't access
resources on a server even though I've granted that account access. What's wrong?