Blog - Title

October, 2009

  • Comment issues, continued

    Hey all. If you have a moment, please try and post a comment on this post. Especially non-Microsoft employees. We're still trying to see why comments stopped working.

    Update Nov 2: Well, it seems to be working now. :-) Thanks for all the help folks, it's much appreciated. Comment away, we'll see 'em now.

    Thanks,

    Ned

  • 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

     

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

    Ned here again. Windows 7 and Windows Server 2008 R2 introduce a long sought feature known as NTLM blocking. This prevents NTLM from being used for authentication. IT works in both a send or receive mode, and allows you to create exceptions.

    There’s currently very little documentation on this new capability, so I am going to get the ball rolling and talk about some techniques you can use to start evaluating if NTLM blocking will work for your network. Through the use of auditing techniques and application analysis, it is possible to correctly outline all NTLM use in an environment. This is a critical phase to complete before attempting to block NTLM – if you just start blocking arbitrarily you will likely have applications that stop working. Don’t say I didn’t warn you.

    NTLM auditing and analysis recommendations

     

    The key to rolling out NTLM blocking is that you must be systematic and take your time. I fully expect an NTLM blocking deployment to take at least 6 months of testing and analysis in a complex environment with hundreds of applications and thousands of computers. You may find applications that you had no idea were using NTLM, and they will need to be updated or reconfigured – that can really stretch out the timelines. Some elderly applications may simply use legacy code and will always require NTLM – this may cause you to abandon the blocking effort, or force you to come up with an exception strategy.

    Below are some guidelines for your auditing and analysis phase:

     

    1. Deploy all three types of NTLM auditing (See Enabling NTLM Auditing below).
    2. Deploy the auditing in a test environment as long as all applications have been inventoried and there is no reasonable possibility of users running unknown applications in production.
    3. Deploy auditing in the production environment if not all applications can be inventoried.
    4. Deploy the incoming and outgoing auditing policies to all servers and computers. Deploy the domain auditing on DC's only; it will have no effect on member computers.
    5. NTLM blocking in environments that have Vista/2008/XP/2003 or older OS's is not recommended. NTLM cannot be blocked on them directly and auditing/remote exceptions will be very difficult.
    6. Come up with an audit event collection strategy. This may include third parties, Event Subscriptions, or other methods. The key is to make sure that the events are not lost. Make sure the NTLM audit event logs are increased to a large enough size that they do not constantly wrap. 
    7. It is easier to monitor NTLM auditing on servers than clients - clients can be used for detailed analysis after server behaviors start becoming apparent.

    Expect to find a large number of applications using NTLM even if they theoretically support Kerberos:

    • Applications that allow various security configurations and providers (such as IIS or OCS)
    • Applications that have not been correctly configured with Service Principal Names (such as SQL or SharePoint)
    • Applications that use IP addresses instead of DNS names, due to misconfiguration or vendor documentation.
    • Applications with a legacy code base can have NTLM-only portions (i.e. they were originally written to work with Windows NT)

    When you find these applications, contact your vendor for further support. If a Microsoft application, contact that support specialty. The Directory Services team does not know your applications!

    Enabling NTLM Auditing

    There are three security policies introduced in Win7/R2 that support auditing NTLM. When accessed through GPMC.MSC and you edit a policy, they are stored in:

    Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options

    image

    To enable the deepest level of auditing, including both workgroup and domain authentication attempts that use NTLM, set:

    Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit All
    Network security: Restrict NTLM: Audit NTLM authentication in this domain =
    Enable all
    Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts

    Note: Configure "Audit NTLM authentication in this domain" on DC's only. Configure "Outgoing NTLM traffic to remote servers" and "Audit Incoming NTLM Traffic" on all computers.

    NTLM audit events are written out to this event log path:

    Event Viewer (Local)\Applications And Services Logs\Microsoft\Windows\NTLM\Operational

    image

    image

    Auditing for applications that do not communicate over SMB

    Applications that directly implement NTLM and use a protocol/transport other than SMB are generally easy to analyze. By enabling auditing most NTLM usage will be quickly apparent.

    Example walkthrough:

    1. Settings "Audit Incoming NTLM Traffic" and "Outgoing NTLM traffic to remote servers" are enabled on all servers and clients. "Audit NTLM authentication in this domain" is enabled on the DC's.

    2. Testers and users are evaluating various applications in the environment.

    3. 8004 events are being seen on the DC's - examination of DC 2008r2-f-01 shows:

    Log Name:      Microsoft-Windows-NTLM/Operational
    Source:        Microsoft-Windows-Security-Netlogon
    Date:          9/25/2009 10:47:36 AM
    Event ID:      8004
    Task Category: Auditing NTLM
    Level:         Information
    Keywords:     
    User:          SYSTEM
    Computer:      2008r2-f-01.contoso.com
    Description:
    Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
    Secure Channel name:
    2008R2-F-04
    User name: roberg
    Domain name: CONTOSO
    Workstation name: 7-X64-01
    Secure Channel type: 2

    3. Note the important information here - the time, user, domain, transitive logon, and originating workstation are all listed. User RoberG in the Contoso domain used NTLM to connect from his client 7-x64-01 to his server 2008r2-f-04 on Sept 25th at 10:47:36 AM.

    Also note that a DC event is not guaranteed - for example a local user account could be connected to a file server and that would require NTLM.

    4. 8003 events are being seen on the member servers - examination of server 2008r2-f-04 shows:

    Log Name:      Microsoft-Windows-NTLM/Operational
    Source:        Microsoft-Windows-NTLM
    Date:         9/25/2009 10:47:36 AM
    Event ID:      8003
    Task Category: Auditing NTLM
    Level:         Information
    Keywords:     
    User:          SYSTEM
    Computer:      2008r2-f-04.contoso.com
    Description:
    NTLM server blocked in the domain audit: Audit NTLM authentication in this domain
    User: roberg
    Domain: CONTOSO
    Workstation: 7-X64-01
    PID: 4
    Process:
    Logon type: 3
    InProc: true
    Mechanism: (NULL)

    Note how on the member server you have the 8003 event at the same time for the same user from the same client as in Step 3. You cannot see the Process ID though as - in this particular instance - the local processing came in through Kernel mode (PID 4 is SYSTEM). This means you will need to examine the client.

    5. 8001 events are logged on the clients that were seen in steps 3 and 4 and show the final important details:

    Log Name:      Microsoft-Windows-NTLM/Operational
    Source:        Microsoft-Windows-NTLM
    Date:          9/25/2009 10:47:36 AM
    Event ID:      8001
    Task Category: Auditing NTLM
    Level:         Information
    Keywords:     
    User:          SYSTEM
    Computer:      7-x64-01.contoso.com
    Description:
    NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked.
    Target server: HTTP/10.70.0.106
    Supplied user: roberg
    Supplied domain: CONTOSO
    PID of client process: 3416
    Name of client process: C:\Program Files (x86)\Internet Explorer\iexplore.exe
    LUID of client process: 0x384a35
    User identity of client process: Administrator
    Domain name of user identity of client process: CONTOSO
    Mechanism OID: (NULL)

    Note how the actual problem is now clear - users are connecting to the IP address of web servers, not the NetBIOS name or fully qualified domain name that would have allowed Kerberos to work. Furthermore you can see they were using Internet Explorer, so you know the application. Finally you can see that the user running the application is different from the credentials being supplied to logons from that application. All of this information will be helpful info in identifying behaviors and misconfigurations that will cause NTLM to be used.

    image 

    Auditing for applications that do communicate over SMB

    Applications that use a protocol/transport like SMB (via the redirector) are more difficult to analyze. This is because all communication - often to Named Pipes - is through kernel mode. When auditing these types of applications the only process ID (PID) that will appear is 4 - i.e. SYSTEM. By enabling auditing you will be able to locate the computers. Then by examining those computers under Process Monitor, the actual calling application will become visible.

    Example walkthrough:

    1. Settings "Audit Incoming NTLM Traffic" and "Outgoing NTLM traffic to remote servers" are enabled on all servers and clients. "Audit NTLM authentication in this domain" is enabled on the DC's.

    2. Testers and users are evaluating various applications in the environment.

    3. 8004 events are being seen on the DC's - examination of DC 2008r2-f-01 shows:

    Log Name:      Microsoft-Windows-NTLM/Operational
    Source:        Microsoft-Windows-Security-Netlogon
    Date:          9/30/2009 5:13:21 PM
    Event ID:      8004
    Task Category: Auditing NTLM
    Level:         Information
    Keywords:     
    User:          SYSTEM
    Computer:      2008r2-f-01.contoso.com
    Description:
    Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
    Secure Channel name: 2008R2-F-04
    User name: Administrator
    Domain name: CONTOSO
    Workstation name: 7-X64-01
    Secure Channel type: 2

    Note the important information here - the time, user, domain, transitive logon, and originating workstation are all listed. User Administrator in the Contoso domain used NTLM to connect from his client 7-x64-01 to his server 2008r2-f-04 on Sept 30th at 5:13:21 PM.

    Also note that a DC event is not guaranteed - for example a local user account could be connected to that would require NTLM.

    4. 8003 events are being seen on the member servers - examination of server 2008r2-f-04 shows:

    Log Name:      Microsoft-Windows-NTLM/Operational
    Source:        Microsoft-Windows-NTLM
    Date:          9/30/2009 5:13:21 PM
    Event ID:      8003
    Task Category: Auditing NTLM
    Level:         Information
    Keywords:     
    User:          SYSTEM
    Computer:      2008r2-f-04.contoso.com
    Description:
    NTLM server blocked in the domain audit: Audit NTLM authentication in this domain
    User: Administrator
    Domain: CONTOSO
    Workstation: 7-X64-01
    PID:
    4
    Process:
    Logon type: 3
    InProc: true
    Mechanism: (NULL)

    Note how on the member server you have the 8003 event at the same time for the same user from the same client as in Step 3. You cannot see the Process ID though as the local processing in this case came in through Kernel mode (PID 4 is SYSTEM). This means you will need to examine the client.

    5. 8001 events are logged on the clients that were seen in steps 3 and 4 and show the final important details.

    Log Name:      Microsoft-Windows-NTLM/Operational
    Source:        Microsoft-Windows-NTLM
    Date:          9/30/2009 5:13:21 PM
    Event ID:      8001
    Task Category: Auditing NTLM
    Level:         Information
    Keywords:     
    User:          SYSTEM
    Computer:      7-X64-01.contoso.com
    Description:
    NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked.
    Target server: cifs/10.70.0.106
    Supplied user: (NULL)
    Supplied domain: (NULL)
    PID of client process: 4
    Name of client process:
    LUID of client process: 0x14e5b2
    User identity of client process: Administrator
    Domain name of user identity of client process: CONTOSO
    Mechanism OID: (NULL)

    Examining the client shows us that SMB (CFS) is being used, but the process is still 4 for SYSTEM. This is because any application authenticating while using SMB as a transport is going through the client redirector in kernel mode. The actual calling application is opaque to the auditing, because the actual caller for authentication is the redirector, which runs in the kernel. So you will need to dig deeper with Process Monitor.

    6. Install Process Monitor on the computer that is sending NTLM credentials through SMB (in this case, 7-X64-01.contoso.com). Process monitor can be downloaded from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx.

    7. Set a filter in Process Monitor for the Path to start with the remote server throwing 8003 events. Make sure to set the filter for both the computername and the IP address. This will require giving the user of that computer Admin rights temporarily, during this analysis phase. Alternatively, this could be done through boot logging so that PM is always running silently in the background (note: filtering does not apply with boot logging, so ensure you have plenty of free disk space in that case).

      Path \ begins with \ <server name> \ Include
      Path \ begins with \ <server IP address> \ Include

    Example:

    image

    8. Wait for the issue to reproduce through user application use.

    9. Examine the Process Monitor log output and compare the time stamps to when the 8003 events occurred. Applications that call into SMB will (hopefully) be easily discernable in the log data.

    For example:

      Explorer.EXE 2300 FileSystemControl \\10.70.0.106\IPC$
      Explorer.EXE 2300 FileSystemControl \\10.70.0.106\IPC$
      Explorer.EXE 2300 CloseFile \\10.70.0.106\IPC$
      Explorer.EXE 2300 QueryOpen \\10.70.0.106\SharedData\
      Explorer.EXE 2300 CreateFile \\10.70.0.106\SharedData\
      Explorer.EXE 2300 QueryBasicInformationFile \\10.70.0.106\SharedData\
      Explorer.EXE 2300 QueryBasicInformationFile \\10.70.0.106\SharedData\
      Explorer.EXE 2300 CloseFile
    \\10.70.0.106\SharedData\

    By modifying the Process Monitor column headers, you can also correlate the time, user, and authentication ID's seen in the 8001 events:

    image

    Note how the time, user, path, and authentication ID all line up with the previous NTLM audit events. Explorer is the calling application. Further investigation and interview of the end user determines that they are mapping drives by IP address, forcing the use of NTLM.

    More Information and the Big Finish

    For the current NTLM Restriction doc on TechNet, see:

    Introducing the Restriction of NTLM Authentication

    For future docs on TechNet (no ETA on release date, so don’t ask me):

     

    Discovering and Auditing NTLM Usage Step-by-Step Guide

    Restricting NTLM Usage Step-by-Step Guide

    Update 2/23//2012: He's dead, Jim...

     

    NTLM blocking does not totally turn off NTLM on a computer. After all, a local logon uses NTLM. So if you are at home and log on with your computername\user account, the logon will work even if NTLM is disabled fully through group policy. Your Windows 7 client does not run a local KDC after all…

    NTLM blocking is no joke. I didn’t bother to discuss how you actually disable NTLM here because you’re not ready to do it yet. NTLM blocking can be a résumé generating event!

       - Ned “seriously, just audit for now” Pyle

  • 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

  • How to Decommission an ADAM/ADLDS server and Add Additional Servers

    Hello, LaNae here again. Recently I worked with a customer that was looking for a comprehensive document that outlined the steps for decommissioning a server that had an ADAM/ADLDS instance installed on it. I along with the customer realized there is no such document and you have to piece together multiple documents to get the steps. I decided to write this blog at the urging of the customer so that others do not have this issue.

    For the purpose of this blog we will work with the following example:

    Current Configuration

    • There are 2 ADAM/AD LDS instances in one configuration set.
    • Server A and Server B are the names of the servers that host the instances.

    Goal

    Add Server C and Server D and install and configure ADAM/AD LDS instances that will be part of the existing configuration set. Remove the ADAM/AD LDS instances from Server A and Server B and decommission them.

    Overview of Steps

    1. Install ADAM or the AD LDS role on servers C and D.

    2. Install and configure the ADAM/AD LDS instances one on each server to be members of the existing configuration set. Steps for ADAM: Managing Configuration Sets Steps for AD LDS: Practice Managing Replica AD LDS Instances

    3. Once replication is complete you will need to transfer the ADAM/AD LDS built-in FSMO roles from Server A or B which ever holds the roles to Server C or D. There are only 2 roles you will need to transfer, Naming Master and Schema Master. Replication in ADAM or AD LDS

    Check Replication

    From an ADAM command prompt or regular command prompt depending on whether this is ADAM or AD LDS you can run the following command to check replication.

    Repadmin /showreps servername:portnumber of instance

    Determining FSMO Role Holder

    If ADAM is installed all the following steps must be done from the ADAM command prompt. If using ADLDS a regular command prompt is fine.

    1. Type dsmgmt <enter>

    2. Type roles <enter>

    3. Type connections <enter>

    4. Type connect to server servername:portnumber of instance <enter>

    5. Type quit <enter>

    6. Type select operation target <enter>

    7. Type list roles for connected server <enter> Note: This should list who owns the FSMO roles.

    image

    Transfer FSMO Roles to new Server

    The following steps need to be done from an ADAM command prompt if running ADAM.

    1. Open an ADAM tools command prompt.

    2. At the command prompt, type: dsmgmt

    3. At the dsmgmt: command prompt, type: roles

    4. At the FSMO maintenance: command prompt, type: connections

    5. At the server connections: command prompt, type: connect to server servername:portnumber where servername:portnumber is the computer name and communications port number of the ADAM instance that you want to use as the new naming master or schema master.

    6. At the server connections: command prompt, type: quit

    7. At the FSMO maintenance: command prompt, type: transfer rolename

    image

    Remove the Instances from the old servers

    To remove an ADAM instance

    1. Open Add or Remove Programs.

    2. Click Change or Remove Programs, and then click the ADAM instance that you want to remove.

    3. Click Remove.

    To remove an AD LDS instance

    1. To open Programs and Features, click Start, click Settings, click Control Panel, and then double-click Programs and Features.

    2. Locate and click the AD LDS instance that you want to remove.

    3. Click Uninstall.

    You can now decommission Server A and B.

    - Lanae Wade

  • DFS Referrals and IPv6: Outta site!

    Hi, David Everett here again to discuss an issue where DFS clients connect to out-of-site targets when the IPv6 protocol has been partially disabled using an incorrect method.

    The customer deployed a DFS link replicated by DFSR. An in-site DFS namespace (DFSN) target called ContosoFS1 was deployed in the branch site. It wasn’t long before branch site users started reporting slow performance access data on the DFS link.

    The 1st step was to determine what Active Directory site the DFS clients resided, whether in-site targets existed in the DFS referral and if the in-site target was the Active Target of the DFS client.

    To determine which site the client thought it belonged to in Active Directory, we ran this command from the client’s command prompt:

    Nltest.exe /dsgetsite

    This returned the correct site name. Then in order to determine if the in-site target server was appearing in the list of servers we had the user connect to the DFS link and had the user run this command at the command prompt:

    Dfsutil.exe /pktinfo

    We found that the client was seeing the in-site DFS target server in the referral. As shown below the in-site DFS target server, which is also a DFS Root server, was at the top of the referral order for \\contoso\dfsroot but ContosoFS1 was at the bottom of the referral order for the in-site folder target.

    c:\>dfsutil /pktinfo
    Microsoft(R) Windows(TM) Dfs Utility Version 4.2
    Copyright (C) Microsoft Corporation 1991-2005. All Rights Reserved.

    --mup.sys--
    4 entries...
    Entry: \Contoso\DFSRoot
    ShortEntry: \Contoso\DFSRoot
    Expires in 0 seconds
    UseCount: 3 Type:0x81 ( REFERRAL_SVC DFS )
       0:[\ContosoFS1\DFSRoot] State:0x119 ( ACTIVE TARGETSET )
       1:[\ContosoFS2\DFSRoot] State:0x09 ( )
       2:[\ContosoFS3\DFSRoot] State:0x109 ( )
       3:[\ContosoFS4\DFSRoot] State:0x09 ( )
       4:[\ContosoFS5\DFSRoot] State:0x09 ( )

    Entry: \Contoso\DFSRoot\TargetFolder
    ShortEntry: \Contoso\DFSRoot\TargetFolder
    Expires in 0 seconds
    UseCount: 0 Type:0x1 ( DFS )
       0:[\ContosoFS4\TargetFolder] State:0x131 ( ACTIVE TARGETSET )  
    <- out of site IPv4-only W2K3 target that client is connected to
       1:[\ContosoFS3\TargetFolder] State:0x21 ( )   
    <- out of site IPv4-only W2K3 target
       2:[\ContosoFS5\TargetFolder] State:0x21 ( )   
    <- out of site IPv4-only W2K3 target
       3:[\ContosoFS1\TargetFolder] State:0x121 ( )    <- In-site target that should be at top of list but isn't because IPv6 is incorrectly disabled

    Once we knew the client was determine its site correctly from active Directory and that the in-site DFS target server was appearing in the DFS referral the focus turned from the client to the Active Directory and the target server.

    A quick glance at Active Directory Sites and Services snap-in suggested the IPv4 Site/Subnet logic was properly configured and correct site discovery by the client reinforced this. However, there were no Site/Subnet associations for IPv6 which is the preferred protocol for Windows Server 2008.

    Since IPv6 is the preferred protocol for Vista and later Operating Systems I was going to implement an IPv6 Site/Subnet association in Active Directory Sites and Services and see if this would improve DFS referral ordering of the in-site DFS target server. I checked the configuration of IPv6 on ContosoFS1 and found the protocol had been unchecked; which is not a good practice.

    It’s a common misconception that unchecking IPv6 disables the protocol when in fact all it does is introduce transient errors. Windows Vista and later operating systems heavily rely upon IPv6 for internal operation, which means the protocol cannot be disabled or uninstalled entirely. Unchecking IPv6 on the adapter settings only unbinds the protocol from the NIC and the OS can still attempt to send remote traffic to the NIC where it never hits the wire.

    There are three solutions for this:

    I. The preferred method is to place a check mark next to "Internet Protocol Version 6 (TCP /IPv6)" on the IP Properties of the Adapter and reboot the server.

    II. Configure Static IPv6 addresses on your Windows Server 2008 DFS target servers and then define IPv6 Subnet/Site associations in Active Directory Sites and Services. See the following TechNet article on how to do this:

    Create a Subnet Object or Objects and Associate them with a Site

    III. For those who have some aversion to having any IPv6 traffic hitting the wire there is a “supported” [not recommended by the Microsoft Product Group] way to disable outbound IPv6 using the DisabledComponents registry value as directed in KB929852. Contrary to what the article states, it is possible to simply use Group Policy Preferences to disable IPv6 domain-wide – there is no need for a custom ADMX.

    NOTE: It is beyond the scope of this blog to determine which components of IPv6 should be disabled in a given environment using DisabledComponents. To completely disable all External use of IPv6 configure DisabledComponents to ffffffff. Also, if you find IPv6 remains checked in the UI after configuring DisabledComponents in the registry rest assured the protocol is disabled for all remote traffic.

    For those interested in more about DFS Site Discovery and Target Selection please see the DFS FAQ.

    -David “Dy-no-miiiite!” Everett

  • Group Policy Slow Link Detection using Windows Vista and later

    Mike here again. Many Group Policy features rely on a well connected network for their success. However, not every connection is perfect or ideal; some connections are slow. The Group Policy infrastructure has always provided functionality to detect slow links. However, the means by which Group Policy determines this are different between operating systems prior to Windows Server 2008 and Windows Vista.

    Before Windows Server 2008 and Vista

    Windows Server 2003, Windows XP, and Windows 2000 Group Policy uses the ICMP protocol to determine a slow link between the Group Policy client and the domain controller. This process is documented in Microsoft Knowledgebase article 227260: How a slow link is detected for processing user profiles and Group Policy (http://support.microsoft.com/default.aspx?scid=kb;EN-US;227260).

    The Group Policy infrastructure performs a series of paired ICMP pings from the Group Policy client to the domain controller. The first ping contains a zero byte payload while the second ping contains a payload size of 2048 bytes. The results from both pings are computed and voila, we have the bandwidth estimation. However, using ICMP has some limitations.

    Many "not-so-nice" applications use ICMP maliciously. This new found use increased ICMP’s popularity forced IT professional to take precautions. These precautions included blocking ICMP. The solution to block ICMP provided relief from the susceptibility of malicious ICMP packets, but broke Group Policy. Workarounds were created (Microsoft Knowledgebase article 816045 Group Policies may not apply because of network ICMP policies); But the update did not remove the ICMP dependency.

    The Windows Server 2008 and Vista era

    Windows 7 and Windows Vista to the rescue! These new operating systems implement a new slow link detection mechanism that DOES NOT use ICMP-- but we already knew this. The question we will answer is how does the new Group Policy slow link detection work?

    The easy answer to how the new slow link detection works is Network Location Awareness (NLA). This networking layer service and programming interface allows applications, like Group Policy, to solicit networking information from the network adapters in a computer, rather than implementing their own methods and algorithms. NLA accomplishes this by monitoring the existing traffic of a specific network interface. This provided two important benefits: 1) it does not require any additional network traffic to accomplish its bandwidth estimate-- no network overhead, and 2) it does not use ICMP.

    Group Policy using NLA

    The question commonly asked is how does Group Policy slow link detection implement NLA. The actual algorithms used by NLA are not as important as what Group Policy does during its request to NLA for bandwidth estimation.

    Locate a domain controller

    A Group Policy client requires communication with a domain controller to successfully apply Group Policy. The Group Policy service must discover a domain controller. The service accomplishes this by using the DCLocator service. Windows clients typically have already discovered a domain controller prior to Group Policy application. DCLocator caches this information makes it available to other applications and services. The Group Policy service makes three attempts to contact a domain controller, with the first attempt using the domain controller information stored in the cache. The latter two attempts force DCLocator to rediscover domain controller information. Retrieving cached domain controller information does not traverse the network, but forceful rediscovery does. Domain controller information includes the IP address of the domain controller. The Group Policy service uses the IP address of the domain controller (received from DCLocator) to begin bandwidth estimation.

    During bandwidth estimation

    The Group Policy service begins bandwidth estimation after it successfully locates a domain controller. Domain controller location includes the IP address of the domain controller. The Group Policy service performs the following actions during bandwidth estimation.

    NOTE: All actions listed in this section generate network traffic from the client to the domain controller unless otherwise noted. I've included a few actions that do not generate network traffic because their results could be accomplished using methods that generate network traffic. These actions are added for clarity.

    Authentication

    The first action performed during bandwidth estimation is an authenticated LDAP connect and bind to the domain controller returned during the DCLocator process. This connection to the domain controller is done under the user's security context and uses Kerberos for authentication. This connection does not support using NTLM. Therefore, this authentication sequence must succeed using Kerberos for Group Policy to continue to process. Once successful, the Group Policy service closes the LDAP connection.

    NOTE: The user's security context is relative to the type of Group Policy processing. The security context for computer Group Policy processing is the computer. The security context for the user is the current user for the current session.

    The Group Policy service makes an authenticated LDAP connection as the computer when user policy processing is configured in loopback-replace mode.

    Determine network name

    The Group Policy services then determines the network name. The service accomplishes this by using IPHelper APIs to determine the best network interface in which to communicate with the IP address of the domain controller. The action also uses Winsock APIs; however, this action does not create any network traffic. Additionally, the domain controller and network name are saved in the client computer's registry for future use.

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History is where the service stores these values. The value names are DCName and NetworkName.

    NOTE: The NetworkName registry value is used by the Windows firewall to determine if it should load the domain firewall profile.

    Site query

    Group Policy processing must know the site to which the computer belongs. To accomplish this, the Group Policy service uses the Netlogon service. Client site discovery is an RPC call from the client computer to a domain controller. The client netlogon service internally caches the computer's site name. The time-to-live (TTL) for the site name cache is five minutes. However, TTL expiry is on demand. This means the client only checks the TTL during client discovery. This check is implemented by Netlogon (not the Group Policy service). If the cached name is older than five minutes from when the name was last retrieved from the domain controller, then the Netlogon service makes an RPC call to the domain controller to discover the computer site. This explains why you may not see the RPC call during Group Policy processing. However, the opportunity for network traffic exists.

    Determine scope of management

    The following Group Policy actions vary based on Group Policy processing mode. Computer Group Policy processing only uses normal Group Policy processing. However, user Group Policy processing can use normal, loopback-merge, and loopback-replace modes.

    Normal mode

    Normal Group Policy processing is the most common Group Policy processing actions. Conceptually these work the same regardless of user or computer. The most significant difference is the distinguished name used by the Group Policy service.

    Building the OU and domain list

    The Group Policy service uses the distinguished name of the computer or user to determine the list of OUs and the domain it must search for group policy objects. The Group Policy service builds this list by analyzing the distinguished name from left to right. The service scans the name looking for each instance of OU= in the name. The service then copies the distinguished name to a list, which it uses later. The Group Policy service continues to scan the distinguished name until for OUs until it encounters the first instance of DC=. At this point, the Group Policy service has found the domain name, which completes the list. This action does not generate any network traffic.

    Example: Here is the list from a given distinguished name

    Distinguished Name:
                cn=user,OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
    List:
                OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
                OU=hq,DC=na,DC=contoso,DC=com
                DC=na,DC=contoso,DC=com

    Evaluate scope of management

    The Group Policy service uses the list OUs to determine the Group Policy objects linked to each scope of management and the options associated with each link. The service determines linked Group Policy objects by using a single LDAP query to the domain controller discovered earlier.

    LDAP requests have four main components: base, scope, filter, and attributes. The base is used to specify the location within the directory the search should begin, which is usually represented as a distinguished name. The scope determines how far the search should traverse into the directory; starting from the base. The options include base, one-level, and subtree. The base scope option limits the search to only return objects matching the filter that matches the base. The onelevel option return objects from one level below the base, but not including the base. The subtree option returns objects from the base and all levels below the base. The filter provides a way to control what objects the search should return (see MSDN for more information on LDAP search filter syntax). The attribute setting is a list of attributes the search should return for the objects discovered that match the filter.

    The service builds the LDAP request with the following arguments:

    BaseDN:  domain
    Scope: Sub Tree
    Filter: (|(distinguishedname=OU=xxx)( more OUs)(ends domainNC DC=))
    Attributes: gpLink, gpOptions, ntSecurityDescriptor

    Example:  Scope of management LDAP search
           BaseDN: DC=na,DC=contoso,DC=com
           Scope: SubTree
           Filter: (|(distinguishedname= OU=marketing,OU=hq,DC=na,DC=contoso,DC=com)
                   (distinguishedname =OU=hq,DC=na,DC=contoso,DC=com)
                   (distinguishedname =DC=na,DC=contoso,DC=com))
        Attributes:gPlink,gPoptions,nTSecurityDescriptor

    Determining the scope of normal Group Policy processing mode occurs in the security context of the applying security principal. The computer performs the LDAP query computer processing and the user performs the LDAP query for user processing. Merge and Replace are user-only processing modes, which occur under the security context of the user.

    Replace user-processing performs an LDAP query using the computer’s distinguished name. Each component of the distinguished name is inserted into the filter portion of the LDAP query. The LDAP query filter parameter ends with the distinguished name of the domain (which is assembled using the parts of the computer’s distinguished name.

    Merge user-processing performs two LDAP queries. The first LDAP query uses the distinguished name of the user object. The second query uses the distinguished name of the computer object. The Group Policy links returned from both queries are merged into one list. The Group Policy service merges these lists together by adding the Group Policy links returned from the computer query to the end of the list of Group Policy links returned from the user query. Concatenating the computer list to the end of the user list results with the Group Policy links listed in the order they apply.

    Determine the Link Status:

    The Group Policy service is ready to determine the status of the link between the client computer and the domain controller. The service asks NLA to report the estimated bandwidth it measured while earlier Group Policy actions occurred. The Group Policy service compares the value returned by NLA to the GroupPolicyMinTransferRate named value stored in HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon, which is the preference key or, HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System, which is the policy key. The default minimum transfer rate to measure Group Policy slow link is 500 (Kbps). The link between the domain controller and the client is slow if the estimated bandwidth returned by NLA is lower than the value stored in the registry. The policy value has precedence over the preference value if both values appear in the registry. After successfully determining the link state (fast or slow—no errors), then the Group Policy service writes the slow link status into the Group Policy history, which is stored in the registry. The named value is IsSlowLink and is located at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History. This value is an REG_DWORD value that is interpreted as a Boolean value; with a non-zero value equaling false and a zero value equaling true. If the Group Policy service encounters an error, it read the last recorded value from the history key and uses that true or false value for the slow link status.

    Conclusion

    Group Policy slow link detection has matured since the days of using ICMP for slow link detection. Today, Windows 7 and Windows Vista’s Group Policy services use NLA to sample TCP communication between the client and the domain controller, without sending additional network traffic.

    - Mike “Huuuh, whaaaa?” Stephens

  • Using ADMT 3.1 to migrate to Windows Server 2008 R2 domains

    UPDATE June 19 2010 - stop reading and go here, we released ADMT 3.2:

    http://blogs.technet.com/b/askds/archive/2010/06/19/admt-3-2-released.aspx

    ===============

    Hi all, Ned here again. Microsoft is still working on ADMT 3.2, which can be installed on Windows Server 2008 R2 servers for migrations. There's no estimated date for this new tool yet.

    In the meantime, we have tested ADMT 3.1 and come up with supported scenarios for using it to migrate to R2 domains. Below are two KB articles that cover the requirements, what's supported, and known issues. As anyone who has emailed me already knows, we definitely support running ADMT 3.1 on a Windows Server 2008 DC or member server in an R2 domain, and migrating with it will be supported. Read more about this:

    Known issues that may occur when you use ADMT 3.1 to migrate to a domain that contains Windows Server 2008 R2 domain controllers - http://support.microsoft.com/kb/976659

    You cannot uninstall ADMT 3.1 after you perform an in-place upgrade to Windows Server 2008 R2 -
    http://support.microsoft.com/kb/974625 

    Important note: If you do not have Windows Server 2008 (i.e. you went from Windows 2000 or Windows Server 2003 straight to Windows Server 2008 R2), you do have downgrade rights. See this website on how to get product keys and media for R2:

    http://www.microsoft.com/windowsserver2008/en/us/downgrade-rights.aspx

    Perhaps the onslaught of emails about this can now subside... :-)

    - Ned "go go go" Pyle