When utilizing ISA (in this case, ISA 2006) to publish Outlook Web Access (OWA), there are various options you can choose from in order to authenticate a user. One listener authentication mechanism that is often used is Forms Based Authentication. By default, your ISA form when publishing OWA will look like the following:
As you can see, by default, it asks you for Domain\User name. By going into the listener authentication options, you can specify the default domain that should be specified if the user does not specify a domain. Without specifying this, if the user were to only enter their user name, authentication would fail as it is not passing the domain back to Exchange. By going into the properties of your OWA listener, you will see an Authentication tab.
Because we will be utilizing RSA, we will choose RSA as the method of Authentication utilizing Forms Based. Because Exchange isn’t set to also authenticate to RSA (only ISA), we will need to collect additional information in the form. This allows a user to also enter their AD credentials so after ISA authenticates a user, ISA can still pass back the AD credentials back to Exchange as the Authentication Delegation mechanism using Basic. Selecting to Collect dditional delegation credentials in the form allows you to utilize either Basic, NTLM, or Negotiate as an Authentication Delegation mechanism.
By clicking on Advanced, we can see the section in which we can configure the domain to automatically pass back to Exchange during the Authentication Delegation. Again, a user authenticates from a browser to a web listener and from there, ISA then takes certain information about the user and passes that back to Exchange which is the Authentication Delegation piece.
But, as you can see, the Domain name piece is greyed out. But if you look at the authentication form for ISA when RSA is enabled, you can see it doesn’t ask for the Domain Name.
Now because of this, if a user doesn’t specify to use a different user name which does allow you to enter a domain\username, the authentication delegation piece will fail as the basic authentication mechanism that you will set on Exchange will want a domain\username passed back. So if we can’t set this in ISA, how do we set it? Well, we can actually configure IIS to automatically assume a specific domain to be used if no domain is specified. While IIS6 and IIS7 are very much different, you can actually utilize the Exchange Management Console to set this option which will stamp IIS appropriately (both IIS6 and IIS7.)
The default authentication option for OWA on a CAS is to use Forms Based Authentication and require a user to specify their domain.
If you specify the following option, choose your domain, and click Apply, it will stamp IIS to assume the specified domain name. A user can still specify their domain or not specify it and both will work when authenticating. This should hopefully make you realize that if ISA relays authentication back to IIS on the CAS, that it won’t matter anymore if the domain is specified or not.
But because our ISA Authentication Delegation for our OWA rule will utilize Basic Authentication, we now want to specify Basic Authentication within Exchange for OWA. But don’t worry, even if you change it from the previous setting of Forms Based Authentication with the assumed domain, IIS will still stay stamped properly. So go ahead and choose Basic. You will be prompted to do an IISReset -Noforce. Go ahead and do it after choosing Basic.
So back over to ISA, if we go into our Outlook Rule, we can see the Authentication Delegation set to Basic which it will need to be since that’s what the Authentication option is set to for OWA on our CAS.
So taking everything into account what we did above, what happens is the user authenticates to ISA utilizing a form and specifies their username without the domain, RSA key, and password for their username. When they click Log On to authenticate, ISA will authenticate the user with RSA, and when that passes, ISA will utilize basic authentication due to the authentication delegation being set to basic to pass the username and password they specified (with no domain) back to OWA. Because IIS is stamped to automatically utilize the domain even if it wasn’t specified, authentication will work and the user will be logged into OWA.
The listener is set to RSA, correct? When you set it to All Users, you're essentially bypassing pre-authentication for the listener for those other rules. When you have it set to Authenticated Users, you're forcing the client to perform pre-authentication which would fail due to those services not supporting RSA authentication.
Whenever I bypass pre-authentication for a rule, I always do two things:
1. Set the authentication delegation on the rule to have clients authenticate directly to Exchange.
2. Set it to allow All Users.
Hi Elan, I've run into an issue with creating a second site on the CAS – forms-based authentication is set on the Exchange directory and is required for a 3rd party application and installing a second CAS is not an option at this stage. Going back to using the same web listener – the only way I can get it to work is setting users to All Users on the AS & OA ISA publishing rule. Authenticated Users does not work. Is there a setting I'm missing?
Kind Regards
Una
The listener is set to RSA, correct? When you set it to All Users, you're essentially bypassing pre-authentication for the listener for those other rules. When you have it set to Authenticated Users, you're forcing the client to perform pre-authentication which would fail due to those services not supporting RSA authentication.
Whenever I bypass pre-authentication for a rule, I always do two things:
1. Set the authentication delegation on the rule to have clients authenticate directly to Exchange.
2. Set it to allow All Users.
Thanks for your help Elan, OWA is authenticating to the RSA without the need to specify a domain. I've decided to go the more secure option and purchase a new cert for OWA, hosting it on a new site and leave AS and OA as is using LDAPS for authentication. Kind Regards Una
Yes.
Hi Elan, Thank you for the RSA blog. I have a question re ActiveSync once I've implemented OWA using RSA.
Before I purchase another certificate, I would like to confirm my ActiveSync site will need to change? Because I need a new web listener for ActiveSync I will need a new certificate and site name for ActiveSync? In other words, ActiveSync can no longer use webmail.company.com but would have to be configured for mobile.company.com?
You could use the same listener if you set your rule to not require ISA Pre-Authentication by setting its Authentication Delegation to Allow Clients to Authentication Directly. This will trump listener authentication. Otherwise, yes, you need a new listener with a new certificate.
Thanks for the quick reply. Does this also work if ISA has been installed in a workgroup and not connected to the domain?
Yes
Nope. This is why I did it the way I did it. It sets the necessary information in IIS rather than going in and manually doing it. Personally, this satisfied my needs and didn’t research more into what exactly it did in IIS.
In a single forest, multi-domain environment, Exchange 2003\ IIS 6 could be configured to you ISAPI filters to append the domain to any user authenticating with OWA. You could set a “\” on the domain setting then the IIS Process would look up the correct domain. This was great in that only the username was needed. Are you aware of any additional setting in Exchange 2007 that does the same thing? We are also using ISA 2006 w\SP1, which may also have that capability?
Thanks,
Ed McKinzie
Great article… i use RSA for my OWA, however I am having issues on my ‘Outlook Anywhere’ where if i type my password in once my AD account gets locked. I know its not really the same topic but i can’t figure it out. internally it locks after ‘2 tries’… any idea? I do use the same listner for both ‘Outlook Anywhere’ and ‘OWA’
Sorry, can’t help ya out there. There was a different listener for OA that didn’t use RSA.