Account Administration for K-12 School Systems
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.
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.
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.
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.
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.).
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
|NVMe over Fabrics Support Coming to the Linux 4.8 Kernel||Aug 22, 2016|
|What I Wish I’d Known When I Was an Embedded Linux Newbie||Aug 18, 2016|
|Pandas||Aug 17, 2016|
|Juniper Systems' Geode||Aug 16, 2016|
|Analyzing Data||Aug 15, 2016|
- Updates from LinuxCon and ContainerCon, Toronto, August 2016
- NVMe over Fabrics Support Coming to the Linux 4.8 Kernel
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- New Version of GParted
- All about printf
- Analyzing Data
- Tor 0.2.8.6 Is Released
- Blender for Visual Effects
- Juniper Systems' Geode
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide