How to configure Integrated Windows Authentication in VisualSVN Server

Applies to: VisualSVN Server 5.3 and later

VisualSVN Server supports Integrated Windows Authentication (IWA), which provides Active Directory Single Sign-On for SVN clients and web browsers.

When accessing VisualSVN Server, IWA allows a client to authenticate to VisualSVN Server as the current user's domain account, without prompting the user to enter their username and password, without sending the password over the network and without needing to cache the credentials on disk. More information and the comparison of authentication methods available in VisualSVN Server can be found in the article KB182.

IWA allows the client and the server to use either Kerberos or NTLM authentication protocol, with Kerberos being the higher priority choice, and to use the Negotiate (SPNEGO) mechanism to negotiate the protocol selection.

Note
Integrated Windows Authentication is only available with the Enterprise and Enterprise Multinode licenses. It is also possible to try out Integrated Windows Authentication under a free Evaluation license. You can request an Evaluation license key from the evaluation page.

Activating Integrated Windows Authentication

Follow these steps to activate Integrated Windows Authentication in your installation of VisualSVN Server:

  • Open the VisualSVN Server Manager console.
  • Click Action | Properties.
  • Click the Authentication tab.
  • Ensure that the active authentication mode is Windows authentication.
    Note
    If the current authentication mode enabled in your VisualSVN Server installation is Subversion authentication, please follow the instructions given in the article KB182: VisualSVN Server authentication modes to change the authentication mode to Windows authentication.
  • Select the Integrated Windows Authentication option.
  • Click Apply.

Upon the change, VisualSVN HTTP Service Service restarts, and domain users become able to automatically authenticate with their current Windows credentials.

Note
To prevent passwords from being cached on disk, it is recommended that you disable Windows Basic Authentication when you enable Integrated Windows Authentication.

Troubleshooting and common issues

  • Single Sign-On may fail when the server is contacted by using an IP address in the URL. Kerberos authentication doesn't work in scenarios when the server is contacted by IP address instead of hostname.
  • Single Sign-On may fail when the server is contacted by using a custom DNS name in the URL. Consider the article KB224 for steps to create a custom DNS name properly.
  • MS Edge and Chrome enable Single Sign-On by default only for sites belonging to the Local intranet zone. If you access the server by its fully qualified domain name (FQDN), the web browser may not recognize the server as belonging to Local intranet and will not enable Single Sign-On for it. Consider the article KB239 for resolution steps.
  • Mozilla Firefox has Single Sign-On disabled by default. Consider the article KB42 for resolution steps.
  • Eclipse IDE may require additional configuration to support Single Sign-On. Consider the article KB145 for resolution steps.
  • Single Sign-On may fail in the scenario when an administrator configured the VisualSVN HTTP Service to run under a custom user account, instead of the default Network Service account. This issue may occur when the Service Principal Name (SPN) wasn't configured properly for the dedicated user account. The issue and resolution are described in the article KB52.

See also

KB180: Understanding Windows authentication mode settings
KB182: VisualSVN Server authentication modes
KB236: Understanding advanced settings for Windows authentication methods

Last Modified: