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 <https://cyrus.topicbox.com/latest>* / Info / see discussions
<https://cyrus.topicbox.com/groups/info> + participants
<https://cyrus.topicbox.com/groups/info/members> + delivery options
<https://cyrus.topicbox.com/groups/info/subscription> Permalink
<https://cyrus.topicbox.com/groups/info/T1c604a219c5fa805-M059a18671a19543256a45753>
------------------------------------------
Cyrus: Info
Permalink:
https://cyrus.topicbox.com/groups/info/T1c604a219c5fa805-M2157f1b6017def01b02f257e
Delivery options: https://cyrus.topicbox.com/groups/info/subscription
