Unable to authenticate OpenLDAP users on macOS clients "user not found: no secret in database"

Question

I have an Ubuntu 16.04 server that is runnning an OpenLDAP server. I am able to see everything just fine:

serveradmin@Magic:~$ ldapsearch -x -H ldap://localhost -D cn=admin,dc=example,dc=com -W
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: work
dc: example

# admin, example.com
dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
...

# Groups, example.com
dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups

...

# Policies, example.com
dn: ou=Policies,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Policies
description: Password policy for users

# foo, People, example.com
dn: uid=foo,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
sn: foo
...

On my any macOS client of my choosing from OS High Sierra down to El Capitan I can run:

a0216:data admin$ dscl localhost -list /LDAPv3/example.com/Users
foo
bar
...

Which will retreive a list of all of my users.

I use a MacBook Pro 2016 edition running High Sierra. When I attept to authenticate as a user under the Directory Utility it successfully allows me to authenticate:

Jun 14 16:36:23 magic slapd[344850]: conn=1276 op=1 SRCH attr=uidNumber uid userPassword
Jun 14 16:36:23 magic slapd[344850]: conn=1276 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:36:24 magic slapd[344850]: conn=1277 fd=19 ACCEPT from IP=10.0.1.20:65410 (IP=0.0.0.0:389)
Jun 14 16:36:24 magic slapd[344850]: conn=1277 fd=19 closed (connection lost)
Jun 14 16:36:24 magic slapd[344850]: conn=1278 fd=19 ACCEPT from IP=10.0.1.20:65411 (IP=0.0.0.0:389)
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=0 SRCH attr=supportedSASLMechanisms defaultNamingContext namingContexts schemaNamingContext saslRealm
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=1 BIND dn="uid=foo,ou=People,dc=example,dc=com" method=128
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=1 BIND dn="uid=foo,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=1 RESULT tag=97 err=0 text=

However if I attempt the same thing from an iMac running either High Sierra, or El Capitan I get the following:

Jun 14 16:40:04 magic slapd[344850]: conn=1345 op=3 SRCH attr=uidNumber uid userPassword
Jun 14 16:40:04 magic slapd[344850]: conn=1345 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:40:04 magic slapd[344850]: conn=1358 fd=19 ACCEPT from IP=10.0.1.67:49545 (IP=0.0.0.0:389)
Jun 14 16:40:04 magic slapd[344850]: conn=1358 fd=19 closed (connection lost)
Jun 14 16:40:04 magic slapd[344850]: conn=1359 fd=19 ACCEPT from IP=10.0.1.67:49546 (IP=0.0.0.0:389)
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=0 SRCH attr=supportedSASLMechanisms defaultNamingContext namingContexts schemaNamingContext saslRealm
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=1 BIND dn="" method=163
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: security flags do not match required
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=2 BIND dn="" method=163
Jun 14 16:40:04 magic slapd[344850]: SASL [conn=1359] Failure: no secret in database
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=2 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=3 UNBIND
Jun 14 16:40:04 magic slapd[344850]: conn=1359 fd=19 close

I have tried everything that I can possibly think of and have a feeling the answer is starring me directly in the face. Does anybody know why I keep getting No secret in database while attempting to login from an iMac ,and is there a simple solution to this issue?

I have done some research and come across a few things (IE this) however, what I have come across the directions and ideas are not clear, and it seems like it works differently for everyone. Any help or a point in the right direction would be greatly appreciated. Thank you

Brian Mc · Answer 1 · 2022-05-05T16:39:13.083

I recently had an issue with this. I was unable to get user authentication to work while the DIGEST-MD5 and CRAM-MD5 mechanisms were being presented as options from the server. I wanted to make the change on the LDAP server rather than modify each client with plist settings.

The following two methods worked to fix user authentication by blocking the server from using the 2 SASL MD5 mechanisms. Tested with macOS Yosemite and Mojave clients bound to an OpenLDAP server version 2.4.44.

METHOD 1: Set the olcSaslSecProps noactive option which will disable all mechanisms that are susceptible to active non-dictionary attacks. (Note: There are other options as well see: https://docs.oracle.com/javase/jndi/tutorial/ldap/security/sasl.html)

vi modify_olcSaslSecProps.ldif

dn: cn=config
changetype: modify
replace: olcSaslSecProps
olcSaslSecProps: noplain,noanonymous,noactive

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

To view the changes before and after the modify:

ldapsearch -H ldapi:/// -x -s base -b "" -LLL "+" | grep sasl

BEFORE:
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN

AFTER:
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: GSSAPI

METHOD 2: Which gives even more control is to create a configuration file that allows the specific SASL mechanisms desired. For me on a CentOS 7.9 server with Cyrus SASL 2.1.26 package installed. Create a file named slapd.conf with the contents shown below and then reload slapd service for the changes to take effect. Edit the SASL mechanisms as desired in lowercase with a single space between each.

vi /usr/lib64/sasl2/slapd.conf

mech_list: plain login external gssapi gss-spnego

systemctl reload slapd.service

Also the the olcSaslSecProps should be set to "noplain,noanonymous".

vi modify_olcSaslSecProps.ldif

dn: cn=config
changetype: modify
replace: olcSaslSecProps
olcSaslSecProps: noplain,noanonymous

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

There is a typo in your answer but I can't submit a change less than 6 characters. "chagetype" should be "changetype" — Tamerz, Apr 19 '22 at 13:00

CertifcateJunky · Accepted Answer · 2018-06-18T22:00:59.937

I FIGURED IT OUT!

Okay so the issue is that macOS tries to authenticate using CRAM-MD5. OpenLDAP default is DIGEST-MD5. In order for this to work you have to add the hashing algorithm to the plist for when the SASL authentication fails. To do so:

sudo su 
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string DIGEST-MD5" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist 
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string CRAM-MD5" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string NTLM" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string GSSAPI" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist

Restart the Mac, and it will work successfully. Also, make sure you copy the plist so you don't have to screw with it anymore!

score 1 · Answer 3 · answered Jul 16 '18 at 21:03

I also ran into this when integrating MacOS with my OpenLDAP-based IAM solution which has hashed passwords and therefore does not support challenge-response mechanisms like CRAM-MD5 or DIGEST-MD5:

MacOS tries the SASL mechs it finds in the LDAP server's rootDSE in attribute supportedSASLMechanisms. So instead of configuring SASL mechs in each MacOS LDAP client I've made the unwanted SASL mechs invisible by ACL in OpenLDAP (static) configuration.

The following two ACLs make all SASL mechs invisible except EXTERNAL (used for LDAPI and with TLS client certs):

# allow anonymous access to supportedSASLMechanisms: EXTERNAL
access to
  dn.base=""
  attrs=supportedSASLMechanisms
  val.regex="^EXTERNAL$"
    by * read
# deny access to all other SASL mech values
access to
  dn.base=""
  attrs=supportedSASLMechanisms
    by * none

Unable to authenticate OpenLDAP users on macOS clients "user not found: no secret in database"

3 Answers3