|
|
|
|
Inside Active Directory: A System Administrator's Guide
Last Updated 2/3/2009 3:43:00 PM
Abstract
Need Abstract
The previous chapter's discussion of managing OUs, users, and groups in Active
Directory assumes that you always have a right to do what you want. In fact, Active
Directory has access control features that facilitate the management of access to
various elements in the directory. In this chapter we examine how Active Directory's
access control works.
First we briefly review Windows 2000 security in general. Then we give some
background for Active Directory access control. After that we move to the main
topic, which is how permissions work to protect each Active Directory object.
You have three ways to manage permissions, and we describe each of them in
separate sections of the chapter:
- You can manage the permissions manually. In our explanation, we don't just
describe how to manage permissions, we also explore the permission mechanisms
behind the administrative user interface.
- You can use the Delegation of Control wizard.
- You can accept the default permissions, which we list in a number of tables.
After we describe the mechanisms and user interface, we introduce scenarios
to illustrate the kinds of permissions you can use in different practical situations
and the way to implement these permissions.
As a final step to discussing permissions, we delve into the underlying architecture.
This information is normally presented only to programmers, but administrators
can also benefit from it.
At the end of the chapter we introduce user rights. They don't control access
to individual objects'they control access to the system as a whole.
INTRODUCTION TO WINDOWS 2000 SECURITY
From the very beginning, Windows NT, and consequently Windows 2000, was
designed with security in mind. Windows 2000 enhances the security features of
Windows NT and introduces new security technologies to accommodate the
needs of the current intranet and Internet era. Securing data so that only those
who are supposed to see it do see it is a major concern of businesses. Windows
2000 has 'A A A' security as a result of the following features:
- Authentication checks the user's identity when he starts to use the network.
A user tells who he is by typing a logon name and proves this by typing the
correct password. Alternatively, a user can be required to insert a smart card in
a reader and type a personal identification number (PIN). Authentication may
be interactive when it takes place in the computer that the user is sitting at.
Otherwise, a network authentication occurs when the target resource is in a
different computer from the one the user is using. There are various underlying
authentication protocols such as Kerberos version 5 and Windows NT/LAN
Manager (NTLM).
- Authorization protects the objects and resources in the network. This
process determines whether the user has permission to read, modify, create,
or delete a certain object or resource.
- Auditing enables administrators to log the usage of objects and resources.
This allows administrators to see who has been gaining access to each object
and what he has been doing with it.
This chapter focuses on authorization with respect to objects in Active Directory.
We also briefly discuss auditing.
Some other features of Windows 2000 security include the following.
- Windows 2000 supports single sign-on, which means that a user must enter
her logon name and password only once, and then she can use objects and
resources in different servers and workstations, even in different domains.
- Public key infrastructure (PKI) provides data protection by encrypting the
data on disk (Encrypting File System, or EFS) and on the wire (SSL and IPSec)
so that unauthorized users on a network cannot read the data. PKI also allows
digital signing of documents and software components to ensure they are not
tampered with. Another application of PKI is to authenticate users who have
digital certificates.
- An administrator can assign and enforce the security settings he chooses to
a number of workstations and servers by using Group Policy and security templates.
He can also analyze whether the current security settings of those
computers are acceptable. (See Chapter 7 for more information about Group
Policy.)
Whether you are administering or simply using a Windows 2000 network, you
must have appropriate rights and permissions to do the things you need to do.
Table 4.1 lists the typical areas of rights and permissions.
Merely putting people in correct security groups often gives them all the
rights and permissions they need. Unfortunately, there are cases that require setting
them manually. Therefore, Table 4.1 mentions which utility you can use in
each case to control the rights and permissions.
|
NOTE: User rights may override permissions. For example, if a user has the right to make
backups, she can do so even though she doesn't have permission to read the files
she is backing up.
|
|
NOTE: The utilities mentioned are the typical ones, but there may be other choices. Also,
you can control rights and permissions with scripting.
|
|
NOTE: Table 4.1 lists rights and permissions that you can assign to users and groups (the
latter is usually preferable). In addition, a number of security settings affect the
whole computer and are not user- or group-specific. For example, you can disable
the Ctrl-Alt-Delete requirement for logon if you don't need the protection it offers
against malicious password-capturing programs.
|
BACKGROUND FOR ACTIVE DIRECTORY ACCESS CONTROL
When any user tries to access any Active Directory object, the system first checks if
that user has permission for the access he requested. Depending on the result,
the user is either granted or denied access.
Active Directory permissions are used to control access to Active Directory.
Administrators obviously need permission to create users and other objects, as
well as modify existing objects. End users need permission to read the properties
of their own objects and perhaps modify some of those properties. They also
benefit from being able to see other users' e-mail addresses, fax numbers, and
so on.
Between a full-powered administrator and an ordinary end user, there may be
various levels of assistant administrators with partial administrative permissions
and rights. There may also be a person who is otherwise an end user, but who can
modify some information, such as the address information of all the users in her
department.
In the previous chapter about OUs, users, and groups, you operated with full
access. In this chapter you will learn and study what the world looks like when
access is controlled and limited.
Controlling Access
The permissions that determine who can access an object and in which way (read,
modify, create, delete, and so on) are stored as a property (called nTSecurity-Descriptor) in every Active Directory object. That property also identifies the
owner of the object.
The permissions are defined as a list of individual permission entries. It is up
to the owner to specify appropriate permissions for the objects she owns. One of
the permissions the owner can give to someone else is Modify Permissions. As the
name implies, this allows the other party (in addition to the owner) to modify the
permission list. Figure 4.1 illustrates these concepts.
|
NOTE: A developer could create an object without an access control list. In that case,
everyone would have full access to the object. In reality, however, there is always
an access control list. If (and when) the list exists but is empty, no one has access
to the object.
|
NTSecurityDescriptor is part of the global catalog. This means that when
users search for other users or resources, they can search only on the properties
that they are allowed to read, and they are shown only the objects and properties
they are allowed to read.
Security Principals
You assign permissions to security principals, which are users, computer objects,
security groups and well-known security principals. Figure 4.2 shows them on
the left. You cannot give permissions to OUs; however, we include it (unattached)
in Figure 4.2 in anticipation of Microsoft making this possible in the future. You
can give permissions for any Active directory object, as shown on the right side of
Figure 4.2.
|
IF YOU KNOW NDS: In Active Directory, only the four types on the left side of Figure 4.2 can have permissions
for objects and resources, while in NDS any directory object can have
permissions for objects and resources.
|
As Figure 4.2 shows, you can assign user Jack permissions for group gsSales,
group gsSales permissions for user Jack, user Jack permissions for user Jill, or user
Jill permissions for user Jack.
|
NOTE: Remember that the best choice is to assign permissions to domain local groups,
the second best choice is to use global or universal groups, and the last choice is
to assign permissions directly to users.
|
No matter which type of security principal gets the permissions, it's always the
logged-on user (or a background process running under some user account) who
is actually using them. Table 4.2 lists when a user can leverage the permissions
given to one of the four security principal types.
|
IF YOU KNOW NDS: There is no concept of security equivalence in Active Directory.
|
Well-Known Security Principals
The term well-known security principal refers to fixed accounts that are kind of
like users or groups. However, you cannot delete or rename them. Actually, you
don't even see them in the list of users and groups (except in the dialog boxes
where you give permissions).
A well-known security principal may include a number of users, but you cannot
designate who these 'members' are. For example, whether a user is a 'member'
of Interactive depends on the circumstances'he is a 'member' if he is
sitting at the computer where the resource being accessed resides. Table 4.3
explains Interactive and the other well-known security principals.
Well-known security principals are referred to as special identities in Windows
2000 Help. The reason for well-known security principals to exist is that they allow
administrators to assign permissions to these special identities, so that appropriate
users can use those permissions. You can also think of well-known security principals
as 'dynamic groups,' because their 'member' lists are dynamically determined.
|
NOTE: You shouldn't use the System account to run third-party services in domain controllers,
because that account has so many rights. It is safer to use some other
account. However, in member servers and workstations, it's fine to use System for
services.
|
|
IF YOU KNOW NT: In Windows NT it was quite common to run services with the System account. If
you got into this habit, now is a good time to get out of it.
|
|
NOTE: You cannot extend the list of well-known security principals. For example, you
cannot add a 'Those who logged on using a smart card' principal.
|
You can put a well-known security principal as a member in a domain local or
built-in group, but you cannot do this using the Users and Computers snap-in.
Instead, you must use a command such as
NET LOCALGROUP "Print Operators" Interactive /ADD
This command would put Interactive as a member in the Print Operators
built-in group, allowing any locally logged-on user to create a print queue, for
example.
|
NOTE: You can put Interactive in a domain local or built-in group, or assign permissions to
Interactive. However, Active Directory doesn't honor either of these settings'that
is, a user logged on at a domain controller cannot use those permissions to access
Active Directory. For example, if Interactive is a member of Print Operators, a user
who is logged on at a domain controller cannot create a printer object. However,
he can create a printer (i.e., print queue) because it is outside Active Directory.
|
MANAGING ACTIVE DIRECTORY PERMISSIONS
To manage permissions in your Active Directory, you can use the following means
(in order of preference):
- Default settings. If you can cope with per-domain permissions, and you don't
need per-OU (or even more granular) permissions, you will probably do fine
with the default permissions. All you need to do is put users in appropriate,
predefined administrative groups, such as Account Operators.
- Wizard. Use the Delegation of Control wizard to give additional permissions
that the defaults won't cover.
- ACL Editor. Turn on Advanced Features in the Users and Computers snap-in
and start using the Security tab (i.e., ACL Editor) to assign permissions
manually.
In this chapter we discuss the three choices in just the opposite order. First
we explore ACL Editor and the mechanisms behind it. Then we talk about the Delegation
of Control wizard. Last, we list the default permissions for various Active
Directory objects. The reason for the opposite order is that if you want to understand
the Delegation of Control wizard or the defaults, you need to understand
the permissions mechanisms. Those in turn can best be explained with the manual
user interface, so we start with it.
Remember that to be able to manage permissions for some object, you need
to either be the owner of that object or have Modify Permissions permission for it.
When you start to use ACL Editor, we recommend you proceed in the following
order:
- Don't change anything.
- Don't click OK or Apply.
- Learn how the permissions work.
- Learn some more.
- First use a small test network.
- When you finally start making changes in the production network, explore
the results after each change.
If you make unwanted changes, permissions may become either too loose or
too tight. The former case is a security risk if someone accidentally or deliberately
makes use of the excess permissions. The latter case may result in a loss of some
functionality.
To correct the wrong permissions, you first need to discover the problem and
then know which permissions to restore. To determine the latter, you can see
what kind of permissions other similar objects have and proceed on the assumption
that those permissions are appropriate to restore.
|
NOTE: If you remove all administrative permissions for an object (usually by blocking
inheritance to it and removing some permission entries), the owner of the object
can restore the permissions.
|
|
Page:
1,
2,
3,
4,
5,
6,
7,
8,
9, |
next page  |
>
|
|