AzureAD

Azure AD Application Proxy – SSO and Authorization notes from the field

Posted on by Joosua Santasalo

This blog attempts to capture some of the Single Sign-On and Authorization scenarios I’ve dealt with during my extensive tenure with Azure AD Application proxy deployments.

To keep this blog short there is no description of what Azure AD Application Proxy is generally. More information can be found here

  • AAD SSO Column in the table indicates whether Single Sign-On setting on Azure AD Enterprise Application is enabled or disabled
  • Native Clients in the following table assumes scenario where browser-like features (web view etc) are only used to perform subset of functions, such as authenticating user to Azure AD. All other calls are authorized to Azure AD Application via the usage of Access Tokens passed in Authorization Header
    • For example: The native app may not use cookies to hold session persistence, but rather refresh token stored in the device
    • Some native clients rely completely on running browser inside the app, or open external browser (payment views etc). In these scenarios the application may support similar option as described in the second column (2 Browser)


Back-end Protocol
AAD SSO1 Native Client 2 Browser
SAML – WS/FED (SSO)*Enabled:SAML / or Disabled*No – At least when the most common binding: (Redirect -> POST) is used
Yes – 1.Further reading 2.Source
Header Based Authentication against back-end APIDisabledYes – With Azure API management using JWT_Bearer Grant Yes – With Azure API management using JWT_Bearer Grant (Note this solution is not for rendering browser views. To render browser view from API response additional client side rendering is required
OAuth2 / OIDC Disabled No, unless the application is using web-view that maintains the session to Azure AD (source) Yes – While existing Azure AD session is maintained within browser. Fetch/XHR, or redirect based client can make requests to the back-end app, which can then validate tokens in Authorization Bearer scenario (source)
Header Based Authentication using PingAccessEnabled:Header-BasedNot tested – Probably? (Refer to the documentation) Not tested – Probably? (Refer to the documentation)
Windows integrated Authentication / SPNEGO * * Enabled:Windows Integrated Authentication
Yes – Kerberos Constrained Delegation by the App Proxy Agent is transparent to the client		 Yes – Kerberos Constrained Delegation by the App Proxy Agent is transparent to the client
Basic / NTLM Authentication  * * * Disabled No – Authorization header is reserved for Bearer Tokens, which App Proxy Consumes Yes – While existing Azure AD session is maintained within browser, Basic Authentication can be used. NTLM can be used as well, applies also to WIA scenario when WIA fallbacks to NTLM
SOAP API (U/P)Disabled
Yes – When credentials are passed as part of body, and authorization header contains the Bearer Token		 Yes – When credentials are passed as part of body, and authorization header contains the Bearer Token
Client CertificateNANo No

Clarifications

  • * Existing IDP Session
    • You could also have specified another Azure AD application separate from the App Proxy Enterprise Application. The SSO works regardless of the SSO setting, when the application uses sames IDP which the user has existing session on.
  • * * About SPNEGO [Source]
    • ”If you configure a connector machine for SPNEGO, make sure that all other connectors in that Connector group are also configured with SPNEGO. Applications expecting standard KCD should be routed through other connectors that are not configured for SPNEGO ”
  • * * * Compound Authorization (in some cases Double authentication)
    • First Authorization: Azure AD Consumes the Authorization header
      • While Sending additional Bearer token in other than Authorization header, or in body payload
      • Or While Sending additional Credentials in other than Authorization header, or in body payload
      • Sequentially (after) challenged by the back-end app running in browser session

Good to know

  • Native API clients using AAD Pre-authentication
    • With Native Clients Forwarding JWT tokens to back-end service doesn’t work unless the Native client is calling Azure AD App Proxy from webview like representation or pure browser
  • Only user identities can passed through application having Azure AD pre-authentication enabled
    • For example Application identity (Client Credentials Flow) doesn’t work with Azure AD App Proxy Applications, unless Compound Authorization is used
    • Apps can still work in chain (On-Behalf-of-Flow for example) as long as the identity being delegated is user identity
  • If you have Windows Authentication enabled in the Application, ensure the deployment scenario supports Kerberos Constrained Delegation, and the Azure AD App Proxy agent can act as delegating party to the SPN.
  • While Mutual TLS authentication isn’t supported features such as require device compliance from and other Client recognizing options are available when combined with Conditional Access.
  • There are also other scenarios which I may cover in another blog post
    • Using a mix of pre-authenticated and pass-trough Azure AD Applications
    • Linked applications
    • Password-based

Further reading

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-single-sign-on-with-kcd

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-for-claims-aware-applications

If you find any discrepancies (errors etc) with the information on the table just dm me at @santasalojoosua, or post question to this blog, and I shall correct it /explain it.

Deep Diver – Azure AD Identity Protection (IPC) Alerts

Posted on by Sami Lamppu

This blog is all about Azure AD Identity Protection alerts (referred to provider name ”IPC” later on the blog post) in the Microsoft cloud ecosystem.

If you want to read how IPC works I encourage you to read my blog post or navigate straight to docs.microsoft.com.

IPC is an Azure AD P2 feature that has been in general availability mode for approx. three years. Earlier this year Microsoft did ”refresh” for IPC and added new detection capabilities and enhanced UI. Azure AD P2 feature means that it’s available in most expensive license packages.

You will get a taste of its features even with a free Azure AD license but all the cool features are included in AAD P2. Practically, IPC calculates user risk (online/offline) based on Machine Learning & AI and makes decisions based on policies, is user login approved, is MFA or password change needed or is user sign-in blocked.

Gimme The Alerts – Where are Those?

Azure AD Identity Protection (IPC) is a provider for multiple security solutions which means that alerts triggered in IPC can be found from multiple places (list below). Let’s have a closer look.

  • Azure AD Identity Protection blade
  • Intelligent Security Graph (ISG)
  • Azure Sentinel
  • Cloud App Security (MCAS)
  • Azure Security Center
  • Microsoft Threat Protection suite (MTP)
  • PowerShell for management

Azure AD – Identity Protection Blade

Identity Protection UI resides in Azure AD where investigation and mitigations can be done. Btw, check my demo environment Identity Secure Score, 237 out of 265. Quite impressive even I say it myself 🙂

If a risk is detected admins (or dedicated email distribution list) will receive an alert as seen below. When a link is clicked, the person who received the email will land to the Identity Protection portal in Azure AD.

Intelligent Security Graph (ISG) aka Microsoft Security Graph

Identity Provider is one of the ISG providers, the full list of available providers at the time of writing can be found here. In pictures below are ISG high-level architecture and export from ISG alert from my tenant. In the latter one, you can see the provider highlighted with yellow color.

Microsoft Intelligent Security Graph (ISG)
ISG Alert – Provider IPC

Azure Sentinel

If you are using Azure Sentinel (a cloud-native SIEM which is a hot topic right now) and you have configured data connectors, and activated rule properly you will get IPC alerts to Azure Sentinel as incidents.

Azure Sentinel Identity Protection template rule basically raises an incident if an alert is generated in IPC.

Microsoft Cloud App Security

The IPC alert is also found from MCAS. As you can see from the picture below MCAS adds information to the alert and makes it more useful for the investigation. Btw, MCAS is the best solution in the Microsoft ecosystem to investigate internal user suspicious activity and behavior. If you are using it, I highly encourage you to get familiar with it and especially to UEBA capabilities.

I’m sold to it, totally:) But, I’m looking it only from the technical perspective, not from a financial perspective.

Azure Security Center (ASC)

IPC alerts are also found from Azure Security Center. ASC also provides a geolocation map which can be very useful to get a bigger picture of the attack.

Microsoft Threat Protection Suite (MTP)

MTP was just launched to public preview. Unfortunately, I don’t have such an environment available where it’s enabled. In a nutshell, it is a pre -and post-breach enterprise defense suite that natively integrates across endpoints, protecting:

  • Endpoints with Microsoft Defender ATP
  • Email and collaboration with Office 365 ATP
  • Identities with Azure ATP and Azure AD Identity Protection
  • Applications with Microsoft Cloud App security

More information from here and here.

PowerShell

This has slipped out of my radar totally. Microsoft released the PowerShell module for Microsoft Security Graph in April 2019. You can read more about it from here. In a nutshell, you need to do the following:

  • PowerShell v5 or above
  • Register App to Azure AD
  • User this URI: urn:ietf:wg:oauth:2.0:oob, it’s needed for desktop app redirect to work
  • Configure permissions to the App ( SecurityEvents.ReadWrite.All )
  • Grant Admin consent to the App
  • Install the module
  • Run and enjoy 🙂

In the Technet blog, there are multiple questions about App registration guidance. My 2cents:

  • When registering the App, grant API permissions for delegated mode (interactive login is used)
  • Grant SecurityEvents.Read.All & SecurityEvents.ReadWrite.All permissions to the App
  • Grant admin consent
  • When running the PowerShell – use you userprincipalName as username and AppID as password.

Using the module

Login with userPrincipalName + App ID. After the initial login, the modern authentication prompt appears (it’s encrypted by Finnish) and interactive login is processed together with Conditional Access policies.

Managing the Alerts

MicrosoftGraphSecurity module has following available commands

With Get-GraphSecurityAlert you can get all alerts from the ISG with Identity Protection alerts included.

Secure Score information is also available with Get-GraphSecuritySecureScore command.

Set ISG Alert

ISG alerts can be managed via PowerShell with Set-MicrosoftGraphSecurity cmdlet. Extremely useful if the alerts are sent to SIEM. The downside is that there isn’t any integration to the backends (providers).

Note: This means that even you update the alert status in ISG it will remain open in the ISG providers (Identity Protection, Cloud App Security etc.)

Summary

The Microsoft cloud ecosystem is huge and organizations have multiple security solutions available by default. Keep in mind that most of the advanced tools (including IPC, MCAS) require E5/A5, G5, P2 license. As seen above, synergy advantages are obvious.

What solutions to use is more a matter of cloud logging and monitoring strategy. From which sources you want to have an audit trail & events sent and to where? Where are you processing all the alerts, in SIEM or directly in Security solutions? And lastly, how operations are built around the solutions.

Until next time!

Cheat sheet: AD FS and Azure AD Hybrid Conditional Access

Posted on by Joosua Santasalo

What is so great about AD FS 2016 + Azure AD Hybrid Device Join?

  • You get absolutely the best SSO experience with it – In fact it’s preferred over any 1 of the existing methods in terms of the use experience when used with W10 (Standard licensing)ADFSss
  • It works as seamless second factor for Azure AD Applications with Azure AD Conditional Access (AAD P1)
  • You can use it as seamless factor for your on-premises federations by requiring the presence of trusted claims in the request. In the absence of these trusted claims you can fall-back into standard 2-Factor Auth (AAD P1)
  • Hybrid Device Registration with AD FS is not dependent on AAD Connect to enable SSO on the device (AAD P1)
    • AAD connect Synchronization links the device to corresponding Azure Device, once the on-prem device satisfies required filter conditions in metaverse

Title

  1. Please note, that Azure AD join is not something that replaces initial Sign-on modes, it still requires that initial sign-in has taken place before the device is paired with Azure AD to obtain SSO experience based on the PRT tokens

Major tips to get it right

Do I need any on-premises pointing device registration records to accomplish the scenario presented?

  • Absolutely none – In fact, if you look at the Device Registration Logs, you will find out that it explicitly states that local endpoints will NOT be enabled

DRS

DRS is in Hybrid AAD mode, registration endpoints will NOT be enabled.

Do I need to enable Device Authentication in the Authentication policies for Intra/extranet? 

No – The device authentication claims in this scenario are emitted as part of Windows, or Forms authentication. This happens with the AD DS Device Object and its properties in conjunction with Primary Refresh Token, which is accounted for in the Windows Login process,

  • While you need to have Device Registration enabled, you don’t need to enable device authentication as method in the authentication policies.

AADDS2

AADDS3

  • If you look at the claims with forms authentication and Extranet login, you will see the Device Claims that were emitted as part of the FormsAuthentication

Xray

Xray2

Take note of the PRT claim – You wont find it in the RP’s login trace pipeline, because it’s formed at Windows Login

If you want to peek under the hood, and understand how these DRS claims end up in the same pipeline, then check DRS trace logs

Here DRS is checking for device match

DRS2

”GetDeviceKeyFromKeyCredLink” &  GetDevice(ID,DC): 

 

 

 

Is it multi-factor authentication method?

Not in the context of AD FS, but conceptually it’s Multifactor Auth (one factor more added to the on-going authentication sequence)

Is there single important action that help will me in achieving the goal?

  • Yes, start with the newest version of the AAD Connect. It now supports both AAD HDJ and Writeback configuration during the setup without manual scripts AAD Connect 1.1.819.0
    • (DISCLAIMER: Do always review the changes made to AAD connect, and estimate if there is any change existing Relying Party trusts or sync related settings before proceeding)

What should I confirm before debugging anything else?

Coarse flow description

Example policy using Device-Based Conditional Access

1. Requiring presence of ’known device’ when accessing on-prem federations

  • This policy will ensure, that unknown devices will have to perform standard multi-factor authentication, whereas known devices will be granted access based on the presence of the ’isknown’ claim with value=True

AADDS34

Do I need Web Application Proxy

In my experience not, if you have capable reverse proxy, and opt for the Azure AD joined Domain devices. For Example KEMP VLM that can impersonate WAP for most of the features, and forward IP and Proxy information to AD FS via the use of headers1

This would have been different with the non hybrid device registration which requires that SSL is terminated at the WAP's directly

Extra stuff:

  1. One very welcome addition is, that the shared W10 and Server 2016 Devices don’t reserve this feature to only single user. Thus you get for example in remote desktop installation the Azure AD join SSO for multiple users.

LoginLogin2

Br, Joosua!

 

Creating Custom Multi-Factor Authentication Client with Azure Functions

Posted on by Joosua Santasalo

I used to do a quite a bit of availability testing in past, but never got to test how virtual login flows would work with transient (non-persistent) one time passwords.

It wasn’t until recently I got assignment to do something that monitors MFA system. During the assignment I stumbled on something called PyOTP, which pairs quite well with Azure functions. After the assignment was over I decided to write this blog to share some details:

This blog covers creation of MFA client using Azure Functions and PYOTP.  If you’re interested how One-Time-Passwords do work, then check the RFC’s below for in depth information:

Disclaimer: The information in this weblog is provided “AS IS” with no warranties and confers no rights.

How does it work?

Prerequisites:

  1. Azure Subscription with possibility of creating Azure Functions
  2. Your MFA implementation is compatible with RFC4226 and RFC6238
    • Examples Microsoft MFA, RCdevs OpenOTP and many others

Azure Functions

  • Create New Azure Function (consumption plan will suffice)
  • Locate platform features, and select Advanced Tools (Kudu)

Locations

Platform features

  • Update Python version to 3.5.2 using guide Azure Functions Python
    • I opted to install ’python-3.5.2-embed-win32’
      • Bit earlier or later versions, I suppose do work just as well
    • Drag & Drop the correct packet to d:\home\site\tools (It will unzip automatically)

AzureFunctions2

Drag&Drop

PYOTP

This part covers installation of PyOTP, which is a Python library for generating and verifying one-time passwords. /Read more @ https://github.com/pyotp/pyotp 

  • Install PYOTP with Powershell, or CMD console in KUDU

Python -m pip install pyotp --target=d:\home\site\tools

PIP 2

installing PyOTP

Fetch the key from your MFA solution;

In the example I use Microsoft MFA

  •  Use the URL MFA Enroll
    • Select ’Configure app with notifications’ and take note of the ’Secret Key’

Kuvaesitys vaatii JavaScriptin.

  • Create Python HTTP trigger
    • Remember to toggle ’Experimental Language Support = Enabled’

BlogF

Create new HTTP Trigger

  • Test the function with the ”MFA key” fetched from MFA, and inserted into the code.
    • In production code you might not want to have the secret key in plaintext, for this prototype I opted for the low hanging fruit :)…
import os
import json
import platform
print("Python == ", platform.python_version())
import pyotp
totp = pyotp.TOTP('YourMFAKeyHere')
s = totp.now()
str(s)

response = open(os.environ['res'], 'w')
response.write(s)
response.close()
  • Output should now display the OTP in the response

Funcss

Function editor

Response

Call example

Consuming OTP’s

  • Choose your coding /scripting language and just add simple REST call to it:
    • Get the key to call the function from ’Get function URL’, and implement it to the part of the code where you fetch the OTP, and deliver it for the verification

      PY

      URI for the function

    • if possible, limit the call to only certain range of IP’s (this is not required for this thing to work, but its something you might want to consider)

Below is the snippet of that part where the OTP is delivered to the login form:

  • PowerShell is just too easy, and keeps my from learning new languages :)… so I opted for it (once again) to create the prototype:
$OTP=Invoke-RestMethod -UseBasicParsing -Uri "APIURIHERE" -Method Post
$keys = $OTP -split "" | where {$_ -ne ""}
[Microsoft.VisualBasic.Interaction]::AppActivate($ieProc.Id);Start-Sleep -Seconds 1

foreach ($key in $keys)
{
Start-Sleep -Milliseconds 20
[System.Windows.Forms.SendKeys]::SendWait("{$key}");
}

 

Hope this helps somebody 🙂 – I for sure had a blast doing it!
Br,
Joosua