Blog - Title

May, 2010

  • New Directory Services Content 5/16-5/22



    The first data point that is in a Performance Monitor log .csv file may be a larger number than expected in a Windows Server 2003-based domain


    File Services management pack has been released

    ADFS/SharePoint webcast w/Brjann Brekkan

    Group Policy Setting of the Week 26 – Do not automatically make redirected folders available offline

    Work Remotely with Windows PowerShell without using Remoting or WinRM

    File Services Management Pack for System Center Operation Manager 2007 is available

    KB978098 Focus: Large “Folder Redirection” issue

    The case of the blank file properties dialog

    Configuring applications in Windows with Group Policy preferences

    Moving the NTP service to a new PDCe

    How to exclude individual users or computers from a Group Policy Object

    Run Diagnostics to Check Your System for Memory Problems

    Locating Domain Controllers To Access The Default Domain DFS (SYSVOL/NETLOGON)

    Infrastructure Planning and Design Guides

    Information About Upgrading to Windows Server 2008 R2 AD

    AD Schema Changes Made by Exchange

    New Networking-related KB articles for the week of May 9 – May 15

    Enable and Use Remote Commands in Windows PowerShell

    AD FS 2.0 … a SAML Promise Delivered!

    AD FS 2 proxy management

    File upload/download and remote program execution using WS-Management

    Issuing Information Cards with AD FS 2.0

    Servicing a Server Core Installation

    Manage Windows 7 Power Options from the Command Line

  • Designing and Implementing a PKI: Part III Certificate Templates

    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 this segment I will be covering setting up certificate templates on the newly created CA hierarchy. Enterprise Certification Authorities (CAs), as well as clients, utilize what are called certificate templates. Certificate templates contain properties that would be common to all certificates issued by the CA based on that template. Windows includes several predefined templates, but Administrators also have the ability to create their own templates specific for their enterprise. When requesting a certificate, a client can just specify the template name in the request and the CA will build the certificate based upon the requestor’s information in Active Directory and the properties defined in the template.

    Certificate templates are also used to define the enrollment policy on the CA. First, an Enterprise CA can only issue certificates based upon the templates it is configure to use. For example, if the CorpUserEmail template is not available on the CA then the CA cannot issue certificates based on that template. Second, permissions set on the certificate template’s Active Directory object determine whether or not a user or computer is permitted to request a certificate based on that template. If a user does not have Enroll permissions on a particular template, the CA will deny any request submitted by the user for a certificate based on that template.

    As the Windows Server operating system has evolved over the last ten years, so has the concept of the certificate template. Currently, there are three versions of templates:

    Version 1 templates were introduced in Windows 2000, and can be used by Windows 2000, Windows Server 2003 (R2), and Windows Server 2008 (R2) Enterprise CAs. Version 1 templates Active Directory objects are created the first time an Enterprise CA is created in the forest. These templates were designed to reflect the most common scenarios for digital certificates in the Enterprise. Unfortunately, if you don’t like the settings we selected you’re pretty much out of luck. Creating new v1 templates, or editing the existing templates, is not supported. The only customization supported is to the permissions on the template.

    Version 2 templates were introduced in Windows Server 2003 and are a vast improvement over v1 templates. First and foremost, v2 templates can be modified by an Enterprise Admin. In addition, the Admin can duplicate an existing v1 or v2 template to create a new v2 template, and then customize the result. Finally, v2 templates expose a larger number of properties that can be configured, and also expose some controls to take advantage of some other new features introduced in Windows Server 2003. One of these features, for example, is key archival. Version 2 templates can be used by Windows Server 2003 and Windows Server 2008 Enterprise or Datacenter Editions. On Windows Server 2008 R2, v2 templates can be used by a CA installed on Standard, Enterprise, Datacenter, Foundation and Server Core Editions.

    Version 3 templates were introduced in Windows Server 2008. Version 3 templates have all the features of a version 2 template with two major additions. First, v3 templates support the use of Crypto Next Generation (CNG) providers, which means that the certificates support Suite B algorithms based on Elliptical Curve Cryptography (ECC). Second, v3 templates have a setting that instructs Windows to grant the Network Service account access to the private key created on the requesting computer. This is great for those certificates that will be used by applications or services that run as Network Service rather than Local System. Version 3 templates are supported by CAs installed on Windows Server 2008 Enterprise and Datacenter Editions. They are also supported by CAs installed on Windows Server 2008 R2 Standard, Enterprise, Datacenter, Foundation and Server Core Editions.

    For a complete table of Windows Server SKU and the features supported by it, check out this blog post by the Windows PKI development team.

    Deploying Certificate Templates

    For the purpose of example, I am going to use a fictional company called Fabrikam. The diligent IT staff at Fabrikam have done their research, performed some testing, consulted the auguries, and they’ve determined what types of certificates they need to issue to meet the specified business needs. The next step is to look at what templates are available that they can use out of the box and which ones they need to modify to suit their purposes.

    Here’s a quick overview of what Fabrikam determined:

    CA Issuance: Domain Controller Authentication, Web Server, and User certificates
    Key Archival: The private keys for User certificates should be archived
    Doman Controller Authentication template: No additional requirements
    Web Server template:

    • A version 2 template must be created from the default Web Server template.
    • The security group Fabrikam Web Servers should have Enroll permissions.
    • The Subject name must contain the DNS name of the web server, and should be provided automatically.

    User Certificate Template:

    • A version 2 template must be created from the default User template
    • Key Archival must be implemented for the template

    Certificate Templates Setup

    Fabrikam has decided that they need to deploy the following certificate templates: Domain Controller Authentication, Web Server, and User. In addition, the fact that Key Archival is to be enabled for the User template means that the CA should also be configured to issue certificates based on the Key Recovery Agent template (Actually, this is not a requirement if there is another Windows Enterprise CA in environment that is configured to issue Key Recovery Agent certificates, and is trusted to do so.)

    Let’s assume that the PKI hierarchy has been set up and is functional. The next step is to configure the certificate templates. Let’s check the configuration of the templates before deploying them.

    To manage the certificate templates, you use the Certificate Templates MMC snap-in. In the Certificate Services MMC snap-in, right-click on the Certificate Templates folder and select Manage from the context menu.


    In the view pane of the Certificate Templates snap-in you’ll see all the certificate templates available in Active Directory. If you locate the Domain Controller Authentication template and double-click on it, you’ll see the properties available for that template. Our fictional IT staff has already reviewed the settings and determined that no changes need to be made, so we’ll just click Cancel, here.


    Next, locate the Web Server template. The default Web Server template already meets the current requirements that arose from an analysis of business needs. However, to allow for future changes Fabrikam has decided that they need to duplicate this default template and create a v2 template.


    To duplicate the existing Web Server template and create Version 2 template:

    1. I right click on the Web Server template and select Duplicate Template from the context menu.
    Fabrikam still has a lot of Windows Server 2003 servers and Windows XP workstations (But they are steadily upgrading. No, really! They are!! Trust me! Sigh.) This means that we can’t use the latest and greatest v3 templates available on our Windows Server 2008 CA. We’ll have to specify that we’re creating a template for Windows 2003 Server, Enterprise Edition which will create a v2 certificate template.

    2. We’ll give a new name to the template: Fabrikam WebServer.

    3. Clients within Fabrikam will connect to the web servers via the server’s DNS name. This means that the requesting server’s fully qualified DNS name must be in the Subject of the certificate it receives. To meet this requirement, click on the Subject Name tab and select Build from this Active Directory information. For the Subject Name Format, select DNS Name. Finally, deselect all of the check boxes under Include this information in the alternate Subject name.

    Now that the new template is configured per the specified requirements, we need to set the security. The computer account for a particular web server will be the principal enrolling for the Fabrikam WebServer template, so we have to make sure that all the web server computer accounts have Enroll permission on the new template. Fabrikam, luckily, has a Security Group containing all of their web servers called, oddly enough, Fabrikam Web Servers. We can simply grant the necessary permissions to that group.


    1. In the template properties, elect the Security tab, and click Add…
    2. Enter the group name (Fabrikam Web Servers) and click the Check Names button.
    3. After the name of the security group is resolved, click OK.
    4. Grant the group Enroll permission.

      The permissions in the security tab should like this when these changes are complete.


      Once all the necessary changes have been made, click Ok to commit the new template and save it to Active Directory. The Fabrikam WebServer template is now ready to be added to the CA.

    User Certificate Template

    We’ll use essentially the same process to duplicate the default User template and modify the resulting v2 template to suit Fabrikam’s requirements.

    Just as with the default WebServer, we’ll duplicate the existing User template to create the custom v2 template. We need to do this because the default User template is a v1 template, so its properties cannot be modified. One of our requirements is to enable Key Archival which requires configuring a setting in the template, so in order to do this a v2 template is required.

    To create and configure our new User template:

    1. Select the User template, right click on it, and select Duplicate Template from the context menu.

    2. Select Windows 2003 Server, Enterprise Edition to create a v2 template.

    3. Change the Template Display name to Fabrikam User.

    4. Navigate to the Request Handling Tab, and select Archive subject’s encryption private key to enable key archival for this template.

    5. Next, set permissions on the new template. Domain Users will already have Enroll permission, but since this certificate will be deployed via user Autoenrollment, Domain Users will also require Autoenroll permission. The permissions, when set properly, should look like this:


      Once all the necessary changes have been made, click Ok to commit the new template and save it to Active Directory. The Fabrikam User template is now ready to be added to the CA.

    Key Recovery Agent Certificate Template

    Although this template was not mentioned as one of Fabrikam’s requirements, it is a requirement to issue at least one Key Recovery Agent certificate to support Key Archival. This step is only necessary if there is not another Windows Enterprise CA configured to issue certificates based on the Key Recovery Agent template.

    For this example, however, let’s assume that there is not and go ahead and configure the Key Recovery Agent template. The only setting that requires modification is the permissions. We’ll assign enroll permissions to the Fabrikam KRA security group so that members of that group can enroll for a Key Recovery Agent certificate.

    1. Open up the Key Recovery Agent certificate template by double-clicking on it and selecting the Security tab. I click Add…
    2. Enter the name Fabrikam KRA and click the Check Names button.
    3. After the name of the security group is resolved, click OK.
    4. Check the Enroll permission.

    Configuring the CA to issue certificates

    To configure the CA to issue the desired certificate templates, I right-click on the Certificate Templates folder, select New, then select Certificate Templates to Issue from the context menu.


    Then I select the certificate templates I wish to issue, by holding down the control key and selecting multiple templates, and then clicking OK.


    This CA can now issue certificates based on the selected certificated templates.



    That’s really all there is to it. While in this segment we only modified a few properties of our templates, in the vast majority of cases there should be no need for making extreme changes. The default templates should be sufficient for most implementations, and the changes we made were more to ease certificate deployment than actually create truly custom templates. Perhaps in a later blog post we’ll cover some of the more esoteric settings. However, this shouldn’t stop you from exploring on your own using the online help.

    In Part IV of this series we’ll cover implementing Web Enrollment and Key Archival.

  • FRS to DFSR Migration Tool Released

    Heya, Ned here again. I am out of my barrel and on the road again this week, coming to you live from Las Colinas Texas. As you may have noticed, I recently wrote a TechNet Whitepaper on how to migrate your old custom FRS data to DFSR. Hopefully that's been useful.

    In the meantime though, Mike Stephens and I also created a free migration tool. Because I am lazy very busy I am simply going to repost from our download page at Code Gallery. I hope you find this useful.


    FRS2DFSR is a utility that assists Windows admins in moving from the legacy File Replication Service (FRS) to the newer Distributed File System Replication (DFSR) service. Because FRS is no longer supported except for SYSVOL starting in Windows Server 2008 R2 and because Windows 2000 support ends on July 13 2010, this utility can help unblock admins from migrating to newer operating systems. The tool is written in C# .NET and can be run on x64 and x86 Windows Server 2003/2008/2008 R2 and Windows Vista/7 with DFSR RSAT installed. It requires domain admin rights and is command-line only. FRS2DFSR.EXE exports an existing File Replication Service replica set, deletes the replica set in Active Directory and creates DFS Replication group with the same servers, folders, connections, and settings. See the release notes for utility limitations. This tool is not used for SYSVOL migrations, see below for steps on using DFSRMIG.EXE in that scenario.

    Important support information:

    This tool is provided as-is, without warranty and is not supported by Microsoft Commericial Technical Support (aka CTS, PSS, CSS, EPS). No official support cases may be opened against this tool. It is intended only as a fully functional sample. Use the Discussions and Issue tracker tabs to report issues.

    For a supported set of steps for migrating from FRS to DFSR for custom sets, see:

    DFS Operations Guide: Migrating from FRS to DFS Replication

    To migrate SYSVOL, use the DFSRMIG.EXE tool included in Windows and reference:

    SYSVOL Replication Migration Guide: FRS to DFS Replication

    - Ned "and Mike Stephens" Pyle

  • Enabling CEP and CES for enrolling non-domain joined computers for certificates

    Hey all, Rob here again. I thought I would expand upon my last blog describing Certificate Enrollment Web Services by covering some of the different configurations that are possible.

    As a refresher, Certificate Enrollment Policy and Certificate Enrollment Services abstracts certificate Policy and certificate Enrollment from a specific Active Directory forest allowing clients in a different forest -- or no forest -- to request and obtain certificates.

    So here is a simple network diagram of what I am setting up in this blog post.


    A non-domain joined computer on the Internet needs to be able to enroll for certificates from a Microsoft Enterprise Certification Authority. We are configuring the CEP/CES web services to interact with the Internet-based computer and this computer has no network connectivity to domain controllers or certification authorities behind the firewall. You could also further isolate the domain controllers and certification authorities by placing the CEP/CES server(s) in a perimeter network with another firewall between CEP/CES and the internal network.

    Installing CEP and CES Role Services

    First you need to install the CEP and CES roles on the member server Win2K8R2-MEM1.

    1. Launch Server Manager.
    2. Click on Roles in the tree view.
    3. In the right hand pane click on “Add Roles”.
    4. Click the Next button.
    5. Check the box “Active Directory Certificate Services”.
    6. Click Next button twice.
    7. Uncheck “Certification Authority”.
    8. Check “Certificate Enrollment Web Service”.
    9. When you check the role, another dialog box will come up as shown below. Click the “Add Required Role Services” button.

      Figure 1 - Additional required role services 
    10. Check “Certificate Enrollment Policy Web Service”.

      Figure 2 - Adding CEP and CES Role Services 
    11. Click the Next button.
    12. Click the Browse button and select the CA to which this CES server will send certificate requests.

      Figure 3 - Select the certification authority 
    13. Click the Next button.
    14. Select “Username and password” as the Authentication Type. We are choosing this method because these are non-domain joined computers and do not have a domain-based account to pass to the web service.

      Figure 4 - Select Authentication Type 
    15. Click the Next button.
    16. Select “Use the built-in application pool identity”.

      NOTE: I know that the setting default is Specify service account (recommended). If you want to specify an account see the advanced configuration section at the end of the blog.

      Figure 5 - CES Application pool identity 
    17. Click the Next button twice.
    18. You will be given a screen listing IIS components. Do not make any changes; just click the Next button.
    19. Click the Install button.

    Configuring SSL certificate for the websites

    For those of you well versed in getting certificates issued through IIS and how to setup the websites to require SSL you can skip this section.

    1. Open Internet Information Services (IIS) Manager.
    2. Select the server node in the tree view.
    3. In the right hand pane double click on Server Certificates.

      Figure 6 - Server certificates 
    4. Click on Create Domain Certificate.

      Figure 7 - Create domain certificate 
    5. The Create Certificate dialog box will be presented. Fill out the fields; the “Common name” field MUST be the DNS name that the clients will use to connect to the CEP / CES services on the Internet. In figure 8 you will be using “” as the Internet DNS name. If you need to request a certificate that has multiple DNS names associated with it then you can create the certificate using the Custom Certificate requests within the Certificates snap-in.

      Figure 8 - Create Certificate wizard 
    6. Once you have filled in the fields, click the Next button.
    7. Select the online certification authority.NOTE: If an enterprise certification authority is not listed, then look to make sure that the Root CA certificate is in the Trusted Root Certification Authority machine store. Also, the Create Certificate Wizard will attempt to enroll for a certificate based on the default Web Server template. If that template is not available then enrollment will fail.
    8. Type in a friendly name for the certificate.
    9. Click the Finish button.
    10. Back in the IIS Manager Tree view, expand to select Default Web Site node.
    11. In the right hand pane select SSL Settings.
    12. Click on Bindings for the action.

      Figure 9 - SSL Bindings
    13. Select the HTTPS binding, and click the Edit button.
    14. Select the certificate created in step 9 for the SSL certificate field.
    15. Click the OK button.
    16. Click the Close button.
    17. Select each web service virtual directory one at a time and do the following.
      1. Double click on SSL Settings.
      2. Verify Require SSL is checked.
      3. Lastly, you will want to give a friendly name to the CEP service. This friendly name shows up on all client computers when they manually request certificates.
      4. Expand Default Web Site.
      5. Select the virtual directory ADPolicyProvider_CEP_UsernamePassword.
      6. Double click on Application Settings.
      7. Double click on the group name FriendlyName.
      8. In the value field, enter a name that uniquely identifies your organization. See figure 10 for an example.

        Figure 10 - Adding FriendlyName value

    Modification of msPKI-Enrollment-Servers attribute

    Now that you have the services installed and the IIS configuration completed, you need to focus on the URI sent to the client computer to which it will send the enrollment request.

    1. Run ADSIEdit.msc.
    2. Expand ADSIEdit to: cn=Enrollment Services,cn=Public Key Services,cn=Services,cn=Configuration, DC=yourforestrootdomain,dc=com.
    3. In the right hand pane select the CA for which you are configuring CEP/CES.
    4. Right click and select Properties.
    5. Double click on the attribute msPKI-Enrollment-Servers. See Figure 11.

      Figure 11 - CA Enrollment Services object properties
    6. You need to modify the URL address here to match the Internet based URL that the client computers will be using. You can use the Remove button, and modify the URI and then click the Add button to get the changed URI added back to the attribute.
    7. So in my setup here is what I changed:

      Original URI: 140

      Changed URI: 140
    8. Click the OK button.
    9. Exit ADSIEdit.msc.

    Configuring the client computers

    Alright, you are almost done with the setup now. The last thing you have to do is configure the clients to use the CEP/CES services.

    Before clients will enroll for certificates against a certification authority hierarchy, they must have the public Root CA certificate in the computer’s trusted root store. This part of the configuration is probably the most difficult since these are not domain computers and you will have to rely on the user to follow the steps. There are two ways to do this – through the snap-in, or with a command-line that you could give to the user as a batch script.

    Adding the Root certificate to the Trusted Root Store
    1. Logon as a local computer administrator account.
    2. You can add the Root CA certificate to the computers Trusted Root Certification Authorities store via the MMC:
      1. Open the Run command and type MMC.
        1. Select File then Add/Remove Snap-in
        2. Select Certificates, and click the Add > button.
        3. Select Computer Account, and click the Next button.
        4. Click the Finish button.
        5. Click OK
      2. Expand Certificates (Local Computer).
      3. Expand Trusted Root Certification Authorities.
      4. Right click on Certificates, and select All Tasks, and then select Import
        1. Certificate Import Wizard comes up.
        2. Click the Next button.
        3. Click the Browse… button and navigate to the CER file.
        4. Click the Next button.
        5. Leave the defaults, and click the Next button.
        6. Click the Finish button.
    3. Or you can run an elevated command prompt (Run as Administrator) and type the below command:

      CertUtil –AddStore Root <Root CA Public Certificate file name>

      For example:
      CertUtil –AddStore ROOT c:\fab-root-ca1.cer
    Configuring the CEP web address in the client

    Before I go into the steps it is important to understand that this configuration is based on the security context. You have a CEP configuration for the user, and you have another configuration for the computer. Depending on what certificates you plan on issuing (user or computer certificates) you may only require one of these to be configured.

    Configuring user certificate enrollment

    1. Run CertMgr.msc.
    2. Expand Certificates, then Current User.
    3. Expand Personal.
    4. Right click on Personal, and select All Tasks, then Advanced Operations, then Manage Enrollment Policies
    5. On the Manage Enrollment Policies dialog click the Add… button. See Figure 12

      Figure 12 - Enrollment Policies dialog box
    6. Type in the URI for the CEP service in the field. This will be in the format of:

      https://<Internet FQDN>/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP

      In my example this would be:

      NOTE: the only thing that will be unique to your environment is the Internet FQDN of the URI.
    7. In the Authentication type drop down select: Username/password
    8. Click the Validate button.
    9. Once the Validate button is pressed, you will be prompted to type in a domain user name and password. Supply these credentials.
    10. If everything goes correctly you should see that the validation test passed in the lower section of the dialog box see Figure 13.

      Figure 13 - Validation of Enrollment Policy Server configuration

      NOTE: You can see in Figure 13 that the only difference is the DNS portion of this URI. If you scroll down further in the validation output, you will see the friendly name you added under the website configuration being displayed also.
    11. Click the Add button.
    12. Uncheck Enable for automatic enrollment and renewal.

      NOTE: Failure to do so could cause users to be prompted for user name and password each time they logon to the computer. This occurs because Windows Autoenrollment runs immediately after the user has logged on. If the enrollment policy is configured for automatic enrollment and renewal, Windows Autoenrollment will attempt to contact the configured CEP server when it starts in order to determine if new certificates have been assigned. Since this will result in the users being prompted for credentials every time they log on your users may be annoyed.
    13. Click the OK button.NOTE: Follow the same procedures to configure the Enrollment Policy server for the computer personal store if you need to enroll for computer certificates.

    Testing the configuration

    With the users certificate store MMC still open do the following:

    1. Right click on Personal, select All Tasks, and select Request New Certificate…
    2. Certificate Enrollment wizard is displayed.
      1. Click Next.
      2. You will see that our new CEP configuration is being displayed.

        Figure 14 - Certificate Enrollment CEP server 
      3. Click the Next button.
      4. You will be prompted for a domain user name and password. Type in a valid domain user name and password combination. Keep in mind that the account used here will determine what certificate templates that are displayed to you next. You can check the box “Remember my credentials”, however if the account password changes you will have to change the credentials through the credentials vault.
      5. Select a certificate template to issue. I always like to use Basic EFS during testing.
      6. Click the Enroll button.
      7. You will be prompted for User name and Password. Type in a valid domain user name and password combination.
      8. You have now successfully enrolled for a certificate against the certification authority.

        NOTE: The same procedures can be used to test computer certificates. The templates that are available must be configured for “Supplied in the request” on the Subject Name tab for the template. Also, the user account used to authenticate to the CEP and CES service must be configured on the templates Security tab with Enroll permissions.

    How to deploy the Certificate Enrollment Policy URL to clients:

    Now you may be asking “how can I get this configuration deployed to users?” And you may be thinking “these steps are way too complicated for them to follow.” Well, you can export the configuration from the registry and have the users import the settings.

    Computer CEP configuration is located here:

    Use CEP configuration is located here:

    Advanced Configurations

    Alright, so you got your non-domain joined client computers requesting and getting certificates over the Internet. Great job! There are two different topics to be discussed for advanced configurations:

    1. You have multiple CES servers or multiple authentication methods (Kerberos, Username Password, or Certificate) in your environment.

    2. You want to use the CEP and CES services on the same computer, and use a domain or managed service account for the web application pool.

    Multiple CES servers or multiple authentication methods:

    If you have multiple CES servers that host different authentication methods or one CES server that hosts multiple authentication type web services, you need to be concerned with the priority of the authentication methods you specify. If you recall from the section “Modification of msPKI-Enrollment-Servers attribute”, those changes assume that this is the only CES server and authentication method you are implementing in your environment. If you need to support multiple authentication methods then the CES URI needs to be added in a different way to assign different priorities to each authentication method.

    The first thing to understand is that the lower the priority number the more preferred the CES URI is. So a priority of 100 is more preferred then that of 200. If you want to find out the different CES authentication types assigned to a certain CA and the priority you can type the following CertUtil command: certUtil –config “<CA Computer Name>\<CA Name>” -enrollmentServerURL

    for example:

    CertUtil –config “\Fabrikam Root CA1” –enrollmentServerURL


    Figure 15 - EnrollmentServerURL output

    As you can see from the output in Figure 15 there are two authentication methods assigned to the Fabrikam Root CA1. You have Kerberos at a Priority of 100, and UsernamePassword at a priority of 200. You can also see that the URL addresses are different. External clients would not resolve the DNS name, and internal clients would prefer Kerberos authentication over the UserNamePassword method because the priority for Kerberos is lower. Failure to set the priorities correctly could cause domain joined client computers to prefer UsernamePassword authentication method over Kerberos, and you will get a lot of calls to the help desk asking why the computer is constantly asking for credentials.

    Domain account running the application pool

    Alright, if you are reading this section, you must be really serious about security, and using domain based service accounts to run application pools. As stated earlier, during the installation phase if the CEP and CES web services are running on the same server then the application pool accounts for both of these services must be using the same account.

    1. Open Internet Information Services (IIS) Manager snapin.
    2. Highlight the Application Pools tree node.
    3. On the right hand pane, you will see some application pool accounts. You are interested in WSEnrollmentPolicyServer and WSEnrollmentServer.
    4. Do the following for each application pool.
      1. Right click on the application pool, and select Advanced Settings.
      2. Select Identity under Process Model node, and click on the button. See figure 16.

        Figure 16 - Application Pool Identity
      3. Radio button select Custom account:
      4. Click on the Set… button.
      5. Type in the Application Pool account in the form of domain\user name.
      6. Type in the password twice.
      7. Click the OK button three times.
    5. Open up computer management (Compmgmt.msc).
    6. Add the group to the local computer IIS_IUSRS group.
    7. Open an elevated command prompt, and type IISRESET

    So in a nutshell, that’s pretty much how you can configure CEP/CES to allow users on non-domain joined clients to enroll for certificates against an internal Enterprise CA. Stay tuned in the future when we’ll cover some other scenarios featuring CEP/CES in Windows Server 2008 R2.

    I hope that you have enjoyed learning how to use CEP and CES to extend certificate issuance to your users and customers.

    Rob “Unjoined” Greene

  • AD FS 2.0 and AD FS 1.x Interoperability

    Hi, it’s Adam Conkle again. I am excited about our recent release of AD FS 2.0 on May 5. I wanted to post a blog about AD FS 2.0 and AD FS 1.x interoperability as soon as possible since I think it will be a common scenario for our customers.

    AD FS 2.0 and AD FS 1.x interoperability was a priority for this release, and full functionality of AD FS 1.x security token servers (STS) and the Claims-aware Web Agent is supported in AD FS 2.0.

    Note: AD FS 2.0 does not support the AD FS 1.x Windows Token Web Agent

    In order to federate between the two versions of AD FS there are some requirements that we need to manually address.

    AD FS 1.x includes three claim types:

    1. Identity – claims to uniquely identify the user
    2. Group – claims to show security group membership
    3. Custom – any other attribute you need to extract and send (i.e. – Given name, surname, office, phone, etc.)

    Below, I will describe methods to send claims from AD FS 2.0 which satisfy the AD FS 1.x claim requirements.

    We will be extracting several claims from an Attribute Store, and, before we begin, we need to understand where the extractions should take place. You can extract from the Attribute Store either on the Claims Provider (CP) Trust or on the Relying Party (RP) Trust. Both will work; the difference is this:

    Claims Pipeline

    When you extract using the CP Trust rules, the claims are injected into the policy processing pipeline early in the process. Then, on the RP Trust, we execute the Issuance Authorization Rules and can make RP authorization decisions based on claims that we already have in the pipeline.

    When you extract using the RP Trust rules, the claims are injected into the pipeline later in the process, and any Issuance Authorization Rules you have configured for the RP Trust will not apply to claims which are issued here since the authorization rules have already executed.

    Name Identifier (Name ID) claim in the SAML subject

    In AD FS 1.x, we require at least one Identity Claim (UPN, Email, or Common Name). The Identity Claim is sent as the subject of the SAML 1.1 assertion as a claim called Name Identifier (Name ID). Name Identifier also has a format property which equals the URI of the primary Identity Claim sent. For example, if userPrincipalName (UPN) is sent as the primary Identity Claim, then the Name Identifier claim is specified with the format of UPN with the claim value equal to the UPN of the authenticating user.

    Here is a snippet of AD FS 1.x SAML assertion showing the Name Identifier claim:

    AD FS 1.x SAML Assertion

    When we utilize AD FS 2.0 there is no concept of Identity Claims, and we also do not automatically send a Name ID claim. This needs to be manually configured so that AD FS 2.0 will send the Name ID claim to the AD FS 1.x server in a format that the AD FS 1.x server is expecting. Simply issuing a UPN claim from AD FS 2.0 to AD FS 1.x does not achieve the requirement, and a Claim Rule is needed.

    Let’s go to the AD FS 2.0 STS, and let’s also assume that AD FS 2.0 is the identity provider (IdP) for this federation scenario. We will configure an Acceptance Transform Rule for the Active Directory CP Trust which extracts userPrincipalName from Active Directory as the UPN claim type (URI). Creating this rule on the CP Trust will place the UPN claim into the pipeline prior to any RP Trust rules firing.

    When you create this rule, use the Send LDAP Attributes as Claims template in the rule editor.

    Figure 1 – Selecting a claim rule template to extract from AD
    Figure 1 – Selecting a claim rule template to extract from AD

    Figure 2 and Figure 3 show a rule named Extract UPN from AD which has been added to the claim rules for the Active Directory CP Trust.

    Figure 2 – Configuring the Claim Rule to extract UPN from AD
    Figure 2 – Configuring the Claim Rule to extract UPN from AD

    Figure 3 – New rule has been created to extract UPN from AD
    Figure 3 – New rule has been created to extract UPN from AD

    Now that we have a UPN claim in the pipeline, the next step is to transform this claim into the format that AD FS 1.x requires: Name ID. We perform the transformation with an Issuance Transform Rule on the AD FS 1.x RP Trust.

    To create a transformation rule, use the Transform an Incoming Claim template in the rule editor

    Figure 4 – Selecting a claim rule template to transform a claim
    Figure 4 – Selecting a claim rule template to transform a claim

    Configure the rule to transform from the Incoming claim type: UPN to the Outgoing claim type: Name ID. Once you select Name ID as the outgoing claim type, the Outgoing name ID format drop-down box becomes available so that we can select the UPN format for Name ID. We want to pass the value of the user’s UPN to the new claim, so select Pass through all claim values.

    Figure 5 – Configuring the transformation rule for Name ID
    Figure 5 – Configuring the transformation rule for Name ID

    When a user authenticates to the AD FS 2.0 STS, the UPN will be extracted from AD during execution of the AD CP Trust rules and injected into the pipeline. Next, the processing rules are executed for the AD FS 1.x RP Trust, and UPN will be transformed to Name ID with the UPN format. The value of the user’s UPN is maintained for the outgoing claim to the RP (AD FS 1.x).

    AD FS 1.x Identity Claims

    Now that we have the Name ID claim handled, we still need to send the appropriate Identity Claim(s) to AD FS 1.x. For that purpose, AD FS 2.0 includes Claim Descriptions for AD FS 1.x UPN and AD FS 1.x E-Mail Address.

    Figure 6 – AD FS 1.x Claim Descriptions shown in the Claim Descriptions node of AD FS 2.0
    Figure 6 – AD FS 1.x Claim Descriptions shown in the Claim Descriptions node of AD FS 2.0

    We simply need to extract them from our Attribute Store (AD, in my case), and send them to the AD FS 1.x RP.

    Figure 7 shows how to configure the claim rule to extract UPN and E-Mail as AD FS 1.x UPN and AD FS 1.x E-Mail Address. I have chosen to create this rule on the CP Trust.

    Figure 7 – Configuring a rule to extract AD FS 1.x claims from AD
    Figure 7 – Configuring a rule to extract AD FS 1.x claims from AD

    In Figure 8, I have selected the Pass Through or Filter an Incoming Claim template so I can pass the AD FS 1.x claim types to the AD FS 1.x RP. This rule is created on the RP Trust so that the claims accepted from the AD CP Trust can be passed to the RP.

    Figure 8 – Selecting the claim rule template to pass a claim through to the RP
    Figure 8 – Selecting the claim rule template to pass a claim through to the RP

    Finally, in Figure 9, I have configured the rule to Pass through all claim values for the Incoming claim type: AD FS 1.x UPN. You will need to create another set of extraction and pass through rules to handle the AD FS 1.x E-Mail Address or Common Name claim types if you wish to send them.

    Figure 9 - Configuring a claim rule to pass through the value of the AD FS 1.x UPN claim type
    Figure 9 - Configuring a claim rule to pass through the value of the AD FS 1.x UPN claim type

    AD FS 1.x Group Claims

    Next, you may need to send Group claims to AD FS 1.x. AD FS 2.0 comes with a built-in Claim Description named Group which has the URI that AD FS 1.x expects for Group Claims. This can be seen on the Claim Descriptions node in the AD FS 2.0 MMC console.

    Figure 10 – Group Claim Description on the Claim Descriptions node of AD FS 2.0
    Figure 10 – Group Claim Description on the Claim Descriptions node of AD FS 2.0

    AD FS 2.0 also has a Claim Rule template named Send Group Membership as a Claim which allows you to select a security group, and send a claim based on membership of that group. I have chosen to create this rule on the RP Trust.

    Figure 11 – Selecting the claim rule template to send a claim based on group membership
    Figure 11 – Selecting the claim rule template to send a claim based on group membership

    Now, all we need is the AD FS 1.x Incoming Group Claim Mapping name the AD FS 1.x administrator is expecting on the resource federation server. For our example, let’s call it SharePointUsersMapping. Our rule looks like this:

    Figure 12 – Configuring a claim rule to send a Group claim based on group membership
    Figure 12 – Configuring a claim rule to send a Group claim based on group membership

    Since I created my rule on the RP Trust this time, there is no need to create a pass-through rule in order for the claim to be sent to the RP.

    AD FS 1.x Custom Claims

    We’re on the home stretch now! Finally, we may need to send additional claims to AD FS 1.x which are neither Identity Claims nor Group Claims; they are AD FS 1.x Custom Claims. As an example, I have extended my AD schema to include a user attribute named costCenter. I want to send the users’ cost center as a claim when they authenticate to a resource hosted by my AD FS 1.x partner.

    I need to create a new Claim Description to handle this on the AD FS 2.0 STS, but I need to do a bit of background work before I create the new Claim Description. If I take a look at a SAML assertion from AD FS 1.x which contains a Custom Claim, it looks like this:


    The way the SAML assertion is constructed here is as follows:

    1. The full URI of the claim type is passed in

    2. Everything after the last “/” in the URI is stripped off of the URI and is used as the AttributeName property

    3. Everything before the last “/” in the URI is used as the AttributeNamespace property

    Consider the following full URI:

    Now, run that through the steps above:

    1. is passed in

    2. FirstNameMapping is stripped off of the URI and is used as the AttributeName property

    3. is used as the AttributeNamespace property

    I’m ready to create my Claim Description for costCenter, which is accomplished on the Claim Descriptions node of the AD FS 2.0 MMC console:

    Figure 13 – Configuring a new Claim Description for Cost Center
    Figure 13 – Configuring a new Claim Description for Cost Center

    The AD FS 1.x administrator will need to create an Incoming Custom Claim Mapping named costCenter so that the incoming claim is mapped.

    The last thing we need to do on the AD FS 2.0 federation server is create a rule using the Send LDAP Attributes as Claims template to extract the costCenter attribute from AD and send it to AD FS 1.x as our new claim type. I have chosen to do this on the RP Trust which, again, negates the need for an additional pass-through rule to the RP.

    Figure 14 – Configuring a rule template to extract costCenter from AD and send as Cost Center
    Figure 14 – Configuring a rule template to extract costCenter from AD and send as Cost Center

    We’re done! This blog post covers AD FS 2.0 as the Claims Provider (Identity Provider) and AD FS 1.x as the Relying Party (Resource Provider) because it is AD FS 1.x which has the special claims requirements. You can certainly configure AD FS 1.x as the Claims Provider and AD FS 2.0 as the Relying Party, but that deployment should be a bit more straight-forward since AD FS 2.0 simply needs to be configured to accept the incoming claims from AD FS 1.x. Thanks for reading, and please let me know if there are any questions or points needing clarification.


    Adam “So He Claims” Conkle

  • File Services Management Pack has been released

    Hello there file server admins and datacenter monitoring gurus, Ned here again. After much skull sweat and gnashing of tooth, the File Services management pack for System Center Operations Manager 2007 has been released.

    This new MP covers:

    • DFS Namespaces
    • DFS Replication
    • File Server (the Server service for SMB file sharing)
    • File Server Resource Manager (the service used for File Server Resource Manager and File Classification Infrastructure)
    • Services for Network File System

    It officially supports monitoring Windows Server 2008 R2 (although actually more, see the filecab link below), and is the younger brother of the 2003/2008 DFSR and DFSN management packs for SCOM 2007.

    PS: Jonathan’s description below makes me think I’m in the last scene of Raiders of the Lost Ark…

    Jonathan: We have top men working on it now.
    Mike: Who?
    Jonathan: Top... men.

    Ned “Indiana” Pyle

  • Blog Platform Migration Complete

    Hello, Internetz. Jonathan here again. Ned didn’t tell you the whole story. Not only did I have to wait for the truth serum to wear off; I also had to chew my way out the straps. Nevertheless, I’ve emerged victorious and have again successfully stormed the AskDS gates and vanquished Ned. Don’t fear for the little Neebler, though. Yes, he’s been jammed into a steel drum along the side of one of our nation’s great highways, but he’s being fed well through the bung hole, mostly, and he has a nice view of the Interstate. I hope he enjoys playing Punch Buggy with himself.

    Of course, knowing Ned, I give him about a week before he escapes, so let’s make the most of that time, shall we?

    AskDS has been successfully migrated to our new blog platform. Unfortunately, the backup that was restored after the migration was older than we thought so we appear to have lost some of our more recent posts. I’m working now to re-post those articles now. Please let us know if I missed one.

    --Jonathan “Pretender, Redux” Stephens

  • New Directory Services Content 5/9-5/15



    Some smart cards performing requests cause performance issues


    Errors when you have a large "Folder Redirection" policy settings file in Windows Vista, in Windows 7, in Windows Server 2008, or in Windows Server 2008 R2


    Some providers may receive an incorrect password value from the OLEDB32 component if the password in the connection string is blank in Windows 7 or in Windows Server 2008 R2


    Wiki Page: AD FS 2.0: Migrate Your AD FS Configuration Database to SQL Server

    Wiki Page: Hyper-V: How to Configure Server Core using SCONFIG

    Wiki Page: Hyper-V: Performance Guide

    Wiki Page: Hyper-V: How to Find the Host of a VM


    Migrated Users Get Prompted To Change Password at First Logon Even After Migrating Their Password with the PES

    The Next Generation of AD Performance Analysis

    Validating your AD Schema Prior to Upgrade (a Followup)

    Friday Mail Sack – It’s About To Get Real Edition

    Hey, Scripting Guy! Weekend Scripter: Configuring W32Time Service Logging

    Considerations when upgrading your Active Directory to Windows Server 2008 and 2008 R2

    Group Policy Setting of the Week 25 – Remove the Action Center icon

    BPOS Deployments – notes from the field

    What's next for Windows Server and beyond?

    Announcing the Availability of Active Directory Federation Services 2.0 and Forefront Protection for SharePoint 2010

    AD Clients Not Authenticating to its Local Site

    Top 10 IAM Challenges for Heterogeneous Enterprises

    Eugenio Pace on Identity Federation, WIF, and ADFS 2.0

    Free Office Mobile 2010 for Windows Phones

    Best Practices for Creating a Secure Guest Account on Windows 7

    Choosing an Appropriate User State Virtualization Solution

    PowerShell Resource Page at Windows IT Pro

    Folder Redirection isn’t working correctly — the redirection targets the wrong server!

    Select WMI

    The very best Sysinternals tools for Windows server security

    Hyper-V Best Practice Analyzer - What does it check

    New Networking-related KB articles for the week of May 2 – May 8

    New topic and script about testing for Active Directory schema extension conflicts

    Adding claim mapping to existing provider in SPS 2010

    Using Kerberos security with Server for NFS

    Two Minute Drill: The Schtasks command

    Windows Intune - Under the Hood

    IPv6 transition technologies on Windows Server 2008 R2 Server Core

    PowerShell and AD DS Best Practice Analyzer