Microsoft Entra Private Access brings conditional access to on-prem Active Directory

Attackers are increasingly targeting cloud resources, but that doesn’t mean they no longer see our on-premises Active Directory installations as excellent targets for gaining access to our networks. Government entities, for example, often rely on lots of on-premises servers as well as traditional desktops that make for juicy targets.

As a result, Microsoft last year began testing how to add Microsoft Entra’s increased access control capabilities to on-premises systems as a means for enabling organizations to establish conditional access and multi-factor authentication (MFA) options for these resources. Initially the rollout included support for connecting to resources such as Active Directory domain controllers using Entra’s identity-centric Zero Trust Network Access (ZTNA) framework.

In July the official Microsoft documentation included details about configuring what the company calls “Entra Private Access for Active Directory Domain Controllers,” indicating that these features are in mainstream release and available for production use.

There is one major hurdle to overcome before you can roll out this capability: You will need to ensure your network is NTLM free and only supports Kerberos authentication with your domain controllers. The goal for Entra Private Access is to take the place of legacy VPNs and internal Active Directory resources.

Prepping your systems for Entra Private Access

While Entra Private Access has been generally available since November 2024, full Active Directory domain controller integration and documentation has only been available as of last month.

To set up the service you must have the Global Secure Access Administrator role in Microsoft Entra ID. The product also requires licensing, but you can use trial licenses to test the deployment in a proof of concept.

You must also ensure that client machines run Windows 10 or higher and that they are Microsoft Entra joined or hybrid joined devices. Client machines must also have line of sight to the private resources and domain controller. In other words, the user must be within the corporate network, accessing on-premises resources.

For firewall rules, you must open inbound TCP port 1337 in the Windows Firewall on the domain controllers. You must also identify the Service Principal Names (SPNs) of the private apps you want to protect and add them to the Private Access Sensors policy installed on the domain controllers.

Microsoft recommends testing this functionality with your private app first. You can enforce MFA to the domain controller by using the private app’s SPN, but doing so at a later stage may help you avoid any admin lockout issues, Microsoft reports.

As with many deployments, issues often start with troubleshooting the various parts needed for installation. I would recommend you review the resources at the Global Secure Access community resources hub and set up a proof of concept.

At this time, clients that can be protected include Windows 10 and 11 and Android. Windows on Arm, macOS, and iOS are in preview at this time.

Putting Entra Private Access to work

Before you can roll out these additional security settings, you need to be well on your way toward removing NTLM from your network. First you’ll need to audit your environment to identify where NTLM is being used.

To do so, navigate to Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.

The deepest level of auditing, including workgroup and domain authentication attempts that use NTLM, can be achieved by setting:

Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit All

Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all

Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts

Note that the setting of “Audit NTLM authentication in this domain” should be set for domain controllers only.  Auditing of “Outgoing NTLM traffic to remote servers” and “Audit Incoming NTLM Traffic” should be set on all computers.

Now sit back and review your log files located in Event Viewer (Local)Applications And Services LogsMicrosoftWindowsNTLMOperational.

Identify the applications and processes that are communicating over a very insecure protocol. Even if you don’t deploy Entra Private Access, take the time to audit use of NTLM in your network, as it will assist you as well in defending against ransomware attacks.

Once you have identified NTLM use in your applications and processes, you’ll want to block NTLM v1 and begin the transition to enforce and restrict NTLM v2 by setting the following policy:

Go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.

Find Network Security: LAN Manager Authentication Level and set it to Send NTLMv2 response only. Refuse LM & NTLM. This enforces use of Kerberos and only allows NTLMv2 as a fallback where absolutely necessary.

Once again, review the results and determine which applications and network segments are impacted. For applications that are deeply impacted, you may want to evaluate your options, as some applications may need to be retired or updated to newer versions to phase out NTLM.

If you are no longer reliant on NTLM, you can safely block its use in the domain.

To do so, under Group Policy, configure Network Security by selecting the policies: “Restrict NTLM: NTLM authentication in this domain.” You can choose from “Deny for domain accounts to domain servers” to “Deny All” for total blocking.

For any applications in your network, review to ensure they are not hardcoded for NTLM.  Specifically check for the following:

Calls to the AcquireCredentialsHandle function that are passing in the hardcoded string ntlm — replace these instances with negotiate

Calls to the RpcBindingSetAuthInfo function — replace RPC_C_AUTHN_DEFAULT with RPC_C_AUTHN_GSS_NEGOTIATE.

Removing NTLM from your network is not impossible, but it can be challenging. Take the time and resources to review your options so you can add more cloud security techniques and embed them into your local Active Directory.