How Tickets Work

Explains the concept of tickets and how they work.

When an authenticated user runs a client, the client uses that user's ticket to communicate securely with the server. After Enabling Wire-level Security, supported communications channels between client and server are encrypted.

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

User Blocking

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

What Blocking Affects

A blocked user cannot access the MapR filesystem or the CLDB. Blocking only revokes a user's existing valid tickets, be aware of the following interactions:

  • Blocking has no effect on Oozie's cached credentials in ~/.oozie-auth-token; and has no effect on Oozie in general, even after a restart.
  • Blocking does not affect a new authentication with user ID and password or with existing Kerberos credentials.
  • Since NFS does not use MapR tickets, blocking does not affect NFS access.
  • Blocked users can still be impersonated as impersonation does not check whether a user is blocked or not.
  • Blocking has no effect on ZooKeeper. Blocked users can still connect to the ZooKeeper server and execute commands. The workaround to resolve this issue is to delete the ticket file.