Blog - Title

October, 2009

  • Come and get it

    Windows 7 and Windows Server 2008 R2 reached general availability today.

    IMAG0002

    The line in our site’s company store was out the door, but we were able to snag some for this nice picture taken from a new Windows Mobile phone. Yeah, I went there too.

     Win7 and R2 Beta have been my fulltime job since October 2008 and it's been the most fun I've ever had as a Microsoft employee. I hope you enjoy using it as much as I enjoyed breaking it.

    - Ned “The Shill” Pyle

  • New Directory Services KB Articles/Blogs 10/11-10/17

    KB

    970401

    Description of BitLocker To Go Reader

    972422

    A Windows XP-based computer stops responding at the "Windows is loading your profile" screen when you connect to the computer by using an RDP connection

    975652

    Error message when you use an application that monitors the event log to open an event log file on a computer that is running Windows Server 2003 SP2: "The event log file is corrupt"

    972635

    The Active Directory Application Mode service may crash if the Active Directory Application Mode instance database is of a large scale on a computer that is running Windows Server 2003 SP2

    972122

    A query takes a long time to complete and increases CPU usage to a high level on the domain controllers that are running Windows Server 2003 when you use NSPI API functions to query address book information

    973667

    A Windows Server 2003-based domain controller may incorrectly return the "NO_SUCH_USER (0xc0000064)" status code in response to logon requests when the domain controller is shutting down or restarting

    973995

    You may lose some events when you subscribe to some events that are in multiple event logs on a computer that is running Windows Server 2008 or Windows Vista

    973509

    The advanced security settings for Windows Firewall that you deploy by using a Group Policy object (GPO) are not displayed in Windows Vista or in Windows 2008

    975212

    When you use a VPN connection that uses Smart Card authentication on a client computer that is running Windows Vista or Windows Server 2008, the computer stops responding

    971265

    A memory leak issue in the Lsass.exe process causes an application or a service to stop responding if the application or the service uses the NTLM authentication on a computer that is running Windows Server 2008 or Windows Vista.

    974178

    Error code 1450 after you transfer data by using the named pipes protocol between a client computer and a server that are running Windows Vista or Windows Server 2008

    975598

    The Nslookup.exe utility does not use all the suffixes in the DNS suffix search list if the total length of the DNS suffix search list is longer than 255 characters on a computer that is running Windows Server 2008 or Windows Vista

    975142

    You cannot install Active Directory Domain Services on a member server that is running Windows Server 2008 in a branch office if the DNS and LDAP communication between the branch office and the forest root domain is blocked

    975808

    All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2

    974639

    Lots of SceCli 1202 events are added to the application event log on a domain controller that is running Windows Server 2008 R2 or Windows 7 after some domain level group policies are updated

    974636

    AD RMS may stop working when it queries Active Directory global catalogs on a computer that is running Windows Server 2008 R2

    974431

    An update is available to improve the stability and reliability of Windows 7 and of Windows Server 2008 R2

    Blogs

    Windows Server 2008 R2 CAPolicy.inf Syntax

    Breaking News: Argentina DST Change

    The Four Stages of NTFS File Growth

    Classification made easy with File Classification Infrastructure in Windows Server 2008 R2

    Error when installing AD Management Gateway Service

    Introducing the Windows 7 Resource Kit PowerShell Pack

    Using Hyper-V without re-installing your world

    Domain and Forest Functional Levels

    Hypervisor is not running error: How to fix

    Upgrading Windows Server 2008 R2 without media

    Add Object Specific ACEs using Active Directory Powershell

    Security Bulletins for the Regular IT Guy - oct 09

    BranchCache Deployment Guide for Windows Server 2008 R2 and Windows 7

    Exchange Automatic conversion of non-security enabled groups into security enabled groups

    Offline NT Password Editor Still Works for Windows 7

    Network Monitor Videos on Channel 9

    Windows 7 / Windows Server 2008 R2: What’s New in Remote Desktop Services

  • DFSR Monitoring Management Pack for System Center 2007 Released

    You can stop yelling at me, it's released:

    Download:

    DFS Replication Management Pack for System Center Operations Manager 2007

    Overview:

    The DFS Replication Management Pack for System Center Operations Manager 2007 monitors the health of the DFS Replication service on Windows Server 2003 R2 and Windows Server 2008 computers. This management pack monitors events generated by the DFS Replication service. These events provide an insight into the health of the service and folders replicated on monitored computers. This management pack includes a dashboard view which can be used to monitor replication backlogs.

    The management pack also features consolidation rules that monitor computers for frequent occurrences of certain operational conditions such as staging cleanups, sharing violations, replication conflicts etc.

    Feature Summary:

    The following features are new in this release of the DFS Replication Management Pack:

    • Alerts indicating outages of the DFS Replication service on monitored computers.
    • Alerts indicating configuration issues that require administrative intervention.
    • Dashboard view that enables tracking of replication backlogs on monitored computers.
    • Tracking of intermittent operational conditions. These conditions are tracked by the management pack and show up either as warnings/errors. Transient warnings/errors flagged for conditions that are resolved over time are automatically corrected by the management pack, once those conditions are resolved.
    • Intuitive state view indicating red, yellow and green states of the service, replication groups, and replicated folders configured on monitored computers.
    • Monitoring of important service parameters such as staging area usage and replication conflicts generated.

    System Requirements:

    Supported Operating Systems: Windows Server 2003 R2 (32-Bit x86); Windows Server 2003 R2 x64 editions; Windows Server 2008
    Other Software: System Center Operation Manager 2007

    Big thanks to MaheshU for letting everyone know the instant it was out.

    - Ned 'you hurt me with your words' Pyle

  • ADMT, RODC’s, and Error 800704f1

    Hello all, Jason here again. With this blog post, I just wanted to bring an ADMT issue to the masses’ attention, as I’ve experienced it multiple times within just the last couple of months.

    There’s an issue when attempting to migrate computer account objects into a Windows 2008 domain that had been prepared for a Read-Only Domain Controller with the ‘ADPrep /RODCPrep’ command.  To confirm if the command had been implemented, look for the following attribute within the ADSIEdit snap-in on the targeted 2008 domain:

    CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=<DomainName>,DC=com

    Note: If ran, the value for the ‘Revision’ attribute will be set to ‘2’.

    This is what is specifically witnessed within the ADMT log file:

    ERR3:7075 Failed to change domain affiliation, hr=800704f1

    The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

    When this error is generated, it is due to the following hotfix NOT being installed onto the client machine that you are migrating into the Windows 2008 domain:

    944043 Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients and for Windows Vista
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;944043

    Upon installing the hotfix and rebooting the client machine(s), re-running ADMT for the computer object migration will now succeed.

    - Jason “J4” Fournerat

  • Windows Server 2008 R2 CAPolicy.inf Syntax

    Greetings! This is Jonathan again. I was reviewing Chris’ excellent blog post series on designing and implementing a PKI when I realized that it would be helpful to better document the CAPolicy.inf file. The information in this post relies heavily on the information published in the Windows Server 2003 Help File, but this information is updated to include information pertinent to Windows Server 2008 R2.

    Another helpful document that discusses many of these settings is available on Technet.

    Background

    First, what is a CAPolicy.inf file? The CAPolicy.inf contains various settings that are used when installing the Active Directory Certification Service (ADCS) or when renewing the CA certificate. The CAPolicy.inf file is not required to install ADCS with the default settings, but in many cases the default settings are insufficient. The CAPolicy.inf can be used to configure CAs in these more complicated deployments.

    Once you have created your CAPolicy.inf file, you must copy it into the %systemroot% folder (e.g., C:\Windows) of your server before you install ADCS or renew the CA certificate.

    I’m not going to discuss what settings you need for your particular configuration, nor will I offer guidance on how you should set up your PKI to meet whatever your needs may be. Please follow Chris’ series for that sort of information. I’m simply going to document the available settings in the CAPolicy.inf which, if you follow Chris’ guidance, you’ll find will come in handy.

    Let’s get started, shall we?

    As I mentioned earlier, the CAPolicy.inf file uses the .INF file structure to specify sections, settings, and values for those settings. It will be impossible here to define a default template suitable for all purposes, so I’m just going to describe all the options and allow you to decide which settings meet your needs. Not all the settings below are required in the file, but those that are required will be called out.

    The following key words are used to describe the .INF file structure.

    • A section is an area in the .INF file that covers a logical group of keys. A section always appears in brackets in the .INF file.
    • A key is the parameter that is to the left of the equal sign.
    • A value is the parameter that is to the right of the equal sign.

    Version

    The first two lines of the CAPolicy.inf file are:

    [Version]
    Signature=”$Windows NT$”

    • [Version] is the section.
    • Signature is the key.
    • “$Windows NT$” is the value.

    Version is the only required section, and must be at the beginning of your CAPolicy.inf file.

    PolicyStatementExtension

    Next is the PolicyStatementExtension section. This section lists the name of the policies for this CA. Multiple policies are separated by commas. The names LegalPolicy and ManagementPolicy are used here as examples, but the names can be whatever the CA administrator chooses when creating the CAPolicy.inf file.

    NOTE: Administrator defined section names must observe the following syntax rules:

    • A section name cannot have leading or trailing spaces, a linefeed character, a return character, or any invisible control character, and it should not contain tabs.
    • A section name cannot contain either of the bracket ([]) characters, a single percent (%) character, a semicolon (;), or any internal double quotation () characters.
    • A section name cannot have a backslash (\) as its last character.

    The names have meaning in the context of a specific deployment, or in relation to custom applications that actually check for the presence of these policies.

    [PolicyStatementExtension]
    Policies=LegalPolicy,ManagementPolicy

    For each policy defined in the PolicyStatementExtension section there must be a section that defines the settings for that particular policy. For the example above, the CAPolicy.inf must contain a [LegalPolicy] section and a [ManagementPolicy] section.

    For each policy, you need to provide a user-defined object identifier (OID) and either the text you want displayed as the policy statement or a URL pointer to the policy statement. The URL can be in the form of an HTTP, FTP, or LDAP URL. Continuing on with the example started above, if you are going to have text in the policy statement, then the next three lines of the CAPolicy.inf will be:

    [LegalPolicy]
    OID=1.1.1.1.1.1.1
    Notice=”Legal policy statement text”

    If you are going to use a URL to host the CA policy statement, then next three lines would instead be:

    [ManagementPolicy]
    OID=1.1.1.1.1.1.2
    URL=
    http://pki.wingtiptoys.com/policies/managementpolicy.asp

    Please note that the OID above is arbitrary and is used as an example. In a true deployment, you would obtain an OID from your own OID gatekeeper.

    In addition:

    • Multiple URL keys are supported
    • Multiple Notice keys are supported
    • Notice and URL keys in the same policy section are supported.
    • URLs with spaces or text with spaces must be surrounded by quotes. This is true for the URL key, regardless of the section in which it appears.
    • The Notice text has a maximum length of 511 characters on Windows Server 2003 [R2], and a maximum length of 4095 characters on Window Server 2008 [R2].

    An example of multiple notices and URLs in a policy section would be:

    [LegalPolicy]
    OID=1.1.1.1.1.1.1
    URL=
    http://pki.wingtiptoys.com/policies/legalpolicy.asp
    URL=ftp://ftp.wingtiptoys.com/pki/policies/legalpolicy.asp
    Notice=”Legal policy statement text”

    CRLDistributionPoint

    You can specify CRL Distribution Points (CDPs) for a root CA certificate in the CAPolicy.inf. This section does not configure the CDP for the CA itself. After the CA has been installed you can configure the CDP URLs that the CA will include in each certificate that it issues. The URLs specified in this section of the CAPolicy.inf file are included in the root CA certificate itself.

    [CRLDistributionPoint]
    URL=
    http://pki.wingtiptoys.com/cdp/WingtipToysRootCA.crl

    Some additional information about this section:

    • Multiple URLs are supported.
    • HTTP, FTP, and LDAP URLs are supported. HTTPS URLs are not supported.
    • This section is only used if you are setting up a root CA or renewing the root CA certificate. Subordinate CA CDP extensions are determined by the CA which issues the subordinate CA’s certificate.
    • URLs with spaces must be surrounded by quotes.
    • If no URLs are specified – that is, if the [CRLDistributionPoint] section exists in the file but is empty – the CRL Distribution Point extension will be omitted from the root CA certificate. This is usually preferable when setting up a root CA. Windows does not perform revocation checking on a root CA certificate so the CDP extension is superfluous in a root CA certificate.

    Authority Information Access

    You can specify the authority information access points in the CAPolicy.inf for the root CA certificate.

    [AuthorityInformationAccess]
    URL=
    http://pki.wingtiptoys.com/Public/myCA.crt

    Some additional notes on the authority information access section:

    • Multiple URLs are supported.
    • HTTP, FTP, LDAP and FILE URLs are supported. HTTPS URLs are not supported.
    • This section is only used if you are setting up a root CA, or renewing the root CA certificate. Subordinate CA AIA extensions are determined by the CA which issued the subordinate CA’s certificate.
    • URLs with spaces must be surrounded by quotes.
    • If no URLs are specified – that is, if the [AuthorityInformationAccess] section exists in the file but is empty – the CRL Distribution Point extension will be omitted from the root CA certificate. Again, this would be the preferred setting in the case of a root CA certificate as there is no authority higher than a root CA that would need to be referenced by a link to its certificate.

    Enhanced Key Usage

    Another section of the CAPolicy.inf file is [EnhancedKeyUsageExtension], which is used to specify the Enhanced Key Usage extension OIDs placed in the CA certificate.

    • Multiple OIDs are supported.
    • This section can be used during CA setup or CA certificate renewal.
    • This section can be used for both the root CA and for subordinate CAs.
    • This extension can be marked as Critical.

    An example of this section is:

    [EnhancedKeyUsageExtension]
    OID=1.2.3.4.5
    OID=1.2.3.4.6
    Critical=No

    If this section is omitted from the CAPolicy.inf file, the Enhanced Key Usage extension will be omitted from the root CA certificate. If this extension does not exist in a root CA certificate then that root CA certificate can be trusted for all purposes.

    By populating this section with specific OIDs, you are limiting the purposes for which the root CA certificate can be trusted. For example, consider the following section:

    [EnhancedKeyUsageExtension]
    OID=1.3.6.1.5.5.7.3.4        ; Secure Email
    OID=1.3.6.1.4.1.311.20.2.2    ; Smart Card Logon
    Critical=No

    During the setup of the CA, the root CA certificate will be created with the two OIDs above in the Enhanced Key Usage extension. This root certificate, because of the OIDs specified, can only be trusted for Secure Email (signing and encrypting) and Smart Card Logon. Any certificate issued for some other purpose, such as Client or Server Authentication, would be considered invalid. This restriction would apply not only to this root CA, but also to any CA subordinate to this root.

    Basic Constraints

    You can use the CAPolicy.inf file to define the PathLength constraint in the Basic Constraints extension of the root CA certificate. Setting the PathLength basic constraint allows you to limit the path length of the CA hierarchy by specifying how many tiers of subordinate CAs can exist beneath the root. A PathLength of 1 means there can be at most one tier of CAs beneath the root. These subordinate CAs will have a PathLength basic constraint of 0, which means that they cannot issue any subordinate CA certificates.

    This extension can be marked as Critical.

    [BasicConstraintsExtension]
    PathLength=1
    Critical=Yes

    It is not recommended to use this section in the CAPolicy.inf file for a subordinate CA. To add a PathLength constraint to a subordinate CA certificate if the parent CA has no PathLength constraint in its own certificate, you can set the CAPathLength registry value on the parent CA. For example, to issue a subordinate CA certificate with a PathLength constraint of 1, use the following command to configure the parent CA.

    Certutil –setreg Policy\CAPathLength 2

    Setting this value causes the CA to behave as though its own certificate had a PathLength constraint of whatever number you specify. Any subordinate CA certificate issued by the parent CA will have a PathLength constraint set appropriately in its Basic Constraints extension.

    You must restart Active Directory Certificate Services for this change to take effect.

    Cross Certificate Distribution Points

    The cross certificate distribution points (CCDP) extension identifies where cross certificates related to the CA certificate can be obtained and how often that location is updated. The CCDP extension is useful if the CA has been cross-certified with another PKI hierarchy. Windows XP and later operating systems would use this extension for the discovery of cross-certificates that might be used during the path discovery and chain building process.

    The SyncDeltaTime key indicates how often, in seconds, the locations referred to by the URL key(s) are updated. While this entire section is optional, if it exists, and if the SyncDeltaTime key is present, then at least one URL key must also be present.

    This extension can be marked as Critical.

    [CrossCertificateDistributionPointsExtension]
    SyncDeltaTime=600    ; in seconds
    URL=
    http://pki.wingtiptoys.com/ccdp/PartnersCA.crt
    Critical=No

    Request Attributes

    The [RequestAttributes] section, when implemented on a subordinate CA, allows you to specify a custom subordinate certification authority template. There is already the default Subordinate Certificate Authority template that is published in Active Directory the first time an Enterprise CA is installed in the forest. This default template, however, is a v1 template (Windows 2000-style) and cannot be edited. The CertificateTemplate key allows you specify a different template for your subordinate CA certificate request, one that you created by duplicating the default template.

    [RequestAttributes]
    CertificateTemplate=WingtipToysSubCA

    Server Settings

    Another optional section of the CAPolicy.inf is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and the certificate revocation list (CRL) validity period for a CA that is being renewed or installed. None of the keys in this section are required. Many of these settings have default values that are sufficient for most needs and can simply be omitted from the CAPolicy.inf file. Alternatively, many of these settings can be changed after the CA has been installed.

    An example would be:

    [certsrv_server]
    RenewalKeyLength=2048
    RenewalValidityPeriod=Years
    RenewalValidityPeriodUnits=5
    CRLPeriod=Days
    CRLPeriodUnits=2
    CRLDeltaPeriod=Hours
    CRLDeltaPeriodUnits=4
    ClockSkewMinutes=20
    LoadDefaultTemplates=True
    AlternateSignatureAlgorithm=0
    ForceUTF8=0
    EnableKeyCounting=0

    RenewalKeyLength sets the key size for renewal only. This is only used when a new key pair is generated during CA certificate renewal. The key size for the initial CA certificate is set when the CA is installed.

    When renewing a CA certificate with a new key pair, the key length can be either increased or decreased. We in Support see this most often when a customer has set a root CA key size of 4096 bytes or higher, and then discover that they have Java apps or network devices that can only support key sizes of 2048 bytes. In that situation, we can use this setting in the CAPolicy.inf file to reduce the key size of the CA. Of course, that means that we have to reissue all the certificates issued by that CA. The higher up in the hierarchy the CA resides, the more inconvenient this procedure is.

    RenewalValidityPeriod and RenewalValidityPeriodUnits establish the lifetime of the new root CA certificate when renewing the old root CA certificate. It only applies to a root CA. The certificate lifetime of a subordinate CA is determined by its superior. RenewalValidityPeriod can have the following values: Hours, Days, Weeks, Months, and Years.

    CRLPeriod and CRLPeriodUnits establish the validity period for the base CRL, while CRLDeltaPeriod and CRLDeltaPeriodUnits establish the validity period of the delta CRL. CRLPeriod and CRLDeltaPeriod can have the following values: Hours, Days, Weeks, Months, and Years. Each of these settings can be configured after the CA has been installed:

    Certutil -setreg CA\CRLPeriod Weeks
    Certutil -setreg CA\CRLPeriodUnits 1
    Certutil -setreg CA\CRLDeltaPeriod Days
    Certutil -setreg CA\CRLDeltaPeriodUnits 1

    Restart Active Directory Certificate Services for any changes to take effect.

    ClockSkewMinutes allows you to accommodate possible clock synchronization issues. The CA will set the effective time of the published base CRL and delta CRL to the current time less the ClockSkewMinutes. For example, if the clock skew is set to 5 minutes, and the current time is 4:00pm, then the effective time of a newly published CRL would be 3:55pm.

    This value can also be set after the CA has been installed.

    Certutil -setreg CA\ClockSkewMinutes 10

    Restart Active Directory Certificate Services for any changes to take effect.

    The default value for ClockSkewMinutes is 10 minutes; if this interval is sufficient then this key can be omitted from the CAPolicy.inf file.

    LoadDefaultTemplates only applies during the install of an Enterprise CA. This setting, either True or False (or 1 or 0), dictates whether or not the CA is configured with any of the default templates.

    In a default installation of the CA, a subset of the default certificate templates is added to the Certificate Templates folder in the Certification Authority snap-in. This means that as soon as the ADCS service starts after the role has been installed a user or computer with sufficient permissions can immediately enroll for a certificate. This behavior is not always desirable.

    To illustrate the point, the Domain Controller and Domain Controller Authentication templates are among the default templates added to the CA as it is installed. The default permissions on these two templates allow all domain controllers in the forest to enroll for certificates based those two templates. Finally, the default behavior of a domain controller is to immediately enroll for a Domain Controller or Domain Controller Authentication template as soon as an Enterprise CA is detected in the forest (Windows 2000 DCs will attempt to enroll for a Domain Controller certificate; Windows Server 2003 and higher will attempt to enroll for a Domain Controller Authentication certificate).

    You may not want to issue any certificates immediately after a CA has been installed, so you can use the LoadDefaultTemplates setting to prevent the default templates from being added to the Enterprise CA. If there are no templates configured on the CA then it can issue no certificates.

    On Windows Server 2003 and Windows Server 2003 R2, the LoadDefaultTemplates setting only applies to a root Enterprise CA. It is ignored on a subordinate Enterprise CA.

    On Windows Server 2008 and Windows Server 2008 R2, the LoadDefaultTemplates setting applies to both root and subordinate Enterprise CAs.

    AlternateSignatureAlgorithm configures the CA to support the PKCS#1 V2.1 signature format for both the CA certificate and certificate requests. When set to 1 on a root CA the CA certificate will include the PKCS#1 V2.1 signature format. When set on a subordinate CA, the subordinate CA will create a certificate request that includes the PKCS#1 V2.1 signature format.

    ForceUTF8 changes the default encoding of relative distinguished names (RDNs) in Subject and Issuer distinguished names to UTF-8. Only those RDNs that support UTF-8, such as those that are defined as Directory String types by an RFC, are affected. For example, the RDN for Domain Component (DC) supports encoding as either IA5 or UTF-8, while the Country RDN (C) only supports encoding as a Printable String. The ForceUTF8 directive will therefore affect a DC RDN but will not affect a C RDN.

    Finally, EnableKeyCounting configures the CA to increment a counter every time the CA’s signing key is used. Do not enable this setting unless you have a Hardware Security Module (HSM) and associated cryptographic service provider (CSP) that supports key counting. Neither the Microsoft Strong CSP nor the Microsoft Software Key Storage Provider (KSP) support key counting.

    For more caveats to be aware of when using key counting, please review the following KB article:

    951721 The certification authority startup event in the Security log always reports a usage count of zero for the signing key on a computer that is running Windows Server 2008 or Windows Server 2003

    Conclusion

    There we go. We’ve finally finished the list of all the settings you can configure via the CAPolicy.inf file.

    I had at first considered putting all the sections I talked about above into one file so you could see how a “finished” CAPolicy.inf file would look. Then I realized that would be a monumentally bad idea seeing as, with the exception of the [Version] section, everything covered above is totally optional – perhaps with some settings even being contradictory. I’d hate to be responsible for a bad sample CAPolicy.inf file bouncing around the Internet.

    The settings that you will want to configure in your CAPolicy.inf file will completely depend on your needs, and will vary between root CAs and subordinate CAs. I certainly hope that you find this information useful.

    - Jonathan ‘Small bills only’ Stephens

  • Designing and Implementing a PKI: Part II Implementation Phases and Certificate Authority Installation

    The series:

    Designing and Implementing a PKI: Part I Design and Planning

    Designing and Implementing a PKI: Part II Implementation Phases and Certificate Authority Installation

    Designing and Implementing a PKI: Part III Certificate Templates

    Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archival

    Designing and Implementing a PKI: Part V Disaster Recovery

    Chris here again. In Part I of this series we covered design considerations for implementing a PKI. In this part of the series I will cover the steps required to implement a PKI. We will cover the steps and build the configuration files we will use for implementing the PKI.

    Here is a breakdown of the steps for implementing a PKI. The steps can vary somewhat, but below are my recommendations to help ensure that the actual implementation is painless.

    Planning Phase

    During the planning phase you document the requirements of your PKI.

    You then take the requirements and translate them into a physical design.

    Pre-Implementation Phase

    During this phase you will build the configuration files. There are essentially two configuration files. One is the CAPolicy.inf file. The CAPolicy.inf file is used during the installation of Active Directory Certification Services (ADCS) and during the renewal of the CA certificate. In the CAPolicy.inf you will configure some basic settings for the CA.

    The second configuration file is the Post-Installation script. Although not required, using a Post-Installation script will allow you to quickly configure the new CA. Also, since you can review the script before implementation, it helps alleviate any misconfiguration due to typos.

    Testing Phase

    This is the phase that is most often avoided and to be honest I am not quite sure why. I would recommend walking through the installation process of the CA hierarchy at least once if not multiple times in a test environment. With the rise of virtualization software (Hyper-V, VMWare) it is fairly easy to do testing, even with limited access to hardware. Testing the implementation not only will get you familiar with the installation process, but will also help you identify any potential issues with your installation steps. Also, during testing you can thoroughly document the steps that you will take during the installation in the production environment.

    Implementation Phase

    During this phase you will implement the actual CA hierarchy. The implementation phase would also include any configuration that needs to be done after ADCS is installed.

    Walkthrough

    I am going to walk through these phases with you, so you feel more comfortable with the process. In my walk through, we are going to be installing a PKI for a fictional company called Fabrikam.

    Pre-Implementation Planning with Fabrikam

    We met with Fabrikam and Fabrikam is interested in deploying a Public Key Infrastructure to be leveraged by a number of current and future projects. Fabrikam currently has its corporate offices located at one site, although the company is rapidly expanding and may add additional sites in the future. Fabrikam currently either uses certificates from Commercial Certification Authorities or has put on hold projects that require certificates until the internal PKI is put in place. We discussed the importance of having a secure PKI deployment.

    We discussed with Fabrikam the fact that a Hardware Security Module (HSM) would provide stronger key protection then the protection offered by DPAPI. However, Fabrikam has decided at this point to forgo the use of an HSM, as they felt the use of an HSM was not a requirement for them. After some discussion it was determined that Fabrikam would deploy a two tier hierarchy which would provide key protection for the Root CA. If security requirements change Fabrikam will consider implementing Common Criteria Role Separation in the future to further increase the security of the CA and the Private Key.

    To additionally increase the level of private key protection the root CA will be kept offline. The hard drive of the offline Root CA will be stored in a safe that only certain members of the security team have access to. Access to the safe is logged and monitored. This protects the private key of the Root CA. This also limits the ability of an attacker or malicious employee to create additional CAs from the key pair of the Root CA.

    Fabrikam is also interested in having the ability to add additional Issuing CAs in the future. They want the flexibility to add more issuing CAs based on load or geography. To increase the level of manageability they would like all current and future issuing certificate authorities to chain up to the same Root CA (Trust Anchor).

    In terms of certificates Fabrikam has a list of requirements that must be met. They have some third party applications and devices that can use Secure LDAP, and they would like to issue certificates to Domain Controllers to support those apps. Also, Fabrikam is looking to deploy Outlook Web Access and has several intranet sites that currently have SSL configured. Right now, Fabrikam purchases certificates for these web sites from a third-party and would like to move this process in house to save money. In the future, Fabrikam is also looking at other technologies that could benefit from the internal PKI such for protecting wireless networks, and enabling remote access for user through VPN. However, these are future initiatives and Fabrikam just needs the flexibility to issue certificates in the future to support these technologies.

    Fabrikam has also decided that it would like the issuing CA to be valid for 5 years to limit the lifetime of the public/private key pair. They plan to renew with a new key pair at the 3 year mark. They have also decided with some consultation that they would like to limit the root CA certificate to being valid for 10 years and plan to renew with a new key pair at the 5 year mark.

    We looked into the applications and network devices that Fabrikam currently uses and they all support key lengths of 4096 bits or less. Fabrikam is going to make it a requirement that all future applications and network devices support key lengths as large as 4096 bits.

    For the Root CA, Fabrikam was looking for a compromise between security and manageability in terms of renewing the Root CRL. The security team wanted to renew the CRL for the Root CA every month and the operations team wanted to have the Root CA renewed once a year, to limit the number of times they needed to bring the Root CA online. Eventually a compromise was reach of publishing a new CRL for the root CA after every 6 months. Similar discussions were held for determining the CRL validity period for the Issuing CA. It was eventually determined that a base CRL would be valid for a week and delta CRLs would be valid for 2 hours. Microsoft warned Fabrikam that if there was a hardware failure on the CA, there would be certificate validation issues after 2 hours due to the Delta CRLs expiring. Fabrikam plan to have a process in place to perform offline CRL signing in case of a CA failure.

    We also discussed placement of AIA and CDP paths. Most of Fabrikam’s systems are Windows domain joined clients. However, they would like to have the flexibility for third party Operating Systems to access the CDP and AIA locations. Based on this discussion we decided to publish CRLs and CA certificates to both Active Directory and to a web server.

    After having the discussions with Fabrikam, we are ready to look at the business requirements and translate those requirements into the implementation steps.

    Planning Phase walkthrough

    After reviewing the business requirements, Fabrikam documented the following design and configuration.

    PKI Configuration

    Number of Tiers: 2
    Number of CAs in each Tier: 1
    Operating System Version: Windows 2008
    Operating System Edition: Standalone Edition for the Offline Root CA and Enterprise Edition for the Enterprise CA
    CA Type: Root CA will be Standalone. Issuing CA will be Enterprise.
    CA Issuance: Domain Controller Authentication and Web Server
    Private Key Protection: Root will be offline. No additional private key protection for Issuing CA.
    Policy: No constraints will be defined.

    Root CA Configuration

    Validity Period for Root CA Certificate: 10 years
    Key Length for CA Certificate: 4096 bits
    Certificate Validity Period for issued Certificates: 5 years
    AIA Locations: LDAP and HTTP
    CDP Locations: LDAP and HTTP
    CRL Validity: 26 Weeks
    Delta CRLs: Delta CRLs will not be used
    CA Name: Fabrikam Root CA

    Issuing CA Configuration

    Validity Period for Issuing CA Certificate: 5 years (determined by certificate validity period of root CA.)
    Key Length for CA Certificate: 2048 bits
    Certificate Validity Period for issued Certificates: 2 years
    AIA Locations: LDAP and HTTP
    CDP Locations: LDAP and HTTP
    CRL Validity: 1 week
    Delta CRLs Validity: 2 hours
    CA Name: Fabrikam Issuing CA 1

    Pre-installation Phase

    In this phase we will be building our configuration files. Since we are building a two tier hierarchy with one CA in each tier, we will need the following configuration files.

    Root CA

    CAPolicy.inf
    Post-Installation Configuration Script

    Issuing CA

    CAPolicy.inf
    Post-Installation Configuration Script

    Root CA CAPolicy.inf

    The CAPolicy.inf file is fairly straightforward. It is simply an .INF file consisting of named sections containing keys associated with some data. The only required section is [Version]. Then we have the [Certsrv_Server] section which specifies certain CA settings, most of which only apply when renewing the CA certificate. The initial CA configuration will be defined when the ADCS role is installed, but in the future the settings specified in the CAPolicy.inf file will be used. We also specify an empty CDP and AIA location by listing the [CRLDistributionPoint] and [AuthorityInformationAccess] sections with no values. These empty CDP and AIA values are not required in Windows Server 2008 since the installation of a Root CA will omit these extensions by default. However, in Windows Server 2003 you would have to specify these sections in order to omit these extensions from your Root CA Certificate.

    [Version]
    Signature= "$Windows NT$"

    [Certsrv_Server]
    RenewalKeyLength=4096
    RenewalValidityPeriod=Years
    RenewalValidityPeriodUnits=10

    [CRLDistributionPoint]

    [AuthorityInformationAccess]

    Root CA Post-Installation Configuration Script

    The Post-Installation script I am using is based on the one provided in the Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure. If you are looking to deploy a PKI this is a must read, and goes in to greater depth then this blog series. Below is the Post-Installation configurations script that I will be using: 

     

    You will have to modify line 1 of the script to reflect your forest root domain name. For our environment the line is modified to:

    SET myADnamingcontext=DC=fabrikam,DC=com

    In line 2 we set the DSConfigDN setting, which is used by the CA to build the LDAP paths for the AIA and CDP location.

    In lines 3-6 we configure the CRL publication options.

    Before we look at this section of the script, we first need to understand the options, variables, and structure of this command. So, clearly the command certutil –setreg CA\CRLPublicationURLs is going to set locations for publishing CRLs.

    The format is <publication option>:<publication URL> . Multiple publication locations are separated by \n.

    The Publication Option includes a number that maps to the options that are configured in the GUI. For CDP there are the following options as outlined in the table below. Each option is represented by a number, and the list of all options selected is represented by the combined total of their option numbers. This total value is what is placed in the CRLPublicationURLs publication options value.

     

    Option Number

     

    Option

     

    0

     

    No Options Defined

     

    1

     

    Publish CRLs to this location

     

    2

     

    Include in the CDP extensions of issued certificates

     

    4  

     

    Include in CRLS. Clients use this to find Delta CRL Locations

     

    8

     

    Include in all CRLs.  Specifies where to publish in the Active Directory when publishing manually.

     

    64

     

    Publish Delta CRLs to this location

     

    128

     

    Include in the IDP extension of issued CRLs

     

     

    There are also variables that can be included in the publication location. Variables are preferred over hard coded values, due to some issues that can arise with hard coded values. For example, customers that hardcode these URLs frequently leave off the variable that represents the index value of the CA certificate’s private key (%4). As a result, and after a CA certificate is renewed, publishing the CRL signed by the second private key overwrites the CRL signed by the first private key because the index that would differentiate the filename has been omitted.

    Below is a table that explains these variables:

     

    Variable

     

     

    Variable Display Name in the CertSrv MMC

     

    Description

     

    %1

     

    <ServerDNSName>

     

    The DNS name of the certification authority server

     

    %2

     

    <ServerShortName>

     

    The NetBIOS name of the certification authority server

     

    %3

     

    <CaName>

     

    The name of the Certificate Authority

     

    %4

     

    <CertificateName>

     

    The renewal extension of the certification authority

     

    %6

     

    <ConfigurationContainer>

     

    The location of the Configuration container in Active Directory

     

    %7

     

    <CATruncatedName>

     

    The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end

     

    %8

     

    <CRLNameSuffix>

     

    Inserts a name suffix at the end of the file name when publishing a CRL to a file or URL location

     

    %9

     

    <DeltaCRLAllowed>

     

    When a delta CRL is published, this replaces the CRLNameSuffix with a separate suffix to distinguish the delta CRL

     

    %10

     

    <CDPObjectClass>

     

    The object class identifier for CRL distribution points, used when publishing to an LDAP URL

     

    %11

     

    <CAObjectClass>

     

    The object class identifier for a certification authority, used when publishing to an LDAP URL

     

     

    *Descriptions were taken from the following online document: Specify certificate revocation list distribution points in issued certificates, which is located at http://technet.microsoft.com/en-us/library/cc773036(WS.10).aspx

    So for example from line 4 of the configuration script we have the following:

    1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\

    This translates to the following:

    1. Publish CRLs to %WINDIR%\System32\CertSrv\CertEnroll\ directory.

    2. The filename of the CRL will be the name of the CA + a CRL name suffix + a “+” character if the file represents a CRL.

    3. Note that the only publication option set by this string instructs the CA to write the CRL to the specified location. This location will not appear in the actual certificates issued by the CA because that option was not specified.

    Understanding the variables and options not only allows you to understand what the script does, but also how to modify the script. It also allows you to understand the configuration when reviewing the Certificate Authorities configuration in the registry.

    In my example, I am happy with the default settings, so I am going to leave them in the default.

    On lines 7 through 9 of the script we define publication options for the CA certificate, commonly referred to as Authority Information Access.

    In interpreting the variables in the script you can use the Variable Table we used previously to decode the script or to encode your desired setting. However, since we will not be using any of the CRL related variables, only a subset of the options are available when working with AIA, they are outlined in the table below:

     

    Variable

     

    Variable Display Name in the CertSrv MMC

     

    Description

     

    %1

     

    <ServerDNSName>

     

    The DNS name of the certification authority server

     

    %2

     

    <ServerShortName>

     

    The NetBIOS name of the certification authority server

     

    %3

     

    <CaName>

     

    The name of the Certificate Authority

     

    %4

     

    <CertificateName>

     

    The renewal extension of the certification authority

     

    %6

     

    <ConfigurationContainer>

     

    The location of the Configuration container in Active Directory

     

    %7

     

    <CATruncatedName>

     

    The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end

     

    %11

     

    <CAObjectClass>

     

    The object class identifier for a certification authority, used when publishing to an LDAP URL

     

     

    When setting AIA publication, a different, smaller set of Options is available":

     

    Option Number

     

    0

     

    Not Defined

     

    1

     

    Automatically Publish CA Certificate to this location

     

    2

     

    Include in the AIA extension of issued certificates

     

    32

     

    Include in the online certificate status protocol (OCSP) extension

     

     

    As an example on line 8 we have the following:

    1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt

    This translates to:

    1. Publish the CA Certificate to %WINDIR%\system32\CertSrv\CertEnroll

    2. The file name of the CA certificate will be <ServerDNSName>_<CAName> with the renewal extension of the Certificate Authority.

    3. As with the CRL, the option specified indicates only that the CA should write the CA certificate to this location. This location will not be included in the AIA extension of certificates issued by this CA since that option was not specified.

    Next, on lines 10 and 11 we have the following:

    certutil -setreg CA\CRLPeriodUnits 180
    certutil -setreg CA\CRLPeriod "Days"

    These set the CRL Validity and Publishing period 180 days or roughly six months.

    Then on line 12 we have the following:

    certutil -setreg CA\CRLDeltaPeriodUnits 0

    This means that Delta CRLs will not be published because the publication period is zero.

    Next, on lines 13 and 14 we have the following:

    certutil -setreg ca\ValidityPeriodUnits 10
    certutil -setreg ca\ValidityPeriod "Years"

    These settings define the maximum validity period for certificates issued by the CA. Since this is a Root CA and only Subordinate CA certificates are going to be issued, this would be the validity period for the Subordinate CA certificate. In my case I only want my Subordinate CA to be valid for 5 years so I am going to change the entry in line 13 to reflect that, with the following change:

    certutil -setreg ca\ValidityPeriodUnits 5

    Then on line 15 we stop and start certificate services. We do that so that the new configuration can be read by the certificate authority:

    net stop certsvc & net start certsvc

    On line 16 we ensure that the CertEnroll share is created, and if IIS is installed, that the CertSrv virtual directory is installed.

    certutil –vroot

    Finally, on line 17 we publish a new CRL: 

    certutil -CRL

    So now we are done with the post-installation configuration script. The reason for understanding this script is so that you validate the values in the sample script are the ones you want implemented on your CA. If not, you can of course modify the sample script or create your own. The reason for using the sample script on the Root CA is that you validate all of the settings prior to implementing them. Also, if you are going to test your installation in a test environment, you can run this script and verify you get the results you are expecting. This will help eliminate any surprises you may have when implementing the Root CA in production.

    Issuing CA CAPolicy.inf

    The CAPolicy.inf file for my Issuing CA is fairly straight forward. You can actually configure quite a bit with these configuration files. Jonathan Stephens will be posting a blog on all of the settings that can be configured with the CAPolicy.inf file, so stay tuned. However, the PKI I am setting up is pretty straightforward, so I am only going to specify the Renewal Key Length, Renewal Validity, and direct the CA to not load the default certificate templates. The reason for not deploying the default certificate templates is that machines and users will be able to begin enrolling for the default templates if they have access once the installation of the CA is complete. In my case I want to make sure that I setup my templates to meet my business requirements before users and machines can enroll for certificates. The LoadDefaultTemplates setting works on Windows 2003 Root Enterprise CAs, Windows 2008 Root CAs, and Windows 2008 Subordinate CAs.

    [Version]
    Signature= "$Windows NT$"
    [Certsrv_Server]
    RenewalKeyLength=4096
    RenewalValidityPeriod=Years
    RenewalValidityPeriodUnits=5
    LoadDefaultTemplates=0

    Issuing CA Post-Installation Configuration Script

    The post-installation script I am using is based on the one in Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure. I am not going to go in as much detail for this script, since I covered all of the settings for the Root CA. Below is the script I will be using:

    certutil -setreg CA\CRLPublicationURLs "65:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n6:http://FCCA01.FOURTHCOFFEE.COM/certenroll/%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"

    certutil -setreg CA\CACertPublicationURLs  "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://FCCA01.FOURTHCOFFEE.COM/certenroll/%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11"

    certutil -setreg CA\CRLPeriodUnits 7

    certutil -setreg CA\CRLPeriod "Days"

    certutil -setreg CA\DeltaCRLPeriodUnits 2

    certutil -setreg CA\DelatCRLPeriod "Hours"

    net stop certsvc & net start certsvc

    certutil.exe -vroot

    certutil -CRL

    Lines 1-8 of the script will Configure CRL and AIA publication. You can use the tables in the previous section to determine if these are configured to meet your requirements. After examining the CDP and AIA publishing, the settings in the script happen to match the requirements of my environment.

    In lines 9 and 10 we configure the validity period and publication interval for the Base CRL. In my environment, my requirement is publication once a week. So, I will change line 10 to reflect this (Since this setting is used in combination with the certutil -setreg CA\CRLPeriod "Days" the resulting period will be seven days):

    certutil -setreg CA\CRLPeriodUnits 7

    After line 10 I am going to add two additional lines to configure my delta CRL publication so that a new delta CRL is published every two hours:

    Certutil –setreg CA\DeltaCRLPeriodUnits 2
    Certutil –setreg CA\DeltaCRLPeriod “Hours”

    PKI Installation Walkthrough

    Root CA Install

    1. Copy CAPolicy.inf to the c:\Windows directory.

    2. Start Server Manager and select Roles. In the Roles section click on Add Roles.

    3. This will start the Add Roles Wizard, click Next.

    4. On the Select Server Roles page of the wizard, select Active Directory Certificate Services and click Next.

    5. On the Introduction to Active Directory Certificate Services page, click Next.

    6. On the Select Role Services page, select Certification Authority, and click Next.

    7. On the Specify Setup Type page, make sure Standalone is selected, and click Next.

    8. On the Specify CA Type, select Root CA, and click Next.

    9. On the Set Up Private Key page of the wizard, and make sure Create a new private key is selected and click Next.

    10. On the Configure Cryptography for CA, you can select the CSP or KSP you wish to use, the Key Length for the Root Certification Authorities key, and the hash algorithm. Due to the business requirements of Fabrikam, I will be using the RSA Microsoft Software Key Storage Provider KSP, a key length of 4096 bits, and the SHA1 algorithm. (Check to determine supportability of stronger hash algorithms.) When finished click Next.

    11. On the Configure CA Name page enter the Common Name for the CA and the name suffix.

    12. When setting up the PKI for Fabrikam we are going to use Fabrikam Root Certification Authority for the Common Name and O=Fabrikam,C=US for the name suffix.

    13. When complete, click Next.

    14. On the Set Validity Period of the wizard, select the validity for the Root CA Certificate. As specified at the beginning of this post, Fabrikam is using a validity period of 10 years for the Root CA. Once complete, click Next to continue the wizard.

    15. On the Configure Certificate Database page, select the locations for the Certificate Services Database and logs. Fabrikam will be using the default file paths. Select Next, when complete.

    16. The Confirm Installation Selection page will summarize your selections. Review this information and then click Install.

    17. Once setup is complete, run the post-installation configuration script. Review the settings to determine they are set to your specifications.

    18. Copy the CRL and CRT files from c:\windows\system32\certsrv\certenroll to a Floppy or other removable media.

    19. Logon to the machine that will become the Enterprise CA. Attach the removable media. Run the following command to publish the Root CA Certificate to Active Directory: certutil –f –dspublish <CaCertFileName> RootCA.

    20. Then publish the CRL from the Root CA to Active Directory with the following command: certutil –f –dspublish <CrlFileName>.

    21. Wait sufficient time for replication to complete within your site.

    22. Run certutil –pulse. Running this command will trigger autoenrollment and the Root CAs Certificate and CRL will be downloaded automatically to the Trusted Root Certification Authority store on the local machine.

    Issuing CA Installation

    1. Copy the CAPolicy.inf file to the c:\Windows directory.

    2. Start Server Manager and select Roles. In the Roles section click on Add Roles.

    3. This will start the Add Roles Wizard, click Next.

    4. On the Select Server Roles page of the wizard select Active Directory Certificate Services and click Next.

    5. On the Introduction to Active Directory Certificate Services page, click Next.

    6. Part of the business requirements of Fabrikam is to have Web Enrollment available. As part of the plan we decided to install Web Enrollment on the Issuing CA, and in this way we could use it as the HTTP repository for CRLs and CA Certificates as well. If you wish to use the same approach, on the Select Role Services page, select Certification Authority and Certification Authority Web Enrollment, and click Next.

    7. You will then be prompted to add the additional IIS role services required to run Web Enrollment. Click on Add Required Role Services.

    8. On the Specify Setup Type page, select Enterprise, and click Next. Note: If you see the Enterprise option grayed out, that is an indication that the computer is not joined to the domain or you are not logged in with Enterprise Admin credentials.

    9. On the Specify CA Type page, select Subordinate CA, and click Next.

    10. On the Setup Private Key page, select Create a new private key, and click Next.

    11. On the Configure Cryptography for CA, you can select the CSP or KSP you wish to use, the Key Length for the Issuing Certification Authorities key, and the hash algorithm. Due to the business requirements of Fabrikam, I will be using the RSA Microsoft Software Key Storage Provider KSP, a key length of 2048 bits, and the SHA1 algorithm. (Check to determine supportability of stronger hash algorithms.) When finished click Next.

    12. On the Configure CA Name, enter the Common Name for the Issuing CA. The distinguished name should already be poplulated with the DN of the domain in which you are installing the CA. Fabrikam has the Common name set as “Fabrikam Issuing Certification Authority”, and the DN of course is set to DC=Fabrikam,DC=com. When finished click Next.

    13. On the Request Certificate from a Parent CA, select Save a certificate request to file and manually send it later to a parent CA. Then click the Browse button, navigate to Removable Media, enter a file name for the request, and click Save. Then click Next.

    14. On the Configure Certificate Database page, select the locations for the Certificate Services Database and logs. Fabrikam will be using the default file paths. Select Next, when complete.

    15. On the Web Server (IIS) page, click Next.

    16. On the Select Role Services page of the wizard, click Next.

    17. On the Confirm Installation Selections, select Install.

    18. You will then be prompted with the Installation Results. The results will indicate that installation is not complete because you still need to submit the request to the Root CA and then install the resulting certificate. Click Close to acknowledge the results.

    19. Take the removable media that you saved the request to and connect it to the Root CA. In the Certificate Services MMC (certsrv.msc) on the Root CA, select the root node (CA Name), right click, then select All Tasks, then Submit new request…, from the context menus.

    20. Browse to the request file and then select Open.

    21. The request will now be pending. Navigate to the Pending Request Folder and locate the request. Right click on the request, select All Tasks, and then Issue.

    22. Navigate to the Issued Certificates folder. Locate the certificate for the Issuing CA, Right click on the certificate and select Open. This will open the Certificate Properties. Select the Details tab, then click on the Copy to File… button.

    23. This will open the Certificate Export Wizard, click Next.

    24. Select DER encoded binary X.509 (.CER) and click Next.

    25. Click Browse…

    26. Navigate to Removable Media, enter a name for the certificate and then click Save.

    27. Then click Next.

    28. Then click Finish.

    29. You will be prompted that The export was successful. Click OK to acknowledge.

    30. Open the Certification Authority MMC on the Issuing CA. Right click on the Root Node (CA Name), select All Tasks, and Start Service.

    31. You will then be asked if you would like to install the CA Certificate, click Yes.

    32. Insert the removable media that contains the CA Certificate for the issuing CA. Browse to the certificate, and select Open.

    33. Next run the Post Installation Configuration Script and review the configuration to ensure that it meets your requirements.

    Conclusion

    In this installment we covered the requirements for a sample PKI deployment. We covered configuring the CAPolicy.inf and Post Configuration script. In Part III of this series I will cover a sample configuration and setup of Certificate Templates.

    - Chris “Duuuuude” Delay

     

    SET myADnamingcontext=DC=fourthcoffee,DC=com

    certutil.exe -setreg ca\DSConfigDN "CN=Configuration,%myADnamingcontext%"

    certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2:http://FCCA01.fourthcoffee.com/certenroll/%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"

    certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://FCCA01.fourthcoffee.com/certenroll/%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11"

    certutil -setreg CA\CRLPeriodUnits 180
    certutil -setreg CA\CRLPeriod "Days"

    certutil -setreg CA\CRLDeltaPeriodUnits 0

    certutil -setreg ca\ValidityPeriodUnits 5

    certutil -setreg ca\ValidityPeriod "Years"

    net stop certsvc & net start certsvc

    certutil -vroot

    certutil -CRL

     

  • New Directory Services KB Articles/Blogs 10/4-10/10

    KB

    976235

    You receive an error message that contains the event ID 11 error code when you try to update your Windows Vista-based computer by using Windows Update or Microsoft Update

    973780

    Some TCP connections between an NLB server that is running Windows Server 2008 and its clients are broken after the Port Scalability feature is enabled on the NLB server

    976442

    The performance of DFS Replication in Windows Server 2008 may be slow on a WAN connection without any error message being logged in the DFS Replication log

    973625

    A container object conflict occurs when you create a GPO for a wireless network policy by using the Group Policy Management MMC snap-in from a domain controller that is running Windows Server 2008 to connect to a PDC that is running Windows Server 2003

    Blogs

    NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7

    Managing Power with Group Policy Preferences: TechEd Online Video

    Free P2V tool: Disk2Vhd.exe

    Microsoft Exchange 2010 is done and released to manufacturing

    Installing WireShark on Windows 7 x64

    Interested in managing desktops with an online service? Get in on the private beta!

    Microsoft and Red Hat Complete Cooperative Technical Support

    Using NMAPI to Access TCP Payload

    New Fix it technology included in TechNet articles

    Guidance for placing several RODCs in the same site

    One subnet to catch them all

    Checking if you Conficker

    DirectAccess Design Guide – now available for download

    How to view SOAP XML messages to and from AD Webservices and Powershell

    AGPM: GPLinks are being destroyed each time I deploy

    List of All Domain Controllers in Your Domain

    Windows 7 / Windows Server 2008 R2: Console Host

    Top Issues for Microsoft Support Services on Windows Server 2008 Hyper-V

    Finding DCs reported in event id 1864 and a little bit of explanation around AdFind switches to get the info

  • New Directory Services KB Articles/Blogs 9/27-10/3

    KB

    976063

    When you run an LDAP query against a Windows Server 2008-based domain controller, you obtain a partial attribute list

    976267

    Filter Driver Registry Entries Are Migrated During Windows Vista or Windows Server 2008 Upgrade or Service Pack Setup

    975788

    Step-by-step: Turn off the secure desktop in Windows 7 without changing other UAC settings

    Blog

    Windows 7 / Windows Server 2008 R2: Core Parking / Intelligent Timer Tick / Timer Coalescing

    Windows 7 / Windows Server 2008 R2: Fault Tolerant Heap and Memory Management

    Mergers, acquisitions, or reorganizations may have you considering Active Directory restructuring

    Viewing and Comparing IE Security Zone Settings

    So I used Serverless Binding with ADSI (or .NET), now what DC am I talking to??

    Microsoft releases XP Mode virtualization to manufacturing

    Gui for 2008 r2 Recycle Bin

    Windows 7 / Windows Server 2008 R2: Upgrade Paths, Registry Enhancements, Crash Dumps and Page File Sizing

    Configuring a Power Plan with Group Policy Preferences (by Alan Burchill)

    John Fontana on SAML Interoperability

    New test results for SAML Profile For eGovernment

    DNS 6702