On Nov 1, 2022, at 2:54 PM, Quanah Gibson-Mount <quanah@fast-mail.org> wrote:

--On Tuesday, November 1, 2022 7:16 PM +0000 jarett@bioteam.net wrote:

Hi,

I am attempting to have SSSD do logins to my OpenLDAP 2.6.3 installation,
however, I get "permission denied" when trying to log in because SSSD is
asking for a password policy, which the server does not appear to have by
default. Notably, we don't really care what "policy" the server will
claim to have, because password authentication is delegated via SASL to
another server which ensures strong passwords. So I just need something
that will "get past" whatever checks SSSD is doing. What LDIF config can
I add to my configuration to allow SSSD to let users log in properly?

You could simply load the ppolicy overlay in you configuration so that the control is available, regardless of whether you intend to use it.

How is this done? In the LTB distribution there is a ppolicy ldif in the schema directory of openldap/etc; no such file exists for "vanilla" OpenLDAP and I'm not even sure if it would be compatible.

However nothing in the log you provided shows there was any issue due to SSSD requesting it.

The BIND operation was successful:

Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 RESULT tag=97 err=0 qtime=0.000028 etime=0.000136 text=

The SEARCH operation was successful:

Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000016 etime=0.000326 nentries=0 text=

The biggest issue seems to be that it is configured to send invalid search filters, causing ZERO results to be returned (nentries=0 above):

ov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH base="ou=users,dc=clab,dc=lab" scope=2 deref=0 filter="(&(?objectClass=sudoRole)(|(&(!(?sudoHost=*))(cn=de>
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH attr=objectClass objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs sudoRunAsUser sudoRunAs>

Note that "sudoRole" objectClass, "sudoHost" attribute is not found. Note that "cn=de>" is not a valid filter.

Those were just truncated lines. Here is another example without the truncation:

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 fd=14 ACCEPT from IP=10.8.8.202:35250 (IP=0.0.0.0:389)

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000018 etime=0.000221 nentries=1 text=

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=1 BIND dn="cn=admin,dc=clab,dc=lab" method=128

Nov 02 06:40:46 ldapserver00 slapd[109046]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=1 BIND dn="cn=admin,dc=clab,dc=lab" mech=SIMPLE bind_ssf=0 ssf=0

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=1 RESULT tag=97 err=0 qtime=0.000018 etime=0.000106 text=

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=2 UNBIND

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 fd=14 closed

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 fd=14 ACCEPT from IP=10.8.8.202:35260 (IP=0.0.0.0:389)

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000016 etime=0.000145 nentries=1 text=

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=1 BIND dn="cn=admin,dc=clab,dc=lab" method=128

Nov 02 06:40:46 ldapserver00 slapd[109046]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=1 BIND dn="cn=admin,dc=clab,dc=lab" mech=SIMPLE bind_ssf=0 ssf=0

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=1 RESULT tag=97 err=0 qtime=0.000018 etime=0.000092 text=

Nov 02 06:40:46 ldapserver00 slapd[109046]: get_filter: conn 1006 unknown attribute type=sudoHost (17)

Nov 02 06:40:46 ldapserver00 slapd[109046]: get_ssa: conn 1006 unknown attribute type=sudoHost (17)

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=2 SRCH base="ou=users,dc=clab,dc=lab" scope=2 deref=0 filter="(&(?objectClass=sudoRole)(|(&(!(?sudoHost=*))(cn=defaults))(?sudoHost=ALL)(?sudoHost=ldapclient)(?sudoHost=ldapclient)(?sudoHost=10.8.8.202)(?sudoHost=10.8.8.0/24)(?sudoHost=fe80::f9:c8ff:fe92:990d)(?sudoHost=fe80::/64)(?sudoHost=+*)))"

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=2 SRCH attr=objectClass objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp

Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000018 etime=0.000227 nentries=0 text=

Nov 02 06:42:03 ldapserver00 slapd[109046]: conn=1006 op=3 UNBIND

Nov 02 06:42:03 ldapserver00 slapd[109046]: conn=1006 fd=14 closed

root@ldapserver00:/tmp#

I note in the SSSD documentation it says it will not perform authentication binds in cleartext. I think(?) I am running the server with SSL but not START-TLS.