1 / 63

SEC316 Planning And Deploying PKI In The Real World

SEC316 Planning And Deploying PKI In The Real World. Brian Komar Principal Consultant Microsoft Trustworthy Computing Services (EC3). Agenda. Deploying Windows Server 2003 PKI in a Windows 2000 Forest Case Studies Defense Contractor Power Company.

kyrie
Download Presentation

SEC316 Planning And Deploying PKI In The Real World

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SEC316Planning And Deploying PKI In The Real World Brian KomarPrincipal Consultant Microsoft Trustworthy Computing Services (EC3)

  2. Agenda • Deploying Windows Server 2003 PKI in a Windows 2000 Forest • Case Studies • Defense Contractor • Power Company

  3. Deploying The Windows Server 2003 PKI In A Windows 2000 Network

  4. Windows Server 2003 PKI • A common misconception: • I need to upgrade all of my domain controllers to Windows Server 2003 to run the Windows Server 2003 PKI • False • The Windows Server 2003 PKI can be run in a Windows 2000 Network • You must prepare the network for installation

  5. Windows 2000 Network Preparation • Microsoft Exchange Attributes • Extending the Schema • Adjusting Cert Publishers Scope

  6. Microsoft Exchange Issues • The Exchange 2000 schema defined the following objects: • Secretary • LabeledURI • ms-Exch-House-Identifier • These attributes are used by the InetOrgPerson class (RFC 2798) • The Exchange 2000 definitions are not RFC compliant • Those in Windows Server 2003 and the InetOrgPerson Kit are RFC compliant

  7. Mangling Of The Exchange Attributes • If you do not modify before updating the schema, the Exchange attributes are mangled • If Exchange 2000 is detected in the schema, the Secretary, LabeledURI, and ms-Exch-House-Identifier LDAPDisplayName attributes are modified to prevent conflicts • Replica DCs detect this as a schema collision • Attribute is modified by adding Dup and additional unique characters as a prefix

  8. Mangling Does Not Occur When… • You add the Windows 2000 InetOrgPerson kit before updating to the Windows Server 2003 schema • You update to the Windows Server 2003 schema before installing Exchange 2000 • You add Exchange 2000 to an existing Windows Server 2003 forest

  9. Mangling Occurs When… • You install Exchange 2000 before you install the InetOrgPerson kit • You install Exchange 2000 before you upgrade to the Windows Server 2003 schema

  10. How To Prevent Mangling • Verify that the schema is replicating to all domain controllers in the forest • Log on with an account with the following group memberships: • Schema Admins • Enterprise Admins • Enable schema updates at the Schema operations master

  11. How To Prevent Mangling dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=example,DC=com changetype: Modify replace: lDAPDisplayName lDAPDisplayName: msExchAssistantName - dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=example,DC=com changetype: Modify replace: lDAPDisplayName lDAPDisplayName: msExchLabeledURI - dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X changetype: Modify replace: lDAPDisplayName lDAPDisplayName: msExchHouseIdentifier - dn: changetype: Modify add: schemaUpdateNow schemaUpdateNow: 1 • Create the following LDIF file:

  12. How To Prevent Mangling • Run the following command: ldifde -i -f exchangefix.ldf -c DC=example,DC=com DC=example,DC=com Q314649 – ADPREP Command causes Mangled Attributes in Windows (soon to be updated!!)

  13. Fixing LDAP Display names demo

  14. Preparing The Schema • Version 2 certificate templates require attributes defined in the Windows Server 2003 Schema • Biggest obstacle to deployment in most organizations • Must be approved by the schema modification committee

  15. Preparing The Schema Use the following procedure: • Log on as a member of the Schema Admins and Enteprise Admins • From the Windows Server 2003 compact disc, run z:\i386\adprep /forestprep • When prompted, type C to continue

  16. What About /domainprep • Not required for the Windows Server 2003 PKI • Does not hurt to do this at this point, so you do not forget later • Run adprep /domainprep at the infrastructure master in each domain of the forest

  17. Updating The Schema demo

  18. Cert Publishers Group • When you install an Enterprise CA, it is added to its domain’s Cert Publishers group • The scope of the Cert Publishers group varies between Windows 2000 and Windows Server 2003 • Windows 2000: Global Group • Windows 2003: Universal Group • Membership in this group allows Enterprise CAs to: • View the userCertificate attribute • Modify the userCertificate attribute

  19. Solution • Create a custom universal group that contains each domain’s Cert Publishers global group • Modify permissions for the userCertificate attribute where necessary • See Q281271 - Windows 2000 CA Configuration to Publish certificates in AD of Trusted Domain

  20. Procedure • Create a custom universal group • Add each domain’s Cert Publishers group

  21. Procedure • Run the following script: dsacls "dc=example,dc=com" /G Example\EntCertPublishers:WP;userCertificate dsacls " example,dc=com" /G Example\EntCertPublishers:RP;userCertificate dsacls "cn=adminsdholder,cn=system,dc=example,dc=com" /G Example\EntCertPublishers:WP;userCertificate dsacls "cn=adminsdholder,cn=system,dc=example,dc=com" /G Example\EntCertPublishers:RP;userCertificate dsacls "dc=sub,dc=example,dc=com" /G Example\EntCertPublishers:WP;userCertificate dsacls "dc=sub,dc=example,dc=com" /G Example\EntCertPublishers:RP;userCertificate dsacls "cn=adminsdholder,cn=system,dc=sub,dc=example,dc=com" /G Example\EntCertPublishers:WP;userCertificate dsacls "cn=adminsdholder,cn=system,dc=sub,dc=example,dc=com" /G Example\EntCertPublishers:RP;userCertificate

  22. Preparing The Enterprise Cert Publishers Group demo

  23. PKI Solutions Case Studies

  24. Design Scenarios • CA hierarchy design in face of merger • Issuance policies and procedures • Automating certificate distribution to users with at Windows 2000 computers • Implementing role separation

  25. Scenario CA Hierarchy Design

  26. Environment • Windows 2000 Active Directory • Windows 2000 desktop computers with some Unix workstations • Limited Windows XP deployment • Web servers include IIS and Apache • Databases include Oracle and SQL Server • Customer was just acquired by another company contractor

  27. CA Hierarchy Design • The current Active Directory would be collapsed and merged into a new forest • All Certificate Revocation List (CRL) and Authority Information Access (AIA) URLs must reference both forests • Naming convention had to meet the acquiring organization naming • Contoso (Acquired company) • Fabrikam (Acquiring company)

  28. Fabrikam Internal Policy CA Fabrikam External Policy CA Fabrikam Sector 1 CA Fabrikam Sector 2 CA Fabrikam External Use CA Proposed CA Hierarchy Fabrikam Root CA

  29. URL Configuration • Use the following script: ::Declare Configuration NC certutil -setreg ca\DSConfigDN CN=Configuration,DC=fabrikam,DC=com ::Modify the CDP Extension URLs certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:LDAP:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n2:http://certdata.fabrikam.com/CertData/%%3%%8%%9.crl\n10:LDAP:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=contoso,DC=com%%10" ::Modify the AIA Extension URLs certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:LDAP:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://certdata.fabrikam.com/CertData/%%1_%%3%%4.crt\n2:LDAP:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,CN=configuration,DC=contoso,DC=com%%11"

  30. Scenario Role Separation

  31. Role Separation • Distributes management roles across different individuals in an organization • Prevents a single person from being in charge of all PKI management functions • Enables independent review of all CA management actions • Enforced by configuration of Certificate Services

  32. Common Criteria Roles

  33. Create a domain local group to contain the CA Administrators Populate the domain local group with global or universal groups Assign the domain local group - Manage CA permission Defining CA Administrators

  34. Defining Certificate Managers • Create a domain local group to contain the CA Administrators • Populate the domain local group with global or universal groups • Assign the domain local group - Issue and Manage Certificates permission

  35. Defining Backup Operators CABackups

  36. Defining Auditors CAAuditors

  37. Enabling Role Separation • Must be enabled or disabled by a local administrator • Can be enforced only on: • Windows Server 2003, Enterprise Edition • Windows Server 2003, Datacenter Edition • If user holds two or more roles, they are blocked from all CA management • certutil -setreg ca\RoleSeparationEnabled 1 • certutil -delreg ca\RoleSeparationEnabled

  38. Guidelines When you enable Role Separation: • Assign roles to domain local groups, not to users • Ensure that a user’s group memberships only allow a user to perform a single role in PKI management • Ensure that the CA administrator and certificate manager aren’t local administrators • Define roles in the appropriate console

  39. Scenario Issuance Policies And Procedures

  40. DoD Issuance Policies • Provides recommendations for issuance requirements • Intended for digital signature certificates • Available at: • Http://www.c3i.osd.mil/org/sio/ia/pki/DoD_CP_V60_31May2002.pdf

  41. Class 2 Certificate Policy • User proves identity through a user name and password • No additional verification of identity • Digital signature services for mission support or administrative data on any network • Key exchange for privacy of system high data in an encrypted network or for confidentiality of low value information on unclassified networks

  42. Class 3 Certificate Policy • Applicant’s identity must be validated by the registration authority • Application must provide photo identification • Applicants must provide at least one federal government official picture identification credential • Two nonfederal government issued official identification credentials, at least one of which must be a photo ID, such as a drivers license or passport

  43. Class 3 Certificate Policy • Private key material may be stored on the user’s hard disk • May be exported to a hardware device (known as Class 3 hardware) • Good for medium value transactions

  44. Class 4 Certificate Policy • Same issuance requirements as Class 3 • The private key material is stored on a hardware tokens, such as a smart card • Good for high value transactions

  45. Class 5 Certificate Policy • This policy does not currently define the requirements associated with CLASS 5 certificates • No current X.509 public key certificate implementation is approved for CLASS 5 implementations • Biometrics, etc

  46. Issuance Procedure • User connects to customized Certificate Enrollment Web site • User requests a Class 3 signing certificate • Certificate request is pended • User visits a Local Registration Authority (LRA) • LRA verifies identity and records identification into a custom database

  47. Issuance Procedure (cont’d) • Database insertion informs Certificate Administrator to issue the certificate • User is informed that the certificate is ready for installation • User receives the pending certificate request at the custom Web Enrollment site

  48. Identifying The Issuance Process • Object Identifier (OID) is inserted into issued certificates • In the Certificate Policies extension • OID represents the security process used in certificate issuance • Described at a URL provided in certificate • Best implemented in a private OID space • IANA, ANSI

  49. Defining Issuance Policies demo

  50. Scenario Automating Certificate Installation

More Related