Changes in Functionality from Windows Server 2003 with sp1 to Windows Server 2008
What settings have been added or changed?
Download 1.83 Mb.
|
- Navigate this page:
- Active Directory Lightweight Directory Services Role
- Who will be interested in AD LDS
- Are there any special considerations
- Do I need to change any existing code
- Who will be interested in this server role
- What new functionality does this server role provide
- Improved installation and administration experience
- Why is this functionality important
- Self-enrollment of AD RMS server
- How should I prepare for this change
- New AD RMS Administrative Roles
What settings have been added or changed?You configure Windows NT token-based Web Agent settings with the IIS Manager snap-in. To support the new functionality that is provided with Internet Information Services (IIS) 7.0, Windows Server 2008 AD FS includes user interface (UI) updates for the AD FS Web Agent role service. The following table lists the different locations in IIS Manager for IIS 6.0 or IIS 7.0 for each of the AD FS Web Agent property pages, depending on the version of IIS that is used.
 Note
There are no significant UI differences between the Active Directory Federation Services snap-in in Windows Server 2008 and the Active Directory Federation Services snap-in in Windows Server 2003 R2. Active Directory Lightweight Directory Services RoleThe Active Directory® Lightweight Directory Services (AD LDS) server role is a Lightweight Directory Access Protocol (LDAP) directory service. It provides data storage and retrieval for directory-enabled applications, without the dependencies that are required for Active Directory Domain Services (AD DS). AD LDS in the Windows Server® 2008 operating system encompasses the functionality that was provided by Active Directory Application Mode (ADAM), which is available for Windows® XP Professional and the Windows Server® 2003 operating systems. What does AD LDS do?AD LDS gives organizations flexible support for directory-enabled applications. A directory-enabled application uses a directory—rather than a database, flat file, or other data storage structure—to hold its data. Directory services (such as AD LDS) and relational databases both provide data storage and retrieval, but they differ in their optimization. Directory services are optimized for read processing, whereas relational databases are optimized for transaction processing. Many off-the-shelf applications and many custom applications use a directory-enabled design. Examples include: Customer relationship management (CRM) applications Human Resources (HR) applications Global address book applications AD LDS provides much of the same functionality as AD DS (and, in fact, is built on the same code base), but it does not require the deployment of domains or domain controllers. You can run multiple instances of AD LDS concurrently on a single computer, with an independently managed schema for each AD LDS instance or configuration set (if the instance is part of a configuration set). Member servers, domain controllers, and stand-alone servers can be configured to run the AD LDS server role. AD LDS is similar to AD DS in that it provides the following: Multimaster replication Support for the Active Directory Service Interfaces (ADSI) application programming interface (API) Application directory partitions LDAP over Secure Sockets Layer (SSL) AD LDS differs from AD DS primarily in that it does not store Windows security principals. While AD LDS can use Windows security principals (such as domain users) in access control lists (ACLs) that control access to objects in AD LDS, Windows cannot authenticate users stored in AD LDS or use AD LDS users in its ACLs. In addition, AD LDS does not support domains and forests, Group Policy, or global catalogs. Who will be interested in AD LDS?Organizations that have the following requirements will find AD LDS particularly useful: Application-specific directories that use customized schemas or that depend on decentralized directory management AD LDS directories are separate from the domain infrastructure of AD DS. As a result, they can support applications that depend on schema extensions that are not desirable in the AD DS directory—such as schema extensions that are useful to a single application. In addition, the local server administrator can administer the AD LDS directories; domain administrators do not need to provide administrative support. Directory-enabled application development and prototyping environments that are separate from the enterprise's domain structure Application developers who are creating directory-enabled applications can install the AD LDS role on any server, even on stand-alone servers. As a result, developers can control and modify the directory in their development environment without interfering with the organization's AD DS infrastructure. These applications can be deployed subsequently with either AD LDS or AD DS as the application's directory service, as appropriate. Network administrators can use AD LDS as a prototype or pilot environment for applications that will eventually be deployed with AD DS as its directory store, as long as the application does not depend on features specific to AD DS. Management of external client computers' access to network resources Enterprises that need to authenticate extranet client computers, such as Web client computers or transient client computers, can use AD LDS as the directory store for authentication. This helps enterprises avoid having to maintain external client information in the enterprise's domain directory. Enabling of earlier LDAP client computers in a heterogeneous environment to authenticate against AD DS When organizations merge, there is often a need to integrate LDAP client computers running different server operating systems into a single network infrastructure. In such cases, rather than immediately upgrading client computers running earlier LDAP applications or modifying the AD DS schema to work with the earlier clients, network administrators can install the AD LDS server role on one or more servers. The AD LDS server role acts as an interim directory store using the earlier schema until the client computers can be upgraded to use AD DS natively for LDAP access and authentication. Are there any special considerations?Since AD LDS is designed to be a directory service for applications, it is expected that the applications will create, manage, and remove directory objects. As a general-purpose directory service, AD LDS is not supported by such domain-oriented tools as: Active Directory Domains and Trusts Active Directory Users and Computers Active Directory Sites and Services However, administrators can manage AD LDS directories by using directory tools such as the following: ADSI Edit (for viewing, modifying, creating, and deleting any object in AD LDS) Ldp.exe (for general LDAP administration) Other schema management utilities Do I need to change any existing code?Applications that were designed to work with ADAM do not require changes in order to function with AD LDS. Active Directory Rights Management Services RoleFor Windows Server® 2008, Active Directory Rights Management Services (AD RMS) includes several new features that were not available in Microsoft® Windows® Rights Management Services (RMS). These new features were designed to ease administrative overhead of AD RMS and to extend its use outside of your organization. These new features include: Inclusion of AD RMS in Windows Server 2008 as a server role Administration through a Microsoft Management Console (MMC) Integration with Active Directory Federation Services (AD FS) Self-enrollment of AD RMS servers Ability to delegate responsibility by means of new AD RMS administrative roles Note
This topic concentrates on the features specific to AD RMS that are being released with Windows Server 2008. Earlier versions of RMS were available as a separate download. For more information about the features that were available in RMS, see Windows Server 2003 Rights Management Services (RMS) (http://go.microsoft.com/fwlink/?LinkId=68637). What does AD RMS do?AD RMS, a format and application-agnostic technology, provides services to enable the creation of information-protection solutions. It will work with any AD RMS-enabled application to provide persistent usage policies for sensitive information. Content that can be protected by using AD RMS includes intranet Web sites, e-mail messages, and documents. AD RMS includes a set of core functions that allow developers to add information protection to the functionality of existing applications. An AD RMS system, which includes both server and client components, performs the following processes: Licensing rights-protected information. An AD RMS system issues rights account certificates, which identify trusted entities (such as users, groups, and services) that can publish rights-protected content. Once trust has been established, users can assign usage rights and conditions to content they want to protect. These usage rights specify who can access rights-protected content and what they can do with it. When the content is protected, a publishing license is created for the content. This license binds the specific usage rights to a given piece of content so that the content can be distributed. For example, users can send rights-protected documents to other users inside or outside of their organization without the content losing its rights protection. Acquiring licenses to decrypt rights-protected content and applying usage policies. Users who have been granted a rights account certificate can access rights-protected content by using an AD RMS-enabled client application that allows users to view and work with rights-protected content. When users attempt to access rights-protected content, requests are sent to AD RMS to access, or “consume,” that content. When a user attempts to consume the protected content, the AD RMS licensing service on the AD RMS cluster issues a unique use license that reads, interprets, and applies the usage rights and conditions specified in the publishing licenses. The usage rights and conditions are persistent and automatically applied everywhere the content goes. Creating rights-protected files and templates. Users who are trusted entities in an AD RMS system can create and manage protection-enhanced files by using familiar authoring tools in an AD RMS-enabled application that incorporates AD RMS technology features. In addition, AD RMS-enabled applications can use centrally defined and officially authorized usage rights templates to help users efficiently apply a predefined set of usage policies.
You should review this section, and additional documentation about AD RMS, if you are in any of the following groups: IT planners and analysts who are evaluating enterprise rights management products IT professionals responsible for supporting an existing RMS infrastructure IT security architects who are interested in deploying information protection technology that provides protection for both data at rest and in motion
Are there any special considerations?AD RMS relies on Active Directory Domain Services (AD DS) to verify that the user attempting to consume rights-protected content is authorized to do so. When registering the AD RMS service connection point (SCP) during installation, the installing user account must have Write access to the Services container in AD DS. Finally, all configuration and logging information is stored in the AD RMS Logging Database. In a test environment, you can use the Windows Internal Database, but in a production environment, we recommend using a separate database server. What new functionality does this server role provide?AD RMS includes a number of enhancements over earlier versions of RMS. These enhancements include the following: Improved installation and administration experience. AD RMS is included with Windows Server 2008 and is installed as a server role. Additionally, AD RMS administration is done through an MMC, as opposed to the Web site administration presented in the earlier versions. Self-enrollment of the AD RMS cluster. AD RMS cluster can be enrolled without having to connect to the Microsoft Enrollment Service. Through the use of a server self-enrollment certificate, the enrollment process is done entirely on the local computer. Integration with AD FS. AD RMS and AD FS have been integrated such that enterprises are able to leverage existing federated relationships to collaborate with external partners. New AD RMS administrative roles. The ability to delegate AD RMS tasks to different administrators is needed in any enterprise environment and is included with this version of AD RMS. Three administrative roles have been created: AD RMS Enterprise Administrators, AD RMS Template Administrators, and AD RMS Auditors.
In the earlier versions of RMS, administration was done through a Web interface. In AD RMS, the administrative interface has been migrated to an MMC snap-in console. AD RMS console gives you all the functionality available with the earlier version of RMS but in an interface that is much easier to use. Why is this functionality important?Offering AD RMS as a server role that is included with Windows Server 2008 makes the installation process less burdensome by not requiring you to download AD RMS separately before installing it. Using an AD RMS console for administration instead of a browser interface makes more options available to improve the user interface. The AD RMS console employs user interface elements that are consistent throughout Windows Server 2008, which is designed to be much easier to follow and navigate. Additionally, with the inclusion of AD RMS administration roles, the AD RMS console displays only the parts of the console that the user can access. For example, a user who is using the AD RMS Template Administrators administration role is restricted to tasks that are specific to AD RMS templates. All other administrative tasks are not available in the AD RMS console. Self-enrollment of AD RMS serverServer enrollment in AD RMS is the process of creating and signing a server licensor certificate (SLC) that grants the AD RMS server the right to issue certificates and licenses. In earlier versions of RMS, the SLC had to be signed by the Microsoft Enrollment Service through an Internet connection. This required that either the RMS server had to have Internet connectivity to do online enrollment with the Microsoft Enrollment Service or be able to connect to another computer with Internet access that could do offline enrollment of the server. In AD RMS with Windows Server 2008, the requirement for AD RMS server to directly contact the Microsoft Enrollment Service has been removed. Instead, a server self-enrollment certificate is included with Windows Server 2008 that signs the AD RMS server's SLC. Why is this functionality important?Requiring the SLC to be signed by the Microsoft Enrollment Service introduced an operational dependency that many customers did not want to introduce into their environment. The Microsoft Enrollment Service is no longer required to sign the SLC. What works differently?Instead of requiring the Microsoft Enrollment Service to sign the AD RMS server's SLC, the server self-enrollment certificate, included with Windows Server 2008, can sign the SLC locally. The server self-enrollment certificate allows AD RMS to operate in a network that is entirely isolated from the Internet. How should I prepare for this change?When upgrading from RMS with Service Pack 1 (SP1) or later, the root cluster must be upgraded before the licensing-only cluster. This is required so that the licensing-only cluster receives the root cluster's new self-enrolled SLC. Integration with AD FSEnterprises are increasingly feeling the need to collaborate outside their enterprise boundaries and are looking at federation as a solution. Federation support with AD RMS will allow enterprises to leverage their established federated relationships to enable collaboration with external entities. For example, an organization that has deployed AD RMS can set up federation with an external entity by using AD FS and can leverage this relationship to share rights-protected content across the two organizations without requiring a deployment of AD RMS in both places. Why is this functionality important?In earlier versions of RMS, the options for external collaboration of rights-protected content were limited to Windows Live™ ID. Integrating AD FS with AD RMS provides the ability to establish federated identities between organizations and share rights-protected content. How should I prepare for this change?If you are interested in using AD FS with AD RMS, you must have federated trust between your organization and the external partners you would like to collaborate with before AD RMS is installed. Additionally, you must use the AD RMS client included with Windows Vista® or RMS Client with Service Pack 2 (SP2) to take advantage of the AD FS integration with AD RMS. RMS clients earlier than RMS Client with SP2 will not support AD FS collaboration. New AD RMS Administrative RolesTo better delegate control of your AD RMS environment, new administrative roles have been created. These administrative roles are local security groups that are created when the AD RMS role is installed. Each of these administrative roles has different levels of access to AD RMS associated with them. The new roles are AD RMS Service Group, AD RMS Enterprise Administrators, AD RMS Template Administrators, and AD RMS Auditors. The AD RMS Service Group holds the AD RMS service account. When the AD RMS role is added, the service account configured during setup is added to this administrative role automatically. The AD RMS Enterprise Administrators role allows members of this group to manage all AD RMS policies and settings. During AD RMS provisioning, the user account installing the AD RMS server role and the local administrators group are added to the AD RMS Enterprise Administrators role. As a best practice, membership of this group should be restricted to only user accounts that need full AD RMS administrative control. The AD RMS Templates Administrators role allows members of this group to manage rights policy templates. Specifically, AD RMS Template Administrators can read cluster information, list rights policy templates, create new rights policy templates, modify existing rights policy template, and export rights policy templates. The AD RMS Auditors role allows members of this group to manage logs and reports. This is a read-only role that is restricted to read cluster information, read logging settings, and run reports available on the AD RMS cluster.
Why is this functionality important?The new AD RMS administrative roles give you the opportunity to delegate AD RMS tasks without giving full administrative control over the entire AD RMS cluster. How should I prepare for this change?Customers who would like to deploy AD RMS in their organization will not have to do anything to prepare for this change. Optionally, it is recommended to create Active Directory security groups for each of these administrative roles and add them to their respective local security groups. This will give you the ability to scale your AD RMS deployment across several servers without having to add specific user accounts to each AD RMS server. Directory: uploads uploads -> 587 Return function, r i(X) r i(0) r i(1) r i(2) r i(3) 1 0 2 4 6 Thermal Station, I 2 0 1 5 6 3 0 3 5 6 10 uploads -> Department of science and humanities department of mathematics part-a questions and answers uploads -> The Case Against the nypd’s Quota-Driven ‘Broken Windows’ Policing What Is It? uploads -> For want of a nail uploads -> Ownership Models There are two different types of ownership models uploads -> Police Militarization uploads -> City of rising star regular meting thursday, july 14, 2016 uploads -> Township of winfield uploads -> Stop Militarizing Law Enforcement Act of 2014 uploads -> The Black Panther Party’s Ten-Point Program What We Want Now! Download 1.83 Mb. Share with your friends:
|