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

Continuing from last post with the same topic but now from the negative side of things. What could go wrong if you don’t do it right. This post will assume that you are still having on-premises AD with ADCS and ADFS enabled but you are moving towards the cloud.

Restrict access to your Tier0

Making walls between the servers should always be the case. In on-premise environment and in the cloud. When you have those users in the cloud, you will probably use Azure AD as your IdP. Azure AD doesn’t have similar DC to protect, so that surface is covered but there is a lot of steps involved on making it secure as possible.

In on-premises by using at least network segmentation and denying services to interact with outside world and in the cloud similar approach by Disabling public access and using Isolation with RBAC-based access controls when possible.

Here is an excellent list of commands and tools to try it out ourself, use them only for learning not harming.

Enable PTA (Pass-Through Authentication)

This could be in both segments, do’s or the don’ts. PTA is an excellent solution for those needing it to establish Seamless SSO or to push authentication from ADFS to Azure. I would advise not to enable it before you made sure that isolation is enforced in your infrastructure, read below article and see for your self.

And how to attack the flaws from Nestori’s own blog

PTA operates by installing up to 40 agents per tenant on on-premise servers. When a user logs in to a service using the Azure AD identity platform, Azure AD encrypts the user’s credentials and sends an authentication request to one of the agents. The agent then decrypts the credentials, logs in using them, and gives the results to the user.

How PTA authentication works

Example on the attack workflow

More on the findings

Microsoft has also replied to this flaw on 20th of September

Link to hardening instructions

Make your ADCS deployments secure

If you are having Domain controllers and Federation Services, there is a big change you will also have Certificate services to supplement your environment with your own certificates.

In August this year, there was an CVE that had score if 8.8 from 10

Read more about the vulnerability from Semperis.

Do not Install agents on Domain controllers

This should make sense, don’t give possibilities to attack your DC’s. They have all the information from your domain.

Here are some excellent point from Sander Berkouwer on why it isn’t an excellent idea.

Do not Use high-privileged admin credentials on services

This is why there’s the Hybrid Identity Administrator role, switch to it to avoid privilege escalation with any of your services.

For the AD-based services use GMSA accounts when possible.

What could happen if you don’t use them?

Have visibility to your servers

Defender for Servers will give you the visibility that is needed. And you can onboard to your on-premises server in example with Azure ARC

What kind of alerts it gives the visibility?

There is two levels for Defender for Servers, P1 and P2

  • Plan 1
  • Plan 2
    • Plan 1: Includes everything in Defender for Servers Plan 1.
    • Additional features: All other enhanced Defender for Servers security features.

And here is the refence table for the alerts it finds

Don’t Store your passwords plain-text

If you need to use password in your service, be sure to keep them safe.


How to find exposed GitHub credentials?

Well, it’s easier than you think, there is a lot different solutions for this job, you can use them to understand the risks but so can those attackers.


Instead use System.Management.Automation.PSCredential to store your credentials in a file in PowerShell.

Azure Key vault

In Azure, use key vault

Restrict Storage accounts from public access

Keep using SAS-policies and don’t disable public access, there is a lot storage accounts still open out there.

See more from Cyberark on the exposed accounts

And their BlobHunter to check your Storage accounts.

Finally the recommendations from Microsoft for Blog storages

To make it closed completely, you can use Private Endpoints with Managed Identities and let the services that need access, have access.

Multi-factor authentication scenarios

Don’t have any users with out MFA

To solve, you can enable Nudge for Microsoft authenticator

Or enable MFA with Conditional access policies.

Use complex authentication methods

Always show your users where they login to and from where they are making the login from. Better yet, use Number matching feature when using Microsoft Authenticator.

Why to use them?

Well one reason could be MFA fatigue attacks.

Multi-factor authentication is excellent security feature, in the most simplified scenario you need your Username and Password + some form of proof that you are really doing the sign-in to a service.

But if you go where the fence is the lowest or implemented MFA ages ago and didn’t take care of the methods it’s uses after that. You could be facing the risks of MFA fatigue.

MFA fatigue means that after attacker will phish your credentials and once they do, they will sign-in to a service of their wishing and bombard you with endless swarm of MFA request until you accept the request.

To make the sign-in’s visible for your users please enable these. Then educate your users, it’s makes the deployment a lot longer but it’s worth it, I promise you.

Positive ending

The get a positive ending to this story. You can always rely on Azure Active Directory security operations guide for a helping hand with your secure Identity designs.

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 *