June, 2009

KB Articles

Blogs

· Internet Explorer behaviors with Kerberos Authentication

· Recovering from Unsupported One-Way Replication in DFSR Windows Server 2003 R2 and Windows Server 2008.

· Implementing an OCSP responder Part 1 (Part 2, Part 3)

· RSAT and ADUC for Vista - Update to add tabs for Terminal Services Profile, Environment, Sessions, and Remote Control

· Debunking the Vista Remote Differential Compression Myth

· Deploying DFSR Clustering in Windows Server 2008 R2

· How many DFS-N namespace servers do you need?

· Active Directory Enhancements - Windows Server 2008 R2 Demo Screencast 4 of 4

· Detection logic for PowerShell installation

· Discovery options with R2 AD Cmdlets

· Active Directory Port Requirements

· Use Active Directory Powershell to manage Windows 2003/2008 DCs

Chris here again. In part I of this series we covered the basics of how OCSP works. We also covered the underlying reasons for deploying an OCSP Responder. In Part II we covered configuring the Certificate Authorities for whom which the OCSP Responder will check revocation status for on behalf of the clients. In Part III we covered configuring and OCSP Responder to support an Enterprise CAs. You may use Standalone CAs in your environment. In this blog post, I will be covering deploying a Revocation Configuration to support a Standalone CA.

Enterprise CAs are very tightly integrated with Active Directory. As such the certificates for the Root CA and for intermediate CAs are published to Active Directory. These certificates are automatically placed in the appropriate certificate stores on the clients. If you publish the Root CA certificate that the issuing CA chains up to; in Active Directory the clients will have that Root CA certificate published to the Trusted Root Certification Authorities container in the user and machine store. If you have not, or do not plan to deploy the Root CA certificate through Active Directory and Group Policy you will need to manually publish the Root Certificates in the Trusted Root Certification Authority store.

Installing OCSP Responder Role

The first step is to install the OCSP Responder Role.

To install the OCSP Responder: Open a command prompt and type: servermanagercmd.exe –install ADCS-Online-Cert

Requesting and Installing the OCSP Responder Signing Certificate

The next step is to request the OCSP Response Signing Certificate from the Standalone CA. Since a Standalone CA does not have certificate templates we must manually request the attributes we would like in the certificate. To do this we use a utility called certreq.exe. More information for Certreq is available here: http://technet.microsoft.com/en-us/library/cc736326.aspx.

To use certreq we must first generate a configuration file. FIgure 1 shows a sample configuration file. The key items that must be included is the OCSP Signing OID, and the OCSP No Revocation Check Extension, otherwise known as the id-pkix-ocsp-nocheck extension.

Let us take a look at this configuration file.

· First we have [NewRequest] which is a required section indicating that this is for a new certificate request.

· Then we have the subject in X.500 format. You can also use the ldap format which is derived from X.500. For example: CN=FCOCSP01,DC=Fourthcoffe,DC=Com. Alternatively, you could use just the common name, such as CN=FCOCSP01.

· PrivateKeyArchive=False since we will not be archiving the private key.

· Exportable=True which gives us the option to export the private key if so desired.

· UserProtected=False which disables strong key protection.

· MachineKeySet =True which is used to indicte that the resulting certificate will be stored in the machine store.

· ProviderName=”Microsoft Enhanced Cryptographic Provider v1.0” specifies the Cryptographic Service Provider (CSP) that will be used.

· UseExistingKey Set=False indicates that this request is for a new certificate, with a new key pair.

· RequestType=CMC tells certreq to generate the request in CMC format.

· Then we specify the new section [EnhancedKeyUsageExtension] which indicates what extensions should be placed in the EKU Extension in the certificate. Under that extension we specify that this certificate can be used for OCSP Signing by specifying the OCSP Signing OID (OID=”1.3.6.1.5.5.7.3.9).

· We then start a new section called [Extensions] and specify that the id-pkix-ocsp-nocheck extension should be included in the certificate.

Below are the steps for generating the request and installing the signing certificate:

1. First we use certreq to generate the request file. We specify the configuration file and the output request file. The key pair for this certificate is generated at the same time the request file is created by Certreq.

2. Next, we must submit the request to the CA. Copy the request file over to the Standalone CA. From the Certification Authority MMC, right click on the CA Name, and select All Tasks from the context menu, and then Submit New Request.

3. Browse to the request file, and select Open.

4. The request will then show up in Pending Requests. Right click on the request, and select All Tasks from the context menu, then select Issue.

5. You will now find the requested Certificate under Issued Certificates. Double click on the certificate to view its properties.

6. Verify the certificate. Key things to look for here are the presence of the OCSP No Revocation Checking Extension. And that OCSP Signing is specified in the Enhanced Key Usage (EKU) Extension.

Exporting the Certificate from the CA

1. First select Copy to File from the Details Tab of the Certificate Properties. This will open the Certificate Export Wizard.

2. Click Next at the Welcome Screen.

3. Select DER encoded binary x.509 (.CER), and click Next.

4. Browse to the location where you which to save the resulting certificate, and give the certificate a name, and click on Save.

5. Click Finish at the Completing the Certificate Export Wizard screen.

6. You will be prompted that The export was successful. Click OK.

Installing the OCSP Response Signing Certificate

Copy the resulting certificate to the OCSP Server. Open up a command prompt. Navigate to the location where you saved the certificate file, and run certreq –accept <Certificate Name>, to complete the installation of the certificate.

Configuring Private Key Permissions

The Online Responder Service runs under the Network Service account. By default the Network Service account does not have access to private keys of certificates located in the Local Computer Personal store. To give the Network Service access, perform the following steps:

1. Open up the Certificates MMC targeted for the Local Computer.

2. Right click on the certificate, then select “All Tasks” from the context menu, and then select Manage Private Keys….

3. Click Add on the Permissions dialog box.

4. Type Network Service,and then click Check Names to resolve the name. Then click OK.

5. The Network Service only needs read permissions to the Private Key, so deselect the Allow privilege for Full Control, and verify the Allow privilege is granted for Read, and click OK.

Now that we have installed the OCSP Response Signing certificate, and configured Private Key permissions, we must now configure the Revocation Configuration for the CA, on the OCSP Responder. Open the OCSP Management Console. Follow the following steps to configure the Revocation Configuration:

1. Right click on Revocation Configuration, and select Add Revocation Configuration from the context menu.

2. This will start the Add Revocation Configuration wizard. Click Next, when presented with the Getting started with adding a revocation configuration screen.

3. On the Name the Revocation Configuration screen, give a name to the configuration, and click Next. Note: It is a good idea to name the configuration for the CA server, in case this Responder will be used for multiple CAs.

4. On the Select CA Certificate Location screen, Select a certificate from the Local certificate store, and click Next.

5. On the Choose CA Certificate screen, click Browse.

6. Select the CA certificate, for the CA you are configuring on the OCSP Responder, and click OK.

7. You will then be returned to the Choose CA Certificate screen. The CA that you selected will be displayed. Click Next to continue.

8. You will now need to select a signing certificate, on the Select Signing Certificate screen. Select Manually select a signing certificate, and click Next.

9. You will then be returned to the Revocation Provider screen, click Finish to complete the wizard.

Assigning the Signing Certificate

After completing the Wizard, you will notice under the “Revocation Configuration Status” portion of the “Online Responder Configuration” page that the OCSP Configuration that you just added has an error indicating “Bad Signing certificate on Array controller. No need to panic at this point. This error is generated because we have not assigned the OCSP Response Signing certificate yet.

Now let us go ahead and assign the Signing certificate.

1. In the OCSP MMC, expand Array Configuration, and click on the name of the OCSP Server. Then in the center pane of the console, select the appropriate Revocation Configuration, then right click on that revocation configuration, and elect Assign Signing Certificate from the context menu.

2. You will then be prompted select the Signing certificate. Select the appropriate Signing certificate, and click OK.

At this point you will now see some warnings. If you look under the Revocation Configuration Status for the Revocation Configuration you are configuring, you will notice this error:

Also, on the Online Responder Configuration page you will notice this error:

This is due to the fact that the Revocation Provider has not yet been verified. To verify the Revocation Provider, right click on Array Configuration, and select Refresh Revocation Data.

Once the Revocation Provider has been verified, you should see this under Revocation Configuration Status for the Revocation Configuration you are configuring.

And that OCSP Signing is specified in the Enhanced Key Usage (EKU) Extension.

Verify OCSP Configuration

To verify your ocsp configuration please follow the Verify OCSP Configuration section in Part III of this series.

Conclusion

This concludes Part IV of this Series. I hope you enjoyed the first four parts of the series and find them useful. I plan to cover other PKI topics in the near future.

Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs 
Implementing an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy

- Chris Delay

Ned here again. The DFSR development team has posted a new series for anyone wanting top learn more about the new DFSR clustering capabilities in Windows Server 2008 R2. It's pretty indepth and walks you through the entire process.

1. Deploying DFS Replication on a Windows Failover Cluster – Part I: Explains how to create a new Windows Server 2008 R2 failover cluster.
2. Deploying DFS Replication on a Windows Failover Cluster – Part II: Explains how to configure DFS Replication service for high availability on the failover cluster.
3. Deploying DFS Replication on a Windows Failover Cluster – Part III: Explains how to add the failover cluster as a member server in a DFS replication group.

Nice stuff, Mahesh!

- Ned Pyle

Chris here again. As promised I will be covering configuring an OCSP Responder to support Enterprise CA. I will also be covering validating your OCSP Configuration.

Installing OCSP Responder Role

The first step is to install the OCSP Responder Role.

To install the OCSP Responder: Open a command prompt and type: servermanagercmd.exe –install ADCS-Online-Cert.

Configuring the OCSP Responder

First we will add a Revocation Configuration to the OCSP Responder.

Right click on the Revocation Configuration and select Add Revocation Configuration from the context menu.

The Add Revocation Configuration wizard opens. Click Next to continue.

Give a Friendly Name to the Revocation Configuration, and click Next. It is a good idea to include the name of the CA for which you are setting up this Revocation Configuration, especially if this OCSP Responder will handle requests for multiple CAs.

On the Select CA Certificate page, you will need to select a CA certificate. This is where you determine the CA for which you will be providing revocation information.

Select a certificate for an Existing enterprise CA, and click Next

Select Browse CA certificates published in Active Directory, and click Browse.

Select the appropriate CA, and click OK

Next you will need to select a certificate that will be used for signing OCSP responses. For a particular Revocation Configuration, the OCSP Signing certificate must be issued by the CA for which the OCSP Responder will answer revocation status requests.

Select Automatically select a signing certificate. If you wish to automatically enroll for the OCSP Response Signing Certificate, make sure the Auto-Enroll for an OCSP signing certificate is checked. Select the certificate template that you configured for use with the OCSP Responder, then click Next.

On the Revocation Provider page, you can click Provider to select revocation providers. The Windows Server 2008 OCSP Responder can only use CRLs for revocation information. If you have the CDP Extension available in the signing certificate, the Revocation Providers will be populated from the information in the CDP Extension from the OCSP Response Signing Certificate.

You can add the repository locations for your CRLs and Delta CRLs if appropriate. By default these will be populated from information included in the CDP extension of the Signing certificate. After you have reviewed the configuration or made any changes, click OK.

That completes the initial Configuration of the OCSP Responder. If you would like to modify the configuration of the OCSP Responder, you can right click on the Revocation Configuration and select Properties from the context menu.

The Local CRL tab allows you to configure a Local CRL. You can add revocation information for certificates which you wish to consider revoked. It is recommended that you do not use this option, as it adds unnecessary complexity to the revocation configuration.

The Revocation Provider tab allows you to modify the location of the CRLs and Delta CRLs that will be used for providing revocation information.

Signing Tab

In the signing tab you can:

• Modify the hash algorithm used to sign responses.
• Do not prompt for credentials for cryptographic operations. This setting may need to be disabled if you are using an HSM to protect the private key of the OCSP Signing certificate. Disabling this setting allows you to be prompted for the password that is associated with the operator card on the HSM.
• Use renewed certificates for signing certificates. This option is enabled by default, when you use the OCSP Responder with an Enterprise CA and automatically renew certificates. If you use OCSP Responder with a standalone CA, the OCSP responder will use renewed signing certificates even if this setting is not enabled.
• Enable NONCE extension support allows the user to attach the NONCE sent in the request with the OCSP response. If this setting is used, you will not be able to utilize cached responses.
• Use any valid OCSP signing certificate. Not recommended if the OCSP Responder is supporting Vista clients since they do not support this option. This allows the OCSP responder to use any certificate that the OCSP Signing configured in the Extended Key Usage extension of the certificate. Vista clients will only accept OCSP responses that are signed by the same CA for which the OCSP Responder is providing revocation information.
• All responses will included the following Online Responder identifies: This setting determines whether a Key Hash or Subject will be included in the response. RFC 2560 specifies the structure of the response. In section 4.2.1 of the RFC it is specified that the Responder ID field can either be populated with a Name or Key hash. This setting determines which is included in the response. The Key hash is a hash of the OCSP Responder’s public key. The Name is the distinguished name of the subject of the OCSP signing certificate.

Verify OCSP Configuration

After configuring the OCSP Responder, you will want to verify that the OCSP responder is functioning properly. The easiest way to verify that the OCSP is functioning is to use the Certutil URL Retrieval tool.

First request a certificate from the CA. Place a copy of that cert on the file system, and run the following command: certutil –URL <Certificate Name>. This will open the URL Retrieval Tool

Select OCSP, and click on the Retrieve button.

If the certificate is valid you will get the following response.

If the certificate is revoked, you will get the following response.

And if it fails, the status will be listed as Failed.

You can also use the PKIView tool to verify the configurations of the OCSP Responder.

Conclusion

This concludes configuring an OCSP Responder to support an Enterprise CA. If you follow the steps listed here you now have your OCSP configured to support your Windows Server 2003 or Windows Server 2008 CA. In the next part of this series, I will be configuring an OCSP Responder to support Standalone CA.

Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs 
Implementing an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy

- Chris Delay

Ned here again. Have you ever visited Snopes.com? It’s a terrific urban legend reference where they research folklore. Snopes is the place you go to find out if eating Thanksgiving turkey makes you sleepy (it doesn’t), if Coca Cola can dissolve a tooth overnight (it can’t), or if a man really did live in a Paris airport for 8 years (he did!).

Today I’m going to talk about another urban legend – that removing the Remote Differential Compression feature from Windows Vista will make your file copying faster over the network.

Background on RDC

Remote Differential Compression (RDC) is a Microsoft algorithm that was originally created for DFSR five years ago. RDC divides a file’s data into chunks by using signatures. When a file exists on two computers and the file is modified, only the differing chunks need to be sent to the other computer.

An application needs to be specifically written to support RDC. Windows Vista and Windows 7 include MSRDC.DLL to allow apps like Windows Live Messenger to use that functionality.

The feature can be turned on and off within the Control Panel “Program and Features” applet.

When turned on, the MSRDC.DLL will exist in the %SYSTEMROOT%\System32 directory. When it’s turned off, this DLL is removed.

The Myth

Unfortunately, the Internet is full of people telling you that RDC will somehow make your network communication slower. I have no idea how this got started, but this nonsense has been reprinted on thousands of websites by people unfamiliar with the Scientific Method. Folks have actually convinced themselves that turning this feature on or off has some affect on file transfer speeds. While there are a variety of things you can do to speed up Vista file copy performance, this isn’t one of them.

The Method

So after hearing this baloney for the umpteenth time, I set out to debunk it once and for all:

• I setup a Windows Server 2008 SP2 file server and a Windows Vista SP2 client as virtual guests inside a Hyper-V host.
• Each guest got 1GB of RAM and a virtual gigabit NIC.
• I dropped a 3GB ISO file onto a share on the file server.
• I used robocopy.exe (which automatically reports bytes per second and megabytes per minute) to copy that ISO file five times with MSRDC.DLL installed, then five more times with MSRDC.DLL removed.
• In between every copy, I rebooted both the client and server to ensure that there was no caching of the file that might artificially improve my results.

The Results

Here is what I found after the ten total passes, with and without RDC installed:

Hmmm… What if I sort my data points highest to lowest?

Interesting. Let’s look at the actual averages:

With MSRDC.DLL installed: 1209.6838 MB/min

With MSRDC.DLL removed: 1208.1666 MB/min

Wait – so removing RDC actually made it slower? Not really – the variance there is well within any respectable margin of error. These results mean that the two sets of copies were 99.87% identical. Removing RDC did nothing at all. There are going to be various performance differences when copying a file, depending on what else happens on the network, what the computers are doing, and I think when people claim RDC removal made things ‘faster’, it’s because they are not testing repeatedly over time to see variance.

Maybe you want more proof? Alright, let’s go to the debugger.

• I installed Notmyfault on my Vista client and configured the computer for a complete memory dump
• I started yet another file copy, then I listed out the process and service information with TASKLIST.EXE and TASKLIST.EXE /SVC
• After a few seconds, I intentionally crash dumped (the so-called “Blue Screen of Death”) the Vista computer. I then cracked open the MEMORY.DMP file in the Windows debugger

First, I listed loaded modules - all libraries and drivers loaded in the kernel memory space:

Note how MSRDC.DLL is not loaded in memory in the Kernel space. It’s still possible that a given process or service might have it loaded though, so then I listed all processes to see which ones would be interesting and likely to be involved in file copies. The TASKLIST output comes in handy here to see which PID is which hexadecimal CID value. In my case though I dumped them all just for exploratory purposes.

I know that the Workstation Service is responsible for SMB file copying, and the robocopy process is definitely doing work, so I examined those.

Note how neither process has MSRDC.DLL loaded either. It’s simply not being used, and a module that is not being used cannot possibly affect anyone. Remember, an application has to be coded to use RDC. Nothing in the Kernel, in Robocopy, or in the Workstation service uses RDC at all in Vista or Win7.

Still don’t believe me? Here is the Microsoft Remote File Systems development team stating it as well.

Changes that can truly improve file copy performance

By now you want me to get to the helpful part. Here’s a short list of some things that can improve your file copy network performance on Windows Vista and Windows Server 2008:

• Install Service Pack 2
• Install the latest NIC drivers from your vendor.
• Try disabling Receive Side Scaling, Chimney Offload, and NetDMA support, then testing like I did above to see if the results are measurably different after many copies of the same file. Note that this just disables the Windows implementation of those components – your vendor may also support them through their NIC configuration and it will need to be turned off there as well. While these components are intended to help performance, mileage can vary based on how good your hardware and vendor drivers are.
• Use robocopy.exe rather than Explorer – the price of the friendly shell showing progress and browsing folders is slightly slower performance.

Wrapup

It’s amazing that a component that was designed to speed up network file performance can somehow be vilified as a cause of bad performance; especially when it’s not even being used. I welcome people following my steps and telling me what you find out.

Don’t believe everything you read on the Internet. Unless I wrote it. :-)

- Ned ‘Rick Rolled’ Pyle

Chris here again. In Part I we covered some of the basics and background information on the reason for the OCSP Responder and a basic understanding of how the OCSP Responder functions. So now we look towards implementing the OCSP Responder. However, before we move forward with the Install of the OCSP Responder we must first configure the CA to support OCSP for revocation status checking.

As discussed in the first part of this series, the OCSP Responder provides revocation information to clients or application requesting revocation status for a specific certificate. In order for this to be accomplished there are certain prerequisites that need to be in place.

Some of the prerequisites are different depending on which version of the CA you are using, and whether you are using a Standalone or Enterprise CA.

Configuring AIA Extension to support OCSP

To advertise that revocation status information for a particular CA can be obtained via OCSP, the CA must include a pointer to the OCSP Responder in the certificate. This is done by adding an OCSP URI to the AIA extension of the certificate.

Although this is mentioned as a prerequisite, you may want to do this after the OCSP Responder is configured. The reason being is that if you issue certificates before the Responder is available you will create unnecessary traffic to the soon to be OCSP location.

1. Open the Certification Authority Snap-in on the CA, as an Enterprise Administrator.

2. Right click on the CA name, and select Properties

3. Click on the Extension Tab. From the Select Extension drop down Box, select Authority Information Access (AIA).

4. Then click on the Add… button to add the OCSP location

5. Type the location for the OCSP responder. This will typically be:

http://<fqdn of the ocsp responder>/ocsp

6. Then click OK.

7. Check the Checkbox for Include in the online certificate status protocol (OCSP) extension.

8. And click OK, to close the CA Properties.

Preparing Windows Server 2003 Standalone CA for use with OCSP Responder

OCSP Signing Certificates

In order to be able to deploy the OCSP Signing Certificate used by the OCSP Responder, there are some configuration changes that need to be made on a Windows Server 2003 CA.

A signing certificate includes the id-pkix-ocsp-nocheck extension. This extension informs the OCSP client that the OCSP signing certificate should not be checked for revocation during the lifetime of the certificate. The OCSP Signing certificate should therefore have a short lifetime. By default, a Windows Server 2003 CA will ignore the id-pkix-ocsp-nocheck extension in a certificate request and will not include that extension in the issued certificate. To change this behavior, you must allow custom extensions to be used in certificate requests.

To enable support for custom extensions, run the following command on the CA:

The extension object ID (OID) for the id-pkix-ocsp-nocheck extension is1.3.6.1.5.5.7.48.1.5. The above command instructs the CA to include that extension in the issued certificate if it is found in the request.

Preparing Windows Server 2003 Enterprise CA for use with OCSP Responder

If you plan on using a Windows Server 2003 Enterprise CA to issue the OCSP Signing Certificate you will need to follow the instructions outlined in the previous section for enabling the use of custom extensions.

If you plan on using a certificate template on the Windows Server 2003 Enterprise CA, you must have at least 1 Windows Server 2008 Enterprise CA in the environment. The reason is you will be duplicating the Version 3 OCSP Signing Template on the Windows Server 2008 CA for use with the Windows Server 2003 CA. Both the Windows Server 2003 and Windows Server 2008 CA, must be running Enterprise Edition. This is due to the fact that only Version 1 templates are supported in the Standard Editions of the Server OS.

Duplicating the OCSP Signing Template

1. Logon to a Windows Server 2008 Enterprise CA, with an account that is a member of the Enterprise Admins group.

2. Open up the Certificate Template management console (certtmpl.msc).

3. Right click on OCSP Response Signing Template, and select Duplicate Template from the context menu, as illustrated below:

4. From the Duplicate Template dialog box, select Windows Server 2003 Server, Enterprise Edition, and click OK. Selecting Windows Server 2003 Server, Enterprise Edition, creates a Version 2 Template instead of a Version 3 Template.

 
5. Give a Name to the Duplicated Template, and click OK.

6. Log on to the Windows Server 2003 CA, and open the Certificate Authority Snapin (Certsrv.msc), and right click on Certificate Templates, and select New, then Certificate Template to Issue from the context menu.

7. Select the Duplicated Template, and click on OK.

Preparing Windows Server 2008 Standalone CA for use with OCSP Responder

In the previous section on preparing the Windows Server 2003 Standalone CA, we had to enable the CA to accept custom extensions sent in the request. This was to allow us to request a certificate with the id-pkix-ocsp-nocheck extension. Windows Server 2008 natively supports the id-pkix-ocsp-nocheck extension, so there is no need to allow custom extensions. On the Windows Server 2008 Enterprise CA there is no action necessary to support the id-pkix-ocsp-nocheck extension. However, on the Windows Server 2008 Standalone CA, we need to run the following command to add support for the id-pkix-ocsp-nocheck extension:

Preparing Windows Server 2008 Enterprise CA for use with OCSP Responder

The only preparation required for the Windows Server 2008 Enterprise CA, is to give permissions to the templates to the OCSP Servers, and to make the template available for issuance.

1. Open the Certificate Template Management console (certtmpl.msc)

2. Locate the OCSP Certificate Template, Right-click, and select Properties

3. On the Security Tab, add the hostname of the soon to be OCSP Server, and give the server Read and Enroll permissions to the template. Note: A more scalable solution, as seen in the illustration below, is to create a security group, assign permissions to the security group, and add any OCSP servers to the Security Group.

4. Go back to the Certification Authority management console, Right-click on the Certificates Templates node, and from the context menu, select New and then "Certificate Template to issue.

5. Select the OCSP Response Signing Template, and select OK.

Conclusion

You should now have your Certificate Authorities configured to support the OCSP Responder as a source of revocation status. In the next part of this series I will cover installing and the configuring the OCSP Responder to support Enterprise CAs.

Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs 
Implementing an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy

- Chris Delay

Ned here. After much strife, here is the hotfix to get RSAT AD Users and Computers to include tabs for:

• Terminal Services Profile 
• Environment 
• Sessions 
• Remote Control 

960890 Some tabs are not available in the properties of a user account in the Active Directory Users and Computers MMC snap-in after you install Remote Server Administration Tools (RSAT) on a computer that is running Windows Vista
http://support.microsoft.com/default.aspx?scid=kb;EN-US;960890

If you have been hacking away at this previously to make it work, make sure to unregister and remove your server DLL's before installing this update.

 Linda Taylor rules.

- Ned Pyle

KB Articles

Blog Posts