using lualdap ( http://www.keplerproject.org/lualdap/ ) one could assert a simple
bind like this:
This would allow prosody if the supplied credentials are valid
Sadly, I am not fluid in lua and don't really have the time at the moment :(
possible in the current trunk version thanks to cyrus sasl
( --> http://blog.marc-
I'm uncertain yet whether this is enough to satisfy everyone, or whether we should
still add native support. Native support would allow to integrate vCards with LDAP I
guess, so it's probably still desirable.
Native LDAP support would be a huge win. In addition to populating vCards from LDAP
(I'm having problems getting vCards to work with SASL authenticated users, but that's
another issue), authentication configuration would be simplified. Also, allowing
multiple forms of authentication, e.g. LDAP users and a local user database, is
something that drew me to Prosody in the first place. I've implemented this by using
both auxprop with sasldb and saslauthd, but the configuration is not pretty. Also,
I'd love to not have to install Cyrus SASL on my systems.
There is a mod_auth_ldap in prosody-modules that is compatible with trunk/0.8. It requires LuaLDAP and best of all hasn't been tested... volunteers welcome :)
The new storage API in trunk/0.8 should also allow for a full LDAP storage backend to be written.
I have written a mod_auth_ldap version, based on the one posted above, which works for me with prosody 0.8 RC1 (module is attached).
It uses ldap_bind to test the user password instead of a plaintext lookup, and allows you to add an additional filter. It still assumes your username is stored in 'uid', but this should be easy to change. It does a lookup to find the DN, so it does not depend on the username to be in the DN, but requires two binds per login (should be easy to change in the code to use only one bind if the DN can be constructed from the username, but it requires a bit more code to make a single configurable module which supports both methods).
To use it, place the following in your prosody.cfg.lua
ldap_server = "servername";
ldap_base = "ou=People,dc=example,dc=org";
ldap_rootdn = "<admindn>"; -- optional
ldap_password = "<adminpw>"; -- optional
ldap_filter = "(authorizedService=jabber)"; -- optional
-- dont forget this one!
authentication = "ldap";
Pushing this to a future release so as to not block 0.10. The modules are available already, in any case. They just won't be shipped with Prosody.
Pushing to new milestone. As I wrote in my previous comment, LDAP modules already exist in prosody-modules. Some feedback on those from people who are actively using them would be good.
After having a short chat with Zash on Prosody channel, I thought to leave a couple of comments since I have faced some LDAP-related issues on Debian after upgrading to 0.11.0.
Currently I am using the mod_auth_ldap module, and it has worked pretty fine in the releases prior to 0.11.0. This is both on Debian 8 Jessie and Debian 9 Stretch.
However, one good thing to try to keep in mind would be that Debian at the moment (even in unstable) does not have Lua LDAP bindings for Lua 5.2, only for Lua 5.1. And this broke my Prosody set-up during upgrade to 0.11.0.
The Debian bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814218 gives some pretty good information about relevant issues (namely the maintenance of Lua LDAP package seems a bit flaky).
Related to module itself, I have a couple of items as feedback:
- Currently only the password-based authentication is supported. It might be nice to be able to support other types of authentication, like TLS (client) certificate etc. SASL has been mentioned on chat in general.
- If you want to have a filter that grants XMPP access to a specific group of users, you must use some form of meta-attribute at the moment (e.g the memberOf attribute via OpenLDAP's memberof overlay). In many cases it might make more sense to introduce a group-based filter instead (e.g. specifying groupOfNames or groupOfUniqueNames entry in LDAP directory). In such a case it could be useful to have ability to recurse the groups as well (can be costly, though, and I think only AD has some kind of built-in support for this for doing it server-side).