UWWI FAQ - Common Problems and Scenarios (draft)
In addition to explanations of basic Windows technology, this document also includes
explanations relevant to the more complex cross-forest scenarios that are relevant
here at the UW. We welcome suggestions as to additional questions that should be
added to this document.
What can I do with UWWI? Why should I use it? What are the benefits?
The primary benefits to using the UW Windows Infrastructure are:
- Access to automatically provisioned Windows user accounts and passwords that correspond
to all active UW NetIDs
- Access to automatically provisioned Windows groups that correspond to University
affiliations (e.g. student/staff/faculty) and course groups
These benefits translate into higher-level benefits like:
- The ability to provide Windows-based services to clients outside one's existing
Windows domain
- The ability to provide Windows access controls in ways that previously required
a data feed from the Student Registrar or UW Technology
- The ability to collaborate via the Windows platform with people outside your immediate
domain without adding any domain trusts except to the UW Windows Infrastructure
- The ability to use built-in Windows authentication and authorization for web-based
applications as an alternative to Pubcookie and a manual authorization process
For example, you can grant access to files shared on your server to anyone in the
university, and regardless of where their computer lives (in an untrusted domain,
at home, in your domain) they can provide their UW Windows Infrastructure credentials
and gain access to those files.
The
common use scenarios section of the How to Use the UW Windows
Infrastructure document talks about the things you can do with
the UW Windows Infrastructure. There are also a few basic examples of uses within
this FAQ document.
Go to top of page
I recently changed my name. Why hasn't my new name shown up in the UW Windows
Infrastructure?
Right now, changes to your public "directory information" (like your name, department,
campus mail box) isn't propagated in real-time. The UW Windows Infrastructure
updates that information when your account gets created, and updates it every time
you change your password. To force an update of your name and directory information,
change your password using the Manage Your UW NetID site.
Go to top of page
I've recently changed my affiliation with the University - why aren't I in the right
affiliation-based groups?
While your affiliation information is contained in a different system, it's refreshed
and updated on the same 'schedule' as your directory information. The UW Windows
Infrastructure grabs your affiliations when your account is created and each time
your password is changed. To update your affiliations, the best way is to
change your password using the Manage Your UW NetID website.
Go to top of page
I used to be able to see what groups my friends and co-workers were in. Why
can't I now?
In order to provide schools and departments across campus with access to the course-based
groups, we needed to devise a way to allow use of the group without providing the
ability to see who was in the group. This information is protected by federal
legislation - the Family Educational Rights and Privacy Act, or FERPA. By
locking that down, it also prevents you from casually browsing your friends' group
memberships. System administrators can
contact us if they have a legitimate business need to gain access to that
information.
Go to top of page
How do I configure my workstation so I can login interactively with my UWWI user
account?
To find out what users and groups have the ability to login interactively to your
workstation, launch "secpol.msc". This will bring up the Local Security Settings.
On the left, open the Security Settings, open the Local Policies, open the User
Rights Assignment. On the right, you should see a policy named Logon on Locally.
The accompaning security setting tells you want users and groups can log into your
workstation interactively. It is often the case that you will see Administrators
listed. This corresponds to the local adminstrators group on your workstation. You
can view what users and groups are members of the local administrators group by
launching "compmgmt.msc". This will bring up Computer Management. On the left, open
Computer Management (local), open System Tools, open Local Users and Groups, open
Groups. On the right, double-click on Administrators. You should see a list of all
the members of this group. If you don't see NETID\yourUWNetID listed, then it's
likely that you need to add it. Click on the Add button. A Select Users, Computers,
or Groups window will appear. Click on the Locations button, select netid.washington.edu
from the Locations window and click OK. In the text box, type your UW NetID. Click
on the Check Names button. Click on the OK button. Now try to login again.
If your workstation is in a domain, it's possible that the "logon locally" user
right is controlled by your domain administrators via group policy. If this is the
case, you can talk with them about this issue.
Go to top of page
My password doesn't seem to work. How can I fix this?
We've seen some remote cases where a password can end up out of synchronization
with the rest of the UW NetID world. A good place to start troubleshooting
is to change your password using the
Manage Your UW NetID site. Changing your UW NetID password will make
sure the UW Windows Infrastructure has the most recent one.
Another possible solution is that you haven't granted your UW NetID authorization to login interactively
on the computer you are trying to login to. How to do that
is described here.
Another possible issue is that your LM compatiblity settings are not compatible
with the UW Windows Infrastructure. You can find out how to
check and fix that here.
Go to top of page
I can login on some computers but not others. Why is this happening?
It is likely that
your LM compatiblity settings are not compatible with the UW Windows Infrastructure. You are probably seeing an error of "unknown user name or bad password."
See What should my LmCompatibilityLevel settings be?
Go to top of page
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?
It is likely that your LM compatiblity settings are not compatible with the UW Windows
Infrastructure. You are probably seeing an error of "access denied."
See What should my LmCompatibilityLevel settings be?
Go to top of page
What should my LmCompatibilityLevel settings be?
Having an LM Compatibility level that is high
helps ensure that your password is not protected in a manner that will prevent others
from getting it.
If your workstation
is in a domain, it's likely that your LM Compatibility level is set by the domain
administrators via group policy. You should talk with them
about this issue. If you are the domain adminstrator, see below for more detail.
If your
workstation is a standalone workstation, you can check and change the LM Compatibility
level by using regedit.exe and navigating to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel.
If that registry value does not exist under the LSA key, then select the LSA registry key. In the
Edit menu, choose New Dword Value. Give the new registry value a name of LmCompatibilityLevel. Double-click
on this new registry value, and enter either 3 or 5.
More detail:
For the simplest scenario where you are just trying to interactively
login to a Windows computer, you should ensure that your computer has a LM Compatibility
Level of 3 at least ("Send NTLMv2 response, accept LM, NTLM, NTLMv2"). A level of 5 ("Send NTLMv2 response
only/refuse LM & NTLM") is optimal from a security perspective, but may cause
problems if your workstation needs to interact with domain controllers other than
the UW Windows Infrastructure and they are not running at level 5. We suggest you
set a level of 3 initially, and test a level of 5 as time allows.
The group policy setting:
computer configuration/security settings/local policies/security option/network
security: LAN Manager authentication level
is where you can set the LM Compatibility level via group policy. We suggest you
set this group policy setting at the domain level. This ensures that all your computers
will benefit, and also ensure that there are no incompatible mismatches within your
own domain.
Go to top of page
How do I make use of UWWI groups?
There are two ways to make use of groups in an external forest, as noted in this
diagram. You can either:
The first option of nesting the group in a domain local group is the Microsoft recommended
method of applying authorization that many Windows administrators will recognize
from Microsoft Certified Training Curriculum. In other words, users in global or
universal groups, the global/universal group in domain local or computer local groups,
the domain/computer local group applied to the resource. There are many reasons
for this, but the best one we've seen is when you go to do a domain migration. This
method simplifies things tremendously.
Adding a group from UWWI to a domain local group in your domain is fairly simple.
Here are the steps required:
- Create the domain local group. Using Active Directory Users and Computers, choose
select the container where you'd like to locate the new domain local group.
- In the
Action menu, select New, select Group.
- In the resulting 'New Object - Group' window,
fill in an appropriate and meaningful name, select Domain Local in the Group Scope
section, and ensure that the Group Type is Security. Then click OK.
- Add the UWWI group. Open the properties of the domain local group.
- Select the Members
tab. Click the Add button.
- In the resulting 'Select Users, Contacts, Computers,
or Groups' window, click the Locations button.
- In the resulting 'Locations' window,
select netid.washington.edu and click OK.
-
If you know the name of the group you want to add, type it in, and click the Check
Names button.
- You will likely be prompted to enter a user account and password with
permissions in netid.washington.edu. Use your uwnetid and password. If the name
you typed exists in UWWI, then it will resolve, otherwise a 'Name Not Found' window
will guide you through the process of choosing another group name. Once you've got
a resolved group name, click OK twice more.
-
If you don't know the name of the group you want to add, in the 'Select Users, Computers,
Or Groups' window click the Advanced button. Use the resulting 'Select Users, Computers,
Or Groups' window (yes, this is a second window with the same name) to query the
netid.washington.edu domain for the group you are looking for.
As an example, let's
say you know you want to add a Math course group from the Autumn quarter of the
academic 2006/7 year, but you've forgotten the course number and suspect you would
be able to pick it from a list. The
groups section of the How to
Use UWWI for Windows document tells you the naming format of
course groups in UWWI. Armed with that knowledge, you can search for groups with
a name that starts with '2006AUT-Math'. This will give you a list of all the Math
courses offered that quarter to pick from. Select it and click OK. And click OK
twice more.
Go to top of page
How do I limit access to a share or folder to students in a particular course?
This answer assumes that the Windows computer with file content to share is part
of a domain that trusts the UW Windows Infrastructure. It also assumes that there
is already a file share created.
There are two parts to controlling access to a file share. The first part involves
the share permissions. The second part involves the NTFS permissions. Both permissions
are required.
Open the Management Tool:
Launch "compmgmt.msc". This will bring up Computer Management. If the local computer
you are on is not the computer with the file share and content, then in the left
pane, right click on Computer Management (local) and select Connect To Another Computer.
Type the name of the computer with the file share in and click OK.
Share Permissions:
When you have Computer Management focused on the computer with the file share, in
the left pane, open System Tools, open Shared Folders, open Shares. In the right
pane, double-click on the share to open its properties. Select the Share Permissions
tab. If the Share Permissions lists either Everyone or Authenticated Users with
allow Full Control, then you don't need change the Share Permissions and you can
move onto the NTFS permissions section. If neither of those dynamic groups is granted
full control, then click the Add button. Type Authenticated Users. Click OK. Select
Authenticated Users in the Share Permissions tab. Click allow Full Control. Click
OK to approve your Share Permissions change.
NTFS Permissions:
When you have Computer Management focused on the computer with the file share, in
the left pane, open System Tools, open Shared Folders, open Shares. In the right
pane, double-click on the share to open its properties. Select the Security tab.
Click the Add button to bring up the Select Users, Computers, or Groups window.
Within this window, click the Locations button to the launch the Locations window.
Within this window, select netid.washington.edu and click OK. Back at the Select
Users, Computers, or Groups window, type "gds.uw-student" in the text box. Click
Check Names. Click OK. The Security tab should now show NETID\gds.uw-student is
allowed Read permissions. If you would like to grant more permissions do that now.
Click OK when you have granted the appropriate set of permissions.
More detail for Windows administrators:
This description includes two choices that may not follow best practices in order
to simplify this description. Granting share permissions to a wider group than necessary
is poor security practice, and it would be better to only grant netid\gds.uw-student
if that is the only group that needs access to this share. Granting access directly
to the universal group netid\gds.uw-student is generally regarded by Microsoft Curriculum
to be bad form. Microsoft recommends that you first nest netid\gds.uw-student within
a domain local group, then nest that domain local group in a local group on the
computer it will be used on and finally use this local group in all ACLs (share
and NTFS).
Go to top of page
How do I limit access to a Web page to just faculty and staff?
This answer assumes that the Windows computer with with the web server is part of
a domain that trusts the UW Windows Infrastructure. It also assumes that there is
already a website with content. It also assumes the use of IIS.
Open the Management tool:
On the computer with the web server, launch "%SystemRoot%\system32\inetsrv\iis.msc"
to bring up the Internet Information Services (IIS) Manager. Select the website
you would like to grant access to faculty and staff.
Check the Authentication protocol:
Right click on the website and select Properties. Select the Directory Security
tab. Click the Authentication and Access Control Edit button to bring up the Authentication
Methods window. Select Integrated Windows Authentication. See more detail on this
choice below. Click OK twice.
Set IIS permissions:
Within the IIS Manager, within the website, find the file or directory that you
want to grant access to staff and faculty. Select this file or directory. If this
is the entire website, select the website. Right click and choose Properties. If
you selected just a file, then now you should select the File tab. If you selected
a directory, then now you should select the Directory tab. If you selected the website,
then now you should select the Home Directory tab. Ensure that the appropriate IIS
permissions are granted. Read permissions are generally what is needed, but you
may wish to grant other permissions. Click OK.
Set NTFS permissions:
Within the IIS Manager, within the website, find the file or directory that you
want to grant access to staff and faculty. Select this file or directory. If this
is the entire website, select the website. Right click and choose Permissions. Click
the Add button to bring up the Select Users, Computers, or Groups window. Within
this window, click the Locations button to the launch the Locations window. Within
this window, select netid.washington.edu and click OK. Back at the Select Users,
Computers, or Groups window, type "gds.uw-employee" in the text box. Click Check
Names. Click OK. The Security tab should now show NETID\gds.uw-employee is allowed
Read permissions. If you would like to grant more permissions do that now. Click
OK when you have granted the appropriate set of permissions.
More detail for Windows administrators:
Integrated Windows Authentication is the most secure choice available, but may not
be an appropriate option because not all browsers and clients can use this authentication
method. Digest authentication encrypts the password over the wire, and is a good
next best option. If you must use basic authentication, UW Minimum Security Standards
requires that you require SSL encryption.
Instead of using gds.uw-employee, you could certainly have used gds.uw-faculty and
gds.uw-staff.
Go to top of page
Should I use Pubcookie or the UW Windows Infrastructure with IIS?
This is a complex question and deserves a bit of background. We recommend first
reading X if you aren't intimately familar with how authorization is connected to
authentication on the Windows platform.
Pubcookie can certainly do authentication, but for the Windows platform requires
that you write your own code to do the authorization. On the unix platform, there's
something called mod_uwa that will do authorization against GDS, the enterprise
groups directory. However, GDS has a limited set of groups in it at this time, which
primarily consists of course groups. If you wrote your own code to do the authorization
on Windows, on what can you base the decision-making within that code? You can snag
the uwnetid string that Pubcookie has. You could then compare that to ... GDS, the
enterprise groups directory? Only if GDS had groups that meant something to your
web application. Groups in your Windows domain? Why should you write something if
you could do this comparison without writing code and instead use native Windows
authentication and authorization?
By using the UW Windows Infrastructure for both authentication and authorization
for your web-based application, you eliminate the need to develop something yourself.
However, there is a catch: you have to carefully navigate a choice of authentication
methods for your webserver that your clients can successfully use, and ensure that
you don't violate the UW minimum computing standard of sending a password over the
network unencrypted. And this is a significantly meaty catch.
IIS provides 3 authentication methods you can toggle on/off independently of one
another. They are (in order of decreasing security):
- Integrated Windows authentication
- Digest authentication
- Basic authentication (i.e. cleartext)
Integrated Windows authentication is a funny conglomeration of authentication methods,
and is sometimes known as http-spnego. It negotiates the "best" mechanism among
it's available mechanisms that both client and server will accept. The available
mechanisms that this method can choose from are (in the order of preference):
For a Windows client (any Windows os after Win9x/ME), which of those 3 is negotiated
depends on what authentication methods are allowed in the domain of the client computer,
or if it isn't in a domain which is configured on the computer (by default all 3
are allowed).
For a non-Windows client, whether integrated Windows authentication will work depends
on the capability of the platform. Mac OS has the ability to get NTLMv2 tokens if
configured properly. Unix platforms have the ability to get a Kerberos ticket from
the netid.washington.edu kerberos realm. It's unclear if browsers on that platform
can use that ticket via htttp-spnego.
Which brings us to browsers. For the longest time, the only browser that would work
with http-spnego was Microsoft Internet Explorer. However, this has changed. Mozilla
has supported http-spnego since a beta of 1.72. Firefox and Safari also support
http-spnego. So if the users of these browsers have tickets then they should be
able to properly authenticate transparently.
Digest is the commonly understood authentication mechanism you can read about elsewhere
(e.g. in RFCs) that passes a hash of the password. Not good, but better than basic.
Basic authentication violates the UW minimum computing standards unless it is used
in connection with session-level encryption, such as https or ipsec. However, it
is the most widely supported authentication mechanism, and therefore the best choice
for a website that have an extreme diversity of clients and browsers.
So ultimately the answer to this question depends on your priorities. You have to
decide whether navigating these mechanisms is worth the elimination of development
of your own custom authorization mechanism. If you do choose to develop a custom
authorization mechanism, do take note that it may be a risky undertaking to use
the UW Windows Infrastructure's groups as your source of authorization information
because of the
privacy limitations.
Go to top of page