Device-based permissions in a Windows Printing environment

We have a student lab that uses a single color printer and multiple print queues to handle color and b/w prints. We're also using pcounter for our auditing. We're moving off of Novell's NDPS system and onto Windows 2008, and I've hit a bit of a wall in this instance. The printing managers want to have a single printer in this lab (a Ricoh printer in this case) and have two separate print objects for color and b/w jobs, and charge separately for either.

This is not a simple thing. PCounter's color detection is not reliable in this instance so we can't use that to keep color jobs out of the b/w queue. What seems to work is if we put two different printers on the lab-stations with locked down drivers. This model worked well in the Novell environment as students would have to add the Novell Client to their laptops in order to print color jobs to the b/w queue, and we never found any who did that. A Windows printing environment changes all that since just about anything can print to Windows Print objects these days.

Our students will be able to use personal non-domained machines on the wireless network (and maybe the dorms) to map drives to the central file-servers, and presumably the central print-servers as well. We have zero ways to manage these privately owned, non-domained laptops, so do not have any kind of driver-level control; especially for all those MacBooks running around. This is why driver-level solutions are not viable.

We have to allow the entire student body to print to these printers, but we'd really like it if the spooler would only accept jobs from specific work-stations as well. Does the Windows printing environment support a feature like that?

There is no functionality in the Windows Spooler Service to allow you to set permissions on print queues based on computer used to submit a print job-- only the user.

The only even halfway decent idea that I'm coming up with is to firewall the print server queuing for this printer such that only those computers permitted to submit print jobs can access TCP ports 139 and 445. That would be tedious to configure and could cause you to need more server computer instances to service different combinations of printer and permitted computers.

I thought about trying to hack Microsoft's Internet Printing Protocol (IPP) server, but that's a really long shot. It allows users to submit jobs through HTTP over IIS, which does have the ability to permit / deny requests based on source IP or DNS name. That's a long shot, thought.

I also thought about using a custom "front-end" process running, say, an HP "direct print" (TCP port 9100) server to authorize jobs based on submitting device. It could pick them up, authorize the job, and then submit it to the back-end Windows queue. The problem there is that per-user authentication and accounting would be lost.

I think you'd do well to buttoning-down your existing queue permissions and living with per-user security.