Although you may be tempted to give users wide access, you need to balance the user's need for job-related resources against your need to protect sensitive resources or privileged information. For example, you wouldn't want everyone in the company to have access to payroll data. Consequently, you'd make sure that only those who need that information have access to it.
The Windows 2000 Security Model
You control access to network resources with the components of the Windows 2000 security model. The key components you need to know about are the ones used for authentication and access controls.Authentication Protocols
Windows 2000 authentication is implemented as a two-part process. That process consists of interactive logon and network authentication.When a user logs on to a computer, the interactive logon process authenticates the user's logon, which confirms the user's identity to the local computer and grants access to Active Directory directory service. Afterward, whenever the user accesses network resources, network authentication is used to determine whether the user has permission to do so.
Windows 2000 supports many different network authentication protocols. The key protocols are
- Kerberos V 5 A standard Internet protocol for authenticating users and systems. It's the primary authentication mechanism for Windows 2000.
- NT LAN Manager (NTLM) The primary Windows NT authentication protocol. It's used to authenticate computers in a Windows NT domain.
- Secure Socket Layer/Transport Layer Security (SSL/TLS) The primary authentication mechanism used when accessing secure Web servers.
- A user logs on to the domain by using a logon name and password or by swiping a smart card into a card reader.
- The interactive logon process authenticates the user's access. With a local account, the credentials are authenticated locally and the user is granted access to the local computer. With a domain account, the credentials are authenticated in Active Directory and the user has access to network resources.
- Now the user can authenticate to any computer in the domain through the network authentication process. With domain accounts, the network authentication process is automatic (through Single Sign-On). With local accounts, on the other hand, users must provide a user name and password every time they access a network resource.
Access Controls
Active Directory is object-based. Users, computers, groups, shared resources, and many other entities are all defined as objects. Access controls are applied to these objects with security descriptors. Security descriptors do the following:- List the users and groups that are granted access to objects
- Specify permissions the users and groups have been assigned
- Track events that should be audited for objects
- Define ownership of objects
When working with ACEs, keep the following points in mind:
- Access control entries are created with inheritance enabled by default.
- Inheritance takes place immediately after the ACE is written.
- All access control entries contain information specifying whether the permission is inherited or explicitly assigned to the related object.
Differences Between User and Group Accounts
Windows 2000 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. While you can log on to user accounts, you can't log on to a group account. Group accounts are usually referred to simply as groups.User Accounts
In Windows 2000 two types of user accounts are defined:- Domain user accounts Users accounts defined in Active Directory are called domain user accounts. Through Single Sign-On, domain user accounts can access resources throughout the domain. Domain user accounts are created 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.
Logon Names, Passwords, and Public Certificates
All user accounts are identified with a logon name. In Windows 2000, 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
The pre-Windows 2000 logon name is MICROSOFT\wrstanek.
When working with Active Directory, you may also need to specify the fully qualified domain name for a user. The fully qualified domain name for a group is the combination of the Domain Name Service (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 2000 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 2000 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 may gain access to resources simply by re-creating an account.
When you change a user name, you tell Windows 2000 to map a particular SID to a new name. When you delete an account, you tell Windows 2000 that a particular SID is no longer valid. Afterward, even if you create an account with the same user name, the new account will not 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 2000 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 while 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 may 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 may also need to specify the fully qualified domain name for a group. The fully qualified domain name 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 and all access permissions are revoked. 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 2000, 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.
Groups can have different scopes—domain local, built-in local, global, and universal. That is, the groups have different areas in which they are 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 are defined.
- Built-in local groups Groups that have a special group scope that have domain local permissions and, for simplicity, are often referred to as domain local groups. The difference between built-in local groups and other groups is that built-in local groups can't be created or deleted. 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 are defined.
- Universal groups Groups that are used to grant permissions on a wide scale throughout a domain tree or forest. Members of global groups include accounts and groups from any domain in the domain tree or forest.
When you work with groups, there are many things you can and can't do based on the scope of the group. A quick summary of these items is shown in Table 7-1. For complete details on creating groups, see Chapter 8, "Creating User and Group Accounts."
Table 7-1 How Group Scope Affects Group Capabilities
| Group Capability | Domain Local Scope | Global Scope | Universal Scope |
|---|---|---|---|
| Native Mode Membership | 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. |
| Mixed Mode Membership | 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. |
As with user accounts, Windows 2000 uses unique security identifiers to track group accounts. This means that you can't delete a group account, re-create it, and then expect all the permissions and privileges to remain the same. The new group will have a new security identifier and all the permissions and privileges of the old group will be lost.
Windows 2000 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.
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 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.
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 would follow these steps:
- Start by creating global groups for each marketing group. On the SEATTLE domain, create a group called GMarketing and add the members of the Seattle marketing department to it. On the CHICAGO domain, create a group called GMarketing and add the members of the Chicago marketing department to it. On the NY domain, create a group called GMarketing and add the members of the New York marketing department to it.
- 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 LocalMarketingData. The SEATTLE, CHICAGO, and NY domains should each have their own local groups.
- 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.
- Add UMarketing to the LocalMarketingPrinter and LocalMarketingData groups at each office. Marketing users should now be able to share data and printers.
No comments:
Post a Comment