Taking care of computers in schools can present special problems; this program solves them.
K12Admin is an account administration system designed specifically for K-12 school systems. It can be used to administer accounts on Linux servers in individual schools from a central location. The interface to the system is web-based. A teacher in a school who has been granted account-administration rights will be able to create student and staff accounts, delete accounts, create/delete local groups, modify the membership of local and global groups and change passwords within that one school.
K12Admin was developed at Coast Mountains School District in British Columbia, Canada. It was originally used to administer the accounts in an NT domain. We needed a method for allowing staff in one school to create accounts for their school without accidentally messing with accounts from other schools. The web interface and database ran on a Linux machine, and account changes were made on the NT Primary Domain Controller using a TCP/IP connection. Soon after this, we set up a Linux server in each town to use as an authenticating proxy server. The Squid logs on each of these servers were copied to the main account administration computer and analyzed for potentially inappropriate use by scanning for a list of keywords in the URL.
Figure 1. Main K12Admin Menu
Many accounts had already been created on the NT system before we set up the Linux server for account administration, so we did not have UNIX passwords for these accounts. To solve this problem, we modified the source for the Squid proxy server so that it redirected users to a page where they could “register” their account if proxy authentication failed. The user name and password they entered here were checked against a POP server running on an NT server before being added to the password database on the Linux servers.
Once we had UNIX passwords for all users, it became possible to use Linux servers in the schools.
When accounts are created, a list of first and last names is typed or pasted into a text box. Unique user IDs are created using the first and last names of the users. There are currently two different user ID creation schemes in K12Admin. One uses part of the first name and all of the last name. Under this scheme, my user ID might be stonnesen, sttonnesen, stetonnesen, etc. until a unique user ID was found. The second scheme uses the first name and the initial letter of the last name. Under this scheme, my user ID might be stevet, stevet2 or stevet3 until a unique user ID was found. This second scheme makes for a more anonymous user ID if protection of children's privacy is a concern in your district.
Figure 2. Form for Creating New Accounts
When accounts are created, each user ID can be assigned an individual password by the administrator, all accounts being created can be assigned the same default password, or random passwords can be generated for each account. Currently, the random passwords generated consist of a three-letter word, a single digit, plus another three-letter word (e.g., far6yet). With the word list I'm using, this results in a password space of just under 2,000,000 passwords. Not exactly the best security you could ask for, especially since my list of three-letter words is now quite public. I am considering adding an option to generate truly random passwords (such as “a5Tr43Zp”), but these are quite difficult for students to remember. It might be better just to instruct students (and staff) on good password-selection techniques and get them to change their assigned passwords right away. K12Admin has system-wide global groups that grant special-access privileges to users:
Web Users: members can authenticate with a proxy server to access the Web.
Dial-in Users: members can access dial-up pools.
Account Administrators: members can administer accounts in their school.
Application Administrators: members have read/write access to application shares on their school server.
Library Administrators: members have read/write access to a Library software share on their school server.
School Administrators: members have access to a share for school administrative software.
Figure 3. Account Administration Menu As Seen by School Administrator
Web Administrators: members have access to the root directory of the school's web server.
Domain Administrators: members have access to all schools in the system and can set system-wide configuration options.
Figure 4. Account administration Menu As Seen by District Administrator
In addition to the global groups, local groups can be created which are unique to each school. These can be used to create class groups (Grade 7, Grade 4/5, Division 14, etc.) or other logical groupings (Yearbook Club, Computer Club, etc.).
Accounts can be modified by account administrators or by users. The users can change their passwords, review a security audit of their account, or review potentially inappropriate web use by their account. Account administrators can change passwords and add/remove users to/from groups.
Figure 5. Form for Removing Accounts
In the rest of this document, I will refer to three different types of computers. The k12admin-server will be the central account administration computer for the district. The k12admin-client computers will typically be Linux servers in the schools that update their account information from the k12admin-server computer. These computers will likely be used as web proxies, file servers, web servers, e-mail servers, etc. Lastly, I will refer to the computers our users sit at as workstations.
K12admin-client computers run updates once an hour. The updates are done using rsync and ssh to securely and quickly copy files from the k12admin-server and run a script, called “setup”, which is part of these files. Password files (passwd/group, shadow/gshadow, smbpasswd, squid.auth, apache.auth) on the client are updated at this time. The hourly update also runs some audits of the school server. Specifically, it scans the log files and generates a synopsis of which accounts have been used and when. This information is sent back to the k12admin-server computer, where it is inserted into an audit database which can be queried by the user. This allows a user to determine if their account is being used inappropriately.
Figure 6. Audit of Account Usage for User “demoteacher”
The Squid proxy log files on the k12admin-client computer are also scanned for potential inappropriate use. The log files are scanned for one of a list of keywords. These keywords can be grouped into different categories (porn, chat rooms, gaming, executable downloads) and enabled or disabled on a per-school or per-server basis. Again, this information is transferred to a database on the k12admin-server where it can be reviewed by school administrative staff at any time. A synopsis is also e-mailed to school administrative staff weekly.
Individual k12admin-client servers can be configured from the web page with a variety of options. They can be attached to one or more schools. You can also have more than one server attached to the same school. This allows you to have one server for two small schools connected by Ethernet, or have several servers in a large school. Servers can be configured to update passwd/group files, update smbpasswd files, update Squid-authentication files, update Apache-authentication files, create home directories for new accounts, and clean up old home directories, either by deleting them outright or moving them to a temporary holding area.
The K12Admin system is quite functional as it stands. However, my goal is to create a server appliance which can be placed in a school and administered entirely through the K12Admin interface. What I see happening in schools now is that a teacher is given “release” time to maintain the network in the school. Attempts to “homogenize” the network are difficult when teachers in individual schools have invested significant amounts of time in learning how to run their chosen network operating system and setting up their network. In order to make K12Admin a viable alternative, I see a few obstacles to overcome:
Server administration must be easy to learn. Since K12Admin is geared specifically to a K-12 setting, it should have an advantage over a vanilla, out-of-the-box, network operating system.
The servers must be flexible enough to serve the needs of all users in a K-12 setting. Since I have experience with only one school district's way of doing things, I need feedback from other users to determine which options are required to meet their needs.
When problems do occur, they should be easy to diagnose, both for technical staff and the users in the school. I have some problem-diagnosis tools in place for monitoring disk space, swap space and “stuck” printer spools. These tools need to be expanded. I was hoping to incorporate the “Big Brother” network monitor to take care of some of this, but the license is too restrictive.
Here is a list of planned additions to K12Admin:
Creation of default shares on the client servers (exported by Samba, Netatalk, NFS, Coda, etc.)
Applications: general applications used by client computers, be they Macintosh, Windows, Linux or whatever. There will, of course, be separate shares for each type of client computer.
Library: share for library administration software.
Administration: share for school administration software.
Localgroups: share holds a directory for each local group created within the school, accessible only by members of that group. This share will contain a class folder for which teachers have write access, a drop box, and a public folder to which everyone can write. This makes it easy to share files with the members of your class or some other logical group.
HTML: web server root directory.
CD: a share where CDs can be copied in order to be shared back to client computers.
Default: skeleton files for creating new user home directories are placed here.
Rebuild: share for storing images of client workstations for rebuilding purposes.
More server configuration options, such as the ability to configure the services which should run on a particular server (i.e., dhcpd, Samba, Netatalk, Apache, Squid, etc.).
Monitor the status of services that have been configured to run on each server. Possibly integrate the “Big Brother” network monitoring tool, if its license allows.
Integration with Bruno Vernier's EDUML standard.
Possible integration with the Roster project. Roster is a server configuration system designed for college/university applications. It contains methods for updating server types other than Linux.
Modularize (OOP!) the data layer (Roster has this already and might be usable).
Extend the Squid proxy scan to scan the HTML files in the Squid cache, matching files to URLs using the Squid logs.
Ability to add users to multiple schools. Useful for staff members who teach part time in two schools, or district staff who may work in all schools in the district (this latter case is a special one that should probably be handled differently).
Generic configuration of system files such as Samba configuration, Squid configuration, Netatalk configuration, network configuration (dhcpd, IP masquerading, etc., using private IP addresses).
Support for having “backup” k12admin-server machines that synchronize their databases with the main k12admin-server and can be used for automatic failover protection.
Packages are provided for installing on Debian and Red Hat systems. There is also a tar archive file for installing on other systems.
There are two packages: k12admin-server and k12admin-client. The k12admin-server package should be installed only on the computer that will be the main account administration computer for your district. The k12admin-client package should be installed on every machine that will be updated from the k12admin-server machine.
The k12admin-server package contains the files necessary to use a machine as the central account administration server. Typically, you will want k12admin-server installed on only one machine in your district. It is possible to install the k12admin-client package on the same machine as the k12admin-server package, although for security reasons this may not be desirable. It would be better if the accounts on the server computer were administered manually, so that students and staff members do not have accounts on the server and are less likely to try mucking around there.
Install the k12admin-server package by running
dpkg -i k12admin-server*deb
or
rpm -i k12admin-server*rpm(use -U in place of -i if this is an upgrade) in the directory where you have stored the package. If this is a first install, you will be told to run k12admin-server.setup as root to create the MySQL database. This file was placed in the /usr/bin/ directory when the package was installed, so it should be in your path.
If you are installing the package from a tar file, unpack the archive, go (cd) to the k12admin-server* directory and run make install to install the package.
In order to create the MySQL database, you will need to enter the root password of your MySQL server. Note that the MySQL root password is not the same as your normal root password. You should have been prompted to enter a password for your MySQL server when that package was installed. The script will allow you to keep trying passwords until it succeeds. Just press ENTER if your MySQL root password is blank. If this is the case, the k12admin-server package will prompt you for a new password, as it is a grave security risk to have a blank MySQL password.
The second password asked for by the k12admin-server.setup is one for the k12 MySQL user. This user is used by the scripts to connect to the MySQL database. You do not need to memorize this password, as it is stored in the /etc/k12admin.MySQL.pass file which is readable by the k12admin and www-data users only. You can change this password at any time by rerunning the k12admin-server.setup program.
Now you must configure Apache so it knows where the k12admin files are located. Once Apache is configured and reloaded, you should be able to access the account administration system at http://yourservermachine/k12admin/ from any web browser. Log in as user demoteacher with demopass as the password.
I strongly recommend using apache-ssl (http://www.apache-ssl.org/) in order to encrypt packets between your web browser and the k12admin-server. This is especially true if there is potential for someone to be sniffing packets that are being transmitted. The basic authentication that is part of the HTTP standard is not encrypted, and your password can be grabbed easily off every outgoing web request if you are not using a secure server.
You must edit the Apache configuration files to enable the account-administration system. Add the following lines to the bottom of Apache's access.conf file:
Alias /k12admin/ /var/k12admin/web/
ScriptAlias /k12admin-cgi/ /var/k12admin/webscripts/
<Directory /var/k12admin/>
AllowOverride AuthConfig
</Directory>
You might also have to change the user and group of the Apache web server process. It may be set to “nobody” by default. The web server process must have access to the database containing sensitive account information. The password for accessing the database is stored in /etc/k12admin.MySQL.pass and is readable by only the www-data user and the k12admin group. It is, therefore, necessary to have the Apache process running as www-data. This account was created when k12admin-server was installed, if it didn't already exist.
To set the user and group of the Apache process, change the following lines in Apache's httpd.conf file:
User www-data Group www-data
Reload Apache after making these changes. On Debian systems, reload Apache by running
/etc/init.d/apache reloador
/etc/init.d/apache-ssl reloadOn Red Hat, run
/etc/rc.d/init.d/httpd reload
The k12admin-client package contains the files necessary to update a machine using information from the k12admin-server machine.
Install the k12admin-client package by running:
dpkg -i k12admin-server*deb
or
rpm -i k12admin-server*deb(use -U instead of -i if you are upgrading) in the directory where you have the package. If this is an initial install, you will be asked to run k12admin-client.setup as root.
If you are installing the package from a tar file, unpack the archive, go (cd) to the k12admin-client* directory and run make install to install the package.
You will be asked for the name of the k12admin-server and the root password of that machine. The name of the k12admin-server can be an IP address or a host name (as long as the host name can be resolved to an IP address, of course). Once you supply the server's host name, the post-installation script will try to connect to the server using ssh to inform the server that it has a new client and copy the client's ssh key to the server. The ssh program will ask you for the root password of the server machine. The root password is not stored anywhere by the post-installation script. If you ever wish to connect your k12admin-client computer to a different k12admin-server machine, simply rerun the k12admin-client.setup program.
After the post-installation script completes, the server will take up to five minutes to notice the new client and register the new ssh key. Configure the new client by using a web browser to access the account administration system. From the main menu, select “Domain Tools”, then “Edit Servers”. Your new client should appear in the list of servers. Select your new client server and click on the Edit Server button, then configure appropriately.
Every five minutes, the data in the MySQL database on the server is converted to plaintext files which can be copied to the clients and used to update their local files. This process is accomplished by the /var/k12admin/scripts/server/k12.updateserver script. This script is run by cron every five minutes as the k12admin user. It can also be run manually, but it must be run by the k12admin user and not by root. When this script is run, it generates several files in the /var/k12admin/serverdata/ directory that are used by the clients. This script also uses a lock file in the /var/k12admin/lock/ directory to prevent multiple instances of k12.updateserver from running simultaneously and to prevent clients from performing their updates while the files are still being generated.
There is another key file in the /var/k12admin/serverdata/ directory, called “setup”. This file contains all the code used for updating and auditing the clients. This file is copied to the clients before the clients are updated, so do not edit this file on the clients if you are trying to add new features—edit it on the server.
On the client machines, updates are done once an hour. The script that does the updating is /usr/bin/k12.updateclient. Since this script must modify key system files, it is run as root from the system crontab file.
If run interactively, this script executes /var/k12admin/clientdata/setup with no command-line arguments. To avoid any delay in the menu coming up, the rsync is not performed. One option on the menu is to perform the rsync, if the latest data from the server is desired.
If run with command-line arguments, the script first runs rsync (using ssh as the transport agent) to sync all the files from the /var/k12admin/serverdata/ directory on the server to the /var/k12admin/clientdata/ directory on the client, then executes /var/k12admin/clientdata/setup with the same command-line arguments it received.
If the script is run without arguments, it will enter an interactive mode and present a menu of options from which to pick. It will also show progress information that is not displayed in the batch (non-interactive) mode. In batch mode, the following arguments can be supplied:
k12.updateclient auto: performs all client update routines.
k12.updateclient passwd: updates all password files (passwd/group/shadow/gshadow/smbpasswd/ squid.auth/apache.auth).
k12.updateclient audit: performs security audit on the client. The generated information is copied to the server, where it is inserted into the audit table in the database.
k12.updateclient homedirs: creates new home directories and cleans up old home directories.
The setup program contains the following subroutines:
auto: runs the passwd, homedirs and audit subroutines. This is the subroutine that is called from the crontab file.
rsync: syncs the data from the /var/k12admin/serverdata/ directory on the server to the /var/k12admin/clientdata/ directory on the client. When setup is run interactively, this syncing is not done before the menu is brought up, so if you need the latest data from the server, choose this option first.
passwd: updates the passwd, group, shadow, gshadow, smbpasswd, squid.auth and apache.auth files, depending on the configuration of the server.
homedirs: creates new home directories and cleans up old ones. Old home directories can either be left alone, deleted or moved to a temporary holding area (/var/k12admin/oldhomedirs/) where they are deleted when they are 30 days old.
audit: run a security audit on the local server. This goes through various log files and determines which accounts have been used. This information is copied to the server, where it is added to the audit table in the database, so any user can review where and when their account has been used.
atalktable: generates a mapping of AppleTalk nodes to AppleTalk computer names.
squid: audit of the Squid proxy authentication files.
apache: audit of any authenticated access to an Apache web server.
netatalk: audit of access to AppleTalk services (logins from a Macintosh computer).
samba: audit of access to Samba services (logins from a Windows workstation).
ssh: audit of ssh (secure shell) connections.
squidmonitor: not really a security audit, this searches through the proxy logs for any potentially inappropriate web browsing and also sends this information back to the server computer for review by school staff.
Steve Tonnesen (tonnesen@cmsd.bc.ca) works at Coast Mountains School District in Hazelton, BC, Canada. Coast Mountains School District has 30 schools and 5,000 students.
