Print servers are generally the opposite of exciting. Environments that only use AD connected Windows clients simply add Print Services and go. Users can use point and print, or admins can deploy printers via GPO. The Windows print server will even install drivers for the client systems and update them if needed. What happens when things aren’t quite as homogeneous?
The Scenario
Printing needs to be provides for multiple OSes including Windows, MacOS, Linux, ChromeOS, etc. Add in that a significant portion of clients are bring-your-own-device (BYOD) that belong to the individual and are not actually managed by IT.
The basic Windows print server starts to break down. The deploy drivers feature doesn’t work for a number of clients and point and print is invalid for a sizable group of users.
There are some products that provide printing service in similar situations, but that doesn’t make for an interesting story. Can we build something that can provide services and does not require purchasing and introducing a new product/technology? That is interesting, at least as interesting as a print server gets.
The goals are simple:
- Solve the BYOD issue. Make it simple and straight forward for users to connect their systems to the available printers.
- Minimize client interruption when a printer is replaced.
- Use the same system for 95+% of printing needs. This includes the managed Windows AD systems as well. There are a number of reasons that one-offs may happen, but keep them to a minimum.
With these goals in mind, I decided that the print server will have the following feaures:
- Use IPP for all clients. This is a well defined protocol that is available to practically all clients.
- Use SSL encryption between the client and the server. The server will answer on the standard HTTPS port so that the chance of firewall issues between networks or client security suites are minimized. We don’t want any sensitive information sent to the printer in the clear.
- Provide useful logging of print jobs
- Clients should generally use generic drivers (PCL or PS)
Evaluating Options
Without purchasing a third party solution, our options are:
- Use Windows Print Services
- Use CUPS
Feature 1: Use IPP
Both options can serve as an IPP print server. Windows by uses IIS to provide IPP services. This is actually a nice feature as it provides browsing to clients using a system that is designed to serve the purpose.
CUPS is IPP. There isn’t anything special to do. Simply add a printer and share it.
Feature 2: Use SSL
Due to the diversity of clients that will use the service(BYOD), the print server will use an SSL cert signed by a trusted CA. No self signed certs allowed. Because Windows uses IIS to provide IPP services, it is very easy to add SSL protection to all printing. Also, managing the service port is exactly the same as any other IIS hosted service. This creates nice consistency of management for those that are predominately Windows shops. It’s fairly simple and straight forward.
CUPS on the other hand doesn’t play nicely with SSL. It is quite easy to find Internet posts detailing various problems with SSL and CUPS. The greatest concern may be securing SSL. There didn’t seem to be any way to limit the ciphers used so the server could use weak or broken ciphers and leave communications vulnerable. The newest versions of CUPS may have addressed some of the issues, but maintaining and patching a production system is typically much easier (read secure) when using packages from the distro.
The workaround for CUPS in this case is rather simple. Copy the Windows method. Install a webserver and configure the webserver to act as a reverse proxy for the CUPS service. The webserver can provide all SSL services and the clients can use the standard HTTPS port that the webserver listens on by default. In addition, the SSL becomes fully configurable, just like Windows. Another benefit of this extra layer is the method of restricting access to printers. While CUPS does have various access controls, using the webserver seems more flexible to me. The webserver’s configuration can be used to restrict access to individual printers via the Location directive. This allows one printer to be restricted to a specific set of IPs while others remain open. Using the extra layer to solve the SSL problem turns out to be a nice feature.
Feature 3: Useful Logging
Useful logging is heavily influenced by the environment in which the service is run. Both Windows and CUPS allow for logging to a central log server, though each in the underlying system’s own way. Windows has the Event Logger and Windows Event Forwarding while CUPS (*NIX) has syslog. The existing infrastructure will probably hold final sway in which system “wins” this feature.
If things are “equal”, CUPS does provide a logging advantage over Windows. Windows captures the user that printed as IUSER_ANONYMOUS for unauthenticated printing. CUPS, on the other hand, is able to capture the username of the user that is logged into the system. For clients that authenticate against AD or other central service, this is the user’s username. For the BYOD devices it’s whatever username they are using on the system that is printing. This may not always be the best or most reliable information, but it is better than not having the information should there be a need to track something down.
I was not able to get authenticated printing working on the Windows server, but the issue seemed to be on the client side and not the server. A number of sites indicate that it “should work”. I have not yet had a chance to test authentication via the CUPS server. I will update this information once I have had the chance to test authentication with the CUPS server. I hope to find that I can use the webserver configuration to control authentication/authorization on a per printer basis similar to what was described in the SSL section.
Feature 4: Use Generic Drivers
This is targeting goals 1 and 2. Users shouldn’t need to find, download, and install drivers for a specific printer. Also, should a printer be replaced with a different brand/model, clients can continue to print as they were before without any interaction or modification.
The drawback to using generic drivers is that some advanced features may not be usable. The most commonly used example of a missing feature is duplex printing. Users may not able to use duplex printing on a specific print job. This, so far, seems to apply more to Windows clients than other operating systems. Other missing features would be any number of finishing functions or accounting controls that require native print drivers. If required, native drivers can be installed as needed.
How It’s Working
I ended up using the CUPS option. The winning factors revolve around consistency with existing infrastructure and logging of usernames.
So far things are going rather well. The biggest issue to this point has revolved around the generic driver to use. Older printers may not recognize the PCL language version. Some printers are slow when using the PS driver versus PCL driver. These issues are usually resolved by switching to the other driver.
Interestingly, there were a couple of odd printing issues that were resolved by using the print server. In one case, a user could not print to a specific printer regardless of setup including direct ip and native vendor drivers. Another user would experience very long delays when printing from a Mac. In both cases, going through the print server corrected the issue.
It’s still too early to declare success, but it’s moving on the right track.