support LDAP

[ivucica]

Hi,

tl;dr Oragono could have multiple password backends, incl. PAM on UNIXes, libsasl2, or it could talk to LDAP. PAM and libsasl2 are very customizable, but just LDAP would be enough.

PAM and libsasl2 probably require CGo to be acceptable, but hiding this code behind a build-tag is an option.

---

It would be great if username+password could be checked on a backend separate from the rest.

I run a Samba4 server to serve as a single store of user accounts (both for passwords, and for other generic user account information such as real name).

This is, on my side, used for:

• accounts in Prosody for XMPP,
• accounts in Dovecot for IMAP,
• accounts in Postfix for SMTP,
• provide username+password portion handling for an OAuth2 server,
• log into a Windows with it,
• log into Gerrit
• etc

How?

• Mostly things go straight into checking password via a direct LDAP bind,
• sometimes it's LDAP bind+username lookup+actual LDAP bind for password check
• sometimes things go through PAM towards LDAP,
• sometimes libsasl2 + LDAP (though it could be libsasl2 + PAM + LDAP., not sure).

Gecos fields are also populated from LDAP.

Adding IRC to the mix would be great.

[slingamn]

We're pretty averse to C dependencies, but I'm definitely interested in adding LDAP support via one of the various pure-Go client libraries.

One of the questions I have is whether LDAP support would be an all-or-nothing config option (as in, flip a switch in the config file, and now all authentication and account management are deferred to LDAP) or whether they would exist side by side (some accounts managed by the LDAP server, some natively in Oragono). A similar question is whether to allow all valid LDAP accounts access (or perhaps only accounts that match some piece of LDAP-managed metadata?) or require the Oragono operator to manually create the accounts (e.g., with a variant of NS SAREGISTER).

[ivucica]

If I were the one making a design decision here, I'd just offer a password-checking interface{} and (presumably necessary?) user info interface{}.

They're in my mind two different things: as an example of previous art, on Linux, password checks are generally a responsibility of PAM, and other information is served from NSS's passwd database.

I personally would find the password-checking part more important and useful; I can add user info to BoltDB, but I would prefer not to write a tool to sync user password changes into it.

interface{}-based stuff usually translates into easily fakeable implementations, for go test purposes.

---

Two initial implementations for password checker would then be use current BoltDB (?) database or the LDAP store.

Third implementation could be a CombinedAuthenticator implementation which accepts a list of concrete backends to use. This is what PAM does; in PAM you can say 'call into LDAP; if that fails, call into a module that reads /etc/passwd; if that fails, deny login'. So in this Combined implementation you would translate this into 'check LDAP; if that fails, check native store; if that fails, deny login'.

An additional debug module (doesn't even have to be a struct{}; it could live on top of a type AcceptPassword bool) could accept any username, too: see PAM's pam_permit.so module.

Constructing the auth system like this (pluggable password check + pluggable userdb) would allow one to write a module with an optional C dependency on PAM or anything else, really. Perhaps write a gRPC client, even, to have an external service check the password!

---

And if you opt to also go for a pluggable userinfo store, a writable userinfo store wouldn't translate well onto LDAP. I wouldn't want an IRC server writing into my LDAP server, so having a layered approach e.g. CombinedUserInfoStore where I can use LDAP only as a fallback store, possibly blocking writes into some properties such as realname and password, would be great.

---

_{Side note: If SASL is also rearchitected along similar lines, one could optionally write a SASL handler that uses libsasl2's systemwide configuration in. This would allow adding SASL mechanisms written for the libsasl2 plugin approach; check out this client- AND server-side SASL mechanism implementation for XOAUTH2.}

[slingamn]

I think we might be talking about different things. When you say "offer a password-checking interface{}", are you saying "offer it to developers who will then make non-first-party code changes to Oragono"? The assumption I was making is that all functionality will be implemented in trunk, then controlled by the operator using the config file.

I agree that it's inappropriate for Oragono to try to store ircd-specific data in LDAP.

[ivucica]

I’d certainly prefer the changes to happen in trunk — forks of a healthy project rarely survive long. However, it’s good to structure things in a way that would allow adding more implementations. That’s all I meant. If the interface{} is designed and used well, even an optional PAM-based implementation could be contributed (which would pull in some C code). Or it could be maintained in a fork. Or out-of-tree. I’m not sure my approach to talking to LDAP in my toy projects is best, but perhaps I can attempt a demo PR over the holidays. -- Sent from Gmail Mobile

[slingamn]

That makes sense, thanks.

The plan is that Oragono will always maintain some amount of user data in its own database (either buntdb or some other remote datastore, via an abstraction layer, see #357).

I'm definitely interested in a proof-of-concept PR that integrates an LDAP client. In particular, if you're in a position to choose an LDAP client library that is clean, small, well-maintained, and doesn't have weird transitive dependencies, and then write a PoC for integrating it into oragono, that would be really helpful.

In terms of pluggable password checking, most of the authentication extensions we're looking at aren't using SASL PLAIN at all (#502, #175, #414) --- this one is sort of an exception.

[ivucica]

Regarding e.g. #175, you'd get SCRAM-SHA-256 for free with libsasl2, and (not sure) SASL EXTERNAL as well for #414. I'd be happy enough to get LDAP stuff working. I might tackle that then.

[slingamn]

I've renamed this ticket to "support LDAP", we can spin off additional subtickets as needed.

[slingamn]

Some implementation notes:

1. Operators who want to use LDAP will turn off user registration (set accounts.registration.enabled to false), turn on accounts.require-sasl.enabled, and then configure LDAP in a new subsection of the accounts section.
2. This section will contain information on how to talk to the LDAP server and how to do "DN resolution" (I'm personally unclear on what exactly that involves :-)
3. It should also have some way to control which valid LDAP accounts are allowed to log into Oragono (I'm not sure what sources of LDAP metadata this functionality can draw on)
4. The place to add LDAP support is probably inside AccountManager.AuthenticateByPassphrase. If LDAP is enabled in the config, instead of trying to check the passphrase against a bcrypt hash in the local database, it'll call out to the LDAP server. It should autocreate an account in the database if necessary, with blank local credentials (no local passphrase hash, no certfp).
5. I'm not sure whether LDAP should completely replace local credentials when enabled, or whether failed LDAP logins should try to fall back to local passphrase checking.
6. When we design this functionality, we should keep in mind CA-based system for client certificates #414, which gets into a lot of the same issues (having an alternative source of truth for authentication, autocreating accounts on first login, etc.)

[matt0x6F]

I'm not sure whether LDAP should completely replace local credentials when enabled, or whether failed LDAP logins should try to fall back to local passphrase checking.

Places I've been at it's been common when running any kind of external authentication to have at least one local account that can be used. If it's an easy option then we should aim to do that.

[ivucica]

For 3.: group membership