Kerberos

Kerberos

Tutorial

Keytab

  • Deployment

    The keytab file is independent of the computer it's created on, its filename, and its location in the file system. Once it's created, you can rename it, move it to another location on the same computer, or move it to another Kerberos computer, and it will still function. The keytab file is a binary file, so be sure to transfer it in a way that does not corrupt it.

Active Directory

CLI cheatsheet

Get a TGT (Ticket-granting Ticket)

  • kinit --password-file=<text-file-storing-password> <principal>

    If the default cache type supports switching, kinit princname will search the collection for a matching cache and store credentials there, or will store credentials in a new unique cache of the default type if no existing cache for the principal exists. Either way, kinit will switch to the selected cache.

Show all caches with contents

klist -A

MIT - Show all principals in the specified keytab file with timestamps

klist -tke $keytab_file

MIT - Switch to the specified cache by principal name

kswitch -p $principal

Note: The cache must exist already.

MIT - Destroy the specified cache by principal name

kdestroy -p $principal

MIT - ktutil command lists

> ktutil:  ?
  Available ktutil requests:
 
  clear_list, clear        Clear the current keylist.
  read_kt, rkt             Read a krb5 keytab into the current keylist.
  read_st, rst             Deprecated and removed.
  write_kt, wkt            Write the current keylist to a krb5 keytab.
  write_st, wst            Deprecated and removed.
  add_entry, addent        Add an entry to the current keylist.
  delete_entry, delent     Delete an entry from the current keylist.
  list, l                  List the current keylist.
  list_requests, lr, ?     List available requests.
  quit, exit, q            Exit program.

MIT - Merge Keytab files

> ktutil
  ktutil: read_kt mykeytab-1
  ktutil: read_kt mykeytab-2
  ktutil: read_kt mykeytab-3
  ktutil: write_kt krb5.keytab
  ktutil: quit

MIT - Delete a key from a keytab file

> ktutil
  ktutil: read_kt mykeytab
  ktutil: list
 
  ...
  slot# version# username@ADS.IU.EDU        version#
  ...
 
  ktutil: delent slot#

SPNEGO

SPNEGO is used when a client application wants to authenticate to a remote server, but neither end is sure what authentication protocols the other supports. The pseudo-mechanism uses a protocol to determine what common GSSAPI mechanisms are available, selects one and then dispatches all further security operations to it. This can help organizations deploy new security mechanisms in a phased manner.

SPNEGO auth with curl

curl --negotiate -u : -G $HTTP_ENDPOINT

  • --negotiate

    Enables SPNEGO authentication

  • -u :

    Selects the user name and password from your environment, colon is required.

GSS

Workflow

The definitive feature of GSSAPI applications is the exchange of opaque messages (tokens) which hide the implementation detail from the higher-level application. The client and server sides of the application are written to convey the tokens given to them by their respective GSSAPI implementations. GSSAPI tokens can usually travel over an insecure network as the mechanisms provide inherent message security. After the exchange of some number of tokens, the GSSAPI implementations at both ends inform their local application that a security context is established.

Once a security context is established, sensitive application messages can be wrapped (encrypted) by the GSSAPI for secure communication between client and server. Typical protections guaranteed by GSSAPI wrapping include confidentiality (secrecy) and integrity (authenticity). The GSSAPI can also provide local guarantees about the identity of the remote user or remote host.

systemdOracle Database