kadmin.local Authenticating as principal root/admin@REDFLO.DE with password. kadmin.local: ? Available kadmin.local requests: add_principal, addprinc, ank Add principal delete_principal, delprinc Delete principal modify_principal, modprinc Modify principal change_password, cpw Change password get_principal, getprinc Get principal list_principals, listprincs, get_principals, getprincs List principals add_policy, addpol Add policy modify_policy, modpol Modify policy delete_policy, delpol Delete policy get_policy, getpol Get policy list_policies, listpols, get_policies, getpols List policies get_privs, getprivs Get privileges ktadd, xst Add entry(s) to a keytab ktremove, ktrem Remove entry(s) from a keytab lock Lock database exclusively (use with extreme caution!) unlock Release exclusive database lock list_requests, lr, ? List available requests. quit, exit, q Exit program.
You see: you don't need a password and you get a list of commands with "?". Let's see what principals we have:
kadmin.local: list_principals K/M@REDFLO.DE kadmin/admin@REDFLO.DE kadmin/kerberos.redflo.de@REDFLO.DE kadmin/changepw@REDFLO.DE kadmin/history@REDFLO.DE krbtgt/REDFLO.DE@REDFLO.DE
The first principal is the master database account. The kadmin/* principals are to authenticate the kadmind server. Remember the difference: we have 3 user principals for the user kadmin and one service principal for the service kadmin. The last principal is a "ticket granting ticket" principal. The instance name is the same as the realm name. We'll talk about that later (todo).
If you try to use kadmin instead of kadmin.local you'll get:
kadmin Authenticating as principal root/admin@REDFLO.DE with password. kadmin: Client not found in Kerberos database while initializing kadmin interface
Why? Simple: We did not setup a user-account with "admin" instance and password.