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
Giving the Zero Trust Treatment for OWA and Exchange On-premises

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

HMA endpoints

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
Azure AD authentication for OWA, Outlook and ActiveSync

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
  • 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 the DNS for the domain is working as intended (no local resolution here)

Remember that Azure AD Token Sign In certificate has to be imported from ”Intermediate Certs”
  • Ensure that reverse resolution for IP to DNS name works
https://support.kemptechnologies.com/hc/en-us/articles/203860275-Kerberos-Constrained-Delegation

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
Initial ActiveSync registration after standard 401 – Request Authorization Code

Initial ActiveSync registration – Get access token in exchange for Authorization Code


Initial ActiveSync registration – Request ActiveSync options with Bearer Token (Access 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

0 comments on “Lab: Zero Trust Exchange 2016 with AAD oAuth2 and SAML (KEMP)

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out /  Muuta )

Google photo

Olet kommentoimassa Google -tilin nimissä. Log Out /  Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s

%d bloggaajaa tykkää tästä: