Yet Another Active Directory Alternative: the Univention Corporate Server

Previously I have "test-driven" Zentyal, a MS Windows Small Business Server alternative and Active Directory domain controller (http://anorak-tech-notes.blogspot.ca/2015/01/zentyal-and-freeipa-foss-id-management.html).

This post is a brief look at another AD domain controller alternative, the Univention Corporate Server (UCS). In my case it is the free "UCS Core Edition" version 4.1. This is by no means a complete review or evaluation, merely my impressions of the product.

The best news is that UCS provides another free alternative to MS Windows Server and it's licensing expenses. Univention touts it's integration with cloud services and SAML single sign-on features along with Docker support to differentiate their product with others. Those features were irrelevant to my use case, so while those features are not important to me, they might be invaluable to others.

My use case is hypothetical. I evaluate based on how an IT product would fit into a K-12 school network supporting student instruction. The basic need is for secure, distributed, cross-platform, ID management and file service. Beyond that, how easy would it be for novice system administrators to deploy and manage these services. Cost is always a consideration.

As with Zentyal, ClearOS, and SME, UCS can fulfill many roles on the network. In my case only directory services and file service were investigated. The UCS server was installed from the downloaded ISO DVD image under VirtualBox v4.3.34 on a Linux Mint 17 64-bit host. The clients of the UCS server were Linux Mint v17.2 Mate and Linux Mint Debian Edition v2 (LMDE) Mate workstations. The clients were also virtual machines running under VirtualBox. Both Server and clients were on a VirtualBox internal network, connected to the outside world via a virtual pfSense firewall router supporting IPv4 NAT and IPv6 routing.

Installation was pretty straight-forward and worked well. One of the features of UCS not supported by Zentyal was IPv6 support, which I wanted to investigate. During installation I was able to specify an IPv4 static IP address, but not the IPv6 address, which was left to SLAAC.

Because I was interested in UCS's usefulness as an Active Directory alternative my first test was to see if I could join the Mint and LMDE workstations with the UCS server as I would with MS AD or Zentyal. I used "realmd" to successfully join the workstations to the domain, using the same directions I worked out previously here.

None of the problems I had were major, but they were important. First, the web-based administration user interface was non-intuitive. I'm sure the developers loved it but I found it very needlessly different from anything else I've used with a menu. This is especially important for novice sys-admins (like teachers).

One limitation of UCS, shared by Zentyal, was that the DNS server was not suitable for use as the primary for any network beyond the simplest. This limitation means that I could only recommend that the AD domain be run as a sub-domain within an organization; that way the UCS DNS server would only have to deal with the AD domain and all other DNS needs could be met with a more flexible DNS implementation (even the BIND package in pfSense for example). Likewise, the DHCP server supplied with UCS is not very flexible either. Here is a screenshot of the form for configuring DHCP service:

No provision for static assignments, let alone boot information for thin clients. Again I would use another implementation for DHCP service instead of UCS (or Zentyal).

When I went to check out UCS's IPv6 functionality, the first problem was establishing a static IPv6 address and entering it into DNS so that IPv6-only clients could find the server. I like to number my servers with host address portion consisting of sequential small integers (like ::1 for default gateway, ::2 for directory servers, ::3 for file servers etc.) but I ran into a problem; here is a screenshot that illustrates the location of my problem:

Nowhere in the documentation could I find out how to supply an acceptable "Identifier". Instead I merely checked the "Autoconfiguration (SLAAC)" box, then manually entered the AAAA record in the DNS entry for the server. Luckily SLAAC-generated addresses are static (as long as the host remains on the same network). Once the addressing was straightened out, I was able to have services accessible over IPv6 addresses, in contrast to Zentyal which was IPv4 only.

Pros

• Easy installation
• IPv6 support
• Web-based management (no Windows tools needed)
• Cloud and SAML support (un-tested)
• Provides an AD alternative (Kerberos, LDAP, AD schema, DNS SRV RRs etc.)
• Linux clients can use "realmd" for joining the AD domain

Cons

• Non-intuitive user interface
• Limited DNS and DHCP functionality
• Extensive yet incomplete documentation

Conclusions

If I were charged with deploying a free AD alternative, as of this writing I would choose Zentyal over UCS for my use case. I simply couldn't turn a novice over to the UCS user interface, it would be a support nightmare. I hope that UCS improves over time because I feel that IPv6 support will become more important in future. Both UCS and Zentyal are developed in Europe; Zentyal in Spain and UCS in Germany. This can make the translations of documentation more problematic for English speakers, making the user interface intuitive more important than otherwise might be the case. Both UCS and Zentyal are usable and useful as a limited MS AD alternative, my hope is that they become more refined and robust over time.

Links

Univention Corportate Server: https://www.univention.com/products/ucs/

Tale of Two Tunnel Brokers: Gogo6 & Hurricane Electric

Late in 2013 I decided it was time I got serious about learning the essentials of IPv6. I had played with the protocol shortly after the turn of the millenium, but at the time it's actual use case was in the future. With the exhaustion of the IPv4 address space, the future has arrived. Let me be clear, since I am now retired and have no responsibility for building or maintaining a University network anymore, I am still "playing", but I am now a bit more systematic about it.

Gogo6/Freenet6

Since my ISP does not support IPv6, the only way I could gain anything resembling a real life experience with the protocol was to use an IPv6 tunnel broker. I initially settled on Gogo6/Freenet6 mainly because the client software was in the Linux Mint repository and it could work with IPv4 NAT-based home networks. I later tried Hurricane Electric as a tunnel broker in conjunction with my home firewall-router, a NetGear running "Toastman Tomato" firmware.

Gogo6/Freenet6 provides IPv6 tunneling services for free. There are two forms of tunnels: anonymous and registered. Anonymous tunnels use a dynamically assigned host address at each connection. Registered users receive a statically assigned IPv6 address registered on their  DNS servers (both forward and reverse zones). Registered users can also request a /56 address prefix delegation, which gives you 8-bits of subnet addressing (255 subnets of /64 networks). I wanted to investigate dual-stack routing, so I asked for and received a /56 address prefix delegation.

After registering with Gogo6 and Freenet6, getting the gogoc service took a bit of tweaking. In my /etc/gogoc/gogoc.conf file I had to enter my userid and passwd information, and set the following parameters:

server=montreal.freenet6.net   # those in Europe can use amsterdam
always_use_same_server=yes 
auth_method=digest-md5         # not the best, but better than nothing
host_type=router               # I wanted my sub-nets
prefixlen=56                   # can be 128, 64 or 56
if_prefix=eth0                 # interface for router advertisements
tunnel_mode=v6anyv4            

In the /var/lib/gogoc/tsp-last-server.txt file I pre-loaded the single entry "montreal.freenet6.net", since one weakness of Gogo6/Freenet6 is that while they have several server locations, your registration is only recognized in the one you register for, in my case Montreal.

Once this was done, it worked as advertised and I had the basis for my experimental dual-stack network. Here is a simplified diagram of one of my experimental networks:

I am not using my real IPv6 addresses on the diagram, the ones labeled here are similar to RFC1918 addresses for IPv4. The "File Server" here is a generic stand-in for any of several servers providing various services, such as: XMPP, Active Directory services, NT4 domain services, NFS file server, IPA Directory server, LDAP server etc. R1 and R2 are Linux Mint servers running Quagga, BIND, ISC DHCP and supporting services. All hosts on the net are virtual machines built with VirtualBox running on a Linux Mint v17 host with 3 NICs.

Gogo6/Freenet6 works very well. I don't run IPv6 full time, I turn it on and off with the "service" command as needed. One thing to keep in mind is that IPv6 is tunneled right through my firewall, so I have to make sure that any services are secured. All ssh servers are address restricted via /etc/hosts.allow and password authentication is turned off (authorized keys only) for instance.

Advantages of Gogo6/Freenet6

I was able to run IPv6 from within my NATed home network where I had great flexibility in routing. The delegation of a /56 IPv6 prefix meant that I could create an elaborate dual-stack intranet as an excellent learning platform. The ability to have an anonymous tunnel (for IPv6) can be a plus for some users. I run a second registered host tunnel on my laptop, and since it is a static address with proper DNS entries I can log into my home IPv6 net even with address restrictions.

Problems with Gogo6/Freenet6

Since my home firewall/router doesn't have the "gogoc" client, I can't run Gogo6/Freenet6 on my Netgear/Tomato box.

Twice I have "lost" my /56 prefix assignment and a different one was assigned. There is very little tech support and I never found out exactly why this happens. Both times I had to re-number my networks and update my local DNS records. My tunnel address was never lost, only the /56 prefix.

Just recently the Montreal Gogo6/Freenet6 server went down completely (Amsterdam stayed up) for a period of nearly two weeks. I received no announcement about this but on their community forum I found out that it was being worked on and when it came back up, all was well. Apparently this is a volunteer-run service and while I am thankful for it, I would not trust a production network to this service.


Hurricane Electric

When Gogo6/Freenet6 was "down" for two weeks and I was unsure if or when it would be back up, I looked into Hurricane Electric briefly. I was able to get my Netgear/Tomato firewall router working with an IPv6 tunnel once I registered at HE. I received a /64 delegation and an optional /48 prefix. I had planned to re-number my virtual network (again) and use HE as my tunnel broker.

First the good news. I was able to get the tunnel and the /64 prefix running on my home network. The bad news is that the Netgear/Tomato router has no provision for static IPv6 routes (other than default) nor any IPv6 routing services (OSPFv3 for instance), so it meant that I couldn't run my virtual IPv6 intranet with the delegated /48 prefix, or rather I could, but they couldn't be connected to the outside world. This is not a problem with HE, but a limitation of Tomato.

The further bad news (for me) is that I don't have a statically assigned public IPv4 address, so once I had to power-cycle my firewall/router (we have a lot of power outages here in America's paradise), I lost my tunnel endpoint address and HE tunnel stopped working. Manually editing my tunnel settings at HE should have fixed it, but I had trouble there too. I might have been able to work through these problems, but since I would still not be able to run my virtual net the way I wanted, I didn't try very hard. About that time Gogo6/Freenet6 came back on-line and I switched back.

Advantages of Hurricane Electric

The HE 6-in-4 tunnel is more generic and widely supported in commodity home firewalls than gogoc. If one had a statically assigned public IPv4 address from one's ISP, I think HE would be a better choice for most home users looking for solid IPv6 connectivity than Gogo6/Freenet6. Most home users wouldn't need elaborate routing, the /64 prefix would cover even the largest single home LAN.

Disadvantages of Hurricane Electric

HE really works best if you have a static public IPv4 endpoint for your tunnel. I didn't use HE long enough really wring it out, and the problems I had were mostly due to my own environment (bad local power, limited router functionality) rather than with HE.

Conclusions

For my purposes (self education and playing with technology) Gogo6/Freenet6 has worked pretty well, even with prolonged outages and changing prefix delegations. It is likely the only tunnel broker I can use without upgrading some of my home network equipment (pfSense router for instance) and paying my ISP for a static public IPv4 address. If only my ISP would just upgrade to support native IPv6  ...

With a better firewall/router and a static tunnel endpoint, HE would be a good choice and I think it may be more reliable and better supported than Gogo6/Freenet6. HE would be my first choice for a production network if those two criteria were met and I still needed the services of a tunnel broker.

Update 14 April 2016

It appears that Gogo6/Freenet6 is closing down. I received the following notice:

"Hello.  After 6 years of IPv6 goodness, gogoNET is closing down.  With over 100,000 registered members I’d like to think that we made a difference in helping the world transition to IPv6.

The Freenet6 service will also stop accepting new users and it is unknown how long it will continue to operate for existing users.  If you rely on one of our free tunnels or address blocks you should start looking for alternatives.

The company gogo6 stopped operating almost two years ago.  The gogoNET community and FN6 tunnel broker service lost money for years before that but I kept it running because it helped people, not only to get IPv6 but for some people it provided access to the uncensored Internet from countries that try to restrict it.

gogoNET will go dark on April 23, 2016.  How long Freenet6 will continue to operate is uncertain since its IPv6 block from ARIN has not been renewed.

With the transition to the Internet of IPv6 well on its way I have shifted my focus to help with the transition to the Internet of Things with my new site, http://www.iot-inc.com.  Hope to see you there, Bruce"

Links

Gogo6/Freenet6 http://www.gogo6.com/
Hurricane Electric http://he.net/

Directory and File Service for All: ClearOS & SME

In a previous post I discussed Zentyal and FreeIPA as two options for FOSS ID management. Those servers provided directory service via LDAP and security services via Kerberos. In the case of Zentyal it provided a useful sub-set of Active Directory services that could (in some cases) replace a Windows small business server. The two servers under discussion today are a bit different, but supply some of the same features.

Both SME Server and ClearOS provide central ID management and CIFS file service, but without Kerberos or Active Directory compatibility. Both provide and easy to use web-based management interface, no need for Windows tools for managing your server.

SME Server

The Koozali SME (Small and Medium Enterprise) Server provides an easily set-up all-purpose network service appliance for small networks. It is based on CentOS (currently v6.6). In addition to ID management and CIFS file service, SME also provides many other services, whether you want them or not. At installation there are 3 options for the role that SME may play:

1. Server and gateway
2. Private server and gateway
3. Server only

I chose the "Server only" option, since I already had DNS, DHCP and routing implemented on other net components. Beyond the directory service (via OpenLDAP) and CIFS file service (via Samba v3.6.x) that I wanted, I also had an email server (SMTP/IMAP/POP) that I did not want. The trade off here is that SME is very easy to set up, but it is not very modular nor very flexible. Further, Samba does not use LDAP for it's credential store. By default, the server does not use LDAP for it's own authentication, although that can be changed by running a script apparently. Password synchronization between LDAP and Samba happens externally. So this means that there are 3 separate credential stores on SME: /etc/passwd,shadow, LDAP and Samba.

For my purposes I wanted a central directory service for authentication and a CIFS for personal and shared directories for 3 platforms: Linux, MacOS, and Windows. SME implements a Windows NT4-style domain through Samba version 3.6.x and provides the directory service via OpenLDAP version 2.4.x over SSL. SME gave me what I needed, but I was rather disappointed that it included email services that I did not need or ask for. I did not try out the gateway services: Firewall, DNS, DHCP and web content filtering.

Pros

• Provides LDAP over SSL for authentication and general directory service
• Provides Windows NT4-style domain for CIFS file service
• All services are open source and free of charge
• Easy to set up and manage

Cons

• No IPv6 support
• Provides Email whether you need/want it or not
• Divides authentication into 3 separate realms

ClearOS

ClearOS has some similarities with SME Server. Both are based on CentOS (currently v6.6). Both use OpenLDAP and Samba v3.6.x for directory and CIFS file services respectively. Both can provide gateway services as well as email services in addition to the directory and file services. Both implement Windows NT4-style domains for CIFS file service. There are some significant differences as well.

ClearOS is much more modular than SME, you add only the services that you need. Authentication is centralized in LDAP for all services. ClearOS can provide commercial services and subscriptions to extend it's capabilities.

My requirements were the same as those for SME server: Directory and file services for Linux, MacOS and Windows. In addition I did try some of the gateway services with ClearOS, but they won't be discussed here.

The various services come in packages that you can add individually. Once added, I could not find a means to "un-add" them through the management interface. Once the package is installed, you are stuck with them, so choose carefully. Here is a screen-shot of the modules I installed (including the gateway services):

I tested the "Community" edition of ClearOS. Some of the available packages are only available in the commercial or "Professional" edition. All of the modules I tried out were free of charge. One of the commercial (not free) additions available in the ClearOS "Marketplace" that I am interested in is the "Google Apps Synchronization" service. At present I don't have a Google Apps domain, but even if I did it would require the "Professional" version of ClearOS. The prices for the commercial services and subscriptions are generally rather reasonably priced. The "Community" vs. "Professional" dichotomy is no different than many "freemium" offers for software on the net. I would have preferred a straight commercial support option rather than splitting the server into two distributions. The Community edition is quite adequate for many purposes. There were 79 free Marketplace applications available for the Community edition.

Pros

• Provides LDAP over SSL for authentication and general directory service
• Provides Windows NT4-style domain for CIFS file service
• Easy to set up and manage
• Flexible modular architecture
• Extensible via add-on "Marketplace" applications

Cons

• "Professional" version needed in some use cases
• Marketplace applications can be added but not removed
• Limited IPv6 support (optional and set up manually; not all services supported)

Conclusions

The use of Windows NT4-style domain may seem a step backward from Active Directory or even FreeIPA, but it has it's uses. The Samba implementation of NT4-style domains does not require changes to existing DNS domains (as both AD and FreeIPA do), since they use a separate naming service (WINS). This means they can be more easily integrated into existing networks without the need to create sub-domains (as I have done in the past). The CIFS distributed file system may not be the best available, but it is the most widely supported and the NT4 domain makes such file systems easier to share in a diverse network supporting all three major platforms (Linux, MacOS and Windows).

Of the two systems discussed here, I prefer ClearOS to SME. Both are usable and useful, but the modularity and extensibility of ClearOS, along with the unified LDAP authentication tip the balance for me. The commercial nature of ClearOS will dissuade many users. The model I have in mind when evaluating these systems is a small K-12 school. Schools have needs that many small businesses and home networks do not have. The use of Chromebooks in schools is widespread and on the rise, so integration of the campus network with a Google Apps domain that can be used to manage Chromebooks would be a plus; the availability of a packaged GADS application that would allow managing accounts and passwords in one place is a real win for ClearOS, even if it costs $125/year through their "Marketplace".

Links

SME Server: http://wiki.contribs.org/Main_Page

ClearOS: http://www.clearfoundation.com/Software/overview.html

Notes on LDAP client authentication:
https://drive.google.com/open?id=0B6yzbC9y4l-CMkVtejRKaUEzX0k

Zentyal and FreeIPA: FOSS ID Management Options

In the past I have used OpenLDAP combined with Samba3 on CentOS 5.x for cross-platform, centralized authentication services (https://sites.google.com/site/fossvi/centos-5.x-smbldap-fix). Unfortunately that setup has become obsolete, so I have been searching for a more modern system to replace it. The most important criteria for such a system are:

• - Freely available without licensing hassles
• - Run on Linux servers
• - Support Linux, Mac and Windows clients
• - Use encrypted transport for credentials
• - Easily deployed and maintained

I have so far come up with two likely candidates: Zentyal and FreeIPA. The purpose of this posting is to highlight some of the features of these systems and to discuss their pros and cons.

Zentyal 

Zentyal is based on Ubuntu Server LTS (currently 14.04), BIND9 and Samba4. It is intended to be a drop-in substitute for a Microsoft Windows Small Business Server. It's modular design allows it to fill any of several roles. For my purposes I used it as an Active Directory primary domain controller and CIFS file server. While it is a useful sub-set of an Active Directory server, it does not offer all the features that the Microsoft original does. On the other hand, the open source community edition is the right price (free), and there are no CALs to buy.

My testing of Zentyal was conducted on a virtual network built with Virtualbox on a Linux Mint 17 host. The clients were Mint and Debian Linux workstations  using the closed-source Centrify Express client software for joining the hosts to the AD domain. The "Express" Centrify clients provide only basic AD functionality, but again the price was right (free). Centrify Express can be used freely on up to 400 clients for educational institutions (200 for government and commercial institutions). Beyond that scale, or if you need fuller functionality, the full Centrify suite would be required (not free). Centrify offers their software suites (both Express and full) for Mac and Windows too. The full Centrify suite provides full AD functionality and more.

Zentyal clients are authenticated via Kerberos, with group membership and authorization information etc. stored in LDAP, just like Microsoft. LDAP and CIFS are provided by Samba4. A Zentyal server can participate as a primary or additional AD domain controller. Server administration is handled via a web interface running on the server, so you don't need a Windows workstation to manage the server.

Update (22Aug2015):

If you wish to join a recent release Ubuntu client to Zentyal (or any Active Directory Server) then there is a working alternative to Centrify. The "realmd" package is a front-end to sssd (or winbind, reputedly) that can be used to join Ubuntu to an AD domain. There is a good "howto" by Myles Gray on his blog entitled: "Utilising Kerberos/AD auth in Ubuntu 14.04 with realmd". For Linux Mint (v17.2 Mate), I had to tweak a few things to get it working, you can see my notes here.

Pros

• - Easy set-up and management
• - Provides standard AD protocols (krb5, LDAP, AD schema, DNS SRV RRs etc.)
• - With Centrify, easy client enrollment for Linux, Mac & Windows
•  - The "realmd" package makes joining a Zentyal/AD domain easy for Ubuntu & Fedora 

Cons

• - Rigid organization structure
• - Limited DNS functionality
• - Can't be easily used as generic LDAP server
• - Doesn't support IPv6
• - Almost requires 3rd party SW for some Linux & Mac clients

FreeIPA 

FreeIPA is an open source system for ID managment developed by Red Hat. It combines the "389 Directory Server" (LDAP), with MIT Kerberos 5, BIND 9 and Certmonger/Dogtag (certificate managment). While FreeIPA is intended to provide secure ID managment for Unix-like systems, it is capable of providing one-way Kerberos trust relationships with Active Directory domains(AD to FreeIPA). FreeIPA is included in the core repositories (both client and server packages) of the common RedHat Linux derivatives (RHEL, CentOS, Fedora). The FreeIPA client packages are also found in repositories that serve Mint. For a "Howto" on enrolling Linux Mint clients you can go here.

Unlike Zentyal, FreeIPA does not "look like" Active Directory. It does however utilize the same basic approach, using LDAP storage and Kerberos authentication. Unlike Zentyal (and AD) FreeIPA can be easily used as a generic LDAP server. This ability allows authentication by many services that may be difficult to integrate with AD or Kerberos. For Ubuntu, Mint and Debian clients, I can use bare-LDAP authentication. In the past I have used bare-LDAP to authenticate Mac OS X clients (Tiger and Leopard). By using LDAP over SSL (LDAPS), I can have secure centralized authentication without resorting to 3rd party software. I lose the single-sign-on (SSO) capability that Kerberos enables, but  otherwise this is quite adequate in many situations. Beyond bare-LDAP, I was able to enroll Mint and Fedora clients in a FreeIPA/Kerberos domain. When enrolled within such a domain, client IP addresses are recorded along with SSH public host keys and host certificates (provided by certmonger/dogtag). There are no pre-built FreeIPA client package for Mac or Windows hosts. While there is documentation on how to go about manually configuring Windows and Mac hosts to enroll in FreeIPA, I consider those instructions to be too intricate and error-prone to be used by any but expert admins; Macs should readily be able to use bare-LDAP however.

Enrolling Mint clients only succeeded by *not* using sssd (the default setup used by freeipa-client) but utilizing nss-ldapd and pam-krb5 instead, plus manually adding one line to the pam session configuration file (to automatically create home directories). Once these steps were taken, everything went well and worked as expected.

I ran into a "hiccup" when attempting to enroll Fedora v21 (newly released while I was testing) with my CentOS v7 FreeIPA server. The FreeIPA version on CentOS 7 was v3.3.3, while the FreeIPA client version supplied with Fedora v21 was the newer v4.1.2. Enrollment completed, but several key pieces of information did not end up recorded on the server: DNS info, SSH host public keys, and host certificates. Authentication and authorization worked fine. This result combined with a reading of the FreeIPA FAQ leads me to believe that currently, FreeIPA client and servers should be in the same major release version (v3 or v4 but not mixed) for full functionality. I was able to enroll Fedora v20 in FreeIPA without any suprises (used the v3.3.5 client), and even upgrade it to Fedora v21 (via FedUp) without incident. So only the enrollment process seems to be affected by these differing software versions.

The CentOS/FreeIPA server that I used does not provide an integrated CIFS file service. Adding the schema and functions to integrate Samba4 are beyond my brief. File service options would be limited to SSH and NFS (the latter can be Kerberized NFS4). This is unfortunate, because neither of these protocols can be used (for mounted file systems) by newer Macs without 3rd party add-ons.

FreeIPA is managed via a web interface. This management interface is more full-featured than that of Zentyal. The BIND 9 server is more flexibly managed; I believe it could be used as a primary DNS server for small to medium enterprises, though I used it only within a sub-domain for testing.

Pros

• - Easy set-up and management
• - Can be used as generic LDAP server
• - Easy enrollment for Ubuntu/Mint and RedHat/Fedora derivatives
•   - Supports both IPv4 and IPv6
• - Flexible DNS functionality

Cons

• - No integrated CIFS file service
• - No pre-built Windows or Mac clients
• - Enrollment of Ubuntu/Mint client requires minor tweaking
• - Client - Server enrollment is version sensitive

Conclusions 

Both FreeIPA and Zentyal are usable and useful. If you are dealing with mostly Linux clients I would use FreeIPA, with Kerberos (full enrollment) or without (as a bare-LDAP server). If you have some Macs, you could still use FreeIPA as a generic LDAP server, but the lack of CIFS file service will be limiting. If you have primarily Windows and/or Macs, then probably Zentyal along with Centrify client software would be the better choice.

FreeIPA's better performance as a generic LDAP server may make it easier to integrate with GADS (Google Apps Directory Service), although with passwords stored in Kerberos it means that while the accounts can be synced, passwords would have to be managed externally (true for AD and Zentyal as well).

Personally I like the "feel" of FreeIPA better than Zentyal. FreeIPA feels less restricted than Zentyal. The simplicity of the Zentyal management interface comes with the cost of less flexibility.

These two solutions have different target use cases: FreeIPA could manage a fleet of Linux virtual machines in the cloud, while Zentyal is a drop-in for a small business (or school) with Windows workstations. Both solutions are under active development and are bound to become better with time.

While both FreeIPA and Zentyal are useful solutions for central ID management, neither of them quite replaces the basic functionality of my old CentOS-5/OpenLDAP/Samba3 system, which provided authentication and CIFS file service for Linux, Mac and Windows clients (via Samba NT-style domain configuration), but also could be used as a generic LDAP server for use with Squid proxies, web and RADIUS servers etc. While the old system didn't provide Kerberos, and the single-sign-on it provides, it was still quite useful, reasonably secure  and didn't require a third-party client on any of the three platforms.

Update (15 June 2016)

I have received some tips that will allow Mint users to install FreeIPA just like Ubuntu and utilize sssd rather than rely only on LDAP. This information came from Brendon Bonner:

"Reading https://sites.google.com/site/easylinuxtipsproject/mint-cinnamon-first

1.2.1. Mint deviates from the Ubuntu way, where the so-called "recommended" packages are concerned. When you install software yourself, Ubuntu installs the recommended packages by default, but Mint does not.

This has two important disadvantages: in Mint, the features of the applications that you install yourself, can be needlessly crippled. And some how-to's for Ubuntu, don't work in Mint. All this for the sake of saving some disk space...

You can make things right like this:

Menu button - Administration - Synaptic Package Manager

Settings - Preferences - tab General
Section Marking Changes: tick: Consider recommended packages as dependencies

Click Apply

Click OK.

Furthermore, you need to change the setting "false" into "true", in the settings file /etc/apt/apt.conf.d/00recommends. That's easiest to do in the following way:

Menu - Accessories - Terminal

Copy/paste the following command line into the terminal, for example by a right-click with your mouse (this is one line!):

sudo sed -i 's/false/true/g' /etc/apt/apt.conf.d/00recommends

Press Enter. When prompted, type your password. Your password will remain entirely invisible, not even dots will show, this is normal.
Press Enter again."



Links

• - FreeIPA http://www.freeipa.org/ 
• - Zentyal  http://www.zentyal.org/server/
• - Centrify Express http://www.centrify.com/express/centrify-express-overview.asp 
•  - Realmd http://www.freedesktop.org/software/realmd/