• Skip to main content
  • Skip to secondary menu
  • Skip to primary sidebar
  • Skip to footer
  • Home
  • Disclaimer & Policy

Elan Shudnow's Blog

MVP Logo
  • Azure
  • Exchange
  • Lync

Exchange 2007 OWA via ISA RSA – Authentication Delegation

July 1, 2009 by Elan Shudnow 14 Comments

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.

Share this:

  • Twitter
  • LinkedIn
  • Reddit

Filed Under: Exchange Tagged With: Exchange, ISA

Reader Interactions

Comments

  1. Elan Shudnow says

    October 9, 2009 at 2:10 am

    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.

    Reply
  2. Una says

    October 6, 2009 at 12:54 am

    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

    Reply
    • Elan Shudnow says

      October 9, 2009 at 2:10 am

      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.

      Reply
  3. Una says

    October 2, 2009 at 12:16 am

    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

    Reply
  4. Elan Shudnow says

    September 30, 2009 at 8:12 pm

    Yes.

    Reply
  5. Una says

    September 29, 2009 at 8:53 pm

    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?

    Reply
    • Elan Shudnow says

      September 29, 2009 at 11:46 pm

      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.

      Reply
      • Una says

        September 30, 2009 at 4:42 am

        Thanks for the quick reply. Does this also work if ISA has been installed in a workgroup and not connected to the domain?

        Reply
        • Elan Shudnow says

          September 30, 2009 at 8:13 pm

          Yes

          Reply
  6. Elan Shudnow says

    August 3, 2009 at 3:32 pm

    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.

    Reply
  7. Ed McKinzie says

    August 3, 2009 at 12:55 pm

    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

    Reply
  8. Zabulon says

    July 9, 2009 at 1:46 pm

    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’

    Reply
    • Elan Shudnow says

      July 13, 2009 at 1:02 pm

      Sorry, can’t help ya out there. There was a different listener for OA that didn’t use RSA.

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

  • LinkedIn
  • RSS
  • Twitter
  • YouTube

More to See

Azure Event Grid and Serverless PowerShell Functions – Part 1

March 16, 2020 By Elan Shudnow

Retrieving Activity Log Data from Azure Log Analytics – Part 3

March 6, 2020 By Elan Shudnow

Retrieving Activity Log Data from Azure Log Analytics – Part 2

March 6, 2020 By Elan Shudnow

Retrieving Activity Log Data from Azure Log Analytics – Part 1

March 5, 2020 By Elan Shudnow

Tags

ACR Always Encrypted Ansible Azure Azure AD Connect Azure Application Gateway Azure Disk Encryption Azure Firewall Azure Key Vault Azure Load Balancer Azure Monitor Azure Web App Backup Exec CCR CDN DevOps Docker DPM Event Grid Exchange Exchange 2010 Exchange Online Forefront Function App Hyper-V ISA iSCSI Log Analytics Logic App Lync Management Groups NLB OCS Office Office 365 Personal PowerShell RBAC SCOM SQL Storage Accounts Symantec Virtual Machines Windows Server 2008 Windows Server 2008 R2

Footer

About Me

Chicagoland consultant focused on Azure IaaS, PaaS, DevOps, Ansible, Terraform, ARM and Powershell.

Previously a 6x Microsoft MVP in Exchange Server then Lync Server.

My hobbies include watching sports (Baseball, Football and Hockey) and participating in my 14 year old Stepson’s sports.

Recent

  • Azure Event Grid and Serverless PowerShell Functions – Part 2
  • Azure Event Grid and Serverless PowerShell Functions – Part 1
  • Retrieving Activity Log Data from Azure Log Analytics – Part 3
  • Retrieving Activity Log Data from Azure Log Analytics – Part 2
  • Retrieving Activity Log Data from Azure Log Analytics – Part 1

Search

Tags

ACR Always Encrypted Ansible Azure Azure AD Connect Azure Application Gateway Azure Disk Encryption Azure Firewall Azure Key Vault Azure Load Balancer Azure Monitor Azure Web App Backup Exec CCR CDN DevOps Docker DPM Event Grid Exchange Exchange 2010 Exchange Online Forefront Function App Hyper-V ISA iSCSI Log Analytics Logic App Lync Management Groups NLB OCS Office Office 365 Personal PowerShell RBAC SCOM SQL Storage Accounts Symantec Virtual Machines Windows Server 2008 Windows Server 2008 R2

Copyright © 2021 · Magazine Pro on Genesis Framework · WordPress · Log in