Re: LDAP auth and ptloader

"ellie timoney" <ellie@xxxxxxxxxxxx> · Fri, 14 Jun 2019 13:38:52 +1000

Hi Sven,

On Thu, Jun 13, 2019, at 12:27 AM, Sven Schwedas wrote:
Is there another way to get ptloader to spit out debug information and
pinpoint what's not set up correctly?

I remember this thing as being very noisy, let me see...

Okay, in your cyrus.conf SERVICES entry, if you add "-d1" to the ptloader line like this,

         ptloader cmd="ptloader -d1" listen="/path/to/some/socket" 

then ptloader will syslog every user that it's asked about...

You need "debug: 1" in imapd.conf, which will tell Cyrus to not swallow LOG_DEBUG level log lines, but ALSO: your syslog itself must be configured to log these lines (the default is often to not).  We have some makeshift instructions here but ymmv: https://www.cyrusimap.org/imap/installing.html#setting-up-syslog

If you turn on the "ptloader -d1" switch and set debug:1 and don't start seeing entries in your logs like "ptloader[pid]: user [user]", then you need to fiddle with syslog to enable the LOG_DEBUG log level :)

Here's an example of some ptloader log output from running our test suite, for example:

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: executed

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: starting: ptloader.c 3.1.6-696-gf38559858

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: accepted connection

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: user admin

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: collecting all domains from ou=domains,o=cyrus

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Domain filter: (&(objectclass=domainrelatedobject)(associateddomain=*))
Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: we have a domain internal.

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: ptsmodule_standard_root_dn called for domain internal.

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=internal

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=internal

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=internal

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Found admin in dc=internal

Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: we have found admin in dc=internal

And part of another run, showing it resolving a group membership (sorry these lines got truncated during copy&paste, but you get the idea):

Jun 14 13:11:47 debian 0311460101/ptloader[16345]: accepted connection

Jun 14 13:11:47 debian 0311460101/ptloader[16345]: user group:group co

Jun 14 13:11:47 debian 0311460101/ptloader[16345]: (groups) about to search ou=groups,o=cy

Jun 14 13:11:47 debian 0311460101/imap[16344]: timeout_select exiting. r = 1; errno = 0

Jun 14 13:11:47 debian 0311460101/imap[16344]: timeout_select: sock = 15, rp = 0x7ffca95e3

Jun 14 13:11:47 debian 0311460101/imap[16344]: timeout_select exiting. r = 1; errno = 0

Jun 14 13:11:47 debian 0311460101/imap[16344]: ptload read data back

Jun 14 13:11:47 debian 0311460101/imap[16344]: ptload returning data

Jun 14 13:11:47 debian 0311460101/imap[16344]: canonified group:group co -> group:group co

Not sure if this is helpful, but this is the directory structure our tests are working with:

https://github.com/cyrusimap/cassandane/blob/master/data/directory.ldif

... ohhhhhhh,

ldap_member_attribute: memberUid 

This kinda sounds like your groups are what I think of as "normal": a group in LDAP is an entry that contains a multi-valued attribute listing all the group members.  Is that a good description of your schema?

As far as I've been able to figure out while building tests, Cyrus seems to expect each user entry to contain a multi-valued attribute listing the groups it is a member of (e.g. see that directory.ldif linked above).  This feels backwards to me, but maybe it's normal somewhere??  I don't understand the rationale for this choice, or whether Cyrus can support a "normal" setup... maybe using the "ldap_member_method: filter" configuration (vs the default setting of "attribute") somehow??

Hopefully this is enough for you to get some useful logging out of the thing anyway,

Cheers,

ellie
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus