MapR 5.0 Documentation : Tickets and Certificates

MapR implements security features that use tickets and certificates. Tickets contain keys, and are used to authenticate users and MapR servers. Certificates are used to implement SSL encryption and server authentication. Every user who wants to access a cluster must have a MapR user ticket (maprticket_<uid>) and every node in the cluster must have a MapR server ticket (maprserverticket).


A ticket is an object that contains specific information about a user and a key. A ticket authenticates a user to the cluster. Tickets are encrypted to protect their contents. MapR supports three types of tickets that can be used for authentication:

  • MapR user tickets
  • MapR service tickets
  • Kerberos tickets

The identity of the user that authenticates with the maprlogin utility is independent from the identity of the user of the client OS.

MapR tickets contain the following information:

  • UID (generated from the UNIX user ID)
  • GIDs (group IDs for each group the user belongs to)
  • ticket creation time
  • ticket expiration time (initial duration of the ticket)
  • renewal expiration time (maximum lifetime of the ticket)

Note that, because a ticket contains the GIDs for a user at the time the ticket is generated, a user must re-generate their ticket after changing group memberships.

For complete syntax, see The maprlogin Utility.

Generating a MapR User Ticket

A user ticket file is stored in /tmp and can only be read by that user. To generate a MapR user ticket, run the following command:

maprlogin password

This command prompts for the user's password, then generates a mapr user ticket associated with the UNIX user ID. By default, tickets on Linux systems are generated in the /tmp directory and are named in the form maprticket_<UID>. Tickets on Windows systems are generated in the %TEMP%/ directory and are named in the form maprticket_<username>. To change the default location, change the value of the MAPR_TICKETFILE_LOCATION environment variable.

To illustrate a typical work flow, suppose a user wants to access two clusters, cluster1 and cluster2. During this session, a user logs in as root to cluster1, gets a MapR user ticket, and displays the ticket contents with the maprlogin print command.

root@qa-node113:~/SecurityInstall# maprlogin password
[Password for user 'root' at cluster 'cluster1': ]
MapR credentials of user 'root' for cluster 'cluster1' are written to '/tmp/maprticket_0'

First Ticket for Cluster1

root@qa-node113:~/SecurityInstall# maprlogin print
Opening keyfile /tmp/maprticket_0
qasecurity1: user = root, created = 'Wed Sep 11 14:19:02 PDT 2013', expires = 'Wed Sep 25 14:19:02 PDT 2013', RenewalTill = 'Fri Oct 11 14:19:02 PDT 2013', uid = 0, gids = 0, 42

Now the root user logs in to cluster2. The maprlogin command returns a ticket for cluster2. This ticket is stored in the common ticket file. Commands now have access to both tickets.

root@qa-node113:/opt/mapr/conf# maprlogin password -cluster cluster2
[Password for user 'root' at cluster 'cluster2': ] 
MapR credentials of user 'root' for cluster 'cluster2' are written to '/tmp/maprticket_0'

Showing Tickets for Both Clusters

root@qa-node113:/opt/mapr/conf# maprlogin print 
Opening keyfile /tmp/maprticket_0
qasecurity1: user = root, created = 'Thu Sep 12 11:07:54 PDT 2013', expires = 'Thu Sep 26 11:07:54 PDT 2013', RenewalTill = 'Sat Oct 12 11:07:54 PDT 2013', uid = 0, gids = 0, 42
qasecurity2: user = root, created = 'Thu Sep 12 15:20:49 PDT 2013', expires = 'Thu Sep 26 15:20:49 PDT 2013', RenewalTill = 'Sat Oct 12 15:20:49 PDT 2013', uid = 0, gids = 0, 500

Generating a Service Ticket

Applications may have service processes that run outside the MapR cluster but need to access the cluster to run MapR commands. For security reasons, you may not want to run these services as the mapr user. Instead, you can use the maprlogin utility to generate a "service ticket" that can be used to access the cluster for the user account that runs the service. The maprlogin utility uses the current user's ticket (the user running the maprlogin command) to send an authenticated request for a newly generated service ticket. 

This type of ticket has a specified duration (expiration), a renewal period (maximum lifetime), and a designated location where the ticket is safely stored. The service process that uses the ticket can access it based on the definition of the MAPR_TICKETFILE_LOCATION environment variable, which points to the location of the ticket and should be set for the service process when it starts. Short duration and renewal values may be used for security reasons, but much longer lifetimes are supported for ease of administration. 

For example:

# maprlogin generateticket -type service -out /tmp/longlived_ticket -duration 30:0:0 -renewal 90:0:0
MapR credentials of user 'xxxx' for cluster 'xxxx' are written to '/tmp/longlived_ticket'

This command generates a service ticket that expires after 30 days and is stored in /tmp/longlived_ticket. The ticket may be renewed at any time before the 30 days pass, extending its lifetime to a maximum of 90 days. The ticket must be renewed explicitly before its expiration date; it does not renew automatically when it expires.

Generating a maprticket from a Kerberos Ticket

On clusters that use Kerberos for authentication, a MapR ticket is implicitly obtained for a user that runs a MapR command without first using the maprlogin utility.

If you want to use a Kerberos ticket to generate a maprticket, follow these steps:

  1. Obtain a Kerberos identity by running kinit or by another mechanism.
  2. Run maprlogin kerberos to indicate that you have an existing Kerberos ticket. You can also specify these options:
    [ -cluster ] The name of the cluster.
    [ -duration ] The ticket duration in seconds.

How Tickets Work

When an authenticated user runs a client, the client uses that user's ticket to communicate securely with the server. After enabling security features, supported communications channels between client and server are encrypted.

Nodes use tickets to identify themselves to one another in order to prevent spoofing, a condition where an untrusted machine presents itself as a trusted machine to gain access to the cluster.

When you submit a job to the JobTracker with a valid ticket for the local cluster, that job completes even if the job runs longer than the ticket's lifetime. Ticket expiration does not stop a running job unless the job accesses a remote cluster during its execution. The JobTracker can only generate tickets for the local cluster.

Components that submit jobs individually, such as Oozie or HiveServer2, cannot generate valid tickets for remote clusters. Jobs submitted by such components for remote clusters will fail if the remote clusters have security features enabled.

User Blacklisting

System administrators can use the command line interface to blacklist a user. A blacklist command invalidates all of a user's tickets. Once a blacklist command is received by the CLDB, the name of the blacklisted user is sent to all FileServer nodes, which reject any request sent by that user that has a ticket older than the blacklist's time stamp. Due to the nature of this check, there is no explicit removal of a blacklist. Issuing a new ticket with a time stamp more recent than the blacklist's time stamp implicitly removes the user from the blacklist. To permanently prevent a user from logging in again, revoke the user's credentials in the PAM registry.

What Blacklisting Affects

A blacklisted user cannot access the MapR file system or the CLDB, but since blacklisting only revokes a user's existing valid tickets, be aware of the following interactions:

  • Blacklisting has no effect on Oozie's cached credentials in ~/.oozie-auth-token, and has no effect on Oozie in general, even after a restart.
  • The JobTracker needs a restart to pick up blacklisting-related changes.
  • Blacklisting does not affect a new authentication with user ID and password or with existing Kerberos credentials.
  • Since NFS does not use MapR tickets, blacklisting does not affect NFS access.


A certificate performs authentication and encryption for websites that use the HTTPS protocol. A certificate contains information about an entity and contains a public key. The public key is related to a private key which is NOT part of the certificate, but is used by one entity when it communicates with another entity.

MapR stores the private key and certificate in a key store file called ssl_keystore. A certificate is also digitally signed so that it cannot be altered. The signer is known as the signing certificate.

In order for an HTTPS connection to be established, the following criteria must be met:

  • the server must have a key file that contains a certificate and private key
  • the client must provide a trust file that contains a signer who signed the certificate used by the server
  • the server certificate must be valid and not expired
  • the client must determine that the SubjectDN in the certificate is acceptable

The process of enabling MapR security generates the common ssl_keystore and ssl_truststore files on the first CLDB server that are used by all clients and servers.

You can also generate your own ssl_keystore and ssl_truststore files. Pass the -nocerts flag to the script during to suppress automatic generation of keystore and truststore files, then specify the location of your own storefiles in the mapr.login.conf file. Contact MapR Support for assistance in generating JKS-format storefiles from your vendor-supplied certificates.

  • The ssl_keystore contains a single self-signed certificate with a wildcard SubjectDN (for example, if the hostname of the CLDB is the SubjectDN would be CN=*
  • The ssl_truststore contains the signer for the certificate in the ssl_keystore.

Adding Your Certificate to the Keystore

The REST API calls in a MapR cluster communicate over the HTTPS protocol on port 8443. These calls are secured with SSL certificates that identify a node to the cluster. The ./adminuiapp/webapp/WEB-INF/ssl_keystore file stores SSL certificates.

The default keystore contents are generated during installation. To add an existing certificate and its corresponding key from a vendor to the keystore, use the keytool command.

 The following steps assume your vendor has delivered the certificate in Java KeyStore (JKS) format, or another format supported by the keytool utility.

On a Linux or Mac OS system, use a syntax similar to the following example:

keytool -import -trustcacerts -file <certificate>.crt -alias <hostname> -keystore $JAVA_HOME/jre/lib/security/cacerts

On a Windows system, use a syntax similar to the following example:

keytool -import -trustcacerts -file <certificate>.crt -alias <hostname> -keystore %JAVA_HOME%\jre\lib\security\cacerts

The default password for the keystore is changeit.

Verify that the certificate is now in the keystore with the following command:

keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts