[TUHS] YP / NIS / NIS+ / LDAP
davida at pobox.com
Tue Nov 6 15:03:00 AEST 2018
One place I worked recently used FreeIPA. It's a Redhat-sponsored attempt to integrate a bunch of other free/open source projects and put them under a single web UI.
It’s largely compatible, functionally, with Active Directory, and I think can be set up to support cross-realm authentication with an AD installation as well. It *doesn’t* (or at least in the setup I used) replace AD, and doesn’t seem to use any Samba components.
It does however include the DHCP and (Dynamic)DNS integration that’s part of AD.
It seemed pretty fragile in practice, although the overall level of systems expertise in this place was fairly low, and a lot of its problems could well have been issues with the underlying virtual machine or storage infrastructure.
I too still use NIS at home. It works with my Linux boxes, but also the Sun, DEC, SGI and NeXT stuff as well. I like the idea of a central directory, but X.500 always seemed like overkill and the “Lightweight” bit of LDAP doesn’t quite throw enough away for me …
> On 6 Nov 2018, at 14:03, Robert Brockway <robert at timetraveller.org> wrote:
> On Mon, 5 Nov 2018, Grant Taylor via TUHS wrote:
>> I also loath the idea that Unix (Linux) doesn't have a stand alone central directory server solution. Or if LDAP + Kerveros is said solution, so be it. - That's sort of what I'm trying to figure out.
> LDAP with or without Kerberos certainly counts as a standalone directory server solution for *nix.
>> Translation: What is the current Unix (Linux) method to provide central user directory / authentication for about a dozen Unix (Linux / Solaris / *BSD / AIX) systems /without/ a Windows Server in the mix. I don't own a license for any version of Windows Server that supports AD. Nor do I feel compelled to buy one.
> I've seen plenty of businesses with Linux servers and OSX desktops. These business often manage user auth on Linux with LDAP. Various solutions were used to manage the OSX boxes but they were quite separate to Linux.
> One caveat with LDAP. When I last did this a few years ago many Linux systems were set up in such a manner that a failure of LDAP makes the systems largely unusable. AFAIK this is still a problem.
> A sysadmin logging in had to wait out a series of timeouts while trying to open nsswitch.conf or the PAM config to disable LDAP so the underlying problems could be addressed.
> One fix for this that I mentioned earlier is to manage the Linux systems using orchestration tools like Ansible. Have them generate local passwd, shadow & group files from data stored in LDAP. This prevent the timeout problems I mentioned earlier and also means that switching to a new authentication backend (eg, OpenLDAP to AD) is a lot easier since it is abstracted away.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Message signed with OpenPGP
More information about the TUHS