Managing Windows Domains


With the removal of Exchange and MS Office from the company we then wanted to look at the Domain Controllers. While a lot of Open Source systems have the ability to integrate into Active Directory, it always appeared to be a little complicated and fraught with problems. However, to get Single Sign On working, you need a single directory master. Zimbra includes OpenLDAP as one of it’s components, so we decided to bite the bullet and migrate the Windows desktops off the Windows Domain and onto a Samba domain instead. This would then give us a greatly reduced cost base as well as the ability to have the same username and password within Windows, Zimbra, RT etc etc.

Installing Samba was a little complicated, there are any number of HOWTOs out there to follow and while initially there was a big learning curve, it got easier quickly. Zimbra contains a very explicit HOWTO for integration between Samba and LDAP so while that took a little thought it also worked without too much heartache. It also meant that integration with the various systems were a little easier to debug as well.

Once we had followed the HOWTOs it was a simple matter of migrating the workstations to the new domain. Samba v3 is modelled on the pre Active Directory technology, so the whole process is a little more manual than with the latest Windows technology. However, v4 of Samba promises to include all that functionality in which will make things a lot less manual.

It did mean that we now could reuse 3 Domain Controllers (and not have to purchase Client Access Licences for all the users to be able to connect to the domain controllers with) and save the subsequent licencing costs. Creation of a new user account now occurs within Zimbra, but the login scripts have to be manually set on the Samba server. Telling Samba to obey the pam restrictions on the server ensured that home directories would be created automatically however.

The two biggest issues we encountered:

  1. Until a recent version of Zimbra, if someone changed their password within Zimbra it would not be reflected on the Windows machines. This is now rectified, via an extension, but did require user education.
  2. Samba inexplicably removed a feature by which we could filter the ldap searches on active users, without replacing it with anything similar. As a result I have not been able to find away to disable ex employees from being able to log on just by setting their account status in Zimbra. This is just plain stupid. Instead I have to write a script to check the Zimbra status and apply the same to the Samba statuses. Really, really irritating. If we weren’t saving so much money on the Windows Servers, I would seriously reconsider going to samba again. The workaround is such that if a user gets disabled inadvertently (i.e. they type their password in incorrectly and get locked out) then I need to re-enable them twice.

Leaving the negatives aside, Microsoft makes you buy Windows Server and then Client Access Licences to be able to use the server. Then more licences for anyone wanting to log in to the server (and I swear you have to be a rocket scientist to understand the Terminal Services licencing documentation). It all adds up. Samba is more stable than Windows, fast and works well. Other than the inability to hook into LDAP correctly which I did create a workaround for… Lets hope v4 works better in that respect.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: