TLS/SSL capabilities on Outlook 2003
Tobbe at
SMTP traffic from a client to the server (I.E. users that need to relay).
More specifically I want to make sure that the authentication part is
encrypted, while the message itself might be transferred unprotected.
Encryption of messages will be handled at the client side using individual
certificates.
In my setup I have the requirement to accept encrypted smtp connections on
25 and 465. Naturally I also have the requirement to accept normal anonymous
mail from the internet. The clients that will be used are of a broad range
of both Outlook 2003 and other linux and mac-based clients. However,
initially my focus has been to figure out my options when it comes to the
Outlook 2003 client.
At the moment I only have one public IP so what I've done is that I've
created two virtual smtp servers that listens on different ports, installed
a certificate and disabled the integrated authentication and checked the
"require TLS when basic authentication" is used. I've also left anonymous
access allowed to be able to receive incoming mails from the internet.
Relaying is allowed if the users authenticate.
When configuring a Outlook 2003 client, I've set that my outgoing server
requires authentication and set it to use SPA (what exactly is SPA anyway?
TLS, SSL or something different?). If I try to relay a mail from my client
with this setup it fails with the error message that I'm not allowed to
relay mails. However, if I also set the checkbox on the clientside that
states that the server requires a secure connection it works fine.
From what I've read that means that the entire conversation, both
authentication and messageflow is encrypted between the client and the
relaying mailserver. My goal is to only encrypt the authentication which I
thought would be satisfied by my initial setup where I only had checked the
Authenticate using SPA checkbox.
My main concern is about the non-windows clients and their implementation of
TLS/SSL. If I'm forced to choose "The server requires an encrypted
connection" to get it to work on a Outlook 2003 client I fear that I will be
seeing more issues on the mac and linux part of the company.
I'm thankful for any input that might help.
/Tobbe
neo [mvp outlook]
1) Never mess with the default SMTP virtual server in a multi-server site.
Creating secondaries on 465 (depreciated by the way) and/or 587 (client
message submission port) and just allowing basic auth over tls/ssl is good.
2) Make sure that Office/Outlook 2003 has a minimum of Office 2003 SP2
applied. (TLS/SSL over didn't work on non-standard ports until this revision
level.)
3) Don't use SPA. Basically in a single sign-on environment it is great
because Windows/Outlook will pass the current logged in user credentials to
do the work. Not a great feature when dealing with Workgroup based
computers.
Outside of that, once a clients establishes the TLS/SSL connection, it is
secure from beginning to end.
"Tobbe" <tobbe(at)_nospam_utbyte.se> wrote in message
news:e46LAek0...@TK2MSFTNGP06.phx.gbl...
Tobbe at
1. I'd be greatful if you could explain further why messing with the default
smtp virtual server is a bad idea? The current setup is two frontends under
NLB and a clustered backend active/passive so yes it is a multiserver site.
The plan WAS to let the default smtp servers on the both frontends accept
anonymous connections on 25 and also accept basic authentication but
requiring TLS so that relaying can be made over 25 but always encrypted.
Second smtp virtual server should be dedicated for relaying over 465, hence
only allowing basic with TLS required. The backend will not support relaying
at all.
2. Thanks for pointing that out. That's the conclusion that I had drawn
after sweaping google - much thanks to posts made by yourself. Thanks for
that!
3. Alright. So if I understand this correctly, SPA has nothing to do with
SSL/TLS but it is rather a NTLM/Integrated windows authentication thingy?
If I require TLS on the smtp virtual server the connecting Outlook client
will automatically encrypt the conversation without the "require secure
connection" or the SPA setting? Other clients might very well need to have
this setting configured manually I guess...just thinking out loud here..
4. If I like to give the different mailclients the choice of using either
TLS or SSL that would be satisfied by setting require tls on the basic
authentication on the virtual smtp server and by just having an installed
certificate on the smtp server? The choice between SSL and TLS will then
basically be made by the client in question or does the "require TLS"
setting take any kind of priority over a client checking "server requires a
secure connection" in a Outlook client for instance?
Thanks alot for your input so far!
"neo [mvp outlook]" <n...@online.mvps.org> wrote in message
news:uE23ERn0...@TK2MSFTNGP06.phx.gbl...
neo [mvp outlook]
internet mail at the gateway due to a configuration error. I just like
leaving the default alone and setting up secondary SMTP servers on a
secondary IPs in order to have a finer control over configuration. This
allows my site to publish what it needs to.
To give you a better idea on what I'm talking about so I don't get myself in
dutch in describing my work environment, read
http://msexchangeteam.com/archive/2005/01/24/359677.aspx and keep in mind I
work for a paranoid site about controlling what is exposed that can accept a
userid/password and you will understand.
2. Welcome ;)
3. Yes for NTLM/Integrated kinda thing.
Once you tick the box that TLS/SSL is required, it is quite possible
that nothing will move at this point (taps finger next to #1).
I generally view SPA as good thing in single-sign on environments
because the user doesn't have to visit other applications to update their
password. However, my world isn't so blessed in supporting
multi-environment/platforms.
4. Short answer, yes.
Longer answer... Outlook 2003 is a freak. If the port is 465 it will go
with SSL. If the port is 587, its TLS. Just about every mail client I can
think of today does TLS. Therefore I always go with port 587 because 465 is
old school.
And before I forget, the require TLS checkbox on the SMTP virtual server
means that whatever transpires *must* be secured. (meaning that it is SSL
on connect or clear text on connect and then issue the STARTTLS command.
Again see #1... can you hear me giggling?!?)
"Tobbe" <tobbe(at)_nospam_utbyte.se> wrote in message
news:en1DD0o0...@TK2MSFTNGP04.phx.gbl...
Tobbe at
hands and the head slightly bowed I'll try my luck with some more follow up
questions.
1. I read the article at msexchangeteam and that was great input in general
but naturally it gives me more questions. For example it states "the
internal SMTP transport is authenticated with Windows Integrated
Authentication, Send-As permissions are enforced, Linkstate and EXCH50 blobs
are exchanged".
Since I have an smtp connector configured with both the frontends as local
bridgeheads, how do I know which Virtual smtp server on the FE's that BE
server will contact? I do not specify which SMTP VS server it should
contact - only the full Exchange server. Since at least one of the virtual
smtp servers won't accept integrated auth, how will that affect
outgoing/incoming
mails?
Also, on a more basic level. Agreed that putting a non exchange smtp at the
very front would hide the authentication commands supported by Exchange but
how would the non Exchange servers be used as relays then? Since relaying
based on source network is out of the question I guess that means
maintaining local users on the non Exchange smtp's?
2. Still standing with the hat in my hand and the bowed head...
3. I'm leaving SPA out of the discussion to focus on the encryption part of
my problems for now
4. I actually tried to get Outlook to talk SSL but didn't manage to. With
the client set to "require secure connection" and the virtual server set
likewise (on the connection part, not the TLS setting under basic
authentication) and using port 25, "TLS secured" was logged in the header of
the mail. Setting port 465 on server and client logged the very same info. I
had _not_ set the require TLS checkbox on the virtual server in any of the
scenarios so that makes me wonder if Outlook (2003 sp2) ever talks SSL with
an Exchange 2003 or am I looking at this in the wrong way?
.
Also, trying with a thunderburd client gives me the same behaviour. TLS
works while SSL doesnt. No need to dive into the SSL vs TLS thing too deply
(unless you feel that you have the time) but I'd
really be interested in your thoughts about it.
/Tobbe
"neo [mvp outlook]" <n...@online.mvps.org> wrote in message
news:eYYsIhu0...@TK2MSFTNGP05.phx.gbl...