domain controller and dns

8/8/2019 Domain Controller and DNS

http://slidepdf.com/reader/full/domain-controller-and-dns 1/17

Publishing a Single Exchange 2003 OWA with ISA 2004 Firewall Forms Based

Authentication

I decided to take the DIY approach for setting ISA firewall to securely publish Exchange 2003 Outlook Web Access usingforms-based authentication and SSL bridging to provide a higher level of security in web mail access. I believe this step-by-step article will take out some of the guess work that I went through when checking the configuration.

The procedures in this article will not work for multiple Exchange server environments as the publishing rule can only redirectrequest to a single server. If implemented in a multiple server environment, users will only be able to access OWA mailboxes

located on the published server. I presume that in a multiple server environment the procedure could be configured onlywhen the actual published server is an Exchange front-end server.

The advantage of publishing Exchange Outlook Web Access (OWA) using the ISA firewall's Forms-Based authentication is theability to off load the authentication of web clients from the Exchange server to the ISA firewall, and to preventunauthenticated communication from reaching the Exchange server. The ISA firewall's Forms-Based authentication workswith Exchange 5.5, 2000 and 2003.

This article will focus on Exchange 2003, where a web site certificate is used for two purposes:

1. Provide SSL communication between the remote client and the ISA firewall.2. Provide SSL communication between the ISA firewall and the Exchange server.

This will create an SSL to SSL bridge where the SSL communication from the remote client is terminated at the ISA firewall,and another SSL session is created between the ISA firewall and the exchange server. The remote client does not actuallyconnect directly to the Exchange server over SSL.

Steps for deployment:

Preparing the Exchange server 2003 and certificates.Decision point – Which certificates to useCreate your own certificatesGenerating the web site certificate requestFrom a request to a certificate

Importing the certificates to the ISA firewall.

Checking SSL connectivity between the ISA firewall and the OWA site

Importing the certificatesChecking Browser connectivity from ISA to the OWA site

Configure the ISA Web Listener and Publishing rule.

Verify External connectivity.

Preparing the Exchange server 2003 and certificates.

NOTE!

Do not enable forms-based authentication on the Exchange server itself.

The first step to take is to configure your internal Exchange 2003 server to use a web site certificate for client connections.The clients may be internal or external network clients, as far as the Exchange server is concerned. Since in our case remoteclients will actually connect to the ISA firewall, the ISA firewall itself will act as a client to the OWA web site. The Exchangeserver OWA web site can be configured to require SSL communication only, but this article will not cover this issue as it isusually not necessary to encrypt OWA connections within the internal network.

Decision point – Which certificates to use?

The best way to approach the use of certificates for a publicly accessible web site is to acquire a certificate from a knownCertificate Authority such as Verisign.



Accept the installation defaults and finish the installation.

When done, you will notice that on the CA server, a CA certificate is placed in the %windir%\system32\certsrv\CertEnroll folder. You will need to import the CA certificate to the trusted root CertificateAuthorities store on the ISA firewall later on.

Generating the web site certificate request

Log on to the Exchange 2003 server you intend to publish. Open the Internet Information Services (IIS) Manager toolfrom the Administrative Tools menu, and expand the web sites tree. Locate and click Properties on the Default Web Site,which holds the OWA virtual directories. Select to the Directory Security tab, and click Server Certificate…. In the Wizardselect: Create a new certificate.



Select to Prepare the request now, but send it later, and click Next. Leave the certificate name as Default Web Site,and the Bit Length: 1024 and click Next. Type the name of your organization and an OU, and click Next. In the CommonName window, make sure to enter the exact FQDN that will be used by external users to access the OWA web site. If thefollowing example I used owa.liran.org. You should register this record with your publicly available DNS service provider foryour domain. This record should point to the ISA firewall external interface IP address.

Note! For smaller companies, the external IP address of the ISA firewall may already be configured on your public DNS for yourdomain as the MX record with a name such as mail.liran.org . When creating the certificate, you may use this record as thecertificate common name, and save some time on calling the DNS provider for additional DNS record registration, but I willadvise against it as you might want to set up a mail gateway in the future which will use the mail.liran.org as the MX



record, but will no longer point to the ISA External interface IP address. The is no problem having more then one DNS recordpointing to a single IP address, so just add another host record such as owa.liran.org.

Continue running the certificate wizard, enter additional information in the Geographical Information page. In theCertificate Request File Name page make sure to note the location and file name of the certificate request file. The defaultlocation is c:\certreq.txt. Continue the process and click Finish.

Form a request to a certificate

To approve the certificate request, open a web browser on the Exchange server and enter the URL to the CA server. Forexample: http://CAServer/CertSrv (replace CAServer with the IP address or computer name of your CA server) On theCertificate Services Welcome screen, click Request a certificate. Select advanced certificate request, and click Submit

a certificate request by using…. On the Submit a Certificate Request or Renewal Request page focus on the SavedRequest window.

Open the request file generated earlier, (c:\certreq.txt), with notepad, and copy the content code between the Begin andEnd sections, and paste into the Saved Request window.

When done click Submit. Wait for the Certificate Pending, and close the web browser. Log on to the certificate server,open the Certification Authority console from the Administrative tools menu. Expand the CA, and navigate to thePending Requests tree. On the right pane you will see the certificate request just waiting there to be approved. Right clickthe certificate and select All Tasks and then Issue. The issued certificate will be moved to the Issued Certificates

container.



Go back to the Exchange server, and open the web browser. Again point to http://CAServer/CertSrv , and click View the

status of a pending certificate request. Click the saved request certificate link, and select Download certificate usingthe DER Encoded. Save the file certnew.cer to the Exchange server desktop. Open the IIS console on the Exchangeserver, and again navigate to the Directory Security tab of the Default Web Site. Click Server Certificate… and use the

wizard to process the pending request. Provide with the certnew.cer file, verify port 443 as the SSL port, click Next, Finish,and OK to close the properties page. Restart the Default web site.

At this point, the Default web site is SSL enabled, which means you can access it using either HTTP or HTTPS.

If you try to access the OWA web site using a web browser with https://, you might be prompted with an Alert such as thefollowing one:

Note that the Alert contains three parts as explained:a. Warning will appear if the CA that generated the certificate is not trusted.

In case you generated the certificate yourself from a privately installed CA,you will need to import the CA certificate to the computer Trusted rootcertificate authorities store. This is NOT required process on every clientunless you find this message very annoying.b. Warning will appear if the certificate dates are invalid.

This could happen if the date scope of the certificate does not matchthe date settings on the browsing computer, or if the certificate datesthemselves either will start in the future or already ended.



c. Warning will appear if contacting with a URL that is different for the

certificate common name.In the above example I used the server NetBIOS name instead of https://owa.liran.org/exchange, which caused the alert to appear.

In order for ISA firewall to properly publish the secured web site, you must make sure that SSL connection to the OWA website will not fail any of the above tests. This will be covered later on.

Importing the certificates to the ISA firewall.

The ISA firewall will require the web site certificate with its private key to make client-to-ISA SSL connections, and ISA-to-OWA SSL connections. You should export a copy of web site certificate for a later use.

To do so, return to the Directory Security tab of the default web site on the Exchange server, and click View Certificate.On the certificate window, select the details tab, and click Copy to file. In the wizard, select Yes, export the private key,

select to enable strong protection, set a password, and select to save the certificate to a file named c:\owasitecert.pfx.Copy the file to the ISA firewall hard drive. As I explained at the last section on step 1, the ISA 2004 server must be able toperform SSL client connectivity to the Exchange secured OWA site without any warning messages.

Checking SSL connectivity between ISA 2004 and the OWA site

Make sure SSL connection can be made from the ISA firewall to the Exchange server. Open a CMD console, and enter thefollowing line to test SSL connectivity: telnet ExchangeIP 443. (Replace ExchangeIP with the Exchange server internalnetwork IP address).

If a connection could not be made, create a computer definition for the Exchange server in the ISA console, and then createan access rule to allow HTTPS from LOCALHOST to the Exchange server computer object. Check connectivity again usingtelnet. When the connection could be made, continue by importing the required certificates to the ISA firewall.

Importing the certificates

On the ISA firewall, click Start -> Run, type mmc and click OK. In the new console either click CRTL+M, or selectAdd/Remove Snap-in from the file menu. On the Standalone tab, click Add, and select Certificates. Select ComputerAccount, and click Next. Select Local Computer and click Finish. Click Close and OK.

In the console, expand Certificates (Local computer), and navigate to Trusted root Certificate Authorities ->Certificates. Try to locate the Certificate server certificate. It should be named as your external domain name if you usedmy suggestion earlier for naming the CA. (This is not required if using 3rd party certificate) If you cannot find the certificate,you will need to import it. Copy the .crt file from the \system32\certsrv\CertEnroll folder of the Certificate authorityserver to the ISA firewall.

Back on the ISA firewall, right click the copied certificate, and select Install Certificate. Click Next, and select Place allcertificates in the following store. Click Browse, enable Show physical stores, expand the Trusted root certificateauthorities, and select Local Computer. Click OK, Next and Finish. You will be prompted with a security warning, click Yes,and OK to confirm the certificate installation.

To confirm the certificate installation, refresh the Trusted root Certificate Authorities certificate list and verify thecertificate can be located.



Keep the certificate console open on the ISA firewall.

Next, you will need to import the Web site certificate to the ISA firewall.

Use the certificates console again.

In the Console tree, expand Certificates (Local Computer), and select the Personal container. Right click Personal andselect All Tasks -> Import. Use the Browse to locate the owasitecert.pfx file you copied from the Exchange serverearlier, provide the password, and place the imported certificate to the personal certificate store. When down, refresh the

personal store and locate the imported web site certificate under Personal -> Certificates.

The certificate will be named based on the Common Name you selected for the published web site.



Close the Certificates console. You are not required to save it.

Checking Browser connectivity from ISA to the OWA site

Now we will check if the ISA firewall can connect to the OWA web site. As explained on the first section of the article, a fewchecks are made when connecting to a site with an SSL certificate.

We already covered the importing of the CA certificate to the ISA firewall, so the CA should already be trusted.

I assume that the web site certificate dates are valid as well as the date/time configuration on the ISA firewall clock, so weare only left with making sure that the URL used to connect to the OWA site is the one specified in the common name. This

means that in our lab case, we should be able to resolve the URL owa.liran.org from the ISA firewall to the Exchange serverinternal IP address.

If the ISA firewall cannot resolve the common name (owa.liran.org) to the Exchange IP address using DNS, (test byperforming a ping command), you should edit ISA firewall's hosts file (located in the %systemroot%\SYSTEM32\DRIVERS\etc folder) to include a name to IP translation of the common-name FQDN to the Exchange IPaddress. After updating the HOSTS file, try to ping the FQDN again, and verify that the ping request indeed tries to ping theExchange IP address. Note that we are looking for a successful name resolution and not a successful ping as ping trafficmight be blocked by the ISA firewall default rule.

Open a web browser on the ISA firewall, and enter the URL for test. The URL should be in the form of: https://common-name/exchange (You should replace the common name with the actual FQDN). If you are getting the Security Alertmessage, you should resolve the cause of the problem and try again. If you are unable to access the site at all, disable anyweb proxy settings in the browser LAN Settings and try again. Do NOT delete the added entry to the hosts file!

After resolving any problems you might have, you will be able to connect and logon to a mailbox on the Exchange OWA website using basic authentication pop-up window. Form based authentication will be performed for remote clients by the ISAfirewall.

Configure the ISA 2004 Listener and Publishing rule

In our example, the ISA firewall is configured with two network adapters. The first adapter connects to the LAN and thesecond adapter to the Internet. To publish the OWA web site, we will open the ISA management console, and navigate to theFirewall Policy on the left pane. On the right pane, expand the Task Pane. Click Publish a mail server on the Tasks tab.



The Welcome to the new mail server publishing rule wizard will appear. Select your desired rule name and click Next.Select Web Client Access, and click Next. On the Select Services page, make sure that Outlook Web Access is selectedand click Next.

On the Bridging Mode page select Secure Connection to client and mail server.



On the Specify the Web Mail Server page, type the FQDN of the published site (not the IP address, not the NetBIOS nameand not the internal domain FQDN unless the full server name of the Exchange server in the internal Active Directory DNSmatches the Common name FQDN, which is not likely).



On the Public Name Details page, enter the FQDN again, and click Next.

On the Select web Listener pane either edit an existing listener or create a new Listener in case no listener exists.

Configure the listener to listen on the External network segment. You can use the Address option to specify the specificexternal IP address to listen to in case you got multiple external IP addresses.



On the Port Specification page, enable SSL on port 443 and clear "Enable HTTP". Click Select to select the web sitecertificate that will be used for the client secure connection. If clicking Select results with no certificates, you should eitherclose and reopen the ISA console (it might have been open when you imported the certificate), or re-check the certificateexistence in the Personal certificate store of the Local Computer. Click Next and Finish to close the Listener configuration.Back in the Select Web Listener page, click Edit to edit the listener further more.

On the Preferences tab click Authentication.



Remove the Integrated selection, and select the OWA forms-Based instead. Click OK twice to confirm the Listenerconfiguration and return to the Select Web Listener page. Click Next twice to make the rule apply to all users, and clickFinish. Back in the ISA console, click Apply to activate the new rule.

Verify External connectivity.

The final step is to make sure that external clients can indeed access the OWA web site. Connect a computer to the Internet,and ping the web site common name. The name should be resolved to the ISA firewall external interface IP address that youspecified on the listener. If the name could not be resolved by the public DNS service for your domain, verify that the recordwas registered with the ISP/DNS service provider. To temporarily overcome the record registration issue, update the clientHOSTS file to provide the name-to-IP translation, where the common name translates to the ISA External IP address.

After name resolution is available, open a web browser and connect to the URL, for example: https://owa.liran.org/exchange

Note! As the Web Publishing rule is configured to answer requests directed specifically to the FQDN in addition to the specificExchange virtual directories, no other URL entered will allow you to access the OWA site.

Other requests will be answered with the error message: Error Code: 403 Forbidden. The server denied the specifiedUniform Resource Locator (URL). Contact the server administrator. (12202)

A successful connection attempt will probably provide with the following Security Alert, as the CA certificate is unknown tothe external client.



Disregard this warning, by clicking Yes.

If your users are concerned with this message either install the CA certificate on each remote computer (which might not bepossible in every Internet Café in Bangkok), or get yourself a web certificate from a trusted CA.

The users will now be instructed to provide logon information using the form based authentication page provided by the ISAfirewall. The transport of the user credentials are encrypted by SSL 128bit encryption.



Voila! We are there. Enjoy your secure Outlook Web access solution.

domain controller and dns

Documents