Integrated Windows Authentication for Entra ID joined computers

Warning
The content of this article is still in development, and this version is a work in progress. Please contact support@visualsvn.com if you encounter any issues or need assistance with the procedures described in this article.

VisualSVN Server supports Integrated Windows Authentication (IWA) which provides secure authentication and Active Directory Single Sign-On using the Kerberos protocol (Kerberos over SPNEGO). IWA works in on-premises Active Directory environments out of the box.

Due to being built on a different technology stack, Entra ID by default doesn't support authentication to on-premises Active Directory resources. However, Entra ID Kerberos (cloud Kerberos trust) lifts this limitation and lets hybrid Entra ID accounts authenticate to domain resources using Kerberos and enables the two-factor authentication features of Windows Hello for Business for AD domain accounts.

This document provides steps for configuring Entra ID Kerberos in on-premises Active Directory Domain Services (AD DS). This enables the following two scenarios that can be used in combination or individually:

  • Scenario #1: Support for Windows Hello for Business (WHfB). Hybrid identities on Entra ID joined and Hybrid joined computers can take advantage of two-factor, biometric and passwordless authentication features provided by WHfB. Entra ID Kerberos simplifies the procedure for deploying WHfB in AD domain environments and makes it possible to authenticate to on-premises AD resources.
  • Scenario #2: Integrated Windows Authentication (IWA) for clients not connected to your corporate network. Hybrid identities on Entra ID joined and Hybrid joined computers can authenticate to Internet-facing installations of VisualSVN Server over Integrated Windows Authentication (with Single Sign-On). This can be helpful when working from home, because a VPN to your corporate network is not required in this case, and a Kerberos KDC Proxy is not required either.
Note
The former name of Entra ID is Azure AD, and the former name of Entra ID Kerberos is Azure AD Kerberos. This article uses the current product names, but in some instances, the older names are used because the Windows OS interface and its internal options have not been updated and still reference Azure AD.

Prerequisites and system requirements

  • Your organization has to be subscribed to a Microsoft cloud service with a dedicated Entra ID tenant. Entra ID Kerberos and synchronization from on-premises Active Directory to Entra ID are supported with free Entra ID licenses (Microsoft Entra ID Free).
  • Active Directory domain controllers must run Windows Server 2016 or later.
  • Client computers must be running Windows 11, Windows 10 version 2004 or later with the latest cumulative updates installed or Windows Server 2022 or later with the latest cumulative updates installed.
  • Administrator has to have an account in your Entra ID tenant in addition to their account in your Active Directory domain. More on the required permissions (roles) can be found in the next sections of the article.

Target environment overview

Although the described scenarios are different, both of them rely on Entra ID Kerberos (Cloud Kerberos trust) which has to be deployed to either enable two-factor authentication with Windows Hello for Business, or to extend Kerberos authentication to Entra ID computers physically located out of your corporate network, or to implement both scenarios.

Note
Cloud-only user accounts aren't currently supported by Entra ID Kerberos. The current version of Entra ID Kerberos requires user accounts signed into Windows to be hybrid user identities synchronized from on-premises Active Directory using Entra Connect or Entra Cloud Sync. This limitation may be removed in future updates.

Scenario #1: Support for Windows Hello for Business

  • All or selected users sign in to Windows and Active Directory using Windows Hello for Business, therefore using two-factor authentication when authenticating to domain resources and VisualSVN Server.
  • VisualSVN Server is deployed on a computer that is part of an on-premises Active Directory domain (AD DS) environment. The server is configured with Windows authentication and specifically with Integrated Windows Authentication (IWA), allowing users to authenticate with their Active Directory credentials.
  • Hybrid Entra ID environment is deployed. This means that your Active Directory domain is integrated (and synchronized) with Entra ID using Entra Connect or Entra Cloud Sync.
  • All or selected end users are signed into Hybrid joined computers with hybrid user accounts (hybrid identities) synchronized from on-premises Active Directory.

Scenario #2: IWA for clients not connected to your corporate network

  • VisualSVN Server installation is accessible to all or selected users from the Internet. The users are signed into Entra ID joined or Hybrid joined computers with hybrid user accounts (hybrid identities). Active Directory domain controllers or any other on-premise resources don't have to be reachable from these client computers.
  • VisualSVN Server installation is accessible to end users within your corporate network as usual.
  • VisualSVN Server is deployed on a computer that is part of an on-premises Active Directory domain (AD DS) environment. The server is configured with Windows authentication and specifically with Integrated Windows Authentication (IWA), allowing users to authenticate with their Active Directory credentials. Optionally, the server installation can be deployed in a DMZ if it's going to be reachable from the Internet.
  • Hybrid Entra ID environment is deployed. This means that your Active Directory domain is integrated (and synchronized) with Entra ID using Entra Connect or Entra Cloud Sync.
Tip
These two scenarios aren't mutually exclusive and can be used together. This means that you can deploy Entra ID Kerberos to enable two-factor authentication, and additionally you can open access to your VisualSVN Server installation from the Internet to selected Entra ID joined computers without having to deploy a corporate VPN or Kerberos KDC Proxy.

Deploying Entra ID Kerberos

Before implementing Scenario #1 and Scenario #2, you need to enable Active Directory and Entra ID synchronization and enable Entra ID Kerberos in your environment.

Step 1: Deploying Entra Connect

The very first step of the procedure is to deploy synchronization of your on-premises Active Directory domain into Entra ID. This is done using Microsoft Entra Connect or Microsoft Entra Connect Sync applications that need to be deployed on any server computer within your Active Directory domain. The step by step procedure for deploying Microsoft Entra Connect is given in the article Get started with Microsoft Entra Connect by using express settings. The express settings used and described in that article are suitable if your Active Directory has a single-forest topology. For more information, please read the official documentation and the prerequisites page.

Note
Please skip this step if your AD DS is already being synchronized with Entra ID by means of Entra Connect or Entra Cloud Sync.

After installing Microsoft Entra Connect, the initial synchronization process starts automatically by default. If you disabled the option 'Start the synchronization process when configuration completes' in the installer, you will have to start the initial synchronization manually (Start-ADSyncSyncCycle -PolicyType Initial).

The AD accounts synchronized from your on-premises Active Directory into Entra ID become hybrid accounts (hybrid identities). They appear in your Entra ID tenant as accounts with a special property On-premises sync enabled = Yes and have a matching account in your on-premises Active Directory domain. Entra ID Kerberos now supports only hybrid identities, so the information in this document is currently applicable only to these accounts.

You can identify if the account is a hybrid identity by looking at its properties in Microsoft Entra admin center. If the account is hybrid, it should have the 'On-premises' section of the Properties populated with relevant data and the property On-premises sync enabled must say Yes.

'On-premises' section of the hybrid account's properties
Note

Make sure that the following prerequisites are met before starting the Entra Connect wizard (AzureADConnect.exe):

Step 2: Creating an Entra Kerberos server object

Note
An administrator who adds the Entra Kerberos server object must be in a Domain Admins group for a domain and a member of the Enterprise Admins group for a forest in Active Directory. And must have the Global Administrators role in Entra ID.

Step 2.1: Installing the AzureADHybridAuthenticationManagement PowerShell module

Before beginning to create the Entra Kerberos server object in your Active Directory environment, please first install the AzureADHybridAuthenticationManagement PowerShell module:

  1. Start the PowerShell console as an administrator.
  2. Run the following commands:
    [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
    Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
  3. If prompted for confirmation whether you want to upgrade the NuGet provider, confirm by entering [Y] Yes.
  4. If prompted if you trust the PSGallery repository, confirm by entering [Y] Yes.

Step 2.2: Creating a Kerberos Server Object

Follow these steps to create the Kerberos Server Object:

  1. Start the PowerShell console as an administrator.
  2. Run the following commands:
    $userPrincipalName = "<USERPRINCIPALNAME>"
    $domain = $env:USERDNSDOMAIN
    Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName
    
    You need to replace the following placeholder before running the command:
    • <USERPRINCIPALNAME>: enter the Entra ID administrator account name in the UPN format such as "myadministrator@example.com".
      Note
      The values must be enclosed in double quotes.
  3. An authentication window appears. Authenticate to Entra ID using the credentials of the admin account that you specified as the <USERPRINCIPALNAME> above. You may be prompted to authenticate several times.

When the above steps are complete, you are ready to proceed to implementing the scenarios described below.

Scenario #1: Support for Windows Hello for Business

Windows Hello for Business (WHfB) enables strong hardware-backed two-factor authentication for Windows computers. When Entra ID Kerberos is deployed in your Active Directory environment, it becomes quite straightforward to enable WHfB on your domain computers. The steps described below show how to deploy WHfB using the Hybrid deployment type and cloud Kerberos trust. The procedure is thoroughly described in Microsoft Learn | Cloud Kerberos trust deployment guide. Note that since you've already deployed Entra ID Kerberos above, you don't have to complete the step "Deploy Microsoft Entra Kerberos" from that page.

Please find the steps required to enable WHfB below.

Step 1: Configuring the required WHfB policies

The client computer must have three special local policies configured to be able to enroll into WHfB. For configuring the policies on Hybrid joined computers, use AD Group Policy. For Entra ID joined computers, use either Local Group Policy or configure the policies through Microsoft Intune.

Note
Group policy changes are not instantly applied. Restart of the client computer may be required.

Policy #1: Use Windows Hello for Business

  • Policy name: Use Windows Hello for Business
  • Group policy path: Administrative Templates\Windows Components\Windows Hello for Business\Use Windows Hello for Business
  • Policy value: Enabled

Policy #2: Use cloud Kerberos trust for on-premises authentication

  • Policy name: Use cloud Kerberos trust for on-premises authentication
  • Group policy path: Administrative Templates\Windows Components\Windows Hello for Business\Use cloud Kerberos trust for on-premises authentication
  • Policy value: Enabled

Policy #3: Use a hardware security device

  • Policy name: Use a hardware security device
  • Group policy path: Administrative Templates\Windows Components\Windows Hello for Business\Use a hardware security device
  • Policy value: Enabled

Step 2: Enrolling into WHfB

The end user has to sign into a hybrid-joined computer to enroll into WHfB. When all prerequisites for WHfB are met, the user will be automatically prompted to set up WHfB and enable PIN-based or another two-factor authentication method (Windows Hello Face, fingerprint, etc.) on this computer. When enrolled, the user should be able to authenticate on this computer using the newly configured two-factor authentication method instead of his domain password.

Enrolling into Windows Hello for Business (WHfB)

If the user isn't prompted for WHfB enrollment, you can get clues on what's wrong by running the dsregcmd /status command on his computer. The output of this command and the section "Ngc Prerequisite Check" specifically, can give you clues on why WHfB enrollment isn't happening.

Step 3: Testing the authentication to VisualSVN Server

Using WHfB on a hybrid-joined computer significantly enhances the device's security, and fully supports Integrated Windows Authentication. The end users enrolled in WHfB should be able to access Active Directory resources and VisualSVN Server without any further changes on their computers. This assumes that the device is located in your corporate network and can reach your domain controllers for authentication within your on-premises domain. For the scenario when some of the client computers aren't in your corporate network or periodically leave it, please see the next section of the document.

Scenario #2: Integrated Windows Authentication for clients not connected to your corporate network

Entra ID Kerberos can enable IWA to work on Entra ID joined computers without having to deploy corporate VPN or Kerberos KDC Proxy. So you enable Kerberos authentication from the selected Entra ID joined computers and Hybrid joined computers when they are not connected to your corporate network and are unable to reach your AD DS domain's domain controllers and other resources.

Your VisualSVN Server installation has to be reachable for the selected client computers over HTTPS, but you don't have to publicly open it to the Internet. You can use firewall whitelisting or another method to allow your server installation to be reachable from the selected client computers. If the server installation is going to be Internet-facing, you can deploy it on an AD DS domain joined computer in DMZ.

The steps below are necessary to register your VisualSVN Server installation and its URL within your Entra ID and Active Directory to use Entra ID Kerberos, and to make the client computer use Entra ID for authenticating to the server installation.

Step 1: Creating a DNS record for your VisualSVN Server installation

You have to ensure that your VisualSVN Server installation is reachable from the client computers. One aspect of this is to make the DNS name of the server discoverable from the client computers. For example, you can create a public DNS record that would point to the public IP address of the server computer or your router that does port forwarding to the server computer.

For explanatory reasons, below we assume the DNS name mysvn.example.com is facilitated by a new DNS A record and use it in the steps below. This name is going to be registered for Entra ID Kerberos and used by the end users to contact VisualSVN Server.

Tip
If your VisualSVN Server installation isn't going to be available from the Internet but only within your corporate network, you can create a CNAME DNS record in your local DNS and point it to the name of the server computer hosting your VisualSVN Server installation. Find the instructions for creating a CNAME record in the article KB224.

Step 2: Creating a new Entra ID app registration

Follow these steps to create and configure a new Entra ID app registration:

  1. Sign into your Microsoft Entra admin center.
  2. Browse to Identity | Applications | App registrations.
  3. Click New registration. New registration
  4. Enter the name for the new app registration (for example, "VisualSVN Server Entra ID Kerberos").
  5. Select Accounts in this organizational directory only (Default Directory only - Single tenant).
  6. Click Register. Register

Follow these steps to grant the necessary API permissions for the app registration:

  1. From the app registration, click API permissions on the left and click Add a permission. Add a permission
  2. Click Microsoft Graph. Microsoft Graph
  3. Click Delegated permissions.
  4. Under Openid permissions, select openid and profile.
  5. Click Add permissions. Add 'openid' and 'profile' permissions
  6. Click Grant admin consent for <Tenant Name> (where <Tenant Name> is the name of your Entra ID tenant) and click Yes. Grant admin consent
  7. From the app registration, click Authentication on the left.
  8. Under App instance property lock, click Configure. App instance property lock
  9. Disable (uncheck) the option Enable property lock and click Save. Enable property lock

Remember the Application (client) ID of the app registration (you will need it later):

  1. From the app registration, click Overview.
  2. Copy the Application (client) ID and save its value for later. Application (client) ID

Step 3: Creating and assigning the SPN to the app registration

If on Step 1 you created a new DNS A record, you need to create a new HTTP/ SPN (Service Principal Name) for the Active Directory computer account where VisualSVN Server is running. And then assign this SPN to the Entra app registration created in the previous step.

Note
You can skip this step if you have created a CNAME record on Step 1. Creating a new SPN record is unnecessary in this case.

Step 3.1: Creating the SPN in Active Directory

Follow these steps to create the new SPN in your Active Directory:

  1. Start the PowerShell console as an administrator.
  2. Run the following command:
    setspn -s HTTP/mysvn.example.com <COMPUTER-NAME>
    You need to replace the DNS name mysvn.example.com and <COMPUTER-NAME> with the actual values present in your environment. The DNS name must be the FQDN the Entra ID users will be using to access VisualSVN Server. And the computer name <COMPUTER-NAME> above corresponds to the name of the server computer that an instance of VisualSVN Server is running on.

Step 3.2: Assigning the SPN to the Entra ID app registration

Follow these steps to assign the SPN to the Entra app registration:

  1. On the computer where the AzureADHybridAuthenticationManagement PowerShell module is installed, start the PowerShell console as an administrator.
  2. Run the following commands:
    $userPrincipalName = "<USERPRINCIPALNAME>"
    $servicePrincipalName = "<SPN>"
    $applicationId = "<APPID>"
    $domain = $env:USERDNSDOMAIN
    
    Import-AzureADKerberosOnPremServicePrincipal -Domain $domain -UserPrincipalName $userPrincipalName -ServicePrincipalName $servicePrincipalName -ApplicationId $applicationId
    You need to replace the following placeholders before running the commands:
    • <USERPRINCIPALNAME>: enter the Entra ID administrator account name in the UPN format such as "myadministrator@example.com".
    • <SPN>: enter the HTTP/ SPN created earlier in the HTTP/mysvn.example.com format such as "HTTP/mysvn.example.com".
    • <APPID>: enter the Application (client) ID GUID you saved earlier such as "3ffb0273-0335-4fac-b403-1f73e2297b7e".
  3. An authentication window appears. Authenticate to Entra ID using the credentials of the admin account that you specified as the <USERPRINCIPALNAME> above. You may be prompted to authenticate several times.

Step 4: Configuring Entra ID Kerberos policies on intended client computers

The client computer must have two special local policies configured to be able to authenticate to VisualSVN Server from an Entra ID joined computer or from a Hybrid joined computer physically located out of your corporate network. For configuring the policies on Hybrid joined computers, use AD Group Policy. For Entra ID joined computers, use either Local Group Policy or configure the policies through Microsoft Intune.

Note
Group policy changes are not instantly applied. Restart of the client computer may be required.

Policy #1: Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon

  • Policy name: Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon
  • Group policy path: Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon
  • Intune policy CSP: /Kerberos/CloudKerberosTicketRetrievalEnabled
  • Policy value: Enabled

Policy #2: Define host name-to-Kerberos realm mappings

  • Policy name: Define host name-to-Kerberos realm mappings
  • Group policy path: Administrative Templates\System\Kerberos\Define host name-to-Kerberos realm mappings
  • Intune policy CSP: /ADMX_Kerberos/HostToRealm
  • Policy value:
    • Value name: KERBEROS.MICROSOFTONLINE.COM
    • Value: <VisualSVN-Server-FQDN>

      You need to replace <VisualSVN-Server-FQDN> with the actual FQDN of your VisualSVN Server installation the Entra ID users will enter to contact the server (for example, mysvn.example.com). The FQDN is typically identical to the one specified in the SPN you created at Step 3.

Step 5: Testing the authentication to VisualSVN Server

The following steps show how to test if Entra ID Kerberos is used for user authentication when accessing VisualSVN Server:

  1. Sign in as the hybrid identity into the Entra ID joined computer you configured on Step 4.
  2. Attempt accessing your VisualSVN Server installation using a web browser or the Subversion client (e.g., svn.exe or TortoiseSVN). You should be authenticated automatically without receiving any sign in prompts.

You can double-check and confirm if the cloud Entra ID Kerberos ticket has been issued in the process of authentication. On the client computer, start PowerShell and run the following command:

klist | Select-String "HTTP/mysvn.example.com" -Context 2,2

You should see the following ticket in the output:

  #1> Client: MyHybridUser @ example.com
>     Server: HTTP/mysvn.example.com @ KERBEROS.MICROSOFTONLINE.COM
      KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
      Ticket Flags 0x40000000 -> forwardable

If the ticket isn't present on the client computer, the command doesn't produce any output.

You can double-check and confirm the authentication method used by checking the events logged into the Windows Security event log on the VisualSVN Server computer.

  1. Start Event Viewer.
  2. Navigate to Windows Logs | Security.
  3. Examine the log to find the event associated with your logon session to VisualSVN Server. The event should look like the example shown below.
    • Note the Security ID, Account Name which should reference your hybrid identity user account.
    • Note the Account Domain which should reference KERBEROS.MICROSOFTONLINE.COM.
    • Note the Logon Process, Authentication Package which should reference Kerberos.
    An account was successfully logged on.
    
    Subject:
    	Security ID:    	NULL SID
    	Account Name:    	-
    	Account Domain:   -
    	Logon ID:    	0x0
    
    Logon Information:
    	Logon Type:       	3
    	Restricted Admin Mode:	-
    	Virtual Account:    	No
    	Elevated Token:    	No
    
    Impersonation Level:    	Impersonation
    
    New Logon:
    	Security ID:    	MYDOMAIN\MyHybridUser
    	Account Name:    	MyHybridUser@example.com
    	Account Domain:   KERBEROS.MICROSOFTONLINE.COM
    	Logon ID:    	0x2C2D452
    	Linked Logon ID:    	0x0
    	Network Account Name:	-
    	Network Account Domain:	-
    	Logon GUID:    	{308fca55-a07d-afba-8e70-4e214514fa9a}
    
    Process Information:
    	Process ID:    	0x0
    	Process Name:    	-
    
    Network Information:
    	Workstation Name:	-
    	Source Network Address:	-
    	Source Port:    	-
    
    Detailed Authentication Information:
    	Logon Process:    	Kerberos
    	Authentication Package:	Kerberos
    	Transited Services:	-
    	Package Name (NTLM only):	-
    	Key Length:    	0
Last Modified: