Configuring Single Sign-On

This guide will lead you through an advanced configuration to enable Single Sign On functionality with Acronis Access.

Note: Single Sign-On is only usable in a working domain.

Note: Single Sign-On does not work when you are running Acronis Access in a single port configuration (when the Gateway Server is proxying the requests for the Access Server).

The Single Sign-On functionality allows all valid LDAP users to login to the web interface and desktop client without having to enter their credentials. The user must have an Acronis Access account or LDAP Provisioning must be enabled on the server.

On the Acronis Access Server

Configuring Single Sign-On:

Note: It is recommended that Acronis Access is installed by a domain administrator, but it is not mandatory.

Note: The Gateway Server's address for administration MUST be a DNS address in order for SSO to work.

Note: If you want to use mobile clients with certificate authentication, the DNS entries for the Access and Gateway servers must NOT be the name of the computer. If the Access Server's SPN is just the name of the machine, the Gateway server will treat the Access Server as "on my machine", and will not attempt to perform Kerberos authentication.

e.g. machineAccess.domain.com / machineGW.domain.com will work

e.g. machine.domain.com / computer.domain.com will NOT work

Note: The settings in the web.xml are preserved on upgrade.

You will have to edit 2 configuration files and enable the feature from the web interface.

Editing the web.xml file:

  1. Navigate to C:\Program Files (x86)\Acronis\Access\Access Server\Web Application\WEB-INF\
  2. Find and open the file web.xml. In this file you will set the domain username and password that the SSO service will run under. The account must match the account that you will use to register the HTTP service with Kerberos in the On the Domain section.
  3. In web.xml there are two properties that need to be set - the domain username and password that the SSO service will use. Find the following lines:

        <init-param>

            <param-name>spnego.preauth.username</param-name>

            <param-value>yourusername</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.preauth.password</param-name>

            <param-value>yourpassword</param-value>

        </init-param>

  4. Replace yourusername with the desired LDAP username.
  5. Replace yourpassword with the LDAP password for the LDAP account specified above.

Editing the krb5.conf file:

  1. Navigate to C:\Program Files (x86)\Acronis\Access\Common\apache-tomcat-7.0.59\conf
  2. Find and open the file krb5.conf  
  3. In krb5.conf there are only two properties are needed from the administrator:
    1. The domain for single sign-on  (e.g., ACME.COM)

      Note: The domain in krb5.conf must always be in UPPERCASE or Kerberos ticket lookups may fail.

    2. The Kerberos Key Distribution Center's address (typically matches the address of your primary domain controller; e.g., acmedc.ACME.COM)
  4. The krb5.conf file that we install looks like this:

        [libdefaults]

            default_realm = ACME.COM

            default_tkt_enctypes = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc

            default_tgs_enctypes = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc

            permitted_enctypes   = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc

        [realms]

            ACME.COM = {

                kdc = acmedc.ACME.COM

                default_domain = ACME.COM

        [domain_realm]

            .ACME.COM = ACME.COM

  5. Replace all instances of ACME.COM with your domain (in uppercase!).
  6. Replace the value for "kdc =" with the name of your domain controller. The domain must be written in uppercase. e.g. kdc = yourdc.YOURDOMAIN.COM
  7. After the above configuration files are updated the Access Server (the Acronis Access Tomcat service) must be restarted in order for the changes to take effect.

Enabling Single sign-on in the web interface:

  1. Open the Acronis Access web interface and log in as an administrator.
  2. Expand the General Settings tab and open the LDAP page.
  3. At the bottom of the page, enable the checkbox Allow log in from the web client and desktop sync client using existing Windows/Mac login credentials.
  4. Press Save.

On the Domain

This is a one-time step that must be performed in order to register the Access Server with the Kerberos server on the domain. We will use 'setspn.exe' to specify which LDAP account will be queried for SSO authentication checks.

Note: If you want to use mobile clients with certificate authentication, the DNS entries for the Access and Gateway servers must NOT be the name of the computer. If the Access Server's SPN is just the name of the machine, the Gateway server will treat the Access Server as "on my machine", and will not attempt to perform Kerberos authentication.

e.g. machineAccess.domain.com / machineGW.domain.com will work

e.g. machine.domain.com / computer.domain.com will NOT work

Configuring the LDAP account that will handle SSO

Note: If you want to use SMB or SharePoint Data Sources, you must configure the Active Directory account to permit Kerberos delegation to each of your SMB and SharePoint data sources. For more information, please visit the Advanced Delegation Configurations article.

  1. Open a command prompt.

    Note: You must be logged in with a domain account and have the rights to use setspn

  2. Enter the command setspn –s HTTP/computername.domain.com account name

    e.g. If your Access server is installed on ahsoka.acme.com and you want to use john@acme.com as the pre-authenticated LDAP account to grant Kerberos tickets, the command will look like this:

    setspn -s HTTP/ahsoka.acme.com john

    Note: The LDAP account name used in the command above MUST match the account specified by the spnego.preauth.username property in web.xml.

    Note: This account will typically match the LDAP account specified by the administrator in the Acronis Access web interface at General Settings -> LDAP -> LDAP Username / LDAP Password, but this is not mandatory.

  3. If your Access server is running on a non-default port (i.e., a port other than 443), you should also register an SPN using the port number.

    e.g. If your server is running on port 444, the command will be:

    setspn -s HTTP/ahsoka.acme.com:444 john

    Note: The HTTP in the commands above refer to the HTTP service class, not the HTTP protocol. The HTTP service class handles both HTTP and HTTPS requests. You do not need to, and should NOT, create an SPN using HTTPS as a service class name.

  4. Go to the domain controller and open Active Directory Users and Computers.
  5. Find the user that you used in the above commands (in this case - john).
  6. Click on the Delegation tab and select Trust this user for delegation to any service (Kerberos only).
  7. Press OK.

Configuring the SPN for the Gateway Server

In order for the KDC ("Key Distribution Center") Kerberos server to be able to authenticate users to the gateway server, the gateway service must be registered with the KDC server by running setspn and specifying the hostname of the server on which it is running as the 'user' in the setspn command.

If the Gateway Server is on a different machine from the Access Server

  1. Open the command prompt.
  2. Enter the following setspn command: setspn -s HTTP/computername.domain.com computername

    For example, if you gateway server is running on host 'cody' in the domain, run this command:

    setspn -s HTTP/cody.acme.com cody

  3. If your gateway server is running on a non-default port (i.e., a port other than 443), you should also register an SPN using the port number; e.g., if your gateway server is running on port 444:

    setspn -s HTTP/cody.acme.com:444 cody.

If the Gateway Server is on the same machine as the Access Server

For this configuration to work, you will need to set an additional DNS entry for your Gateway server.

  1. On your DNS server, open the Forward Lookup Zones for your domain, right-click and create a new Host entry (A record) for the Gateway server.
  2. Enter a name. This will be the DNS address that will be used to reach the Gateway server.

    e.g. codygw.acme.com

  3. Enter the IP address of the Gateway Server (without the port). If you're running the Gateway and the Access Servers on the same IP address, enter that IP address.
  4. Select Create associated pointer (PTR) record and press Add Host.
  5. Go back to the machine with Acronis Access.
  6. Open the command prompt.
  7. Enter the following setspn command: setspn -s HTTP/gatewaydns.domain.com computername

    For example, if you gateway server is running on host 'cody' in the domain and your DNS entry is codygw.acme.com , run this command:

    setspn -s HTTP/codygw.acme.com cody

  8. If your gateway server is running on a non-default port (i.e., a port other than 443), you should also register an SPN using the port number; e.g., if your gateway server is running on port 444:

    setspn -s HTTP/codygw.acme.com:444 cody

  9. If you haven't done so already, you have to change your desired Gateway Server's address for administration to be the Gateway Server DNS entry you created in step 4.

If you wish to use mobile clients with client certificate authentication

This is an additional step that you have to perform. The steps above are required. You need to set up delegation from the Gateway Server to the Access Server regardless if they are on the same machine or not.

  1. To do this, open the Active Directory on the domain controller.
  2. Find and edit the Gateway server's computer object and go to the delegation tab.
  3. Select Trust this computer for delegation to specified services only and Use any authentication protocol.
  4. To select the Access Server's SPN, click Add and enter the username of the account that's associated with the Access Server's HTTP SPN.

    Note: Do not search for the computer that the Access Server is running on - you'll have to do the lookup by username.

    Note: Kerberos authentication to the Access Server is not compatible with single port mode.

  5. Once you search for the user, you should see the HTTP services, so select them (there might be two if you registered the SPN twice - once with the port and once without).
  6. Press Apply and close all dialogs.

Verify that the SPN is registered

To query whether the SPN is registered properly:

  1. Open an elevated command prompt.
  2. Enter the setspn –Q HTTP/computername.domain.com command.

    e.g. setspn -Q HTTP/ahsoka.acme.com

  3. To query the SPNs registered to a particular domain user, use the -l (lowercase L) switch;

    e.g. setspn -l john

  4. After registering the SPN, before you can authenticate to it with SSO you will need to either reboot the client machine or run this command on the client machine:

    klist purge

On the client's machine

This is a small, one-time configuration that must be made on the client machine to enable Single Sign-On support for your browser.

Note: This needs to be done for each user on each machine.

Windows:

For Internet Explorer:

For Chrome:

Chrome uses the same settings as Internet Explorer, so once you’ve configure it for SSO, Chrome will just work as well. However, to enable credential delegation, which is necessary for browsing network nodes from the Web interface, you must configure Chrome to allow it (Internet Explorer allows it by default):

  1. Open the registry editor (regedit32.exe)
  2. Set this registry string value: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome : AuthNegotiateDelegateWhitelist = ahsoka.acme.com

    Note: You can use wildcards, like *.acme.com or just *.

    Note: You might need to create the Google\Chrome keys if they don't already exist.

  3. Restart Chrome.

For Firefox:

  1. Type about:config in the address bar and press enter.
  2. Find and edit the preference network.negotiate-auth.trusted-uris and add https://ahsoka.acme.com , or just .acme.com, [the list is comma-separated].

    Note: To add all subdomains use the format ".example.com" (NOT *.example.com)

  3. To enable Network Data Sources support, you will need to also edit network.negotiate-auth.delegation-uris by adding ahsoka.acme.com or just the domain name - acme.com.
  4. Restart Firefox.

Mac:

Note: This needs to be done for each user on each machine.

For Safari:

It will just work, but you cannot use network data sources. You have to log in with a username and password or use a different browser.

For Firefox:

  1. Type about:config in the address bar and press enter.
  2. Find and edit the preference network.negotiate-auth.trusted-uris and add https://ahsoka.acme.com , or just .acme.com, [the list is comma-separated].

    Note: To add all subdomains use the format ".example.com" (NOT *.example.com)

  3. To enable Network Data Sources support, you will need to also edit network.negotiate-auth.delegation-uris by adding ahsoka.acme.com or just the domain name - acme.com.
  4. Restart Firefox.

For Chrome:

  1. Using the Ticket Viewer application (/System/Library/CoreServices/Ticket Viewer), you can check if you have a Kerberos ticket and create one if it hasn't been created automatically.

    Note: You also can create a ticket via the Terminal by entering kinit and then your password.

  2. To configure Chrome's whitelist to allow authentication against any domains you will be using, open the Terminal and run the following commands:

    $ defaults write com.google.Chrome AuthServerWhitelist “*.acme.com”

    $ defaults write com.google.Chrome AuthNegotiateDelegateWhitelist “*.acme.com”

  3. Restart the Chrome browser.

Troubleshooting Single Sign On