Posts tagged authentication

As you know, I love logging in to University services. I love needing to know which combination of my student ID, account ID, account ID with the “NETWORK/” prefix, email address, password and PIN I need to use. Which is why I’m such a big fan of building a reliable login system which just authenticates you once for everything.

This blog post, however, isn’t about a new login system. It’s about the current one being weird, specifically email.

Today I logged in to my email over the web using Chrome, and I shoved in my username (withouth “NETWORK/”, which is only a necessity because Internet Explorer is retarded when it comes to users not being in the domain it’s currently visiting) and password. It let me log in and worked perfectly, until I wanted to visit an external link in one of my emails.

Apparently the bit of OWA which forwards you to external URLs has logins handled differently to simply viewing your emails, and I don’t have permission to access it. No click-through of URLs for me.

Thinking this might be a byproduct of OWA not working properly in anything but Internet Explorer, I perform my ritual dance of protection and ready the talisman to ward off broken box models. I hit the email site, and log in.

Without “NETWORK\”.

It takes me a moment to realise what just happened, but it appears that the combination of IE8 and Windows 7 isn’t as retarded as previous incarnations. As in it doesn’t automatically specify a domain to authenticate against unless you tell it.

Click-through links in email don’t work, but it appears that one of our great enemies as ICT may be on the way out. I look forward to the last time I ever have to say “Just put NETWORK\ in front of it and it’ll work. Because that’s what fixes it.”.

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.

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.