KAdmin Overview

[ Terms Used ] [ KAdmin Capabilities ] [ School/Center Role ] [ Common Tasks ]

Terms Used

In MIT Kerberos documentation, principal is the term used for the userid belonging to a person or a program for using Kerberos. Penn uses PennKey as a friendlier synonym. They are interchangeable in the context of getting Kerberos to work.

For Kerberos use, each user must have a User PennKey, but each kerberized host must also have a Service Principal PennKey or a Cross-Realm Trust PennKey for each service (telnet, ftp, etc.).

Generic terms appear which you would need to change appropriately for your particular situation.

service: Service string as called for by the application, including host, pop, imap, krbtgt

dept.upenn.edu or theorg.upenn.edu: A DNS domain name for your organization.

machine: The specific host DNS domain name, which with the dept.upenn.edu makes the host's fully-qualified domain name (FQDN).

pennname: An individual's unique alphanumeric identifier assigned within the PennNames database and used in many Penn systems, including PennKey

KAdmin PennKey Capabilities

KAdmin Pennkeys allow creating, changing and deleting other KAdmin PennKeys and Service Principal PennKeys within the DNS domain following the "kadmin-" string. Case is observed, and KAdmin and Service Principal PennKeys must list the DNS domain in lowercase whereas Cross-Realm Trust PennKeys must list the MS domain in uppercase. One KAdmin PennKey may even delete the KAdmin PennKey which created it.

In the examples below, the realm for Penn, @UPENN.EDU, is not included since it is the default if krb5.conf is set up right.

So the example KAdmin PennKey,


may issue, change or delete all of these:

person54/kadmin-theorg.upenn.edu person55/kadmin-server1.theorg.upenn.edu person56/kadmin-www.suborg.theorg.upenn.edu ftp/theorg.upenn.edu host/server1.theorg.upenn.edu mynewservice/www.suborg.theorg.upenn.edu

but not these:


Schools' and Centers' Role

During Kerberos initial introduction, ISC issued KAdmin PennKeys. However, after an authorized individual in a school or center receives a KAdmin PennKey for its DNS domains, ISC plans not to issue additional KAdmin or Service Principal PennKeys for that school or center. Instead, the school or center will control the issuance of its KAdmin, Service and Cross-Realm Trust PennKeys. A list of KAdmin PennKey issuers is available. Systems administrators and Local Support Providers (LSPs) may contact  ISC Client Care.

ISC continues to issue User PennKeys via the applications found in Register Your PennKey.

You'll need to understand the following privileges and assign them carefully. Carelessness with a KAdmin PennKey could undermine the security of systems in your school or center.

In particular, please be aware of the following points:

  1. Only give such privileges to people whom you consider to be very trustworthy.

  2. Make sure to properly authenticate people before issuing KAdmin PennKeys. Accepting requests and issuing keys in email is unacceptable unless requests are properly authenticated (using PGP for example) and passwords properly encrypted (again, PGP).

  3. You should keep records as you issue KAdmin PennKeys to help in removing privileges or revoking keys in the future.

Models for Completing Common Tasks

Here are examples of commands that you may use as models when issuing, managing and administering PennKeys. For more details, see the man page for kadmin on your system or visit MIT's documentation website at web.mit.edu/kerberos/www/krb5-latest/doc/admin/admin_commands/kadmin_local.html.