Centralizing user/group management for Mac OSX with Zentyal

196497-96-20101011170315I 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.

  1. 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.

  1. Zentyal’s firewall blocks LDAP by default. Navigate to this URL and change it to Allow: https://zentyalserver/Firewall/View/InternalToEBoxRuleTable

Screen Shot 2012-12-26 at 8.15.07 PM

Screen Shot 2012-12-26 at 8.04.15 PM

  1. 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:

    $ ldapsearch -x -p 390 -LLL -h zentyalserver -b "" -s base "(objectclass=*)" supportedSASLMechanisms
     supportedSASLMechanisms: DIGEST-MD5
     supportedSASLMechanisms: CRAM-MD5
     supportedSASLMechanisms: NTLM
  2. 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.
    sudo /usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string DIGEST-MD5" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/zentyalserver.plist
    sudo /usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string CRAM-MD5" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/zentyalserver.plist
    sudo /usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string NTLM" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/zentyalserver.plist
  3. Now we configure OSX for LDAP. Open “System Preferences -> Users & Groups -> Login Options -> Edit… -> Open Directory Utility.” Double-click “LDAPv3″ and click “New”. Enter your server’s name and click “Manual”
    Untitled Use custom port “390”
    Untitled 6
  4. Choose “RFC2307 from “Access this LDAPv3 Server using”.  Find your Search Base Suffix in /etc/ldap.conf and enter it into the box.
    $ cat /etc/ldap.conf | egrep ^base
    base dc=zentyal,dc=mycompany,dc=com
    Untitled 3
  5. Click through “Record Types and Attributes” -> Users – > NFSHomeDirectory.  Change it to map to: #/Users/$uid$. This tells OSX to create a local home directory.
    Untitled 4
  6. Click the “Security” tab and check “Use authentication when connecting.” Enter the Distinguished Name and Password that you find in /etc/ldap.conf.
    $ cat /etc/ldap.conf | egrep '^(binddn|bindpw)'
    binddn cn=zentyalro,dc=zentyalserver,dc=mycompany,dc=com
    bindpw wOTaarFLbZSbW0@q9RvH

    Untitled 5

  7. Click OK and you should now be able to connect to the directory and list users from it’s database.
    $ dscl /LDAPv3/zentyalserver -list /Users
  8. Try to “su” as a user that you added with the Zentyal Users & Groups module.
    osxclient:~ localuser$ su - joe
    bz101:~ joe$


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.

  1. Delete the dynamic data plist file for the server:
    sudo rm -i /Library/Preferences/OpenDirectory/DynamicData/LDAPv3/ldap.example.com.plist (Change the filename to match your system)
  2. Restart opendirectoryd:
    sudo killall opendirectoryd
  3. Double-check that Custom Port 390 is still set. If not, just enter it again.
  4. It should now work.

Slow Linux router performance with VMware VMXNET3 adapter

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.

Read more about the issue in the vSphere 4.1 Release Notes:

Poor TCP performance can occur in traffic-forwarding virtual machines with LRO enabled

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.