Administrator Credentials

How to make an admin hat


This is similar to the procedure in Using Multiple Instances. Create a prinicpal on the kdc via kadmin:

addprinc ${USER}/admin
pts createuser ${USER}.admin

Note that as per Kerberos KDC admin hats automatically have full access to the Kerberos database through kadmin. You should probably update /afs/ file to include the new admin; see The Special Case of Don’t forget to vos release afterwards.


For LDAP to consider this user an administrator, a new entry must be created:

dn: cn=admin,uid=${USER},ou=People,dc=acm,dc=jhu,dc=edu
cn: admin
uid: ${USER}
objectClass: jhuacmKerberosInstance

For details, consult LDAP.


For AFS to consider this user an adminstrator, this user must be put in the system:administrators group and by convention we keep the non-admin hats of administrator users in a separate group:

pts add ${USER}.admin system:administrators
pts add ${USER} system:non-admin-hats


No non-.admin credentials should ever be present in system:administrators.

To make the user an AFS superuser, which grants ability to manage the AFS servers, the file:///afs/ file must be updated. Update the .annotated file beside it, then derive the UserList by running ./scripts/ < ./UserList.annotated. Then release the volume (which will suffice to update the machines which are AFS file servers) and inform the ubik servers by hand:

for i in; do
  echo $i
  ssh -t $i sudo cp /afs/ /etc/openafs/server/UserList


We have to do the latter stage separately because the release will break callbacks, and the Ubik servers will attempt to read the UserList after the callback is broken, and will time out. This is sad. Ideally, the VLDB should be a client of the PRDB for these operations (unless a flag is given?) and the PRDB should interrogate itself rather than UserList (again, unless a flag is given?)…


Probably the new admin should also give an SSH key to the pool in file:///afs/ . See The Special Case of