Outlook authentication popup when database move or failover

Have you noticed that when you run Exchange 2010 DAG and move the active database to another node, outlook throw an authentication prompt.

The behavior according to many sources including Microsoft is that a move or failover should go almost unnoticed by the end user. Well it does sometime, but many times outlook popups the authentication prompt.

Messed around in my lab with all kind of configurations and discovered that the prompt is to the outlook anywhere URL. This makes sense because the database goes offline and then another database goes online. This takes a short moment but the only component that should see this is CAS and outlook should still have connection to your Hardware Load Balancer or CAS if you don’t have a HLB. So if outlook is aware of a database goes offline then this is kind of valid.

To try things a little bit more I configured the system not to resolve the Outlook anywhere URL when connected to the internal network and then I did a move of active database again and I was very surprised that outlook still did popup for the outlook anywhere URL without actually being able to resolve it in DNS or even less actually connecting to it.

I figured there must be some caching going on here and to be safe I simply reboot everything. But outlook behaved the same, prompting me for credentials for an URL that could not be reached.

Finally I poked around in the configuration and decided to change the authentication scheme for outlook anywhere to Windows Integrated. I did not have a TMG or UAG in the system so I did not need to configure Kerberos Constrained Delegation (that’s another story).

Placed an outlook on the outside of the network and things went smooth; NTLM let me in directly with my cached domain credentials.

Moved outlook to the internal network and still everything worked as it should. Finally did move of the active database to another server. Outlook did not even blink, well almost, it just said it’s not connected and then a couple of seconds later it said connected again.

Well this must be one of the rare occasions when everything worked as it should according to various sources. Did about 20 more move of the active mailbox database and not a single time did outlook give me authentication prompt.

Well, I reconfigured outlook anywhere to use basic clear text authentication again and moved the database back and forth and about half the times outlook gave me the annoying authentication prompt.

Did some more testing with various setup and different version of outlook but the behavior is the same. When outlook anywhere is configured with basic clear text I get authentication prompts and when configured with Windows Integrated everything work without a hiccup.

Do we have any drawbacks by configure windows integrated authentication on outlook anywhere? Yes there is. Depending on if you have ISA/TMG/UAG doing Kerberos Constrained Delegation against your CAS, everything must belong to the same windows domain. Well, not exactly everything but all accounts used in the process, that is computer and user accounts.
This means if you have multiple forests or multiple domains and publishing Outlook Anywhere with pre-authentication on TMG/UAG, you’re almost forced to use Basic Authentication.

More information about Kerberos Constrained Delegation will be posted in a later post.

Some thoughts about applications sending SMTP messages to Exchange

Most organizations have applications that need to send mail, either to internal recipients or to have a SMTP server to relay there mail destined for external recipients.

Common configuration is that they figure out the server IP address where the application runs on and then enter the IP on the allow relay list on Exchange 2003 virtual server, if then run Exchange 2007 they often are a little bit puzzled until someone shows them MSExchangeteam 'Allowing application servers to relay off Exchange Server 2007'.

Why do I think this is bad?
First, most applications don't need the relay permission, admins often think so but the truth is that they don't need it.
Servers are not static, IP changes, name changes both on the application side and the Exchange side. If the server get infected with something bad, it is not just the application running on the server that are allowed to relay but everything running on the server since its the IP that are allowed to relay.
Remember this: IP restrictions are not authentication.
Have seen applications that are hardcoded to connect to a specific IP or names meaning that either IP or name can be changed on the Exchange server.
Resolution is of course to have applications easy to reconfigure with destination SMTP server’s name.

Another problem is when there is some kind of anti spam software running on Exchange. This will often make the applications mail end up being classified as spam and make Exchange admins trying to configure the anti spam software to white list some mail. Sometimes this cant be done and sometimes it can making admin workload bigger than before.
Resolution here is to educate developers in SMTP. They often doa good job of building applications but are very often bad at SMTP. They find a free SMTP engine on Internet and they stick it in there applications and in the end they manage to send a SMTP mail but it is often bad formatted in various way making the anti spam software react and classify it as spam.
Resolution here is of course knowledge about SMTP.

Back to the relaying part of sending mail. One very good solution here is to have the submitting application to authenticate SMTP session. By sending authenticated SMTP mail to Exchange, it will get the permission to relay, it will most likely bypass antispam software depending of software of course. It will also make the application easier to move to another server without reconfigure Exchange. Another thing with authentication and SMTP is that if I authenticate as ‘application 1’ I am only allowed to use ‘application 1’ email address, I cannot use another SMTP sender address..

My recommendations to developers, building applications sending SMTP mail.
* Use a good SMTP engine that do work. Have encountered one that didn’t like the tarpit time you can configure in Exchange 2003 and are default activated on Exchange 2007. This engine simply could not work with tarpit.
* Use authentication when submitting mail. NTLM is of course better than Basic, but if using basic authentication, use it over TLS.
* Ability to easy change SMTP configurations such as server name, sender and receiver SMTP address, TCP port etc.
* Have redundant SMTP server configuration. The SMTP server that you’re using may not be up and running. If mail are critical, consider having some queue functionality in the application that can try to resend mail. One queue functionality would be to use the local windows SMTP service, but this will only work if application run on Windows boxes and the local SMTP service is working.
* Use only valid sender and destination SMTP addresses. If there is NDRs, they should go back to an existing mailbox that someone can monitor and act upon.

There are of course recommendations to Administrators as well.
* Clearly communicate to developers what the rules are for submitting SMTP mail to Exchange. No hardcoded configuration, no anonymous submission etc.
* Add a good name for your SMTP servers, such as ‘smtp.ADdomainname’ for developers to use instead of giving them the real servername or IP. With a standardized name across all applications you can make them use another server when there is need. If you internal Active Directory name is company.local your smtp server name would be SMTP.company.local
* Set up internal MX records for the AD name space. Same advantage as above.
* If you have multiple HUB server, Load balance TCP port 587 across those servers and make applications use SMTP submission port 587 (this is the client receive connector that are default created on Exchange 2007)  instead of the default 25. Don’t load balance port 25 since it will break functionality in Exchange such as authentication.
* Be very careful of what mail you let through to internet, maybe you should block applications to send to Internet on connectors to maintain your good name on Internet. Companies have ended up on various blacklists because developers have built bad SMTP mail or have a buggy application that spray mail across Internet.

There are probably many more options/alternative/thoughts around this, but these are just some that regularly pops up.

OWA authentication and its affect on OWA functionality

You’re probably aware of that you can configure different authentication methods for OWA (Outlook Web Access). But different authentication mechanisms for OWA alter some behavior in OWA.
When you install an Exchange 2007 CAS, OWA is configured with form based authentication (FBA). This gives the end user a HTML form to fill in with username, password and also some configuration on OWA’s behavior.

The checkbox “Use Outlook Web Access Light” gives a light version of OWA with no activeX controls or other IE only features. This is of course a less feature rich version of OWA than if you use IE. Advantage is that is consumes less bytes on the wire and is therefore suitable if you are on a low bandwidth connection. OWA light is also default selected if you use a non IE and cannot be changed.

Now to the interesting part: selection between Public and private computer.
Clicking on the show explanation link doesn’t give any good clues.

This is a public or shared computer. Select this option if you use Outlook Web Access on a public computer. Be sure to log off when you have finished using Outlook Web Access and close all windows to end your session.

This is a private computer. Select this option if you are the only person who uses this computer. Your server will allow a longer period of inactivity before logging you off.

OWA with forms based authentication saves information in a cookie on the client computer. One thing that is stored in the cookie is the idle time before the user is automatically logged off. By selecting Public computer gives the user an idle period of 15 minutes before the cookie expires and the user is logged off. The timeout period for Private computer is 8 hours. CAS is using several encryption keys and cycle them every half of the time out interval so the actual timeout is between 15 to 22.5 minutes and 8 to 12 hours for private computers.

Timeout values can be changed and is configured with registry values in the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA

Value names are “PublicTimeout” and “PrivateTimeout”, both are DWORD and numbers are in minutes.

some usefull links on the subject.
http://technet.microsoft.com/en-us/library/bb123719.aspx
http://technet.microsoft.com/en-us/library/bb124787.aspx
http://technet.microsoft.com/en-us/library/bb124819.aspx

Other behavior that is dependent on the Public/Private computer selection is “File and Data Access”.
With “File and Data access” the administrator can configure what servers and file types are accessible and how users interact with files by using Allow, Block, or Force save options.This gives the administrator a very good control on how files are accessed through OWA. The good part is that all configurations regarding file access in OWA is separate for public and private computer.
This gives the administrator the ability to have different OWA behavior dependent on what user select during OWA logon. for example a user logon with public computer and tries to download a document from a file server, this is blocked by OWA, but if user logon with a private computer option selected the file is successfully downloaded to the client.

Options that can be configured are: access to windows file shares, access to sharepoint document libraries, webready document viewing, direct file access.
You can also set what file types are allowed and what types are not. Very handy and extremely useful, the only hard part is to make users select the correct option, but I guess that is up to information and education.
http://technet.microsoft.com/en-us/library/bb124731.aspx

But what if you don’t want to use Forms Based Authentication?
There are three other standard authentication mechanisms to choose from: Basic, Windows and Digest authentication.
(Configuring Standard Authentication Methods for Outlook Web Access http://technet.microsoft.com/en-us/library/bb125207.aspx)

With Basic authentication you will always get prompted for username and password.

Once logged on, OWA treats this session as private computer regarding to attachment and data file access, but it will not use a cookie on the client to timeout the session and credentials will be cached by the browser until it’s closed or user click on the Log Off link. With the browser caching users credentials a user can use OWA and then point there browser towards another website and then hit back again and enter OWA without typing in any credentials, so it’s important to educate users about closing the browser or hit the Log Off link to secure access to there’s mailbox.

With Digest Authentication you get almost the same behavior as with basic authentication, except that OWA doesn’t know your credentials and cannot authenticate when you try to open a fileshare or a sharepoint document library. There is an exception when this work anyway and that is if you install CAS and Mailbox role on the same server.

With windows integrated authentication you get the same behavior as with Digest authentication except that if your browser is configured to use windows integrated for your CAS server website you will get automatically logged on with the same user as you’re logged on to windows with. This gives user a seamless access to OWA with typing in credentials. Windows Integrated uses the most secure authentication scheme but hopefully you’re forcing use of SSL on CAS website so this should be no problem to use other authentication than windows integrated.

So be careful when you set your authentication scheme on your CAS, more things change than you first might realize.

If you also have an ISA in front of your CAS, the possibilities and complexity raises, but that’s another story I save for later.