6 Nov
2018
6 Nov
'18
6:03 a.m.
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 …
d
On 6 Nov 2018, at 14:03, Robert Brockway
<robert(a)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.
Cheers,
Rob