Community Pick: Many members of our community have endorsed this article.

Understanding User Rights Assignment - How to lock down or unlock your user's actions

Adam BrownCloud Security Consultant
I'm Adam. I'm an IT guy.
Have you ever wondered why the Administrator account is allowed to do certain things and other accounts aren't?  Probably not unless you're an insomniac like me, but the reason is actually pretty simple and mastering the ability to assign User Rights, Windows' method of determining what users can do what, can grant system administrators a great deal of control over their environment.

This article will delve deep into the dark reaches of User Rights to give you a good enough understanding of this simple system of user management that you'll be able to build a more secure, stable, and efficient Active Directory environment with little effort at all.

The Place

To control the rights that any user has, you'll need to find the right place to take control of it. The User Rights Assignment section of Windows Policy is where you get to manage this stuff.

To see for yourself, open the default domain controllers Group Policy Object (GPO) or run gpedit.msc. With the policy management window open, navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. This part of Windows Policy is where you determine which accounts can do what and which ones can't. Each right listed grants a specific type of operation to any user that is granted a right. When you first look at this section, you'll notice that "Administrators" is listed in almost every line. This is why Administrators can do everything they can do.

The What

Before you can really start going nuts with User Rights Assignment, you should understand something. Some of the rights you can allocate to users can open you up for serious problems. For instance, granting Domain Users the right to, say, act as part of the operating system will probably wind up you having to do some serious fixing in the future. This section will explain what the rights are and what they do. A lot of them are pretty self explanatory, others not so much. Some you'll need to use often, some you should never even touch. How can you know the difference? Well, when you double click on any user right, you'll see this image:
The User Right Dialogue BoxThe little yellow highlighted area is what you should click if you want to know what each right does. It just so happens, I've actually clicked that little button, and the explanation is below: What the User Right Does
Now, as you should be able to gather from that explanation, the Access Credential Manager as a trusted caller right is probably one you shouldn't mess with.  I mean, any time Microsoft takes the time to explicitly state "No accounts should have this privilege" it's probably a good idea to listen. Why is that right even listed? Don't ask me. I'm not Bill Gates.

The How

Giving a user the right to do something is pretty simple. On the Local Security Setting tab, just click Add User or Group and, well, pick a user or group to give the right to.  Same thing for revoking a right. Just highlight the user you no longer want to have that right, and click Remove.

The Why

Now we're getting to the big question. What's the point here? Why should I even bother dealing with this User Rights Assignment stuff? Well, if you want to restrict a user or a group of users from doing something, this is how you do it.

For Instance
Let's say you have a service account. You want to give it a whole lot of permission to access files or processes on your computer, and you want to be able to run a specific piece of software with it, but you don't want your brainy users to be able to log on with it and do whatever they want. Let say you also don't want to have to change the account password very often, and you don't want the account to get locked out because if it does, the service will stop. The best way to accomplish all of this is through a user right assignment. More specifically, a few user right assignments.

In this situation, we have a service that requires the file permissions this account has been given in order to work. What do we do? Well, we grant the user account the Log on as a service right. But we still have this account that has a lot of access, a password that never expires, and never gets locked out. Now what? Well, we add the user to the Deny log on Locally right. But wait, they can't log on locally, but can they log on remotely? Maybe...So let's add that user to the Deny log on through Remote Desktop Services right. Yes, I realize that denying something the right to do something doesn't sound like a right at all, but don't worry about that. Just go with the flow, man. By the way, now we have a service account that can only log on as a service. No one but the operating system can use it. Sound secure?

More Instance
How about a couple more examples of how this can be used.
You want someone else to add computers to the Domain
So you've just hired a new lackey and you want him to have something to do all day. If you feel confident enough, you can give him the Add Workstations to Domain right.
You want users to stop logging on to specific computers
Let's say you have a bunch of users in accounting that keep logging on to workstations in the graphic design department. All you have to do to stop that annoying behavior is build a GPO and set the Deny Log on Locally right, then link it to the OU where the graphic design computers are.

Final notes

There are a fair number of other things you can empower your users to do or completely prevent them from doing with User Rights Assignment. But do be careful, if you do things wrong, you may end up preventing the wrong users from logging on to their computers.

The last thing that you really need to know about User Rights assignment is this:  If a user is not assigned a right, either through a group that they are a member of or explicitly with their user account, they don't have access to that right. So if a user is not listed in the Allow Log on Locally right, they won't be able to log on to that computer.

Now you may be asking, "If not having a user in the Allow Log on Locally right keeps them off the computer, then why is there also a Deny Log on Locally right?"  A fair question to ask, but to answer it, you need to pay attention to the defaults.

By default, Allow Log on Locally is a right given to almost every user class on the local computer: Administrators, Users, and even Guests. Because of the default actions that occur when you add a computer to a domain, for example, groups that a specific member or group of members belong to (think Domain Users or Domain Admins) may be members of the groups that are giving the right to log on locally. The deny right works just like a deny permission for access to folders. It supersedes the allow right. So if you find out that you have users who suddenly can't log on to their computers, it's possible that they either have been denied the right to log on locally or they have been removed from the right that allows them to log on locally.

User Rights Assignment is something that every administrator should at least know about, even if they never have to use it. It's the system that controls the way users access systems on your network. And, as I've shown above, if the way a user can access a system has suddenly changed, there's a very good chance that the rights the user has have been changed. So it's always a good place to look when things go wrong.
Adam BrownCloud Security Consultant
I'm Adam. I'm an IT guy.

Comments (1)

Joseph MoodyBlogger and wearer of all hats.

I really enjoyed reading this! Setting up a proper service account is cool!

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.