Sugerir tradução
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Maio 2009 >  PKI Enhancements in Windows 7 e no Windows Serv...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
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 .

PKI Enhancements in Windows 7 e no Windows Server 2008 R2
John Morello
Este artigo se baseia no código pré-lançamento. Todas as informações aqui contidas estão sujeitas a alterações.
Visão geral:
  • Consolidação de servidor
  • Aprimorado cenários existentes
  • Software + serviços
  • Autenticação de alta segurança

Parece que apenas ontem era escrever um artigo intitulado “ PKI Enhancements in Windows ”. Esse artigo, que foi executado de agosto de 2007 da TechNet Magazine, concentrado na parte as inovações fornecido no Windows Vista e no Windows Server 2008. Essas inovações incluído coisas como registro da interface do usuário aprimoramentos e recursos OCSP (protocolo de status de certificados online). Enquanto esses aperfeiçoamentos foram importantes e bem recebida pelos usuários, você poderia argumentar que as alterações foram alterações incrementais, na verdade, da perspectiva de um profissional de TI. 7 Do Windows, no entanto, fornecerão aprimoramentos de PKI que significativamente melhorar a implantação e operacional experiência para usuários, permitindo poderosos novos cenários ao diminuir os custos operacionais.
Os aprimoramentos em 7 de Windows e Windows Server 2008 R2 são concentrada em torno quatro áreas de núcleo (mostradas na A Figura 1 ):
Consolidação do servidor. Isso permite que as organizações reduzir o número total de autoridades de certificação (CAs) necessário para atender aos seus objetivos de negócios.
Aprimorada cenários existentes. Esse foco é elementos como oferecer suporte a mais completa SCEP (protocolo de registro de certificado simples) e incluindo uma BPA (Best Practices Analyzer).
Software + serviços. Isso é ativar a inscrição autônoma de usuários e dispositivos para certificados independentemente dos limites da rede e provedores de certificados.
Autenticação de alta segurança. Essa área se concentra no aprimoramentos para a experiência de cartão inteligente, a introdução do Windows biométrica Framework e assim por diante.
Figura 1 que o quatro principais áreas de aprimoramentos de PKI
Neste artigo, VOU explorar algumas das principais alterações nessas áreas da perspectiva de um profissional de TI.

Consolidação de servidor
Um dos temas predominante em IT nos últimos anos alguns foi consolidação do servidor. Simplificando, isso é sobre como reduzir o espaço total do ambiente de computação do servidor enquanto ainda reunião, ou mesmo expandir, seus objetivos de negócios. A economia global atual fez economia de custos uma prioridade superior para vários grupos de TI e consolidação do servidor, certamente, pode ser um componente dessa estratégia geral. Embora a maioria das organizações não ter grandes, absolutos números de autoridades de certificação, muitos é necessário mais do que precisam somente com base na transferência de criação de certificado. Em outras palavras, muitas organizações têm autoridades de certificação que são amplamente subutilizada.
Há dois motivos principais para este underutilization. Primeiro, algumas organizações podem exigir autoridades de certificação separadas para regulamentação ou motivos de diretiva de segurança. Por exemplo, alguns clientes tem optado por emitir certificados para parceiros externos de uma CA completamente separada que aqueles que emitir certificados para usuários internos e máquinas. Nesses casos, virtualizar a autoridade de certificação em Hyper-V pode eliminam a necessidade para hardware de servidor separado (embora a autoridade de certificação deverá ainda ser gerenciada, mesmo como uma VM).
O segundo motivo de comuns é que registro automático tem apenas foi tem suporte no cenários de intra-floresta. Especificamente, uma autoridade de certificação só foi capaz de registrar entidades de certificados automaticamente quando essas entidades são parte da mesma floresta que ingressou em. Mesmo em casos onde existem relações de confiança bidirecional nível entre florestas, autoridades de certificação separadas foram necessários para cada floresta onde o registro automático é usado.
Um dos principais recursos novos no Windows Server 2008 R2 é a capacidade de realizar registro automático em toda floresta relações de confiança, criar o potencial para reduzir drasticamente o número total de autoridades de certificação necessária em uma empresa. Considere uma rede de empresa comum que já tenha feito algum trabalho de consolidação e agora tem quatro florestas: produção, desenvolvimento, teste e borda. Antes para R2, se você quiser fornecer registro automático em cada floresta, pelo menos quatro CAs de emissão foi necessário, mesmo que todas as florestas confiáveis entre si. Com o R2, você pode reduzir o número total de autoridades de certificação neste cenário a um, com uma única autoridade de certificação em uma das florestas emitir certificados para entidades em todas as outras florestas.
Para ambientes com mais complexos designs com várias florestas, a redução total em autoridades de certificação possível ainda mais drástico e fornecer um retorno imediato sobre o investimento para a atualização para R2.
Registro entre florestas também torna mais fácil estender uma PKI durante fusões e aquisições, desde a certificados podem inicialização que está sendo configurado aos ativos recém-adquiridos assim que uma relação de confiança de floresta é colocar em prática. E como o registro entre florestas é uma alteração puramente lado do servidor, o registro pode iniciar sem fazer qualquer alteração as máquinas do cliente e ele funciona com os mais antigos sistemas operacionais cliente, como o Windows XP.
Então, como entre florestas inscrição de trabalho? Para o usuário final, a experiência é completamente transparente. Como ocorre com qualquer outro cenário de registro automático, o usuário apenas obtém os certificados com pouca ou nenhuma interação necessária em sua parte. Os usuários finais provavelmente nunca saberá de qual floresta vir as autoridades de certificação e eles não precisará executar quaisquer ações especiais para obter os certificados.
Para um profissional de TI, os blocos de construção básicos são principalmente os mesmos como ocorre com registro automático intra-floresta tradicional. A chave diferença é que a autoridade de certificação agora é capaz de processar as solicitações recebidas de uma floresta externa e recuperar metadados sobre a solicitação de um Active Directory confiável.
Essa capacidade de receber e processar corretamente uma solicitação de uma floresta confiável é o novo recurso chave no R2 que permite que esse cenário funcione. Além de uma CA do R2 e a relação de confiança de floresta bidirecional, modelos de certificado devem ser duplicados entre a floresta que contém a autoridade de certificação e todas as outras florestas que irão registrar contra ele. A Microsoft fornecerá um script Windows PowerShell para automatizar essa replicação, que deve ser feita após cada alteração em um modelo. Em muitos casos, é aconselhável ter esse script executado automaticamente como uma tarefa agendada.
Há alguns outros recursos menores que podem ajudar na consolidação do servidor. Uma é que a autoridade de certificação agora oferece suporte pedidos não-persistentes — essas solicitações de certificados, normalmente o vivia curto, que não são gravados no banco de dados da autoridade de certificação. Por exemplo, considere as autoridades de registro Network Access Protection integridade. Esses sistemas podem emitir milhares de certificados por dia, que são válidos apenas por algumas horas. Manter todas as essas solicitações no banco de dados da autoridade de certificação adiciona pouco valor, mas aumenta consideravelmente o armazenamento necessário. Com o R2, essas solicitações podem ser configuradas para não serem gravados no banco de dados e essa configuração pode ser feita no nível a autoridade de certificação ou modelo (consulte a Figura 2 ).
A Figura 2 escolhendo não para armazenar certificados no banco de dados
Outro recurso projetado para facilitar a consolidação do servidor é o suporte para Server Core. Com o R2, a função de autoridade de certificação pode ser instalada em Server Core, que nenhum outro serviço de função do AD CS (serviços de certificados do Active Directory) esteja disponível no Server Core. Quando instalado no Server Core, a autoridade de certificação pode ser gerenciada com qualquer um dos utilitários de linha de comando local, como certutil, ou usando os MMCs padrão de um sistema remoto. Observe que, se os módulos de segurança de hardware (HSMs) forem usados, você deve garantir que o fornecedor do HSM suporta a execução seus componentes de integração no Server Core.

Aprimorado cenários existentes
7 Do Windows e R2 incluem vários dos aprimoramentos incrementais em recursos existentes. Primeiro é uma alteração a diferenciação de SKU para os modelos de certificados. Nas versões anteriores do AD CS, modelos de certificado avançada (versão 2 e 3) que permitem a funcionalidade de registro automático necessário Enterprise edition autoridades de certificação. No Windows Server 2008 R2, uma edição padrão da autoridade de certificação oferecerá suporte a todas as versões do modelo. R2 também apresenta algumas melhorias para o suporte de protocolo de registro de certificado simples. No R2, o componente SCEP será oferece suporte a renovação de dispositivo solicitações e reutilização de senha.
Novo para AD CS no R2 é um analisador de melhores práticas (veja a Figura 3 ). BPAs foram criados para fornecer uma maneira fácil para os administradores verificar suas configurações em um banco de dados de melhores práticas criados e mantidos por equipes de recurso do Microsoft. Dados de serviços de suporte do cliente indicam a maioria das chamadas de suporte no AD CS são causados por configurações incorretas, portanto, a BPA deve melhorar experiências de clientes, tornando mais fácil verificar que uma autoridade de certificação está configurada corretamente. O analisador irá procurar tais problemas como ausentes AIA (Acesso de informações da autoridade) ou ponteiros OCSP, certificados próximo vencimento e confiar em problemas de encadeamento.
A Figura 3 executar o novo Best Practices Analyzer
Nas versões atuais do Windows, escolher um certificado para autenticação de cliente pode ser difícil para os usuários finais. Quando vários certificados forem válidos para autenticação, Windows não tornam mais fácil para os usuários a determinar qual deles é o correto para um uso determinado. Isso leva a mais chamadas ao suporte técnico e os custos de suporte cliente maior. No Windows 7, a interface de seleção de certificado foi muito aprimorada para tornar muito mais fácil escolher o certificado correto para um determinado cenário. A ordem da lista também alterada para ajudar na tomada de decisões mais inteligentes, apresentando o certificado mais provável para um determinado cenário como a escolha padrão. Finalmente, a seleção da interface do usuário agora diferencia entre os certificados em cartões inteligentes e aqueles armazenados no sistema de arquivos e apresenta os certificados de cartão inteligente mais altos na lista de seleção, desde que eles provavelmente mais a ser usado. As diferenças são ilustradas nas capturas de tela mostradas na Figura 4 . Observe que Internet Explorer 8 irá fazer a filtragem aprimorada (mas sem alterações de interface do usuário) disponíveis em sistemas de nível inferior operacionais bem.
A Figura 4 A maneira mais inteligente apresentar certificados

Software + serviços
Durante o processo de design de Windows 7, a equipe hospedado uma reunião com muitos dos principais PKI usuários para debater as áreas que devem obter atenção na nova versão. Um número grande de usuários indicado que é muito difícil gerenciar certificados em limites organizacionais, como entre duas empresas separadas que sejam parceiros de negócios. Muitos também diz que vêem PKI como um destino ideal para terceirização, pois requer um conjunto de qualificações especializados para gerenciar com eficiência. 7 Do Windows e Windows Server 2008 R2 serão entregar uma nova tecnologia que satisfaça ambos os essas necessidades, facilitando a provisão certificados limites e abrir novos modelos de negócios para soluções PKI hospedados. Essa tecnologia é registro de HTTP.
A Figura 5 O novo modelo de registro
Registro de HTTP é um substituto para o protocolo baseados em RPC/DCOM tradicional usado para registro automático em versões anteriores (observe que a abordagem RPC é continuará disponível no R2). No entanto, o registro de HTTP é mais do que apenas um protocolo de registro — é realmente uma completamente nova abordagem para fornecer certificados para finalizar entidades, independentemente de onde estejam localizados ou se eles são um computador gerenciado e com opções de autenticação flexível. Este novo modelo elimina muitos as barreiras encontradas no registro automático tradicional limites organizacionais e fornece uma estrutura de terceiros para facilmente fornecer serviços de registro automático sem a necessidade de software adicional nos clientes.
Registro de HTTP implementa dois novos protocolos baseados em HTTP. O primeiro protocolo, conhecido como protocolo de diretiva de registro de certificados, disponibiliza os modelos de certificado para os usuários sobre as sessões de HTTPS. As entidades finais podem vir de máquinas nas florestas separadas com sem relações de confiança e máquinas nem mesmo associadas a um domínio. Autenticação usa Kerberos, nomes de usuário/senhas ou certificados. O protocolo de diretiva de registro permite aos usuários monitorar para modelos e determinar quando solicitar certificados baseados em modelos novos ou atualizados.
O protocolo de serviço de registro certificado é uma extensão do WS-Trust. O protocolo é usado para obter certificados depois que as informações do modelo tem sido determinadas. Ele oferece suporte métodos de autenticação flexível e utiliza HTTPS como o transporte.
O exemplo mostrado na A Figura 5 ilustra como funciona esse novo modelo de registro.
  • Na etapa 1, modelos de certificado são publicados no Active Directory em um servidor que está executando o serviço certificado Registro diretiva da Web (um função de serviço novo para R2). O administrador publicar esses modelos está usando os mesmos MMCs e outras ferramentas com os quais eles já estiverem familiarizados.
  • Na etapa 2, um cliente tem sondados o serviço da Web via HTTPS para determinar a lista de modelos disponíveis para registrar-se contra. O cliente descobre o URL para o Web service por meio de diretiva de grupo, script ou configuração manual. O cliente pode ser um sistema integrado ao domínio, um sistema em um parceiro comercial ou sistema de base do usuário.
  • Na etapa 3, o cliente determinou que modelos ele deseja inscrever-se para e envia uma solicitação para o serviço de Web de inscrição de certificado para executar o registro real.
  • Na etapa 4, o servidor que executa o serviço de registro da Web envia a solicitação para uma autoridade de certificação para processamento.
  • Na etapa 5, a autoridade de certificação foi pesquisado dados sobre o solicitador do Active Directory (como seu endereço de email ou nome DNS) que serão incluídos no certificado emitido.
  • Na etapa 6, a autoridade de certificação retorna o certificado concluído para o serviço da Web de inscrição.
  • Na etapa 7, o serviço de registro na Web conclui a transação com o cliente via HTTPS e envia o certificado assinado.
Flexibilidade foi um dos princípios de design principais nesse novo serviço e é importante observar como o projeto pode ser adaptado para ajustar um conjunto variado de cenários. Como o protocolo de registro é HTTPS, os clientes podem facilmente registrar para certificados de qualquer lugar, incluindo atrás de firewalls corporativos ou de conexões de provedor de serviços de Internet domésticas, sem a necessidade de uma VPN. Como três diferentes métodos de autenticação são suportados, os clientes podem ser Unidos em todos os para domínio interno de uma organização, um domínio não confiável de uma organização externa ou nenhum domínio. Finalmente, pois os componentes do lado do servidor são implementados como serviços da Web, podem ser instalados separadamente da autoridade de certificação e oferecer suporte a ambientes segmentados.
Juntamente com o cenário clássico de registrar as entidades finais como usuários e computadores de mesa para certificados, registro de HTTP também permite oportunidades para provisionamento certificados de autoridades de certificação raiz confiáveis. Cenários, como certificados de S/MIME do usuário, público com servidores Web e outros sistemas onde a confiança implícito de certificados é importante poderiam se todos os beneficiar do registro mais autônomo. Por exemplo, muitas organizações com um grande número de servidores Web mantêm certificados sendo que a manualmente, usando listas de nomes de servidor e as datas de vencimento armazenadas em pastas de trabalho do Microsoft Office Excel. Com o registro de HTTP, autoridades de certificação raiz confiáveis pode oferecer um serviço em que eles fornecem certificados diretamente para esses servidores Web automaticamente, liberando o administrador precise manter manualmente os certificados sobre eles. Essa combinação de softwares e serviços permite às organizações escolher os modelos de implantação que atender às suas necessidades melhor, sem ter que criar em torno de rede ou limites organizacionais.

bluebullet.gif Introdução ao Windows Framework biométrica (WBF)
bluebullet.gif Sobre verificação de identidade pessoal (PIV) do federais funcionários e prestadores de serviços
bluebullet.gif Home page de PKI do Windows Server
bluebullet.gif Blog PKI do Windows
Autenticação de alta segurança
Windows 7 inclui a primeira na caixa de suporte para dispositivos biométricos com Windows biométrica Framework (WBF). Inicialmente voltadas para autenticação de impressão digital-com base para cenários de consumidor, WBF é projetado para tornar biométrica uma experiência mais fácil e mais integrada para usuários. Um modelo de driver unificada oferece experiências de usuário consistente entre tipos de dispositivos com suporte para logon do Windows (local e domínio), o UAC (controle de conta de usuário) e descoberta de dispositivos autônomos. Para empresas, WBF fornece um método de Policy–driven de grupo para desativar a estrutura para organizações que optar por não usar biométrica. As empresas também podem optar por permitir biométrica para aplicativos, mas não para logon no domínio. Finalmente, o gerenciamento de dispositivos aprimorada pode impedir uso de dispositivo com simplesmente impedindo a instalação do driver.
Com os aperfeiçoamentos de biométrica, Windows 7 também melhora usuário e administrador experiências para cenários de cartão inteligente. Cartões inteligentes agora são tratados como dispositivos Plug and Play com Windows Update–based instalação do driver. O processo de detecção e instalação de Plug and Play ocorre antes do logon, os usuários de significado que são necessários para o logon com cartões inteligentes será capaz de fazer logon no mesmo em casos onde o cartão foi não anteriormente detectado. Além disso, a instalação não requer privilégios administrativos, tornando-o adequado em ambientes de privilégio mínimo.
O cartão inteligente classe mini-driver agora inclui suporte NIST SP 800-73-1, para órgãos federais podem usar seus cartões PIV (verificação de identidade pessoal) sem ter que usar middleware adicional. O mini-driver também inclui suporte para o emergentes INCITS GICS (borboleta) padrão, fornecendo uma experiência de Plug and Play para as cartas.
Windows 7 também introduz o suporte ao desbloqueio biométrico com base em cartão inteligente e inclui novas APIs para ativar a inclusão de chave seguro. Finalmente, Windows 7 adiciona suporte para certificados de cartão inteligente ECC (criptografia de curva elíptica) para ambos os ECC a inscrição de certificado e utilizando esses certificados ECC para logon.

Quebra automática para cima
7 Do Windows e Windows Server 2008 R2 contêm algumas das mais importante nova tecnologia PKI desde que o Windows 2000 introduziu solicitações automáticas de certificado. Essa nova funcionalidade facilita PKIs e mais eficiente de gerenciar, oferecer uma experiência melhor para usuários finais.
7 Do Windows e Windows Server 2008 R2 incluem novos recursos poderosos que executar uma PKI mais eficiente ao aumentar bastante a função de registro automático. Registro entre florestas pode significativamente reduzir o número total de autoridades de certificação necessário para uma organização e facilitar gerenciar operações de PKI durante fusões, aquisições e divestitures. O novo Best Practices Analyzer torna mais fácil para os administradores procurar problemas comuns de configuração antes que ocorram falhas. Recursos, como suporte a Server Core e solicitações nonpersistent tornam mais fácil adaptar as operações de autoridade de certificação para necessidades organizacionais. E registro de HTTP abre novos métodos para fornecer automaticamente certificados pela organização e os limites da rede.
Os usuários finais também se beneficiarão de recursos de PKI do Windows 7 que tornam mais fácil usar certificados em seu trabalho diário. A interface de seleção de certificado aprimorada facilita para os usuários escolher o certificado correto para um determinado propósito e successfully authenticate mais rapidamente. Aprimoramentos de cartão inteligente como Plug and Play–based instalação de driver e suporte nativo para padrões de cartão significa que menos tempo precisa ser gasto Obtendo cartões para trabalhar em sistemas de usuário. Finalmente, a inclusão de suporte nativo para biométrica fornecerá uma experiência mais consistente e transparente para usuários finais e administradores.
Check-out do Beta Se você ainda e permita-nos saber o que você pensa via a ferramenta de comentários ou em nosso blog em .

John Morello está com o Microsoft desde 2000. Ele demorou mais de cinco anos em serviços de consultoria da Microsoft onde ele desenvolvido soluções de segurança para as empresas da Fortune 500 empresas, governos e militaries em todo o mundo. Ele é atualmente principal líder do gerente de programas do grupo de servidores Windows. John escreveu vários artigos para TechNet Magazine, ele contribuiu para vários livros da Microsoft Press, e ele fala regularmente em conferências, como TechEd e o fórum de TI. Leia blog da equipe no .

Page view tracker