Join Log in
Score:0
William Seligman avatar Server

sendmail and LDAP-based aliases

hu flag
William Seligman

Environment: CentOS 7.9, Sendmail 8.14, OpenLDAP 2.4

I'm trying to get sendmail to read its aliases from an LDAP database (this has worked with NIS for years, but NIS is fading into the twilight). My mail server is an LDAP client. In mailserver:/etc/mail/sendmail.mc:

define(confLDAP_DEFAULT_SPEC, `-H ldaps://ldap.myoffice.mycompany.org -b "ou=Aliases,dc=myoffice,dc=mycompany,dc=org" -d "uid=sendmail,dc=myoffice,dc=mycompany,dc=org" -M simple -P /etc/mail/secret')dnl
define(`ALIAS_FILE',`ldap:-k (&(objectClass=nisMailAlias)(cn=%0)) -v "rfc822MailMember",/etc/aliases')dnl

Deriving that first line was painful, since my web-fu was poor as I searched for documentation on the sendmail K macro for LDAP. This page was the best I could find, and it appears to be for an older version of sendmail.

When I restart sendmail on the mail server and try to use the aliases database, the response is:

# sendmail -bv sysadmin
ldap_init/ldap_bind failed to ldaps://ldap.myoffice.mycompany.org in map Alias0: Protocol error
sysadmin... deliverable: mailer local, user sysadmin

Note when I revert back to the NIS version, the alias resolves; this is the output I was expecting:

# sendmail -bv sysadmin
myname... deliverable: mailer local, user myname

In mailserver:/etc/openldap/ldap.conf:

BASE    dc=myoffice,dc=mycompany,dc=org
URI     ldaps://ldap.myoffice.mycompany.org ldaps://ldap-replica-1.myoffice.mycompany.org ldaps://ldap-replica-2.myoffice.mycompany.org

SIZELIMIT       unlimited

TLS_CACERT /etc/mail/certs/certs-latest/__myoffice_mycompany_org.cer
TLS_CACERTDIR /etc/mail/certs/certs/certs-latest

__myoffice_mycompany_org.cer is in PEM format and contains the certificate chain and a wildcard certificate for my site, *.myoffice.mycompany.org.

For authentication and searches outside of sendmail, the LDAP searches on via the mail server's LDAP client configuration appear to work just fine. Here are my tests, all of which produce the results I expect:

# Authentication-type searches
ldapsearch -LLL -x -H ldaps://ldap.myoffice.mycompany.org "(uid=myname)"
ldapsearch -LLL -x uid=myname -b dc=myoffice,dc=mycompany,dc=org
ldapsearch -LLL -x uid=myname

# Mail-aliase-type searches
ldapsearch -x -h ldap.myoffice.mycompany.org -b "ou=Aliases,dc=myoffice,dc=mycompany,dc=org" "cn=sysadmin"
ldapsearch -x -H ldaps://ldap.myoffice.mycompany.org -b "ou=Aliases,dc=myoffice,dc=mycompany,dc=org" "cn=sysadmin"
ldapsearch -H ldaps://ldap.myoffice.mycompany.org -b "ou=Aliases,dc=myoffice,dc=mycompany,dc=org" "(cn=sysadmin)" -D "uid=sendmail,dc=myoffice,dc=mycompany,dc=org" -y /etc/mail/secret

The output of the last three commands is identical, and demonstrates that I set up the aliases on the LDAP server according to misc.schema:

# extended LDIF
#
# LDAPv3
# base <ou=Aliases,dc=myoffice,dc=mycompany,dc=org> with scope subtree
# filter: cn=sysadmin
# requesting: ALL
#

# sysadmin, Aliases, myoffice.mycompany.org
dn: cn=sysadmin,ou=Aliases,dc=myoffice,dc=mycompany,dc=org
cn: sysadmin
objectClass: nisMailAlias
objectClass: top
rfc822MailMember: myname

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Note that for the last ldapsearch above, in order to try to debug what's going on, I created a separate user uid=sendmail,dc=myoffice,dc=mycompany,dc=org on my LDAP server, with the clear-text password in /etc/mail/secret.

In sendmail.mc, I have also tried:

define(confLDAP_DEFAULT_SPEC, `-h ldap.myoffice.mycompany.org -b "ou=Aliases,dc=myoffice,dc=mycompany,dc=org"')dnl

define(confLDAP_DEFAULT_SPEC, `-H ldaps://ldap.myoffice.mycompany.org -b "ou=Aliases,dc=myoffice,dc=mycompany,dc=org"')dnl

but the results were the same.

Just to confirm that account myname exists (though I doubt that's the issue):

# ldapsearch -LLL -x uid=myname -b dc=myoffice,dc=mycompany,dc=org
dn: uid=myname,ou=People,dc=myoffice,dc=mycompany,dc=org
uid: myname
cn: Bill Myname
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 17316
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 11230
gidNumber: 10130
homeDirectory: /myoffice/desktop/home/myname
gecos: Bill Myname,Room 321,x2280

What am I missing? Or to put it another way, how are the LDAP lookups in sendmail different from LDAP lookups in the rest of CentOS?

Edit:

I found a web page that suggested that the problem might be that sendmail on CentOS 7 may use certificates in its NSS store instead of just the text files in the CERT_DIR directory. I followed the directions suggested on that page:

cd /etc/openldap/certs
certutil -A -d . -n "Myoffice 2022" -a -i /etc/mail/certs/certs-latest/__myoffice_mycompany_org.cer -t "CT,c,"

But this made no changes in sendmail's LDAP+aliases behavior.

123
1 + 2
pt flag
larsks
I guess my first recommendation would be, "why are you using sendmail? Use a more modern mailer with a less baroque (arguably "broke") configuration syntax.", but if you're determined to go down this painful route, consider turning up the logging in your LDAP service so that you can see exactly what queries sendmail is making (if any). If you can't do that, then consider (a) using `ldap://` instead of `ldaps://` and capturing the traffic with `tcpdump`, or (b) if that's not possible, set up an `ldap` to `ldaps` proxy so that you can accomplish the same thing with an extra step.
0
Reply
William Seligman avatar
hu flag
William Seligman
The answer to your question: Because I've spent years configuring sendmail to do what I want it to do. Switching to a different MTA means potentially disrupting services for my users. I know that postfix is described as a superior MTA, but if everything works in sendmail (mailer tables, access lists, mailing-list routing), a better configuration syntax just doesn't seem to be a compelling enough reason.
0
Reply
Score:1
William Seligman avatar Server
hu flag
William Seligman

Thanks to larsks's suggestion, I have the answer. It turned out that olcLogLevel on my LDAP server was already set to -1. I hunted through the logs, which I thought I'd done before, but evidently not carefully enough. I found the message:

send_ldap_result: err=2 matched="" text="historical protocol version requested, use LDAPv3 instead"

It turns out that sendmail 8.14 by default uses the LDAPv2 protocol, which was made obsolete with LDAPv3 many years ago. A web search showed me the procedure to add the option on my LDAP server to accept v2 connections:

In allow_bind_v2.ldif:

dn: cn=config
add: olcAllows
olcAllows: bind_v2

Then I issued the command

# ldapmodify -H ldapi:// -Y EXTERNAL -f allow_bind_v2.ldif

Going back to my mail server, I discovered that a simple configuration was sufficient in my sendmail.mc:

define(confLDAP_DEFAULT_SPEC, `-H ldaps://ldap.myoffice.mycompany.org -b "ou=Aliases,dc=myoffice,dc=mycompany,dc=org"')dnl

After restarting sendmail, I got the results I expected:

# sendmail -bv sysadmin
myname... deliverable: mailer local, user myname

While this worked, it seemed incredible to me that after all these years that even a relatively older version of sendmail couldn't support LDAPv3. Now that I knew what to look for, I found this page which explained how to get sendmail to use LDAPv3: add -w 3 to the confLDAP_DEFAULT_SPEC:

define(confLDAP_DEFAULT_SPEC, `-H ldaps://ldap.myoffice.mycompany.org -b "ou=Aliases,dc=myoffice,dc=mycompany,dc=org" -w 3')dnl

With that, I could turn off bind_v2 on my LDAP server:

In remove_bind_v2.ldif:

dn: cn=config
delete: olcAllows

ldapmodify -H ldapi:// -Y EXTERNAL -f remove_bind_v2.ldif

Sendmail alias resolution still worked just fine.

While I acknowledge that this entire situation+solution tends to confirm larsks' argument about sendmail, I've now got something that works. Time to move on to the next problem.

+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.