Prosody LDAP plugins

2,916 views
Skip to first unread message

Rob Hoelz

unread,
Mar 4, 2012, 12:26:57 PM3/4/12
to proso...@googlegroups.com
Hello Prosody developers,

I've developed a small suite of LDAP-based functionality for prosody,
using some code from mod_auth_ldap. The archive containing the plugins
can be found here:

http://hoelz.ro/files/prosody-ldap-plugins.tar.gz

The suite includes LDAP authentication, rosters, groups, and vCard
support. Please give it a try and let me know what you think.

Thanks,
Rob

signature.asc

Matthew Wild

unread,
Mar 4, 2012, 1:39:47 PM3/4/12
to proso...@googlegroups.com

Wow, nice, thanks! :)

I just gave a quick glance over... code looks nice, the documentation
too! I won't have time to try it out myself for some while (we're
focusing solely on the 0.9 release at the moment), but it would be
great to hear from anyone who does try them.

It would be good to get these into prosody-modules at some point. I
can give you push access to the repository if you like, but it would
be better to not overwrite the existing mod_auth_ldap there for the
moment (we now have a total of 3, yay...).

Regards,
Matthew

PS. One thing I just noticed in the docs, this:

With that note in mind, you need to set 'allow\_unencrypted\_plain\_auth' to
true in your configuration if you want to use LDAP authentication.

This shouldn't be necessary - this setting controls plain auth *only*
on unencrypted connections. Ideally all connections are encrypted, and
I don't recommend enabling this as a rule because it really is
insecure. Plaintext auth on encrypted connections is completely
allowed by default.

quantumriff

unread,
Apr 26, 2012, 4:52:23 PM4/26/12
to proso...@googlegroups.com
Rob, I found your post, and am trying to use it to do just basic user authentication via ldap.  I am trying to follow the readme that you included, but am unsure of several details (sorry, am trying to read lua, but I am not much of a programmer)  You mention that we need to set several things, like 'hostname' but not where.. would that be set in the main /etc/prosody/prosody.cfg.lua file? or inside the ldap.lib.lua  file you included?  You mentioned in the readme that there would be an example, but I didn't find one.

I am getting all sorts of errors about user not being set, and would love to see a sample (sanitized) config, since i'm not sure if I am even starting out right.. (I am trying to run prosody on CentOS 6.2, and really want to get ldap working, since we already have all our users defined in there..)


Thanks,

here is an example of what I am getting, probably from having a bad syntax or wrong location I am defining things..

Apr 26 15:40:48 xmppclient_listener error Traceback[c2s]: /usr/lib64/prosody/modules/ldap/ldap.lib.lua:180: attempt to index field 'user' (a nil value): stack traceback:
/usr/lib64/prosody/net/xmppclient_listener.lua:62: in function </usr/lib64/prosody/net/xmppclient_listener.lua:62>
/usr/lib64/prosody/modules/ldap/ldap.lib.lua:180: in function </usr/lib64/prosody/modules/ldap/ldap.lib.lua:179>
(tail call): ?
/usr/lib64/prosody/modules/mod_auth_ldap.lua:60: in function 'plain_test'
/usr/lib64/prosody/util/sasl/plain.lua:63: in function </usr/lib64/prosody/util/sasl/plain.lua:37>
(tail call): ?
/usr/lib64/prosody/modules/mod_saslauth.lua:76: in function </usr/lib64/prosody/modules/mod_saslauth.lua:65>
(tail call): ?
/usr/lib64/prosody/util/events.lua:67: in function 'fire_event'
/usr/lib64/prosody/core/stanza_router.lua:135: in function </usr/lib64/prosody/core/stanza_router.lua:44>
(tail call): ?
...
[C]: in function 'parse'
/usr/lib64/prosody/util/xmppstream.lua:200: in function 'feed'
/usr/lib64/prosody/net/xmppclient_listener.lua:145: in function 'data'
/usr/lib64/prosody/net/xmppclient_listener.lua:161: in function </usr/lib64/prosody/net/xmppclient_listener.lua:158>
(tail call): ?
/usr/lib64/prosody/net/server_select.lua:820: in function </usr/lib64/prosody/net/server_select.lua:802>
[C]: in function 'xpcall'
/usr/lib64/prosody/../../bin/prosody:427: in function 'loop'
/usr/lib64/prosody/../../bin/prosody:494: in main chunk
[C]: ?

Rob Hoelz

unread,
Apr 27, 2012, 4:42:49 AM4/27/12
to proso...@googlegroups.com
I'd be happy to help; I realize I neglected to provide an example of how the configuration *actually* looks in prosody.cfg.lua!  The configuration goes directly into that file; so it'd look something like this:

ldap = {
  hostname = 'my.ldap.server',
  user          = { ... },
  groups      = { ... },
}

I don't have the configuration file I used at my previous job handy, so I'll post that when I get home from work tonight.

-Rob

quantumriff

unread,
May 2, 2012, 6:11:57 PM5/2/12
to proso...@googlegroups.com
Rob, sorry for taking so long to reply, i have a pile of catch up stuff lately (and I haven't even been gone!)

I am trying to get the ldap authentication working, and have set my /etc/prosody/prosody.cfg.lua to this:

authentication = "ldap";
ldap = {
hostname = "ldap-slave.domain.local";
basedn = "ou=People,cn=domain,cn=local";
usernamefield = "uid";
        namefield = "cn";
}

When I try to connect to prosody, I get the following error, which is weird that the field "user" is not getting passed in from the app?

From a tcpdump, I can see that no connection hits my LDAP server..

May 02 16:43:28 xmppclient_listener error Traceback[c2s]: /usr/lib64/prosody/modules/ldap/ldap.lib.lua:180: attempt to index field 'user' (a nil value): stack traceback:
/usr/lib64/prosody/net/xmppclient_listener.lua:62: in function </usr/lib64/prosody/net/xmppclient_listener.lua:62>
/usr/lib64/prosody/modules/ldap/ldap.lib.lua:180: in function </usr/lib64/prosody/modules/ldap/ldap.lib.lua:179>
(tail call): ?
/usr/lib64/prosody/modules/mod_auth_ldap.lua:60: in function 'plain_test'
/usr/lib64/prosody/util/sasl/plain.lua:63: in function </usr/lib64/prosody/util/sasl/plain.lua:37>
(tail call): ?
/usr/lib64/prosody/modules/mod_saslauth.lua:76: in function </usr/lib64/prosody/modules/mod_saslauth.lua:65>
(tail call): ?
/usr/lib64/prosody/util/events.lua:67: in function 'fire_event'
/usr/lib64/prosody/core/stanza_router.lua:135: in function </usr/lib64/prosody/core/stanza_router.lua:44>
(tail call): ?
...
[C]: in function 'parse'
/usr/lib64/prosody/util/xmppstream.lua:200: in function 'feed'
/usr/lib64/prosody/net/xmppclient_listener.lua:145: in function 'data'
/usr/lib64/prosody/net/xmppclient_listener.lua:161: in function </usr/lib64/prosody/net/xmppclient_listener.lua:158>
(tail call): ?
/usr/lib64/prosody/net/server_select.lua:820: in function </usr/lib64/prosody/net/server_select.lua:802>
[C]: in function 'xpcall'
/usr/lib64/prosody/../../bin/prosody:427: in function 'loop'
/usr/lib64/prosody/../../bin/prosody:494: in main chunk
[C]: ?

Rob Hoelz

unread,
May 3, 2012, 4:00:04 AM5/3/12
to proso...@googlegroups.com
Your LDAP configuration should look something like this:

ldap = {
  user = {
    basedn            = my_base_dn,
    filter                 = my_filter,
    usernamefield = my_username_field,
    namefield        = my_name_field,

jleu

unread,
Jun 8, 2012, 9:20:49 AM6/8/12
to prosody-dev
We have this module in production. Here is an example based on our
config:

authentication = "ldap";
storage = "ldap";

ldap = {
hostname = 'ldap.example.com',
user = {
basedn = 'ou=People,dc=example,dc=com',
filter = '(&(objectClass=posixAccount)(gidNumber=100))',
-- 100 is the gid of users
usernamefield = 'uid',
namefield = 'cn',
},

-- all employees and admins have users and their native group but
are membersOf employees or admins
groups = {
basedn = 'ou=Group,dc=example,dc=com',
memberfield = 'memberUid',
namefield = 'cn',

{
name = 'Admins',
cn = 'admins',
admin = true,
},
{
name = 'Employees',
cn = 'employees',
},
},
};

Rob Hoelz

unread,
Sep 2, 2012, 9:58:26 AM9/2/12
to proso...@googlegroups.com
Hello everyone interested in this bundle of plugins!  I'd like to inform you all that I have finally uploaded the suite to prosody-modules; the plugins' names are mod_auth_ldap2, mod_lib_lidap, and mod_storage_ldap.  I also included a sample configuration and LDIF file for testing, and a miniature test suite written in Perl.  The code shouldn't have changed much (or really at all), but please feel free to test these versions out and let me know if you encounter any issues!

Thanks,
Rob

Rob Hoelz

unread,
Sep 17, 2012, 6:36:59 PM9/17/12
to proso...@googlegroups.com
Hi again, everyone!

Thanks to an outstanding contributon from Petter Ericson, the LDAP plugin suite now supports BINVAL avatars in vCards!  The latest and greatest has been pushed to prosody-modules!

-Rob

Guilhem LETTRON

unread,
Dec 3, 2012, 9:37:07 AM12/3/12
to proso...@googlegroups.com
Hi all,

I try to use this plugin today.

It uses "ldap" configuration to import groups in roaster like mod_groups.

There is some lacks, but it works :)

Some people want to push it in prosody-modules upstream ?

Guilhem LETTRON
Ingénieur - Architecte système
Youscribe - www.youscribe.com


--
You received this message because you are subscribed to the Google Groups "prosody-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/prosody-dev/-/mcXPsaQeXv0J.

To post to this group, send email to proso...@googlegroups.com.
To unsubscribe from this group, send email to prosody-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/prosody-dev?hl=en.

Vadim A. Misbakh-Soloviov

unread,
Dec 3, 2012, 12:00:03 PM12/3/12
to proso...@googlegroups.com
> Some people want to push it in prosody-modules upstream ?
so,
> There is some lacks, but it works :)
for example? ;)

signature.asc

Rob Hoelz

unread,
Dec 3, 2012, 2:24:47 PM12/3/12
to proso...@googlegroups.com, guilhem...@gmail.com
> >>> http://hoelz.ro/files/prosody-**ldap-plugins.tar.gz<http://hoelz.ro/files/prosody-ldap-plugins.tar.gz>
> >>>
> >>> The suite includes LDAP authentication, rosters, groups, and vCard
> >>> support. Please give it a try and let me know what you think.
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>> --
> > You received this message because you are subscribed to the Google
> > Groups "prosody-dev" group.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msg/prosody-dev/-/mcXPsaQeXv0J.
> >
> > To post to this group, send email to proso...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > prosody-dev...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/prosody-dev?hl=en.
> >
>

Hi Guilhem!

Thanks for looking at the LDAP plugins; I have a few
questions/comments, if you don't mind.

1) I noticed your change to mod_lib_ldap.lua (the one regarding the
bind function); what improvements does this make or bugs does this
fix? My LDAP-fu is actually pretty weak, and I've only used the plugin
in a limited setting, so maybe your setup is different than what I
normally test against!

2) I'm happy to see you implemented LDAP roster groups, but this
functionality already exists in mod_storage_ldap. Did you add any
capabilities to your own implementation that are absent from
mod_storage_ldap? If so, I would be happy to merge them in!

Thanks,
Rob
signature.asc

Guilhem LETTRON

unread,
Dec 3, 2012, 3:31:16 PM12/3/12
to Rob Hoelz, proso...@googlegroups.com
hi all,


On Mon, Dec 3, 2012 at 8:24 PM, Rob Hoelz <r...@hoelz.ro> wrote:
> 1) I noticed your change to mod_lib_ldap.lua (the one regarding the
> bind function); what improvements does this make or bugs does this
> fix?  My LDAP-fu is actually pretty weak, and I've only used the plugin
> in a limited setting, so maybe your setup is different than what I
> normally test against!

For now, bind was working like this :
get username : john.doe
get host : example.com
get dn : ou=people,dc=example,dc=com
test bind to : uid=join.doe,ou=people,dc=example,dc=com

This is a trivial but weak idea. LDAP is powerful, you can have many groups in another groups. Current implementation doesn't manage it.

In any LDAP software you do another way :
get username : john.doe
get dn : ou,people,dc=example,dc=com
find userdn : search in ou,people,dc=example,dc=com a user who match uid=john.doe
return dn : uid=john.doe,ou=room1,ou=center3,ou,people,dc=example,dc=com
test bind to : uid=john.doe,ou=room1,ou=center3,ou,people,dc=example,dc=com

This is the "right" way :)
You can also add more flexibility with a "filter".
I implement this.

> 2) I'm happy to see you implemented LDAP roster groups, but this
> functionality already exists in mod_storage_ldap.  Did you add any
> capabilities to your own implementation that are absent from
> mod_storage_ldap?  If so, I would be happy to merge them in!

Mod_storage is read_only (what I read).
With my mod_groups_ldap, you can mix a contacts (my oncle, my friend ...) with all my coworkers classified by service automatically injected.
Maybe I can be wrong, but this isn't possible with mod_storage_ldap and is a big lack for me

>> Some people want to push it in prosody-modules upstream ?
>so,
>> There is some lacks, but it works :)
>for example? ;)

There is 2 TODO in my file :)
I not implement "name" for group and user

  user = {
    namefield     = 'cn' 
  }
  groups = {
    {
      name  = 'everyone'
    }
  }
I always use "cn" name for group and jid for user. I don't find a good way to do this.

Rob Hoelz

unread,
Dec 3, 2012, 3:47:08 PM12/3/12
to Guilhem LETTRON, proso...@googlegroups.com
Hi again!

I've replied to your points from your previous e-mail, responses are
inline. (For those of you who are skimming, I have a question at the
end about Prosody in general)
So what you added was the ability to bind to a DN based on the user ID,
but arbitrarily deep into the LDAP record structure? So all of the
following would bind ok:

uid=john.doe,ou=people,dc=example,dc=com
uid=john.doe,foo=bar,ou=people,dc=example,dc=com
etc...

I implemented bind the way I did because then you could be explicit
about exactly which records you would bind to. Is it the case that
organizations set up their LDAP servers to have user records (and
others) nested arbitrarily deep? I haven't seen that before, but as I
said, my experience with LDAP is fairly limited!

Either way, I like the filter idea a lot! I'll be sure to add it.

>
> > 2) I'm happy to see you implemented LDAP roster groups, but this
> > functionality already exists in mod_storage_ldap. Did you add any
> > capabilities to your own implementation that are absent from
> > mod_storage_ldap? If so, I would be happy to merge them in!
>
> Mod_storage is read_only (what I read).
> With my mod_groups_ldap, you can mix a contacts (my oncle, my
> friend ...) with all my coworkers classified by service automatically
> injected. Maybe I can be wrong, but this isn't possible with
> mod_storage_ldap and is a big lack for me

It is indeed read-only. If I understand you correctly, you want a
regular contacts roster (which you can change from your XMPP client)
plus a set of groups from LDAP. I've had people ask about this before,
but I haven't come up with a good solution. I think that perhaps a
"mixed storage" storage driver would be a good idea for this, so when a
retrieve operation is performed for the contacts list, the filesystem
storage driver is consulted first, then the LDAP driver. Other Prosody
folk: what do you think of this idea?
signature.asc

Guilhem LETTRON

unread,
Dec 3, 2012, 5:43:35 PM12/3/12
to Rob Hoelz, proso...@googlegroups.com
On Mon, Dec 3, 2012 at 9:47 PM, Rob Hoelz <r...@hoelz.ro> wrote:
> > This is the "right" way :)
> > You can also add more flexibility with a "filter".
> > I implement this.
>
> So what you added was the ability to bind to a DN based on the user ID,
> but arbitrarily deep into the LDAP record structure? So all of the
> following would bind ok:
>
> uid=john.doe,ou=people,dc=example,dc=com
> uid=john.doe,foo=bar,ou=people,dc=example,dc=com
> etc...
>
> I implemented bind the way I did because then you could be explicit
> about exactly which records you would bind to. Is it the case that
> organizations set up their LDAP servers to have user records (and
> others) nested arbitrarily deep? I haven't seen that before, but as I
> said, my experience with LDAP is fairly limited!
>
> Either way, I like the filter idea a lot! I'll be sure to add it.
>

Here is a example in ruby
http://www.redmine.org/projects/redmine/repository/entry/trunk/app/models/auth_source_ldap.rb
have a look to the function "get_user_dn"
another one in python :
https://github.com/marcinkuzminski/rhodecode/blob/master/rhodecode/lib/auth_ldap.py

As you can see everyone do the same ;) (my formation is sysadmin /
devops, I can garantee that is the _good_ practice)

to reassure you: you must _never_ have 2 same uid in your LDAP (not
only in the same OU), as you can't have 2 users with the same name on
a *nix system. (that's what is an uid ;) )
So be careful of your ldap and what it mean and every things will be ok :)

> "mixed storage" storage driver would be a good idea for this, so when a
> retrieve operation is performed for the contacts list, the filesystem
> storage driver is consulted first, then the LDAP driver. Other Prosody
> folk: what do you think of this idea?

My mod_groups_ldap do exactly what you want.

Guilhem LETTRON

unread,
Dec 4, 2012, 4:36:30 AM12/4/12
to proso...@googlegroups.com, Rob Hoelz
On Tue, Dec 4, 2012 at 1:51 AM, maat <mini.m...@googlemail.com> wrote:
> One thing I saw with Guilhem's solution was, that he did not patch the
> function _M.singlematch(query) to search through deeper levels of the tree.

Yes I only modify what I need, use and understand (to prevent any side effect)

> Using my solution it is possible to use the root (or any other leaf, in case
> all users are part of that subtree) as basedn and search for all users that
> match the criterion. It is even possible to use groups, by using a filter
> like: filter =
> "(&(objectClass=account)(memberOf=cn=your-grpup,ou=groups,dc=test,dc=com))"

usage of "memberOf" is often forbidden :
It's a common practice on Active Directory because it support it but
this is not the case for every ldap implementation.
For openLdap, you need a medium/high skill to install an external
plugin and it only work with a "groupofNames" and not a "posixGroup".

"memberOf" has also consistency problems with backup / migration (not
atomic operations) etc. So memberOf must be avoid if another solution
exist

Guilhem LETTRON

unread,
Dec 5, 2012, 6:04:39 AM12/5/12
to proso...@googlegroups.com, Rob Hoelz
FYI, I push new changes :
https://code.google.com/r/guilhemlettron-ldap/source/detail?r=0be7f4b4226af2ddf0445db41a819e184d128d15

I created a new lib : mod_lib_groups_bookmarks.
Changed mod_group_bookmarks to use it and a new one mod_groups_bookmarks_ldap.

Guilhem LETTRON
Youscribe - www.youscribe.com

Rob Hoelz

unread,
Dec 5, 2012, 6:07:23 AM12/5/12
to proso...@googlegroups.com
Thanks for keeping us up to date on this! I'll look at your changes and
merge them into my module(s), and I'll also take a look at your new
plugins and see if I can merge their functionality into my LDAP stuff as
well.

-Rob

Guilhem LETTRON

unread,
Dec 7, 2012, 11:00:17 AM12/7/12
to proso...@googlegroups.com
On Thu, Dec 6, 2012 at 2:53 PM, UxBoD <spla...@gmail.com> wrote:
> One enhancement which I would love to see included is the ability to sign
> into Prosody using the full JID and not only the username element.
> Hopefully then one could use the 'mail' attribute from the DIT record
> instead of the 'uid'. I guess an account with the necessary rights to
> search that basedn would first bind, using the specified filter
> (&(mail=JID)) find the associated dn, and then use that 'uid' and password
> to re-bind and validate the credentials. The kicker to this is that the
> account should be available externally via the full JID and not the 'uid'.
> Hope that makes sense ?

I'm happy you talk about it.
I think I will implement this in my last commits (last week I hope, I
already have some work).

I will let anyone to set the attribute to check (mail it you want to)
but I will provide a standard schema for a "jid" attribute :

this one : http://apreta.bzr.sourceforge.net/bzr/apreta/annotate/354.1.1/jabberd/xdb_ldap/jabber.schema
or this one : http://files.inmeta.net/pub/phamm/schema/perversia.net.schema

The OID are registered by IANA for this 2.

If someone know another schema registered let me know.

P D

unread,
Dec 8, 2012, 4:11:36 AM12/8/12
to proso...@googlegroups.com

The way I envisage it is one binds with an admin account first and searches for the JID using the specified attribute. When that is found the DN is extracted and a rebind happens using the password supplied by the connecting guest. If successful then the username within Prosody (SASL) function is set to the supplied JID. Thanks.

--
You received this message because you are subscribed to the Google Groups "prosody-dev" group.

Rob Hoelz

unread,
Dec 10, 2012, 5:06:32 PM12/10/12
to proso...@googlegroups.com
Hey everyone,

Thanks again for trying out these plugins, and for your excellent feedback!  I managed to gather up enough time for tonight, and I have integrated the patches into prosody-modules and prosody-modules-0.8!

I decided not to integrate Guilhem's new plugins, as I believe that these belong in a "multi-storage" storage plugin (as discussed here: https://groups.google.com/forum/?fromgroups=#!topic/prosody-dev/FuiV_KT9hmc).  But I added the subtree search for singlematch, so deeper records will now be considered for authentication.  Also, I made sure that the filter works for authentication.  Of course, I added tests for the new functionality. ;)

To everyone who submitted code, your contribution is much appreciated!  To everyone who is using this module with Prosody, please feel free to grab the latest version from Mecurial and try it out on your installation; you shouldn't have to change anything!

UxBoD:  I haven't added your feature yet, as I wanted to merge the patches already present and push them upstream in a single sitting.  I'll look into adding the full JID match feature in a future coding session!

-Rob

John T

unread,
Dec 13, 2013, 12:41:31 PM12/13/13
to proso...@googlegroups.com
New to prosody and lua, so please bear with me.

Thank you for these excellent LDAP mods, however is there anyway to change the ldap stoarge to use groupofnames vs posix group for the rosters?

I can successfully retrieve rosters with posix groups but have had no luck trying to tweak for groupofnames.

Has anyone been successful working with rosters using a groupofnames?  Any help would be much appreciated.

Rob Hoelz

unread,
Dec 13, 2013, 5:19:09 PM12/13/13
to proso...@googlegroups.com, c1nc...@gmail.com
Hi,

I'm the developer who wrote mod_auth_ldap2, mod_storage_ldap, and
mod_lib_ldap.

I've had groupOfNames as a feature on the TODO list for a while, but I
haven't had the time to devote to developing it, nor have I
personally had the need for the feature. If you would like to
contribute, I would be happy to accept patches.

-Rob

John T

unread,
Dec 13, 2013, 7:30:32 PM12/13/13
to proso...@googlegroups.com, c1nc...@gmail.com
Hi Rob,

Thank you for the quick response and answer.

I wish I had the ability to contribute towards your contribution, however, I have zero experience with lua, combined with very minimal ldap experience.  I however will hold out hope, that someone wiser, smarter and with available time can chug this along.  Should you or anyone else need any test environments etc to move this along, I would happily make those resources available.

Thank you for your wonderful ldap mods and enjoy the holidays,

-John

John T

unread,
Dec 14, 2013, 3:47:43 PM12/14/13
to proso...@googlegroups.com, c1nc...@gmail.com
Hi Rob,

Now that I think through it the change to groupofnames should be a pretty simple hack, I think?

First the only change in the ldap-config would be the change the value of "memberfield" to member from memberUid like so:

    groups = {
      basedn      = 'ou=groups,dc=example,dc=com', -- The base DN where group records can be found
      memberfield = 'member',
      namefield   = 'cn', 

this should return something like : "cn=user1,ou=people,dc=example,dc=com" -- vs posix memberUid : "user1"

Would it be as simple as using a regex to strip "cn=" and everything after and including the first comma?

Does this sound right? Or am I way off?

Rob Hoelz

unread,
Dec 14, 2013, 4:28:26 PM12/14/13
to proso...@googlegroups.com, c1nc...@gmail.com
The change wouldn't actually be that bad; you just need to find the
relevant portions of mod_ldap_auth2 and mod_storage_ldap that refer to
the memberfield of the user.

On Sat, 14 Dec 2013 12:47:43 -0800 (PST)
John T <c1nc...@gmail.com> wrote:

> Hi Rob,
>
> Now that I think through it the change to groupofnames should be a
> pretty simple hack, I think?
>
> First the only change in the ldap-config would be the change the
> value of "memberfield" to *member* from *memberUid* like so:
>
> groups = {
> basedn = 'ou=groups,dc=example,dc=com', -- The base DN
> where group records can be found
> memberfield = '*member*',
> namefield = 'cn',
>
> this should return something like :
> "*cn=user1,ou=people,dc=example,dc=com*" -- vs posix memberUid :
> "*user1*"

John T

unread,
Dec 18, 2013, 7:38:44 PM12/18/13
to proso...@googlegroups.com, c1nc...@gmail.com
Thanks Rob, I am slowly trying to work through it.

I have however run into another speed bump with the ldap plugins...I can't seem to connect to an external ldap server using tls/port 636.

If I run an ldapsearch below (ldap-utils) from the prosody box to external ldap server, results are returned as expected:
ldapsearch -H ldaps://ld1.example.com:636 -D "cn=admin,dc=example,dc=com" -w "password" -b "ou=domains,ou=groups,dc=example,dc=com" "(&(objectclass=posixgroup)(memberUid=testuser))"

If I use cyrus sasl for ldap authentication with prosody, registration works fine over tls/636, but then I cant use ldap for roster, or vcard this way.

Also connecting to external server over port 389 insecurely, everything works too.

Here is my config:


Can anyone point me in the right direction?

Thanks for looking!

Rob Hoelz

unread,
Dec 19, 2013, 3:23:55 PM12/19/13
to proso...@googlegroups.com, c1nc...@gmail.com
Hi John,

What does your prosody configuration look like? Do you have use_tls
set in the ldap section? (Probably not, as I just realized that this
option is undocumented!)

-Rob

On Wed, 18 Dec 2013 16:38:44 -0800 (PST)
John T <c1nc...@gmail.com> wrote:

> Thanks Rob, I am slowly trying to work through it.
>
> I have however run into another speed bump with the ldap plugins...I
> can't seem to connect to an external ldap server using tls/port 636.
>
> If I run an ldapsearch *below* (ldap-utils) from the prosody box to
> external ldap server, results are returned as expected:
>
> *ldapsearch -H ldaps://ld1.example.com:636 -D
> "cn=admin,dc=example,dc=com" -w "password" -b
> "ou=domains,ou=groups,dc=example,dc=com"
> "(&(objectclass=posixgroup)(memberUid=testuser))"*
>
> If I use cyrus sasl for ldap authentication with prosody,
> registration works fine over tls/636, but then I cant use ldap for
> roster, or vcard this way.
>
> Also connecting to external server over port 389 *insecurely*,

John T

unread,
Dec 19, 2013, 5:53:09 PM12/19/13
to proso...@googlegroups.com, c1nc...@gmail.com
Hi again Rob,

I have added the use_tls option, with no success.

Here is my complete config -- http://pastebin.com/E75JvDiQ

Also here is the logged error I receive whenever I try to specify a port with hostname (ex. hostname = 'auth.example.com:636',) -- http://pastebin.com/XW2kmEcA

If I don't specify the port, even with the use_tls = true --- it still will use a default connection port of 389, as I can see through firewall logs.

Thanks for the assistance

-John

Kim Alvefur

unread,
Dec 19, 2013, 6:02:07 PM12/19/13
to proso...@googlegroups.com
Hi John, Rob,

LuaLdap doesn't support ldaps. use_tls enables StartTLS (upgrade to
TLS), not ldaps (TLS first, then LDAP over that).

https://github.com/luaforge/lualdap/blob/master/lualdap/src/lualdap.c#L957
http://linux.die.net/man/3/ldap_start_tls_s

--
Kim "Zash" Alvefur

John T

unread,
Dec 19, 2013, 7:16:30 PM12/19/13
to proso...@googlegroups.com, za...@zash.se
Thank you for that info, just got it all sorted out.

Thank you Kim, and thank you Rob.

Stanislav Kopp

unread,
Jul 1, 2014, 12:28:36 PM7/1/14
to proso...@googlegroups.com
Not sure if this a right place to post, but does anybody have working examples of "Multi-level fields"  for vcard function? The documentation says "I recommend looking at the example configuration for clarification", but there are no examples for  "Multi-level fields" only for "photo" which is "Single-level field". I need working "telephone" and "email" mapping for vCard and can't lua to figure it out on my own.

Rob Hoelz

unread,
Jul 1, 2014, 3:55:56 PM7/1/14
to Stanislav Kopp, proso...@googlegroups.com
On Tue, 1 Jul 2014 09:28:36 -0700 (PDT)
Stanislav Kopp <stas...@gmail.com> wrote:

> Not sure if this a right place to post, but does anybody have working
> examples of "Multi-level fields" for vcard function? The
> documentation
> <https://code.google.com/p/prosody-modules/source/browse/mod_lib_ldap/README.md?repo=0-8&r=798ef3470b9e4779ed11d895c24148785d1d0a5e>
> says "I recommend looking at the example configuration for
> clarification", but there are no examples for "Multi-level fields"
> only for "photo" which is "Single-level field". I need working
> "telephone" and "email" mapping for vCard and can't lua to figure it
> out on my own.
>

Hi Stanislav,

Sorry for the lack of examples; try something like this:

telephone = {
{
work = 'work_phone' -- where work_phone is the name of the LDAP
-- field containing the work phone number
}
}

If this doesn't work, let me know and I can investigate further.

-Rob

Stanislav Kopp

unread,
Jul 2, 2014, 5:00:21 AM7/2/14
to proso...@googlegroups.com, stas...@gmail.com
Hi Rob, thanks for fast response. Unfortunately this example doesn't work for me, this is my vcard config

    vcard_format = { 
      displayname = 'cn', -- Consult the vCard configuration section in the README
      nickname    = 'uid',
      title    = 'title',
      telephone = { 
        {
         work = 'telephoneNumber'
        }
     }   
   },


I see all fields except "telephone" in jabber clent, so the mapping works in general. No errors in prosody debug log. 


Thanks for your help

Rob Hoelz

unread,
Jul 2, 2014, 8:45:19 AM7/2/14
to Stanislav Kopp, proso...@googlegroups.com
Hmm...I'll have to look at this later today, then.

On Wed, 2 Jul 2014 02:00:21 -0700 (PDT)

Rob Hoelz

unread,
Jul 2, 2014, 11:24:28 PM7/2/14
to proso...@googlegroups.com
Hi Stanislav,

Sorry for taking so long; try this:

telephone = {
work = {
voice = true,
number = 'telephoneNumber',
}
}

-Rob

On Wed, 2 Jul 2014 02:00:21 -0700 (PDT)

Stanislav Kopp

unread,
Jul 3, 2014, 5:31:16 AM7/3/14
to proso...@googlegroups.com
Hi Rob, 

thank you, it works! This is my vcard config for anyone interested, since it uses standard LDAP attribute names, it should work in most cases (@Rob maybe include this to prosody-posix-ldap.cfg.lua as examples?).

       telephone = { 
       work = { 
         number = 'telephoneNumber',
        }
      },  
      address = { 
       work = { 
         street = 'street', -- street name     
         pcode = 'postalCode', -- postal code
         locality = 'l', -- city name 
         ctry = 'c', -- country name 
        }
      },  
      email = { 
       internet = { 
         userid = 'mail',

Daniel Carrasco Marín

unread,
May 14, 2015, 1:28:00 PM5/14/15
to proso...@googlegroups.com
Thanks, but the links is dead. I'm searching for a mod_groups but with ldap and i want to try this package. For now i've configured the LDAP access with cirus.
Reply all
Reply to author
Forward
0 new messages