SMB vs HTTP vs HTTPS

So… more on printing. Alongside documenting the service (and cobbling a nice new stylesheet together to replace the old, somewhat kludgy one) I’ve been doing some work with a stopwatch on the relative speeds of SMB vs IPP/HTTP and IPP/HTTPS. The results are slightly unusual.

  • SMB – Printing from Ubuntu and OS X is under 10 seconds for most jobs.
  • IPP/HTTP – Very fast from Windows, but Ubuntu and OS X normally around the region of 30-40 seconds.
  • IPP/HTTPS – Very fast from Windows, but Ubuntu and OS X normally in the region of 15 minutes. Yes, minutes.

I really need to convince people that SMB is a viable solution and isn’t the massive security risk they seem to think it is. It’s faster, easier and more efficient, at least until I can work out how to make a *nix CUPS server talk to SafeCom.

IPP over HTTPS, the acronyms continue!

Following our massive success of printing using SMB, and being told it was a security hole we then evaluated IPP. IPP works fine, as long as we clobber it so that it works over HTTP.

Trouble is, of course, that HTTP isn’t secure. So we need to use HTTPS, which brings with it a whole new and exciting swathe of problems to deal with. Put simply – it doesn’t work at the moment.

I’m currently trying to break in to the server at the other end so that I can see what’s going on other than the cryptic messages which get dumped to the client. I strongly suspect that somebody has forgotten to tick a box, or that HTTP authentication is disabled or using the wrong realm.

It will work, I really mean it! Even if I have to rip apart CUPS and Kerberos and slam them together in a Frankenstein’s Monster of a print system with authentication to the AD (although I’d really rather not – CUPS is a mess internally and Kerberos would involve Yet Another Server).

Update: I managed to break into the server, admittedly by getting myself set as an admin. Once inside I discovered that as I suspected HTTP authentication was disabled entirely. A quick click to turn it on, set the default domain and realm, and force clients to use HTTPS. Job done.

Next up, documentation and implementation.

Almost There…

Following a break from routine yesterday (I went to Sheffield to attend TEDx, where I learnt that I should listen to the Beatles, build cool things with Arduino, use my right brain more, disrupt things, adopt a workflow with no incentives and finally think inside and outside the box at the same time) I am back today and looking at the final pieces of the remote printing puzzle before I get back to revolutionising the way we deal with support queries.

It turns out that Windows Server since 2000 has included IIS components for doing IP Printing (IPP for short) as standard, and all you need to do is share a printer and tick a box. Even better, it comes with support for Windows Integrated Login (the amazingly annoying one which means you need to put “NETWORK\” before your username) and HTTP authentication for those of us who enjoy the *NIX approach to life (Mac guys, that includes you as well). The icing on the cake is that this authentication information is still passed all the way to the spooler in the same way as when you print locally or over the domain (as Lincoln’s printing works at the moment).

So in summary: we already have a fully featured, standards compliant (although admittedly I still need to work out exactly which ports need punching on the firewall for it to work without the HTTP transport) printing solution for non-domain machines of all OS flavours which supports authentication against our existing Active Directory with no additional hardware, software or expenditure and only a short afternoon’s work to implement it

I’ll let you know when we’re ready to let you play around.