modernizing user authentication

[martbhell]

LDAP would be a more modern way of doing the user setup than NIS.

We chose to use the same (as in FGI) style because initially LDAP looked like a lot of work to setup and NIS works nicely and user administration with NIS was known to us and the cluster admins.

Some things to consider:

• What are the options and components of doing an LDAP cluster internal authentication (so not connecting to an external AD/LDAP which we already support but to run our own LDAP). Some sites run LDAP only in one place and copy passwd/group files to the compute nodes. Some run SSSD(or other daemons) on all the nodes.
• Are there other methods than ldap?
• Are there benefits over NIS?
• Do we need to update documentation?

[jabl]

I think it might be difficult to do an easy NIS-LDAP transition, but yeah, certainly there are advantages to LDAP. If nothing else, if we do a EL8 midlife update, that could be a suitable moment?

So we used to have our own LDAP auth system for our Linux workstations here, consisting of mainly

• LDAP master (openldap)
• LDAP slave (openldap, syncrepl replication protocol)
• pam_ldap/nss_ldap using TLS + nscd on clients.
• Due to TLS, need to set up our own CA, and distribute certs to clients.
  • Of course it's also possible to use "real" certs, I think ldap client libs use the builtin cert lists so it might work without having to distribute certs to the clients.
  • Getting this to work was a major PITA, at least I couldn't figure out how to make pam_ldap/nss_ldap to log stuff on failure, so it was a lot of fumbling in the dark. sssd is a lot better in this respect, but wasn't around at the time when we did the above setup.
• In order to manage accounts, you need some tools. ldapvi is a nice and simple CLI tool, and then there are a lot of various web-based tools (we used one called GOSA).

An alternative to doing all by yourself is to use IPA, which sets up 389 ldap server(s), krb5 infrastructure (using kerberos for auth instead of pam_ldap), CA, and ipa-client sets up sssd on the clients. The problem I see here is that we currently use krb to authenticate against our AD + NIS for some cluster internal accounts (e.g. the slurm user, fgi* accounts etc.), and I don't think it's possible to have a machine be a member of two krb5 realms at the same time. So I think that unfortunately rules out IPA.

A benefit of LDAP for us would be that currently we must disable nscd, as it conflicts with sssd caching. So all NIS queries must hit the server. With LDAP, it's possible to have several domains in sssd, so we could cache both AD and cluster internal users/groups.

If one goes all-in for LDAP, there's a lot of other things one can do with the LDAP DB than users/groups. E.g. sudo rules, autofs maps, mail aliases etc.

[jabl]

As for a non-LDAP solution, warewulf (used in OpenHPC) as it's own way, which is essentially copying passwd/group from the admin node to all the managed nodes. At least it's simple, and you can manage it with the same tools as NIS and local passwd files.