Hi Jim, It sounds like you’ve spotted a few issues and have fixed them. I’m quite interested to know what your imapd configuration is for pts and also how the configuration knows what OU the user you’re testing resides in? I haven't personally set up LDAP auth with Cyrus although it’s been something I’ve been wanting to do for some time (so showing a bit of interest in this thread).
When you mentioned nothing seems to get returned to ptloader, is it possible to confirm if there was a ldap response from the user search in the ldap packet trace? Was the result count returned and what was the format of searchresref? If that is returned on the wire (confirming user was found after the initial search) then I guess next step is to debug ptloader to see what that’s expecting to receive and whether the ldap response data gets there ? I’m assuming the search does find the user of interest and the result count is 1 and the distinguished name of the object is returned over the wire to the mail server? If the user is searched but not found, that’s likely a place to investigate e.g where in the tree is it trying to find the user - does the attribute you’re checking for and the user searched match up? For ptloader, there is a debug option. May be worth enabling that although not sure what that technically offers in terms of troubleshooting info. Im a bit unsure on how to attach strace in this context, which process ptloader operates under or whether it’s it’s own seperate process with its own pid. If it’s the later it’s probably going to be a bit easier. Bit of trial and error most likely. Regards Andrew Sent from my iPhone > On 17/06/2021, at 03:48, Jim Wallis <[email protected]> wrote: > > > Hi Andrew, > > This has been very helpful. I didn't think of using wireshark before, it has > enabled me to at least sort out a typo in my bind DN , but I am still not > much further on. > > With auth_mech: pts commented out, and using an imtest line like: > > imtest -u test -a test -w passfortest localhost > > I can see from the wireshark capture that Saslauthd is binding as the test > user and imtest authenticates OK > > with auth_mech: pts uncommented I need to provide bind credentials in > imapd.conf (I use the ones for my cyrus user so I can tell what is being > passed). This cyrus user binds successefully and looks up the test user, but > nothing seems to get returned to ptloader, so I probably need to spend more > time thinking about what attribute I need to return (I have tried several > likely candidates). It doesn't look as though saslauthd is used at all when I > have pts on. Imtest responds not authenticated. > > More work to do... I guess I need to learn how to use strace. > > Thanks > > Jim > > > > On 15/06/2021 20:30, AndrewHardy via Info wrote: >> Hi Jim, >> >> I’m not sure specifically what your issue is here but I’ll help provide some >> options for debugging ldap (specific to the windows logging question). I’d >> suggest dropping the TLS 636 LDAPS and just start with standard LDAP 389, >> removing TLS complexity whilst you validate a working configuration. >> >> I’d suggest also just running wireshark on the domain controller where you >> expect ldap connections to reach and capture the 389 traffic with a filter >> of your source mail server (or component doing the authentication). You’d be >> able to assess the ldap flow; whether the server sees it or not (and what >> the response was from the server, if any). >> >> You could also open another terminal, open saslauthd with strace and dump >> the authentication process to file to analyse what may be happening. If you >> can’t wireshark the target authentication service, you could perhaps tcpdump >> on the ldap client side, drop that into a .pcap file then open this in >> wireshark on your desktop for further analysis. >> >> I’m hoping those potential options can help verify what is/isn’t happening. >> An absence of traffic leaving the server would imply something on the client >> side, ruling out the ldap server at fault - at least initially. >> >> Hope this helps simplify troubleshooting and helps confirm what is/isn’t >> happening at least from an ldap perspective. Unsure of enabling ldap >> debugging in windows, I’ve searched for that for years and never really come >> up with a good solution. Wireshark and/or tcpdump has helped me solve all >> problems I’ve had with ldap/authentication although ldaps can be a bit more >> problematic when just using packet tracing software. Can still come in >> useful though. >> >> Regards >> Andrew >> >> Sent from my iPhone >> >>> On 16/06/2021, at 06:30, [email protected] wrote: >>> >>> >>> It seemed like it would be a good idea to use the existing Active Directory >>> DC as the LDAP source for all mail users. >>> >>> I got cyrus (3.2.6 from Buster backports) running using saslauthd for >>> authentication against the directory, and test users could authenticate OK >>> and see their mailbox in Thunderbird. relevant entires in imapd.conf: >>> >>> allowplaintext: yes >>> sasl_mech_list: PLAIN >>> sasl_pwcheck_method: saslauthd >>> >>> Because I want to use some groups for shared folders and distribution >>> lists, I also want to authorize users and groups against the directory so >>> enabled: >>> >>> auth_mech: pts >>> pts_module: ldap >>> ptloader_sock: var/lib/cyrus/ptclient/ptsock >>> ldap_uri: ldaps:/companydomaincontroller:636 >>> ldap_bind_dn: a cn that works in other binds >>> ldap_password: the password for above >>> ldap_sasl: 0 >>> ldap_version: 3 >>> ldap_ca_dir: /etc/ssl/certs (which is where the ca cert that works with >>> saslauthd resides) >>> ldap_verify_peer: 1 >>> ldap_base: base that other binds can successfully find users from >>> ldap_scope: sub >>> ldap_filter: (sAMAccountName=%u) (I have tried more complex filters and >>> decided on this as one that should work) >>> ldap_user_attribute: mail >>> ldap_size_limit: 1024 >>> I have commented out the group member stuff for now, need to walk before I >>> can run! >>> >>> With these options enabled, no one can authenticate, even though my >>> understanding is that authentication is distinct from authorization. >>> Thunderbird users can no longer login and imtest for user cyrus (which is >>> in the directory) gives the same output up to a line : >>> >>> C: A01 AUTHENTICATE PLAIN {a hash} >>> S: A01 NO authentication failure >>> Authentication failed. generic failure >>> Security strength factor: 256 >>> >>> (the SSF is reported the same, but I have for now only asked for level 0) >>> >>> In /var/log/syslog I find the following lines: >>> cyrus/ptloader[8230]: ldap_initialize failed (ldaps:/DC:636) >>> cyrus/imap[8229]: timeout_select exiting. r = 1; errno = 0 >>> cyrus/imap[8229]: timeout_select: sock = 11, rp = 0x7ffecbb6ad30, wp = 0x0, >>> sec = 30 >>> cyrus/imap[8229]: timeout_select exiting. r = 1; errno = 0 >>> cyrus/imap[8229]: ptload read data back >>> cyrus/imap[8229]: ptload(): bad response from ptloader server: >>> ptsmodule_connect() failed >>> cyrus/imap[8229]: No data available at all from ptload() >>> cyrus/imap[8229]: ptload completely failed: unable to canonify identifer: >>> cyrus >>> cyrus/imap[8229]: SASL bad userid authenticated >>> cyrus/imap[8229]: badlogin: localhost [::1] PLAIN (-notset-) [SASL(-6): >>> can't request information until later in exchange: Information that was >>> requested is not yet available.] >>> >>> I have been searching for answers for days and at one point found a >>> reference that claimed ptsloader is not enabled by default in Debian, so I >>> have downloaded the source package and compiled cyrus-imaps using a >>> configure script based on the Debain default config options with some extra >>> options: --with-auth=pts --with-pts=ldap and --with-ldap >>> This has made no difference. >>> I have also downlaoded the 3.4.1 source package from experimental and >>> compiled with the same options ands still no difference to behaviour so >>> suspect this is a red herring? >>> >>> So why is ptloader not retrieving any data? >>> The ldap_bind credentials I have given it work fine with saslauthd or >>> postfix or ldapsearch. >>> Presumably then my filter and user attributes are bad? But I can't see why. >>> >>> What is the order of operations within cyrus? >>> I assume that it authenticates first using saslauthd, and then uses the >>> same username to check authorization in pts, but enabling PTS seems to >>> prevent authentication. Although in syslog it is suggesting that SASL has >>> authenticated, but with a bad userid? >>> >>> The windows DC uses a directory migrated from an older one on a small >>> business server where microsoft recommended using an internal .local domain >>> which has always been a bit of a headache for me. This means that our >>> search base is a DC=local, as are the bind DN and userPrincipleName, but >>> the mail and proxyAddresses email addresses are all .com >>> Is the problem related to this? do I need to enable virtual domains and/or >>> cross realm authentication for ptloader to get a response from the server? >>> >>> Is there any way to call ptloader outside of master to try to work out >>> exactly what is being passed and what result it achieves? >>> >>> Also, how does ptdump work? I get no indication that it has done anything, >>> is this simply because ptloader has never yet obtained any data for it to >>> dump? >>> >>> As for checking the LDAP server logs, if anyone knows how I can do this on >>> windows 2012 please advise! Looking at directory services in event viewer I >>> see very few entries and nothing relating to communication from my mail >>> server. I assume I need to enable a different log level but I can't find >>> out how or what. >>> >>> All the examples I can find are based on openldap installations, is what I >>> am trying to do possible, or are the Active Directory schema completely >>> incompatible with ptloader? >>> >>> Jim Wallis >>> >>> > Cyrus / Info / see discussions + participants + delivery options Permalink ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/T1c604a219c5fa805-M273af9a3330b1167b9ead573 Delivery options: https://cyrus.topicbox.com/groups/info/subscription
