Policy 2014/08/07: Types of Accounts

On departmental machines there are of course (login) accounts. There are several types of them:

Personal accounts for (strictly personal!) use by members, students or guests of the department:

  • Intended use:
    • interactive login
    • access to files, directories, repositories, ...
    • private mailbox and calendar
  • on Intranet machines implemented via the departmental ldap
    • by default authentication via password
    • the user can setup authentication via ssh keys if needed/wanted
  • on LABO/EXP/PRO/DMZ zone machines implemented as local accounts in /etc/passwd
    • authentication only via ssh keys
    • currently the only use of this kind of accounts is for (access to) repositories on repository server(s)

Service accounts to administer some service:

  • Intended use:
    • mail-only accounts with shared (IMAP) mailbox
    • administration of some service (e.g. apache, mysql, tomcat, ...): configuration, testing, (re)starting, ...:
      • more than 1 administrator: shared administration of that service
      • there is no mailbox for these accounts ... mail is forwarded/aliased to (all) the responsible persons
  • on both Intranet and LABO/EXP/PRO/DMZ zone machines implemented as local accounts in /etc/passwd
    • for mail-only accounts authentication via password because of IMAP
      • but no interactive login and therefore /bin/false as shell
    • on Intranet machines authentication only via sudo
      • Pro: there is more accountability because you need to be authenticated locally using a regular, personal login account before you can sudo to such a service account and the sudo operation is logged
      • Contra: you need a regular, personal login account to be able to sudo to such a service account and you need a system administrator to configure the sudo-right for that/each personal login account
    • on LABO/EXP/PRO/DMZ zone machines authentication only via ssh keys and only from the Intranet
      • Pro: the ssh key(s) of a new member of the service team can be added by any current member of the service team
      • Contra: more difficult to track which of the team members uses the account
    • on LABO firewall server there exist local accounts for accessing image store. The authentication is by password.
      • Pro: easy to use for e.g. clonzilla-live users
      • Contra: allmost impossible to track the people knowing the password.
  • for security reasons we advise to separate (run-time) service from configuration and data by means of separate accounts:

Other remarks in this context:

  1. Shared mailboxes are no longer implemented using Zimbra because of irregular behavior and interference with your own Zimbra account ... we now use local/private mail-only accounts on the IMAP mail servers themselves.

  2. It is our intention to have only regular personal login accounts in ou=people in the departmental ldap and only service accounts in the local /etc/passwd (besides the system accounts of course)

    • in this way, there is a better containment and separation of regular personal login accounts versus service accounts
    • with this we hope to keep dependencies between service accounts and regular, personal login accounts to a minimum: the expected lifespan of the accounts of these types is most probably completely different and we don't want to tie (the existance or details of) an account of one type to (the existence or details of) an account of the other type

    • repository servers are an exception, but these currently only have personal accounts and no service accounts so also there no mistake/misunderstanding is possible

  3. For all accounts on LABO/EXP/PRO/DMZ zone machines and for service accounts on Intranet machines there is no password so no authentication via password is possible; but do notice that this is not the same as having an empty password!

  4. On LABO/EXP/PRO/DMZ zone machines authentication is almost allways (so for both personal and service accounts) via ssh keys (although this is less accountable than sudo) because there are no other means of authentication: there are no passwords associated with login accounts on them and therefore you cannot login locally and use sudo to login to another account (chicken&egg ;-)

    • this is partly mediated by limiting ssh access to service accounts on LABO/EXP/PRO/DMZ zone machines from within the departmental machines only ... we trust other authentication mechanisms (including process accounting and DHCP/IP/MAC address) to track when needed

    The only exception is the LABO firewall where password accessible service accounts exist to store images.

  5. For ssh key authentication for regular, personal accounts the need of such accountability is less because access to the accounts is meant to be private: only the owner of the account should have access and any other (successful) access is fraudulent (and thus expected to be hidden/camouflaged) any way.

Technical notes:

  • Service accounts have:

    • UID going downwards starting from 9999 to keep them apart from both personal accounts (going upwards starting from 10000) and system accounts (going upwards starting from 0)
    • login shell = /bin/bash or /bin/false
    • home directory in /localhost/home/... (i.e. local to the machine and not shared via NFS)
    • login group =
      • either: nogroup or users
        • we assume no group-cooperation is necessary because all team members can login/sudo to that account
        • we therefore also assume (but currently do not check nor enforce) that the home directory is only accessible for the account itself
      • or: a special, dedicated group
        • the GID's for such groups start at 1001, going upwards

  • There is a separate internal how-to actually create/manage these accounts.