Likewise Open-Sources Active Directory Authentication for Linux (eWeek)

Posted Dec 13, 2007 21:30 UTC (Thu) by lysse (subscriber, #3190) [Link]

Posted Dec 7, 2007 16:00 UTC (Fri) by chaneau (subscriber, #6674) [Link]

I'm sorry, did you just use "LDAP" and "easy to set up" in the same phrase? I've never seen that before.

:-)) very funny, but if you plan to deploy any kind of directory service, you should expect to jump some hurdles.

But more to the point of the article, I wonder what this is all about, integrating Linux clients in a Windows AD domain has never been difficult thanks to the wonderfull job done by the Samba team, it's the opposite which can lead to all kind of frustrations, trying to get SSO working with Linux Servers, specially when you have a combination of different versions of Windows clients

The only "relatively easy" setup I know is with zimbra with external LDAP, Samba, Kerberos, SASL/GSSAPI , replication, etc.

Once you have all this working, you have a great GUI to administer your clients, of course the setup can be quite challenging and if somebody provided an easier way to deploy that kind of solutions I would be more than willing to pay for it

Posted Dec 8, 2007 13:19 UTC (Sat) by buchanmilne (subscriber, #42315) [Link]

Active Directory = Microsoft modified Kerboers + Microsoft modified LDAP

Server-side

+ Dekstop application management and configuration + Server/PC management and configuration + GUIs for admins + integration into all other big Microsoft products etc etc.

All the rest of this is client-side. With no standardisation. All ugly registry components stored in the directory.

The closest I've ever gotten to Active Directory on Linux was to get Debian systems running with Kerberos and TLS-secured OpenLDAP. It's not easy, but it works and it didn't require any patches or anything that wasn't already present in the repositories. LDAP by itself can only do a tiny fraction of what AD does.

Since LDAP is a protocol, and you've included a whole bunch of client-side software functionality above (which is dependent on the protocol, but not actually the protocol itself), this is obvious ...

If you add Kerberos to it then it gets the most important parts, but you'd still have to add on a configuration engine

Do you mean the client-side stuff here, or configuration of the directory itself, or GUIs for administering the directory?

and a unified front-end to everything as well as integrating application support through things like GSSAPI.

Any application that supports SASL already has GSSAPI support. There are already a lot of applications under Linux that support GSSAPI. This includes ssh, Evolution (I think KMail as well), Mozilla, libsmbclient (and thus kio_smb for accessing smb shares from KDE applications) and a lot of others. For example, in your example above about Kerberos + OpenLDAP, if your OpenLDAP server had a ldap/hostname ticket, and you had a ticket, you could have "single-sign-on" from ldapsearch etc. by just omitting the -x flag when searching your directory.

Remember using PAM to do Kerberos nework authentication is a BIG no-no.

This is relevant if you mean "connecting to a network service". However, when logging into a client and authenticating over the network, some credential is required to get an initial ticket, and this is where PAM comes in.

Kerberos must be supported on the application level ("application" meaning anything that requires authentication over a network, not nessicarially desktop apps)

You mean server applications? Most already do (dovecot IMAP does, Cyrus IMAP should, modules are available for Apache etc.). Can you provide examples that don't?

Nowadays Windows actually _requires_ a domain controller.

My only Windows XP Home machine can't use a domain controller, so I don't think this is valid ...

Samba folks have found that sometimes file sharing is broken between a W2k3 server without AD.

My win2k3 desktop at work, joined to the samba/LDAP domain controller on my linux workstation doesn't seem to miss AD at all.

It's easier for people setting up networks to use a full-fledged domain system rather then not. And with small business server you get kerberos, ldap, and all of that.

I would agree it is easier, and while doing the equivalent with open-source applications isn't that easy, it only needs to be done once, and is quick (when I used to do this, it would take about an hour to set up for clients).

Linux is just now starting.

No, I've been doing samba/LDAP DC's and LDAP/Kerberos on linux clients since the openldap 2.0/samba 2.2 days (2000-2001).

Some projects of interest are: * Samba 4 -- Will provide network services for Linux and Windows on par with AD.

Since AD provides very little in the way of "Network services" for Linux, that's depressing ...

* The project mentioned in this article is very interesting.

But, there is very little information on what the open-source version does. It seems the "Enterprise" version has some client-side integration (applying GPOs to Linux clients) and policies for AD that support this integration. But, one of the examples they give is this:

You may have a very complex SuDo configuration file that requires hundreds of updates every year. Unfortunately, you have to apply this configuration file to each machine individually every time you make a change.

However, upstream versions of sudo now have LDAP support available (back in 2004 it was available as a patch, and some distributions - such as Mandriva - shipped sudo with the patch for quite some time). Now, even RHEL5 ships sudo with LDAP support. So, there is no need to apply configuration in any place but LDAP. At work, we use this to manage (so far) privileges for 10 sysadmins, 10 developers and about 40 contractors across about 200 Linux (and about 10 Solaris) servers. The other feature they seem to tout is password aging, but this is already available via various means (ppolicy overlay on OpenLDAP, password expiry via MIT or Heimdal Kerberos, or pam_winbind or pam_krb5 if authenticating to AD. So, while there seem to be some useful features ... everything I see so far seems to be available with open-source components now. The features I was hoping to see were things like "Prevent use from changing screen resolution", which could probably be implemented with the KDE Config in LDAP support (I haven't tried yet ...), but don't seem to be possible with the Likewise product.

* Fedora Directory services.

FDS has very little over OpenLDAP, and OpenLDAP 2.4 (which implements equivalents of almost all the features FDS has that OpenLDAP 2.3 or earlier did not) should be added to your list of projects of interest.

Also Sun recently released: http://aruiz.typepad.com/siliconisland/2007/12/apoc-goes-... This is for large scale application configuration. Something that is mostly missing from Linux and open source right now.

This looks a lot more interesting. Mandriva has been doing some development on storing KDE configuration (defaults, or forced settings) in LDAP. This feature is available in their Corporate Desktop 4 product, and will apparently be merged upstream in KDE4. The implementation is quite simple and flexible. Some information on how it was implemented is available in kde bugzilla.

All of this stuff, AD compatability and feature parity, is a requirement for Linux on the desktop in most places. If everybody is able to get that nut cracked then it will make a big difference and make Linux much more marketable.

I just hope that these AD compatability projects don't make AD (or samba4, which is just as ugly so far, leaving many current LDAP-related features that are available on Linux out of the picture - hopefully that will improve as the integration of external LDAP servers in samba4 progresses) a requirement, when there is actually relatively little to do to complete a solution that will allow Linux-only server side, and all OSs client-side. Finally, I get upset when there are articles saying "Now you can", when it has been relatively easy to set up authentication to AD for quite some time (to the point where most distros have GUIs for setting it up).