Don’t try this at home (or how to enable Core Server Remote Management for AD FS GUI)

Posted on by Joosua Santasalo

I’ve been running AD FS on Core servers for some time now, mostly because I like the smaller footprint and centralized management experience.

The smaller footprint also guarantees:

  • That there are less consumed resources
  • That the there is less potential attack surface

But I want my GUI…

ADFSs

The lovely GUI Icon

Sometimes I’ve felt the temptation to just peek into AD FS GUI from remote administration host… only to remember that it’s not possible due to the fact that there is no RSAT for managing AD FS.

Yes this, this is crazy… I am doing it just for the kick of it

CoreSRVR

Scheme

This the part that you definitely shouldn’t do in production, or even in staging if you value your deployment – Nonetheless, I had the temptation to see if I can crack this nut:

  • Install and configure remote management host temporarily as AD FS slave node
  • Disable and stop AD FS service on the remote management node, because you won’t really be needing the service itself, you still need the installation to do management of the primary node

MGMT2

AD FS -> Nobody here, go away!

  • Do a crazy portproxy with NETSH to send port 1500 to primary AD FS node

MGMT3

TCP 1500 has now new destination

  • Enjoy remote management (and maybe some crazy side effects…)

MGMT

Welcome to AD FS management on Core Server!

#Disable and stop the AD FS service on management computer
Get-Service adfssrv | Set-Service -StartupType Disabled; Stop-Service adfssrv
#Do a crazy binding to port 1500
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=1500connectaddress=yourremotehost connectport=1500
#End

Speculation if this was really plausible approach:

Q: Would it just be smarter to have the primary node on GUI enabled server?

A: Pretty much yes

(in this crazy demonstrated approach the only difference, is that you don’t have to have AD FS service running on the remote management host)

Br, Joosua!

Post: Create Logic App for Azure Sentinel/Log Analytics

Posted on by Joosua Santasalo

While I’ve browsed the excellent TechCommunity article about custom connectors, until now I’ve used my own HTTP client implementation to implement connectors against Log Analytics HTTP collector.

All I can say that I am getting seriously spoiled by Logic Apps and the Data Collector Connector…

  • Generate the payload from the app
  • Watch Logic App ingest the payload
  • Check the content from Log Analytics

Br, Joosua

Hardening SalesForce Integration in Azure Logic Apps + Azure Secure Devops Kit Alignment of Logic Apps

Posted on by Joosua Santasalo

What are logic apps? Azure Logic Apps could be described as a convenient way to ”commoditize” input and out operations between multiple resources and API’s within Azure’s 1st party and third party ecosystem.

Where are Logic Apps used? As far as I’ve seen Logic apps are quite popular with architecture modernization projects where the architecture is leaning towards ”pluggable/decoupled” microservice architecture. Logic Apps can consume and push data to 1st and 3rd party services, which sometimes completely obsoletes previous built in API consumer client from a monolithic app – Salesforce integration is good example of this.

Logic apps support parallel flows, and different clauses to proceed, this is just the app I created for testing which works in more linear fashion…

But Isn’t app managed by Microsoft?

The fact that Logic App abstracts lot of the plumbing doesn’t mean it doesn’t have rich set of optional security features. We are exploring common ones for these.

Besides what I present here there is something called Logic Apps ISE (Integrated Security Environment), but that is separate concept, that is tailored to more specific network and data requirements.

While there aren’t particular best practices, this guide attempts to combine some of the AZSK controls and experiences from integrating SF into Logic Apps

But why harden Salesforce side, isn’t this Azure related security configuration

When you have integrations going across environments and clouds, you have to look at the big picture. Especially when the master data that you process is sometimes the data in SalesForce you need to ensure, that source of the data is also protected… Not just where the data is going to

There are similar recommendations on the AZSK kit, but this combines the IP restrictions + and reduces the amount of accounts that have access to the integration in SF side.

Logic App connectors must have minimum required permissions on data source
This ensures that connectors can be used only towards intended actions in the Logic App		 Medium

Checklist

Before proceeding

  • While I am very comfy with building access policies in Azure, I cant claim the same competence in SF -> If you notice something that might cause a disaster, please add comments to this blog, or dm at twitter)
    • hence the Disclaimer: The information in this weblog is provided “AS IS” with no warranties and confers no rights.
    • Do any tests first in a ”NEW” developer account. Don’t ruin your uat/test accounts :)… (Get account here)
    • Make sure that put the IP restrictions under new cloned profile. Not a profile that is currently used
    • For any IP restrictions you set remember to include one IP which you can terminate to (VPN ip etc). This is to ensure that you wont lockout yourself of the SF environment.

Expected result

Once you’ve configured the setup (setup guide below), and tested failure and success behavior the end result you should show failed and success events.

After adding the Logic App IP’s the result should be success.

I can’t emphasize the importance of testing both failing and success behavior when testing any access policy.

Azure Side Configuration

  • Enable Azure Monitoring of the API connection for Azure Control Plane Actions
  • If you want to reduce the output for reader level roles of possibly confidential inputs/outputs in the Logic Apps, then enable Secure Inputs/Outputs setting for the Logic App
  • If your using storage account as part of your logic app flow , ensure storage account logging is enabled
1.0;2020-02-20T07:33:25.0496414Z;PutBlob;Success;201;13;13;authenticated;logicapp;logicapp;blob;"https://logicapp.blob.core.windows.net:443/accounts/Apparel";"/logicapp/accounts/Apparel";

SalesForce Side

  • Profiles in Users
    • Clone, or create new profile for Logic Apps integration.
      • I cloned the System administrator profile, but more granular setup is possibly available by configuring the least privilege permissions for the application
    • Under ’Login IP ranges’ add the Azure Logic App IP ranges that can be found from properties (Include the user IP also which you will use for registering the API in the Logic App)
undefined
  • The SF integration connection ’API connection’ in Azure runs in the context of the user registering the API first time in logic apps
    • There is no point to allow non related users of creating OAuth2 tokens bearing the apps context
  • Oauth Policies in App Manager
    • For ’Permitted users’, change setting to ’Admin approved users are pre-authorized’
    • For ’IP Relaxation’ change setting to ’Enforce IP restrictions’
  • Profiles in App Manager
    • Add the profile created in previous step to profiles
      • This step restricts the users that can use the integration to a custom profile, or system administrators profile
  • In Security ’Session Management’ Ensure IP restrictions aren’t just enforced on login by selecting this setting
    • This setting applies based on the profile IP restriction settings, not globally unless all your profiles have IP login restrictions in place
IP Restrictions setting SF documentation
  • After this revoke all existing user tokens for the app under user settings and Oauth connected Apps
  • Reauthorize the connection
  • Now test the integration to work

Further AZSK recommendations

  • This blog adds the non-Azure side recommendation to hardening guidelines.
  • The following guidelines are where you should start, if you start hardening your Logic Apps
  • if your logging data in Logic Apps (which is recommended to detect misuse and doing debugging: Understand which and what kind of data (PII) etc will be stored/persisted in the logs outside possibly standard access and retention policies.
    • If you want to separate part of the data create separate logic app with secure inputs/outputs, or implement secure inputs/outputs for the current application

Source https://github.com/azsk/DevOpsKit-docs/blob/master/02-Secure-Development/ControlCoverage/Feature/LogicApps.md

LogicApps

Description & Rationale ControlSeverity Automated Fix Script
Multiple Logic Apps should not be deployed in the same resource group unless they trust each other
API Connections contain critical information like credentials/secrets, etc., provided as part of configuration. Logic App can use all API Connections present in the same Resource Group. Thus, Resource Group should be considered as security boundary when threat modeling.		 High Yes No
Logic App connectors must have minimum required permissions on data source
This ensures that connectors can be used only towards intended actions in the Logic App		 Medium No No
All users/identities must be granted minimum required permissions using Role Based Access Control (RBAC)
Granting minimum access by leveraging RBAC feature ensures that users are granted just enough permissions to perform their tasks. This minimizes exposure of the resources in case of user/service account compromise.		 Medium Yes No
If Logic App fires on an HTTP Request (e.g. Request or Webhook) then provide IP ranges for triggers to prevent unauthorized access
Specifying the IP range ensures that the triggers can be invoked only from a restricted set of endpoints.		 High Yes No
Must provide IP ranges for contents to prevent unauthorized access to inputs/outputs data of Logic App run history
Using the firewall feature ensures that access to the data or the service is restricted to a specific set/group of clients. While this may not be feasible in all scenarios, when it can be used, it provides an extra layer of access control protection for critical assets.		 High Yes No
Application secrets and credentials must not be in plain text in source code (code view) of a Logic App
Keeping secrets such as DB connection strings, passwords, keys, etc. in clear text can lead to easy compromise at various avenues during an application’s lifecycle. Storing them in a key vault ensures that they are protected at rest.		 High Yes No
Logic App access keys must be rotated periodically
Periodic key/password rotation is a good security hygiene practice as, over time, it minimizes the likelihood of data loss/compromise which can arise from key theft/brute forcing/recovery attacks.		 Medium No No
Diagnostics logs must be enabled with a retention period of at least 365 days.
Logs should be retained for a long enough period so that activity trail can be recreated when investigations are required in the event of an incident or a compromise. A period of 1 year is typical for several compliance requirements as well.		 Medium Yes No
Logic App Code View code should be backed up periodically
Logic App code view contains application’s workflow logic and API connections detail which could be lost if there is no backup. No backup/disaster recovery feature is available out of the box in Logic Apps.		 Medium No No

Source https://github.com/azsk/DevOpsKit-docs/blob/master/02-Secure-Development/ControlCoverage/Feature/APIConnection.md

APIConnection

Description & Rationale ControlSeverity Automated Fix Script
Logic App connectors must use AAD-based authentication wherever possible
Using the native enterprise directory for authentication ensures that there is a built-in high level of assurance in the user identity established for subsequent access control. All Enterprise subscriptions are automatically associated with their enterprise directory (xxx.onmicrosoft.com) and users in the native directory are trusted for authentication to enterprise subscriptions.		 High Yes No
Data transit across connectors must use encrypted channel
Use of HTTPS ensures server/service authentication and protects data in transit from network layer man-in-the-middle, eavesdropping, session-hijacking attacks.		 High Yes No

Br Joosua!

Measuring Node Execution In VSCode with PowerShell

Posted on by Joosua Santasalo

Background

Forcing synchronous execution in NodeJS some times increases execution time of the function, because you want to ensure certain order of progress in the code.

There are many good reads into the subject. TL DR: In my opinion you can reduce the amount of code quite drastically in particular select cases by introducing synchronous behavior into your code.

Timing functions

Generally you can measure functions execution time setTimeOut() and using dates for calculation. There are also many wrapper solutions for much more fine grained measurements/telemetry etc.

Since PowerShell is my default console for VScode I tend to use native functions of Powershell often to speed up some things – And this is where the Measure-Command function comes into play

Non blocking function

Blocking function

//Non Blocking function
const req = require('request-promises')
var uris =[
    "https://uri1.com",
    "https://uri2.com",
    "https://uri3.com",
    "https://uri4.com"
]
 function LoopAsync (uris) {
    for (let index = 0; index < uris.length; index++) {
        const element = uris[index];
        req(element).then((result) => {
            console.log(element + ".>" + result.headers.server)
        })
    }
}
LoopAsync(uris)



//Blocking function
const req = require('request-promises')
var uris =[
    "https://uri1.com",
    "https://uri2.com",
    "https://uri3.com",
    "https://uri4.com"
]
async function LoopAsyncAwait (uris) {
    for (let index = 0; index < uris.length; index++) {
        const element = uris[index];
        const data = await req(element)
        console.log(element + ".>" + data.headers.server)
    }
}
LoopAsyncAwait(uris)

Example for VScode

Measure-Command {node .\AsyncLoop.js}
Measure-Command {node .\syncLoop.js}

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.