Troubleshooting Single Sign On (SSO) for the KACE SMA (4211364)

The Single Sign On (SSO) capability was added to the SMA server allowing customers to user their current Active Directory (AD) logins for logging into the KACE SMA user interface. This article will discuss some of the problems and solutions to configuring and using this option.
 

Follow the instructions

As simple as it sounds, there are things that can sometimes be missed, so be sure to double-check your steps to make sure everything is setup properly.

Symptoms Issue 1

• Opening a browser and navigating to the SMA webui does not automatically log you in.

Symptoms Issue 2

• You are prompted for your AD credentials when accessing the SMA web portal.

Solution Issue 1 - DNS Resolution

If the AD server cannot be properly resolved, then you will get the error mentioned above in the Cause section.

To test:

• Ping the Fully Qualified Domain Name (FQDN) from the same subnet as your SMA.
• If it fails, ensure the machines in question (SMA and clients) are pointing to the correct DNS server and that there is a proper Host (A) recorded created in your DNS for the SMA server.
• If you are browsing to your SMA by something other than your hostname or FQDN, make sure your DNS record is a CNAME and a Host (A) record, not 2 Host (A) records. For example:
  • kbox hostname: KBOX. Host (A) record would be called kbox. 
  • kbox alias: helpdesk. Should be a CNAME record pointing to the host (A) record for KBOX, and NOT a 2nd Host (A) record. 
• If your SMA is configured with a publicly accessible domain name, your internal SMA DNS name must be configured with a Host (A) record, and the external domain name configured with a CNAME record.

Solution Issue 2 - Add the SMA URL to the Trusted Sites

1. In the Windows start menu search for Internet Options.
2. Click the Security tab.
3. Click the Trusted Sites zone.
4. Click Sites.
5. Add the SMA URL to the sites.
6. Close and re-open your browser and access the SMA web portal again.

Solution Issue 2 - Updating  Internet Options to Include Automatic Log On with Current User Name and Password

1. In the Windows start menu search for Internet Options.
2. Click the Security tab.
3. Click the Trusted Sites zone.
4. In the Internet Options dialog box, on the Security tab, select Trusted Sites, and then click Custom Level.
5. In the Security Settings dialog box, under Logon, select Automatic logon with current user name and password, and click OK.

Solution Issue 2 - Updating Internet Options for Integrated Windows Authentication

1. In the Windows start menu search for Internet Options.
2. Click the Advance tab.
3. Under the Security section enable the option for Enable Integrated Windows Authentication.
4. Click OK and restart your browser.

Solution Issue 3 - Domain Name (Network Settings/SSO) Configuration / TLS Conflicts

In the preferred configuration, the domain will match between:

Settings | Network Settings | Domain (e.g. internal.loc)

Settings | Network Settings | Web Server Name (domain suffix for FQDN - e.g. kace.internal.loc)

Settings | Security | Single Sign On | Domain (e.g. internal.loc)

It is possible (but not recommended) to run in a "mixed" domain configuration, but there are several caveats:

• The SMA can only join one domain for SSO. All users authenticating to the SMA must have accounts existing in the domain to which the SMA is joined. You cannot configure the SMA, for instance, to authenticate via SSO for users of domain.com if you've joined internal.loc for SSO - regardless of Network Settings configuration.

• If you use SSL for public UI access (e.g. kace.domain.com) and want SSO to function on your internal network, you must either:

- Configure split-zone DNS to point the public name (e.g. kace.domain.com) to the internal hostname of your SMA (e.g. kace.internal.loc) via a CNAME record in DNS. See Solution 1 for more DNS info.

OR

- Only access the SMA on your internal network by its internal hostname (e.g. kace.internal.loc). You can still use internal CNAME records in DNS to authenticate via SSO using alternative names (e.g. helpdesk.internal.loc).

• When using SSL and SSO, successful SSO authentication will only happen via HTTPS if the URL you access matches the name on the SSL certificate (e.g. kace.domain.com).

• You can bypass any SSL issues internally by simply accessing the SMA via HTTP. This will, of course, only work if you do not have the port 80 to 443 forward enabled in Security Settings. Note: We strongly recommend against using HTTP publicly.

If none of the above resolve your issue -

• Check the error log for any messages that might provide a clue to the issue. Try searching all or part of the error on quest.com's Knowledge Base as the technology we use for SSO was created by them.
• NOTE: Even successful SSO domain join info is in the error log.
• NOTE: Please DO NOT contact quest support for help with this issue, please contact KACE support.
• Logoff/Logon your Windows client.
• Re-join the domain under the SSO settings in the SMA Settings | Security Settings | Single Sign On.
• Reboot your SMA server, as well as your test client you are using.
• Check Firewall settings to allow Kerberos authentication on port 88 TCP & 88 UDP between SMA and AD controller.
• Computers container in AD has to be writable by the AD admin user account you use for the SSO join. Double-check to make sure the rights to the default Computers container in AD by:
  • Right-clicking the Computers container and going to properties.
  • Click the Security tab. 
  • NOTE: If you do not see this tab, in AD Users and Computers click View > Advanced Features.
    Create user objects AND Create computer objects needs to be checked.
  • This is needed since by default we create a computer and user object in this container for the join.
    
    *Note*
    If the above settings are properly set and you get this error: "Could not create keytab file", this can be:
    • the result of un-joining/re-joining your SMA to the domain too quickly. Wait and retry again in a few minutes, this should resolve the issue.
    • one or both of the objects (user and computer) already exist in AD. If this is the case, a force join should overwrite them. If force join does not work, delete the object(s) from AD and attempt to join.
    • Also check to make sure the time set on your AD matches the time set on the appliance. The AD is very tenacious with time. If they are out of sync, SSO may not function.

If you are still having trouble at this point, please contact KACE support.