Since a couple of weeks, we have a new wish on the IPFire wishlist that is about implementing Active Directory Authentication to the IPFire web proxy. As you can see, this has not made too much progress and I have received some emails that say that this is basically working for them. I would like to answer them now and here:
The “Windows” proxy authentication is broken
When you have a look at the many authentication methods the IPFire web proxy offers, you will find a button with the word “Windows” on it. Some people are using this one to authenticate their users against the Windows domain. Fair enough, it works. But here are the problems:
The are two paths your authentication credentials are travelling. At first, when you open your web browser, you will see a dialogue that asks you for your username and password. Those credentials are then sent to the proxy server which in turn passes them forward to the Windows Domain Controller. If the domain controller says that the user exists and that the password is correct, the web proxy will grant you access to the Internet. Easy, right?
Where can be the flow, you are asking? Well,... The browser sends the password to the web proxy in plain text. The mechanism that is used is called HTTP Basic authentication and it is what the name says. It is just basic, which means that no confidentiality of the data is given. There are no hashes involved, just the plain data that is passing through your wired network – or even worse – wireless network.
It gets slightly better after that step, because the web proxy does not pass the password to the domain controller in plain text, but it uses a hash function. Unfortunately, that hash function is broken. It is old, not recommended for use since ages and still, people are using it. That all will come to an end as Microsoft does not support that broken hash after Windows Server 2000 any more. It was even deprecated in Windows NT Server, but possible to be reactivated in the registry. It is called LAN Manager hash or shortly LM hash.
I think at this point, I don’t have to tell you that this is fundamentally(!) broken and that there is no easy fix.
But there is a solution: Kerberos
When Windows Active Directory was invented, there was a strong focus on security and authentication. The engineers exactly knew what they are designing this for and what requirements there are. In my opinion they made a really good job as they used well-designed and widely deployed protocols like LDAP and Kerberos.
Kerberos is however one of the most tricky to handle protocols there are. That is probably also the reason why it is so secure. If you are interested in how it works, google for it. It is quite interesting, but too complicated to explain it just briefly. Everything you need to know is that it is used everywhere where you need really good authentication and it is also in use for decades. So it is no wonder that Kerberos, paired with SMB, is the protocol suite for Microsoft Active Directory.
IPFire does not yet bring all the tools and libraries that are needed to talk to the domain controllers over Kerberos. This is why we ask you for your support to do all of the work that is required to switch to the new authentication process. Among the things that need to be done is integration of the kerberos libraries from MIT, enhancing the Web User Interface and Samba package that the IPFire firewall can join the Windows Domain and then connecting the squid web proxy to winbindd, the daemon running on IPFire and authenticating all the clients against the domain controllers. Finally the web proxy needs to get rid of the HTTP Basic authentication and switch to NTLMv2. This protocol is much more secure and comes with an other great benefit…
An other benefit: Real Single Sign-On
With this, we are able to get rid of any dialogues popping up when you open the browser. No more prompting for the username and password again. NTLMv2 is well integrated into Windows and automatically and securely sends the credentials you used to log in on the computer to the web proxy. Even Firefox can do that, so this is not limited to Internet Explorer only.
So in conclusion, there are many reasons why this feature is important. It gets rid of a long time broken set of protocols and switches to the state of the art. The old authentication methods have been removed from never versions of Windows Server any way (since Windows Server 2003). It enhances the usability because you don’t need to re-enter your username and password over and over again every time you open a browser window.
I hope that this gives you guys who asked for it the technical information that you wanted and I hope that I made it a bit more clear for the others what this wish is about. I added an other four weeks time that you have enough time to consider if you can support this feature – especially you, the corporate users of IPFire. I know you want this.