Deployment considerations for Group Policy

Deployment considerations for Group Policy



Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Deployment Considerations for Group Policy

This topic describes deployment issues related to managing Group Policy in enterprise environments. This includes interoperability issues such as handling a mix of client operating system versions, a mix of domain versions, as well as new features included with Windows Server 2003.

To view an item, click the appropriate link:
Applying Group Policy on different client operating systems

Using Administrative template files in mixed environments

Administering a mix of Windows 2000 and Windows Server 2003 domains

Upgrading Windows 2000 domains to Windows Server 2003 domains and interaction with Group Policy Modeling

Using Group Policy features across forests

Group Policy for sites

Using Group Policy and Internet Explorer enhanced security configuration

Applying Group Policy on different client operating systems

Group Policy can apply to client computers running any of the following operating systems or later:
Any version of Windows 2000.

Any version of Windows XP Professional.

Any version of Windows Server 2003.


Except for Local Group Policy objects (LGPOs), Group Policy requires Active Directory. In order for computer configuration settings to apply, the computer account must be in an Active Directory domain. In order for user configuration settings to apply, the user account must be in an Active Directory domain.

Group Policy is not applied to computers running any of the following operating systems:
Windows 95

Windows 98

Windows Millennium

Windows NT

Using Administrative template files in mixed environments

Administrative templates, (or .adm files), enable administrators to control registry settings using Group Policy. Windows comes with a predefined set of Administrative template files, which are implemented as text files (with an .adm extension), that define the registry settings that can be configured in a Group Policy object (GPO). These .adm files are stored in two locations by default: inside GPOs and in the %windir%\inf folder on the local computer.

As new versions of Windows are released, new policy settings are added. In addition to supporting these new settings, each successive version of Windows supports all registry policy settings that were available in earlier versions of Windows. For example, the Windows Server 2003 family supports all registry policy settings available in Windows 2000 and Windows XP.

It is important to understand that .adm files are not the actual settings that are deployed to client operating systems. The adm file is simply a template file that provides the friendly name for the setting and an explanation. This template file is used to populate the user interface. The settings that are deployed to clients are contained in the registry.pol file inside the GPO. On Windows XP and Windows Server 2003, each registry setting contains a "Supported on" tag that indicates which operating system versions support that policy setting. If a setting is specified and deployed to a client operating system that does not support that setting, the settings are ignored.

Because all successive iterations of .adm files include settings from earlier versions, and because there is no harm if a new setting is applied inadvertently to a computer running an earlier operating system that does not support that setting, it is recommended to always create and edit GPOs from a computer that has the latest .adm files available. Note that the behavior for handling .adm files in GPMC and the Group Policy Object Editor differs.
Handling .adm files in Group Policy Object Editor
The Group Policy Object Editor uses .adm files to display available policy settings in the Administrative Templates section of a GPO.

By default it attempts to read .adm files from the GPO (from the Sysvol on the domain controller). Alternatively, the .adm file can be read from the local workstation computer. This behavior can be controlled by a policy setting.

By default, if the version of the .adm file found on the local computer is newer (based on the time stamp of the file) than the version on the Sysvol, the local version is copied to the Sysvol and is then used to display the settings. This behavior can be controlled by a policy setting.

If the GPO contains registry settings for which there is no corresponding .adm file, these settings cannot be seen in the Group Policy Object Editor. However, the policy settings are still active and will be applied to users or computers targeted by the GPO.

Handling .adm files in GPMC
GPMC uses .adm files to display the friendly names of policy settings when generating HTML reports for GPOs, Group Policy Modeling, and Group Policy Results.

By default, GPMC uses the local .adm file, regardless of time stamp. If the file is not found, then GPMC will look in the GPO's folder on Sysvol.

The user can specify an alternate path for where to find .adm files. If specified, this takes precedence over the previous locations.

GPMC never copies the .adm file to the Sysvol.

Administering a mix of Windows 2000 and Windows Server 2003 domains

GPMC exposes features that are available in the underlying operating system. Because new features have been added to Group Policy since Windows 2000, certain features will only be available in GPMC depending on the operating system that has been deployed on the domain controllers. This section describes these dependencies. In general, there are three key issues that determine whether a feature is available in GPMC:
Whether the forest supports the Windows Server 2003 schema for Active Directory. Certain features are only available once the schema is upgraded. This is the first step that must be taken before any Windows Server 2003 domain controller can be deployed in an existing Windows 2000 forest. The schema is a forest-wide configuration and is upgraded by running ADPrep /ForestPrep. ADPrep is a utility included on the Windows Server 2003 CD. Note that it is possible to have the Windows Server 2003 schema in a forest with all Windows 2000 domain controllers.

Whether there is at least one domain controller in the forest that is running Windows Server 2003. Group Policy Modeling must be performed on a domain controller running Windows Server 2003.

Whether a domain contains the Windows Server 2003 domain configuration. This is implemented once ADPrep /DomainPrep is run in that domain. This is the first step that must be taken before any Windows Server 2003 domain controller can be deployed in an existing Windows 2000 domain.


Note that there is no dependency from the Group Policy perspective on whether a domain is in native mode or mixed mode.
Delegation of Group Policy Results and Group Policy Modeling

In order to delegate either Group Policy Modeling or Group Policy Results, the Active Directory schema in the forest must be the Windows Server 2003 schema. Note that you can use Group Policy Results even without this schema, but only users with local administrative privileges on the target computer can remotely access Group Policy Results data. Thus, if the forest does not have the Windows Server 2003 schema, the delegation pages in GPMC for organizational units and domains will not show these permissions.
Group Policy Modeling

Group Policy Modeling is a simulation that is performed by a service that can only run on a domain controller running Windows Server 2003 or later. As long as there is at least one domain controller running Windows Server 2003 in the forest, you can use Group Policy Modeling. GPMC will only show the Group Policy Modeling node in the user interface if the Windows Server 2003 schema is present.
WMI filtering

WMI filters are only available in domains that have the Windows Server 2003 configuration. Although none of the domain controllers need to be running Windows Server 2003, you must have run ADPrep /DomainPrep in this domain. Also note that WMI filters are only evaluated by clients running Windows XP, Windows Server 2003, or later. WMI filters associated with a Group Policy object will be ignored by Windows 2000 clients and the GPO will always be applied on Windows 2000. For more information, see WMI filtering using GPMC.

If ADPrep /DomainPrep has not been run in a given domain, the WMI Filters node will not be present, and the GPO scope tab will not have a WMI filters section.
Upgrading Windows 2000 domains to Windows Server 2003 domains and interaction with Group Policy Modeling

Group Policy Modeling is a new feature of Windows Server 2003 that simulates the resultant set of policy for a given configuration. The simulation is performed by a service that runs on Windows Server 2003 domain controllers. In order to perform the simulation in cross-domain scenarios, the service must have read access to all GPOs in the forest.

In a Windows Server 2003 domain (whether it is upgraded from Windows 2000 or installed as new), the Enterprise Domain Controllers group is automatically given read access to all newly created GPOs. This ensures that the service can read all GPOs in the forest.

However, if the domain was upgraded from Windows 2000, any existing GPOs that were created before the upgrade do not have read access for the Enterprise Domain Controllers group. When you click a GPO, GPMC detects this situation and notifies the user that Enterprise Domain Controllers do not have read access to all GPOs in this domain. To solve this problem, you can use one of the sample scripts provided with GPMC, GrantPermissionOnAllGPOs.wsf. This script can update the permissions for all GPOs in the domain. To use this script:
Ensure that the person running this script is either a Domain Admin or has permissions to modify security on all GPOs in the domain.

Open a command prompt and navigate to the %programfiles%\gpmc\scripts folder by typing:

CD /D %programfiles%\gpmc\scripts
Type the following:

Cscript GrantPermissionOnAllGPOs.wsf "Enterprise Domain Controllers" /Permission:Read /Domain:value

The value of domain parameter is the DNS name of the domain.
Using Group Policy features across forests

The Windows Server 2003 family introduces a new feature called Forest Trust that enables you to authenticate and authorize access to resources from separate, networked forests. With trusts established between forests, you can manage Group Policy throughout your enterprise, which provides greater flexibility especially in large organizations. For more information on forest trusts, see Forests in Group Policy Management Console.

This section describes Group Policy behavior in an environment with forest trust enabled:
It is not possible to link a GPO to a domain in another forest.

With Forest trust, it is possible that a user in forest B could log onto a computer in forest A. In this case, when the computer starts up, it will process policy for the computer configuration from Forest A, as usual. When a user from Forest B logs on, where they receive their policy settings from depends on the value of the Allow Cross-Forest User Policy and Roaming Profiles policy setting.

When this setting is Not Configured, no user-based policy settings are applied from the user's forest. Instead, loopback Group Policy processing will be applied, using the Group Policy objects scoped to the computer. Users will receive a local profile instead of their roaming profile.

When this setting is Enabled, the behavior is exactly the same as Windows 2000 Server, User policy is applied from the user's forest and a roaming user profile is allowed from the trusted forest.

When this setting is Disabled, the behavior is the same as Not Configured.

This setting is available on Windows Server 2003 located at: Computer Configuration\Administrative Templates\System\Group Policy\Allow Cross-Forest User Policy and Roaming Profiles.

It is possible to deploy Group Policy settings to users and computers in the same forest, but have those settings reference servers in other trusted forests. For example, the shares that host software distribution points, redirected folders, logon scripts, and roaming user profiles could be in another trusted forest.

Group Policy Modeling requires that both the user and the computer be in the same forest. If you want to simulate a user from Forest A logging on to a computer in Forest B, you must perform two separate Group Policy Modeling simulations: one for the user configuration and the other for the computer configuration.

Delegation across forests is supported for managing Group Policy. For example, you can delegate to someone in Forest B the ability to perform Group Policy Modeling simulations on objects in Forest A.

Group Policy for sites

GPOs that are linked to Active Directory site objects affect all computers in the site. Therefore, any Group Policy object that is linked to a site is applied to all computers in that site, without regard to which domain (in the forest) contains the computers.

This means that computers in multiple domains within a forest can potentially receive the same Group Policy object when you use site-linked GPOs. It also means that a given client computer could receive GPOs from multiple domains in the forest. Note that the GPO exists as a stored entity only in a single domain and it must be read from that domain when the affected clients read their site-linked Group Policy.

If multiple domains are set up across wide area network (WAN) boundaries, the site configuration should take this into account. If it does not, the computers in another domain access a site-linked GPO across a WAN link. This increases the processing time for Group Policy.

In general, it is recommended that you link GPOs to domains and organizational units rather than sites.
Using Group Policy and Internet Explorer enhanced security configuration

Windows Server 2003 includes a new default security configuration for Internet Explorer, called Internet Explorer Enhanced Security Configuration (ESC). ESC impacts the Security Zones and Privacy settings within the Internet Explorer Maintenance settings of a GPO. The Security Zones and Privacy settings can either be ESC enabled or not.
When you edit settings for Security Zones and Privacy settings in a GPO from a computer where ESC is enabled, that GPO will contain ESC-enabled settings. When you look at the HTML report for that GPO, the Security Zones and Privacy header will be appended with the text (Enhanced Security Configuration enabled).

When you edit settings for Security Zones and Privacy settings in a GPO from a computer where ESC is not enabled , that GPO will contain ESC disabled settings. ESC is not enabled on any computer running Windows 2000 or Windows XP, nor on computers running Windows Server 2003 where ESC has been explicitly disabled.


ESC settings deployed through Group Policy will only be processed on and applied by computers where ESC is enabled. ESC settings will be ignored on computers where ESC is not enabled (all computers running Windows 2000 and Windows XP, and Windows Server 2003 computers where ESC has been explicitly disabled). The converse is also true: A GPO that contains non-ESC settings will only be processed on and applied by computers where ESC is not enabled.

remote assistance

Windows XP and .NET:

Microsoft Corporation


The release of Windows® XP comes at a time of transition and growing maturity of the Internet.

The Web has grown to include many millions of sites on almost every conceivable topic. Although more information is available than ever before, the opportunities to fully manage and customize it have remained limited. Until now.

The Microsoft® .NET initiative aims to turn this around through a framework built around XML-based Web services that interoperate via existing open Internet protocols such as TCP/IP and HTTP.

And at the heart of the .NET vision for knowledge workers, business users, and consumers lies the new client operating system, Windows XP.

The successor to Windows 2000 Professional and Windows Millennium is designed to serve as the central information hub for services and act as the smartest of all devices amid a growing constellation of Pocket PCs, mobile phones, Tablet PCs, digital cameras, and other devices.

Buildup to the Microsoft Windows Server System

A lot has changed since the computing experience was safely contained within the walls of organizations. Computing has advanced from the stand alone PC to the Local Area Network and the Internet.

Now employees may be located across the globe. They need to interact with partners, suppliers, and customers, using the Internet as a connectivity medium.
The challenge: getting applications to talk to other applications

Having a ubiquitous set of simple standards for connectivity was essential to the success of the Internet. These standards such as TCP/IP were broadly acceptable, ready to use, and very decentralized. But although the Web has revolutionized the way users talk to applications, it's done very little for how applications talk to applications. The .NET initiative aims to change that.
The solution: XML Web services

XML Web services allow applications to communicate and share data over the Internet, regardless of operating system or programming language. It is this simple premise that drives the Windows Server System and underlies how Windows XP sits at the center of your data and information.

The .NET Framework

The programmatic backbone of this emerging platform is called the .NET Framework. It is the culmination of several years of research and development aimed at simplifying the process of building, deploying, and maintaining applications. Development of the framework is the result of various trends including:

*Distributed Computing. The need to simplify application development through a remoting architecture based on open standards such as HTTP, XML, and SOAP.

*Componentization. The need to simplify the integration of components so that they can be more easily reused, developed, and deployed in mixed environments that require interoperability.

*Maturity factors. Development of large scale Web applications has resulted in the need for Web services that support availability, manageability, scalability, and interoperability.

*Enterprise services. The need to develop scalable enterprise applications without having to write extra code for security, managed transactions, or pooling.

What's in the Windows Server System
Windows XP is an essential piece of the Windows Server System and takes its place alongside other client devices as shown in Figure 1 below.

























.NET Experiences

.NET experiences represent a dramatically more personal, integrated computing experience. Using connected XML Web services, .NET experiences are centered around the user, integrating their data and preferences with a range of services into a unified, personalized experience – all delivered through a smart device.

Microsoft will deliver user experiences for knowledge workers, consumers, enterprises, small businesses, and developers. Some products that will become .NET experiences are future versions of Microsoft Office, MSN® Internet access, bCentral™ small business portal, and Visual Studio® .NET. These .NET experiences will pull together XML Web services and client software to meet specific user needs presented in an integrated way.

Clients

Powerful client software such as the .NET Compact Framework, Windows CE, and Windows XP enable a host of smart devices—PCs, laptops, workstations, phones, handheld computers, Tablet PCs, game consoles, and other devices to operate in the .NET universe. Through the use of this software, smart devices harness the power of the Internet providing you with a compelling and immersive experience while giving you more control over their information.

Services

In addition to developer creation of XML Web services, Microsoft is creating a core set of building block services that perform routine tasks and act as the backbone for developers to build upon.

The first set of XML Web services being built, codenamed "HailStorm", are user-centric services oriented around people, rather than specific devices, networks, or applications. "HailStorm" is based upon the Microsoft Passport user authentication system. With "HailStorm", users receive relevant information, as they need it, delivered to the devices they're using, based on preferences they have established.

Servers The Microsoft® Windows Server System™, including the Windows 2000 Server family, make up the Microsoft .NET server infrastructure for deploying, managing, and orchestrating XML Web services. Designed with mission-critical performance in mind, they provide enterprises with the agility they need to integrate their systems, applications, and partners through XML Web services, and the flexibility to adapt to changing business requirements. The Windows Server System integrated software products include:

*Application Center 2000 to deploy and manage highly available and scalable Web applications.
*BizTalk Server 2000 to build XML-based business processes across applications and organizations.
*Commerce Server 2000 for quickly building scalable e-commerce solutions.
*Content Management Server 2001 to manage content for dynamic e-business Web sites.
*Exchange Server 2000 to enable messaging and collaboration, anytime, anywhere.
*Host Integration Server 2000 for bridging to data and applications on legacy systems.
*Internet Security and Acceleration Server 2000 for secure, fast Internet connectivity.
*Mobile Information 2001 Server to enable application support by mobile devices like cell pones.
*SharePoint Portal Server 2001 to find, share, and publish business information.
*SQL Server 2000 to store, retrieve, and analyze structured XML data.

Tools
The .NET developer tools provide the fastest and easiest way to create experiences and XML Web services. Visual Studio .NET and the .NET Framework provide the tools that make it simple for developers to build applications that expose and consume XML Web services, with extensive support for multiple programming languages and devices.
Windows XP and .NET Today
With native support for XML and SOAP, Windows XP enables a new set of services on the PC and gets your computer ready to take advantage of the .NET Framework and the upcoming Windows Server™ 2003, the successor to Windows 2000 Server.

Windows XP includes a number of features enabled by XML-based Web services:

*Remote Assistance
*Windows Messenger
*Online Print Ordering Wizard
*Web Publishing Wizard
*Passport authentication
Remote Assistance
Remote assistance uses Terminal Services technology, allowing a helper to assist you via a remote Terminal Services session. When you initiate a request for help, Remote Assistance sends an XML-based encrypted ticket to the helper who is prompted to accept the invitation, as shown in Figure 2 below. The helper can remotely connect to a problem-PC and view the screen directly to fix the problem.


For more information about Remote Assistance, see Get Help When You Need it at http://www.microsoft.com/windowsxp/using/helpandsupport/learnmore/remoteassist/intro.mspx.






Windows Messenger

The instant messaging client included with Windows XP contains the ability to access information about tab partners. This will allow users to more easily perform a variety of tasks – from monitoring online auctions to accessing account information for many of their bills. It can also launch a Remote Assistance request, as shown in Figure 3 below.











For more information about Windows Messenger, see Experience Real Time Communication at http://www.microsoft.com/windowsxp/pro/evaluation/overviews/communication.asp.




Online Print Ordering Wizard

As shown in Figure 4 below, users can order photos from any picture folder such as My Pictures. XML is used to describe the services that are dynamically downloaded as well as describe data contained in the wizard process. Third parties can plug their photo printing service and use XML to trade data across the wire.











Web Publishing Wizard

As shown in Figure 5 below, users can publish files to the Web using the wizard available in the left frame from most folders in Windows XP. Similar to the online print ordering wizard, XML is used to describe the services that are downloaded as well as describe the data in the wizard itself.






For more information about how XML is used in the Online Print Ordering and Web Publishing wizards, see Building a Site for Web Publishing and Print Ordering at http://www.microsoft.com/whdc/archive/webwizard.mspx.


Passport authentication

Windows XP makes it easier to use the .NET Passport authentication service, allowing you to securely login to numerous e-commerce Web sites without having to remember additional user names and passwords. This can streamline other services such as the Web publishing and online print ordering services that require authentication. You can access Passport via the .NET Passport Wizard as shown in Figure 6 below.










Passport works by storing your credentials on a server. What makes this a Web service? When you visit a site that subscribes to the Passport authentication service, your credentials are automatically entered on that site. The site operators benefit by not having to implement their own login process.

Personal information is protected by powerful encryption technology and strict privacy policies, and you are always in control of the services that have access to your personal information, including your e-mail and mailing addresses. Passport is safe to use on public or shared computers.
The PC as smart client

With Windows XP, tasks that used to require several steps and knowledge of computer processes can take place automatically. This will make many computing tasks much simpler and enable more people to use computers effectively.

Most people have witnessed this type of functionality first hand in other areas of life such as the supermarket checkout counter. Once an item is scanned, the system recognizes exactly what it is and how much it costs. But sometimes a scan doesn't work and an item must be entered manually and the checkout line grows longer and longer. In some ways, using a computer has been a lot like a grid locked checkout line; advanced tasks required advanced knowledge and took more time to complete. You had to be smart because your computer wasn't.

Windows XP turns this equation around by making your computer perform more like a smart machine than a dumb terminal. In Windows XP, some increasingly common tasks will be much more automated. Plug a digital camera into your computer and Windows XP will recognize it giving you options for tasks associated with the device: download, e-mail, or publish pictures to the Web.

In the emerging interconnected world of PCs and devices, Windows XP enables your computer to become the central information hub that puts you in control of tasks, information, and services.

The value of the smart client

The PC sits at the center of the growing constellation of devices whose success depends on connectivity with the PC. The Palm or Pocket PCs succeed because they're smart about synchronizing with the information you care about on your PC. If your Palm or Pocket PC was a standalone island of data, it would be a lot less interesting. Likewise, the RIM Blackberry device has proliferated because it's smart about getting to your e-mail.

Contrast that with dumb devices like the network computer. That device hasn't been particularly successful because it's fundamentally a dumb terminal without any significant processing power of its own. You can dress it up, but you can't take the "dumb" out of the dumb terminal.

Windows XP and .NET Tomorrow

Windows XP lets you take advantage of the emerging model of applications built around interoperability via the Internet. One of the central goals of the Windows Server System is to enable interoperability of applications via lightweight, simple, and open protocols such as SOAP that can run on existing TCP/IP and HTTP protocols.

Excitement among developers for the Windows Server System is high because it introduces a new infrastructure that simplifies application development, providing the tools to make applications more reliable, secure, and easier to deploy.
XML Web Services Scenarios

End users, IT pros, business users, and others will be able to experience new ways of using their PC through XML Web services. Here is a preview of the types of services that might be available in the near future:

*Printing to your local copy shop. Using XML Web services, standard word processing programs could integrate with a copy center allowing individuals to print a selected document, pay for it and have it sent to the proper location – all from the convenience of their office or home. Because the service would be exposed and consumed using XML and SOAP, it is possible for the chain of copy centers to easily provide the service to a wide variety of devices and programs.
*Extending PC-based information to a Web Service. Information you currently associate with your PC could be accessed via an XML Web service. For example, a Favorites service can let you log on anywhere and still access all your Favorites from your browser. You can check out a prototype of this service developed by the Microsoft MSDN® Architectural Samples team at the fictional company, Cold Rooster Consulting.
*Easing and simplifying e-commerce. Complicated business-to-business transactions could be completed from a standardized user interface right on your desktop. For example, you might use an XML Web service designed to optimize costs of office supplies. The service could be configured to get the best price for paper clips from one supplier and the best price for pencils from another supplier. The service would work behind the scenes to locate best prices, initiate and complete orders, and other processing tasks.
*Getting customized information for free. Some XML Web services will be available for free over the Internet. For example, instead of using Windows XP to read information on Web sites, you could use a Web service that runs customized applications tracking highly specific queries.
*Getting customized information at work. In many organizations, internal communications generates a great deal of information pushed out to employees without much customization. You might be getting lots of information that isn't customized for you. For example, if you work in a book store marketing department you probably want a different view into sales information than employees who work on the warehouse floor. An XML Web service could deliver the same type of information—but customized according to the appropriate user interface and relevant categories. There would be no need to attempt to duplicate the information or spend extra time customizing it for different audiences; the XML Web service would perform this task automatically.

Interoperability

Key to the success of XML Web services in the enterprise is the fact that they are built around open, simple, and lightweight protocols. This permits a high level of interoperability between different operating systems and platforms, delivering flexibility now and in the future. For example, the human relations department could use one platform while the Benefits department uses another. Via an XML Web service, such information could be exchanged and processed regardless of the platform.
"HailStorm"

"HailStorm" is the codename for a set of core XML Web services provided by Microsoft that are designed to help you manage a variety of different types of personal information. "HailStorm" services are oriented around people, instead of around a specific device, application, service, or network. With "HailStorm," information that you may currently store on your PC can become available to you anytime and from any device, a benefit that gives you more control over your data. "HailStorm" also protects personal information by allowing you to control who can have access to it. For more information about "HailStorm", see Building User-Centric Experiences: An Introduction to Microsoft "HailStorm" at http://www.microsoft.com/net/


Summary

Windows XP sits at the center of the emerging .NET technology enabling the PC to consume and process XML-based Web services. This paper is intended to show how Windows XP works in the context of the Windows Server System.

Windows XP can power PCs, laptops, workstations, and Tablet PCs In addition to Windows XP, some of the .NET client software that Microsoft will offer include: Windows CE, Windows Embedded, and Microsoft Windows Server™ 2003. This software will power PCs, laptops, workstations, smart phones, handheld computers, Tablet PCs, and Xbox™ video game consoles.


See the following introductory articles about .NET:

*Introducing Microsoft .NET at http://www.microsoft.com/net/basics/whatis.asp
*Building User-Centric Experiences: An Introduction to Microsoft "HailStorm" at http://www.microsoft.com/net/
*Next Generation Business Integration: The Advantages of Microsoft .NET at http://www.microsoft.com/net/business/nextgenbiz.asp

See the following Microsoft portal sites about .NET:

*MSDN's .NET Developer Center at http://www.msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000519
*TechNet's .NET Resource Center at http://www.microsoft.com/technet/archive/itsolutions/net/default.mspx.
*Microsoft .NET home page at http://www.microsoft.com/net/

See the following demonstration Web service:

*Favorites Web Service by the MSDN fictional company, Cold Rooster Consulting at http://www.coldrooster.com.

For the latest information on Windows XP, check out our Web site at http://www.microsoft.com/windowsxp.

3D UNIVERSE

Carrara 7 Carrara 7 lavishes speed and power that enables users to create more freely and deliver outstanding results under tight deadlines. Now, there is a single tool for figure posing and animation combined with modeling, terrain-building, physics, and rendering that works with a large array of 3D assets.

Carrara 7

Bryce 6.1 Bryce is an award winning, fun, feature-packed 3D modeling and animation package designed to allow new users to quickly create and render stunning 3D environments. Bryce combines exceptional power with an innovative interface for incredible ease of use.

Mimic Lite Mimic 3 Lite is a fun, easy and powerful 3D facial animation solution. You can use it in conjunction with DAZ Studio and Poser, or you can use it as a stand-alone by rendering movies directly out of Mimic. Mimic 3 Lite is powerful enough for professionals yet easy enough for younger customers, too.

3d FOR ART

3D SOFTWARE

Carrara 3D Express Carrara 3D Express introduces you to the world of 3D like no other software can. With an easy-to-use interface and plenty of presets to get you off to a quick start, you'll soon be creating your own 3D portraits, landscape art, and animations.

Carrara 3D Express

freelacer

ICT free lancer available for the best services and delivery on time just contact

ttekke4@ahoo.com

for detailed info

Binary Differential Replication

System Center Configuration Manager 2007

Binary Differential Replication, sometimes known as "delta replication," is used by Configuration Manager 2007 to update package source files with a minimum of additional network traffic.

When Configuration Manager 2007 updates the source files for a package, and the source files have already been distributed, it sends the parts of the package that have changed since the last time the package was sent (originally, as an update, or as a refresh). This minimizes the network traffic between sites, especially when the package is large and the changes are relatively small. A file is considered to be changed if it has been renamed, moved, or its contents have changed.

The originating site keeps the differences between the current version of a package and the previous five versions. If a child site or distribution point has one of the previous five versions of the package, the originating site will send the appropriate changes to that site. If the child site has an older version of the package, the originating site will send the entire package.

If the originating site sends the changed files for a package but the receiving site no longer has the package, or the package has been altered at that site, the receiving site will send a status message to the originating site reporting the problem.Note
In order for Configuration Manager 2007 to use binary differential replication, all receiving sites must first have received at least the initial version of the package. Until all receiving sites have the initial version, Configuration Manager 2007 will not use differential replication.


Care should be taken when distributing changes to a package's source files. If the path to a receiving site is closed, it is important that you not attempt to update the distribution point multiple times before the site address is again available. Each update will include the files from the previous update because the receiving sites will not yet have the previous update. As a result, the updates will include multiple redundant files, wasting network bandwidth.Note

The processing time for large packages can take an extended period of time (20-30 minutes in some cases or even longer, depending on the size of the package).

During this package compression/decompression and hashing/signature-creating process, distmgr.log might appear to be idle, even though the process is continuing.

Joining a Windows Vista Wireless Client to a Domain

Joining a Windows Vista Wireless Client to a Domain

Wireless client computers running Microsoft® Windows Vista™ can use a temporary wireless profile to obtain connectivity to a secure wireless network and join the Active Directory domain. This temporary wireless profile, known as a bootstrap wireless profile, requires the connecting user to manually specify their domain user account credentials and does not validate the certificate of the Remote Authentication Dial-in User Service (RADIUS) server. After joining the domain, the wireless client uses a new wireless profile that automatically leverages the credentials of the computer and user account and validates the credentials of the RADIUS server. This article describes three methods of configuring a bootstrap wireless network profile.

Introduction

Wireless clients need either domain credentials (name/password) or a certificate to perform authentication for secure wireless access. To join the domain and receive domain credentials or certificates, wireless client computers need a successful connection to the wireless network that contains the domain controllers of the domain. To access a secure wireless network and join a computer to a domain, the wireless client user must manually provide their domain user name and password. Once connected to the wireless network, the wireless client user can join the computer to the domain.

In 802.1X-authenticated wireless networks, wireless clients need to provide security credentials that are authenticated by a RADIUS server. These credentials could include a username and password (for Protected EAP [PEAP]-Microsoft Challenge Handshake Authentication Protocol version 2 [MS-CHAP v2]) or certificates (for EAP-Transport Layer Security [TLS]). For either PEAP-MS-CHAP v2 or EAP-TLS, the wireless client also validates a computer certificate sent by the RADIUS server during the authentication process. This is the default behavior of the Windows wireless client. This behavior can be disabled, but is not recommended in production environments.

If the RADIUS server is using computer certificates from a commercial public key infrastructure (PKI), such as VeriSign, Inc., and the root certification authority certificate for the RADIUS server's computer certificate is already installed on the wireless client, the wireless client can validate the RADIUS server's computer certificate, regardless of whether the wireless client has joined the Active Directory domain.

If the RADIUS server is using computer certificates from a private PKI that is integrated with Active Directory (such as one that is based on Windows Server® 2003 Certificate Services), a wireless client that has not yet joined the domain does not have the root CA certificate of the RADIUS server's computer certificate and the authentication process by default will fail. After the wireless client has joined the domain, the root CA certificate of the RADIUS server's computer certificate is automatically installed.

This article describes methods that configure Windows Vista-based wireless clients with a wireless profile to perform manual PEAP-MS-CHAP v2 authentication but not validate the RADIUS server's computer certificate. After connecting to the wireless network, the wireless client computer joins the domain and receives the appropriate root CA certificate. The computer user (manually) or the IT administrator (through Group Policy) can reconfigure the wireless profile so that PEAP-MS-CHAP v2 authentication validates the RADIUS server's computer certificate and automatically uses domain credentials.


Methods for Joining a Wireless Client to a Domain

This section describes the following methods for joining a wireless client to a domain:

IT staff joins a wireless computer to the domain and configures a Single Sign On bootstrap wireless profile

User configures their wireless computer with a bootstrap wireless profile using an XML file and joins the domain

User manually configures wireless computer with bootstrap wireless profile and joins the domain
IT Staff Joins Wireless Computer to the Domain and Configures a Single Sign On Bootstrap Wireless Profile

In this method, an IT administrator joins the wireless computer to the domain before distributing it to the user. When the user starts the computer, the credentials that they manually specify for the user logon are used to both establish a connection to the wireless network and log on to the domain.

The following are the steps for this method:

An IT administrator joins the new wireless computer to the domain (for example, through an Ethernet connection that does not require IEEE 802.1X authentication) and adds a bootstrap wireless profile to the computer with the following settings:

PEAP-MS-CHAP v2 authentication

Validate RADIUS server certificate disabled

Single Sign On enabled

Single Sign On is a new feature for Windows Vista wireless clients that performs 802.1X authentication based on the network security configuration during the user logon process. For this bootstrap wireless profile, the IT administrator specifies that Single Sign On perform 802.1X authentication immediately before user logon.

The IT administrator distributes the new wireless computer to the user.

When the user starts the computer, Windows Vista prompts the user to enter their domain user account name and password. Because Single Sign On is enabled, the computer uses the domain user account credentials to first establish a connection with the wireless network and then log on to the domain.

Single Sign On is required for this bootstrap wireless profile because even though the computer is joined to the domain, the user has never logged on to the computer. If the computer does not have a network connection when the user attempts to log on for the first time, the logon will fail because the computer is unable to verify the user account credentials with a domain controller. Therefore, the network connection must be established first. Single Sign On uses the same user account credentials to establish a wireless connection and to log on to the domain. After the user has successfully logged on, subsequent user logons can utilize cached credentials.
User Configures Their Wireless Computer with a Bootstrap Wireless Profile Using an XML File and Joins the Domain

In this method, the user configures their wireless computer with a bootstrap wireless profile using an XML file and script that has been configured by an IT administrator. The bootstrap wireless profile configured by the XML file allows the user to establish a wireless connection and then join the domain.

The following are the steps for this method:

An IT administrator configures another Windows Vista-based wireless computer with a bootstrap wireless profile that uses PEAP-MS-CHAP v2 authentication with the validation of the RADIUS server certificate disabled.

The IT administrator extracts the bootstrap wireless profile to an XML file with the netsh wlan export profile command (see "Appendix A: Configuring a Bootstrap Wireless Profile" in this article) and creates a script file to execute that will automatically add the profile on the user's computer.

The IT administrator distributes the new wireless computer, the XML file containing the bootstrap wireless profile, and the script file to the user using an appropriate method. The script file contains the netsh wlan add profile XML_File_Name Connection_Name command.

For example, the XML file can be stored on a USB flash drive with a script for the user to run to add the bootstrap wireless profile.

The user starts the computer and performs a logon using a local computer account.

The user runs the script file to add the bootstrap wireless profile.

After the script is run, Windows Vista attempts to connect to the wireless network. Because the settings of the bootstrap wireless profile specify that the user must provide credentials, Windows Vista prompts the user for an account name and password.

The user types their domain user account name and password and the Windows Vista client computer connects to the wireless network.

The user joins the Active Directory domain. For more information, see "Appendix B: Joining a Windows Vista client to a Domain" in this article.
User Manually Configures Wireless Computer With a Bootstrap Profile and Joins the Domain

In this method, the user manually configures their wireless computer with a bootstrap wireless profile based on instructions from an IT administrator. The bootstrap wireless profile allows the user to establish a wireless connection and then join the domain.

The following are the steps for this method:

The IT administrator distributes to the user the instructions for configuring a bootstrap wireless profile that uses PEAP-MS-CHAP v2 authentication with the validation of the RADIUS server certificate disabled.

The user starts the computer and performs a logon using a local computer account.

The user executes the steps in the instructions to configure the bootstrap wireless profile (see "Appendix A: Configuring a Bootstrap Wireless Profile" in this article).

After the bootstrap wireless profile is configured, Windows Vista attempts to connect to the wireless network. Because the settings of the bootstrap wireless profile specify that the user must provide credentials, Windows Vista prompts the user for an account name and password.

The user types their domain user account name and password and the Windows Vista client computer connects to the wireless network.

The user joins the Active Directory domain. For more information, see "Appendix B: Joining a Windows Vista client to a Domain" in this article.

Configuring a Bootstrap Wireless Profile

To configure a bootstrap wireless profile, do the following:

From the Connect to a network dialog box, click I don't see what I want to connect to. You can access the Connect to a network dialog box from many locations in Windows Vista, including the following:

From the wireless connection icon in the notification area of the desktop

From the Connect/disconnect wireless networks link in Control Panel-Network Connections

From the context menu of a wireless network adapter in Control Panel-Network Connections

In the Select a connection option page, click Set up a network.

In the Enter information for the wireless network you want to add page, configure the following:

Network name Type the name of the wireless network.

Security type Select the method used to authenticate a connection to the wireless network (WEP (802.1x), WPA-Enterprise, or WPA2-Enterprise).

Encryption type Select the method used to encrypt data frames sent over the wireless network (WEP, TKIP, or AES).

Click Next.

Click Change connection settings.

Click the Security tab and select the Protected EAP (PEAP) method under Choose a network authentication method. Click Settings.

In the Protected EAP (PEAP) Properties dialog box, clear the Validate server certificate check box.

Click OK twice, and then click Close.

To export the settings of this bootstrap wireless profile to an XML file, type the following command:

netsh wlan export profile XML_File_Name Profile_Name Connection_Name

XML_File_Name is the name of the XML file that will store the wireless profile settings.

Profile_Name is the name of the wireless profile being exported.

Connection_Name is the name of the wireless adapter for which the wireless profile has been configured.


B: Joining a Windows Vista client to a Domain

After successfully connecting to the secure wireless network, use Control Panel-System to do the following:

Under Computer name, domain, and workgroup settings, click Change settings.

From the System Properties dialog box, click Change.

In the Computer Name Changes dialog box, type the computer name in Computer name. Click Domain and type the Active Directory domain name.

Click OK.

When prompted, type your domain name and password to join the computer to the domain.

Restart the computer when prompted.

When computer is restarted, it automatically authenticates to the wireless network using the computer's domain account credentials or certificate.


For More Information

For more information, consult the following resources:

Connecting to Wireless Networks with Windows Vista

Wireless Networking Web page

freelancer out

WIRELESS

802.1X Authenticated Wireless Access Design

Wireless networking offers users a high degree of mobility and provides a networking option when traditional wired networks are impractical. The Windows Server® 2008 operating system provides the networking services needed to deploy a secure and manageable wireless local area network (WLAN) infrastructure for network environment ranging from a small business to an enterprise. This guide provides comprehensive guidance to help you design an 802.1X authenticated wireless access solution.

Wireless access can provide the following benefits:

* Strong authentication. IEEE 802.1X was a standard that existed for Ethernet switches and was adapted to 802.11 wireless LANs to provide much stronger authentication than what was provided in the original 802.11 standard. Wireless network authentication can be based on different EAP authentication methods such as those using secure password (the user account name and password credentials) or a digital certificate. IEEE 802.1X prevents a wireless node from joining a wireless network until the node has performed a successful authentication. Additionally, a component of mutual authentication in EAP prevents wireless users from connecting to rogue wireless access points (APs), rogue NPS servers.

Although 802.1X authenticated access is optimal for medium and large wireless LANs, it can also be used for small organizations that require strong security. An 802.1X authenticated wireless access infrastructures consists chiefly of servers running Network Policy Server (NPS) and an account database such as the Active Directory® Domain Service (AD DS) account database. IEEE 802.1X uses Extensible Authentication Protocol (EAP).

* Infrastructure flexibility. In general, WLANs can extend or replace a wired infrastructure in situations where it is costly, inconvenient, or impossible to lay cables. A wireless LAN can connect the networks in two buildings that are separated by physical obstacles or financial constraints. You can also use wireless LAN technologies to create a temporary network, which is in place for only a specific amount of time. Additionally, deploying a wireless network, in instances where a company needs to rapidly expand their workforce, can be a more efficient and cost effective alternative than installing the physical cabling required for a traditional Ethernet network. And even if no wireless infrastructure is present, wireless portable computers can still form their own ad hoc networks to communicate and share data with each other.

* Mobility and productivity. Wireless access can increase productivity for employees that require mobility. Mobile users who are equipped with a portable computer can remain connected to the network. This enables the user to change locations—to meeting rooms, hallways, lobbies, cafeterias, classrooms, and so forth—and still have access to network resources. Without wireless access, the user must carry Ethernet cabling and is restricted to working near a network jack. Wireless LAN networking is a perfect technology for environments where movement is required.


Prerequisites

Following are the requirements for deploying a wireless access infrastructure by using the scenario documented in this guide:

* Before deploying this scenario, you must first purchase and install 802.1X-capable wireless APs to provide wireless coverage in the locations you want at your site.

* Active Directory Domain Services (AD DS) is installed, as are the other network technologies, according to the instructions in the Windows Server 2008 Foundation Network Guide.


* Server certificates are required when you deploy the Protected Extensible Authentication Protocol Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) certificate-based authentication method. For information about deploying server certificates, see Foundation Network Companion Guide: Deploying Server Certificates.

* Server certificates and computer and user certificates are required when you deploy Extensible Authentication Protocol-Transport Layer Security (EAP-TLS). For information about deploying user and computer certificates, see Foundation Network Companion Guide: Deploying Computer and User Certificates. You can view Foundation Network Companion Guide: Deploying Computer and User Certificates online in the Windows Server 2008 Technical Library at http://go.microsoft.com/fwlink/?LinkId=113884. You can download Foundation Network Companion Guide: Deploying Computer and User Certificates in Word format at the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkId=115742.



* You or someone else in your organization is familiar with the IEEE 802.11 standards that are supported by your wireless APs and the wireless network adapters installed in the client computers on your network. For example, the must be familiar with radio frequency types, the personal and enterprise editions of 802.11 wireless authentication (Wi-Fi Protected Access [WPA] and WPA version 2 [WPA2]), and ciphers (such as Advanced Encryption Standard [AES] and Temporal Key Integrity Protocol [TKIP]).

This is a step-by-step approach to help you decide which design best fits your wireless access needs and to help you create a design based on the most common wireless design goals. The two scenarios are:

* Wireless access by using PEAP-MS-CHAP v2 for secure password authentication. This design is well suited to small businesses and medium organizations. Secure password authentication provides strong security, and uses domain account credentials (user name and password) for client authentication. When deploying wireless access by using PEAP-MS-CHAP v2, you can either purchase certificates from a public certification authority (CA), such as VeriSign, or deploy a private CA on your network by using Active Directory Certificate Services (AD CS).

* Wireless access by using either EAP-TLS or PEAP-TLS for authentication using digital certificates. This design is well suited to medium- and enterprise-sized networks. Digital certificates provide more robust security than secure password authentication. In this design guide, digital certificates are either smart cards, or certificates issued to your users and computers by the CA you deploy on your network. If your wireless solution uses either EAP-TLS or PEAP-TLS, you must deploy a private CA on your network by using AD CS.

Deploying 802.1X Authenticated Wireless Access with PEAP-MS-CHAP v2

The Windows Server 2008 Foundation Network Guide provides instructions for planning and deploying the core components required for a fully functioning network and a new Active Directory® Domain Services (AD DS) domain in a new forest.

This guide explains how to build upon a foundation network by providing instructions about how to deploy Institute of Electrical and Electronics Engineers (IEEE) 802.1X-authenticated IEEE 802.11 wireless access using Protected Extensible Authentication Protocol – Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2).

Because PEAP-MS-CHAP v2 requires that users provide password-based credentials rather than a certificate during the authentication process, it is easier and less expensive to deploy than EAP-TLS or PEAP-TLS.
noteNote
In this guide, IEEE 802.1X Authenticated Wireless Access with PEAP-MS-CHAP v2 is abbreviated to “wireless access.”
About this guide

This guide provides instructions on how to deploy a WiFi access infrastructure using PEAP-MS-CHAP v2 and the following components:

* One or more 802.1X-capable 802.11 wireless access points (APs).

* Active Directory Users and Computers.

* Group Policy Management.

* One or more Network Policy Server (NPS) servers.

* Server certificates for computers running NPS.

* Wireless client computers running Windows Vista or Windows XP with Service Pack 2.

This is for network and system administrators who have:

* Followed the instructions in the Windows Server 2008 Foundation Network Guide to deploy a foundation network, or for those who have previously deployed the core technologies included in the foundation network, including AD DS, Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), TCP/IP, NPS, and Windows Internet Name Service (WINS).

* Either followed the instructions in the Windows Server 2008 Foundation Network Companion Guide: Deploying Server Certificates to deploy and use Active Directory Certificate Services (AD CS) to autoenroll server certificates to computers running NPS, or who have purchased a server certificate from a public CA, such as VeriSign, that client computers already trust. A client computer trusts a CA if that CA cert is already in the Trusted Root Certification Authorities certificate store on Windows-based computers. By default, computers running Windows have multiple public CA certificates installed in their Trusted Root Certification Authorities certificate store.

The Foundation Network Companion Guide: Deploying Server Certificates is available for download in Word format at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=108259) and in HTML format in the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=108258).

It is recommended that you review the design and deployment guides for each of the technologies that are used in this deployment scenario. These guides can help you determine whether this deployment scenario provides the services and configuration that you need for your organization's network.
Requirements

Following are the requirements for deploying a wireless access infrastructure by using the scenario documented in this guide:

* Before deploying this scenario, you must first purchase and install 802.1X-capable wireless access points to provide wireless coverage in the desired locations at your site.

* Active Directory Domain Services (AD DS) is installed, as are the other network technologies, according to the instructions in the Windows Server 2008 Foundation Network Guide.

* Server certificates are required when you deploy the PEAP-MS-CHAP v2 certificate-based authentication method.

* You or someone else in your organization is familiar with the IEEE 802.11 standards that are supported by your wireless APs and the wireless network adapters installed in the client computers on your network; for example, radio frequency types, 802.11 wireless authentication (WPA2 or WPA), and ciphers (AES or TKIP). For information about determining which wireless standards are supported on wireless client computers running Windows Vista and Windows Server 2008.

What this guide does not provide

Following are some items this guide does not provide:

Comprehensive guidance for selecting 802.1X-capable wireless access points

Because many differences exist between brands and models of 802.1X-capable wireless APs, this guide does not provide detailed information about:

* Determining which brand or model of wireless AP is best suited to your needs.

* The physical deployment of wireless APs on your network.

* Advanced wireless AP configuration, such as for wireless VLAN.

* Instructions on how to configure wireless AP vendor-specific attributes in NPS.

Additionally, terminology and names for settings vary between wireless AP brands and models, and might not match the generic setting names referenced in this guide. For wireless AP configuration details, you must review the product documentation provided by the manufacturer of your wireless APs.

Instructions for deploying NPS server certificates

There are two alternatives for deploying NPS server certificates. This guide does not provide comprehensive guidance to help you determine which alternative will best meet your needs. In general, however, the choices you face are:

* Purchasing certificates from a public CA, such as VeriSign, that is already trusted by Windows-based clients. This option is typically recommended for smaller networks.

o Advantages:

+ Installing purchased certificates does not require as much specialized knowledge as deploying a private CA on your network, and can be easier to deploy in networks that have only a few NPS servers.

+ Using purchased certificates can prevent specific security vulnerabilities that can exist if the proper precautions are not taken when deploying a private CA on your network.

o Disadvantages:

+ This solution does not scale as well as deploying a private CA on your network. Because you must purchase a certificate for each NPS server, your deployment costs increase with each NPS server you deploy.

+ Purchased certificates have recurring costs, because you must renew certificates prior to their expiration date.

* Deploying a private CA on your network by using AD CS.

o Advantages:

+ AD CS is included with Windows Server 2008.

+ This solution scales very well. After you have deployed a private CA on your network, AD CS automatically issues certificates to all NPS servers in your domain with no incremental increases in cost, even if you later add NPS servers to your network.

+ AD CS automatically issues a server certificate to new NPS servers that you add to your network.

+ If you later decide to change your authentication infrastructure from secure password authentication using PEAP to one that requires client certificates and uses either EAP-TLS or PEAP-TLS, you can do so by using your AD CS-based private CA.

o Disadvantages:

+ Deploying a private CA on your network requires more specialized knowledge than purchased certificates, and can be more difficult to deploy.

+ It is possible to expose your network to specific security vulnerabilities if the proper precautions are not taken when deploying a private CA on your network.

NPS network policies and other NPS settings

Except for the configuration settings made when you run the Configure 802.1X wizard, as documented in this guide, this guide does not provide detailed information for manually configuring NPS conditions, constraints or other NPS settings.

For more information about NPS, see Additional Resources in this guide.

DHCP

This deployment guide does not provide information about designing or deploying DHCP subnets for wireless LANs.

For more information about DHCP, see the Additional Resources in this guide.
Technology overviews

Following are technology overviews for deploying wireless access:
IEEE 802.1X

The IEEE 802.1X standard defines the port-based network access control that is used to provide authenticated network access to Ethernet networks. This port-based network access control uses the physical characteristics of the switched LAN infrastructure to authenticate devices attached to a LAN port. Access to the port can be denied if the authentication process fails. Although this standard was designed for wired Ethernet networks, it has been adapted for use on 802.11 wireless LANs.
802.1X-capable wireless access points (APs)

This scenario requires the deployment of one or more 802.1X-capable wireless APs that are compatible with the Remote Authentication Dial-In User Service (RADIUS) protocol.

802.1X and RADIUS-compliant APs, when deployed in a RADIUS infrastructure with a RADIUS server such as an NPS server, are called RADIUS clients.
Wireless clients

This provides comprehensive configuration details to supply 802.1X authenticated access for domain-member users who connect to the network with wireless client computers running either Windows Vista or Windows XP with Service Pack 2 or later. Computers must be joined to the domain in order to successfully establish authenticated access.

If you are using computers running Windows Server 2008 as client computers, you can provision 802.1X security and connectivity settings on those computers by using the same Group Policy extension of Windows Vista Wireless Network (IEEE 802.1) Policies as for computers running Windows Vista. If you are using computers running Windows Server 2003 as client computers, you can provision 802.1X security and connectivity settings on those computers by using the same Group Policy extension of Windows XP Wireless Network (IEEE 802.1) Policies as for computers running Windows XP.
Active Directory Doman Services (AD DS)

AD DS provides a distributed database that stores and manages information about network resources and application-specific data from directory-enabled applications. Administrators can use AD DS to organize elements of a network, such as users, computers, and other devices, into a hierarchical containment structure. The hierarchical containment structure includes the Active Directory forest, domains in the forest, and organizational units (OUs) in each domain. A server that is running AD DS is called a domain controller.

AD DS contains the user accounts, computer accounts, and account properties that are required by IEEE 802.1X and PEAP-MS-CHAP v2 to authenticate user credentials and to evaluate authorization for wireless connections.
Active Directory Users and Computers

Active Directory Users and Computers is a component of AD DS that contains accounts that represent physical entities, such as a computer, a person, or a security group. A security group is a collection of user or computer accounts that administrators can manage as a single unit. User and computer accounts that belong to a particular group are referred to as group members.
Group Policy Management

Group Policy Management is a Windows Server 2008 feature that enables directory-based change and configuration management of user and computer settings, including security and user information. You use Group Policy to define configurations for groups of users and computers. With Group Policy, you can specify settings for registry entries, security, software installation, scripts, folder redirection, remote installation services, and Internet Explorer maintenance. The Group Policy settings that you create are contained in a Group Policy object (GPO). By associating a GPO with selected Active Directory system containers—sites, domains, and OUs—you can apply the GPO's settings to the users and computers in those Active Directory containers. To manage Group Policy objects across an enterprise, you can use the Group Policy Management Editor Microsoft Management Console (MMC).

This guide provides detailed instructions about how to specify settings in the Wireless Network (IEEE 802.11) Policies Group Policy Management extension, which in turn configures the necessary settings on wireless client computers for 802.1X authenticated wireless access.
Server certificates

This deployment scenario requires server certificates for each NPS server that performs 802.1X authentication.

A server certificate is a digital document that is commonly used for authentication and to secure information on open networks. A certificate securely binds a public key to the entity that holds the corresponding private key. Certificates are digitally signed by the issuing CA, and they can be issued for a user, a computer, or a service.

A certification authority (CA) is an entity responsible for establishing and vouching for the authenticity of public keys belonging to subjects (usually users or computers) or other CAs. Activities of a certification authority can include binding public keys to distinguished names through signed certificates, managing certificate serial numbers, and revoking certificates.

Active Directory Certificate Services (AD CS) is a Windows Server 2008 server role that issues certificates as a network CA. An AD CS certificate infrastructure, also known as a public key infrastructure (PKI), provides customizable services for issuing and managing certificates for the enterprise.
EAP, PEAP, and PEAP-MS-CHAP v2

Extensible Authentication Protocol (EAP) extends Point-to-Point Protocol (PPP) by allowing additional authentication methods that use credential and information exchanges of arbitrary lengths. With EAP authentication, both the network access client and the authenticator (such as the NPS server) must support the same EAP type for successful authentication to occur. Windows Server 2008 includes an EAP infrastructure, supports two EAP types, and the ability to pass EAP messages to NPS servers. By using EAP, you can support additional authentication schemes, known as EAP types. The EAP types that are supported by Windows Server 2008 are:

* Transport Layer Security (TLS)

* Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2)

security Note
Strong EAP types (such as those that are based on certificates) offer better security against brute-force attacks, dictionary attacks, and password guessing attacks than password-based authentication protocols (such as CHAP or MS-CHAP version 1).

Protected EAP (PEAP) uses TLS to create an encrypted channel between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, such as an NPS server or other RADIUS servers. PEAP does not specify an authentication method, but it provides additional security for other EAP authentication protocols (such as EAP-MS-CHAP v2) that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for access clients that are connecting to your organization's network through the following types of network access servers (NASs):

* 802.1X-capable wireless access points

* 802.1X-capable authenticating switches

* Computers running Windows Server 2008 and the Routing and Remote Access service (RRAS) that are configured as virtual private network (VPN) servers

* Computers running Windows Server 2008 and Terminal Services Gateway

PEAP-MS-CHAP v2 is easier to deploy than EAP-TLS because user authentication is performed by using password-based credentials (user name and password), instead of certificates or smart cards. Only NPS or other RADIUS servers are required to have a certificate. The NPS server certificate is used by the NPS server during the authentication process to prove its identity to PEAP clients.

This guide provides instructions to configure your wireless clients and your NPS server(s) to use PEAP-MS-CHAP v2 for 802.1X authenticated access.
Network Policy Server

Network Policy Server (NPS) allows you to centrally configure and manage network policies by using the following three components: Remote Authentication Dial-In User Service (RADIUS) server, RADIUS proxy, and Network Access Protection (NAP) policy server. NPS is an optional service of a foundation network, but it is required to deploy 802.1X wireless access.

When you configure your 802.1X wireless access points as RADIUS clients in NPS, NPS processes the connection requests sent by the APs. During connection request processing, NPS performs authentication and authorization. Authentication determines whether the client has presented valid credentials. If NPS successfully authenticates the requesting client, then NPS determines whether the client is authorized to make the requested connection, and either allows or denies the connection. This is explained in more detail as follows:

Authentication

Successful mutual PEAP-MS-CHAP v2 authentication has two main parts:

1. The client authenticates the NPS server. During this phase of mutual authentication, the NPS server sends its server certificate to the client computer so that the client can verify the NPS server's identity with the certificate. To successfully authenticate the NPS server, the client computer must trust the CA that issued the NPS server certificate. The client trusts this CA when the CA’s certificate is present in the Trusted Root Certification Authorities certificate store on the client computer.

If you deploy your own private CA, the CA certificate is automatically installed in the Trusted Root Certification Authorities certificate store for the Current User and for the Local Computer when Group Policy is refreshed on the domain member client computer. If you decide to deploy server certificates from a public CA, ensure that the public CA certificate is already in the Trusted Root Certification Authorities certificate store.

2. The NPS server authenticates the user. After the client successfully authenticates the NPS server, the client sends user’s password-based credentials to the NPS server, which verifies the user’s credentials against the user accounts database in Active Directory Doman Services (AD DS).

If the credentials are valid, the server running NPS proceeds to the authorization phase of processing the connection request. Otherwise, NPS sends an Access Reject message and the connection request is terminated.

Authorization

The server running NPS performs authorization as follows:

* NPS checks for restrictions in the user or computer account dial-in properties in AD DS.

* NPS then processes its network policies to find a policy that matches the connection request. If a matching policy is found, NPS either grants or denies the connection based on that policy’s configuration.

If both authentication and authorization are successful, NPS grants access to the network, and the user and computer can connect to network resources for which they have permissions.

To deploy wireless access, you must configure NPS network policies. This guide provides instructions to use the Configure 802.1X wizard in NPS to create NPS policies for 802.1X authenticated wireless access.
Bootstrap profiles

For deployments in which the user or IT administrator cannot physically connect a computer to the wired Ethernet network to join the computer to the domain, and the computer does not have the necessary issuing root CA certificate installed in its Trusted Root Certification Authorities certificate store, this guide describes how to configure wireless clients running Windows Vista with a temporary wireless connection profile, called a bootstrap profile, to connect to the wireless network. A bootstrap profile removes the requirement to validate the RADIUS server's computer certificate. This temporary configuration enables the wireless user to join the computer to the domain, at which time the Wireless Network (IEEE 802.11) Policies are applied. The appropriate root CA certificate is then installed on the computer, and one or more wireless connection profiles that enforce the requirement for mutual authentication is installed on the computer. After joining the computer to the domain and restarting the computer, the user can use a wireless connection to log on to the domain.

Deploying Server Certificates

Windows Server® 2008 Foundation Network

This provides instructions for planning and deploying the core components required for a fully functioning network and a new Active Directory® domain in a new forest.

This guide explains how to build on the foundation network by providing instructions for deploying server certificates for computers that are running Network Policy Server (NPS), Routing and Remote Access Service (RRAS), or both.

Server certificates are required when you deploy certificate-based authentication methods with Extensible Authentication Protocol (EAP) and Protected EAP (PEAP) for network access authentication.

Deploying server certificates with Active Directory Certificate Services (AD CS) for EAP and PEAP certificate-based authentication methods provides the following benefits:

* Binding the identity of the server running NPS or the RRAS server to a private key
* A cost-effective and secure method for automatically enrolling certificates to domain member NPS and RRAS servers
* An efficient method for managing certificates and certification authorities (CAs)
* Security provided by certificate-based authentication
* The ability to expand the use of certificates for additional purposes

instructions for deploying server certificates to servers running NPS, RRAS servers, or both, by using AD CS.

This is designed for network and system administrators who have followed the instructions in the Windows Server 2008 Foundation Network Guide to deploy a foundation network, or for those who have previously deployed the core technologies included in the foundation network, including Active Directory Domain Services (AD DS), Domain Name Service (DNS), Dynamic Host Configuration Protocol (DHCP), TCP/IP, NPS, and Windows Internet Name Service (WINS) (optional).

It is recommended that you review the design and deployment guides for each of the technologies that are used in this deployment scenario. These guides can help you determine whether this deployment scenario provides the services and configuration that you need for your organization's network.
Requirements

Following are the requirements for using certificates:

* To deploy server certificates by using autoenrollment, AD CS requires the Windows Server 2008 Enterprise or Datacenter operating systems. AD DS must be installed before AD CS is installed. Although AD CS can be deployed on a single server, many deployments involve multiple servers configured as CAs.
* To deploy PEAP or EAP for virtual private networks (VPNs), you must deploy RRAS configured as a VPN server. The use of NPS is optional; however, if you have multiple VPN servers, using NPS is recommended for ease of administration and for the RADIUS accounting services that NPS provides.
* To deploy PEAP or EAP for Terminal Services Gateway (TS Gateway), you must deploy TS Gateway and NPS.
* To deploy PEAP or EAP for 802.1X secure wired or wireless, you must deploy NPS and additional hardware, such as 802.1X authenticating switches or wireless access points.
* To deploy certificate-based authentication methods that require certificates for user and computer authentication in addition to requiring certificates for server authentication, such as EAP with Transport Layer Security (EAP-TLS) or PEAP-TLS, you must also deploy user and computer certificates through autoenrollment or by using smart cards.

not provide

This guide does not provide comprehensive instructions for designing and deploying a public key infrastructure (PKI) by using AD CS. It is recommended that you review AD CS documentation and PKI design documentation before deploying the technologies in this guide. For more information, see the Additional Resources section later in this document.

This guide also does not provide detailed instructions for deploying the network access technologies for which server certificates can be used. In some cases, additional Foundation Network companion guides might be available that provide instructions on deploying these network access solutions.
Technology overviews

Following are technology overviews for EAP, PEAP, and AD CS.
EAP

Extensible Authentication Protocol (EAP) extends Point-to-Point Protocol (PPP) by allowing arbitrary authentication methods that use credential and information exchanges of arbitrary lengths. EAP was developed in response to an increasing demand for authentication methods that use security devices such as smart cards, token cards, and crypto calculators. EAP provides an industry-standard architecture for supporting additional authentication methods within PPP.

With EAP, an arbitrary authentication mechanism is used to verify the identities of the client and server that are establishing a network access connection. The exact authentication scheme to be used is negotiated by the access client and the authenticator (the network access server or the RADIUS server).

With EAP authentication, both the network access client and the authenticator (such as the server running NPS) must support the same EAP type for successful authentication to occur.
ImportantImportant
Strong EAP types, such as those that are based on certificates, offer better security against brute-force attacks, dictionary attacks, and password-guessing attacks than password-based authentication protocols, such as CHAP or MS-CHAP, version 1.
EAP in Windows Server 2008

Windows Server 2008 includes an EAP infrastructure, two EAP types, and the ability to pass EAP messages to a RADIUS server (EAP-RADIUS) such as NPS.

By using EAP, you can support additional authentication schemes, known as EAP types. The EAP types that are supported by Windows Server 2008 are:

* Transport Layer Security (TLS)
* Microsoft Challenge-Handshake Authentication Protocol, version 2 (MS-CHAP v2)

In addition, you can plug other EAP modules into the server running RRAS to provide other EAP methods.
PEAP

PEAP uses TLS to create an encrypted channel between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, such as a server running NPS or other Remote Authentication Dial-In User Service (RADIUS) server.

PEAP does not specify an authentication method, but it provides additional security for other EAP authentication protocols (such as EAP-MSCHAP v2) that can operate through the TLS-encrypted channel provided by PEAP. PEAP is used as an authentication method for access clients that are connecting to your organization's network through the following types of network access servers:

* 802.1X wireless access points
* 802.1X authenticating switches
* Computers running Windows Server 2008 and RRAS that are configured as VPN servers
* Computers running Windows Server 2008 and TS Gateway

Features of PEAP

To enhance the EAP protocols and network security, PEAP provides:

* A TLS channel that provides protection for the EAP method negotiation that occurs between the client and server. This TLS channel helps prevent an attacker from injecting packets between the client and the network access server to cause the negotiation of a less secure EAP type. The encrypted TLS channel also helps prevent denial of service attacks against the server running NPS.
* Support for the fragmentation and reassembly of messages, which allows the use of EAP types that do not provide this functionality.
* Clients with the ability to authenticate the NPS or other RADIUS server. Because the server also authenticates the client, mutual authentication occurs.
* Protection against the deployment of an unauthorized wireless access point at the moment when the EAP client authenticates the certificate provided by the server running NPS. In addition, the TLS master secret that is created by the PEAP authenticator and the client is not shared with the access point. Because of this, the access point cannot decrypt the messages that are protected by PEAP.
* PEAP fast reconnect, which reduces the delay between an authentication request by a client and the response by the NPS or other RADIUS server. Fast reconnect also allows wireless clients to move between access points that are configured as RADIUS clients to the same RADIUS server without repeated requests for authentication. This reduces resource requirements for the client and the server, and it minimizes the number of times that users are prompted for credentials.

Active Directory Certificate Services

AD CS in Windows Server 2008 provides customizable services for creating and managing the X.509 certificates that are used in software security systems that employ public key technologies. Organizations can use AD CS to enhance security by binding the identity of a person, device, or service to a corresponding public key. AD CS also includes features that allow you to manage certificate enrollment and revocation in a variety of scalable environments.

Shop BuyDig.com for Electronics & Save Big!

Deploying Computer and User Certificates

This explains how to build on the foundation network by providing instructions for deploying client computer and user certificates with Active Directory Certificate Services (AD CS).

Certificates are used for network access authentication because they provide strong security for authenticating users and computers and they eliminate the need for less secure password-based authentication methods.

When you deploy Extensible Authentication Protocol with Transport Layer Security (EAP-TLS) or Protected EAP with TLS (PEAP-TLS), certificates are required for the authentication of servers, clients, and users during network connection attempts through network access servers such as 802.1X authenticating switches and wireless access points, virtual private network (VPN) servers, and computers running Windows Server® 2008 and Terminal Services Gateway (TS Gateway).
noteNote
All of these network access servers are also called Remote Authentication Dial-In User Service (RADIUS) clients, because they use the RADIUS protocol to send connection requests to RADIUS servers. RADIUS servers process the connection requests and perform authentication and authorization. The RADIUS server and proxy in Windows Server® 2008 is Network Policy Server (NPS). In Windows Server 2008, NPS replaces Internet Authentication Service (IAS).

Deploying certificates with AD CS for EAP and PEAP certificate-based authentication methods provides the following benefits:

* Security provided with certificate-based authentication, which binds the identity of the server running NPS, RRAS server, user, or client computer to a private key
* A cost-effective and secure method for managing certificates, allowing you to automatically enroll, renew, and revoke certificates to domain member computers and domain users
* An efficient method for managing certification authorities (CAs)
* The ability to deploy other types of certificates that are used for purposes other than computer, user, or server authentication. For example, you can deploy certificates that provide users with the ability to digitally sign e-mail, or you can issue certificates used for software code signing.


get products from link above

Deploying client computer and user certificates to domain member computers and domain users by using AD CS.

This is for network and system administrators who have followed the instructions in the Windows Server 2008 Foundation Network Guide to deploy a foundation network, or for those who have previously deployed the core technologies included in the foundation network, including Active Directory Domain Services (AD DS), Domain Name Service (DNS), Dynamic Host Configuration Protocol (DHCP), TCP/IP, NPS, and Windows Internet Name Service (WINS) (optional).

It is recommended that you review the design and deployment guides for each of the technologies that are used in this deployment scenario. These guides can help you determine whether this deployment scenario provides the services and configuration that you need for your organization network.
Requirements

Following are the requirements for deploying client computer and user certificates using autoenrollment:

* AD DS is installed, as are other network technologies, according to the instructions in the Windows Server 2008 Foundation Network Guide, which is available for download at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=105231) and in the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=106252).
* To perform autoenrollment of client computer and user certificates, your CA must be running the Windows Server 2008 Enterprise operating system or the Windows Server 2008 Datacenter operating system and must be an issuing CA. Although AD CS can be deployed on a single server, many deployments use multiple servers configured as CAs.
* To deploy EAP-TLS or PEAP-TLS, you must enroll server certificates to NPS servers and to computers running Windows Server 2008 and Routing and Remote Access service (RRAS), if you are using RRAS servers as virtual private network (VPN) servers. This guide assumes that you have autoenrolled server certificates in accordance with the Windows Server 2008 Foundation Network Companion Guide: Deploying Server Certificates, which is available at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=108259) and in the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=108258).

Note
If you deploy one or more RRAS servers as VPN servers and you do not have NPS installed, network policies and the authentication methods included in these policies are configured individually per RRAS server, which can be time-consuming and can create opportunities for configuration errors. When you install NPS, you can configure RRAS servers as RADIUS clients in NPS, and then use NPS to centrally manage all policies and authentication methods used per policy.

* To deploy PEAP or EAP for VPN, you must deploy Routing and Remote Access configured as a VPN server. The use of NPS is optional; however, if you have multiple VPN servers, using NPS is recommended for ease of administration and for the RADIUS accounting services that NPS provides.
* To deploy PEAP or EAP for TS Gateway, you must deploy TS Gateway and NPS.
* To deploy PEAP or EAP for 802.1X secure wired or wireless, you must deploy NPS and additional hardware, such as 802.1X authenticating switches or wireless access points.

What this guide does not provide

This guide does not provide information about the following:

* How to deploy client computer and user certificates with smart cards.
* How to deploy server certificates with autoenrollment.
* How to design and deploy a public key infrastructure (PKI) by using AD CS. It is recommended that you review AD CS design and deployment documentation before deploying the technologies in this guide. For more information, see Additional Resources.
* How to deploy the network access technologies for which server certificates can be used. There might be other companion guides available that provide instructions for deploying these network access solutions. You might also want to review the NPS documentation for this information.

Technology overviews

Following are technology overviews for client computer and user certificates, EAP, PEAP, and AD CS.
AD CS

AD CS in Windows Server 2008 provides customizable services for creating and managing the X.509 certificates that are used in software security systems that employ public key technologies. Organizations can use AD CS to enhance security by binding the identity of a person, device, or service to a corresponding public key. AD CS also includes features that allow you to manage certificate enrollment and revocation in a variety of scalable environments.
Client computer and user certificates

When you deploy EAP-TLS or PEAP-TLS, you can deploy computer certificates for client computer authentication, user certificates for user authentication, or both.
noteNote
EAP does not provide mechanisms that perform dual authentication — that is, the authentication of both the computer being used to access the network and the user who is attempting to connect. For this reason, you are not required to issue both computer and user certificates when you deploy EAP and PEAP with certificate-based authentication types.

There are two methods for deploying client computer and user certificates:

* Using smart cards. When you deploy certificates using smart cards, you must purchase additional hardware to imprint certificates on user identification or other cards that your employees use to log on to the network. In addition, users must be supplied with smart card readers, which are used to read the certificate that is imprinted on the smart card when they log on. This guide does not provide information about how to deploy client computer and user certificates with smart cards.
* Using autoenrollment. When you deploy certificates using autoenrollment, you configure the CA to automatically enroll certificates to computers that are members of the Domain Computers group and to users who are members of the Domain Users group. No additional hardware is required to autoenroll certificates, because the certificates are stored on the computer that is connecting to the network. When a computer receives a computer or user certificate from the CA, the certificate is stored locally in a data store named the certificate store.

Important
You should enroll certificates only to the computers and users to whom you want to grant network access through RADIUS clients. You do not have to autoenroll certificates to all members of the Domain Users and Domain Computers groups. Instead, you can issue certificates to subsets of the Domain Users and Domain Computers groups, such as to the Sales team or the Accounting department. To enroll certificates to other groups, create the groups and then add members to the groups in Active Directory Users and Computers. In the Certificate Templates snap-in, remove the Domain Users or Domain Computers groups from the access control list (ACL) on the certificate templates (the User template and the Workstation Authentication template, respectively), and then add the groups that you created to the template.
Certificate store

Computers running the Windows operating system have a certificate store where certificates that are installed on the computer are kept. This store contains multiple folders, where certificates of different types are stored. For example, the certificate store contains a Trusted Root Certification Authorities store where the certificates from all trusted root CAs are kept.

When your organization deploys a PKI and installs a private trusted root CA using AD CS, the CA automatically sends its certificate to all domain member computers in the organization. The domain member client and server computers store the CA certificate in the Trusted Root Certification Authorities folder in the Current User and the Local Computer certificate stores. After this occurs, the domain member computers trust certificates that are issued by the trusted root CA.

Similarly, when you autoenroll computer certificates to domain member client computers, the certificate is kept in the Personal certificate store for the Local Computer; and when you autoenroll certificates to users, the user certificate is kept in the Personal certificate store for the Current User.
EAP

Extensible Authentication Protocol (EAP) extends Point-to-Point Protocol (PPP) by allowing arbitrary authentication methods that use credential and information exchanges of arbitrary lengths. EAP was developed in response to the demand for authentication methods that use security devices such as smart cards, token cards, and crypto calculators. EAP provides an industry-standard architecture for supporting additional authentication methods within PPP.

With EAP, an arbitrary authentication mechanism is used to verify the identities of the client and server that are establishing a network access connection. The authentication scheme to be used is negotiated by the access client and the authenticator (the network access server or the RADIUS server).

For successful authentication to occur, both the network access client and the authenticator (such as the server running NPS) must support the same EAP type.
ImportantImportant
Strong EAP types (such as those that are based on certificates) offer better protection against brute-force attacks, dictionary attacks, and password guessing attacks than password-based authentication protocols (such as CHAP or MS-CHAP, version 1).
EAP in Windows Server 2008

Windows Server 2008 includes an EAP infrastructure, two EAP types, and the ability to pass EAP messages to a RADIUS server (EAP-RADIUS) such as NPS.

By using EAP, you can support additional authentication schemes, known as EAP types. The following EAP types are included in Windows Server 2008:

* Transport Layer Security (TLS). EAP-TLS requires the use of computer certificates, user certificates, or both, in addition to server certificates that are enrolled to computers running NPS. If you deploy Routing and Remote Access as a VPN server, VPN servers must also enroll server certificates.
* Microsoft Challenge-Handshake Authentication Protocol, version 2 (MS-CHAP v2).

In addition, you can install other non-Microsoft EAP modules on the server running NPS or Routing and Remote Access to provide other EAP authentication types. In most cases, if you install additional EAP types on servers, you must also install matching EAP client authentication components on client computers so that the client and server can successfully negotiate an authentication method to use for connection requests.
EAP-TLS deployment overview

The following are the general steps for deploying EAP-TLS:

* Deploy network access servers (RADIUS clients) that are both EAP and RADIUS compliant
* Autoenroll server certificates to servers running NPS and, if applicable, Routing and Remote Access VPN servers
* Autoenroll computer certificates, user certificates, or both, to domain member computers and users, respectively, or to other groups that you have created.
* Configure network access servers as RADIUS clients in NPS.
* Configure EAP authentication in NPS or RRAS network policy.
* Ensure that client computers support EAP. By default, Windows Vista® and Windows XP support EAP.

Group Policy

Group Policy in Windows Server 2008 is an infrastructure used to deliver and apply one or more desired configurations or policy settings to a set of targeted users and computers within an Active Directory environment. This infrastructure consists of a Group Policy engine and multiple client-side extensions (CSEs) responsible for reading policy settings on target client computers. Group Policy is used in this scenario to enroll and distribute certificates to users, computers, or both.
PEAP

PEAP uses TLS to create an encrypted channel between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, such as a server running NPS or another Remote Authentication Dial-In User Service (RADIUS) server.

PEAP does not specify an authentication method, but it provides additional security for other EAP authentication protocols (such as EAP-MSCHAP v2) that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for access clients that are connecting to your organization's network through the following types of network access servers:

* 802.1X wireless access points
* 802.1X authenticating switches
* Computers running Windows Server 2008 and Routing and Remote Access that are configured as VPN servers
* Computers running Windows Server 2008 and TS Gateway

noteNote
If you plan to deploy Network Access Protection (NAP), you must use PEAP as the authentication method for your deployment with NPS.
Features of PEAP

To enhance the EAP protocols and network security, PEAP provides:

* A TLS channel that provides protection for the EAP method negotiation that occurs between the client and server. This TLS channel helps prevent an attacker from injecting packets between the client and the network access server to cause the negotiation of a less secure EAP type. The encrypted TLS channel also helps prevent denial of service attacks against the server running NPS.
* Support for the fragmentation and reassembly of messages, which allows the use of EAP types that do not provide this functionality.
* Clients with the ability to authenticate the server running NPS or another RADIUS server. Because the server also authenticates the client, mutual authentication occurs.
* Protection against the deployment of an unauthorized wireless access point at the moment when the EAP client authenticates the certificate provided by the server running NPS. In addition, the TLS master secret that is created by the PEAP authenticator and the client is not shared with the access point. Because of this, the access point cannot decrypt the messages that are protected by PEAP.
* PEAP fast reconnect, which reduces the delay between an authentication request by a client and the response by the server running NPS or another RADIUS server. Fast reconnect also allows wireless clients to move between access points that are configured as RADIUS clients to the same RADIUS server without repeated requests for authentication. This reduces resource requirements for the client and the server, and it minimizes the number of times that users are prompted for credentials.

ImportantImportant

To deploy PEAP-TLS, autoenroll server certificates to servers running NPS and, if applicable, RRAS VPN servers. Also autoenroll computer certificates, user certificates, or both to domain member computers and users, respectively. Configure PEAP authentication in NPS or RRAS network policy.
PEAP-TLS deployment overview

The following are the general steps for deploying PEAP-TLS:

* Deploy network access servers (RADIUS clients) that are both EAP and RADIUS compliant.
* Autoenroll server certificates to servers running NPS and, if applicable, RRAS VPN servers.
* Autoenroll computer certificates, user certificates, or both, to domain member computers and users, respectively, or to other groups that you have created.
* Configure network access servers as RADIUS clients in NPS.
* Configure EAP authentication in NPS or RRAS network policy.
* Ensure that client computers support EAP. By default, Windows Vista® and Windows XP support EAP.