Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 1: How OWA Authentication Really Works

Summary: OWA authentication is easier to troubleshoot once the frontend, Exchange authentication layer, HttpProxy, and backend are treated as separate parts of the same request. This first part sets the baseline, shows the main commands, and explains which settings matter before we start changing anything.

Version scope: The behaviors and configurations covered in this series apply to Exchange Server 2019 CU15 and Exchange Server Subscription Edition (SE) RTM. Microsoft states that SE RTM is code-equivalent to Exchange 2019 CU15 apart from the license agreement, product name, and build number. Earlier Exchange versions and later SE cumulative updates are outside the scope unless they are explicitly tested. Microsoft Learn: Exchange Server SE release notes

Why OWA authentication can be misleading

When OWA sign-in fails, the first instinct is often to check the IIS Authentication page and one or two Exchange properties. That is useful, but it does not show the whole flow.

An OWA request normally passes through the Client Access frontend, Exchange authentication logic, HttpProxy, and the backend OWA application. Those layers do not use identical authentication settings.

Browser
  |
  v
Default Web Site\owa        (frontend, HTTPS 443)
  |
  v
Exchange OWA authentication / Client Access
  |
  v
HttpProxy / routing
  |
  v
Exchange Back End\owa      (backend, HTTPS 444)
  |
  v
OWA application / mailbox services

Microsoft describes Client Access services as the front door for client connections. They authenticate incoming connections and normally proxy them to the backend service that owns the active mailbox database. Microsoft Learn: Client Access services

Start with the Exchange OWA baseline

Before changing anything, I capture the OWA authentication settings that matter for troubleshooting.

I use the following command for the baseline:

Get-OwaVirtualDirectory -Identity "EX601\owa (Default Web Site)" |
Format-List FormsAuthentication,BasicAuthentication,WindowsAuthentication,
DigestAuthentication,InternalAuthenticationMethods,
ExternalAuthenticationMethods,LogonFormat,DefaultDomain

Get-OwaVirtualDirectory -Identity "EX601\owa (Default Web Site)" |
Format-List FormsAuthentication,BasicAuthentication,WindowsAuthentication,
DigestAuthentication,InternalAuthenticationMethods,
ExternalAuthenticationMethods,LogonFormat,DefaultDomain

The baseline used in this series showed the following authentication combination:

FormsAuthentication           : True
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
InternalAuthenticationMethods : {Basic, Fba}
ExternalAuthenticationMethods : {Fba}

The two values that usually cause the first question are FormsAuthentication=True and BasicAuthentication=True. They are not contradictory.

With the normal OWA configuration, the user still sees the Exchange forms-based sign-in page. Microsoft also documents that OWA and EAC use Forms-Based Authentication by default and that FBA relies on Basic authentication. Microsoft Learn: Disable Basic authentication on Exchange Server virtual directories

Exchange FBA is not IIS Forms Authentication

This is probably the most important distinction to get right before troubleshooting OWA.

On the frontend OWA application, IIS shows a baseline similar to this:

Anonymous Authentication : Disabled
Basic Authentication     : Enabled
Digest Authentication    : Disabled
Forms Authentication     : Disabled
Windows Authentication   : Disabled

At the same time, Exchange reports:

FormsAuthentication : True

Both are correct. The Forms Authentication feature shown in IIS Manager is the generic IIS/ASP.NET feature. Exchange OWA Forms-Based Authentication is Exchange functionality and is managed through Exchange configuration.

So seeing Forms Authentication = Disabled in IIS Manager does not mean OWA FBA is disabled.

Frontend and backend OWA use different authentication settings

Exchange has two OWA applications involved in the request path:

Default Web Site\owa
Exchange Back End\owa

Microsoft documents different default authentication settings for them. On the frontend OWA virtual directory, IIS Basic authentication is enabled. On the backend OWA virtual directory, Anonymous and Windows Authentication are enabled. Microsoft also states that the backend virtual directories should not normally be configured by the user. Microsoft Learn: Default settings for Exchange virtual directories

This means the following combination is normal:

Frontend OWA
  Basic Authentication   = Enabled
  Windows Authentication = Disabled
  Exchange FBA           = Enabled

Backend OWA
  Anonymous Authentication = Enabled
  Windows Authentication   = Enabled

That also explains why WindowsAuthentication=False on the OWA virtual directory does not mean Windows Authentication is absent from the entire OWA request path. The frontend and backend are separate authentication boundaries.

Check the published OWA URLs separately

I also capture the configured OWA URLs when taking a baseline:

Get-OwaVirtualDirectory -Server EX601 | Format-List Identity,InternalUrl,ExternalUrl

Get-OwaVirtualDirectory -Server EX601 | Format-List Identity,InternalUrl,ExternalUrl

InternalUrl and ExternalUrl are Exchange service configuration values. They are not an IIS hostname allow-list.

For example, a browser can still reach a different OWA hostname when DNS points that name to Exchange, IIS accepts the HTTPS request, the /owa application exists, and the certificate matches. An empty ExternalUrl by itself does not prove that OWA cannot be reached through an externally published namespace.

Also, manually browsing to an OWA URL does not require Autodiscover. The user already supplied the URL to the browser.

What InternalAuthenticationMethods really tells us

The baseline in this series showed:

InternalAuthenticationMethods : {Basic, Fba}

This is useful configuration information, but it is not runtime proof of what happened in a specific request.

{Basic, Fba} does not mean every OWA login performs Basic authentication and then performs FBA as a second user authentication step. In the same way, later seeing {Ntlm, WindowsIntegrated} does not tell us whether a particular client used NTLM or Kerberos.

That difference between configured and actually used becomes important later in the series.

ExternalAuthenticationMethods does not prove Internet exposure

The baseline also showed:

ExternalAuthenticationMethods : {Fba}

This does not prove that OWA is reachable from the Internet. Actual reachability also depends on DNS, firewall rules, NAT, reverse proxy or WAF configuration, load balancers, certificates, and IIS bindings.

I treat this property as Exchange authentication configuration, not as evidence that the service is externally published.

The three logs I want for OWA authentication troubleshooting

Once the configuration baseline is known, I normally follow the request through three log layers.

1. Frontend IIS – W3SVC1

C:\inetpub\logs\LogFiles\W3SVC1

This tells us what reached the frontend: client IP, URI, method, username visible to IIS, HTTP status, User-Agent, and timing information.

2. Exchange HttpProxy OWA logs

C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa

This is one of the most useful places to look because it can expose fields such as AuthenticationType, IsAuthenticated, AuthenticatedUser, HttpStatus, BackEndStatus, TargetServer, and routing information.

3. Backend IIS – W3SVC2

C:\inetpub\logs\LogFiles\W3SVC2

This shows what happened when Exchange reached the backend IIS application on the backend HTTPS site.

For a controlled test, I use the following PowerShell command to watch only new entries in the active backend IIS log and save them at the same time:

Get-Content -Path ((Get-ChildItem "C:\inetpub\logs\LogFiles\W3SVC2\u_ex*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1).FullName) -Tail 0 -Wait |
Tee-Object -FilePath C:\OWA-Backend-Test.log

Get-Content -Path ((Get-ChildItem "C:\inetpub\logs\LogFiles\W3SVC2\u_ex*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1).FullName) -Tail 0 -Wait |
Tee-Object -FilePath C:\OWA-Backend-Test.log

-Tail 0 skips the old lines, -Wait follows new requests, and Tee-Object lets me watch the traffic while also saving the capture. One small caveat: if IIS rolls over to a new log file during the test, Get-Content -Wait continues following the file it originally opened.

A few things I do not assume from a single value

Several OWA troubleshooting clues look more definitive than they really are:

• WindowsAuthentication=False does not mean Windows Authentication is absent from the backend path.
• cs-username=- in an IIS log does not prove Anonymous Authentication was used.
• An HTTP 401 is not always a failed login. It can be part of a Windows Integrated Authentication challenge.
• An HTTP 302 from /owa/auth.owa does not prove the password was accepted.
• Seamless browser SSO does not prove Kerberos was used. NTLM can also be transparent to the user.

Those points are easier to see when we start changing one setting at a time and compare the browser behavior with W3SVC1, HttpProxy, and W3SVC2.

Broader authentication inventory

The focused commands above are enough for this article. When I want a wider OWA authentication dump, I use the single command below. For a broader Client Access URL and authentication inventory, I use Get-ExchangeURLs-v2.ps1.

Get-OwaVirtualDirectory | Format-List *auth*

Get-OwaVirtualDirectory | Format-List *auth*

Next: Forms-Based and Basic Authentication

Part 2, Forms-Based and Basic Authentication – What Really Changes?, moves from observation to controlled frontend changes. It shows what happens when FBA is disabled, when Basic Authentication is used on its own, and when the normal FBA configuration is restored.

Exchange Server OWA Authentication Deep Dive Series

1. Part 1: How OWA Authentication Really Works — current
2. Part 2: Forms-Based and Basic Authentication – What Really Changes? — coming soon
3. Part 3: Frontend vs Backend Authentication – Controlled A/B Tests — coming soon
4. Part 4: Troubleshooting OWA Authentication with IIS and HttpProxy Logs — coming soon
5. Part 5: Managed Availability and OWA Health Probes — coming soon
6. Part 6: Windows Authentication, NTLM, Kerberos, SPNs and SSO — coming soon
7. Part 7: LogonFormat, DefaultDomain and a Practical OWA Authentication Troubleshooting Playbook — coming soon

The remaining titles will become links as those parts are published.

References

• Exchange Server Subscription Edition release notes
• Default settings for Exchange virtual directories
• Client Access services
• Disable Basic authentication on Exchange Server virtual directories
• Set-OwaVirtualDirectory

Ceyhun Kirmizitas

Cloud and infrastructure professional with nearly two decades of experience in enterprise IT environments, spanning public cloud, private cloud, and hybrid architectures.