Windows Server 2008 R2 : Understand Local Users and Groups (part 2) - Understand Local User Rights & Work with Local Account Policies

3. Understand Local User Rights

You might be thinking that granting users permissions to your server is as easy as adding the user to the right group. Well, in part, you are correct; however, you need to understand what truly grants users the ability to do work on the Windows Server 2008 R2 server. Those abilities are called rights on a server, and in turn the local rights are assigned to the user or group. For example, when you add a user to the Backup Operators group, that group is granted a few built-in rights. A couple of those rights are Backup Files and Directories and Restore Files and Directories, for example.

3.1. View the Local User Rights

To see a list of the local rights on the server, you need to open the Local Security Policy MMC on the system. The local security policy will allow you to look at the local user rights and will show account policies, Windows Firewall, and other important security settings on your server. To view the local security policy, you need to be an administrator for the server.

3.2. Rights or Permissions

A common area that can cause confusion is the distinction between rights and permissions. Even though they are similar, in a Windows Server 2008 R2 environment they are used for different purposes. Understanding the difference will help you maintain your systems more efficiently. This concept of rights and permissions will follow you through all the work you do regarding secure access to your Windows Server 2008 R2 servers, even when you work with the Active Directory domain infrastructures.

Rights One way you can think of rights, as you have seen from the previous examples, is that they grant user abilities on the server. These abilities are special and usually give your user extra access to a server.

Permissions These grant the user the ability to access Windows Server 2008 R2 resources, such as printers, files, and shares. Permissions will determine your level of access to an object such as a file or whether you can change the object or just read it, and they will be determined by the permissions assigned to the object.

4. Work with Local Account Policies

You will need to manage the local account policies on your servers. The local account policies on your server are designed to protect the integrity of your users and the passwords they use. Whether you are using a stand-alone sever or an Active Directory domain for logon access, these local policies have the same impact in both environments. They also help lock out the accounts if there are too many invalid attempts to access a given user account. Before you take a look at how to manage the account policies of your server, you need to understand the importance of passwords and how the account policies are there to protect you.

4.1. A Word on Passwords

As you most likely know, there is nothing more important to the security of your environment than the passwords used by you and your users. Keeping these passwords protected is critical to any environment. You also want to always enforce password complexity and length to make sure your users passwords are hard to guess and can't be hacked.

You may have heard this phrase before:

"Passwords are like bubble gum. They are strongest when fresh, should only be used by individuals and not a group, and if left laying around can create a sticky mess."

This is a fantastic way to think of passwords. What it means in a technical sense for you as an administrator is this: make sure you expire passwords on a regular basis to force users to regularly change passwords. This also goes hand in hand with password history and making sure that you keep track of users' former passwords so they cannot revert to old passwords. If you do not keep track of password history, what your users may do when their passwords expire is change their password to a new password and then change the password right back to their former password. Expiring passwords and keeping track of passwords will help keep your passwords fresh and secure.

If you have shared workstations in your network and have multiple users using a workstation, it is well worth your time to create individual accounts for each of the users. Not only will this protect the security of your environment, but it will also provide you with some flexibility when it comes to administering the users on the workstation.

Lastly, you may have seen or heard about users using sticky notes with the passwords written on them stuck to the monitor of their workstation. As you can imagine, this potentially opens your environment up to having users' passwords stolen. It is worth your time to occasionally patrol the hallways of your business to make sure this is not happening.

While on patrol, you may also notice unlocked desktops, which is another open avenue for you to be attacked. One way you can prevent this is with group policies and setting screensaver policies to lock the desktop after a predetermined amount of idle time. Another, more nefarious way is that you can provide your users with a teachable moment when you find an unlocked desktop—send the user an email from themselves. Now, this method is more than likely prohibited by your employer, and I do not recommend this. It's just something to get you thinking about the potential danger of unlocked desktops in your organization. Now, you do not need to send the message to anyone other than the user who left their desktop unlocked. It would look something like this:

From: Unlocked User

To: Unlocked User

Subject: Lock Your Desktop

Message: Just think this message could have gone to your boss. So please, lock your desktop in the future.

Sincerely,

Your friendly neighborhood administrator

4.2. A Look at Account Policies

Your local account policies are also located in the local security policy for your server. The account polices are broken into two areas. One is for the password policy, as shown in Figure 14, and the other is your account lockout policy, as shown in Figure 15.

Figure 14. Password policy

Figure 15. Account lockout policy

Working with your password policy allows you to control settings regarding password settings. Table 3 describes those settings and the default values. To change any of the settings on your server, you can use Group Policy or modify the settings by double-clicking them when you're viewing them in the Local Security Policy MMC.

Working with account lockout policies allows basic control over failed logon attempts to your server. When an account is locked out, it effectively becomes disabled and cannot be used until the account is unlocked by an administrator or a preset amount of time has passed. All of those settings can be changed with Group Policy, or you can modify the settings by double-clicking them when you're viewing them in the Local Security Policy MMC. Table 4 describes the Account Lockout Policy settings and the default values.