All sessions against sicconfd start out as unauthenticated. Certain commands are usable by unauthenticated users.
To authenticate the session, one of two commands is used: session auth login <uname> <password> or session auth cookie <cookie>.
The first of these makes an initial authentication. The account name and password is checked against Kerberos, and if it matches, the session gets authenticated as the given user.
An important feature for those writing text clients is that the password can be left out, making the command session auth login <uname>. This results in a special response from sicconfd: 550 Password expected as last argument. When the client gets a 550, it asks the user for a password with the text hidden. The client then sends the same command as before, but with the entered password as an extra argument.
With this model, the client doesn't have to know any commands at all, the server says when it needs a password. Users should only be shown the command without the password argument.
When the session has been authenticated, you send commands until you're done. When you want to quit, you have two options. If you use session quit the connection is closed, and that's that.
However, if you use session quit with cookie, the server returns a cookie (at the moment 128 randomly chosen characters in the [A-Za-z0-9] set). By presenting this cookie to the server within a certain time (30 minutes being the standard), you can reauthenticate as the same user without having to enter the password. When 30 minutes have passed, the cookie ceases to be valid. Using a cookie also invalidates it. You have to do a new session quit with cookie for each session.
Reauthentication is done with the session auth cookie <cookie> command. The purpose is that web interfaces to sicconfd, which can't keep a connection open to the server during the whole execution, won't have to save the users password, but only remember a cookie (which can be used for only one authentication against sicconfd).
With each command in the command listing, the minimum rights to run the command is listed.
In general the rules are rather generous. There are superusers (albeit few) that can do everything, and domain administratos that can modify any user who has addresses in their domains.
These rules can be misused. An audit trail or log will be made available at a later date, where users can see who has done what with their accounts, and why it was allowed. For now, this information can only be read by the superusers. Contact them for help if needed.
Basically, rotating administrative rights are used. Certain users are in the list of administrators, and those in the list has the right to add new and remove old users from the same list. Thus, administrative rights can be transmitted and be passed on without interference by superusers or system administrators.
The only restriction is that you can't remove yourself from the administrator list of an object. This partly because we don't want objects to suddenly be without an administrator, and partly because it eliminates certain types of easily made mistakes.
Superusers can anything everywhere in the system.
Some things can only be done by a superuser, for example delete a user completely or create new maildomains.
The superuser group is deliberately very small. It's smaller than the group of people who has the root password on the server. Of course, everyone with root password can do whatever they want with the server, but it's a lot harder.
A very special class of people. The only thing they can do that noone else (apart from superusers) is to run the command user <uname> create.
These people are trusted by the superusers to create new accounts in a correct manner. A few people in large customer organizations can be in this group.
Addmins can only be added and removed by superusers, there's no rotating administratorship for them.
Members of the staff group are implicitly considered admins of all domains and users. As domain administrators they can therefore also modify most maillists.
They can also add and remove other users as members of the staff group.
Domain administrators are those explicitly added to the list of administrators for the domain.
When a superuser creates a domain, he or she sets a user as the first domain administrator. This user is responsible for passing this responsibility on, or sharing it.
The purpose is that the person responsible for mail of each mail domain should be the domain administrator in sicconfd. Some organization might also want all their helpdesk personnel as domain administrators.
Domain administrators also gets rights on certain mailing lists and mail accounts. To lower the risk of abuse, the list should be a short as practically possible.
Mailing list administrators for a certain list are those who has been added to the list of administrators for the mailing list.
However, domain administrators for a domain where the first domain name component is the same as the mailing list name prefix can change it. A mailing list named dtek-class-01 can thus be administered by the administrator for the dtek.chalmers.se domain.
Domain administrators can also create mailing lists, but only with names that fit the above criteria. They can therefore always add a first administrator to the list.
A user has a non revocable right to administer his or her own account.
Each account also has a rotating list of extra administrators.
Apart from this, domain administrators for all domains where the user has a mail address has the right to change the accounts settings in sicconfd.