Suggérer une traduction
 
Suggestions d'autres utilisateurs :

progress indicator
Aucune autre suggestion.
TechNet Magazine > Accueil > Tous les numéros > 2009 > TechNet Magazine Mai 2009 >  Améliorations de PKI dans Windows 7 et Windows ...
Affichage du contenu :  côte à côteAffichage du contenu : côte à côte
Ce contenu traduit automatiquement peut être modifié par les membres de la communauté. Nous vous invitons à améliorer la traduction en cliquant sur le lien « Modifier » associé aux phrases ci-dessous.
Security
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.

References
bluebullet.gif Introduction to the Windows Biometric Framework (WBF)
microsoft.com/whdc/device/input/smartcard/WBFIntro.mspx
bluebullet.gif About Personal Identity Verification (PIV) of Federal Employees and Contractors
csrc. nist.gov/groups/SNS/piv/index.html
bluebullet.gif Windows Server PKI Home
microsoft.com/pki
bluebullet.gif Windows PKI Blog
blogs.technet.com/pki
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 blogs.technet.com/pki .

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 blogs.technet.com/WinCAT .

Sécurité
Améliorations de PKI dans Windows 7 et Windows Server 2008 R2
John Morello
Cet article repose sur le code préliminaire. Toutes les informations dans le présent document sont susceptibles d'être modifiées.
Vue d'ensemble :
  • Consolidation de serveur
  • Améliorée de scénarios existants
  • Logiciels + services
  • Authentification forte

Il semble simplement hier j'a été écrire un article intitulé “ améliorations PKI dans Windows ”. Cet article, ce qui a exécuté dans le août 2007 de TechNet Magazine, axé sur des innovations qui livrés dans Windows Vista et Windows Server 2008. Ces innovations inclus telles que l'inscription de l'interface utilisateur Améliorations et fonctionnalités OCSP (Online Certificate état Protocol). Lorsque ces améliorations étaient utile et bien reçus par les utilisateurs, vous pouvez dire que les modifications étaient vraiment incrémentielles modifications de perspective un INFORMATICIEN professionnel. Toutefois, Windows 7, offre une améliorations PKI qui considérablement améliorer la déploiement et opérationnelle expérience des utilisateurs, l'activation de nouveaux scénarios puissants tout en réduisant les coûts opérationnels.
Les améliorations de Windows 7 et Windows Server 2008 R2 sont axé autour quatre zones principales (illustrés La figure 1 ):
Consolidation des serveurs. Cela permet aux organisations de réduire le nombre total d'autorités de certificat requis pour atteindre leurs objectifs métier.
Améliorée de scénarios existants. Cette vue est sur des éléments tels qu'offrant la prise en charge SCEP (Simple Certificate d'inscription Protocol) plus complète et comprenant une utilisation pratiques Analyzer (BPA).
Logiciels + services. Il est de permettre autonome d'inscription des utilisateurs et des périphériques pour les certificats indépendamment des limites du réseau et fournisseurs de certificat.
Une authentification renforcée. Cette zone porte sur les améliorations apportées à l'expérience de carte à puce, l'introduction de la cadre biométrique pour Windows et ainsi de suite.
Figure 1 que les quatre zones de PKI améliorations de base
Dans cet article, J'AI Explorer certaines des modifications dans ces zones principales du point de vue d'une informatique professionnel.

Consolidation de serveur
Parmi les thèmes prédominante dans IT au cours des dernières années a été consolidation des serveurs. Plus simplement, il s'agit sur réduire l'encombrement total de votre environnement informatique serveur lors de la réunion toujours, ou même développement, vos objectifs commerciaux. L'économie globale actuelle a apporté des économies une priorité supérieure pour plusieurs groupes INFORMATIQUES et consolidation des serveurs peut être certainement un composant de cette stratégie général. Bien que la plupart des entreprises ne disposent pas absolue, numéros des autorités de certification, nombre ont plus dont ils ont besoin uniquement en fonction de débit de création de certificat. En d'autres termes, nombreuses organisations ont autorités de certification qui sont considérablement sous-utilisé.
Il existe deux raisons principales pour cette underutilization. Tout d'abord, certaines organisations peuvent nécessiter des autorités de certification distinct pour réglementaires ou raisons de stratégie de sécurité. Par exemple, certains clients ont choisi d'émettre des certificats à des parties externes d'une autorité de CERTIFICATION complètement distincte que celles qui émettent des certificats à des utilisateurs internes et des ordinateurs. Dans ce cas, le virtualiser l'autorité de CERTIFICATION de la technologie Hyper-V pouvez éliminent la nécessité de matériel de serveur distinct (bien que l'autorité de CERTIFICATION doit toujours être gérée, même en qu'un ordinateur virtuel).
La raison la deuxième courante est que cette inscription automatique a été uniquement pris en charge dans intra-forêt scénarios. Plus précisément, une autorité de CERTIFICATION a uniquement réussi à inscrire automatiquement les entités pour les certificats lorsque ces entités sont une partie de la même forêt qui est joint. Même dans les cas où les approbations de forêt bidirectionnelle niveau existent, distinct autorités de certification ont été nécessaires pour chaque forêt où l'inscription automatique est utilisée.
Une des clés les nouvelles fonctionnalités dans Windows Server 2008 R2 est la capacité à exécuter auto-inscription dans forêt relations d'approbation, création de la possibilité de réduire considérablement le nombre total d'autorités de certification requise dans une entreprise. Prendre en compte un réseau d'entreprise classique qui a déjà des opérations de consolidation et qui possède maintenant quatre forêts : production, développement, le test et le bord. Antérieure à R2, si vous vouliez fournir auto-inscription sur chaque forêt, au moins quatre émission autorités de certification sont requis, même si toutes les forêts approuvé eux. Version 2, vous pouvez réduire le nombre total d'autorités de certification dans ce scénario à un, avoir un seul autorité de CERTIFICATION dans une des forêts émettre des certificats aux entités dans tous les autres forêts.
Pour les environnements avec modèles multi-forest plus complexes, la réduction totale d'autorités de certification peut être encore plus considérables et fournir un retour immédiat sur investissement de la mise à niveau à R2.
Inscription inter-forêts facilite également l'étendre une PKI pendant fusions et acquisitions, étant donné que les certificats peuvent démarrer est mis en service pour les actifs récemment acquis dès qu'une approbation de forêt est placée en place. Inscription inter-forêts étant une modification purement côté serveur, l'inscription pouvez début sans apporter de modifications sur les ordinateurs client et d'et il fonctionne avec les anciens systèmes d'exploitation client, tels que Windows XP.
Donc comment entre forêts l'inscription de travail ? À l'utilisateur final, l'expérience est complètement transparent. Comme avec n'importe quel autre scénario inscription automatique, l'utilisateur renvoie uniquement les certificats avec peu ou pas interaction requise sur son cadre. Les utilisateurs finaux sont probablement jamais sachent à partir de quel forêt les autorités de certification ont sont et ils devrez pas effectuer les actions spéciales pour obtenir les certificats.
Pour un professionnel de l'informatique, les blocs de construction de base sont généralement les mêmes comme avec auto-inscription traditionnel intra-forêt. La différence essentielle est que l'autorité de CERTIFICATION est maintenant en mesure de traiter les demandes provenant d'une forêt externe et récupérer les métadonnées relatives à la demande à partir d'un Active Directory approuvés.
Cette possibilité de recevoir et de correctement traiter une demande d'une forêt fiable est la nouvelle fonctionnalité clée dans R2 qui permet ce scénario à utiliser. En outre à avoir une autorité de CERTIFICATION R2 et l'approbation de forêt bidirectionnelle, modèles de certificat doivent être répliquées entre la forêt contenant l'autorité de CERTIFICATION et tous les autres forêts sont inscrire sur cette. Microsoft fournira un script Windows PowerShell pour automatiser cette réplication, qui doit être effectuée après chaque modification à un modèle. Dans de nombreux cas, il sera judicieux d'avoir ce script s'exécute automatiquement comme une tâche planifiée.
Il existe quelques autres fonctionnalités plus petites qui peuvent aider avec consolidation des serveurs. Un est que l'autorité de CERTIFICATION prend désormais en charge les demandes non persistants, ces demandes de certificats, généralement court résidaient, qui sont ne sont pas écrites dans la base de données de l'autorité de CERTIFICATION. Par exemple, envisagez de Network Access Protection intégrité enregistrement références. Ces systèmes peuvent émettre des milliers de certificats chaque jour qui sont uniquement valides pendant quelques heures. Gestion toutes ces demandes dans la base de données d'autorité de CERTIFICATION ajoute peu d'intérêt, mais considérablement l'augmentation le stockage requis. Avec R2, ces demandes peuvent être configurés pour ne pas écrites dans la base de données et cette configuration peut être effectuée au niveau de l'autorité de CERTIFICATION ou le modèle (voir figure 2 ).
La figure 2 choix ne pas à stocker des certificats dans la base de données
Une autre fonctionnalité conçue pour faciliter la consolidation des serveurs est prise en charge de Server Core. Avec R2, le rôle d'autorité de CERTIFICATION peut être installé sur Server Core, si aucun autre service de rôle AD CS (services de certificats Active Directory) n'est disponible sur Server Core. Lorsque installés sur Server Core, l'autorité de CERTIFICATION peut être gérée avec deux utilitaires de ligne de commande locales, comme certutil, ou en utilisant les MMCs standard à partir d'un système distant. Notez que si matériel sécurité modules (HSM) sont utilisés, vous devez vous assurer que le fournisseur HSM prend en charge l'exécution leurs composants Intégration sur Server Core.

Améliorée de scénarios existants
Windows 7 et version 2 incluent un numéro d'améliorations incrémentielles aux fonctionnalités existantes. Tout d'abord est une modification à une différenciation de point de stock pour les modèles de certificats. Dans les versions antérieures de AD CS, modèles de certificats avancée (version 2 et 3) qui permettent la fonctionnalité d'auto-inscription requis Édition Entreprise autorités de certification. Dans Windows Server 2008 R2, une édition standard autorité de CERTIFICATION prendra en charge toutes les versions de modèle. Version 2 introduit également certaines améliorations à la prise en charge simple Protocol d'inscription de certificat. Dans R2, le composant SCEP prendra en charge renouvellement de périphérique les demandes et réutiliser de mot de passe.
Nouveau AD CS dans R2 est un Best Practices Analyzer (voir figure 3 ). BPAs ont été créées fournit un moyen facile pour les administrateurs vérifier leurs configurations par rapport à une base de données de méthodes recommandées créée et gérée par les équipes de fonctionnalité de Microsoft. Données de services de support client indiquent la majorité des appels de support dans AD CS sont provoquées par configurations incorrectes, afin du BPA doit améliorer les expériences de client en facilitant ainsi la vérifier qu'une autorité de CERTIFICATION est correctement configurée. L'analyseur vérifie pour ces problèmes comme étant manquants AIA (autorité informations Access) ou OCSP pointeurs, certificats près d'expiration et approuver des problèmes de chaînage.
La figure 3 exécution nouveau Best Practices Analyzer
Dans les versions en cours de Windows, choix d'un certificat pour l'authentification du client peut être difficile pour les utilisateurs finaux. Lorsque plusieurs certificats sont valides pour l'authentification, Windows ne permettent aux utilisateurs de déterminer celui qui est celui droite pour une utilisation donnée. Cela conduit vers d'autres appels de support technique support et des coûts de support client accrue. Dans Windows 7, l'interface de sélection de certificat a été améliorée considérablement pour faciliter grandement choisir le certificat droit pour un scénario donné. La commande liste a également été modifié afin d'aider à décisions plus intelligents en présentant le certificat probablement pour un scénario donné en tant que choix par défaut. Enfin, la sélection l'interface utilisateur maintenant différencie les certificats sur les cartes à puce et celles stockées dans le système de fichiers et présente des certificats de carte à puce plus haut dans la liste de sélection, car ils êtes plus susceptibles d'être utilisée. Les différences sont illustrées dans les captures d'écran illustré figure 4 . Notez que Internet Explorer 8 va apporter le filtrage amélioré (mais pas les modifications de l'interface utilisateur) disponible sur systèmes d'exploitation de niveau inférieur ainsi.
La figure 4 plus intelligents moyen de présenter des certificats

Logiciels + services
Pendant le processus de création Windows 7, l'équipe hébergé une réunion comporte de nombreux des supérieur PKI utilisateurs à rechercher équipe les zones doivent obtenir l'attention dans la nouvelle version. Un nombre d'utilisateurs énorme indiqué qu'il est trop difficile de gérer les certificats au-delà des limites de l'organisation, comme entre deux sociétés distinctes qui sont des partenaires commerciaux. Nombre dit qu'il voit PKI comme une cible idéale d'externalisation, car il nécessite un ensemble de compétences spécialisées pour gérer efficacement. Windows 7 et Windows Server 2008 R2 offre une nouvelle technologie qui satisfait à ces deux besoins, facilitant ainsi la provision certificats frontières et ouverture des nouveaux modèles d'entreprise des solutions PKI hébergées. Cette technologie est l'inscription de HTTP.
La figure 5, le nouveau modèle d'inscription
L'inscription de HTTP ne remplace pour le protocole RPC/DCOM traditionnel utilisé pour l'inscription automatique dans les versions antérieures (Notez que l'approche RPC est toujours disponible en version 2). Toutefois, l'inscription de HTTP est plus qu'un protocole d'inscription, il est vraiment une totalement nouvelle approche à fournir des certificats à la fin des entités, quel que soit où ils vous trouve ou si elles sont un ordinateur géré et avec les options authentification flexible. Ce nouveau modèle d'élimine nombre des problèmes liés trouvés dans l'auto-inscription traditionnelle au-delà des limites organisationnelles et fournit une infrastructure permettant de tiers fournir facilement des services d'inscription automatique sans nécessiter de logiciel supplémentaire sur les clients.
L'inscription de HTTP implémente deux nouveaux protocoles basés sur HTTP. Le premier protocole appelé protocole de stratégie de certificat d'inscription, disponibles modèles de certificats aux utilisateurs via HTTPS sessions. Les entités de fin peuvent provenir d'ordinateurs dans des forêts séparées avec aucune relation d'approbation et les machines même pas joint à un domaine. Authentification utilise Kerberos, des noms d'utilisateur/mot de passe ou des certificats. Le protocole de stratégie d'inscription permet aux utilisateurs d'interroger des modèles et déterminer le moment demander des certificats basés sur des modèles de nouveaux ou mis à jour.
Le protocole de service d'inscription de certificat est une extension WS-Trust. Le protocole est utilisé pour obtenir des certificats une fois que les informations de modèle a été déterminées. Il prend en charge les méthodes d'authentification flexible et utilise des HTTPS en tant que le transport.
L'exemple présenté dans La figure 5 illustre le fonctionne de ce nouveau modèle d'inscription.
  • À l'étape 1, les modèles de certificats sont publiés à partir d'Active Directory sur un serveur qui exécute le certificat d'inscription stratégie Web Service (un rôle service nouveau vers R2). L'administrateur de publication de ces modèles utilise les mêmes MMCs et autres outils à laquelle elles sont déjà familiers.
  • À l'étape 2, un client est interrogé le service Web via HTTPS pour déterminer la liste des modèles disponibles pour s'inscrire à. Le client apprend l'URL du service Web via stratégie de groupe, de script ou d'une configuration manuelle. Le client peut être un système joint au domaine, un système à un partenaire commercial ou système de base d'un utilisateur.
  • À l'étape 3, le client a déterminé quels modèles qu'il souhaite inscrire et envoie une demande du service certificat d'inscription Web pour effectuer l'inscription réelle.
  • À l'étape 4, le serveur qui exécute le service Web d'inscription envoie la requête à une autorité de CERTIFICATION pour traitement.
  • À l'étape 5, l'autorité de CERTIFICATION est recherchée données concernant le demandeur d'Active Directory (comme son adresse de messagerie ou nom DNS) qui seront inclus dans le certificat émis.
  • À l'étape 6, l'autorité de CERTIFICATION renvoie le certificat terminé à du service Web d'inscription.
  • À l'étape 7, le service de Web d'inscription se termine la transaction avec le client via HTTPS et envoie le certificat de signature.
Flexibilité était un des principes de conception clé dans ce nouveau service et il est important de savoir comment la conception peut être adaptée à un ensemble varié de scénarios. Étant donné que le protocole d'inscription est HTTPS, les clients peuvent facilement inscrire certificats à partir de n'importe où, y compris derrière des pare-feu d'entreprise ou de connexions fournisseur de services Internet personnelle, sans nécessiter un réseau privé virtuel (VPN). Dans la mesure où trois différentes méthodes d'authentification sont prises en charge, les clients peuvent être jointes à domaine interne d'une organisation, un domaine non approuvé d'une organisation externe ou aucun domaine ne tout. Enfin, étant donné que les composants côté serveur sont implémentées en tant que services Web, ils peuvent être installés séparément à partir de l'autorité de CERTIFICATION et prend en charge les environnements segmentés.
Outre le scénario classique d'inscription d'entités de fin tels que les utilisateurs et ordinateurs de bureau pour les certificats, l'inscription de HTTP permet opportunités de mise en service de certificats d'Autorités de certification racines de confiance. Scénarios tels que les certificats S/MIME d'utilisateur, publiquement face serveurs Web et d'autres systèmes où implicite confiance des certificats est important peuvent tout tirer parti d'inscription plus autonome. Par exemple, plusieurs organisations avec un grand nombre de serveurs Web gérer les certificats manuellement, l'utilisation des listes de noms de serveur et les dates d'expiration stockées dans des classeurs Microsoft Office Excel. Avec l'inscription de HTTP, autorités de certification racines de confiance peuvent offrir un service dans lequel ils fournissent certificats directement à ces serveurs Web automatiquement, libérer de l'administrateur de devoir manuellement gérer les certificats sur eux. Cette combinaison de logiciels et services permet aux organisations à choisir les modèles de déploiement selon leurs besoins meilleur, sans devoir créer autour de réseau ou des limites organisationnelles.

Références
bluebullet.gif Introduction à Windows biométrique Framework (WBF)
Microsoft.com/whdc/device/INPUT/smartcard/WBFIntro.mspx
bluebullet.gif Sur la vérification identité personnelles (PIV) employés fédérales des Contractors
csrc. NIST.gov/groups/SNS/piv/index.html
bluebullet.gif Accueil de PKI Windows Server
Microsoft.com/PKI
bluebullet.gif Blog PKI Windows
blogs.technet.com/PKI
Authentification forte
Windows 7 prend en la première dans zone charge périphériques biométriques avec la WBF (Windows biométrique Framework). WBF êtes initialement l'authentification en fonction par empreinte digitale pour les scénarios de consommateur, est conçu pour rendre biométrie une expérience plus facile et plus intégrée pour les utilisateurs. Un modèle de pilote unifiée fournit utilisateur cohérente expériences sur les types de périphériques avec prise en charge de l'ouverture de session Windows (local et domaine), contrôle (compte d'utilisateur et découverte de périphérique autonome. Pour les entreprises, WBF fournit une méthode Policy–driven de groupe pour désactiver l'infrastructure pour les organisations qui choisissez de ne pas utiliser la biométrie. Les entreprises peuvent également choisir d'autoriser biométrie pour les applications, mais pas pour ouverture de session de domaine. Enfin, la gestion des périphériques renforcée peuvent empêcher usage de périphérique en plus pour tout simplement empêcher l'installation du pilote.
Avec les améliorations biométrie, Windows 7 améliore également utilisateur et administrateur rencontre pour les scénarios de carte à puce. Les cartes à puce sont désormais traités comme des périphériques Plug-and-Play avec installation de pilote Windows Update–based. Le processus de détection et l'installation de Plug-and-Play a lieu avant ouverture de session, utilisateurs signification qui sont nécessaires pour vous connecter avec cartes à puce sera en mesure de se connecter même dans les cas où la carte n'a pas été précédemment détectée. En outre, l'installation ne nécessite pas des privilèges d'administration, rendant approprié dans les environnements de moindre privilège.
Le mini-driver classe carte à puce inclut désormais prise en charge NIST 800 73 SP-1, ce agences fédérales peuvent d'utiliser leurs fiches PIV (vérification d'identité personnels) sans devoir utiliser middleware supplémentaire. Le mini-driver également prend en charge la nouvelle INCITS GICS (papillon) standard, fournissant une expérience de Plug-and-Play pour ces cartes.
Windows 7 également introduit la prise en charge pour le déverrouillage de carte à puce biométrique basé et inclut les nouvelles API pour permettre l'injection de clé sécurisée. Enfin, Windows 7 apporte une prise en charge des certificats de carte à puce chiffrement courbe elliptique (ECC) pour les deux Inscription de certificat ECC et pour l'utilisation de ces certificats ECC pour l'ouverture de session.

Conclusion
Windows 7 et Windows Server 2008 R2 contiennent de la nouvelle technologie PKI plus importante étant donné que Windows 2000 introduit des demandes automatiques de certificats. Cette nouvelle fonctionnalité facilite PKIs et plus efficace pour gérer, remise une meilleure expérience aux utilisateurs finaux.
Windows 7 et Windows Server 2008 R2 incluent les nouvelles fonctionnalités puissantes qui exécute une infrastructure PKI plus efficace tout en considérablement améliorer la fonction d'inscription automatique. Inscription inter-forêts peut considérablement réduire le nombre total d'autorités de certification requise par une organisation et faciliter la gérer les opérations d'infrastructure de clé publique (PKI) au cours des fusions, les acquisitions et divestitures. Nouveau Best Practices Analyzer facilite pour les administrateurs rechercher courants des problèmes de configuration avant de pannes se produisent. Fonctionnalités, telles que prise en charge de Server Core et des demandes nonpersistent facilitent adapter les opérations d'autorité de CERTIFICATION à besoins organisationnels spécifiques. Et l'inscription de HTTP ouvre des nouvelles méthodes pour activer automatiquement les certificats sur l'organisation et les limites du réseau.
Les utilisateurs finaux profitez également des fonctionnalités Windows 7 PKI qui la rendent plus facile à utiliser les certificats dans leur travail quotidien. L'interface de sélection de certificat améliorée facilite aux utilisateurs de sélectionner le certificat droit à un objectif donné et authentifiés plus rapidement. Améliorations de carte à puce comme Plug-and-Play Play–based installation du pilote et prise en charge native des normes de carte impliquent moins de temps doit à dépenser, à l'obtention des cartes pour travailler sur des systèmes de l'utilisateur. Enfin, l'inclusion de prise en charge native de biométrie s'offrent une expérience plus cohérente et transparente pour les utilisateurs finaux et les administrateurs.
Extraire la version Bêta Si vous ne l'avez pas déjà fait et dites-nous ce que vous pensez via l'outil de commentaires ou sur notre blog sur blogs.technet.com/PKI .

Morello Jean travaille chez Microsoft depuis 2000. Il a passé cinq ans dans Microsoft Consulting Services où il conçu solutions de sécurité pour les entreprises entreprises classées dans Fortune 500, gouvernements et les militaries dans le monde entier. Il est actuellement principal responsable responsable de programme dans le groupe de serveurs Windows. Jean a écrit de nombreux articles TechNet Magazine, il a contribué à plusieurs ouvrages Microsoft Press, et il parle régulièrement à des conférences telles que TechEd et forum informatique. Vous pouvez lire le blog de son équipe à blogs.technet.com/WinCAT .

Page view tracker