Native transport authentication schemes and limitations in LCM

Lifecycle Manager (LCM) authentication options are set in the dse.yaml and cassandra.yaml files in LCM Config Profiles.

LCM requires internal as the default scheme in dse.yaml when used in conjunction with DSE Authenticator in cassandra.yaml.

The location of the cassandra.yaml file depends on the type of installation:

Package installations

/etc/dse/cassandra/cassandra.yaml

Tarball installations

installation_location/resources/cassandra/conf/cassandra.yaml

LCM-compatible authentication schemes

To monitor the cluster and perform ongoing management activities, OpsCenter must be able to issue CQL queries against the cluster. LCM automatically configures the required access and is compatible with the following authentication scenarios:

Internal authentication only
Internal authentication with LDAP or Kerberos
Authentication disabled

If any form of authentication is enabled, and the internal scheme is not set as the primary scheme, then LCM install jobs fail when attempting to change the password for the internal cassandra user built-in to the internal authentication scheme. As a result, LCM fails to register the cluster with OpsCenter.

Internal authentication only

Internal authentication only is the default authentication scheme for LCM. This scheme uses the cassandra username with a default password of cassandra. LCM requires that you change this password in the Edit Cluster dialog.

The Edit Cluster dialog prompts for the information necessary to change the default password of the cassandra username that is built into the internal authentication scheme. LCM sets the password for this user as specified, and configures OpsCenter to use the password when accessing the cluster.

DSE Authentication default scheme options

Internal authentication with LDAP or Kerberos

Internal authentication in LCM can be configured as the primary scheme (default_scheme), with LDAP or Kerberos (or both) as optional schemes (other_schemes).

Adding LDAP or Kerberos as other_schemes in dse.yaml is allowed, but LCM and OpsCenter ignore the additional schemes and use the internal cassandra username, as described in the Internal authentication only scheme.

This scenario is useful when client applications using DSE for data storage must have accounts managed through a centralized Kerberos or LDAP service. OpsCenter will use the internal cassandra username to ensure that DSE management operations can be completed, even if access to the Kerberos or LDAP service is disrupted or unavailable.

When authentication is enabled in a configuration profile, LCM prompts for credentials after the profile is selected in the Edit Cluster dialog. See Editing a Cluster for more information.

Supported authentication other schemes in LCM

Authentication disabled

Running DSE with authentication disabled is not recommended without appropriate network access controls in place. However, LCM supports configuring OpsCenter to access a DSE cluster that has authentication disabled.

To disable authentication, uncheck the enabled checkbox under authentication_options in dse.yaml. In cassandra.yaml, select DseAuthenticator as the authenticator, which is a flexible option that is recommended in all use cases.

You can also disable authentication by selecting the AllowAllAuthenticator authenticator option in cassandra.yaml, but the DseAuthenticator option is preferred.

LCM-supported authenticator options in cassandra.yaml Authentication disabled in dse.yaml

Unsupported authentication scenarios

The following configurations are not supported:

LDAP authentication in cassandra.yaml instead of DSE authentication, and DSE authentication with LDAP as the default scheme.
Kerberos in cassandra.yaml instead of DSE authentication, and DSE authentication with Kerberos as the default scheme.

See the authenticator option for details.