Windows Service logon in Entra ID environment without Entra DS

Question

Hi, because of costs, we are trying to deploy an Entra ID environment without Entra DS, we have several windows services that required access to resources outside the virtual machine, using local accounts to run the windows services is not compliant with this need as we cannot provide access to local accounts in external resources, Managed Identities cannot be configured as logon for windows service and without Entra DS there aren't service accounts or gMSA, is there a way to achieve the configuration of a windows service so that the entity configured as logon can access resources outside the virtual machine (no Entra DS)?

Answer 1

In a Microsoft Entra ID only environment without Entra Domain Services, Windows Service logon is fundamentally limited by the absence of domain based service principals such as traditional service accounts or gMSA.

A Windows Service requires a security principal that can obtain a Kerberos or NTLM token when accessing external resources such as file shares, SQL Server, or other Windows based workloads. Without Active Directory Domain Services or Entra Domain Services, the operating system cannot issue domain credentials for that purpose.

It is important to clarify the boundary here.

Microsoft Entra ID is an identity provider for modern authentication using OAuth 2.0 and OpenID Connect. It does not provide:

• Kerberos domain functionality
• NTLM authentication infrastructure
• Service account objects
• gMSA capability
• Domain joined machine context

Because of this, there is no native way to configure a traditional Windows Service to log on using a Microsoft Entra ID identity in the same way as a domain service account.

You effectively have the following supported design options.

Option 1: Redesign the service to use modern authentication

If the external resource supports Microsoft Entra ID authentication, the recommended architecture is:

• Run the Windows Service under Local System or a local managed account
• Implement application level authentication using Microsoft Entra ID
• Use client credentials flow with a registered application
• Use certificate based authentication instead of client secrets

In this model, the Windows Service does not rely on the Windows logon token to access external resources. Instead, it acquires an access token from Microsoft Entra ID using MSAL and calls the resource using OAuth.

This approach is valid only if the target system supports Entra ID based authentication such as Azure SQL, Azure Storage, Microsoft Graph, or other modern workloads.

Option 2: Use Managed Identity on Azure Virtual Machines

If the workload runs on Azure Virtual Machines, you can:

• Enable System Assigned or User Assigned Managed Identity
• Grant that identity access to Azure resources
• Modify the service to request tokens from the Azure Instance Metadata Service

Managed Identity cannot be configured directly as the Windows Service logon identity. However, the service code can request tokens programmatically and access external Azure resources without stored credentials.

Again, this works only for Azure resources that support Entra ID authentication.

Option 3: Use traditional Active Directory

If the service must access:

SMB file shares

On premises SQL Server using Windows authentication

Legacy applications using NTLM or Kerberos

Then a domain is required. Your options are:

• Deploy Active Directory Domain Services
• Deploy Microsoft Entra Domain Services
• Join the machine to that domain
• Use domain service accounts or gMSA

There is no supported method to emulate Kerberos or NTLM domain authentication using Microsoft Entra ID alone.

Important architectural conclusion

If your external dependencies require Windows integrated authentication, an Entra ID only environment without Entra Domain Services cannot satisfy that requirement.

Microsoft Entra ID is not a replacement for domain based service authentication. It is an identity provider for modern application authentication.

Therefore the correct design decision depends entirely on the authentication model of the external resource:

If the resource supports OAuth and Entra ID, redesign the service for token based authentication.

If the resource requires Windows integrated authentication, deploy a domain solution.

There is no supported configuration that allows a Windows Service to log on using a pure Entra ID identity and obtain Kerberos or NTLM credentials without a domain.