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
     dn:
     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
    Administrator
    dns-bzzentyal
    joe
    mary
  8. 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.

  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.

Speed up MacOS X file transferring over network

We had an issue with a group of MacOS X clients on a particular VLAN that were experiencing painfully slow transfers (~100KB/s) to our Solaris fileservers running netatalk (AFP). The problem was solved by tweaking a kernel parameter on the client that made it “more compatible.”

delayed_ack=0 responds after every packet (OFF)
delayed_ack=1 always employs delayed ack, 6 packets can get 1 ack
delayed_ack=2 immediate ack after 2nd packet, 2 packets per ack (Compatibility Mode)
delayed_ack=3 should auto detect when to employ delayed ack, 4 packets per ack. (DEFAULT)

Get the current value for net.inet.tcp.delayed_ack (default is 3)

$ sudo sysctl -a net.inet.tcp.delayed_ack
net.inet.tcp.delayed_ack: 3

Let’s try changing it to 2 and you should immediately notice a difference (this worked for us, you may also try values of 0 and 1)

$ sudo sysctl -w net.inet.tcp.delayed_ack=2
net.inet.tcp.delayed_ack: 3 -> 2

I’m not sure why OSX ships with a default of “3.” Our software vendor also did not know, nor did our enterprise Apple support. All I do know, is that Google is filled with people experiencing the same problems as far back as ten years ago. This fix is good for all sorts of network weirdness and compatibility issues with Samba, netatalk, FreeBSD, Solaris, Windows, etc etc.

To make this persistent across reboots you will need to use /etc/sysctl.conf. If this file does not exist, create it, or use the following command.

$ echo "net.inet.tcp.delayed_ack=2" | sudo tee -a /etc/sysctl.conf

You can read more here:
TCP Performance problems caused by interaction between Nagle’s Algorithm and Delayed ACK