I found my notes from when I set up the connection between cyrus and the AD, I am sending them directly rather than on list just in case I haven't redacted any server names etc. properly.
The contents of my saslauthd.conf file are included (with domain and server info redacted).
I remember spending a lot of time with wireshark noting that one of the methods (presumably starttls) resulted in a one sided communication with the AD ignoring the cyrus server or something.
As far as I know this is the setup that we are currently using.
I must also stress that I am not an IT professional, I am an engineer in a very small company who also ends up sorting out the boss' grand IT plans (which he never matches with a suitable budget - hence we are using EEOL windows servers now), and this may be entirely the wrong way to achieve this. In particular note that I ended up using a self signed CA on the local network to enable the connection - if you are linking sites you might need to set up something more trustable.
Also note that I inherited an LDAP schema from SBS2003 which makes things a little more complex than a straight 2013 LDAP schema would.
*****
Notes from w/b 16/05/21
Cyrus & saslauthd are both running and appear to work as per the documentation (i.e. the debian section on the cyrus website).
Login as own user and us su – to get root privileges with full root environment (for paths etc. to work properly)
Note that chkconfig is obsolete so use systemctl instead. Examples:
systemctl status saslauthd (report status of saslauthd)
systemctl restart cyrus-imapd (restart imapd and reload the config file)
systemctl enable cyrus-imapd (cause imapd to start on boot)
Configuration files:
/etc/cyrus.conf
/etc/imapd.conf
/etc/saslauthd.conf
/etc/default/saslauthd
Current plan is to use the SASL LDAP method in Cyrus to authenticate using saslauthd against Active Directory (AD) on Domain Controller (DC).
Because this requires a password to be sent in plain text, it is necessary to first encrypt the connection between saslauthd and AD using TLS.
In /etc/default/saslauthd
Change MECHANISMS = “sasldb” to MECHANISMS = “ldap”
Previously we were authenticating against a local sasldb database, but the aim is to reduce the number of places that usernames and passwords need to be stored.
Now they are only going to be stored in AD on the DC and the mail server will simply query it to see if the user is allowed to read a mailbox
I then needed to create /etc/saslauthd because it did not exist:
# Jims attempt to create config to connect to Active Directory on Windows
# Domain Controller
# This line is for insecure LDAP which is not a good idea as passwords
# have to be sent in plain
#ldap_servers: ldap://{DC name here}:389
# This line is for secure LDAP
ldap_servers: ldaps://{DC name here}:636
# Normally we could just search {domain name here).local but because the AD is
# inherited from the old SBS, the susers are in3bd
# SBSUsers.Users.MyBusiness.{domain name here) so we have to create a more
# detailed search base to get them. But if we do this we can't authenticate
# users in the top level Users.{domain name here) (which is where I put
# saslauthd so might need to switch search bases at some point in future.
#ldap_search_base: dc={domain name here),dc=local
ldap_search_base: ou=SBSUsers,ou=Users,ou=MyBusiness,dc={domain name here),dc=local
# This matches the username part of the supplied argument to the AD property
# sAMAccountName, which is similar to linux UID and identifies a user
# uniquiely (which email addresses and common names don't)
ldap_filter: sAMAccountName=%U
# We need to provide some credentials to read from AD so a made a user
# called saslauthd with the password shown. Note that because we had to
# change the search base to get SBS users we need to give the full dn
# for the bind to be successful
#ldap_bind_dn: cn=saslauthd,dc=s{domain name here),dc=local
ldap_bind_dn: cn=saslauthd,cn=Users,dc={domain name here),dc=local
ldap_password: {Redacted}
# In order to use LDAPS for lookups to protect passwords, we need to tell
# saslauthd where to find the CA certs to validate the server cert
ldap_tls_cacert_file: /etc/ssl/certs/{DC name here}-CA-Cert.pem
ldap_tls_cacert_dir: /etc/ssl/certs
ldap_tls_check_peer: yes
# We don't seem to need to set this value?
#ldap_tls_cert: /etc/ssl/certs/LDAPS.pem
Note that after tweaking we have ldaps connection working (TLS secured) and can authenticate users in the SBSUsers folder in AD users and computers.
To do this we need to provide some authentication credentials for the ldap bind, so I created a user called saslauthd in the top level Users folder in AD (note that I need to explicitly add cn=Users to the dn).
We also needed some certificates, which are provided by the windows machines.
In order to use LDAPS on a DC for access to AD, it needs a certificate which provides server identification.
Most guides to do this take the short cut of installing AD certificate services (ADCS) on the DC, but this is widely said to be a bad idea.
So instead I installed ADCS on {Local server name here}, and set it up as a Certificate Authority (CA) with a self signed CA certificate.
The self signed certificate needed to be exported to {cyrus server name here} – open it in windows and on the details tab choose “copy to file...” and choose “Base 64 encoded X.509 (.cer)”.
Once saved we need to change the file extension to .pem for linux and copy to /etc/ssl/certs.
Update: copy the file to /usr/local/share/ca-certificates/ and when you run update_ca_certificates below it creates a link in /etc/ssl/certs and appends the certificate to ca-certificates.crt
For the certificate for the DC itself, just need to reboot the DC and when it finds there is an AD CS server on startup it requests the certificate and it is automatically created.
I also exported this cert but this might not have been necessary because I think the DC presents it.
Apparently in debian we also need to run update_ca_certificates before the new CA certificate is useable, but the output suggested it had done nothing.
This was because I had dropped the certificate in the final location and not the custom store, see notes above. When certificate is in the custom store this command works properly.
I needed to set the ldap_tls_... options in the file above to use the CA certificate to recognise the server certificate.
Some testing commands:
testsaslauthd –u {username} –p {password}
Try with any user in SBSUsers with their password and it should return OK.
It will not work for users in other folders in AD.
Demostrates that SASL can make a bind and authenticate the user against AD
/usr/lib/cyrus/bin/imtest –t “” –u {username} –a {username} localhost
This tests the imap server.
The username with –u can be any username, the username with –a is the user whose password you will need to enter (interactively), so far I have only tested with the same user for both, I think using different users might be useful if mailboxes have delegation set up?
This command will list some stuff and then ask for a password, if the correct password is supplied it should say Authenticated and then be looking for more input (use ctrl-c to get out of it)
By finish of 21/05/21 I had both commands giving me positive results showing that I could contact the imap server and authenticate a user against AD from it.
I then added a user “testuser” to AD with a temporary password and created an account in thunderbird which was able to successfully connect to {cyrus server name} and access an automatically created mailbox.
*****
Best regards
Jim
On 13/03/2024 14:07, denis via Info
wrote:
Hi Jwallis
I am facing the same issues as yours although not exactly. I also belief that in the near future Microsoft will force us to use ldaps so I am trying to get Cyrus-imap authentication with windows 2022 AD over ldaps.
The only difference from you is that I don’t need ptloader I don’t need groups information. I only need user authentication.
Currently I managed to setup in the Lab a working cyrus-imap which authenticate through Windows 2022 AD over ldap (not secured and I could see the password in plain text)
I imported CA certificate and updated the local thrusted stores.
Executed the following command:
ldapwhoami -ZZ -H ldap://dnsservername -D "CN=xxxxx,CN=Users,DC=xxxxxxx,DC=xxx" -W
and I got the proper reply. Which indicate that the AD is accepting connections on LDAPS port and CA was properly imported.
I belief something is related to configurations in /etc/saslauthd.conf file
Do you have a typical /etc/saslauthd.conf file which permits authentication over LDAPS please?
Thanks
Denis
