#########################
Administrator Credentials
#########################

.. index::
   single: Kerberos; LDAP admin; AFS admin

How to make an admin hat
########################

.. _admin-hats_instances:

Kerberos
--------

This is similar to the procedure in :ref:`kdc-instances`.  Create a
prinicpal on the kdc via kadmin::

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

Note that as per :doc:`kdc` admin hats automatically have full access to the
Kerberos database through ``kadmin``.  You should probably update
``/afs/acm.jhu.edu/group/admins.pub/k5login`` file to include the new admin;
see :doc:`../afsdoc/admins-pub`.  Don't forget to ``vos release
group.admins.pub`` afterwards.

LDAP
----

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 :doc:`ldap`.

.. _admin-hats_afs:

AFS
---

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

.. note:: 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/acm.jhu.edu/group/admins.pub/UserList file must be
updated.  Update the ``.annotated`` file beside it, then derive the UserList by
running ``./scripts/afs-UserList.pl < ./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 root@typhon.acm.jhu.edu root@echidna.acm.jhu.edu root@chicago.acm.jhu.edu; do
    echo $i
    ssh -t $i sudo cp /afs/acm.jhu.edu/group/admins.pub/UserList /etc/openafs/server/UserList
  done

.. note:: 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?)...

.. _admin-hats_ssh:

SSH
---

Probably the new admin should also give an SSH key to the pool in
file:///afs/acm.jhu.edu/group/admins.pub/authorized_keys .  See
:doc:`../afsdoc/admins-pub`.