It’s important for every environment to run as securely as budgets will allow. And in these times budgets are limited so administrators and IT directors must balance the funds available with the security needs of the organization.

One component of maintaining a secure environment is that of securely sending and receiving email. However problems can occur due to incorrect settings, incompatibilities and sometimes problems with services binding to the wrong Secure Socket Layer (SSL) certificates and external URLs – which will be the focus of this article.

When administrators initially set up Exchange server they will be asked to create a self-signed SSL certificate which will be used to identify the internal NETBIOS of the machine that is used to run the server.

An issue that may result from using the self-signed SSL certificate can be observed during the connection process to an outside URL. An SSL error popup message may show up indicating that the external URL site’s https URL is not the correct site address for the SSL Client/Server socket (connection). For instance, the popup window might say something about the “https” URL, such as https://yourserver(dot)yourcompany(dot)com/, not being the correct name for the SSL Client/Server connection.

Remember that Secure Socket Layer (SSL) was originally developed as a way to secure the internet connections between web browsers and web servers. Developed by Netscape in 1994, the Secure Socket Layer can be used in other applications such as Telnet and FTP.

SSL is an excellent security technology with a number of uses. From a user perspective it is most often seen as a front end to the Hyper Text Transfer Protocol (HTTP) in the form of HTTPS. It can also be used for POP3, SMTP, IMAP, and just about any other well behaved TCP application. It’s very easy for most programmers who are developing network applications from the start to just pull down an SSL implementation and integrate it with their application to provide encryption when communicating across the network via TCP.

And a lot of times, when certificates are needed for Exchange server, some administrators will just use the self-signed certificate that is created during initial setup. An option that administrators should consider is to purchase a certificate from an outside authority, known as a Root Certificate Authority. Certificates can be purchased from such authorities as: Verisign, GlobalSign, Thawte, and others.

But even after installing a valid certificate administrators may find that they are still receiving popup error messages about SSL errors and those error messages still refer to the aforementioned URL as not being a valid name for the SSL Client/Server connection.

It helps to know that all communication in an Exchange server environment is expected to run through SSL encryption. Meaning that communications between Exchange servers is encrypted and that communications between Exchange and Outlook clients is also encrypted. But you may have thought that those communications were supposed to be using RPC and MAPI. That still happens but only for some services.

Other services are using HTTPS. For example when Outlook 2007 is started up it will use an “Autodiscover” service to locate the mailbox for a user on an Exchange server. Normally this service is configured at setup time. The “Autodiscover” service uses SSL encrypted “tunneling” to the Exchange server for its communications.

(Tunneling, or port forwarding, is a way to forward otherwise insecure TCP traffic through SSH. You can secure POP3, SMTP and HTTP connections that would normally be insecure. I have used tunneling when working at remote customer sites and I was behind a firewall but I needed to get access to my own network.)

Getting back to our story, most Client Access Server Role services are bound to the SSL certificate you configured in Internet Information Server for the default website and which are subsequently by Exchange services for the sub sites. In order to correct this situation a reconfiguration will need to be performed that will bind all services to use the newly installed SSL Certificate – pulled down from one of the aforementioned Root Authorities – and to the company’s outside URL web site.

The Exchange information can be changed using cmdlets commands in the Windows PowerShell environment. The Windows PowerShell runtime can invoke these cmdlets from within automation scripts or invoke them through the Windows PowerShell APIs from via software.

The cmdlet that an administrator can invoke is as follows:

Set-WebServicesVirtualDirectory -Identity “(Virtual Directory ID)” -ExternalUrl “Https://(hostname to connect to Exchange server from outside the firewall)/” -InternalUrl “Https://(hostname of Exchange server for connection from inside the firewall)/”

This command will update all of the service addresses such as: OAB, Free/Busy, OOF, GAL.

If you are interested in updating only the Autodiscovery SCP you can use the following CMDLET:

Set-ClientAccessServer -Identity Servername -AutoDiscoverServiceInternalUri https://yourserver(dot)yourcompany(dot)com/

This cmdlet can be used to support the certificate which you purchased earlier and to sidestep Autodiscovery service errors as seen in such Exchange server environments.

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

Internal SSL Errors and Outlook

There have been many times in the past when I have started a project for a new customer and discovered that they are not using SSL for their email servers.  Usually after a brief discussion they agree to implement SSL in the new system we are installing for them.

Occasionally they agree but insist on doing it in a less than ideal manner.  And sometimes, although rarely, they decline our advice and continue without SSL.

What is SSL?

SSL stands for Secure Socket Layer and is an encryption protocol that secures communications between two parties over insecure networks such as the internet.  Although still commonly referred to as SSL its new name is actually TLS (Transport Layer Security) which more accurately describes its role of securing communications at the Transport layer of the OSI model (eg, the TCP protocol).

In an SSL/TLS secured communication the two parties (e.g. a web server and a web browser) agree on how to secure the connection they are establishing.The server sends the client its public encryption key (sometimes known as an SSL certificate) which the client then verifies against its own list of trusted certification authorities.  Once it has verified the key the client will generate a random number, encrypt it with the server’s public key, and send it to the server.  The public key encryption ensures that only the server can read the random number.

Contrary to popular assumption it is not the server’s public key (or SSL certificate) that is used for the encrypted connection, rather it is only used to secure the initial exchange of the random number.  The random number is then used to encrypt and decrypt the actual connection traffic.

Why is SSL important for Exchange Servers?

Exchange servers come with useful remote access features such as Outlook Web Access, Outlook Anywhere, and ActiveSync.  These features allow your users to access their email from any location with an internet connection by using a web browser, their laptop, or a mobile device such as a smartphone.

This convenience carries with it some security risks, the most obvious being the risk of password credentials being compromised.

Operating any of these remote access services without SSL means that the connection, including password credentials, occurs over an unsecured HTTP connection.  HTTP is the protocol that most websites use.  It is fast, stable, and works through just about any firewall.  But HTTP has no built in security.  Every bit of data sent over HTTP is unencrypted, so when passwords are sent over HTTP they are sent “in the clear”, vulnerable to network sniffers.

Because so much of this remote access occurs from untrusted locations such as free wireless hotspots, it is critical that SSL be used to protect this traffic.

Recommendations for using SSL

Here are some recommendations for using SSL to secure your Exchange server’s remote access features.

• Make it mandatory, not optional.  If you enable SSL but also still allow unencrypted HTTP you make it possible for an unwitting user to connect over the insecure method.
• Use it internally as well as externally.  It is tempting to allow non-SSL connections from locations within your own corporate network but this is still risky.  Some security professionals consider all network segments to be untrusted.
• Use a commercial Certificate Authority instead of a private one.  You may be tempted to save money on SSL certificates by installing a private CA and issuing your own, but this causes more headaches than it is worth.  Your private CA will not be trusted by devices such as smartphones or non-corporate computers, and will result in SSL warning messages that confuse users and can make some applications refuse to connect at all.  Because the SSL warning messages are also often found with phishing sites like fake banking sites it is not a good idea to get your users used to ignoring them.

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

The Importance of SSL for Exchange Servers

A fix for a flaw in an important Internet security protocol is ready for prime time but it will be many months before the patch is fully implemented, according to technical experts.

The authentication vulnerability in TSL/SSL, which is the most common security code on the Net, could be exploited by hackers for all kinds of mischief. Built into browsers and Web servers to protect high-value information, the flaw impacts a wide scope of technologies including online banking, back-office systems using Web-based protocols, non-HTTP applications such as mail and database servers, mobile phones, wireless access points, DECT phones and home security systems.

The vulnerability was discovered last September by researchers at PhoneFactor, a security service provider in Overland Park, Kansas, but was kept under wraps until November when another security expert, working independently, made the flaw public on a mailing list sponsored by the Internet Engineering Task Force (IETF).

With the cat out of the bag, PhoneFactor decided to push out a press release on the subject. In it CTO Steve Dispensa, who, along with Marsh Ray, initially unearthed the flaw, stated,

“Because this is a protocol vulnerability, and not merely an implementation flaw, the impacts are far-reaching. All SSL libraries will need to be patched, and most client and server applications will, at a minimum, need to include new copies of SSL libraries in their products. Most users will eventually need to update any software that uses SSL.”

“The discovery of this vulnerability speaks to a larger issue with single channel authentication protocols,” he added. “While this vulnerability is larger in scope than many, man-in-the-middle attacks have been a known threat for some time. Out-of-band protocols should be considered when possible to help mitigate the risk of these attacks.””

According to a U.S. Computer Emergency Readiness Team (CERT) vulnerability note, the TLS/SSL defect exploits the way the protocol handles renegotiation requests.

“The server treats the client’s initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data,” it explained.

The note said that SSL and TTL protocols are commonly used to provide authentication, encryption, integrity, and non-repudiation services to network applications such as HTTP, IMAP, POP3, LDAP. A vulnerability in the way SSL and TLS protocols allow renegotiation requests may allow an attacker to inject plaintext into an application protocol stream.

“A remote, unauthenticated attacker may be able to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream,” it added. “This could allow and attacker to issue HTTP requests, or take action impersonating the user, among other consequences.”

What’s more, the attack is invisible to the server and browser it’s directed at, according to PhoneFactor. They have no idea that a session has been hijacked.

Following the public revelations about the TLS/SSL glitch, a working group was formed made up of vendors and representatives from the appropriate standards committees. They hammered out the fix for the problem that was released last week.

Vendors are expected to begin shipping patches containing the fix shortly. However, predictions are that adoption will be slow because patches must be performed on both servers and clients to fully close the security gap. “This obviously will not happen tomorrow,” Ray Marsh wrote in his Extended Subset blog, “but eventually clients and servers will have to start refusing connections with unpatched endpoints (just like they do with ancient versions of SSL today). i.e., their configuration needs to go from “insecure/compatible mode”to secure/strict mode.”

“Unfortunately, as long as there is a single unpatched client and a single compatible-mode server in the world (or a compatible-mode client and an unpatched server) there exists a potential vulnerability,” he added.

Because the patching process will be prolonged, Marsh recommends that steps be taken to ensure that Web surfers are aware of their security status when accessing servers on the Net.

“[In the coming months we will need client applications to begin warning users if they are connecting to an unpatched server,” he noted. “After all, wouldn’t you expect your browser to warn you if your connection could be hijacked because the (supposedly) secure site to which you were connecting was not maintained well enough to apply critical security patches on a regular basis?”

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

Net security hole could take year to fix

Many people have reported problems when they try to sync their cell phones with their Exchange servers.

When they try to sync with MS Exchange Server 2003 using Windows Mobile 5.0 they might get the following error code: 0×80072f17. Some users have also reported problems when trying to sync with MS Exchange Server 2007.

This problem is usually associated with using Secure Socket Layer (SSL) certificates.

Remember that you use SSL for Internet protocols such as Network News Transfer Protocol (NNTP), Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), and Internet Message Access Protocol (IMAP).

The SSL authentication method uses public/private key technology to ensure privacy. The SSL protocol resides at the Open Systems Interconnection (OSI) presentation layer and moves data from the application layer to the TCP transport layer. It is responsible for authentication, encryption, and verification of data integrity.
The authentication function assures that the data is being sent to the correct server and that the server is secure. Encryption ensures that data cannot be read by anyone other than the target server. Data integrity ensures that the data has not been corrupted or altered in transit.

If your user removes the SSL authentication then they’ll probably be able to synchronize their phones with the server. But that’s probably not how you want them to operate. Even if you directly install the certificate you may still have problems. Checking or un-checking the proxy settings related box does not have an effect on the problem.

One solution to this problem is to reissue the SSL certificate through Internet Information Services (IIS). This can happen if you were using the original certificate the Exchange Server installed and the certificate was replaced.

Another possible cause for the 0×80072f17 error is if an unsupported certificate has been installed. If you installed a certificate that supported wildcards from a certifying digital certificate provider, then this certificate will probably install but using the certificate was most likely not supported. To fix this problem you can replace the certificate with one that does not use wildcards and is listed in the root certificate store on the device.

Another situation when the problem can occur is when Microsoft Exchange does not connect but generates another error code: 0×80072EE7. Selecting another system to synchronize with will result in a related synchronization error message such as when the Microsoft Exchange server shows “Synchronization could not be completed. Try again later”. The support code generated by the system is: 0×80072F17.

You might need to add a new certificate to your device. Such as when your SSL certificate issuer on the Exchange Server is new to the business or has made some changes.

Here’s how you can enable and disable Outlook Web Access for internal clients:

If you are using Microsoft Exchange Server 2003 Service Pack 1 (SP1), the following steps do not apply. The Web DAV address check is not present in Microsoft Exchange 2003 Service Pack 1.

To restrict access to Outlook Web Access if you are using Exchange Server 2003 SP1 or later, follow these steps:

1. In the Active Directory Users and Computers snap-in, right-click the user account that you want to restrict from using OWA, and then click Properties.
2. Click the Exchange Features tab, click Outlook Web Access, and then click Disable.

By default, user accounts that are mailbox-enabled are also enabled for Outlook Web Access in Exchange Server 2003.

You can enable users in your corporate network to access Outlook Web Access. At the same time, you can deny access to external clients. The key to this approach is a combination of a recipient policy and a special Hypertext Transfer Protocol (HTTP) virtual server.

To use this approach, follow these steps:

1. Create a recipient policy with a Simple Mail Transfer Protocol (SMTP) domain name. Users who connect to an HTTP virtual server must have an e-mail address with the same SMTP domain as the virtual server. Creating a recipient policy is an efficient way to apply the same SMTP domain to multiple users. (Note Outlook Web Access users do not have to know the name of the SMTP domain.)
2. Apply the recipient policy to the user accounts that you want to enable access for.
3. On the front-end server, create a new HTTP virtual server that specifies the domain that is used in the recipient policy.

After you have completed these steps, users whose e-mail addresses do not have the same SMTP domain as the HTTP virtual server cannot log on and access Outlook Web Access. Also, as long as you do not use the SMTP domain as the default domain, external users cannot determine what the SMTP domain is because the domain does not appear in the From field when users send e-mail messages outside the organization.

For more information, review the following article number in the Microsoft Knowledge Base:  293386  HTTP 401 or 404 error messages when you access OWA implicitly or explicitly.

Besides enabling Outlook Web Access for users in your corporate network, you can also prevent specific internal users from accessing Outlook Web Access. You do this by disabling the HTTP and Network News Transfer Protocol (NNTP) protocols for those users.

To prevent an internal user from accessing Outlook Web Access, follow these steps:

1. In the Active Directory Users and Computers snap-in, open the user’s Properties dialog box.
2. On the Exchange Features tab, click Outlook Web Access, and then click Disable.
3. Restart the IIS Admin Service.

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

Troubleshooting Error Code 0×80072f17

Email operations and email archiving needs to have safe and secure protocols in place, especially if the corporation is under the purview of a privacy-related piece of legislation, such as HIPAA or Sarbanes-Oxley. Generally, the best way to ensure that those privacy protocols are put in place is to avoid cloud-based email and storage services.

Google continues to try to get a seat at the enterprise with Gmail, and this week, some of the industry’s heavy-hitters took Google to the task over the issue. An open letter to Google’s CEO Eric Schmidt says the company is putting users at risk unnecessarily, and that encryption should be enabled by default on their web-based apps, including Gmail.

Currently, SSL is used only during login, after which, all browsing is unencrypted, unless the user takes an active step to return to the https protocol. Unless that step is taken, which most users will not do, the user is vulnerable to attack and theft. In most cases then, Gmail is run in the clear–which is completely unsuitable for corporate use.

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

Google should encrypt the cloud