Making managing BoKS sub-administrators easier

2009-09-28 10:23:00

BokS' administrative GUI is far from a work of art, at least those versions I've worked with (up to and including 6.5.3). The web interface feels kludgy and it's apparent that it was designed almost ten years ago. I'm aware that FoxT are working on a completely new Java-driven GUI, so I'm very curious to see how that turns out!

In the mean time I've asked them to look at an improvement regarding the GUI that the might not have thought of before: the management of sub-administrators.


How do sub-administrators work?

In BoKS one can opt to delegate certain administrative tasks to other departments. For example, one could delegate the creation of simple Unix user accounts to the help desk in order to free up time for the 2nd and 3rd lines of support to do "important" things. In BoKS people with delegated access are called sub-administrators. It's important to remember that -everybody- with the "BOKSADM" access route gets full access to the BoKS web interface, unless they're defined as sub-admins.

According to the BoKS manual the following tasks can and cannot be delegated.


CAN be delegated CANNOT be delegated
User Administration
Access Control (partial)
Host Administration (partial)
Virtual Card Administration
Encryption Key Administration (partial)
Log Administration
Integrity Check
File Monitoring
Database Backup
User Inactivity Monitoring
Host Administration (partial)
LDAP Synchronization
Password Administration
UNIX Groups Administration
Sub-Administrator Configuration
BoKS Agent Configuration
Authenticator Administration
CA Administration

Within each section it's possible to further limit the administrative rights. For example, if you allow your help desk to create simple Unix accounts you may want to limit them to a certain number of user classes, host groups or UID ranges. This can be done, but is quite a hassle. You will need to configure each user separately, on a per-user basis. Frankly, doing this through the web interface sucks, especially if you have a huge list of user classes and want to include/exclude large numbers of classes.

Luckily there is a way to make things a -little- easier for yourself.


What happens under water? Configuration files galore!

I found out that all sub-administrator configuration is held on the file system and NOT in the BoKS database. I found this a bit odd, as it seems logical to keep stuff like this in the DB. This is also why I issued my original feature request: to bind sub-admin rights to BoKS user classes. But no, for now (BoKS 6.5.3 and lower) this config is held in $BOKS_var/subadm.

After enabling sub-administrator access for a particular user BoKS will create a new file in this directory, called $HOSTGROUP:$USERNAME.cfg thus binding it to a specific account. Browsing through this file I discovered how the access limitations work and to be honest: IMNSHO it's a kludge. For each particular section of the BoKS interface you will find a function (TCL subroutine?) that looks something like this:

boks_subadmin_check_$SECTION {
if "getlist" { return "ENTRY1 ENTRY2 ENTRY3 ... ENTRYn" }
if "changeitem matches ENTRY1 || ENTRY2 || ENTRY3 || ... || ENTRYn" { return 1 }
}

That's right, the configuration file actually contains subroutines that return a 0 or a 1 depending on which access rights you've given the user. If you've given him access to a hundred user classes there will be a subroutine with an IF-statement that has a hundred || OR-statements. Ouch. I've said it before and I'll say it again: it's time for a proper (relational) database.


Work around: making sub-administrator templates for BoKS

The way to make managing sub-administrators easier is not very userfriendly, but it's surprisingly easy.

  1. Convert one team member to sub-admin.
  2. Configure this one person through the web interface.
  3. Login to the BoKS master server and become root.
  4. Go into $BOKS_var/subadm.
  5. Copy $HOSTGROUP:$USERNAME.cfg to $USERCLASS.template, then chmod 644.
  6. for USER in $(classadm -L -u $USERCLASS); do cp -p $USERCLASS.template $USER.cfg

Done!

Obviously you'll want to copy $BOKS_var/subadm to all your replica servers as well. If you don't you'll give -everyone- with an "BOKSADM" access route full access to the GUI. I suggest setting up an rsync for this.


One final, very big "gotcha!"

My colleague Wim realized that the current way of sub-admin delegation has one very big flaw. Every time you add a new host group or user class you will need to update all .CFG files to match this. Of course, using the aforementioned templates will make this easier because you can update one file and then copy it to the whole team. But still...


kilala.nl tags: , ,

View or add comments (curr. 1)