Welcome to the four part lab (1/4) regarding implementing ”Zero Trust”, or identity perimeter-ish controls for your’re hybrid environment:

• First part is about unifying access controls for cloud-and on prem users (this part)
• Second part is hardening of the remaining on-prem entry vectors
• Third part is hardening of the remaining cloud entry vectors
• Fourth part is about hardening and monitoring – what happens after authentication and authorization have taken place

Hybrid Modern Authentication + Kerberos Constrained Delegation

One of the most understated, and welcome enhancements introduced lately for Hybrid setups, is the so called ”Hybrid Modern Authentication” – It mostly fixes the problem, of having mix set of users with Legacy Authentication and modern authentication in hybrid environment – Example an environment where all the mailboxes are in on-prem (for compliance reasons) but, other services are consumed from Cloud.

What I mean by mostly, is that I noticed the documentation for HMA left out the Outlook Web Access and ECP out of the possibilities

Exchange

No Oauth for OWA? No problem

”Full blown HMA”  with Azure AD + KEMP

Benefits?

• You get to protect on-prem OWA with Conditional Access , and users get the SSO benefits of Azure AD Device Login (HDJ, Registration and similar options) – besides MAPI,EWS,ACTIVESYNC and OAB

OWA Azure AD Login

(Click pictures to open gallery view)

Outlook Hybrid Modern Authentication 

(Click pictures to open gallery view)

• You get to see all Exchange On-prem logins on Azure AD
  (Click pictures to open gallery view)

• 

• 

• 

• 

• You have the same 2FA experience for on-prem, and cloud mailbox users
• Unified policies based on the use case for both on-prem and cloud mailbox users
• You get Identity protection for on-prem users, and on-prem Apps as well

Configuration

Important configuration notes

• Understand how SPN’s work in Azure AD and Active Directory
  
  • I wanted to ensure, that SPN for OWA doesn’t end-up in Exchange Online list SPN’s for Oauth2 relying partys, so I ensured that OWA has its own FQDN which is later used processing of KCD

• Customize KEMP SAML SP to parse Identity from custom Azure AD attribute
  • I had to do some input/output testing to figure out how KEMP creates KCD attributes from SAML assertion http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

• KEMP is unable to parse the domain from UPN, so its that important the SSO namespace has name that is searchable in the AD Domain

ssomgr: #812# auth_saml_post: SAML Response verified! - redirect to https://sp.dewi.red/ 
 ssomgr: #812# >>add_user():  ts: 1549182167 [age=36]  type: 6  user: joosua@ff00.info  samAccName:   host: 192.168.1.1  domain: default domain [AD02.DEWI.RED] for VS[11]
167 [age=36]  type: 6  user: joosua@ff00.info  samAccName:   host: 192.168.1.1  domain: AD02.DEWI.RED  cookie: 66ac2548acb92ee3796e324e6d392362  failed_auths: 0  lockout: 0  tout: type:900[1] 
 ssomgr: #16972# kcd_reauth_thread: KCD reauth for SAML, user[joosua@ff00.info]
 ssomgr: #16972# baseUserName: basename=|joosua|
 ssomgr: #16972# >>> kcd_get_user_ticket
 ssomgr: #16972# >>>resolve_destination_address: Attempt to resolve destination [192.168.2.7][2]
 ssomgr: #16972# <<>> get_impersonator_cred_handle
 ssomgr: #16972# get_impersonator_cred_handle: /tmp/kerberos_domain_init_done: 0 
 ssomgr: #16972# >>> get_impersonator_cred_handle - handle=0x70c530
 ssomgr: #16972# kcd_get_user_ticket: Get a ticket on behalf of user joosua
 ssomgr: #16972# kcd_get_user_ticket: Credentials aquired
 ssomgr: #16972# Proxy name: [KEMP_KCD@AD02.DEWI.RED] 
 ssomgr: #16972# Target name: [http/sp.dewi.red@AD02.DEWI.RED] 
 ssomgr: #16972# Delegated name: [joosua@AD02.DEWI.RED] 
 ssomgr: #16972# Delegated mech: [{ 1 2 840 113554 1 2 2 }] 
 ssomgr: #16972# encode_ticket: sz=1982 ticket=0x7ffd79b750a0 len=65536 buf_sz=65536

Exchange

• Configure HMA (and it’s prerequisites)

I will go into hardening on a next blog – Nonetheless I highlight that I disabled already for MAPI, ActiveSync, OAB some of the legacy authentication options for testing.

Active Directory

• I am not going to delve into Exchange, DNS and AD Namespaces here, nonetheless its good to understand, that SPN’s and FQDN’s are deeply in play here enabling how Azure AD authentication can be extended to on-premises apps

• Create Service Account for KEMP_KCD and assign the delegation for SPN’s
• We will take an new look into this part the second blog

Azure AD

• Configure SSO for OWA in Azure AD
  
  • Use the Service Principal Name as Entity ID
  • Download certificate and XML to be used KEMP configuration SSO config
  • Implement user assignment if you want to have additional layering of ACL between AAD and OWA

• Create Conditional Access Policy for Exchange and OWA

KEMP

KEMP

Attach the KCD account to Client Side configuration in SSO settings

• Ensure that reverse resolution for IP to DNS name works

See it in action!

”OAuth Parlance”

• For anyone curious I’ve attached the initial flow type example for ActiveSync below with IOS accounts app
• • These initial flows happen before application starts to mostly work with grant_type=refresh token

• 

• 

• 

{
   "aud": "https://tps.dewi.red",
   "iss": "https://sts.windows.net/7fde6064-17a0-4c0e-87d6-19883001bd0d/",
   "iat": 1549180035,
   "nbf": 1549180035,
   "exp": 1549183935,
   "acct": 0,
   "acr": "1",
   "aio": "AVQAq/8KAAAAZt/xl2vYwIQrhcwUYV+BU4WdPVl3S5fXM8tGFmrS990ceaP+ylA0lNP24dVQjPM9l0hKmhmLEESy0iaokgeVcXWfZ5V2KpEETwOa+CYBzR8=",
   "amr": [
     "pwd",
     "mfa"
   ],
   "app_displayname": "iOS Accounts",
   "appid": "f8d98a96-0999-43f5-8af3-69971c7bb423",
   "appidacr": "0",
   "enfpolids": [],
   "family_name": "santasalo",
   "given_name": "joosua",
   "ipaddr": "62.78.150.57",
   "name": "joosua santasalo",
   "oid": "7b01cbef-1b79-4eaf-8862-b8e27e955e19",
   "onprem_sid": "S-1-5-21-621967805-835074083-177589206-1145",
   "puid": "100320003A4286E4",
   "scp": "EWS.AccessAsUser.All",
   "sid": "a6d45091-a808-4415-a49c-83768ce94208",
   "sub": "G0G5xfi7EMTpIqv6RWk9LL2hLobO-3ji1NA1tz3eS80",
   "tid": "7fde6064-17a0-4c0e-87d6-19883001bd0d",
   "unique_name": "joosua@ff00.info",
   "upn": "joosua@ff00.info",
   "uti": "tyDmP9YOIkSJ6CqBymQRAA",
   "ver": "1.0"
 }

Stay tuned for next part (Hardening the setup)

Br, Joosua