#!

Main menu

Archives

Post navigation

I have been following Zentyal since their eBox days, and Samba 4 since 2006. But finally, with the release of Zentyal 3.0 and Samba 4, it appears that my dream of an open source and drop-in replacement for Windows Active Directory has come true. Centralized management of computers, users, and groups for both Windows and Mac, for FREE! and with the option of enterprise level support. It won’t be long before this takes off.

I would describe Zentyal as an intuitive and friendly front-end interface for managing a Linux server. It is specifically designed to run atop Ubuntu Server linux distribution, which happens to be my favorite small and medium-sized business server platform. Samba 4 is a major rewrite that enables Samba to be an Active Directory Primary Domain Controller, participating fully in a Windows Active Directory Domain. Read more about Zentyal here and Samba 4 here.

The first part of this series is using Zentyal’s directory services for storing and managing users/groups in a centralized database so users can log in to both Windows and Mac machines with the same password. Getting Windows machines to authenticate to Zentyal is easy enough and well documented, but making it work with the Mac can be tricky. I am using Mac OSX 10.8 “Mountain Lion” in this example.

The first thing you might want to do is install Zentyal. This article assumes you are able to install the Users & Groups module, configure LDAP server, and add a user.

At first I tried to get the Mac to work with the Samba4 service using OSX’s Active Directory Plugin. It immediately failed with an error message, and I spent all of two minutes on it before I stopped and realized something. Samba 4 is using OpenLDAP as a backend database. Why go through all the trouble of using the Active Directory plugin and mucking up my system with Microsoft tech? LDAP authentication is included and supported by Mac OSX!

One thing you want to note before going forward is Samba 4 takes over LDAP’s default port (tcp/389). So Zentyal has OpenLDAP running on the non-standard port tcp/390.

Let’s get OSX to be happy with Simple Binding to the LDAP server by disabling SASL. This is required of OSX 10.7 and 10.8. More information about this step here and here.
Search your LDAP server’s RootDSE for the advertised SASL methods:

Now we make it so LDAP authentication requests from the Mac client will not attempt to use the aforementioned SASL mechanisms. The following three commands fix this problem by modifying /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver. Make sure you edit these commands to match the name of the .plist on your system.

Try to “su” as a user that you added with the Zentyal Users & Groups module.osxclient:~ localuser$ su - joe
Password:
bz101:~ joe$

Success!

Don’t panic if that last step doesn’t work. I found that, at least in OSX 10.8, that although you set “Custom Port 390,” this setting is ignored and it continues to use default LDAP port 389. I filed a bug report with Apple Enterprise Support. They confirmed it and provided me a workaround.

I have a Linux guest under VMware ESXi 4.1 that runs OpenVPN and therefore acts as a gateway/router into the network. For weeks I was troubled with network slowness and weirdness. I knew OpenVPN wasn’t the problem because it’s fairly easy to configure and I’ve done dozens of similar deployments without any issues. Then I started reading some posts on the VMware forums about people complaining their Linux routers are basically unusable when using VMXNET 3.

I did happen to be using the VMXNET 3 adapter on this guest. It turns out this is a documented issue. The workaround suggests to set a module parameter option for “disable_lro=1″. I tried to do it using this guide but it didn’t seem to help me. For me, the solution was reverting back to using the more compatible E1000 adapter.

Some Linux modules cannot handle LRO-generated packets. As a result, having LRO enabled on a VMXNET 2 or VMXNET 3 device in a traffic forwarding virtual machine running a Linux guest operating system can cause poor TCP performance. LRO is enabled by default on these devices.

Workaround: In traffic-forwarding virtual machines running Linux guests, set the module load time parameter for the VMXNET 2 or VMXNET 3 Linux driver to include disable_lro=1.