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.
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.
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.
The way to make managing sub-administrators easier is not very userfriendly, but it's surprisingly easy.
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.
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: boks, sysadmin,
View or add comments (curr. 1)
You are free to use this specific work, to share and distribute it and to adapt it for your own purposes. However, you must attribute this work as mine and you must share all of your alterations. Click on the logo, or follow this link for full details.
Posted by Thomas
I've had an e-mail discussion with one of FoxT's experts on how we feel sub-administrators should be implemented in a future version of BoKS. This is what transpired.
==============================
>> Well, the current GUI also has sub-admin things, but I really don't like
>> the way it works. Right now it's 100% separate from the BoKS database
>> and the config is very kludgy. So if things can get integrated with the
>> DB somemore I'd be very happy.
> Do you have an oppinion on how you would like this to work?
> E.g. would you prefer to see this implemented by access route assignment,
> SUBADM: fromhost -> menu-function
> or similar?
That's a good question... An access route would be okay I guess, but then it's missing one part: defining which classes + groups someone can administer.
In our case:
* Person X = BOKS.ADM:$account
* His userclass = BoKSSupport
* He has a BOKSADM access route
* His subadmin access gives him modrights to 140+ host groups.
* His subadmin access gives him modrights to 140+ user classes
Should sub-admin access be configured through access routes? Absolutely! I want everything moved into the database. Stuff like this should not be left to individual config files on the file system. But then how do you proceed with the hostgroup/userclass admin access? That could result in hundreds of access rights, just for the subadmin stuff :/
I've discussed the matter with my colleague Wim and this is what we came up with. You'll need three new tables, plus a bunch of new method definitions of course. We do NOT want these access routes mixed in with the normal access routes in T2/T16.
T-New1 = userclass -> sub-admin access routes
T-New2 = user account -> sub-admin access routes
T-New3 = macro -> host group && macro -> user class (compare "program groups").
An access route would be something like:
subadmroute -a -u $USERCLASS -g $HGMACRO -c $UCMACRO -n ".*" -i "100-65535"
subadmroute -a -l $HG:$USER -g $HGMACRO -c $UCMACRO -n ".*" -i "100-65535"
There are of course other ways of setting this up, but this way is most like how BoKS currently works with access routes.
One thing I really -would- like is if the GUI itself changes for a sub-admin. In 6.5 and lower the interface stays exactly the same, with error messages for blocked sections. I'd prefer if those sections would disappear completely so you can't even click on them. Helloooooo dynamic Java / Ajax web interface ;)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.