LDAP auth and ptloader

[ellie timoney]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190614/88144b1c/attachment.html>