Sugerir traducción
Otros han sugerido:

progress indicator
No hay más sugerencias.
TechNet Magazine > Inicio > Todos los números > 2009 > TechNet Magazine Mayo 2009 >  Mejoras de PKI en Windows 7 y Windows Server 20...
Ver contenido:  en paraleloVer contenido: en paralelo
La información aquí ofrecida es contenido traducido automáticamente que los miembros de la comunidad pueden editar. Quienes deseen contribuir a mejorar la traducción, pueden hacer clic en el vínculo “editar” asociado a cualquiera de los siguientes enunciados.
PKI Enhancements in Windows 7 and Windows Server 2008 R2
John Morello
This article is based on pre-release code. All information herein is subject to change.
At a Glance:
  • Server Consolidation
  • Improved Existing Scenarios
  • Software + Services
  • Strong Authentication

It seems like just yesterday I was writing an article titled “PKI Enhancements in Windows.” That article, which ran in the August 2007 issue of TechNet Magazine, focused on some of the innovations that shipped in Windows Vista and Windows Server 2008. These innovations included such things as enrollment UI improvements and OCSP (Online Certificate Status Protocol) capabilities. While those enhancements were valuable and well received by users, you could argue that the changes were really incremental changes from an IT professional's perspective. Windows 7, however, will deliver PKI enhancements that greatly improve the deployment and operational experience for users, enabling powerful new scenarios while decreasing operational costs.
The improvements in Windows 7 and Windows Server 2008 R2 are focused around four core areas (shown in Figure 1 ):
Server consolidation. This allows organizations to reduce the total number of certificate authorities (CAs) required to meet their business objectives.
Improved existing scenarios. This focus is on such elements as offering more complete SCEP (Simple Certificate Enrollment Protocol) support and including a Best Practices Analyzer (BPA).
Software + Services. This is to enable autonomous enrollment of users and devices for certificates regardless of network boundaries and certificate providers.
Strong authentication. This area focuses on improvements to the smart card experience, the introduction of the Windows Biometric Framework, and so on.
Figure 1 The four core areas of PKI improvements
In this article, I explore some of the major changes in these areas from the perspective of an IT professional.

Server Consolidation
One of the predominant themes in IT over the past few years has been server consolidation. Simply put, this is about reducing the total footprint of your server computing environment while still meeting, or even expanding, your business objectives. The current global economy has made cost savings a top priority for many IT groups, and server consolidation can certainly be one component of that general strategy. While most organizations do not have large, absolute numbers of CAs, many do have more than they need solely based on certificate creation throughput. In other words, many organizations have CAs that are vastly underutilized.
There are two primary reasons for this underutilization. First, some organizations may require separate CAs for regulatory or security policy reasons. For example, some customers have chosen to issue certificates to external parties from a completely separate CA than the ones that issue certificates to internal users and machines. In these cases, virtualizing the CA on Hyper-V can eliminate the need for separate server hardware (though the CA itself must still be managed, even as a VM).
The second common reason is that autoenrollment has only been supported in intra-forest scenarios. Specifically, a CA has only been able to automatically enroll entities for certificates when those entities are part of the same forest that it is joined to. Even in cases where bi-directional forest level trusts exist, separate CAs have been required for each forest where autoenrollment is used.
One of the key new features in Windows Server 2008 R2 is the ability to perform autoenrollment across-forest trust relationships, creating the potential to drastically reduce the total number of CAs required in an enterprise. Consider a typical enterprise network that has already done some consolidation work and now has four forests: production, development, test, and edge. Prior to R2, if you wanted to provide autoenrollment on each forest, at least four issuing CAs were required, even though all the forests trusted each other. With R2, you can reduce the total number of CAs in this scenario down to one, having a single CA in one of the forests issue certificates to entities in all the other forests.
For environments with more complex multi-forest designs, the total reduction in CAs can be even more dramatic and provide an immediate return on investment for the upgrade to R2.
Cross-forest enrollment also makes it easier to extend a PKI during mergers and acquisitions, since certificates can start being provisioned to the newly acquired assets as soon as a forest trust is put into place. And since cross-forest enrollment is a purely server-side change, the enrollment can start without making any changes to the client machines and it works with older client operating systems, such as Windows XP.
So how does cross-forest enrollment work? To the end user, the experience is completely seamless. As with any other autoenrollment scenario, the user just gets the certificates with little or no interaction required on his part. End users will likely never know from what forest the CAs have come and they will not need to take any special actions to obtain the certificates.
For an IT pro, the basic building blocks are mostly the same as with traditional intra-forest autoenrollment. The key difference is that the CA is now able to process requests received from an external forest and retrieve metadata about the request from a trusted Active Directory.
This ability to receive and properly process a request from a trusted forest is the key new capability in R2 that enables this scenario to work. In addition to having an R2 CA and the bi-directional forest trust, certificate templates must be replicated between the forest holding the CA and all other forests that will enroll against it. Microsoft will provide a Windows PowerShell script to automate this replication, which should be done after every change to a template. In many cases, it will be a good idea to have this script run automatically as a scheduled task.
There are a few other smaller features that can help with server consolidation. One is that the CA now supports non-persistent requests—these are requests for certificates, typically short lived, that are not written into the CA's database. For example, consider Network Access Protection Health Registration Authorities. These systems may issue thousands of certificates each day that are only valid for a few hours. Maintaining all these requests in the CA database adds little value, but greatly increases the storage required. With R2, these requests can be configured to not be written to the database and this configuration can be made at either the CA or template level (see Figure 2).
Figure 2 Choosing not to store certificates in the database
Another feature designed to make server consolidation easier is support for Server Core. With R2, the CA role can be installed on Server Core, though no other AD CS (Active Directory Certificate Services) role service is available on Server Core. When installed on Server Core, the CA can be managed with either local command-line utilities, such as certutil, or by using the standard MMCs from a remote system. Note that if hardware security modules (HSMs) are used, you should ensure that the HSM vendor supports running their integration components on Server Core.

Improved Existing Scenarios
Windows 7 and R2 include a number of incremental improvements to existing features. First is a change to SKU differentiation for Certificate Templates. In prior releases of AD CS, advanced (version 2 and 3) Certificate Templates that enable the autoenrollment functionality required Enterprise edition CAs. In Windows Server 2008 R2, a Standard edition CA will support all template versions. R2 also introduces some improvements to the Simple Certificate Enrollment Protocol support. In R2, the SCEP component will support device renewal requests and password reuse.
New to AD CS in R2 is a Best Practices Analyzer (see Figure 3). BPAs were created to provide an easy way for administrators to check their configurations against a database of best practices created and maintained by Microsoft feature teams. Data from customer support services indicate the majority of support calls on AD CS are caused by incorrect configurations, so the BPA should improve customer experiences by making it easier to verify that a CA is configured properly. The analyzer will check for such issues as missing AIA (Authority Information Access) or OCSP pointers, certificates near expiration, and trust chaining problems.
Figure 3 Running the new Best Practices Analyzer
In current releases of Windows, choosing a certificate for client authentication can be difficult for end users. When multiple certificates are valid for authentication, Windows doesn't make it easy for users to determine which one is the right one for a given usage. This leads to more help desk calls and increased customer support costs. In Windows 7, the certificate selection interface has been greatly enhanced to make it much easier to choose the right certificate for a given scenario. The list ordering has also been changed in order to assist in making smarter decisions by presenting the most likely certificate for a given scenario as the default choice. Finally, the selection UI now differentiates between certificates on smart cards and those stored on the file system and presents smart card certificates highest in the selection list, since they're more likely to be used. The differences are illustrated in the screenshots shown in Figure 4. Note that Internet Explorer 8 will make the improved filtering (but not UI changes) available on downlevel operating systems as well.
Figure 4 A smarter way to present certificates

Software + Services
During the Windows 7 design process, the team hosted a meeting with many of the top PKI users to brainstorm which areas should get attention in the new release. An overwhelming number of users indicated that it's too hard to manage certificates across organizational boundaries, such as between two separate companies that are business partners. Many also said that they see PKI as an ideal target for outsourcing, since it requires a specialized skill set to manage effectively. Windows 7 and Windows Server 2008 R2 will deliver a new technology that satisfies both these needs, making it easier to provision certificates across boundaries and opening new business models for hosted PKI solutions. This technology is HTTP enrollment.
Figure 5 The new enrollment model
HTTP enrollment is a replacement for the traditional RPC/DCOM-based protocol used for autoenrollment in previous releases (note that the RPC approach is still available in R2). However, HTTP enrollment is more than just an enrollment protocol—it's really a completely new approach to providing certificates to end entities, regardless of where they're located or whether they're a managed machine and with flexible authentication options. This new model eliminates many of the barriers found in traditional autoenrollment across organizational boundaries and provides a framework for third parties to easily provide autoenrollment services without requiring additional software on the clients.
HTTP enrollment implements two new HTTP-based protocols. The first protocol, known as Certificate Enrollment Policy Protocol, makes certificate templates available to users over HTTPS sessions. The end entities can come from machines in separate forests with no trust relationships and machines not even joined to a domain. Authentication uses Kerberos, user names/passwords, or certificates. The Enrollment Policy Protocol allows users to poll for templates and determine when to request certificates based on new or updated templates.
The Certificate Enrollment Service Protocol is an extension to WS-Trust. The protocol is used for obtaining certificates once the template information has been determined. It supports flexible authentication methods and uses HTTPS as its transport.
The example shown in Figure 5 illustrates how this new enrollment model works.
  • In Step 1, Certificate Templates are published from Active Directory to a server running the Certificate Enrollment Policy Web Service (a role service new to R2). The administrator publishing these templates is using the same MMCs and other tools with which they're already familiar.
  • In Step 2, a client has polled the Web service via HTTPS to determine the list of templates available to enroll against. The client learns the URL for the Web service via Group Policy, script, or manual configuration. The client could be a domain-joined system, a system at a business partner, or a user's home system.
  • In Step 3, the client has determined what templates he wants to enroll for and sends a request to the Certificate Enrollment Web Service to perform the actual enrollment.
  • In Step 4, the server running the Enrollment Web Service sends the request to a CA for processing.
  • In Step 5, the CA has looked up data about the requestor from Active Directory (such as his e-mail address or DNS name) that will be included in the issued certificate.
  • In Step 6, the CA returns the completed certificate to the Enrollment Web Service.
  • In Step 7, the Enrollment Web Service completes the transaction with the client via HTTPS and sends the signed certificate.
Flexibility was one of the key design principles in this new service and it's important to note how the design can be adapted to fit a diverse set of scenarios. Because the enrollment protocol is HTTPS, clients can easily enroll for certificates from anywhere, including behind corporate firewalls or from home ISP connections, without requiring a VPN. Because three different authentication methods are supported, clients can be joined to an organization's internal domain, an untrusted domain of an external organization, or no domain at all. Finally, because the server-side components are implemented as Web services, they can be installed separately from the CA and support segmented environments.
In addition to the classic scenario of enrolling end entities like users and desktops for certificates, HTTP enrollment also enables opportunities for provisioning certificates from trusted root CAs. Scenarios such as user S/MIME certificates, publicly facing Web servers, and other systems where implicit trust of certificates is important could all benefit from more autonomous enrollment. For example, many organizations with large numbers of Web servers maintain certificates manually, using lists of server names and expiration dates stored in Microsoft Office Excel workbooks. With HTTP enrollment, trusted root CAs can offer a service in which they provide certificates directly to these Web servers automatically, freeing the administrator from having to manually maintain the certificates on them. This combination of software and services allows organizations to choose the deployment models that fit their needs best, without having to design around network or organizational boundaries.

bluebullet.gif Introduction to the Windows Biometric Framework (WBF)
bluebullet.gif About Personal Identity Verification (PIV) of Federal Employees and Contractors
bluebullet.gif Windows Server PKI Home
bluebullet.gif Windows PKI Blog
Strong Authentication
Windows 7 includes the first in-box support for biometric devices with the Windows Biometric Framework (WBF). Initially focused on fingerprint-based authentication for consumer scenarios, WBF is designed to make biometrics an easier and more integrated experience for users. A unified driver model provides consistent user experiences across device types with support for Windows logon (both local and domain), User Account Control (UAC), and autonomous device discovery. For enterprises, WBF provides a Group Policy–driven method to disable the framework for organizations that choose not to use biometrics. Enterprises can also choose to allow biometrics for applications, but not for domain logon. Finally, the enhanced device management can prevent device use in addition to simply preventing driver installation.
In addition to the biometrics improvements, Windows 7 also enhances user and administrator experiences for smart card scenarios. Smart cards are now treated as Plug and Play devices with Windows Update–based driver installation. The Plug and Play detection and installation process takes place before logon, meaning users who are required to log on with smart cards will be able to log on even in cases where the card has not been previously detected. Additionally, the installation does not require administrative privileges, making it suitable in least-privilege environments.
The smart card class mini-driver now includes NIST SP 800-73-1 support, so Federal agencies can use their PIV (Personal Identity Verification) cards without having to use additional middleware. The mini-driver also includes support for the emerging INCITS GICS (Butterfly) standard, providing a Plug and Play experience for those cards.
Windows 7 also introduces support for biometric-based smart card unlocking and includes new APIs to enable secure key injection. Finally, Windows 7 adds support for Elliptic Curve Cryptography (ECC) smart card certificates for both ECC certificate enrollment and for utilizing those ECC certificates for logon.

Wrapping Up
Windows 7 and Windows Server 2008 R2 contain some of the most important new PKI technology since Windows 2000 introduced automatic certificate requests. This new functionality makes PKIs easier and more efficient to manage, delivering a better experience for end users.
Windows 7 and Windows Server 2008 R2 include powerful new capabilities that make running a PKI more efficient while greatly enhancing the autoenrollment function. Cross-forest enrollment can dramatically reduce the total number of CAs required by an organization and make it easier to manage PKI operations during mergers, acquisitions, and divestitures. The new Best Practices Analyzer makes it easy for administrators to check for common configuration problems before outages occur. Capabilities such as support for Server Core and nonpersistent requests make it easier to tailor CA operations to specific organizational needs. And HTTP enrollment opens up new methods to automatically provision certificates across organizational and network boundaries.
End users will also benefit from Windows 7 PKI features that make it easier to use certificates in their daily work. The improved certificate selection interface makes it easier for users to choose the right certificate for a given purpose and successfully authenticate more quickly. Smart card improvements like Plug and Play–based driver installation and native support for card standards mean less time needs to be spent getting cards to work on user systems. Finally, the inclusion of native support for biometrics will provide a more consistent and seamless experience for both end users and administrators.
Check out the Beta if you haven't already and let us know what you think via the Feedback Tool or on our blog at .

John Morello has been with Microsoft since 2000. He spent five years in Microsoft Consulting Services where he designed security solutions for Fortune 500 corporations, governments, and militaries around the world. He's currently a Principal Lead Program Manager in the Windows Server Group. John has written numerous articles for TechNet Magazine, he has contributed to several Microsoft Press books, and he speaks regularly at conferences such as TechEd and IT Forum. You can read his team's blog at .

Mejoras de PKI en Windows 7 y Windows Server 2008 R2
John Morello
Este artículo está basado en código preliminar. Toda la información de este documento está sujeta a cambios.
En resumen:
  • Consolidación del servidor
  • Mejora los escenarios existentes
  • Software y servicios
  • Autenticación segura

Parece que fue ayer cuando escribí un artículo titulado "Mejoras de PKI en Windows”. Ese artículo, que se publicó en el número de agosto de 2007 de TechNet Magazine, se centraba en algunas de las innovaciones que se agregaron a Windows Vista y Windows Server 2008. Estas innovaciones incluyen tales como las mejoras de interfaz de usuario de inscripción y las capacidades OCSP (Protocolo de estado en línea de certificados). Mientras se eran esas mejoras valioso y bien recibidos por los usuarios, podría argumentar que los cambios fueran cambios incrementales realmente desde la perspectiva de un profesional de TI. Sin embargo, Windows 7, proporcionará mejoras de PKI que enormemente mejorar la implementación y la experiencia operativa para usuarios, permite nuevos escenarios eficaces al reducir los costos operativos.
Las mejoras en Windows 7 y Windows Server 2008 R2 centran aproximadamente cuatro áreas de núcleo (que se muestra en La figura 1 ):
Consolidación del servidor. Esto permite las organizaciones reducir el número total de las entidades emisoras de certificados (CA) necesario para cumplir sus objetivos empresariales.
Mejorado escenarios existentes. Este enfoque está en estos elementos como lo que ofrece compatibilidad SCEP (Protocolo de inscripción de certificados simple) más completa y incluyendo un Best Practices Analyzer (BPA).
Software y servicios. Esto es permitir autónoma inscripción de usuarios y dispositivos para los certificados independientemente de los límites de red y los proveedores de certificados.
Autenticación segura. Esta área se centra en las mejoras de la experiencia de tarjeta inteligente, la introducción de la Windows biométrica Framework y así sucesivamente.
Figura 1 que las cuatro principales áreas de las mejoras de PKI
En este artículo, Descubra algunos de los cambios principales en estas áreas desde la perspectiva de un profesional de TI.

Consolidación del servidor
Uno de los temas predominante en TI en los últimos años ha sido la consolidación del servidor. Simplemente, esto es reducir la superficie total de su entorno informático servidor mientras se sigue reunión, o incluso expandir, los objetivos empresariales. La economía global actual ha realizado ahorro de costos una prioridad superior para muchos grupos de IT y consolidación de servidores ciertamente, puede ser un componente de dicha estrategia general. Mientras que la mayoría de las organizaciones no tienen números grandes absolutas de entidades emisoras de certificados, muchos tienen más de lo que necesitan únicamente según el rendimiento de creación de certificados. En otras palabras, muchas organizaciones tienen entidades emisoras de certificados que están ampliamente infrautilizado.
Hay dos razones principales para esta underutilization. En primer lugar, algunas organizaciones pueden requerir entidades emisoras independientes para las disposiciones legales o motivo de directiva de seguridad. Por ejemplo, algunos clientes decidió emitir certificados a usuarios externos desde una CA completamente independiente de aquellas que emiten certificados a usuarios internos y equipos. En estos casos, la virtualización de la entidad de CERTIFICACIÓN de Hyper-V puede elimina la necesidad de hardware de servidor independiente, (aunque la entidad de CERTIFICACIÓN aún se debe administrar, incluso como una máquina VIRTUAL).
La segunda razón de común es que la inscripción automática sólo se admite en los escenarios dentro del bosque. En concreto, una entidad emisora de CERTIFICADOS sólo ha sido capaz inscribir automáticamente las entidades de certificados cuando esas entidades son parte del mismo bosque que se está unido a. Incluso en casos donde existen confianzas de nivel de bosque bidireccional, entidades emisoras de certificados independientes han sido necesario para cada bosque que se utiliza la inscripción automática.
Una de las nuevas características claves en Windows Server 2008 R2 es la capacidad de realizar la inscripción automática entre bosques relaciones de confianza, crear el potencial para reducir drásticamente el número total de las entidades emisoras de certificados necesario en una empresa. Considere una red empresarial típico que ya ha realizado algún trabajo de consolidación y ahora tiene cuatro bosques: producción, desarrollo, prueba y borde. Anterior a R2, si desea proporcionar la inscripción automática en cada bosque, al menos cuatro entidades emisoras de certificados se necesario, aunque todos los bosques de confianza entre sí. Con R2, puede reducir el número total de las entidades emisoras de certificados en este escenario a uno, tener una única entidad EMISORA en uno de los bosques emitir certificados a entidades de todos los otros bosques.
Para entornos con diseños con varios bosques más complejas, la reducción de total de las entidades emisoras de certificados puede ser aún más llamativo y proporcionar un retorno inmediato de la inversión para la actualización a R2.
Inscripción entre bosques también resulta más fácil ampliar una infraestructura de claves públicas durante las fusiones y adquisiciones, ya que pueden iniciar los certificados que se va a proporcionar a los activos recién adquiridos tan pronto como una confianza de bosque es poner en marcha. Y dado que la inscripción entre bosques es un cambio sólo en el servidor, puede iniciar la inscripción sin realizar ningún cambio en los equipos cliente y funciona con los anteriores sistemas operativos de cliente, tales como Windows XP.
¿Cómo entre bosques trabajo inscripción? Para el usuario final, la experiencia es completamente transparente. Como con cualquier escenario de inscripción automática, el usuario obtiene sólo los certificados con poca o ninguna interacción necesaria en su parte. Los usuarios finales no se probablemente nunca sabe de qué bosque procedan las entidades emisoras de certificados y no se necesitan realizar las acciones especiales para obtener los certificados.
Un profesional de TI, los bloques de creación básicos son principalmente el mismo que con la inscripción automática interna tradicional del bosque. La diferencia principal es que la entidad emisora de CERTIFICADOS ahora es capaz de procesar las solicitudes de recibido de un bosque externo y recuperar los metadatos sobre la solicitud de un Active Directory confianza.
Esta capacidad para recibir y procesar correctamente una solicitud de un bosque de confianza es la clave nueva capacidad de R2, que permite este escenario trabajar. Así como tener una entidad emisora de CERTIFICADOS de R2 y la confianza de bosque bidireccional, las plantillas de certificado deben replicarse entre el bosque que contiene la entidad emisora de CERTIFICADOS y todos los otros bosques inscripción en él. Microsoft ofrecerá una secuencia de comandos de Windows PowerShell para automatizar esta replicación, lo que debe realizarse después de cada cambio a una plantilla. En muchos casos, será una buena idea hacer que esta secuencia de comandos ejecutar automáticamente como una tarea programada.
Hay unos otras características más pequeños que pueden ayudarle con la consolidación del servidor. Uno es que la entidad emisora de CERTIFICADOS ahora admite las solicitudes no persistentes, estas solicitudes de certificados, normalmente corta vividos, que no se escriben en la base de datos de la entidad de CERTIFICACIÓN. Por ejemplo, considere estado registro entidades de red Access protección. Estos sistemas pueden emitir miles de certificados de cada día que sólo son válidos para unas pocas horas. Todas estas solicitudes de la base de datos de entidad emisora de CERTIFICADOS de mantenimiento agrega valor poco, pero aumenta considerablemente el almacenamiento requerido. Con R2, se pueden configurar estas solicitudes no va a escribir en la base de datos y esta configuración se puede realizar en nivel de la entidad emisora de CERTIFICADOS o plantilla (consulte la figura 2 ).
La Figura 2 elección no para almacenar certificados de la base de datos
Otra característica diseñada para facilitar la consolidación de servidores es la compatibilidad con Server Core. Con R2, se puede instalar la función de la entidad emisora de CERTIFICADOS de Server Core, aunque ningún otro servicio de función de AD CS (Servicios de Certificate Server de Active Directory) es disponible de Server Core. Cuando se instala de Server Core, se puede administrar la entidad emisora de CERTIFICADOS con ambos utilidades de línea de comandos locales, como certutil o mediante los estándar MMCs desde un sistema remoto. Tenga en cuenta que si se utilizan los módulos de seguridad de hardware (HSMs), debe asegurarse de que el proveedor HSM admite que se ejecutan sus componentes de integración de Server Core.

Mejora los escenarios existentes
Windows 7 y R2 incluyen un número de mejoras incrementales a las características existentes. En primer lugar es un cambio a diferenciación de unidades de ALMACENAMIENTO para plantillas de certificado. En versiones anteriores de servidor de CERTIFICADOS de Active Directory, plantillas de certificado avanzada (versión 2 y 3) que permiten la funcionalidad de la inscripción automática requieren Enterprise edition las entidades emisoras de certificados. En Windows Server 2008 R2, una entidad emisora de CERTIFICADOS de edición estándar será compatible con todas las versiones de plantilla. R2 también presenta algunas mejoras para admitir el protocolo de inscripción de certificados simple. En R2, el componente SCEP admite la renovación de dispositivo las solicitudes y reutilización de contraseñas.
Nuevo para AD CS de R2 es Best Practices Analyzer (consulte la figura 3 ). Se crearon BPAs proporcionan una forma fácil para los administradores comprobar sus configuraciones con respecto a una base de datos de prácticas recomendadas creado y mantenido por los equipos de característica de Microsoft. Datos de servicios de soporte al cliente indican la mayoría de las llamadas de soporte técnico en AD CS están causados por configuraciones incorrectas, por lo que la BPA debe mejorar las experiencias de cliente que facilita comprobar que una entidad emisora de CERTIFICADOS está configurada correctamente. El analizador buscará dichos problemas como la falta de AIA (entidad emisora Information Access) o punteros OCSP y certificados cerca de caducidad y problemas de encadenamiento de confianza.
La figura 3 ejecutar la nueva Best Practices Analyzer
En versiones actuales de Windows, seleccionar un certificado para la autenticación del cliente puede resultar difícil para los usuarios finales. Cuando varios certificados son válidos para la autenticación, Windows no hace fácil para los usuarios determinar cuál es el otro derecho para un uso dado. Esto conduce a más llamadas de ayuda de asistencia al cliente y costos de soporte técnico cliente mayor. En 7 de Windows, la interfaz de selección de certificado se ha mejorado considerablemente para facilitar mucho elegir el certificado correcto para un escenario determinado. El orden de lista también se cambió para ayudar a tomar decisiones más inteligentes al presentar el certificado más probable es para un escenario determinado como la opción predeterminada. Por último, la selección interfaz de usuario ahora diferencia entre los certificados en tarjetas inteligentes y los almacenados en el sistema de archivos y presenta los certificados de tarjeta inteligente más alto de la lista de selección, ya que probablemente más que se va a utilizar. Las diferencias se ilustran en la capturas de pantalla que se muestra en la figura 4 . Tenga en cuenta que Internet Explorer 8 hará el mejorado filtrado (pero no los cambios de interfaz de usuario) disponible en sistemas así de mapa de bits operativos.
La figura 4 una forma más inteligente de presentar los certificados

Software y servicios
Durante el proceso de diseño Windows 7, el equipo realiza una reunión con muchos de los superiores usuarios de infraestructura de claves públicas para pensar y establecer qué áreas deben atención en la nueva versión. Un número abrumador de usuarios indica que es demasiado difícil de administrar los certificados a través de los límites organizativos, como entre dos compañías diferentes que son socios comerciales. Muchas también dijo que ven PKI como un destino ideal para tercerizar porque requiere un conjunto de cualificaciones especializadas para administrar de forma eficaz. 7 De Windows y Windows Server 2008 R2 proporcionará una nueva tecnología que cumpla ambos estas necesidades, que facilita los certificados de provisión a través de los límites y abrir nuevos modelos de negocios para soluciones de infraestructura de claves públicas alojadas. Esta tecnología es la inscripción de HTTP.
La figura 5 el nuevo modelo de inscripción
Inscripción de HTTP es un sustituto para el protocolo basadas en RPC y DCOM tradicional utilizado para la inscripción automática en las versiones anteriores (tenga en cuenta que el enfoque RPC es estando disponible en R2). Sin embargo, la inscripción de HTTP es algo más que un protocolo de inscripción, es realmente un enfoque completamente nuevo para proporcionar certificados a entidades, independientemente de donde están ubicadas o si son un equipo administrado y con opciones de autenticación flexibles de cliente. Este nuevo modelo elimina muchas de las barreras que se encuentra en la inscripción automática tradicional a través de los límites organizativos y proporciona un marco para otros fabricantes proporcionar fácilmente servicios de inscripción automática sin necesidad de software adicional en los clientes.
Inscripción de HTTP implementa dos nuevos protocolos basados en HTTP. El primer protocolo, conocido como protocolo de directiva de inscripción de certificados, realiza las plantillas de certificado disponibles en los usuarios a través de las sesiones HTTPS. Las entidades finales pueden proceder de equipos en bosques independientes con no relaciones de confianza y ni siquiera unidos a un dominio de equipos. Autenticación utiliza Kerberos, nombres de usuario y contraseñas o certificados. El protocolo de directiva de inscripción permite a los usuarios sondear para plantillas y determinar cuándo solicitar certificados basados en plantillas nuevos o actualizados.
El protocolo de servicios inscripción de certificados es una extensión de WS-Trust. El protocolo se utiliza para obtener certificados de una vez haya determinado la información de plantilla. Admite métodos de autenticación flexibles y utiliza HTTPS como su transporte.
El ejemplo que se muestra en la La figura 5 ilustra cómo funciona este nuevo modelo de inscripción.
  • En el paso 1, se publican las plantillas de certificado de Active Directory en un servidor que ejecuta el servicio de Web directiva de inscripción de certificados (un función de servicio nuevo a R2). El administrador de publicación de estas plantillas consiste en utilizar los mismos MMCs y otras herramientas con los que son ya familiares.
  • En el paso 2, un cliente sondea el servicio Web a través de HTTPS para determinar la lista de plantillas disponibles para inscribir frente a. El cliente obtiene la dirección URL del servicio Web mediante Directiva de grupo, la secuencia de comandos o la configuración manual. El cliente podría ser un sistema unidos a un dominio, un sistema de un socio comercial o sistema de un usuario doméstico.
  • En el paso 3, el cliente determinó qué plantillas que desea inscribir y envía una solicitud al servicio de Web de inscripción de certificados para realizar la inscripción real.
  • En el paso 4, el servidor que ejecuta el servicio de inscripción Web envía la petición a una entidad emisora de CERTIFICADOS para procesar.
  • En el paso 5, la entidad emisora de CERTIFICADOS se busca datos sobre el solicitante de Active Directory (como su dirección de correo electrónico o nombre DNS) que se incluirá en el certificado emitido.
  • En el paso 6, la entidad emisora de CERTIFICADOS devuelve el certificado completado al servicio Web de inscripción.
  • En el paso 7, el servicio Web de inscripción finaliza la transacción con el cliente a través de HTTPS y envía el certificado firmado.
Flexibilidad fue uno de los principios de diseño clave en este nuevo servicio y es importante observar cómo el diseño puede adaptarse para que quepa un diverso conjunto de escenarios. Dado que el protocolo de inscripción es HTTPS, los clientes pueden fácilmente inscribir certificados desde cualquier sitio, incluyendo detrás de los servidores de seguridad corporativas o de las conexiones de proveedor de servicios de Internet principales, sin necesidad de una red privada VIRTUAL. Ya que se admiten tres métodos de autenticación diferentes, los clientes pueden unirse a dominio interno de una organización, un dominio que no son de confianza de una organización externa o ningún dominio de en absoluto. Por último, porque los componentes de servidor se implementan como servicios Web, pueden instalarse por separado de la entidad de CERTIFICACIÓN y admiten entornos segmentados.
Además el clásico escenario de las entidades finales como usuarios y equipos de escritorio para los certificados de inscripción, inscripción de HTTP también permite oportunidades para la provisión de certificados de entidades emisoras de certificados raíz de confianza. Todos los escenarios, como certificados S/MIME de usuario, público opuestas servidores Web y otros sistemas donde la confianza implícita de certificados es importante pueden beneficiarse de inscripción más autónoma. Por ejemplo, muchas organizaciones con grandes cantidades de los servidores Web mantienen certificados manualmente, mediante listas de nombres de servidor y fechas de caducidad almacenadas en los libros de Microsoft Office Excel. Con la inscripción de HTTP, entidades emisoras raíz de confianza pueden ofrecen un servicio en el que proporcionar certificados directamente a estos servidores Web automáticamente, liberando al administrador de tener que mantener manualmente los certificados en ellos. Esta combinación de software y los servicios permite a las organizaciones elegir los modelos de implementación que se ajusten a sus necesidades mejor, sin tener que diseñar alrededor de red o límites organizativos.

bluebullet.gif Introducción a la biométrica Framework (WBF) de Windows
bluebullet.gif Sobre personal comprobación de identidad (PIV) de federales empleados y contratistas
bluebullet.gif Página principal de PKI de Windows Server
bluebullet.gif Blog de infraestructura de claves públicas de Windows
Autenticación segura
Windows 7 incluye la compatibilidad en cuadro primer para los dispositivos biométricos con Windows biométrica Framework (WBF). Inicialmente se centra en la autenticación de huellas dactilares-basada en escenarios de consumidor, WBF está diseñado para que biometría una experiencia más fácil y más integrada para los usuarios. Un modelo de controlador unificada proporciona experiencias de usuario coherente en tipos de dispositivo con compatibilidad para el inicio de sesión de Windows (local y dominio), control de cuentas de usuario (UAC) y el descubrimiento de dispositivos independientes. Para empresas, WBF proporciona un método de Policy–driven de grupo para deshabilitar el marco para las organizaciones que eliges no utilizar biometría. Las empresas también pueden elegir permitir biometría para las aplicaciones, pero no para inicio de sesión de dominio. Por último, la administración de dispositivos mejorado puede evitar uso de dispositivo en Además para simplemente impedir la instalación del controlador.
Junto con las mejoras de lecturas biométricas, Windows 7 también mejora usuario y administrador experiencias para escenarios de tarjeta inteligente. Ahora se tratan las tarjetas inteligentes como dispositivos Plug and Play con Windows Update–based instalación de controlador. El proceso de detección e instalación Plug and Play tiene lugar antes de inicio de sesión, los usuarios de significado que son necesarios para iniciar sesión con tarjetas inteligentes se podrá iniciar sesión incluso en casos donde la tarjeta no anteriormente detectó. Además, la instalación no requiere privilegios administrativos, facilitando adecuado en entornos con los mínimos privilegios.
Mini-driver de clase de tarjeta inteligente ahora incluye compatibilidad de NIST proveedor de servicios 800 73-1, para las agencias federales pueden utilizar sus tarjetas PIV (comprobación de la identidad personal) sin tener que usar middleware adicional. El mini-driver también incluye compatibilidad para el emergente INCITS GICS (mariposa) estándar, proporcionar una experiencia de Plug and Play para esas tarjetas.
Windows 7 también introduce la compatibilidad con Desbloquear tarjeta inteligente biométrica basándose e incluye API nuevas para habilitar la inserción clave segura. Por último, Windows 7 agrega compatibilidad con certificados de tarjeta inteligente de criptografía de curva elíptica (ECC) para ambos inscripción de certificados ECC y para utilizar esos certificados ECC para el inicio de sesión.

Ajustar hacia arriba
7 De Windows y Windows Server 2008 R2 contienen parte de la nueva tecnología de infraestructura de claves públicas más importante ya que Windows 2000 introdujo solicitudes automáticas de certificados. Esta nueva funcionalidad facilita las PKI y más eficaz para administrar, ofrecer una mejor experiencia para usuarios finales.
7 De Windows y Windows Server 2008 R2 incluyen nuevas capacidades eficaces que hacen que ejecutar una PKI más eficaz al mejorar considerablemente la función de la inscripción automática. Inscripción entre bosques considerablemente puede reducir el número total de entidades emisoras de certificados requeridos por una organización así como facilitar administrar las operaciones de infraestructura de claves públicas durante las fusiones, adquisiciones y desposeimientos. El nuevo Analizador de las mejores prácticas facilita a los administradores comprobar problemas comunes de configuración antes de que ocurran interrupciones. Capacidades tales como compatibilidad con Server Core y las solicitudes no persistentes facilitan a adaptar las operaciones de entidad emisora de CERTIFICADOS necesidades organizativas específicas. Y se abre HTTP inscripción nuevos métodos para aprovisionar automáticamente los certificados a través de organización y los límites de red.
Los usuarios finales también se beneficiarán de PKI de Windows 7 características que facilitan la usar certificados en su trabajo diario. La interfaz de selección de certificado mejorada facilita a los usuarios elegir el certificado correcto para un propósito determinado y autenticar correctamente más rápidamente. Mejoras de tarjeta inteligente como Plug and Play–based instalación del controlador y la compatibilidad nativa con los estándares de tarjeta significa menos tiempo necesita gastarse obtener tarjetas para trabajar en sistemas de usuario. Por último, la inclusión de compatibilidad nativa con biometría proporcionan una experiencia más coherente y uniforme para usuarios finales y los administradores.
Comprobar la versión beta si aún no lo ha hecho y háganos saber lo que piensa mediante la herramienta comentarios o en nuestro blog en .

John Morello ha trabajado con Microsoft desde 2000. Había invertido cinco años en Microsoft Consulting Services donde diseñado soluciones de seguridad para corporaciones Fortune 500, gobiernos y militaries todo el mundo. Actualmente es un director de programa responsable principal en el grupo de servidores de Windows. Juan ha escribe numerosos artículos para TechNet Magazine, ha contribuido a varios libros de Microsoft Press, y habla con regularidad en conferencias, como TechEd y el foro de IT. Puede leer el blog de su equipo en .

Page view tracker