Re: LDAP authentication and authorization using Debian and Active Directory

Hello,

I have several working Cyrus installations authenticated against AD, but I do 
not use LDAP. Instead it authenticates via kerberos. To be more precise:
Cyrus/Exim -> Saslauthd -> PAM -> pam_krb5.so -> AD

For distribution groups, aliases and such stuff I use LDAP queries in Exim. But 
kerberos for authentication

Unfortunately kerberos does not give you groups. Maybe you could use winbind 
and libnss-winbind to get groups from AD to Linux and use them as if they were 
in /etc/group...

-- 
Best regards
        Vladislav Kurz

Dne úterý 15. června 2021 16:06:26 CEST, [email protected] napsal(a):
> 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
> Permalink:
> https://cyrus.topicbox.com/groups/info/T1c604a219c5fa805-M8d9393c09736a3175
> 7439505 Delivery options:
> https://cyrus.topicbox.com/groups/info/subscription





------------------------------------------
Cyrus: Info
Permalink: https://cyrus.topicbox.com/groups/info/T1c604a219c5fa805-Md37e7ffaaef955f6381abd34
Delivery options: https://cyrus.topicbox.com/groups/info/subscription