Microsoft Exchange and Blackberry Server Specialists


Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

VPN Through a PIX

Stuck out on site with a client, I couldn't connect to home via VPN. The client has a Cisco PIX and a quick bit of research showed that while the PIX will allow PPTP pass-through, it isn't enabled by default.

Apparently you need 6.3 of the PIX software, but then you can add the following command to the configuration and can then use the Windows VPN client:

fixup protocol pptp 1723

A quick change and I was able to connect home.
More information on Cisco's web site
You have to make a similar change if you need to go through a PIX with the Cisco VPN client to connect to a remote Cisco VPN server. In that case the command is:
Another command that requires version 6.3 of the PIX software.

Why you shouldn't use Self Generated SSL Certificates

A constant theme on many of the Internet forums is the use of self generated SSL certificates versus purchased SSL certificates, particularly when deploying RPC over HTTPS or Outlook Web Access.
Many people will advocate that using a self generated certificate is fine and will do the job.
This could be a certificate generated from the selfssl.exe tool that is supplied with the IIS Resource Kit, or Microsoft's certificate application.
However I am not one of them, and always deploy Exchange with a purchased certificate.

Use of SSL Certificates
SSL Certificates have two main tasks. 

  1. To prove that the server you are accessing is the server that you meant to access.
  2. To encrypt the connection between the application being used to access the server, and the server itself.

There are three things that your web browser looks for when accessing a secure site.

  • that the name on the certificate matches the address being accessed
  • the certificate is issued by someone the browser trusts, or the certificate matches one already installed on the web browser
  • the certificate is valid.

If any of those three fail, then you will get a warning message popup.
With self generated certificates, you will get the warning message when you access the server. This is because the certificate hasn't been issued by a trusted authority.
You can get round that warning message by importing the certificate in to the web browser. However that makes a lot of work with deployment, complicates matters and also means that you have to repeat the exercise when the certificates expires.
It also doesn't help when people are accessing your site from a public computer where you cannot install the certificate, such as an internet café or their machine at home.
And that is where self generated certificates start to cause problems.
You can tell your users to ignore the message when connecting to your site, but users have a habit of only hearing what they want to hear. They will hear "ignore the message" but forget the bit "when using our site". In these days of phishing and spoof web sites network administrators need to give out a consistent message - and telling users to ignore a security warning is a very example of failing to do that.
A security warning of any kind looks unprofessional and shows a lack of concern for security.

So what are the alternatives?
The best alternative is to purchase an SSL certificate.
However many administrators think that they need to go to one of the big SSL certificate issuers such as Verisign and pay US$400 or more per year - and that is just for a 40 bit certificate.
That is not the case.
I do my deployments using RapidSSL certificates. They cost US$69 per year and that is for a 128bit certificate. Their root certificate is in most of the popular web browsers so there is no complication there.
If you do need to deploy the certificates to Pocket PC devices, then that can be easily done (see
You could also certificates from Certificates for Exchange which are trusted by Windows Mobile 5.0 with MSFP and higher. Nothing to install on the devices making deployment easy.
You may also see some "free" SSL certificates around. These should be looked at carefully, paying particular attention to the root certificate support. If the root certificate isn't in the majority of web browsers then you will have the same problem as when issuing your own certificates - prompts and imports.

Do Self Generated Certificates Have a Place?
Yes they do. I use them all the time in lab environments. When I have control over every item accessing the service, then I will use the a self generated certificate and make all of adjustments as required to get it to work correctly. However in a production deployment, they are never used.

Mentioned in EE Newsletter Again

Yet another mention in the Experts Exchange Newsletter. This is starting to get embarrassing.
See the original here:
However here is the quote:
Kudos: There aren't enough superlatives to describe what Sembee has accomplished since he joined EE a little over two years ago. First he makes Rookie of the Year, and follows that up as Expert of the Year. Then he becomes the first EE member to crack the 7,000,000 point level; 5.8 million of those points -- more than all but five members have in total are in the Exchange Server topic area. It's a race to see whether he or objects will be the first to reach 6,000,000 in a single topic area.

Why you shouldn't put Exchange 2003 in a DMZ

If you are looking for a page on how to put Exchange in to a DMZ, then you have come to the wrong place. This isn't it. 
Also I am not posting about deploying Exchange in a secure way - at least not in this post. It just covers Exchange in a DMZ.

I don't deploy Exchange in to a DMZ, never have done, never will do. I discourage anyone who asks about it from doing so.

Yet Exchange in a DMZ is one of the most hotly debated subjects in the Exchange community.
The main "reason" that people want to put an Exchange server in to the DMZ is in the belief that it will increase the security of their network.

However ask yourself this - how does it increase your security? What does putting a member of your production domain in to the DMZ do to increase the security of your production network?

Answer those question with valid reasons, then go ahead and configure Exchange that way. As yet, no one can give me a valid answer to those questions.
Lets look at the reasons why it is a bad idea.

Exchange has to be installed on a domain member. It cannot be installed on a workgroup machine.
Therefore for a member of the domain to work correctly it needs to contact the domain controllers. This means opening ports on your firewall to allow that traffic through.
Furthermore, the Exchange server will talk to any of your domain controllers, and it is good practise not to limit the domain member to talking to just one domain controller. However as you have to allow certain ports through, you will need to change the rules on the firewall to allow the DMZ to talk to a range of IP addresses - even if you subnet it down.

Disabling of Dynamic Ports
Exchange does a lot of communications through dynamic ports. These ports are constantly changing. However to go through a firewall you need to stop it from doing that so that you can open certain ports. That means static ports - which actually reduces the security of your Exchange environment overall.
The change in the port allocation has to be made to all of your Exchange servers - because the front-end machine in the DMZ could talk to any of them. Plus the port has to be opened to all of those servers - making the rules very complex.

Front-end server gets compromised and the attacker walks straight in
As you have changed to static ports and opened the firewall to the the domain controllers, once the machine in the DMZ has been compromised the attacker can walk straight in to your domain controllers. The don't even have to go looking for them. In fact, if they get on to the Exchange server, then they are in already. Exchange will install a copy of Active Directory Users and Computers which the attacker can use to change the password of the administrator account and then has full access.

A Traditional DMZ should be somewhere where you place machines and resources that are expendable
A DMZ exposes machines to the Internet. It is supposed to be a buffer between the production network and the internet. With a domain member in there, it is simply an extension of your production network.
You should be prepared to remove a machine that is in the DMZ with a moments notice. With a domain member and/or an Exchange server you cannot do that. While you can remove an Exchange server instantly, it leaves a mess behind that can take a while to clean up.

A good firewall administrator wants the least number of ports open to the production network.
Having worked with financial institutions, showing them the list of ports that need to be open between an Exchange server on production and one in the DMZ usually means they give up on the idea.
This is the list of ports that need to be open between the frontend server and the production domain to allow all features of Exchange to work. The actual list required can vary from site to site, depending on the features deployed. 

  • SMTP: 25 
  • LDAP (DC lookup): 389 
  • LDAP (GC lookup): 3268 
  • NetBIOS (ports): 135, 139, 1024+ (default config is usually 6000 something). 
  • DNS: 53 
  • RPC: 111, 135, 1024+ 
  • Netlogon: 445 
  • Kerberos: 88 
  • OWA: 80 (HTTP), 443 (HTTPS) 
  • IMAP4: 143, 993 (with SSL) SSL   
  • POP3:110 995 (with SSL)

The NETBIOS ports (125, 139 etc and 445) are the ones that usually scare the firewall administrators the most as those are frequent targets and the NETBIOS traffic shouldn't be passing over a firewall.
Put all domain members inside the production network and open only the ports that you need to. In many cases this can be two - 25 (SMTP) and 443 (HTTPS).

My company has a policy of no machines on the internal network having direct connection to the Internet.
Valid point and a policy that is to be applauded. However this doesn't make a good reason to put Exchange in the DMZ.
Instead, put an ISA Server in the DMZ, on a machine that is part of a workgroup and publish what you need to through that. Once the machine has been completed, clone it so that if the machine gets compromised you can take down the original, restore the clone, fix the security hole and redeploy (after taking a fresh image). As it is a workgroup machine, there will be no problems with domain membership.

Update 7th March 2006: have just published an article on using ISA and Exchange:
Configuring ISA Server 2004 as an Exchange Frontend Server in the DMZ (Part 1)

Microsoft have supplied instructions on how to deploy Exchange in a DMZ.
Not really a valid argument. You could probably ask a car manufacturer to give you instructions on how to drive a car off a cliff. They can provide them to - but whether it is a good idea or not is down to you.

Hopefully this posting has given you an idea on why putting Exchange in to a DMZ is a bad idea, and will help you make your own decision when deploying Exchange in a secure way.

New Articles on

A couple of new bits and pieces for my technical web site

The articles on working with Distribution lists have been grouped together and can be found here:

This was caused by the publication of three new articles...
Creating a moderated distribution group:
How to make your distribution lists appear at the top of the Global Address List (which is actually quite old, but was buried on another page)
And how to hide the membership of a group, or even the existence of a group from the GAL.

Elsewhere, two pages have been added to the Pocket PC section, which may be of interest to Exchange Server administrators.
Working with SSL Certificates deals with getting SSL certificates on the handheld devices. If you are deploying OMA or Exchange Active Sync then this could be of interest to you.
Using the Windows Mobile 5.0 Emulator could also be of interest as it lets you simulate what the users are doing with their devices can aid support of those devices by your support team.

Many of the articles on the web site are reviewed frequently, as I update the techniques or correct errors, so please check back often!