We are conducting our lives and our businesses in an increasingly mobile world.  We need access to our critical business information from multiple locations and using multiple devices.

These needs often clash with the requirement to keep our data secure.  Exchange Servers are kept behind corporate firewalls which restrict who can access them and how they can connect to their mailboxes.

Secure mobile access to mailboxes on Exchange Servers is typically achieved through one or more of these methods:

• Virtual Private Network (VPN)
• Outlook Anywhere
• Outlook Web App (OWA)
• ActiveSync

Virtual Private Networks

A VPN is a secure communications tunnel established between two endpoints.  These endpoints can be two devices such as routers or firewalls, or can be between a client device such as a laptop and a firewall.

Mobile workers use VPNs to establish LAN-like network access to their corporate network.  This usually means that once connected to the VPN they have access to the same network resources they would be able to access when connected to the LAN from within the business premises.  In more security conscious environments this access is sometimes limited to just the few resources they need, but in a practical sense operates just as if they were on the LAN.

Using VPNs for access to Exchange Server makes sense when there are other needs for VPN access as well, such as access to application servers, file servers, or intranet sites.  Rather than each resource having its own independent access method, the VPN provides an “all in one” access solution.

However sometimes VPNs are not practical.  It is not uncommon for a mobile worker to find they are unable to establish a VPN tunnel because of restrictions on the foreign network they are currently working on.  This is mostly the case for IPSEC and PPTP VPN tunnels.  SSL VPN tunnels usually have no such problems because the SSL/HTTPS port is usually permitted out through firewalls.

Outlook Anywhere

Outlook Anywhere was formerly known as RPC-over-HTTPS, which accurately describes how it works.

The Outlook connection to a mailbox server over RPC is tunnelled through an SSL/HTTPS connection so that it can traverse firewalls, as well as to secure the communications over untrusted networks.

Outlook Anywhere is a good solution for secure access to email alone, but provides no access to other resources on the network that the mobile worker might need.

Outlook Web App

Outlook Web App (OWA), known as Outlook Web Access prior to Exchange Server 2010, provides a web-based interface to Exchange Server mailboxes over an SSL/HTTPS connection.  Because access is available via a web browser this makes it accessible for mobile workers who do not have access to the full Outlook software, such as on a home computer or an internet kiosk.

OWA communications are secured over SSL/HTTPS, however when using untrusted computers such as internet kiosks there is the risk of key loggers or other malicious software being used to compromise account passwords.

Because of this risk it is common to use multi-factor authentication with at least one of those being a biometric or a one-time password generated by a token, so that even if the username and password combination are compromised the account cannot be accessed without the additional authentication item.

ActiveSync

ActiveSync is the name of Microsoft’s technology for connecting devices such as smartphones to Exchange Server mailboxes.

The connection is once again secured over SSL/HTTPS and can be subject to numerous restrictions and security policies designed to mitigate the risk of loss due to theft or loss of the smartphone device (which is fairly high risk given their size and general lack of security features).

Those are the four most common secure remote access methods for Exchange Server mailboxes.  I’ve left out some other access methods such as POP and IMAP. Although these can be used securely they are not very common and don’t provide a full functionality experience with Exchange Server.  For most real world scenarios some or all of the above four methods are the solution for secure remote access.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

4 Ways to Access Exchange Server Mailboxes through Firewalls

More and more companies are allowing employees to work from home via remote offices. Outfitted with high-speed internet, separate phone lines for fax and business calls and office white boards and most office workers are ready to be productive as if they were working in any office environment complete with interruptions – though not the usual kind.

One of the interruptions remote office employees will most often face is that of remote connectivity problems. The problem of a remote connection being down is that it is sometimes hard to pinpoint the exact cause of the remote connectivity issue.

For instance, users have reported remote connectivity problems when running Exchange 2003 on a Windows 2003 Enterprise Server. Remote users will experience “disconnected” status issues when connected remotely and Outlook will be displayed as being in “offline” mode. However, when users are in their company’s office they do not have any problems connecting to their Exchange mailbox while using Outlook 2007. And running in cached exchange mode does not appear to help either.

One of the first steps that an administrator should perform is to verify whether the Virtual Private Network (VPN) is working correctly or whether it is part of the problem. An administrator can bypass the VPN by configuring Outlook to communicate with the Exchange server via Remote Procedure Calls (RPC) over Hyper Text Transfer Protocol (HTTP). This will allow the administrator to confirm whether the remote communication problem still exists even when not using a VPN connection. If there is still a remote connection issue, while running RPC over HTTP, then the administrator will know that VPN is not part of the problem.

Running RPC over HTTP is a method used for passing email traffic over the ports normally used for web browsers. Using this method, Outlook MAPI client users are able to access their Exchange server email accounts from remote locations even if the server and the client are on different networks and behind their respective firewalls.

For this to work, administrators will need to setup an RPC proxy server that is used to specify the communication ports for network domain controller, global catalog (GC) servers and the Exchange server that will be used by the client. In addition, the Exchange server(s) must be configured to use RPC over HTTP and user account(s) must also be configured accordingly as well.

Administrators should follow the steps outlined below in order to configure Outlook clients to use RPC over HTTP.

1. Click on the Start button and then right click on the Outlook 2003 icon and then click on Properties.
2. Click the Add button in the Mail dialog box.
3. Type the profile name in the Profile Name text box.
4. Click OK.
5. Select “Add a new email account” option.
6. Click Next.
7. Select the Microsoft Exchange Server option from the Server Type page and click Next.
8. On the Exchange Server Settings page, type the Fully Qualified Domain Name (FQDN) for the Exchange Server in the text box.
9. Type the user account name in the User Name text box.
10. Click the Check Name button to confirm that the Outlook 2003 client machine can communicate with the Exchange Server.
11. Checkmark the “Use local copy of Mailbox” checkbox.
12. Click the More Settings button.
13. Click the Advanced tab and confirm that there is a checkmark in the Use local copy of Mailbox checkbox.
14. Click the Security tab.
15. Checkmark the “Encrypt information” checkbox.
16. Click the Connection tab.
17. Select the Connect using my Local Area Network (LAN) option.
18. Checkmark the “Connect to my Exchange mailbox using HTTP” checkbox.
19. Next, click the Exchange Proxy Settings button.
20. In the Exchange Proxy Settings dialog box, type the FQDN of your Exchange Server in the Use this URL to connect to my proxy server for Exchange text box. (Note: This is the Common Name as listed on the Web site certificate.
21. Checkmark the “Mutually authenticate the session when connecting with SSL” checkbox.
22. Type the FQDN of the Exchange Server (see your Web site certificate) in the Principal name for proxy server text box. (Example: Msstd:FQDN)
23. Checkmark the “Connect using HTTP first, then connect using my Local Area Network (LAN)” checkbox.
24. Select the Basic Authentication option from the “Use this authentication when connecting to my proxy server for Exchange” drop down box.
25. Select the Basic Authentication option.
26. Click OK in the Exchange Proxy Settings dialog box.
27. Click Apply and OK on the Microsoft Exchange Server dialog box.
28. Click Next on the Exchange Server Settings page.
29. Click Finish on the Congratulations! Page.
30. Click OK on the Mail dialog box.

After making all these changes you should then be able to open Outlook and confirm the connection status as “online” to your Exchange Server. If you are able to perform a successful connection here then your problem is not with the Exchange server but somewhere in the VPN connection.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Unavailable Exchange Server

Virtual Desktop Interfaces like GoToMyPC can be more secure than VPNs for remote workers.

As workers become increasingly mobile, they’re demanding access to their computers–both at home and in the office–from whereever they can connect to the Internet. Cube rats want to access their home computers. Road warriors need to connect to their office desktops to maintain their productivity while traveling. Linking to headquarters is essential for telecommuters.

Over the last decade or so, the vehicle for establishing secure connections outside a company’s firewalls has been the Virtual Private Network, or VPN. It allows a remote computer to tap into a corporate network by creating a secure tunnel to it through the Internet. This method, though, can have security risks. That’s opened a market for alternatives to the hoary VPN.

Because VPNs originate with a company’s IT department, their operation is unquestioned by their users. After all, the reason users are told they need to use the VPN is so they can connect to headquarters securely. That creates a false sense of safety among users so they’re likely to transfer sensitive data through the VPN without using additional encryption and deploy protocols that transmit authentication credentials without any protection at all.

In addition, the VPN can serve to protect an intruder’s mischief rather than block it. In many networks, the Intrusion Detection System (IDS) is located outside the VPN server. Because traffic through the VPN is encrypted, the IDS can’t see it. So if a cracker gains contol of the VPN, he or she can attack the internal systems without being picked up by the IDS.

Here’s another problem with a VPN. When a VPN is established from a remote computer to a host computer, the remote computer essentially becomes part of the corporate network. Data moves between the two computers. If a document is opened up on the host computer, that data is sent to the remote computer. If changes are made to that document on the remote computer, the document is changed on the host computer.

“If the remote computer is already compromised by malware or viruses or anything like that, then the data that you exchange with your host computer could get infected,” Kishore V. Kalidindi, director of engineering at the The Tolly Group Companies in Boca Raton, Fla. explained to me.

“Another thing,” he continued, “if you have a Trojan or keylogger on your local PC and it connects to your corporate network, then the malware can start spreading on your corporate network.”

“That’s a risk that administrators have to protect against before granting access from someone through a VPN,” he added. “They have to decide, do we need to do Security Posture Evaluation before letting a remote computer connect to our corporate network? That poses additional challenges for the administrator.”

Some Virtual Desktop Interface solutions, though, like GoToMyPC from Citrix Online, offer an alternative way to connect to a corporate network without a remote computer becoming part of that network. They do that by delivering a screen image to the remote computer, not the actual data from the host. Whatever is displayed on the host computer’s screen is being digitized, encrypted, compressed and transmitted to the remote computer. The host computer sees keyboard and mouse actions at the remote as if they were being executed on a keyboard and mouse connected to the host. “It doesn’t make the remote computer physically part of the corporate network, so certain security risks are mitigated by solutions like those,” Kalidindi explained. “Actual file data doesn’t get transmitted from your local computer to the corporate network.”

“That is a more secure approach of doing things,” he added.

Managing remote users has always been challenging to system administrators, although it’s more challenging now than it was when the only network access available to out-of-office workers was a phone and modem. Access can be less challenging with Virtual Desktop Interfaces. They can make an administrator’s life simpler, not only because sensitive information need not leave the network and their bandwidth requirements are modest, but VDIs will often function in situations where VPNs won’t. Moreover, they remove the burden of the admin acting as Big Brother monitoring what mobile jocks can and can’t do with their laptops. In addition, should a user complain of unsavory happenings on his or her remote computer, the VDI can be used to quickly assess the situation. While VDIs may not be a viable substitute for a VPN in all cases, if they are viable, they can reduce the security concerns  of administrators opening up their networks to remote access by their company’s workforce.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

More secure alternative to VPN

In another post I spoke of VPN and using secret keys to secure communications. VPN stands for Virtual Private Network and if you work for a large company or do business with a large company then chances are you log in to your network via a Virtual Private Network. A VPN is a network within a larger network such as the Internet or a company LAN. But the VPN is not characterized by the physical wires. Instead the VPN uses open connections or virtual circuits through the larger network.

VPNs can enable secure communications over the public network by using authentication or encryption. One of the ways to secure communications of the VPN is by using what is known as IPSec.

IPSec is short for IP security and is a secure VPN protocol. IPSec is defined by the Internet Engineering Task Force.

There are two encryption modes used by IPSec: tunneling and transport. Tunneling means that the header and payload of each packet is encrypted. It is then encapsulated into a new IP packet with a new IP header. Transport mode encrypts only the payload. And since only the payload is encrypted then the header which contains the routing information is left intact. Only IPSec compliant systems can take advantage of this protocol. And firewalls in the network must have very similar security policies. IPSec data can be encrypted between devices such as router to router, firewall to router, PC to router and PC to server.

IPSec operates at Layer 3 of the OSI model. Other protocols such as SSL, TLS and SSH operate at the upper layers. IPSec can use the following cryptographic algorithms: Triple DES, AES and HMAC-SHA1.

Almost all operating systems implement IPSec support in their kernels. These include: Windows, IBM AIX, HP_UX, Sun-Solaris, IBM z/OS and Linux.

When an IPSec connection occurs an IPSec node initializes a connection with a remote node or network. The remote node will check the connecting node’s credentials and then both nodes will negotiate the authentication method for the communication. Some systems use the pre-shared key method of authentication of which I have written about in other posts. Both systems use the same key in the succeeding communication process.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

How to secure your network using IPSec