Using Workspace ONE's Unified Access Gateway to Protect your OnPremises Exchange Environment

Disclaimer: I am not claiming to be an expert in the recent Microsoft HAFNIUM exploits. 

If you haven't read about them there were several 0-day exploits combined which gave unprecedented access to thousands of On-premises Exchange servers. Everything from installing malware to contents of mailboxes was (still is if your unlatched) up for grabs.  

You can read about it at a few places:

"These vulnerabilities are used as part of an attack chain," Microsoft says. "The initial attack requires the ability to make an untrusted connection to Exchange server port 443. This can be protected against by restricting untrusted connections, or by setting up a VPN to separate the Exchange server from external access. Using this mitigation will only protect against the initial portion of the attack; other portions of the chain can be triggered if an attacker already has access or can convince an administrator to run a malicious file."

Workspace ONE - Extending to protect more of Exchange Server.

This had me thinking of customers I had worked with in the past to deploy Workspace ONE to help protect their On-Premises Exchange.  Majority of customers chose to protect their Exchange ActiveSync endpoint with the Workspace ONE component Secure Email Gateway. It is an ActiveSync proxy that checks if the device is managed before allowing the connection to the Exchange server hosting the EAS endpoint. 




That is a good start but that alone wouldn't of protected against HAFNIUM attack. 

A more thorough approach is to consider the Unified Access Gateway.  This is our DMZ component meant to protect On-Premises resources. It can run multiple services, such as the Secure Email Gateway, VMware Tunnel, and an Authenticated Reverse Proxy.


Microsoft Exchange is made up of a multitude of different client protocols. Protocols such as EAS, OWA, ECP, EWS, Outlook Anywhere and more. 

With the UAG above we can add a layer of protection. 



The Secure Email Gateway service has been around and well documented on docs.vmware.com. VMware Tunnel service is a per-app VPN that works on all Workspace ONE UEM managed devices, and recently there is support on registered (without an MDM agent).  If I'm honest hiding some services behind a VPN doesn't sound very 2021 to me, especially in the work anywhere environment we are in today. However a lot of organizations choose to protect some services behind VPNs. In this case Workspace ONE Tunnel works on macOS, iOS, Android, and Win10 operating systems. It has best in breed security with TLS Mutual AuthN per-app VPN (as opposed to device wide), and a great user experience with certificate life cycle provided by UEM. 

A strategy some might take are managed devices, which are trusted by the organization, are allowed to use the thick clients to sync and have offline copies of mail. For this the SEG service takes care of mobile clients, and VMware Tunnel works with macOS and Win10 for Outlook on their respected operating systems. 

Then we need to still provide basic mail, contacts, and calendar for folks who need to check mail from home without access to a work managed asset. Enter OWA.  This web version even has some basic data loss prevention settings by utilizing Outlook Web Mailbox Policy. 

This is where we can utilize the UAG's Reverse Proxy feature. Not just a Reverse Proxy which translates owa.acme.com to an internal mail server but rather Authenticated Reverse Proxy.  This means before the user can get to any internal content or internal IP the user must be authenticated.  This could of helped deter the hackers in the HAFNIUM 0-day exploits.  Without the ability to access Exchange server unless properly authenticated a lot of these exploits would of been impossible to carry out unless somewhere else the network was compromised. 

Let's dive into what this would look like end to end.



  • UAG protects the reverse proxy endpoint by ensuring only an authorized session is allowed.
  • The UAG accepts SAML assertions from Workspace ONE Access 
  • Workspace ONE Intelligent Hub is the one stop shop for user access to all applications.
  • Workspace ONE can protect the launch of the 'OWA' application with any combination of authentication. 
  • The UAG takes the UPN from the SAML Assertion from Workspace ONE Access, and reaches out to the KDC for a kerberos ticket for single sign-on into OWA.

Consider this a defense in depth approach. We first validate the user is who they say they are with Workspace ONE Access or even your own 3rd party IdP. This step is important, as it's the main control between the internet and your Exchange server. I would highly recommend this be protected with MFA as an additional layer of protection. The old saying something is better than nothing is mostly true but MFA based on SMS codes has been proven to be weak and recently TOTP codes have also been compromised. Try layering in a Login Risk Score to add that additional logic of historical patterns might help protect your logins from unexpected activity. 

Once the user clicks the OWA catalog application in Workspace ONE, a SAML assertion is generated with that users claims and which reverse proxy on the UAG they are authorized to open. The UAG validates the SAML assertion is from a trusted IdP and initiates the reverse proxy. The session is launched from the client browser, terminated on the UAG, and the UAG opens a session on to the OWA endpoint. 



For more information see:
  • https://techzone.vmware.com/configuring-web-reverse-proxy-identity-bridging-vmware-unified-access-gateway-vmware-workspace-one-operational-tutorial#_270434





Comments

  1. Hi Joe,

    First of all, thank you for great article!

    Just want to ask about one specific part of configuration. When talking about identity bridging to OWA, whole concept absolutely makes sense but please tell have you actually ever tried to configure KCD for OWA? If yes, would you please tell if this is correct approach:

    - Create ASA (Alternate Service Account) credentials for Exchange as computer account in Active Directory

    - Deploy the ASA credential to the Exchange server (Using the RollAlternateserviceAccountCredential.ps1)

    - Associate Exchange (OWA) SPN (Service Principal Name) with the ASA credential computer account in Active Directory

    - On Exchange ECP console, configure "Integrated Windows Authentication" as authentication method for OWA virtual directory

    - iis reset

    - Export keytab file for ASA computer account in Active Directory (UAG will be configured with that keytab)

    Are these steps correct approach or is some important step missing here?

    I know this question is actually more for Microsoft specialist but if you already know how to do it, I believe it would be very helpful for many others reading your blog, thanks :)

    ReplyDelete
  2. Notes I have:
    - IIS - Enable Windows Authentication, add Negotiate as a Provider, if Negotiate:Kerberos uncheck Kernal mode
    - Create ASA (new computer object) for cas array (OWA)
    - Set ASA to the individual CAS Servers: \RollAlternateserviceAccountPassword.ps1 -ToSpecificServers server01,
    server02 -GenerateNewPasswordFor AIRWLAB\CASARRAY-ASA$ -Verbose
    - Create the Target SPN for CAS Servers using setspn command (notes: 1. ASA Account – if you have multiple load balanced CAS servers or a CAS
    Array and you completed step 3.2.1
    2. Service Account if the application pool is running as a domain account.
    3. Machine Name if the application pool is running as Local System/Network
    Service)
    - Setspn -S {HTTP service} WEBAPPSERVERNAME (Setspn -S HTTP/server1.virtualjpr.com EXCH)
    - Create a delegate user in AD
    - Create keytab (ktpass /princ HOST/uagkerberos@virtualjpr.LOCAL /ptype
    KRB5_NT_PRINCIPAL /pass * /out C:\Temp\kerberos.keytab /mapuser uagkerberos
    /crypto All )
    - Define SPN delegation on delegate user (in the setspn step: HTTP/server1.virtualjpr.com)
    - the rest is UAG and WS1 steps in the links I provided.

    ReplyDelete
    Replies
    1. Thanks for provided notes. I did manage to setup KCD for OWA - steps are in next comment.

      Delete
  3. - Create ASA (new computer object in AD) for Exchange array (OWA) and set encryption type to "28"

    - Set ASA to the first Exchange node with .ps1 script and let script generate new password:
    .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer exch01.ws1.local -GenerateNewPasswordFor WS1\ASA$

    - Set ASA to the second Exchange node (copy from first Exchange node):
    .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer exch02.ws1.local -CopyFrom exch01.ws1.local

    - Set Service Principal Name for ASA machine object (for example):
    Setspn -S HTTP/webmail.virtualjpr.com WS1\ASA$

    - Create new user account for delegation and also set SPN for him:
    Setspn -S HTTP/serviceaccount WS1\serviceaccount

    - On serviceaccount - configure delegation to ASA SPN

    - Login to Exchange ECP console for each Exchnage node, and set authentication methods to "Integrated Windows Authentication" + "Basic" (optional) for OWA and ECP console

    - Login to each Exchange node and stop relevant services:

    net stop was /y

    - Start service and wait for a few minutes to be sure everything is up

    net start w3svc

    - Create keytab file for serviceaccount:

    ktpass /princ HTTP/serviceaccount@WS1.LOCAL /mapuser serviceaccount@WS1.LOCAL /pass * /crypto all /ptype KRB5_NT_PRINCIPAL /out C:\owa.keytab

    - Pick your keytab and configure UAG for identity bridging

    Note: Tested with Exchange 2016 CU20 and UAG 3.10

    ReplyDelete
    Replies
    1. Excellent thank you for sharing. Glad this blog helped at least 1 person. :)

      Delete
    2. Great blog, will def follow! :)

      Delete

Post a Comment