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.
Note: You have to open the Acronis Access interface using its FQDN (e.g. https://access.company.com) for SSO to work. Single Sign-on does NOT work if you open the interface via IP address.
Note: This will work only for the Windows client. Mac support will come in a follow-up release.
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:
<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>
Editing the krb5.conf file:
Note: The domain in krb5.conf must always be in UPPERCASE or Kerberos ticket lookups may fail.
[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
Enabling Single sign-on in the web interface:
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.
Note: You must be logged in with a domain account and have the rights to use setspn
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.
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.
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
For example, if you gateway server is running on host 'cody' in the domain, run this command:
setspn -s HTTP/cody.acme.com cody
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.
e.g. codygw.acme.com
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
setspn -s HTTP/codygw.acme.com:444 cody
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.
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.
Verify that the SPN is registered
To query whether the SPN is registered properly:
e.g. setspn -Q HTTP/ahsoka.acme.com
e.g. setspn -l john
klist purge
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):
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.
For Firefox:
Note: To add all subdomains use the format ".example.com" (NOT *.example.com)
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:
Note: To add all subdomains use the format ".example.com" (NOT *.example.com)
For Chrome:
Note: You also can create a ticket via the Terminal by entering kinit and then your password.
$ defaults write com.google.Chrome AuthServerWhitelist “*.acme.com”
$ defaults write com.google.Chrome AuthNegotiateDelegateWhitelist “*.acme.com”