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.).
- Free Today: September Issue of Linux Journal (Retail value: $5.99)
- The Tiny Internet Project, Part I
- Bitcoin on Amazon! Sort of...
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Android Browser Security--What You Haven't Been Told
- Returning Values from Bash Functions
- Epiq Solutions' Sidekiq M.2
- Securing the Programmer
- Nativ Disc
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide