کد:
http://www.isaserver.org/tutorials/Publishing_Web_Sites_using_Client_Certificate_Authentication.html

Web Publishing Rules give you a lot of options on what authentication methods you can use to control access to a Web server on the internal network. A Web Publishing Rule can also be configured to require a secure SSL tunnel between external network clients and the Incoming Web Requests listener. You end up with a very secure connection to the publishing Web server on the internal network when you combine strong authentication and a secure SSL link.
One question that comes up a lot here at ISAServer.org is "where should authentication take place?" Should you require users to authenticate with the Incoming Web Requests listener? Should you require users to authenticate with the Web server on the internal network? Maybe you should authenticate with both the Incoming Web Requests listener and the Web site on the internal network.
There’s no hard and fast answer to this question. One way to approach this problem is to assess which machine is currently taking the most load. If the ISA Server see less processor utilization than the Web server, then you might consider authenticating at the ISA Server instead of the Web server. If the Web server sees less processor utilization over time than the ISA Server, then you might consider having users authenticate with the internal network Web server.
Some ISA Server administrators want users to authenticate before they reach the internal network. In this case, the users will need to authenticate with the Incoming Web Requests listener. Once the users authenticate with the Incoming Web Requests listener, they can then access the Web server on the internal network. This is a secure configuration because if the user can’t successfully authenticate with the Incoming Web Requests listener, they never see the internal network.
------------------
ISA Server Alert
 Most of the principles discussed in this article are covered in high detail in the ISA Server and Beyond book. We were running out of time to get the book to the printer and I had to leave out information specific to how to configure the Incoming Web Requests listener to use client certificates to authenticate external network users. I’ll go over those areas not covered in the ISA Server and Beyond book in greater detail in this article. For areas covered in detail in the book, I’ll give an overview of the configuration and refer you to the book for details.
------------------
 You might run into a problem with this type of configuration. What if you need to require authentication at the Web server? For example, you need to prevent unauthenticated users from having any type of access to internal network resources, so you force users to authenticate with Incoming Web Requests listener. However, you also need internal network users to authenticate with the internal network Web server. You configure the Web server on the internal network to require authentication so that internal network users are force to authenticate to access resources on the internal network server.
This is where we run into problems. If you’ve tried to allow users to authenticate with the Incoming Web Requests listener and the internal network Web server, you’ve realized it doesn’t work. There is only one way to get authentication to work on both the Incoming Web Requests listener and the Web server on the internal network. The only scenario that allows authentication at both the ISA Server and the internal network Web server is when the Incoming Web Requests listener uses client certificate authentication and the internal network Web server uses Digest, Integrated or Basic authentication.
Client certificate authentication allows users to present client certificates to authenticate with the Incoming Web Requests listener. The user doesn’t need to input a user name or password. When the user tries to connect to the Incoming Web Requests listener, a dialog box will appear asking the user to select a user certificate for authentication. The user selects a valid certificate from the list and sends it to the ISA Server’s Incoming Web Requests listener. If the certificate is valid, the user will be able to connect to the Incoming Web Requests listener and subsequently authenticate with the internal network Web server using an alternate method of authentication (integrated, basic, digest).
------------------
ISA Server DEFCON1
The subject of certificates and certificate servers often drives ISA Server admins away. I’m not sure why this is , but I suspect many admins stray away from certificate services because the documentation for certificate services and PKI in general is so dreary. I don’t think I’ve ever read a treatise on Microsoft certificate services and PKI that wasn’t filled with tautologies and absurd assumptions regarding the reader’s level of sophistication regarding the subject matter.
------------------
 I don’t promise to make you a PKI or certificate services expert, but I will show you how to set things up to support client certificate authentication at the Incoming Web Requests listener. You'll find these instructions very straightforward if you already have some certificate server experience. If you don't have a lot of certificate server experience, you may want to use this article in conjunction with the information provided in the book. Once you implement a client certificate authentication setup you’ll be more motivated to learn more about certificate services and PKI in general.
You need to carry out the following procedures to enable the Incoming Web Requests listener to use client certificate authentication:
Install Certificate Server
Assign Web Site Certificate
Export Web Site Certificate
Import Web Site Certificate
Configure the Incoming Web Requests Listener
Create the Web Publishing Rule
Obtain a User Certificate for the Client
Make the Connection to the Web Site
I highly recommend you first test your setup on a lab network or a collection of VMware virtual machines. You should be comfortable with setting up the certificate server, assigning the certificates, and configuring the many to one user certificate mapping before you perform the same steps on your production network. Once you prove to yourself that it actually works on your lab network, you’ll be able to implement the same design on your production computers with confidence.
=======================================
Install Certificate Server
=======================================
 Installing a certificate server is not an absolute requirement. You can use third party certificates if you like. But if you want to allow users who are all under your administrative control to access resources on your internal network, you should consider setting up your own certificate server. This is the best option when you don’t need to support anonymous external network users.
You can install either an enterprise certificate server or a stand-alone certificate server. The enterprise certificate server depends on Active Directory. You should consider installing a enterprise root certificate server and subordinate enterprise certificate servers if you’re running an Active Directory network. If you have only a single enterprise certificate server, that will be your enterprise root server. On the other hand, you may not be running an Active Directory domain or you do not want to integrate certificates services with Active Directory. In that case you can install a stand-alone certificate server.
You’ll need to install an enterprise root certificate server if you want to replicate the configuration I’ll be going over in this article, . The reason for this is you’ll need to map a user certificate in the Active Directory to make this work, and the easiest way to get it to work is to use an Active Directory integrated certificate server. The ISA Server and the enterprise root certificate server must belong to the same domain.
To install the enterprise certificate server, open the Control Panel and run the Add/Remove Programs applet and click the Add/Remove Windows Components button. You’ll need to select the certificate server option and then go through the Wizard.
Figure 1: Installing Certificate Services
Check out the chapter 5 in the ISA Server and Beyond book for a full description on how to install the certificate server.
 =======================================
Assign Web Site Certificate
=======================================
 Now your Web site can request a certificate. Remember that the Incoming Web Requests listener needs to impersonate your internal network Web server when you securely publish it to the Internet. You need to assign the Web site’s certificate to the external interface of the ISA Server. This will allow you to create a secure SSL link with the Incoming Web Requests listener. And since the Web site also has a certificate, you can create a second SSL connection to the internal network Web server. These two SSL channels allow end to end encryption for communications between the Web client and then Web server on the internal network.
Open the Internet Information Services console and then open the Properties dialog box for your Web site. In the Properties dialog box, click on the Security tab. On the Security tab you’ll see the Server Certificate button. Notice that this button is available but the View Certificate and Edit buttons are not. You won’t have access to these other buttons until after you obtain a certificate for the Web site. Click the Server Certificate button to start the Web site certificate Wizard.
Figure 2: Obtaining a Web site certificate
The Wizard will walk you through the steps of obtaining a certificate for the Web site. Make sure you enter the proper information, especially for the Common Name of the Web site. If you don’t enter the exact FQDN the external network user uses to access the Web server, the user will see a dialog box indicating a site name mismatch for the certificate.
Check out chapter 5 of the ISA Server and Beyond book for details on running the Web site certificate Wizard.
 =======================================
Export Web Site Certificate
=======================================
 The next thing you need to do is export the Web site certificate. There are a number of ways you can do this, but the easiest way is to export it as soon as you get it. Once you obtain the certificate, the View Certificate button will be available on the Security tab of the Web site’s Properties dialog box. Click the View Certificate button and click on the Details tab. You can click the Copy to File button on the Details tab of the Certificate Propertiesdialog box and export the certificate. When you export the certificate make sure you export the private key as well.
Figure 3: Exporting the Web site certificate
Check out chapter 5 of the ISA Server and Beyond book for details on running the Certificate Export Wizard.
 =======================================
Import Web Site Certificate
=======================================
 The Web site certificate is in the form of a .pfx file. Copy this file to a floppy disk and take it to the ISA Server computer. You could also copy it over the network, but that would require writable shares on the ISA Server and you probably want to avoid this for security reasons. If you’re feeling adventurous, you might consider creating a temporary writable share on the ISA Server so that you can copy the certificate. Then you can remove the share after you copy the file.
You’re ready to import the Web site certificate once you get the certificate copied to the ISA Server. The Web site’s certificate needs to be imported into the machine’s certificate store. You do not need to import the certificate into the logged on user’s certificate store and you do not need to import the Web site’s certificate into the Web Proxy service’s certificate store.
It’s a common misconception that you need to import the certificate into the Web Proxy service’s certificate store. The only time you need to import a certificate into the Web Proxy service’s certificate store is when you want to allow the Web Proxy service to use client certificate authentication to authenticate against a Web site on your internal network. In that case, you need to obtain a machine certificate for the ISA Server and then copy the machine certificate into the Web Proxy service’s certificate store.
Figure 4: Importing the Web site certificate
Check out chapter 5 of the ISA Server and Beyond book for details on importing the Web Server certificate into the ISA Server’s machine certificate store.
 =======================================
Configure the Incoming Web Requests Listener
=======================================
 Now that the Web site certificate is in the ISA Server’s machine store, you can attach the certificate to the Incoming Web Requests listener. You need to create an Incoming Web Requests listener before you can attach the certificate to the Incoming Web Requests listener. It’s a good idea to create your listeners separately if you are using certificate authentication. Since you can assign only one certificate per listener, you give yourself the most options when you create separate listeners. If you used the same configuration for all addresses bound to the external interface, then a single certificate would have to suffice for all incoming requests. That would prevent you from being able to publish multiple Web servers using different certificates.
Figure 5: Attaching the Web site certificate to the Incoming Web Requests listener
Check out chapter 5 of the ISA Server and Beyond book for details on creating the Incoming Web Requests listener and binding a certificate to the listener.
 You need to remove all other authentication methods if you want to force external network uses to use client certificate authentication. Notice in figure 6 that checkmarks have been removed from the Basic with this domain, Digest with this domain, and Integrated checkboxes. The only authentication method available is Client certificate (secure channel only). When you require client certificate authentication, you also require a secure SSL channel between the client and server. Its important that you only allow client certificate authentication. Otherwise, the client will try to negotiate other authentication methods for clients that do not have certificates.
Figure 6: Forcing client certificate authentication
Make sure the Enable SSL listeners checkbox is selected on the Incoming Web Requests dialog box. I do not recommend you use the Ask unauthenticated users for identification option. This option forces all Incoming Web Requests listeners to authenticate, even those that you may want to allow anonymous access! The Ask unauthenticated users for identification option is a global one; you cannot force authentication for a single listener. The way to enforce authentication is by configuring the Web Publishing Rule to do so.
Figure 7: Enabling SSL Listeners


=======================================
Create the Web Publishing Rule
=======================================
 Now you’re ready to create the Web Publishing Rule. Remember that you need to create a Destination Set for your site before you create the Web Publishing Rule. Its vital that you use the same FQDN in the Destination Set that your users use to access the site. This is also the same FQDN that you used as the Common Name when you requested the certificate. You may also want to create a HOSTS file entry for your internal network Web server that includes the server’s private IP address. That will keep your logs more orderly and easier to read. A better solution than a HOSTS file is a split DNS infrastructure. But if you don't have a split DNS setup, a HOSTS file will work fine.
Figure 8: Creating the Web Publishing Rule
Check out chapter 5 of the ISA Server and Beyond book for details on creating the Web Publishing Rule.
 You have to change the bridging characteristics of the Web Publishing Rule. Double click on the Rule and click on the Bridging tab. In the Redirect SSL requests as frame, select the SSL requests option. This will allow you to maintain a secure channel end to end by having the ISA Server create a second SSL connection between its internal interface and the internal network Web server. Make sure you configure the Web server to require SSL for all incoming connections.
Put a checkmark in the Require secure channel (SSL) for published site checkbox. This option forces users to use SSL to connect to the site. If your clients support 128-bit encryption, put a checkmark in the Require 128-bit encryption checkbox. You do not need to put a checkmark in the Use a certificate to authenticate to the SSL Web server checkbox. This is only required if you wish to enforce certificate authentication at the Web site.
Figure 9: Requiring a secure channel and redirecting as SSL
Check out chapter 5 of the ISA Server and Beyond book for details on using client certificates on the ISA Server and configuring Web sites to require client certificate authentication.
 =======================================
Obtain a User Certificate for the Client and Machine Certificate for the ISA Server
=======================================
 The client needs a user certificate before it can use certificate authentication! You can use either the Web based certificate enrollment system or the Certificates mmc to obtain a user certificate. Web based certificate enrollment can be used from anywhere. For example, you can publish the Web enrollment site and allow external network clients to obtain a client certificate from the Internet. The Certificates mmc requires the user be on the internal network.
The easiest way to get the certificate is with the Certificates mmc. Open an mmc and then open the Certificates snap-in for the logged on user. You’ll need to log on as the user that requires the certificate. As you can imagine, it can be a large administrative burden to log on as each user and request a certificate for each of them. Another option is to provide users instructions on how to obtain their own certificates. The best option is to use Active Directory to automatically assign user and machine certificates to domain members via autoenrollment.
Figure 10: Obtaining a User Certificate using the Certificates mmc snap-in
You should obtain a machine certificate for the ISA Server itself. The ISA Server does not use its own machine certificate to impersonate a Web server on the internal network. The ISA Server does not use its own machine certificate to publish any Web sites at all! A machine certificate has different users than a Web site certificate. However, you can use the machine certificate for client authentication. You can copy the machine certificate into the Web Proxy service’s certificate store. You can use this certificate to allow the Web Proxy service to use client certificate authentication with an internal Web site once the certificate is copied to the Web Proxy store.
Figure 11: Assigning a machine certificate to the Web Proxy service
Check out chapter 5 of the ISA Server and Beyond book for details on using the Certificates mmc, the Web-based enrollment system, and assigning a client certificate to the Web Proxy service.
 =======================================
Configuring Many-to-one mapping for a User Certificate
=======================================
 You need to map a user account to a certificate in a "many-to-one" setup. The Many-to-one certificate mapping allows you to map all user certificates issued by your certificate authority to a single user certificate. Then you configure the Web Publishing Rule to allow the user permission to use that Web Publishing Rule. Note that you allow permission to the user account that you're mapping the certificates to. You do this the same way you normally assignment permissions to a Web Publishing Rule by using the Applies To tab on the Rule's Properties dialog box. The many to one certificate mapping approach is much easier to administer than a one to one certificate mapping configuration and it gives a good level of security for sites you wish to allow groups of users to access.
In this example I use the administrator account, but you should create an account of your own in the Active Directory and then put that account into a group. Assign this group permission to access the Web Publishing Rule used to publish the internal network Web site.

  1. Export the user certificate you want to use for the many to one mapping. Copy that user certificate (.cer file) to a domain controller. You will need this user certificate to perform the mapping.
  2. Click Start, point to Programs and then point to Administrative Tools. Click Active Directory Users and Computers.
  3. Expand the domain name and click the Users node in the left pane of the console. In the right pane, right-click the Administrator account and click Name Mappings.
  4. Click on the X.509 Certificates tab and click the Add button.
  5. Select the certificate you need to add, and click Open.
  6. Remove the checkmark from the Use Subject for alternate security identity check box and click OK.
  7. A message tells you won't be able to use the subject for alternate security identity. That’s fine, since we have no idea what they’re talking about anyway . Click Yes.
  8. The new mapping appears in the dialog box. Click Apply and click OK.

You have now configured Active Directory to map all certificates from the issuing CA to the Administrator account. For details on MMC configuration, such as setting it for Advanced view, check out ISA Server and Beyondchapter 6.
=======================================
Make the Connection to the Web Site
=======================================
 Now that all the pieces are in place, you’re ready to make the client connection. Go to an external network client and open Internet Explorer. Type in the URL for your site in the Address bar. In this example the URL for the site is https://www.internal.net. You will see a dialog box that looks like what appears in figure 12. A user named "bob" has a user certificate installed on his computer. The Client Authentication dialog box identifies this certificate and asks if you want to use this certificate. Note that even though we mapped the Administrator account, Bob can still use his certificate to authenticate. As long as the Administrator and Bob are assigned certificates from the same Trusted Root authority, Bob will be able to use his certificate to authenticate. Click on the certificate and then click OK.
Figure 12: The Client Authentication dialog box
The Web server has been configured to require basic authentication. Figure 13 shows what the dialog box for basic authentication credentials looks like when you’ve configured a default domain. Enter your user name and password and click OK to enter the site.
Figure 13: The basic authentication log on dialog box
Once you’re in the Web site you’ll see that the connection is protected by SSL. Look in the status bar of the browser and you’ll see the "lock" icon confirming the SSL connection. You can double click on the lock icon and see the Web server certificate.
Figure 14: Connecting to the Web site


=======================================
Summary
=======================================
 In this article we went through the procedures that enable you to use client certificate authentication with the Incoming Web Requests listener. While there are a number of procedures you have to perform, I think you’ll find that its not nearly as difficult as you thought it was. The most common problem people have with certificate authentication is forgetting a small step somewhere in the process. If things don’t work for you, double check that you’ve performed all the steps correctly. The second most common problem is that the name on the certificate is incorrect. Make sure the common name on the Web site certificate is the same as the FQDN users use to access your Web site.






موضوعات مشابه: