Configuring User Certificate Authentication for IIS

IIS does not use .htaccess files, as Apache does, for access control. Instead, it relies on authenticating users to the operating system, and then authorizing them to access the service. At Fermilab we typically use KCA certificates for user authentication. DOEGrids can be used too. The authentication step is done when obtaining the certificate. This conflicts with the basic operation of IIS, so the web server admin must create an account on the server to which to map certificate users for protected access. In this example, we will map all KCA users to a non-privileged Windows account. When creating the account, be sure to revoke ALL access rights within the operating system.

This example was created using IIS 5.0. Windows 2003 IIS/6.0 should be similar. Also, the following example assumes you have a working SSL IIS installation. If you have not yet configured your site to use SSL, please get a DOEGrids server certificate and install SSL. To accept KCA user certificates for authentication, you will need to also import the KCA server certificates.

1. Create a new local account on the webserver that is not a member of any groups. Also set appropriate OS permissions to deny access to the general operating system.
2. Add this account to your local group policy that allows for logon over the network, to permit IIS to work properly. This is similar to what you do now for your IIS account (Domain members only - alternately you can use a Shared Service account for this if remote file access is required)
3. From the Computer Management window, right click on your web site OR the directory you wish to protect with Certificate access and select Properties.
   
   
4. Click on the Edit tab in the Secure Communications section.
   
   
5. Check the ‘Require secure channel’, ‘Require client certificates’ and ‘Enable client certificate mapping’ checkboxes.
   
6. Click the Edit button, select the ‘Many-to-1’ tab and select the ‘Enable Wildcard Client Certificate Matching’.
7. Click the ‘Add...’ button.
   
8. Click the ‘Enable the wildcard rule’ checkbox and give a name for this rule (such as ‘Permit KCA certificates’).
   
9. Click the ‘Next’ button.
10.   In the ‘Rules’ screen, click on the ‘New’ button to create a new certificate mapping rule.
11. Uncheck the ‘Match Capitalization’ checkbox. Change the ‘Certificate Field’ to ‘Issuer’. Change the ‘Sub Field’ to ‘CN’.
    1. If using KCA certificates: Change the ‘Criteria’ field to ‘Kerberized CA’
    2. If using DOEGrids certificates: Change the ‘Criteria’ field to ‘DOEGrids CA 1’
    3. If you wish to further restrict the access to only select users, you can create another rule similar to this one and specify only the user DN.
12. Click the ‘OK’ button 
    
13.   Select the ‘Accept this certificate for Logon Authentication’. Enter the account name and password you created in step 1 and click the ‘Finish’ button
    
14. You now need to create a "deny" rule to prevent other certificates or lack of certificates from viewing the protected web pages. Back at the ‘Account Mappings’ screen, select the ‘Add...’ button.
    
15. Ensure the ‘Enable this wildcard rule’ is checked and give a name to this new rule (such as ‘Deny any other access’) and click the ‘Next’ button
    
16. At the ‘Rules’ screen, click the ‘New’ button.
    
17. Uncheck the ‘Match Capitalization’ checkbox and change the ‘Criteria’ field to ‘*’ and click the ‘OK’ button
    
18. Click the ‘Next’ button and select the ‘Refuse Access’ radio button then click the ‘Finish’ button
    
19. You should now have (at least) 2 rules defined. Make sure they're in the right order, where the "deny" rule is last.
    
20. Click the ‘Apply’ and the ‘OK’ buttons

You can now test with your browser. If you have a valid KCA certificate installed (or DOEGrids certificate if you configured your server to accept them), you should see the web pages. If you do not have a valid certificate or it has expired, you should receive an error.