Defining a Kerberos scheme

Prerequisites

Completely set up Kerberos for DSE nodes before turning on Kerberos authentication. When switching authentication methods, or enabling authentication for the first time in a production environment, DataStax recommends setting up applications to use Kerberos tickets before restricting access to only authenticated connections. When DSE Authenticator is disabled, the credentials portion of the connection request is ignored. Therefore, you can pass Kerberos tickets to DSE before implementing authentication in the environment.

Change the replication strategy and default replication factor for the system_auth and dse_security keyspaces, see Configuring system_auth keyspace replication

How to add the Kerberos authenticator to cassandra.yaml and Kerberos options to dse.yaml.

Procedure

On each node, edit the cassandra.yaml file to set the authenticator to the DSE Authenticator.
```
authenticator: com.datastax.bdp.cassandra.auth.DseAuthenticator
```
In cassandra.yaml, set the rpc_address and listen_address to the IP address. Do not use localhost or the hostname.
```
rpc_address: 100.200.182.1
listen_address: 100.200.182.1
```

On each node, edit the dse.yaml file:

Set Kerberos as default or other scheme in the authentication options:

authentication_options:
    enabled: false
    default_scheme: kerberos
    other_schemes:
        - internal
    scheme_permissions: true
    allow_digest_with_kerberos: true
    plain_text_without_ssl: warn
    transitional_mode: disabled

When initially enabling authentication, specify the internal scheme as the default or other. After restarting DSE, to establish roles requires using the internal default cassandara account.

Option Description

auth_enabled in dse.yaml

Turns on authentication using the default scheme.

default_scheme in dse.yaml

Specifies the authentication scheme when not defined in the connection: -

internal- Plain text authentication using internal login role with password, supply the role name and password as credentials. No additional configuration required.
ldap - Plain text authentication using pass-through LDAP authentication. See Defining an LDAP scheme.
kerberos - GSSAPI authentication using the Kerberos authenticator.

other_schemes in dse.yaml

You cannot use other_schemes with DSE components that use Thrift, such as CFS and the CassandraHiveMetastore in Analytics datacenters. Only the default_scheme is used when using components that use Thrift drivers.

scheme_permissions in dse.yaml

Validate that the role mapped to user matches the authentication scheme. Grant the role permission to the scheme.

allow_digest_with_kerberos in dse.yaml

Allow Kerberos digest-md5 authentication.

plain_text_without_ssl in dse.yaml

Handling of plain text connection requests: * block - Block the request with an authentication error. * warn - Log a warning about the request but allow it to continue. Default. * allow - Allow the request without any warning.

transitional_mode in dse.yaml

Sets the behavior when authentication fails and credentials are missing: include::partial$ConfigWH-transitional_modeVALUES.adoc

Configure the Kerberos options.

The options are located in the kerberos_options section.

Example:

kerberos_options:
   keytab: /etc/dse/dse.keytab
   service_principal: dse/_HOST@REALM
   http_principal: HTTP/_HOST@REALM
   qop: auth

kerberos_options
Option	Description
keytab	The keytab file must contain the credentials for both of the fully resolved principal names, which replace `_HOST` with the FQDN of the host in the `service_principal` and `http_principal` settings. The UNIX user running DataStax Enterprise must also have read permissions on the keytab.
service_principal	Sets the principals name for the DSE database and DSE Search (Solr) processes. Use the form `dse/_HOST@REALM`, where dse is the service name. Leave `_HOST` as is. This variable is used in dse.yaml. DataStax Enterprise automatically substitutes the FQDN of the host where it runs. Credentials must exist for this principal in the keytab file and readable by the user that Cassandra runs as, usually cassandra. The `service_principal` must be consistent everywhere: dse.yaml file keytab *cqlshrc file (where it is separated into the service/hostname)
http_principal	The http_principal is used by the Tomcat application container to run DSE Search. The Tomcat web server uses GSS-API mechanism (SPNEGO) to negotiate the GSSAPI security mechanism (Kerberos). Set REALM to the name of your Kerberos realm. In the Kerberos principal, REALM must be uppercase. The http_principal is used by the Tomcat application container to run DSE Search. The Tomcat web server uses GSS-API mechanism (SPNEGO) to negotiate the GSSAPI security mechanism (Kerberos). Set REALM to the name of your Kerberos realm. In the Kerberos principal, REALM must be uppercase.
qop	A comma-delimited list of Quality of Protection (QOP) values that clients and servers can use for each connection. The client can have multiple QOP values, while the server can have only a single QOP value. The valid values are: `auth` - Default: Authentication only. `auth-int` - Authentication plus integrity protection for all transmitted data. `auth-conf` - Authentication plus integrity protection and encryption of all transmitted data. Encryption using `auth-conf` is separate and independent of whether encryption is done using SSL. If both `auth-conf` and SSL are enabled, the transmitted data is encrypted twice. DataStax recommends choosing only one method and using it for both encryption and authentication.

When adding a Kerberos scheme to an authentication enabled cluster, configure Kerberos roles before restarting DSE, see Managing roles.

What’s next

When initially configuring authentication complete the set up by:

Defining a Kerberos scheme

Prerequisites

Procedure

What’s next

Was this helpful?

Give Feedback