This document answers basic questions about Windows security. We welcome suggestions as to additional questions that should be added to this document.
NOTE: There are a number of security related questions covered in the End User Help FAQ.
- How does the Windows authentication mechanism work? And how does Windows authorization work?
- Are other types of authentication allowed besides Kerberos?
- How does the authentication mechanism get chosen?
- What’s the LmCompatibilityLevel setting and what do I set it to?
- How do I reconfigure NTLMv1 on my computer so it will work with the NETID domain?
- How does someone in my department get access to files on someone else’s computer in another department?
- Can I restrict everyone except members of my department from logging into our department’s workstations?
- How do we handle students who walk away from public workstations leaving themselves logged on? Can we set kerberos ticket lifetimes?
- How do I prevent users from running certain applications on my computers?
- How do I make use of NETID groups across a trust?
- How do I learn more about Active Directory Security?
- What is SDDL?
How does the Windows authentication mechanism work? And how does Windows authorization work?
Depending on the type of Windows login, you get a portion of your authorization along with your authentication. For an interactive login (what you do when you hit ctrl-alt-del), you get a login token that contains all your domain-based global and universal groups attached.
During the login process, you present a password to your workstation. Your workstation contacts the domain controller, negotiates an authentication mechanism, then in slightly different ways dependent on the mechanism, interacts with the domain controller to check if your password is correct. If it is, a login token of the type of authentication mechanism negotiated is issued you on your workstation.
Which authenticaton mechanism is used depends on a negotiation between your workstation and the domain controller. Specifically, it depends on the setting called the LmCompatibilityLevel. Read more about that here.
When you then try to access a remote resource, that login token (the interactive one) is passed to the remote server, like IIS, to perform a different kind of Windows login–a network login. As a user, you don’t see that login happening–unless it isn’t accepted. In the background, you as a user are passing your login token to the server and allowing the server to do a limited number of things with that token. One of those things is to examine the token for the domain-based global and universal group memberships. Another is to construct the other group memberships that you are entitled to. The other group memberships include domain-based local groups, computer-based local groups, and dynamic group memberships. These other group memberships must be constructed at the time of access because they are context specific–e.g. there are many possible domains/computers that you *might* access and so only those memberships are constructed when needed. The remote server then makes an authorization decision based on whether you possess a group or user principal that is allowed the “logon over the network” user right on that remote server. Then it makes another decision as to whether you possess a group or user principal that corresponds to an allow ACE in the ACL on the resource you tried to access.
So … authentication is tied to authorization in Windows. With Windows it’s not a one to one mapping, but it is inexorably mated together.
Are other types of authentication allowed besides Kerberos?
Yes, but it is limited. NTLMv2 authentication is allowed. NTLMv1, LANMAN and cleartext authentication are not permitted. We recommend that where possible Kerberos be used.
How does the authentication mechanism get chosen? What’s the LmCompatibilityLevel setting?
Which authentication mechanism is used depends on the configuration of your workstation and the domain controller. Specifically, it depends on the setting called the LmCompatibilityLevel. This setting determines which mechanisms are allowed to be sent and received. If the client and domain controller don’t share at least one mechanism in common, then authentication will fail, and appear in the security event log as “Unknown user name or bad password”. The authentication mechanism re-enters the picture later if you try to use the token you’ve been granted to access a resource on a server. At that point, if the server doesn’t allow tokens of the authentication mechanism you negotiated with the domain controller, then you will fail to access the server with an “access denied” error.
You may see problems like those described in the FAQ I can login on some computers but not others. Why is this happening? You may also see problems like those described in the FAQ 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 is wrong?.
What should my LmCompatibilityLevel settings be? describes how to set the LmCompatibilityLevel to a value that is optimal for the UW Windows Infrastructure.
How does someone in my department get access to files on someone else’s computer in another department?
This requires a small amount of coordination with someone who has the privileges to administer file shares on the destination computer. The administrator of the destination computer can either give a single NETID user account access or an entire group access to the shared files. Then the person in your department can provide their credentials to access the resource.
We also offer DFS, Distributed File Service, functionality that allows departments to publish their shared file resources in a hierarchical tree. This simplifies the process of getting to resources for users, while also providing the benefit of a static target “link” that clients know about, such that administrators can swap the backend server behind that link with relative ease and virtually no impact on clients.
Can I restrict everyone except members of my department from logging into our department’s workstations?
Yes. Windows has a grantable user right called “logon locally”. By default, the general “Users” group has this right. You can restrict this on a machine by machine basis to another group or account (via “local security settings” under administrative tools). You can also set this right via group policy on an OU-wide basis (so every machine in your OU is affected) or on a domain-wide basis. The group policy object for this setting is located under computer/windows/security/local policies/user rights/logon locally (& deny logon locally), and one designates the groups you want to give access (or deny access).
How do we handle students who walk away from public workstations leaving themselves logged on? Can we set Kerberos ticket lifetimes on our OU?
You can’t set Kerberos ticket lifetime on an OU basis, nor can you affect the ticket lifetime set on NETID users. Kerberos ticket lifetimes can only be set via a group policy object on a domain-wide basis–so the lifetime chosen for NETID user accounts is shared by all.
However, several alternatives would better address this situation. The Windows resource kit has a tool just for this situation called WinExit (winexit.scr). It is a screen saver which logs the current user off the computer after a designated time period. One designates an idle time, and then this tool kicks in. When it is launched, a window appears and a countdown (which you specify) begins. The logoff can be aborted by the user by clicking on a button within this window.
This option can be used by placing all your public workstation in an OU by themselves. This OU would need a GPO which enabled loopback group policy editing (so you could set the important settings based on the machine and not the user). The machine GPO would be a combination of a registry key modification, and a software installation (the tool). Additionally, the GPO would have several user settings under user/admin/control panel/display to designate the right options, including the screensaver activation time, etc.
There are public workstations where the activity doesn’t keep the screensaver from being triggered. For example, playing a movie or musical recording via the CD/DVD drive doesn’t prevent the screensaver from being triggered. These exception cases can be handled a couple ways. One would be to specify their machine accounts as exceptions to the GPO. There wouldn’t be any logout protection in this case. Another would be to except those machine accounts, and create an alternate GPO which only applied to that handful of machines. You could set the timeout higher, say 3 hours or the longest movie time in your collection. Another way to deal with it is to just tell the few users at those workstations that they’ll have to click the abort logout button when it comes up.
How do I prevent users from running certain applications on my computers?
Almost all desktop restrictions are now controlled via group policy objects (gpo). Computers can be grouped together either in an OU (you could setup an OU under your primary OU or child domain) or in groups (just like users can be members of groups). This makes it simple to apply a restrictive gpo to many computers. You can either assign your restrictive group policy to your public workstation OU, or you could assign the gpo to your entire OU (or child domain) and only give the public workstation computer group the access rights to read & apply it. The OU approach is cleaner, but there are other reasons to take the group approach. As to what can be restricted . . . a lot. Windows has the ability to be quite restrictive. You can prevent the command prompt from being called, restrict access to the task manager, and either specify a don’t run list or the converse: give a list of only allow these programs to run.