Managing Windows 7 in a Domain : Authentication vs Authorization

As an example, if Joe is given a domain account, he can log on with that account. He uses it for authentication. However, just because Joe can log on doesn't mean he's automatically granted access to all the resources in the domain. Instead, his account is granted access to specific resources based on his needs and what he's authorized to access.

1. Authentication

Authentication is used to prove a user's identity. In general, there are three factors of authentication:

Something you know

This can be implemented with domain user accounts that have specific user names and passwords. As long as users know their user name and password, they are able to use these credentials for authentication.

Something you have

Smart cards are being used more and more today. A smart card is a credit card–sized card that can be inserted into a reader (often as part of the keyboard). Users insert the card and usually enter a personal identification number (PIN) for authentication. Within a domain, the smart card is associated with a domain user account.

Something you are

Biometrics can be used to prove a user's identity. Fingerprint readers can be found on more and more mobile computers today. Once configured, a user authenticates with their finger on the fingerprint reader. Other biometric methods include retinal scanners and hand scanners.

2. Authorization

Users are granted rights and permissions based on the user accounts that authenticate them. If users log on with the local administrator account, they are able to perform any action and access any of the resources on the system.

Rights and permissions are different but often clumped together. In short, rights identify what a user can do on a system and permissions identify the resources a user can access.

Figure 1 shows the User Rights Assignment page from the Local Security Policy. It includes several actions that a user can be authorized to perform on a system, such as logging on locally, backing up files and directories, and changing the system time.

Figure 1. User Rights Assignments in Local Security Policy

You can access the Local Security Policy from the Administrative Tools menu. The User Rights Assignment node is also available in Group Policy objects.

3. Built-in Groups

Although rights and permissions can be assigned to individual user accounts, they are much more commonly assigned to groups. If a user is a member of a group, and the group is granted specific rights and permissions, the user also has those rights and permissions.

Windows 7 and Windows domains both include many built-in groups. Figure 2 shows the built-in groups on a local system, and Figure 3 shows some of the built-in groups in a domain. These groups have been assigned specific rights and permissions to perform actions on systems and within domains.

Figure 2. Groups on a Windows 7 system

Figure 3. Built-in groups in a domain

You can access the Computer Management console to view local built-in groups via the Administrative Tools menu or by clicking Start, right-clicking Computer, and selecting Manage. You view domain built-in groups via the Active Directory Users and Computers console on a domain controller found in the Administrative Tools menu. There is a Builtin container, but additional built-in groups exist in the Users container.

Some of these groups deserve special mention:

Administrators (local)

Members of the Administrators group on local computers (including Windows 7 computers) can do anything on that computer. The local administrator account is a member of this group, and the first account created on a Windows 7 computer when it is installed is a member of this group.

Administrators (domain)

Members of the domain Administrators group have complete and unrestricted access to computers in the domain. The domain administrator account, the Domain Admins group, and the Enterprise Admins group are all members of the domain Administrators group by default.

Domain Admins

Users in the Domain Admins group can do anything in the domain. This group is automatically added to the local Administrators group for every computer in the domain. It's also added to the domain Administrators group.

Enterprise Admins

Users in the Enterprise Admins group can do anything in the forest. A forest is a group of one or more domains, and users in this group have permissions to add, remove, and administer all of the domains in the forest. This group is a member of the domain Administrators group for every domain in the forest.

Power Users

Power Users is a local group added for backward compatibility. It was used on older operating systems to give a user additional permissions without putting the user in the Administrators group.

Server Operator

This is a special group on domain controllers. It grants members rights and permissions to administer the domain controller without granting them any permission in the domain.

Backup Operators

This group grants members the ability to back up and restore files.

4. Organizing Users with Groups

It's also possible to create additional groups to meet specific needs. This is rarely done on local Windows 7 systems alone, but it's often done in a domain to organize users and easily grant specific rights and permissions.

As an example, consider Figure 4. Sally, Bob, and Alice are all in the Sales department. A group named G_Sales is created to organize the users, and each user account is then placed in the G_Sales group. Now imagine that the users in the group need access to the SalesData Share hosted on FS1.

Figure 4. Organizing users with a group

Instead of granting the same permissions to the individual accounts, the permissions to the SalesData Share are granted to the group. Because the users are members of the group, they have the same permissions as the group.

While it takes a little planning initially to design and create the groups, it eases the administration burden in the long run. For example, imagine that you originally granted Read permission to a share, but later wanted to change this to Modify for all the users in the Sales department. If a group is created and permissions are assigned to the group, you make the change once and you're done. However, if you originally assigned the permissions to each user, you'd have to modify the permissions for each user.

Groups are also useful even if only one user is a member. For example, imagine that an HR department has only one employee, Maria. On the surface, it may seem easier to assign all the permissions to Maria's account. However, what do you do if Maria is transferred or promoted within the company and someone else needs to take over?

If the permissions are assigned to the individual user, then they all have to be modified to remove Maria's access and grant the new employee's access. However, if a group was created and all the permissions were assigned to the group, you'd simply need to add the new employee's account to the group and remove Maria's account.

5. Group Scope and Group Type

Groups created in a domain have both a group scope and a group type. Figure 5 shows the screen used to create a new group. You can access this in Active Directory Users and Computers by right-clicking a container and selecting New => Group.

Figure 5. Creating a new group in a domain

The three group scopes are global, domain local, and universal:

Global

Global groups are commonly used to organize users (such as all the users in the Sales department with a group named G_Sales). Global groups can also contain other global groups.

Domain local

Domain local groups are sometimes used in administrative models in larger domains. A domain local group commonly identifies assigned permissions to specific resources. As an example, the DL_Print_ClrLaserPrinter group could be used to identify a group that is assigned print permission for a color laser printer. A domain local group typically contains one or more global groups and can also contain universal groups.

Universal

Universal groups are used in multiple-domain environments. They can contain global groups from any domain and can be added to domain local groups in any domain.

The two group types are distribution and security:

Distribution

A distribution group is used for email only. It cannot be assigned permissions.

Security

A security group can be assigned permissions or used as a distribution group.

In larger domains where both global and domain local groups are used, a common strategy known as A G DL P is used. Figure 6 shows an example of A G DL P.

Figure 6. A G DL P administrative model used in larger domains

When A G DL P is used, accounts (A) are added to global groups (G). Global groups are added to domain local (DL) groups, and permissions (P) are assigned to domain local groups.

The direction of the arrows in the figure also helps to identify what can be added to a group. The arrow goes down from the accounts, indicating they can be added to global groups or domain local groups. The arrow also goes down from the global group, indicating it can be added to a domain local group.

However, a global group can't be added to a user (which admittedly sounds silly), and a local group can't be added to a global group; both of these examples go against the arrow.

The arrow goes up from permissions. Permissions can be assigned to accounts or any type of group, but it's a good practice to assign permissions to groups whenever possible. When you begin assigning permissions directly to users, administration becomes more difficult.

The benefits of using domain local groups are realized only in larger domains where administrators want to manage permissions for some resources more closely. Most organizations use a simpler model of AGP (shown earlier in Figure 9.5) where accounts (A) are placed into global (G) groups and permissions (P) are assigned to the global groups.

Exercise 1 walks through the process of creating users and groups in a domain.

Exercise: Creating Users and Groups in a Domain