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?
The error from `journalctl -u slapd` is shown below:
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 fd=11 ACCEPT from IP=10.8.8.202:41516 (IP=0.0.0.0:389) Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion> Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000020 etime=0.000271 nentries=1 text= Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 BIND dn="cn=admin,dc=clab,dc=lab" method=128 Nov 01 18:16:58 ldapserver00 slapd[105481]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 BIND dn="cn=admin,dc=clab,dc=lab" mech=SIMPLE bind_ssf=0 ssf=0 Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 RESULT tag=97 err=0 qtime=0.000028 etime=0.000136 text= Nov 01 18:16:58 ldapserver00 slapd[105481]: get_filter: conn 2239 unknown attribute type=sudoHost (17) Nov 01 18:16:58 ldapserver00 slapd[105481]: get_ssa: conn 2239 unknown attribute type=sudoHost (17) Nov 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> 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=
TIA!
--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.
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.
Regards, Quanah
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.
The documentation describes the password policy overlay, but appears to be in conf format rather than the ldifs we use now and there's no indication as to what sort of "default" options would normally be associated with permitting a client to bind, check passwords for login and allow or reject the login. https://www.openldap.org/doc/admin26/overlays.html (section 12.10.2) I imagine there must be a reference for this somewhere as it has to be one of the most common LDAP use cases?
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.
Jarett T. DeAngelis, MS
Scientific Systems Engineer
Email: jarett@bioteam.net mailto:jarett@bioteam.net M: +1.646.417.2165
bioteam.net https://www.bioteam.net/
--On Wednesday, November 2, 2022 2:41 AM -0500 Jarett DeAngelis jarett@bioteam.net wrote:
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.
https://www.openldap.org/doc/admin25/appendix-upgrading.html
"B.2. ppolicy overlay
The overlay now implements version 10 of the ppolicy draft in full. This includes the notion of a password administrator where applicable (as determined by having a manage permission to the userPassword attribute) and skips certain processing when there is no valid policy in effect or where the operation is initiated by a password administrator. Many attributes are now tagged with NO-USER-MODIFICATION in the schema, requiring the use of relax control to modify them.
In OpenLDAP 2.4 the slapo-ppolicy(5) overlay relied on a separate schema file to be included for it to function. This schema is now implemented internally in the slapo-ppolicy module. When upgrading slapd.conf(5) deployments the include statement for the schema must be removed. For slapd-config(5) deployments, the config database must be exported via slapcat and the old ppolicy schema removed from the export. The resulting config database can then be imported."
No idea why the LTB project would ship a retired schema file, you'd need to ask them.
The documentation describes the password policy overlay, but appears to be in conf format rather than the ldifs we use now and there's no indication as to what sort of "default" options would normally be associated with permitting a client to bind, check passwords for login and allow or reject the login. https://www.openldap.org/doc/admin26/overlays.html (section 12.10.2) I imagine there must be a reference for this somewhere as it has to be one of the most common LDAP use cases?
I would note again that nothing in your log indicates that the lack of the ppolicy overlay is the source of any problems. There is simply a warning thrown and then the operation proceeds and completes normally with no issues reported.
Since ppolicy is a database specific module, you would first add it to the module load section of the global configuration (assuming it was built as a module) and then instantiate it as an overlay on top of the backend, as demonstrated in the code for test022-ppolicy:
dn: olcOverlay=ppolicy,olcDatabase={#}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy
I don't know which database number your MDB database is, so you'd need to fill that in above. There's no need to specify anything for the configuration past that unless you intend to actually make use of the overlay.
But again, nothing indicates the lack of it being present as the source of any issues in your deployment.
Those were just truncated lines. Here is another example without the truncation:
The logs again show that the sudo schema is missing from the system, but that all operations executed do so correctly. Nothing in your logs indicates any issues being caused by the lack of the ppolicy overlay being instantiated.
So, if you want to remove all the reported issues from your logs, you can instantiate ppolicy, and you can load the sudo schema. That may better enable you to track down the actual root cause by removing extraneous noise.
Regards, Quanah
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 01.11.2022 um 20:54
in Nachricht <AA5643E98105A35D696CE959@[192.168.1.15]>:
‑‑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.
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.
For some strange reason sssd starts do query the sudo schema, even if it was not configured on the server, typically flooding the logs with invalid requests. I added the schema here, just to silence the errors...
Regards, Quanah
On Wed, Nov 02, 2022 at 08:48:39AM +0100, Ulrich Windl wrote:
For some strange reason sssd starts do query the sudo schema, even if it was not configured on the server, typically flooding the logs with invalid
That's the default. You need to add "sudo_provider = none" to the sssd config under the domain section that's using ldap as an id_provider.
openldap-technical@openldap.org
-
Jarett DeAngelis -
jarett＠bioteam.net
-
Paul B. Henson -
Quanah Gibson-Mount -
Ulrich Windl