Wintivity ™

Connecting iPhone and Microsoft Exchange reveals two primary connectivity relationships.

• IMAP (possible with iPhone 1.0 and 2.0)
• Exchange Active Sync employing Direct Push (iPhone 2.0 and newer)

Exchange has two major releases that support iPhone

• Exchange 2003
• Exchange 2007

The service packs for Exchange also support different functionality.

The key turning point for iPhone in relation to Exchange has been Apple’s support for Direct Push technology and Exchange Active Sync (achieved in iPhone 2.0 release). Microsoft has placed the emphasis on Direct Push since Exchange 2003 Service Pack 2 released in June 2005, and now Apple is on-board. H

Prior to 2.0 release, Apple offered only IMAP as a supported method of connecting iPhone to Exchange.

Here are some great articles on setting up IMAP in your Exchange environment

• Configuring IMAP for iPhone Sync Microsoft Exchange 2003 - Non-Clustered Configuration
• Configuring iPhone and IMAP access for Microsoft Exchange 2007

Followed by Apple’s own articles on connecting iPhone to Exchange using Exchange Active Sync. First is Apples definitive guide (.pdf) on deploying iPhone in the Enterprise . There are also Apple specific articles including:

• Apple - Support - iPhone - Mail Helper
• Preparing Exchange for iPhone setup
• iPhone 2.1 Exchange Active Sync “direct push” - setting up iPhone with Exchange

This is what iPhone 2.0 looks like from the Exchange 2007 administrator’s perspective if connected using Exchange Active Sync.

POP3 and IMAP are still supported in the latest release of Exchange 2007 SP1. Therefore iPhone can support both methods. One question that may also be asked prior to selecting the method is whether you require support for Public Folders from Exchange to be supported in the iPhone. At this time only IMAP connectivity will provide iPhone users any view of Public Folders in Exchange.

To learn more about the differences between IMAP and EAS, please read Mobile Device Connectivity to Exchange using IMAP vs Exchange ActiveSync .

Finally, the follow table examines iPhone on Exchange 2003 and 2007 in light of Public Folders

Why the emphasis on Public Folders? Clients are often interested in the Public Folder concept of Microsoft Exchange. Microsoft however has recently “de-emphazied” Public folders… making them essentially an endangered species in reference to future support and expansion of the concept.

TO BE CONTINUED

When administering Exchange for the first time with newer clients, we find Microsoft Exchange Public Folders to be one of the most underutilized features of Exchange installations. The more we inform our clients about Public Folders, what they can do and how to use them, the more value they generally receive from their existing Exchange installations (that is of course when public folders provide a make sense solution to certain needs within their organization).

Because Outlook Web Access is often one of the first features used by clients, we find ourselves looking over and tightening up security by encrypting credentials for OWA access through use of an SSL certificate (yes, we still find businesses authenticating in the clear!). The need to encrypt access credentials is obvious but many small businesses completely overlook this security fundamental OR do not have the funds needed to purchase a “brand name” certificate from the highly recognized Authorities like Thawte, Verisign, etc… Buying a basic Server certificate from Verisign (as an example) is $995 year. While this amount of money is a drop in the bucket for big IT infrastructures, for some small businesses it’s not affordable at all and they find it hard to justify paying the fee each year (especially when they may not even have ever been told why encryption is important to security in the first place).

At WIGITAL, we generate a lot of self signed certificates at 2048 bit count encryption as part of our services. This DIY approach saves the client a bunch of money each year, they get the encryption they need for OWA and we get to sleep better at night as consultants.

Here is where the failure can occur when attempting to Administer Public Folders in Exchange after a selfSSL certificate (or any certificate for that matter) is generated for OWA Outlook Web Access.

The typical method of generating a self signed SSL certificate using selfssl.exe requests a common name during the process of making the certificate. The CN is used to identify the cert with the site (ex CN=owa.mycompany.com). The certificate is named so that when Users log on to OWA, they can recognized the “name” of the SSL certificate matches the name of the website. This name matching of certificate and URL is also part of the warning system of most browsers with the browser prompting the user if the name of the certificate does not match the name of the website.

In the case of Exchange and OWA however, unless the administrator also publishes the COMPUTERNAME of the Exchange Server (or Front End Exchange Server) in the certificate along with the website name, Exchange will cause Public Folders to become inaccessible to administration. This is because the SSL cert causes an error when attempting to access the Public Folders using Exchange System Manager.

Exchange System Manager can (and will) throw errors such as the following when the CN on a self signed SSL certificate does not match the SERVERNAME of the Exchange Server or is not trusted.

Errors

ID c103b404 The SSL certificate server name is incorrect.

OR

ID 80090325 The certificate chain was issued by an authority that is not trusted.

The second error indicating the certificate is not trusted can be a simple oversight on the part of the administrator. The selfSSL tool does have a parameter to make sure a certificate “trusted” at the time it’s created. However, adding the cert to the Trusted Root using the Certificate snap-in does not solve the problem “when” the SERVERNAME is not one of the Common Name’s in the certificate.

Fortunately the work around is pretty simple.

Exchange System Manager uses IIS as it’s vehicle to provide the administrative functionality for Exchange Public Folders. In other words, the administration of ESM actually rides on top of IIS using IIS as the engine to provide the functionality for administration. A virtual server (exadmin) is created during Exchange setup in IIS as a subsite (or child) of the default web site. exadmin in IIS, then…. is the engine on which we administer (EXchange ADMINistration) Public Folders.

Using an SSL certificate above the exadmin node (on the Default web site root) and then requiring SSL at the level of the exadmin virtual server can cause the errors we’re writing about. Exchange will not allow administration if the name of the certificate does not match the name of the server (and this is always the case if the certificate is named for the “public URL” of the default website).

SOLUTION: Simply disable the requirement for SSL on the exadmin virtual server in IIS and problem is solved.

You can also enter multiple Common Names into self signed certificates (including the proper SEVERNAME) using selfSSL by following this article

http://wintivity.wigital.net/security/multiple-common-names-for-certificates-using-selfsslexe

Be advised however, that it is never advisable to publish the FQDN Fully Qualified Domain Name of a server on your internal network into the details of a certificate to be published on a public facing website.

READING

See this thread at msexchange.org

Here are some additional articles with other reasons why Public Folders may fail to open when attempting to administer them:

You receive an SSL Certificate error message when you view public folders in Exchange System Manager

http://support.microsoft.com/kb/324345

Troubleshooting Microsoft Exchange System Manager Public Folder Expansion Problems

http://technet.microsoft.com/en-us/library/aa996098(EXCHG.65).aspx

Cleaning up Exchange 2000/2003 administrative groups - Do not delete the admin group that holds the public folders

http://mostlyexchange.blogspot.com/search?q=public+folder+delete

Thanks for reading,

Mark Raborn
WIGITAL
Business Computing and Technology Professionals

ISA Server has some extraordinary functionality when it comes to securely publishing Servers and Web Servers in the Windows Domain.

Today, I’m preparing to use this tool to securely publish Microsoft Exchange 2003 using Forms Authentication with SSL Bridging. Given the complexity of many procedures related to ISA, my experience is that Microsoft has done an excellent job of documenting ISA 2006 with walkthroughs. I have made references to TechNet , etc… for various pieces of the security puzzle. Much of this article is taken from their work. Thank you Microsoft.

Also, Dr. Tom Schinder (as always) has outstanding walkthrough’s available at isaserver.org. Tom is one of the true community leaders in ISA - Internet Security and Acceleration Server.

About the article: this data is being written for the reference of one of our clients. Since we are using the internet for our notepad, everyone may share the material, refer to it and borrow from it.

TOPOLOGY

• Domain Controller - Windows Server 2003
• Exchange Server - Exchange Server 2003
• ISA Server 2006
• Windows XP and Vista client(s) - for testing
• Windows Mobile 5.0 with Messaging and Security Feature Pack - for testing

We are going to use ISA today to securely publish a single Exchange Server. To do so, we must assure that Microsoft Exchange 2003 is setup properly to provide Outlook Web Access, Outlook Mobile Access and Outlook via the Internet using RPC/HTTP. Please verify that:

• IIS 6.0 is installed on Windows Server hosting Exchange 2003
• Exchange 2003 has the Prerequisites for running IIS (including SMTP and NNTP)
• RPC over HTTP is configured in Exchange Server 2003
• The network interface is configured with a valid IP address and subnet mask, and is using the domain controller as its DNS server and WINS server
• The default gateway is configured to be the internal IP address of the ISA Firewall
• Service Pack 2 for Exchange 2003 is installed
• Windows Update has been used to apply all updates

the WALKTHROUGH

1. Setup ISA according to the requirements of the list above
2. When naming ISA Server, do so as a Workgroup member (in this scenario we are not a member of the Domain)
3. Create at least a 2 leg ISA configuration (requires two network adapters)
4. Place the ISA Server outside the perimeter of your Network (as the edge firewall)
5. Connect the ISA Server (WAN side) to the Internet in the IP subnet assigned to you by your ISP (you can multi-home an external facing ISA NIC - article here )
6. Confirm Internet Connectivity from the WAN side network interface card (example: http://update.microsoft.com)
7. CREATE A WEB LISTENER FOR MAILl
   1. Go to ISA Management Console
   2. Go to the Toolbox [tab] and expand Network Objects
   3. Right click the Web Listeners container and select New Web Listener…
   4. Enter a Web listener name: (such as OWA 2003 SSL with FBA) and click Next
   5. Under Client Connection Security select the radio button ( ) Require SSL secured connections with clients and click Next
   6. Under Web Listener IP Addresses select the checkbox [ ] for network to which this listener will be assigned
      1. this will enable the Select IP Address [button] below the networks selection area
      2. click Select IP Address [button]
      3. Under External Network Listener IP Selection select the radio button ( ) to Listen for requests on:
         1. If the selected Network has only 1 IP address assigned then select ( ) Default IP address for network adapters on this network
         2. If the selected Network has multiple IP addresses assigned (i.e. the Network Adapter is multi-homed) then select ( ) Specified IP address on the ISA serer computer in the selected network
            
         3. NOTE: once selected the IP’s will appearin the networks box
      4. Click Next ……
   7. Under Listener SSL Certificates, it is possible to Use a single certificate for this Web Listener OR to Assign a certificate for each IP address . Select the setting appropriate to your needs. Most oftern a single certificate for a each IP address is used as SSL is commonly enabled on a 1 to 1 ratio of 1 Certificate to 1 IP address
   8. NOTE: certificates are installed to the Personal certificate store of the ISA Server. This can be accomplished using the Certificates Snapin in the MMC Microsoft Management Console
   9. Authentication Settings
      1. Under Authentication Settings, from the drop-down menu Select how clients will provide credentials to ISA Server, choose HTML Form Authentication
      2. Under Select how ISA Server will validate client credentials: select LDAP (Active Directory),
      3. click Next
   10. Single Sign On Settings can be enabled by selecting the radio button ( ) Enable SSO for web sites published with this Web Listener and entering the domain name of your published resources that share the same first level domain. For SSO to work, the resources allocated for SSO must use the same Web Listener. To read more, please refer to Dr. Tom Shinder’s article. Please click Next
   11. Review your settings to complete the wizard. Click Finish
8. INSTALL THE RPC/HTTP PROXY ON THE EXCHANGE SERVER
   1. On the Exchange Server, go to Control Panel
   2. Select Add or Remove Programs
   3. Select Add/Remove Windows Components
   4. Highlight Network Services and click the Details [button]
   5. Select the checkbox [ ] RPC over HTTP Proxy and click OK
   6. On the Windows Components page click Next
   7. you may be prompted for the Windows Server installation disk or Service Pack location
   8. when the Components configuration is completed, click Finish
9. SET EXCHANGE 2003 AS BACKEND EXCHANGE SERVER
   1. Go to Exchange System Manager
   2. Under the Exchange Organization you are publishing, expand the Servers container
   3. Right click your Exchange server and select Properties
   4. Select the RPC-HTTP [tab]
   5. Select the radio button ( ) RPC-HTTP back end server
   6. NOTE: you may be prompted that there is no RPC-HTTP front-end in your Exchange Organization. Click OK
   7. Click Apply and Click OK
10. CONFIGURE THE RPC PROXY SERVER TO USE SPECIFIC PORTS FOR RPC/HTTP
    1. NOTE!!! - THIS REQUIRES EDITING THE REGISTRY
    2. To to Start | Run | and type regedit.exe
    3. per Dr. Schinder: the following registry values are automatically configured during Exchange setup. Although you do not have to configure these registry values, you should verify that these registry values are configured correctly.
    4. VALUES - CONFIRM THESE
       1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
          1. Value name: Rpc/HTTP Port
          2. Value type: REG_DWORD
          3. Value data: 0×1771 (Decimal 6001)
       2. KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
          1. Value name: HTTP Port
          2. Value type: REG_DWORD
          3. Value data: 0×1772 (Decimal 6002)
       3. KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
          1. Value name: Rpc/HTTP NSPI Port
          2. Value type: REG_DWORD
          3. Value data: 0×1774 (Decimal 6004)
    5. NEW…
    6. NEW SETTINGS - MODIFY REGISTRY TO CONFIGURE RPC PROXY SERVER TO USE SPECIFIC PORTS
       1. perform the following steps to configure the RPC proxy server to use specific ports:
       1. 1. On the RPC proxy server, start Registry Editor (Regedit).
          2. In the console tree, locate the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy
          3. In the details pane, right-click the ValidPorts subkey, and then click Modify.
          4. In Edit String, in the Value data box, type the following information:
             1. NETBOISNAMEofExchangeServer:6001-6002;FQDNofExchangeServer:6001-6002;NETBIOSNAMEofExchangeServer:6004;FQDNofExchangeServerFQDN:6004;
                
          5. NOTE: To determine the NETBIOS Name and the FQDN Fully Qualified Domain Name of your Exchanger server Go to Start | Run | type cmd.exe | in the command windows type ipconfig /all
12. Click Next….

NOTES:

• The root certification authority (CA) certificate for a CA that issued the server certificate on the published Web server needs to be installed on the ISA Server computer
• ISA Server needs to resolve the FQDN that is used to create the certificate. The connection between the ISA Server computer and the Exchange front-end server will not be successful if ISA Server uses a different FQDN than the FQDN used to create the certificate
• Limit access to authenticated users. If you do not limit access to authenticated users, as in the case when a rule allowing access is applied to all users, ISA Server will not validate the user’s credentials. When access is limited to authenticated users, ISA Server will use the user’s credentials to authenticate to the Web server according to the configured delegation method.
• Microsoft recommends that you apply each publishing rule to all authenticated users or a specific user set, rather than selecting Require all users to authenticate on the Web listener, which requires any user connecting through the listener to authenticate
• Disable Forms Authentication on the Exchange HTTP Virtual Server to permit ISA to act as the Proxy for Exchange Forms Authentication.

NOTES ON LDAP PASSWORD CHANGE

To configure the Change Password option when using LDAP authentication, LDAP needs to be configured with the following settings:

• Connection to the LDAP servers must be over a secured connection. This requires an SSL certificate to be installed on the Active Directory servers. For more information about enabling LDAP over SSL, see “How to Enable LDAP over SSL with a third-party certification authority” at the Microsoft Support Web site.
• The ISA Server computer needs to have the root certificate for the CA that issued the SSL certificate installed on the Active Directory servers.
• Connection to the LDAP servers cannot be via a global catalog (it must be LDAP secure - port 636 by default~> a link with some info )
• A user name and password (a custom Service Account) that is used for verifying user account status and changing passwords as required (when the ISA Server communicates to Active Directory).

NOTES ON REDIRECTING CLIENTS TO THE SSL SECURED EXCHANGE VIRTUAL DIRECTORY

The default setting in IIS for access to web sites, virtual directories, etc… is to do so over HTTP. Given that credentials passed over HTTP are in the clear, the use of Secure Socket Layer encryption should be considered *a must have* to improve network security for usernames and passwords passed over the Internet.

Most users don’t consider typing https (the secure form of http). So, after SSL has been setup, the next step should be to consider that IF most users don’t habitually type URL’s in the form of https… something-something, then a REDIRECT might be useful to help them reach their destination securely to your OWA - Outlook Web Access domain name.

• On the OWA Server, open IIS Manager
  • CMD - go to Run and type inetmgr.exe
  • GUI - Start | All Programs | Administrative Tools | Internet Information Services [IIS] Manager
• Navigate the SERVERNAME (local computer) to the Web Sites node
• Right-click the OWA Virtual Server (usually Default Web Site) and select Properties
• Select the Home Directory tab
• Under the setting The content for this resource should come from: select the radio button A redirection to a URL
• Check the box A directory below the URL entered
• Click OK
• When prompted to confirm inheritance overrides, click OK
• Restart IIS
• more….

Please note that this procedure should only be used when Outlook Web Access is the main web service provided to your users and the Default Web Site is NOT hosting other services and functionalities that require the use of the http:// Port 80 access at the web site root.

ALSO: there is more than one way to achieve a redirect for OWA in IIS. For further study please read:

• How to redirect an HTTP connection to HTTPS for Outlook Web Access clients
• Redirect clients in your application with HttpRedirection module (mvolo - big time IIS guy)

Other Online Walkthroughs on Exchange 2003 and ISA 2006

• ISA 2006 Deployment with Exchange 2003
• Secure Application Publishing - LDAP Configuration
• ISA 2006 SSL Bridging
• Secure Outlook Web Access Publishing
• http://www.isaserver.org/tutorials/ISA-Firewall-Publishing-OWA-RPC-HTTP-Single-IP-Address-Part2.html (READ THROUGH THIS SERIES)

Guides

• Front-End and Back-End Server Topology Guide for Exchange Server 2003 and Exchange 2000 Server

For Troubleshooting see:

• Troubleshooting OWA and ISA
• Authentication in ISA 2006