Do’s and don’ts concerning security for Identity part 2

Continuing with the do’s of Identity and supposing that you have a Hybrid identity setup.

If you still need (haven’t convinced you otherwise) federation services in on-premises, use should use

Defender for Identity sensors for ADFS

What it needs?

ADFS in Windows Server 2016 and up that isn’t an Domain controller

You to open port 443 in your firewalls and proxies to <your-instance>

Allow the Directory service account that you specify in (Configuration > Directory services > Username) have access to AdfsConfiguration database.

The account types

Type of DSAProsCons
gMSAMore secure deployment since Active Directory manages the creation and rotation of the account’s password like a computer account’s password.You can control how often the account’s password is changed.Requires additional setup steps.
Regular user accountSupports all operating system versions the sensor supports.Easy to create and start working with.Easy to configure read permissions between trusted forests.Less secure since it requires the creation and management of passwords.Can lead to downtime if the password expires and password isn’t updated (both at the user and DSA configuration).

Adding user account to the database with PowerShell when you internal SQL Express DB.

Setting ADFS logging to verbose with

And then the agent install from here

Read this excellent post from Jeffrey Appel about MDI and how set it up!

What it can do?

It will detect on-premises attacks against AD FS servers and report the information back to Defender for Identity.

Find Honeypot’s from your environment and how they are used for possible lateral movement. Here is an excellent blog about the pots.

What it will find?

It will find the following reconnaissance information

  • LDAP enumeration
  • Group membership enumeration
  • Users and IP enumeration
  • DNS enumeration
  • Suspicious resources access activities
  • Reconnaissance by targeted entity attributes

And the following credential access

  • Brute force attacks (ADDS & ADFS)
  • Login/failed suspicious activities
  • Suspicious DC password changes using different services
  • Suspicious Kerberos SPN exposure
  • Honeytoken account activities
  • Suspicious VPN activities

And there lateral movements

  • Pass-the-ticket attack
  • Pass-the-hash attack
  • NTLM relay and NTLM tampering
  • Overpass-the-hash
  • Suspicious certificates
  • Suspicious group membership changes
  • Suspicious SID history injection

In example you can protect you self from attacks like Nobelium

If you install both Defender for Identity and the Defender for Endpoint sensors, you can protect ADFS and the server itself.

Defender for Endpoint

To try out Defender for Endpoint, enable your trial here

Defender for Endpoint plans

PlanWhat’s included
Defender for Endpoint Plan 1Next-generation protection (includes antimalware and antivirus)Attack surface reductionManual response actionsCentralized managementSecurity reportsAPIsSupport for Windows 10, iOS, Android OS, and macOS devices
Defender for Endpoint Plan 2All of the Defender for Endpoint Plan 1 capabilities, plus:Device discoveryDevice inventoryCore Defender Vulnerability Management capabilitiesThreat AnalyticsAutomated investigation and responseAdvanced huntingEndpoint detection and responseMicrosoft Threat ExpertsSupport for Windows (client and server) and non-Windows platforms (macOS, iOS, Android, and Linux)

With Defender For Endpoint you can detect threat like.

And also dumping, like Living Off The Land Binaries.

Living off-the-land binaries, or “LOLBins,” are not inherently dangerous, but when they are used by cybercriminals to their advantage, they can cause serious damage to your computers. Local tools that come with your operating system are called LOLBins. Some highest used examples of these are PowerShell.exe, rundll32.exe and Certutil.exe

But an better solution could be switching from on-premises ADFS to…

Certificate-based authentication

Customers can directly authenticate against Azure AD using certificate-based authentication. Federated AD FS is necessarily no longer required thanks to Azure AD CBA, which simplifies customer environments and lowers costs.

And CBA is now globally available! You can read more from the feature inside my previous post.

Authentication context


Auth context also went GA at Ignite, it can be used inside ASP.NET CORE application to force phishing resistant authentication

Native applications

Or inside application it supports in example these applications can be like SharePoint, or applications protected by Microsoft Defender for Cloud Apps.

Templates to educate users

You can use Microsoft Entra end-user rollout templates and materials (Customizable posters, training, stickers, and email templates) to roll out Azure Active Directory features in your organization

These are just brilliant, I really should try them out when taking security features in use!

You download here the templates that Martin Coetzer’s team has made for your disposal.

Use AAD Connect Cloud Sync (if able to)

Those of you that use Azure AD password reset and Azure AD Connect, should really consider switching to Azure Active Directory Connect cloud sync to keep your password up to date in real-time.


  • A SQL (Express) database on your server is not necessary.
  • You can build high availability by setting up several agents without configuring inbound ports or load balancers.
  • Agents will upgrade automatically on the background.
  • Sync logs from the Azure portal is provided.
  • Azure makes it simple to force synchronization and by default cloud provisioning occurs every 2 minutes.
  • Up to 50.000 users can sync together in a single group.

Customizing sync

Inside AAD Connect you had Metaverse which had all the user attributes from AD and Azure AD inside an SQL DB.

You could do queries on them and custom rules based on different factors.

Cloud sync user a little bit different methods because there is no local components except the light-weight proxy-based agent.

It create an App registration that the agent will contact eventually and through that API it will do it’s magic but keep this in mind.

Once you create the config and give it a name, that will become the App registration name

Under App registrations

If we look at manifest a bit.

It has access with the agent and the gMSA account create for it to your local AD.

And the following App roles

Here is instructions on how to modify or query the schema with Microsoft Graph.

You can either update with Graph or download the rules and edit them in VS Code or similar editor and Put them back to the schema once done.

Supported scenarios


  • Directory extension attributes from AD are not synced.
  • Pass-Through Authentication (PTA) is not supported by Cloud Sync.
  • Hybrid Exchange Deployment is not supported by Cloud Sync.
  • Device and group writeback is not supported by cloud sync


In this part we discovered how MDI and MDE works but also about CBA and Cloud sync and why they are useful for your environment.

In the next part more Identity do’s and don’ts, Stay tuned!

Hackers don’t break in – they log in.

Author: Harri Jaakkonen

Leave a Reply

Your email address will not be published. Required fields are marked *