Without at least the threat of harm you cannot enforce a student booting your Exam OS. Skip to the horizontal rule for how I would achieve your overall goal. This is how I would fool your system:

I would boot into my Linux, where I will always have root privileges and everything I may need. Then I would mount the Exam OS root file system. That file system is on the CD you gave me and I will always be able to mount it. Then I would open a new terminal, chroot into Exam OS and fire up Exam OS inside that chroot-jail. If you based Exam OS on Debian or one of its derivatives I'd

/etc/init.d/rc S
/etc/init.d/rc 2

In effect I will have your Exam OS, which means I have everything you want to give me and at the same time I have my own Linux for everything you don't want to give me.

Maybe I'm overshooting a little by running /etc/init.d/rc S and probably should restrict myself to running /etc/init.d/rc 2 only. Every distribution has an easy to find out similar magic incartation.

Yes, you can go to war and make this cost me valuable exam time, but for every minute you cost me you have to invest several hours! Also, you have to make Exam OS refuse to boot inside a virtual machine, as that's another option to fool your system.

So much for the destructive part, let's get constructive. :-)

If you don't want students doing something, tell them and fail them, if they break that rule. That has worked for centuries! I would hand out Exam OS CDs and tell them using another OS during this exam is considered cheating. Now we have that problem solved. All we need to do now is catch them cheating (which they most likely won't anyway anymore).

To create Exam OS I'd modify some existing Live-CD. Which is almost irrelevant, however, it will be easiest if it is some "full scale" Linux so Ubuntu and Fedora are the first that come to mind, here is an incredibly large list of alternatives. I'd pick the one with the best documentation on how to create/rebuild the live-cd! The finished Exam OS would have to fulfill the following requirements:

1. students have quick access to all programs I want them to have
2. the desktop has distinctive design/skin so I can tell from a distance with 80% certainty if somebody is not using Exam OS
3. no username password authentication is required by default
4. to log in as another user, su or sudo you need an USB-stick (the one on your keychain) to authenticate
5. have funky network settings so to restrict the internet and local communication to fit my needs.
6. have a customised kernel that doesn't even have support for bluetooth, irda or any other subsystem than ethernet that could enable communication. USB needs to be restricted as well!

1 basically means I put desktop shortcuts to everything I want them to be able to use. That way I would have easy testing if everything works.

To achieve 2 I would skin the desktop with the school colors and an occational logo so that I recognise the Exam OS desktop when I see it. During the exam, when I see odd colors or pictures or even miss something I know should be there I can investicate more closely.

3 is easy, makes Exam OS uncomplicated and when I think somebody is cheating I can close the laptop, turn it around and open it up. When I see an Exam OS I appoligise, if I don't or even see a locked screen I caught someone cheating.

4 means to harden the system so you can only become root by having my usb key. There is a pam module for that so the USB-stick authentication is not hard to do (google pam_usb). With the basic OS of a live CD and that pam module in place for any service that can be used to get super user privileges, i.e., login, su, sudo and maybe some desktop manager and sshd, it should be sufficiently hard to become root. After that one still has to make sure that the normal user may not edit important configuration files and directories!

5 means no nameserver-entry in /etc/resolv.conf but some entries in /etc/hosts for all the websites I want the users to be able to visit. Also there needs to be a restrictive firewall which drops all incomming and outgoing packets and for each host I want the students to be able to reach an exception by ip-address has to be defined.

6 means just that. take the config from the generic kernel of the live-cd you chose and rip out all the subsystems you don't want. sound, video for linux, bluetooth, everything that is not needed during the exam. Rip out everything usb that is not usb-hid and usb-storage. Very important w.r.t. USB-stricks: remove all the filesystems that you do not need, and keep only those you need. For the authentication stick I would choose some odd FS that nobody anymore. Maybe even an experimental one that is not part of standard linux.

That's a rough guide only, sorry :D

1.

So your first problem seems to be this:

Currently not working:

• Cannot add the Windows printer driver to CUPS using the "printmanagement.msc" MMC (I get a "access denied" error). So Samba's Point'n'Print will not work.

Note, that the Windows clients do not retrieve their printer drivers from CUPS, and CUPS itself cannot communicate with the Windows clients directly.

Only Samba can do that, so Windows clients will retrieve their printer drivers from Samba. Samba poses as a Windows print server for the clients, and Samba will also provide a special share (listed [print$] in smb.conf) for clients to auto-install the drivers from. (You should try to use the UNC path of \\myserver\print$ or \\myworkstation\print$ in Windows explorer and see the drivers from any host which shares a printer.)

Windows users need a special privilege in to administer printers and configuring/uploading drivers. This privilege was named SePrintOperatorPrivilege by Microsoft.

Samba implements the SMB set of Windows networking protocols and procedures so Windows clients can use its services.

Hence, only users which have this privilege granted can upload and preconfigure printer drivers to a Samba server, just like it would be the case for a Windows print server.

Typically, you would want to grant the privilege to the Domain Admins group, plus, maybe another Domain Group you may have called Our Printer Admins. I now assume your domain name is MYDOMAIN.

To grant the named user groups that right, execute the following commands:

  net rpc rights grant "MYDOMAIN\Domain Admins" \
     SePrintOperatorPrivilege -U "MYDOMAIN\administrator"

  net rpc rights grant "MYDOMAIN\Our Printer Admins" \
     SePrintOperatorPrivilege -U "MYDOMAIN\administrator"

  net rpc rights grant "MYDOMAIN\User54321" \
     SePrintOperatorPrivilege -U "MYDOMAIN\administrator"

In each case you'll be prompted to supply the domain admin password:

  Enter MYDOMAIN\administrator's password:

If you know this password and everything works, you'll see this confirmation:

  Successfully granted rights.

Of course, you could grant this privilege to one or more individual domain users (example above: MYDOMAIN\User54321) too. But this is not recommended. Better grant the privilege to a group instead of individual accounts. This enables you to add and revoke the privilege by updating the group membership.

To list all users and groups having the SePrintOperatorPrivilege privilege granted, enter:

  net rpc rights list privileges SePrintOperatorPrivilege\
     -U "MYDOMAIN\administrator"

You should see the following output:

  SePrintOperatorPrivilege:
     BUILTIN\Administrators
     MYDOMAIN\Domain Admins
     MYDOMAIN\Our Printer Admins
     MYDOMAIN\User54321

You've now created the pre-condition that users listed above can upload and install printer drivers to your Samba server.

(Update: Just had a closer look at the smb.conf you quoted above... Replace MYDOMAIN\ with MYWORKGRP\ for the commands I gave, or skip it altogether and just use a user name or a group name known to Samba. You could possibly also temporarily try guest ok = yes inside the [print$] stanza. Don't forget to set it back to no once your drivers are in place...)

2.

Your second problem seems to be:

It seems CUPS default options interfere with the workstation's ones: I set duplex printing off by default on CUPS but want it to work if the user tick the checkbox on it's printing settings.

Where should I go to make CUPS use user's settings?

CUPS by default does not "filter" print jobs it gets handed over by Samba. It processes them as "raw" jobs and just passes them to the real print hardware device.

So if the driver is correctly installed on the Windows print clients, whatever job options they click, should be honored by the printer, regardless of default settings which may be configured into CUPS for CUPS-local printing...

You cannot "make" CUPS use user's settings -- CUPS will just pass them through.