Known issues

The following sections describe the currently known issues in SaltStack Enterprise version 6.3.0.

General

  • If the PostgreSQL database is not set to use UTF-8, sorting will not be consistent across the application.
  • Job return numbers may differ from target numbers based on current key state and grain data.
  • Compound targeting with grains does not work if the grain filter value contains spaces. To use compound targeting with grains, do one of the following:
    • Use the G@ glob matcher but replace spaces with wildcard characters (*) instead. For example, change G@osfinger:CentOS Linux-7 to G@osfinger:CentOS*Linux-7
    • Use the P@` Perl-compatible regular expression (PCRE) matcher but replace spaces with \s to match whitespace. For example, change G@osfinger:CentOS Linux-7 to P@osfinger:CentOS\sLinux-7
  • When creating compound targets using grains, the Enterprise API server (RaaS) will return no minions if the grain name has a space in the name. Change the name of the grain to remove spaces.

The Enterprise Console

  • Scheduled jobs display in the Enterprise Console only if scheduled within the next 12 weeks.
  • After upgrading SaltStack Enterprise (for example, from 6.2.0 to 6.3.0), you must clear your web browser cache. Failing to clear the cache might result in unpredictable behavior in the Enterprise Console.
  • When running jobs against a large number of minions, only 2,000 job returns show in the Enterprise Console by default. To retain job returns for all minions, use the Enterprise API to query the get_returns function.
  • If you File Server contains a large number of files, the File Server search functionality might lag.

SaltStack Comply and SaltStack Protect

  • SaltStack Comply and SaltStack Protect require Salt version 2018.3.3 or later for Linux or Unix minions, and 3000 or higher for Windows minions.
  • It is recommended SaltStack Comply and SaltStack Protect assessments and remediations are run weekly or biweekly for target groups greater than 1,000 minions. If run more frequently, the results table will quickly consume all available disk space.
  • In some cases, SaltStack Comply and SaltStack Protect assessments results might show a negative count of minions returned.
  • In the Enterprise Console, SaltStack Protect does not show any minions included in a newly-created policy until you have run the first assessment.
  • A SaltStack Protect security policy’s Advisories tab does not show vulnerabilities that have been remediated. To view remediated advisories, go to the policy’s Minions tab, select a remediated minion, and then select the Last Remediation tab to verify the minion was remediated.
  • Remediating vulnerabilities on a minion might not result in any changes to the minion if the operating system has not yet provided updated packages required to remediate the vulnerability. In these cases, the remediation job returns successfully, but the vulnerabilities have not been remediated.
  • Vulnerability scans run immediately following a fresh installation of SaltStack Enterprise might fail. This happens because after the initial install, SaltStack Enterprise takes roughly 15-20 minutes to ingest vulnerability content. Once the ingestion process is complete, you can run vulnerability assessments and remediations successfully.
  • After running a SaltStack Protect scan one day, vulnerabilities are shown in the policy dashboard charts. If those vulnerabilities are not remediated and a new scan is run the following day, the policy chart resets to zero and begins with a fresh count for that day. This behavior is expected as the chart is intended to act as a daily scan summary. The chart does not display results for the days on which no vulnerability scans were run.
  • When importing a Tenable vulnerability scan through the API, the import may complete but will not change its status to complete on the backend and the user interface might stall while importing. This issue only occurs if the Tenable scan shows no vulnerabilities or if the Tenable scan does not cover any assets. A workaround is available when you Contact Support.

LDAP and Active Directory

  • When working with nested groups in LDAP, the Authentication workspace does not accurately reflect when a nested (or child) group is enabled. By enabling a parent group, you also enable all child groups by default. However, in the workspace, the child groups do not appear to be enabled.
  • When configuring a Directory Service connection for a forest structure, the Auth Bind DN Filter field must be left blank.
  • Any groups you have removed from a connection are still visible in the Roles workspace, and can be selected, although they are inactive. This also applies to any removed users previously visible in the Roles workspace. Although you can select an inactive group or user, these users can’t log in to SaltStack Enterprise.
  • When configuring Active Directory services, the results are limited to 10,000 users or less. Using a filter can help narrow down the directory to the specific users you would like to sync with SaltStack Enterprise.
  • SaltStack Enterprise might not correctly detect Active Directory members that belong to 20 or more groups.
  • Active Directory users with Superuser access privileges may find their password settings are occasionally reset when they access the Authentication workspace (accessed from the Administration menu). A temporary workaround is to set the password as the root user on the Authentication workspace, but the problem will recur the next time the user loads the Authentication workspace.