This document answers basic questions a user might have about topics related to the Microsoft Infrastructure. We welcome suggestions as to additional questions that should be added to this document.
- How can I remotely access my Windows computer?
- I recently changed my name. Why hasn’t my new name shown up in the NETID domain, the Exchange Address Book, Sharepoint, Sharepoint Online, OneDrive for Business, Skype for Business, or our Azure AD tenant?
- Why can’t I see what groups my friends and co-workers are in?
- My password doesn’t seem to work. How can I fix this?
- I changed my UW NetID password but only my old password works on my computer at home. What is going on?
- How do I configure my workstation so I can login interactively with my NETID user account?
- 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?
- What should my LmCompatibilityLevel settings be?
- 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?
How can I remotely access my Windows computer?
One option is Windows file sharing. All Windows computers (from Windows 3.11 for Workgroups on) are capable of sharing files with other Windows computers. This means that any networked Windows computer should be able to access a file share on another Windows computer, if the user has the proper access permissions to the file share. There are a few things you need to do to make it happen, and several provisos that you should consider. Windows operating systems since Windows 2000 have file sharing built in by default, whereas earlier Windows OS’ need an additional piece of software installed to enable this functionality. In a nutshell, one creates a file share, and then grants both share permissions and NTFS permissions to the appropriate folks.
If the computer being used to access the shared resources is not part of a domain, then you will need to specify a NETID user after you attempt to access the file share. You’ll get a login challenge, for which you’d respond:
Connect As: netid\UW NetID
This assumes that the computer with the shared resources belongs to a domain that trusts the NETID domain.
Another possible option is called Terminal Services or Remote Desktop, depending on the Windows operating system. One uses a simple client software, called a RDP client or terminal services client to remotely connect to the remote Windows computer. The connection gives you an identical graphical interface to your computer as if you were at the console.
There is one last option with Windows Terminal Services, which may be very useful to people who travel and want to use an Internet cafe to access their Windows computer. Awhile ago, Microsoft released the Terminal Service Advanced Client, which contains an ActiveX control that Internet Explorer on a Windows client can use to connect to a Terminal Server. By placing this ActiveX control on a webserver, you only need a browser, and a URL to a special webpage to be directed to your remote Windows computer. There are more details about this functionality on the Microsoft website.
I recently changed my name. Why hasn’t my new name shown up in the NETID domain, the Exchange Address Book, Sharepoint, Sharepoint Online, OneDrive for Business, Skype for Business, Teams, or our Azure AD tenant?
Most UW NetIDs can control their name via the Preferred Name capability. Changes to your public directory information (like name, department, campus mail box) aren’t propagated in real-time. The updates to that information take the following path:
- Identity.uw.edu -> UW-IT Microsoft Infrastructure MIM server – this part of the data flow takes about ~20-30m
- MIM processing – this part takes ~1.5h on average
- NETID Active Directory replication – this part takes 15-30m
- Azure AD Connect -> Azure AD – this takes ~30m
- Office application directory – this takes 5m-5h
NOTE: The sync process from #4 to #5 is provided by an undocumented system Microsoft is solely responsible for, which occasionally has problems.
When you change your password using the Manage Your UW NetID site, you skip steps #1 & 2 in the above noted data flow.
Some applications cache directory information like names and only update them occasionally. For example, Outlook has an Offline Address Book which by default is only updated once daily. Teams sometimes needs you to sign out and sign back in to reflect updated identity information. You can also try the steps documented here: https://www.canr.msu.edu/news/clearing-the-cache-for-microsoft-teams.
If you had more than one personal UW NetID which were merged to a single personal UW NetID, this can result in a known problem to your name in Microsoft applications. Contact UW-IT for assistance in resolving this.
There are considerably more details documented about what to expect for the name associated with an account.
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. You can contact us if youhave a legitimate business need to gain access to that information, such as an application that needs to integrate with our infrastructure.
How do I configure my workstation so I can login interactively with my NETID 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 accompanying 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 administrators 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.
My password doesn’t seem to work. How can I fix this?
We’ve seen some rare cases where a password for the NETID domain can end up out of synchronization with your UW NetID. 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 Microsoft 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 NETID domain. You can find out how to check and fix that here.
I changed my UW NetID password. Only my old password works on my Windows computer at home, but the new password works with Office 365. What is going on?
The process to change a UW NetID password is documented here: https://itconnect.uw.edu/tools-services-support/access-authentication/uw-netids/about-uw-netids/#passwords. That procedure results in an update to the corresponding NETID Active Directory user password. This works in all situations. The UW NetID account and password is used for access to UW Office 365 services, so any UW NetID password change immediately would affect any subsequent interactive sign in to UW Office 365.
Windows computers which are joined to Active Directory (AD) rely on network connectivity to AD for their authentication. When a Windows computer does not have network connectivity to AD, it uses cached credentials–a locally cached & hashed version of your password at the last time the user signed into the computer when network connectivity to AD was present. If your AD user password changes while a computer doesn’t have connectivity to AD, then you must use the older password because the locally cached credentials are based on the older password. If, after initial sign in to your computer which does not have connectivity to AD, you try to connect to services which rely on the AD user account for access (e.g. a Windows file server), you will be challenged to provide your existing AD user password. This is because the cached credentials are only accepted by the local computer–no other computer will accept them. This is how Active Directory joined computers have worked for 20+ years–there is nothing new about this experience.
There are four things you can do about having a Windows cached credential which is based on your old UW NetID password:
- Get your device directly on the UW network & sign in. The network connection could be via an ethernet connection or wireless directly connected to the UW network–not a network provided via some other provider.
- Use a Windows ‘Network Sign-in” compliant VPN at Windows sign in. This requires a number of things to come together:
- You need a VPN solution homed on the UW network which is capable of supporting Windows sign in. Husky OnNet is NOT capable. The Managed Windows VPN is–see https://uw.service-now.com/sp?id=sc_entry&sys_id=8a9c2321db9ab348d6a77a8eaf9619d5&sysparm_category=ced37caddba2bf40d6a77a8eaf9619f3 for more on how to get it.
- You’ll need the VPN client setup on the Windows device
- At Windows sign-in, you’ll need to sign in to Windows via the VPN. An example of the user experience can be seen in the Autopilot documentation. Go to /tools-services-support/it-systems-infrastructure/msinf/aad/device/intune/autopilot/setup/, click ‘Setting up a device with Autopilot’, and scroll down to #7. The first screenshot shows the Windows sign in page and points to an icon which is used to trigger the VPN sign in experience. The 2nd screenshot shows the installed VPN clients. You sign in to the VPN which also signs you into Windows.
- Because your device connects to the VPN first, your Windows sign in is able to contact AD and you’ll get a fresh cached credential saved to the device.
- Change your UW NetID password enough times that you can cycle back to your original password
- Continue using your old password at Windows sign in
After changing your UW NetID password, you may get a Windows taskbar notification about updating an account. This notification is likely your Azure AD device registration (see /tools-services-support/it-systems-infrastructure/msinf/aad/authn/help/background/#deviceReg), which most versions of Office running on Windows require to allow Azure AD sign in. You will be directed to the ‘Access Work or School’ Windows setting to update your Azure AD account password. So to summarize, this notification happened because your UW NetID password was changed, which resulted in your AD user password changing, which resulted in your Azure AD user password changing, so Windows wanted to get a new Azure AD refresh token to reduce future Azure AD sign-ins to applications like Office 365.
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 NETID domain. You are probably seeing an error of “unknown user name or bad password.” See What should my LmCompatibilityLevel settings be?
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?
It is likely that your LM compatiblity settings are not compatible with the NETID domain. You are probably seeing an error of “access denied.” See What should my LmCompatibilityLevel settings be?
What should my LmCompatibilityLevel settings be?
Having an LM Compatibility level that is high helps ensure that your password is protected in a manner that will prevent others from getting it. You can fix that your self using this document.
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 administrator, see more detail here.
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 NETID domain. 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.
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.
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 “uw_student” in the text box. Click Check Names. Click OK. The Security tab should now show NETID\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\uw_student if that is the only group that needs access to this share. Granting access directly to the universal group netid\uw_student is generally regarded by Microsoft Curriculum to be bad form. Microsoft recommends that you first nest netid\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).
How do I limit access to a Web page to just faculty and staff?
We recommend that system administrators and developers read /tools-services-support/it-systems-infrastructure/msinf/other-help/faq/services-and-netid-domain/#windowsWebAuthN. This answer assumes a less than optimal solution, as noted on that page, however, with extra work parts of this can be used with the optimal solution.
This answer assumes that the Windows computer with with the web server is part of a domain that trusts the NETID domain. 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 “uw_employee” in the text box. Click Check Names. Click OK. The Security tab should now show NETID\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 not the best choice available. If you use basic authentication, you must require SSL encryption. With extra work you can use parts of this with Azure AD.
Instead of using uw_employee, you could certainly have used uw_faculty and uw_staff.