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

     

  • 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

  • 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

  • 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

  • New Directory Services KB Articles/Blogs 10/18-10/24

    KB

    976723

    IPv6 network address seems case-sensitive at address assignment for multiple network adapters installed on a Windows7 and Windows Sever 2008 R2 based computer.

    976647

    The migration of hotfixes may fail after the installation of a Windows Server 2003 or Windows XP service pack

    975702

    Error message when you change security settings for a folder that contains a child object for which you do not have access permission: "Access is denied"

    974971

    Error message when you use the CryptAcquireContext function to request a handle to a third-party CSP on a computer that is running Windows Vista or Windows Server 2008: "0x800b0100 (Invalid Signature)"

    974504

    The Windows Remote Manager (WinRM) service does not start after you uninstall WinRM 2.0 on Windows Server 2008 or on Windows Vista

    975815

    File corruption occurs under a stress situation when the CopyFileEx function is used to copy a file between two computers that are running Windows Server 2008 or Windows Vista

    976924

    You receive Windows Time Service event IDs 24, 29, and 38 on a virtualized domain controller that is running on a Windows Server 2008-based host server with Hyper-V

    974909

    The network connection of a running Hyper-V virtual machine is lost under heavy outgoing network traffic on a Windows Server 2008 R2-based computer

    974625

    You cannot uninstall ADMT 3.1 after you perform an in-place upgrade to Windows Server 2008 R2

    976659

    Known issues that may occur when you use ADMT 3.1 to migrate to a domain that contains Windows Server 2008 R2 domain controllers

    976826

    Upgrading a member server to Windows Server 2008 R2 does not fully remove FRS

    976736

    How to install Windows PowerShell on a computer that is running Windows Server 2008 R2 Core

    976888

    Error message when you try to manage a server that is running Windows Server 2008 R2 by using the Remote Server Administration Tools for Windows 7: "You do not have the permission to complete this task"

    Blogs

    ADMT, RODC’s, and Error 800704f1

    Importing the DFS Replication Management Pack

    Group Policy Slow Link Detection in Vista and beyond

    Linus Torvalds gives Microsoft Windows 7 a thumbs up!

    RDS CAL Single Pack now available in Retail channel

    View/Configure Protected ACL and Fixing Broken Inheritance

    Installing the DFS Replication Management Pack

    Windows 7 Virtual PC and XP Mode RTM - now available for download

    How do you tell AdFind that you only want just the xyz attribute returned?

    Interesting Issue with Major Implications

    Windows 7 / Windows Server 2008 R2: Problem Steps Recorder

    Group Policy Changes in Windows XP SP3

    Microsoft releases Windows-7-friendly version of Desktop Optimization Pack

    DFS Replication Management Pack for Operations Manager 2007 is available

    Windows 7 / Windows Server 2008 R2: AppLocker

  • Followup - more info on the new SCOM 2007 Management Pack for DFSR

    Hey all, Ned here again. Mahesh from the DFSR development team has new posts up on the System Center Operations Manager 2007 management pack that was released for DFSR. Give them a read, Mahesh always writes good stuff.

    Installing the management pack

    Importing the management pack

    Configuring the management pack

    Optional configuration – enabling backlog monitoring 

    These are in addition to the post I referenced back here

    - Ned 'the redirector' Pyle

  • 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