New features in AD DS in Windows Server 2008
In
Windows Server 2008, organizations can use Active Directory
Domain Services (AD DS) to manage users and resources, such as computers,
printers, or applications, on a network. AD DS includes many new features
that are not available in previous versions of Windows Server
Active Directory. These new features make it possible for organizations to
deploy AD DS more simply and securely and to administer it more
efficiently. This topic provides an overview of the improvements in AD DS.
For details about the improvements, see the following topics that describe the
new features in Windows Server 2008 AD DS:
AD
DS: Auditing.
AD DS: Fine-Grained Password Policies.
AD DS: Read-Only Domain Controllers.
AD DS: Restartable Active Directory Domain Services.
AD DS: Database Mounting Tool (Snapshot Viewer or Snapshot Browser).
AD DS: User Interface Improvements.
AD DS: Owner Rights.
AD DS: Fine-Grained Password Policies.
AD DS: Read-Only Domain Controllers.
AD DS: Restartable Active Directory Domain Services.
AD DS: Database Mounting Tool (Snapshot Viewer or Snapshot Browser).
AD DS: User Interface Improvements.
AD DS: Owner Rights.
AD DS:
Auditing
The global audit policy Audit directory service access controls whether auditing for directory service events is enabled or disabled. This security setting determines whether events are logged in the Security log when certain operations are carried out on objects in the directory. You can control what operations to audit by modifying the system access control list (SACL) on an object. In Windows Server 2008, this global audit policy is not enabled by default. Although the subcategory Directory Service Access is enabled for success events by default, the other subcategories are not enabled by default.
The global audit policy Audit directory service access controls whether auditing for directory service events is enabled or disabled. This security setting determines whether events are logged in the Security log when certain operations are carried out on objects in the directory. You can control what operations to audit by modifying the system access control list (SACL) on an object. In Windows Server 2008, this global audit policy is not enabled by default. Although the subcategory Directory Service Access is enabled for success events by default, the other subcategories are not enabled by default.
If you
define this policy setting (by modifying the default Domain Controllers
Policy), you can specify whether to audit successes, audit failures, or not
audit at all. Success audits generate an audit entry when a user successfully
accesses an AD DS object that has a SACL specified. Failure audits
generate an audit entry when a user unsuccessfully attempts to access an
AD DS object that has a SACL specified.
You
can set a SACL on an AD DS object on the Security tab in
that object's properties dialog box. Audit directory service access is
applied in the same manner as Audit object access; however, it
applies only to AD DS objects and not to file system objects and registry
objects.
AD DS:
Fine-Grained Password Policies
You can use fine-grained password policies to specify multiple password policies within a single domain. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain.
You can use fine-grained password policies to specify multiple password policies within a single domain. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain.
For
example, you can apply stricter settings to privileged accounts and less strict
settings to the accounts of other users. In other cases, you might want to
apply a special password policy for accounts whose passwords are synchronized
with other data sources.
AD DS:
Read-Only Domain Controllers
Inadequate physical security is the most common reason to consider deploying an RODC. An RODC provides a way to deploy a domain controller more securely in locations that require fast and reliable authentication services but cannot ensure physical security for a writable domain controller.
Inadequate physical security is the most common reason to consider deploying an RODC. An RODC provides a way to deploy a domain controller more securely in locations that require fast and reliable authentication services but cannot ensure physical security for a writable domain controller.
However,
your organization may also choose to deploy an RODC for special administrative
requirements. For example, a line-of-business (LOB) application may run
successfully only if it is installed on a domain controller. Or, the domain
controller might be the only server in the branch office, and it may have to
host server applications.
In
such cases, the LOB application owner must often log on to the domain
controller interactively or use Terminal Services to configure and manage the
application. This situation creates a security risk that may be unacceptable on
a writable domain controller.
An
RODC provides a more secure mechanism for deploying a domain controller in this
scenario. You can grant a nonadministrative domain user the right to log on to
an RODC while minimizing the security risk to the Active Directory forest.
You
might also deploy an RODC in other scenarios where local storage of all domain
user passwords is a primary threat, for example, in an extranet or
application-facing role.
AD DS:
Restartable Active Directory Domain Services
Restartable AD DS reduces the time that is required to perform certain operations. AD DS can be stopped so that updates can be applied to a domain controller. Also, administrators can stop AD DS to perform tasks, such as offline defragmentation of the Active Directory database, without restarting the domain controller. Other services that are running on the server and that do not depend on AD DS to function, such as Dynamic Host Configuration Protocol (DHCP), remain available to satisfy client requests while AD DS is stopped.
Restartable AD DS reduces the time that is required to perform certain operations. AD DS can be stopped so that updates can be applied to a domain controller. Also, administrators can stop AD DS to perform tasks, such as offline defragmentation of the Active Directory database, without restarting the domain controller. Other services that are running on the server and that do not depend on AD DS to function, such as Dynamic Host Configuration Protocol (DHCP), remain available to satisfy client requests while AD DS is stopped.
AD DS:
Database Mounting Tool
Although the Active Directory database mounting tool does not recover deleted objects by itself, it helps streamline the process for recovering objects that have been accidentally deleted. Before the Windows Server® 2008 operating system, when objects or organizational units (OUs) were accidentally deleted, the only way to determine exactly which objects were deleted was to restore data from backups. This approach had two drawbacks:
Although the Active Directory database mounting tool does not recover deleted objects by itself, it helps streamline the process for recovering objects that have been accidentally deleted. Before the Windows Server® 2008 operating system, when objects or organizational units (OUs) were accidentally deleted, the only way to determine exactly which objects were deleted was to restore data from backups. This approach had two drawbacks:
- Active Directory had
to be restarted in Directory Services Restore Mode to perform an
authoritative restore.
- An administrator could
not compare data in backups that were taken at different points in time
(unless the backups were restored to various domain controllers, a process
which is not feasible).
The
purpose of the Active Directory database mounting tool is to expose
AD DS data that is stored in snapshots or backups online. Administrators
can then compare data in snapshots or backups that are taken at different
points in time, which in turn helps them to make better decisions about which
data to restore, without incurring service downtime.
AD DS:
User Interface Improvements
AD DS user interface (UI) improvements provide new installation options for domain controllers. Furthermore, the updated Active Directory Domain Services Installation Wizard streamlines and simplifies AD DS installation.
AD DS user interface (UI) improvements provide new installation options for domain controllers. Furthermore, the updated Active Directory Domain Services Installation Wizard streamlines and simplifies AD DS installation.
AD DS
UI improvements also provide new management options for AD DS features
such as read-only domain controllers (RODCs). Additional changes to the
management tools improve the ability to find domain controllers throughout the enterprise.
They also provide important controls for new features such as the Password
Replication Policy for RODCs.
AD DS:
Owner Rights
Owner Rights is a well-known security principal that you can add to the DACL of an object to specify the permissions that are assigned to owners of objects in the directory service. This added security feature overrides the default behavior of owners of objects in the system. Because owners of objects (as specified in the security descriptor of the object) have WRITE_DAC permission, they can give rights to themselves and to other security principals as they see fit.
Owner Rights is a well-known security principal that you can add to the DACL of an object to specify the permissions that are assigned to owners of objects in the directory service. This added security feature overrides the default behavior of owners of objects in the system. Because owners of objects (as specified in the security descriptor of the object) have WRITE_DAC permission, they can give rights to themselves and to other security principals as they see fit.
The
Owner Rights security principal is specified using the well-known security
identifier (SID) S-1-3-4. For example, if the Owner Rights security principal
is located in the fabrikam.com domain, its distinguished name (also known as
DN) can be expressed this way: CN=Owner Rights,CN=WellKnown Security
Principals,CN=Configuration,DC=fabrikam,DC=com.
By
default, Owner Rights are not defined on objects. This means that the
pre–Windows Server 2008 behavior of owners having WRITE_DAC
permissions to the objects that they own still applies.
When
you add the Owner Rights security principal to objects, you can specify what
permissions are given to the owner of an object. For example you can specify in
the access control entry (ACE) of an object that the owner of a particular
object is given Read permissions or you can specify NULL permissions to an
object, which grants the owner of the object no permissions.
Post a Comment