Differences Between User and Group Accounts


Differences Between User and Group Accounts

Windows Server 2003 provides user accounts and group accounts (of which users can be a member). User accounts are designed for individuals. Group accounts are designed to make the administration of multiple users easier. Although you can log on with user accounts, you can't log on with a group account. Group accounts are usually referred to simply as groups .

Real World

Windows Server 2003 supports the InetOrgPerson object. Essentially, this object is the same as a user object and you could use it as such. However, the real purpose for the InetOrgPerson object is to allow for compatibility and transition from third-party X.500 and Lightweight Directory Access Protocol (LDAP) directory services that use this object to represent users. If you are migrating from a third-party directory service and end up with many InetOrgPerson objects, don't worry. These objects can be used as security principals just like user accounts. The InetOrgPerson object is fully enabled only when working in Windows Server 2003 operations mode. In this mode you can set passwords for InetOrgPerson objects and you can change the object class if desired. When you change the object class, the InetOrgPerson object is converted to a user object and from then on is listed as the User type in Active Directory Users And Computers.

User Accounts

In Windows Server 2003, two types of user accounts are defined:

  • Domain user accounts

    User accounts defined in Active Directory are called domain user accounts . Through Single Sign-On, domain user accounts can access resources throughout the domain. You create domain user accounts in Active Directory Users And Computers.

  • Local user accounts

    User accounts defined on a local computer are called local user accounts . Local user accounts have access to the local computer only, and they must authenticate themselves before they can access network resources. You create local user accounts with the Local Users And Groups utility.

Note

In a domain, only member servers and workstations have local user and group accounts. On the initial domain controller for a domain, these accounts are moved from the local security manager to Active Directory and then become domain accounts.


Logon Names , Passwords, and Public Certificates

All user accounts are identified with a logon name. In Windows Server 2003, this logon name has two parts :

  • User name

    The text label for the account

  • User domain or workgroup

    The workgroup or domain where the user account exists

For the user wrstanek, whose account is created in the microsoft.com domain, the full logon name for Windows Server 2003 is wrstanek@microsoft.com. The pre “Windows 2000 logon name is MICROSOFT\wrstanek.

When working with Active Directory, you might also need to specify the fully qualified domain name (FQDN) for a user. The FQDN for a group is the combination of the Domain Name System (DNS) domain name, the container or organizational unit location, and the group name. For the user microsoft.com\users\wrstanek, microsoft.com is the DNS domain name, users is the container or organizational unit location, and wrstanek is the user name.

User accounts can also have passwords and public certificates associated with them. Passwords are authentication strings for an account. Public certificates combine a public and private key to identify a user. You log on with a password interactively. You log on with a public certificate using a smart card and a smart card reader.

Security Identifiers and User Accounts

Although Windows Server 2003 displays user names to describe privileges and permissions, the key identifiers for accounts are security identifiers (SIDs). SIDs are unique identifiers that are generated when accounts are created. SIDs consist of the domain's security ID prefix and a unique relative ID, which was allocated by the relative ID master.

Windows Server 2003 uses these identifiers to track accounts independently from user names. SIDs serve many purposes. The two most important ones are to allow you to easily change user names and to allow you to delete accounts without worrying that someone might gain access to resources simply by recreating an account.

When you change a user name, you tell Windows Server 2003 to map a particular SID to a new name. When you delete an account, you tell Windows Server 2003 that a particular SID is no longer valid. Afterward, even if you create an account with the same user name, the new account won't have the same privileges and permissions as the previous one. That's because the new account will have a new SID.

Groups

In addition to user accounts, Windows Server 2003 provides groups. You use groups to grant permissions to similar types of users and to simplify account administration. If a user is a member of a group that can access a resource, that particular user can access the same resource. Thus, you can give a user access to various work- related resources just by making the user a member of the correct group. Note that although you can log on to a computer with a user account, you can't log on to a computer with a group account.

Because different Active Directory domains might have groups with the same name, groups are often referred to by domain \ groupname , such as work\gmarketing for the gmarketing group in the work domain. When you work with Active Directory, you might also need to specify the FQDN for a group. The FQDN for a group is the concatenation of the DNS domain name, the container or organizational unit location, and the group name. For the group microsoft.com\users\gmarketing, microsoft.com is the DNS domain name, users is the container or organizational unit location, and gmarketing is the group name.

Real World

Employees in a marketing department probably need access to all marketing-related resources. Instead of granting access to these resources individually, you could make the users members of a marketing group. That way, they automatically obtain the group's privileges. Later, if a user moves to a different department, you simply remove the user from the group, thus revoking all access permissions. Compared to having to revoke access for each individual resource, this technique is pretty easy ”so you'll want to use groups whenever possible.

Group Types

In Windows Server 2003 there are three types of groups:

  • Local groups

    Groups that are defined on a local computer. Local groups are used on the local computer only. You create local groups with the Local Users And Groups utility.

  • Security groups

    Groups that can have security descriptors associated with them. You define security groups in domains using Active Directory Users And Computers.

  • Distribution groups

    Groups that are used as e-mail distribution lists. They can't have security descriptors associated with them. You define distribution groups in domains using Active Directory Users And Computers.

Group Scope

Groups can have different scopes ”domain local, built-in local, global, and universal. That is, the groups have different areas in which they're valid.

  • Domain local groups

    Groups that are used to grant permissions within a single domain. Members of domain local groups can include only accounts (both user and computer accounts) and groups from the domain in which they're defined.

  • Built-in local groups

    Groups with a special group scope that have domain local permissions and, for simplicity, are often included in the term domain local groups . The difference between built-in local groups and other groups is that you can't create or delete built-in local groups. You can only modify built-in local groups. References to domain local groups apply to built-in local groups unless otherwise noted.

  • Global groups

    Groups that are used to grant permissions to objects in any domain in the domain tree or forest. Members of global groups can include only accounts and groups from the domain in which they're defined.

  • Universal groups

    Groups that are used to grant permissions on a wide scale throughout a domain tree or forest. Members of universal groups include accounts, global groups, and other universal groups from any domain in the domain tree or forest. Universal groups are available only when Active Directory is running in Windows 2000 native operations mode or in Windows Server 2003 operations mode.

    Best Practices

    Universal groups are very useful in large enterprises where you have multiple domains. If you plan properly, you can use universal groups to simplify system administration. Members of universal groups shouldn't change frequently. Each time you change the members of a universal group, you need to replicate these changes to all the global catalogs in the domain tree or forest. To cut down on changes, assign other groups to the universal group rather than accounts. For more information, see the section in this chapter entitled "When to Use Domain Local, Global, and Universal Groups."


When you work with groups, there are many things you can and can't do based on the group's scope. A quick summary of these items is shown in Table 8-1. For complete details on creating groups, see Chapter 9 , "Creating User and Group Accounts."

Table 8-1. How Group Scope Affects Group Capabilities

Group Capability

Domain Local Scope

Global Scope

Universal Scope

Windows Server 2003/ Windows 2000 Native Mode

Accounts, global groups, and universal groups from any domain; domain local groups from the same domain only

Only accounts from the same domain and global groups from the same domain

Accounts from any domain, as well as groups from any domain regardless of scope

Windows 2000 Mixed Mode

Accounts and global groups from any domain

Only accounts from the same domain

Can't be created in mixed-mode domains

Member Of

Can be put into other domain local groups and assigned permissions only in the same domain

Can be put into other groups and assigned permissions in any domain

Can be put into other groups and assigned permissions in any domain

Scope Conversion

Can be converted to universal scope, provided it doesn't have as its member another group having domain local scope

Can be converted to universal scope, provided it's not a member of any other group having global scope

Can't be converted to any other group scope

Security Identifiers and Group Accounts

As with user accounts, Windows Server 2003 uses unique SIDs to track group accounts. This means that you can't delete a group account, recreate it, and then expect all the permissions and privileges to remain the same. The new group will have a new SID, and all the permissions and privileges of the old group will be lost.

Windows Server 2003 creates a security token for each user logon. The security token specifies the user account ID and the SIDs of all the security groups to which the user belongs. The token's size grows as the user is added to additional security groups. This has several consequences:

  • The security token must be passed to the user logon process before logon can be completed. Because of this, as the number of security group memberships grows, the logon process takes longer.

  • To determine access permissions, the security token is sent to every computer that the user accesses . Because of this, the size of the security token has a direct impact on the network traffic load.

    Note

    Distribution group memberships aren't distributed with security tokens. Because of this, distribution group memberships don't affect the token size.


When to Use Domain Local, Global, and Universal Groups

Domain local, global, and universal groups provide a lot of options for configuring groups in the enterprise. Although these group scopes are designed to simplify administration, poor planning can make these group scopes your worst administration nightmare. Ideally, you'll use group scopes to help you create group hierarchies that are similar to your organization's structure and the responsibilities of particular groups of users. The best uses for domain local, global, and universal groups are as follows :

  • Domain local groups

    Groups with domain local scope have the smallest extent. Use groups with domain local scope to help you manage access to resources, such as printers and shared folders.

  • Global groups

    Use groups with global scope to help you manage user and computer accounts in a particular domain. Then you can grant access permissions to a resource by making the group with global scope a member of the group with domain local scope.

  • Universal groups

    Groups with universal scope have the largest extent. Use groups with universal scope to consolidate groups that span domains. Normally, you do this by adding global groups as members. Now when you change membership of the global groups, the changes aren't replicated to all the global catalogs. This is because the membership of the universal group didn't change.

Tip

If your organization doesn't have two or more domains, you don't really need to use universal groups. Instead, build your group structure with domain local and global groups. Then, if you ever bring another domain into your domain tree or forest, you can easily extend the group hierarchy to accommodate the integration.


To put this in perspective, consider the following scenario. Say that you have branch offices in Seattle, Chicago, and New York. Each office has its own domain, which is a part of the same domain tree or forest. These domains are called Seattle, Chicago, and NY. You want to make it easy for any administrator (from any office) to manage network resources, so you create a group structure that is very similar at each location. Although the company has marketing, IT, and engineering departments, let's focus on the structure of the marketing department. At each office, members of the marketing department need access to a shared printer called MarketingPrinter and a shared data folder called MarketingData. You also want users to be able to share and print documents. For example, Bob in Seattle should be able to print documents so that Ralph in New York can pick them up on his local printer, and Bob should also be able to access the quarterly report on the shared folder at the New York office.

To configure the groups for the marketing departments at the three offices, you'd follow these steps:

  1. Start by creating global groups for each marketing group. In the Seattle domain, create a group called GMarketing and add the members of the Seattle marketing department to it. In the Chicago domain, create a group called GMarketing and add the members of the Chicago marketing department to it. In the NY domain, create a group called GMarketing and add the members of the New York marketing department to it.

  2. In each location, create domain local groups that grant access to the shared printers and shared folders. Call the printer group LocalMarketingPrinter. Call the New York shared folder group LocalMarketingData. The Seattle, Chicago, and NY domains should each have their own local groups.

  3. Create a group with universal scope called UMarketing on the domain at any branch office. Add Seattle\GMarketing, Chicago\GMarketing, and NY\GMarketing to this group.

  4. Add UMarketing to the LocalMarketingPrinter and LocalMarketingData groups at each office. Marketing users should now be able to share data and printers.



Microsoft Windows Server 2003 Administrator[ap]s Pocket Consultant
Microsoft Windows Server 2003 Administrator[ap]s Pocket Consultant
ISBN: 735622450
EAN: N/A
Year: 2003
Pages: 141

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net